Offensive testing of healthcare and financial systems must simulate real attacks within formally authorized boundaries, with isolation, traceability, and protection of operational continuity. The appropriate approach combines application and API penetration testing, control validation, attack path simulation, and response exercises without exposing patients, moving real money, or disrupting critical services.
Why These Systems Require a Specific Approach
Healthcare and financial applications share three characteristics: they process sensitive data, integrate many systems, and can cause material impact when they fail. A vulnerability does not represent only an information leak; it can alter a clinical decision, prevent care delivery, cause financial fraud, or disrupt essential operations.
In healthcare, targets include electronic health records, patient portals, hospital systems, connected devices, HL7 v2 integrations, FHIR APIs, and telemedicine platforms. In finance, the scope may involve online banking, mobile applications, payment APIs, Pix, Open Finance, CRMs, antifraud engines, and administrative systems.
The main risks are:
- unauthorized access to personal and sensitive data protected by the LGPD;
- authentication, authorization, or segregation failures between users and organizations;
- API abuse through automation, enumeration, or logic flaws;
- alteration of clinical, registration, or financial data;
- unavailability of critical services;
- compromise of third parties, integrations, and technical credentials;
- lateral movement between applications, cloud environments, and internal networks;
- detection and response failures even when preventive controls are in place.
Therefore, running only an automated scanner is not enough. It is necessary to validate how technical flaws, identities, processes, and integrations can be combined.
Red Team, Penetration Testing, and Scanning Are Not the Same
Automated Scanning
Scanners identify vulnerable versions, insecure configurations, and known patterns. They are useful for frequent coverage, but they generate false positives and generally do not understand business rules.
Penetration Testing
A penetration test assesses a defined scope, such as a web application, API, mobile application, or cloud environment. The objective is to confirm vulnerabilities, demonstrate controlled impact, and recommend reproducible fixes.
Red Team Ops
A red team operation assesses whether people, processes, and technologies can prevent, detect, and respond to a simulated adversary. Rather than looking for every flaw, the team pursues previously approved objectives, such as determining whether it would be possible to access another institution’s clinical records or reach a privileged financial function.
Red teaming does not replace penetration testing. An organization with low maturity generally gains more value by addressing inventory, authentication, API exposure, and known vulnerabilities before conducting an objective-driven operation.
How to Define a Safe Offensive Test
Before any activity begins, there must be formal authorization with rules of engagement. This document must define:
- systems, domains, IP addresses, applications, and APIs within scope;
- prohibited environments or those allowed only during specific windows;
- authorized and expressly prohibited techniques;
- limits for social engineering, persistence, and lateral movement;
- execution times and emergency contacts;
- objective criteria for stopping the test;
- handling, retention, encryption, and disposal of evidence;
- the procedure for reporting critical vulnerabilities;
- responsibilities of the provider, client, and third parties.
In production, the principle is to minimize impact. Destructive testing, denial of service, irreversible changes, and mass data extraction must be replaced with minimal proofs. Safe evidence can use synthetic records, test accounts, and previously prepared identifiers.
An emergency channel must remain operational throughout the engagement. If there is degradation, a risk to patient care, an unexpected transaction, or a suspected simultaneous real attack, the activity must be stopped and preserved for analysis.
Offensive Testing in Healthcare Systems
Applications, FHIR APIs, and HL7 v2 Integrations
FHIR APIs must be assessed for authentication and authorization by resource, patient, organization, and clinical context. It is not enough to verify that the user is authenticated: it is necessary to confirm whether that user can perform that action on that specific resource.
Tests must examine:
- unauthorized access to resources by changing identifiers;
- excessive exposure of clinical fields;
- search and export operations without appropriate limits;
- segregation among patients, professionals, and institutions;
- tokens with excessive scopes or inappropriate validity periods;
- logs containing clinical data, tokens, or personal information;
- validation of FHIR payloads, attachments, and extensions;
- behavior of gateways, queues, and intermediary services.
In HL7 v2, security often depends on the architecture that transports and processes messages. Network segmentation, system-to-system authentication, encrypted channels, source validation, queues, retry mechanisms, and invalid message handling must be reviewed. It is also important to verify whether sensitive data appears in operational logs or observability tools.
Security Without Risk to Patient Care
An operation must not alter prescriptions, test results, or data used in patient care. When a hypothesis requires a change, the recommended approach is to reproduce it in a representative staging environment or use a clearly identified synthetic record.
Healthcare-specific stop criteria include:
- noticeable degradation of a patient care system;
- abnormal growth in integration queues;
- impact on clinical workstations or equipment;
- access to a real record beyond the authorized minimal proof;
- any possibility of influencing a medical decision.
Offensive Testing in Financial Systems
APIs, Authentication, and Business Rules
Financial systems require both technical and transactional assessment. Many relevant flaws are not found in outdated components, but in sequences allowed by business rules.
The test plan must consider:
- account recovery and device changes;
- multifactor authentication and resistance to session reuse;
- authorization by account, company, role, and transaction limit;
- changes to beneficiaries and registration data;
- replay, concurrency, and operation idempotency;
- manipulation of amounts, currencies, fees, and rounding;
- abuse of coupons, chargebacks, credit, or limits;
- API protection against enumeration and automation;
- segregation among transaction creation, approval, and execution;
- exposure of keys, secrets, and financial data in logs.
Payment testing must use sandboxes or controlled accounts and amounts. When production is indispensable, limits, recipients, reversal procedures, and monitoring must be agreed upon in advance. The objective is to demonstrate the flaw with the least possible effect, not to maximize losses.
When cardholder data is involved, applicable PCI DSS requirements must be included in the scope. For APIs, references such as the OWASP API Security Top 10 and OWASP ASVS help establish verifiable criteria, but they do not replace analysis of business rules.
Methodology and Evidence That Lead to Remediation
A technically consistent workflow can follow seven stages:
- Threat modeling: identify critical assets, likely threat actors, and attack paths.
- Authorized reconnaissance: map exposed surfaces, technologies, and integrations.
- Control validation: test authentication, authorization, sessions, inputs, and configurations.
- Controlled exploitation: confirm impact with the minimum proof required.
- Chaining: determine whether low- or medium-risk flaws form a critical path.
- Detection assessment: measure which events were logged, alerted on, and investigated.
- Retesting: confirm remediation and look for variations of the same root cause.
Each finding must include the affected asset, preconditions, sanitized evidence, impact, likelihood, root cause, and recommendation. Severity must not depend solely on a CVSS score: clinical context, transaction value, exposure, required privileges, and compensating controls also matter.
For red team operations, the report must map observed techniques to a framework such as MITRE ATT&CK and provide a timeline. Useful metrics include time to detection, time to triage, the proportion of actions logged, and the points at which the defensive team could have interrupted the attack chain.
Checklist for Contracting or Approving the Operation
Before starting, confirm:
- [ ] signed authorization and a technically identifiable scope;
- [ ] inventory of the applications, APIs, cloud environments, and third parties involved;
- [ ] test accounts with different profiles and organizations;
- [ ] synthetic data and cleanup mechanisms;
- [ ] validated backups and recovery procedures;
- [ ] active monitoring and emergency contacts;
- [ ] limits for production, social engineering, and exfiltration;
- [ ] encrypted evidence storage;
- [ ] an SLA for reporting critical findings;
- [ ] a remediation plan with responsible parties and deadlines;
- [ ] retesting included in the cycle;
- [ ] separation between the executive report and sensitive technical evidence.
How to Choose Between Penetration Testing and Red Teaming
Choose penetration testing when the objective is to find and remediate vulnerabilities within a known scope, especially after launching a new application, making a major architectural change, or implementing an integration. Choose red teaming when the organization already has basic controls, monitoring, and a response team, but needs to determine whether a chained attack would be detected and contained.
The trade-offs are clear: penetration tests provide broader coverage of flaws per asset; red teams provide greater operational realism but cover fewer vulnerabilities. Testing in a staging environment reduces risk but may conceal configuration differences. Testing in production increases fidelity but requires stricter limits and a real ability to stop the operation.
How Predictor Solutions Addresses This
Predictor Solutions conducts offensive assessments with authorized scopes, threat modeling, application and API testing, cloud validation, and attack path analysis. In healthcare, its experience with systems, dashboards, wearables, HL7 v2, and FHIR helps assess controls without overlooking patient care risks; in financial and corporate platforms, the analysis includes authorization, integrations, identities, and business rules.
The company also works on secure development and remediation of identified root causes, connecting red teaming, software engineering, DevOps, and observability. This work is part of an operation that has already served 9 medium and large companies, with reported overall results of R$1.32 million in average savings per client per year, a 70% average increase in productivity, and a 43% increase in profit over six months.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.