Category: Security
Offensive testing in healthcare and financial systems must reproduce real attacks without putting patients, transactions, or personal data at risk. To achieve this, a Red Team operation must combine formal authorization, a precise technical scope, rules of engagement, continuous monitoring, and immediate termination when there is any clinical, financial, or operational impact.
Why These Systems Require a Different Approach
Healthcare and financial applications share three characteristics: they process sensitive data, integrate many systems, and support operations that cannot simply be shut down. A vulnerability can cause information exposure, fraud, unavailability, or decisions based on incorrect data.
In healthcare, the risk does not end with confidentiality. An attack against medical records, prescriptions, devices, or integrations can affect the integrity of the data used in patient care. A tampered HL7 v2 message, for example, can associate a result with the wrong patient; a poorly implemented FHIR authorization mechanism can expose third-party clinical resources.
In financial applications, concerns include changing beneficiaries, replaying transactions, abusing limits, manipulating webhooks, and compromising privileged accounts. Even when no money is moved, changes to balances, reconciliations, or audit trails can cause significant losses.
Therefore, running automated tools without considering the context does not constitute a mature Red Team operation. The work must validate complete attack paths, including people, applications, APIs, identity, infrastructure, cloud, and detection capabilities.
Red Team, Penetration Testing, and Scanning Are Not the Same Thing
The choice of format should be based on the objective:
- Vulnerability scanning: identifies versions, configurations, and known patterns. It is fast and recurring, but it produces false positives and rarely demonstrates impact.
- Penetration testing: tests a defined scope, such as an API, web application, or cloud environment. It looks for exploitable vulnerabilities and provides technical evidence.
- Red Team Ops: simulates an adversary’s objectives, such as accessing medical records, compromising a financial account, or reaching the production environment. It also assesses prevention, detection, and response.
- Purple Team: promotes collaboration between offense and defense teams to test controls, adjust alerts, and repeat scenarios until they are detected.
A penetration test is more appropriate before a launch, after significant changes, or when evaluating a specific integration. A Red Team exercise makes more sense when the organization already has basic controls, centralized logs, and a team capable of responding. Without these elements, the exercise tends only to confirm already expected weaknesses.
What Must Be in Place Before the First Test
No offensive activity should begin based only on verbal authorization. The Rules of Engagement document must be approved by the technical, legal, and business stakeholders.
Authorization and Scope Checklist
- authorized assets, domains, IP addresses, applications, and APIs;
- permitted and explicitly prohibited environments;
- test period, schedule, and traffic origin;
- permitted, conditional, and prohibited techniques;
- limits for phishing, social engineering, and physical access;
- contacts available throughout the entire operation;
- an emergency stop procedure, known as a kill switch;
- a policy for collecting, storing, and destroying evidence;
- handling of third-party services and shared infrastructure;
- criteria for immediately reporting a critical vulnerability.
Dependencies that do not belong to the organization must also be identified. Authorization to test a portal does not permit attacks against the payment provider, health insurance provider, email service, or cloud platform outside the applicable contractual conditions.
Real data should be avoided whenever synthetic data adequately represents the scenario. When the use of production data is indispensable, collection must be minimal, encrypted, and traceable, with restricted access and a defined deletion deadline.
Offensive Scenarios for Healthcare Systems
The test must follow the clinical workflow, not just the application’s screens. This includes registration, care delivery, results, prescriptions, billing, integrations, and administrative profiles.
FHIR APIs and HL7 v2 Integrations
For FHIR APIs, the main tests involve authentication, resource-level authorization, and segregation among patients, professionals, and organizations. It is necessary to look for vulnerabilities such as BOLA/IDOR, filters that allow enumeration, excessive scopes, indirect references, and improper exposure in histories or search results.
For HL7 v2, the focus includes message validation, trust between systems, source control, unexpected fields, message replay, and error handling. The test must never insert ambiguous clinical information into production without previously agreed-upon containment measures.
Other relevant scenarios include:
- compromise of professional and administrator accounts;
- unauthorized access across organizations or units;
- alteration of prescriptions, results, or patient identification;
- data extraction through reports, exports, and logs;
- abuse of integration tokens and service accounts;
- lateral movement from legacy applications;
- unavailability of components essential to patient care.
Criticality must consider the clinical effect, not just the CVSS score. A technically simple vulnerability can be critical if it allows information used in a medical decision to be modified.
Offensive Scenarios for Financial Applications
In financial systems, testing only the login process leaves out the highest-impact workflows. The Red Team must assess the complete transaction journey, from adding a beneficiary through confirmation, posting, reconciliation, and notification.
The most important scenarios include:
- multifactor authentication bypass and insecure account recovery;
- alteration of the recipient or amount between validation and execution;
- request replay due to a lack of idempotency;
- race conditions involving balances, limits, redemptions, or payments;
- broken segregation among users, companies, and operators;
- improper webhook signatures or webhook reuse;
- exposure of keys, tokens, and credentials in code or pipelines;
- abuse of privileged accounts and administrative dashboards;
- manipulation of reconciliation files and audit trails.
Tests involving real fund transfers must use predefined limits, controlled accounts, and rollback mechanisms. Denial-of-service attacks, password spraying, or high-volume automation require specific authorization because they may trigger lockouts, anti-fraud mechanisms, and third-party costs.
How to Conduct the Operation Safely
A consistent execution process can be divided into six stages:
- Threat modeling: identify critical assets, plausible adversaries, and attack objectives.
- Controlled reconnaissance: map external exposure, identities, technologies, and integrations without exceeding the scope.
- Initial validation: confirm vulnerabilities with the minimum interaction required to produce evidence.
- Chaining: demonstrate how smaller vulnerabilities make it possible to reach a critical asset.
- Detection and response: verify which actions were alerted on, investigated, and contained.
- Remediation and retesting: validate the implemented solution and look for alternative paths.
Each piece of evidence must record the date, asset, identity used, preconditions, relevant request or command, impact, and recommendation. Isolated screenshots are insufficient when they do not make it possible to reproduce the finding.
During testing, operators must monitor errors, latency, queues, resource consumption, and business indicators. The exercise must be stopped if there is a risk of incorrect patient care, improper financial processing, unplanned degradation, or propagation to third parties.
How to Classify and Prioritize Findings
CVSS helps standardize technical severity, but it does not replace business analysis. A useful prioritization process combines at least five criteria:
| Criterion | Practical Question |
|---|---|
| Exploitability | Does the attack require internal access, interaction, or a rare condition? |
| Technical impact | Is there a loss of confidentiality, integrity, or availability? |
| Business impact | Could it affect a patient, transaction, billing, or operation? |
| Scope | Does the issue affect one user, one organization, or the entire environment? |
| Detection | Does the activity generate an actionable alert and an adequate investigation? |
Remediation must address the root cause. If different endpoints have authorization flaws, fixing only the route used in the proof of concept preserves the vulnerable pattern. The solution may require a centralized authorization layer, automated negative tests, and a review of access profiles.
Metrics That Show Whether the Exercise Worked
The raw number of vulnerabilities does not measure maturity on its own. More useful indicators include:
- proportion of attack paths detected;
- time between the first offensive action and the first alert;
- time required for triage, containment, and escalation;
- number of preventive controls bypassed;
- percentage of findings remediated and approved during retesting;
- recurrence by root cause;
- log coverage across identities, APIs, and critical assets;
- difference between the expected impact and the demonstrated impact.
These metrics should be compared across equivalent exercises. Reducing detection time while expanding coverage is a better sign than simply finding fewer vulnerabilities.
How Predictor Solutions Addresses This
Predictor Solutions structures offensive assessments by connecting applications, APIs, identity, cloud, integrations, and business impact. In healthcare, its experience with systems, dashboards, wearables, HL7 v2, and FHIR makes it possible to assess controls without overlooking clinical safety; in financial applications, the work considers authorization, transactions, webhooks, segregation, and traceability.
The approach includes scope definition, rules of engagement, threat modeling, controlled exploitation, reproducible documentation, and retesting. When appropriate, the work also integrates security into the development lifecycle through architecture reviews, authorization testing, secrets management, cloud hardening, and improved observability.
The company, based in Lavras, Minas Gerais, has served 9 medium-sized and large organizations. Across its software, artificial intelligence, data, and automation portfolio, it reports aggregate results of R$ 1.32 million in average savings per client per year, an average 70% increase in productivity, and 43% profit growth in six months; these indicators represent the full set of projects and should not be interpreted separately as Red Team results.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.