Offensive testing in healthcare and financial systems must simulate an attacker’s real objectives, but with formal authorization, technical boundaries, and immediate interruption mechanisms. The focus is not only on finding vulnerabilities: it is on verifying whether preventive controls, monitoring, and response can prevent a flaw from becoming fraud, a data breach, or a patient care risk.
Red Team is not synonymous with pentesting
A traditional penetration test usually evaluates a defined technical scope, such as a web application, API, or cloud environment. Red Team Ops works with business objectives and may combine application analysis, identity, infrastructure, authorized social engineering, and an assessment of detection capabilities.
The practical difference lies in the question being answered:
- Pentest: which vulnerabilities can be exploited within this scope?
- Red Team: could an adversary reach a specific critical asset without being contained?
- Purple Team: how can offensive and defensive teams jointly validate and improve controls?
In healthcare, an objective could be to assess whether a compromised account could access health records beyond what is necessary. In finance, it could be to verify whether an authorization flaw would make it possible to view third-party accounts or initiate an improper transaction. Execution should use synthetic data, controlled transactions, and segregated environments whenever possible.
Why healthcare and finance require a different approach
These sectors concentrate personal data, complex integrations, and operations with little tolerance for downtime. A technique that is acceptable on an institutional website may be dangerous in an ICU, a prescription system, or a platform that processes payments.
The main risks differ, although they partially overlap:
| Sector | Critical assets | Possible impacts |
|---|---|---|
| Healthcare | health records, prescriptions, results, devices, and clinical integrations | data exposure, delays in care, alteration of clinical information |
| Financial | accounts, balances, credentials, transactions, keys, and accounting trails | fraud, unauthorized movement of funds, ledger inconsistencies, and downtime |
| Both | identity, APIs, cloud, backups, vendors, and logs | privilege escalation, data breaches, extortion, and recovery failure |
Brazil’s General Data Protection Law (LGPD) applies to both contexts, with special attention to health data, which is classified as sensitive personal data. Financial institutions must also consider industry regulations, contractual requirements, and, when card processing is involved, PCI DSS. The exact applicability must be validated by the legal, compliance, and security teams.
Safely planning the operation
No Red Team operation should begin with technical execution. The first artifact is a rules of engagement document approved by those responsible for the environment and the business.
What the rules of engagement must define
- Objective, scope, dates, and permitted windows.
- Included domains, APIs, accounts, networks, and environments.
- Authorized, conditional, and prohibited techniques.
- Data that may be accessed, copied, or only viewed.
- Limits on persistence, lateral movement, and privilege escalation.
- Operational and executive contacts available during the test.
- An immediate interruption keyword or procedure, known as a kill switch.
- Rules for evidence retention, encryption, and destruction.
- Handling of real incidents discovered during the operation.
- Responsibility for third parties, vendors, and shared services.
Third-party assets must not be tested merely because they are integrated with the system under assessment. Specific authorization from the owner and compliance with the provider’s terms are required.
Objective- and threat-based modeling
An effective operation begins with the so-called crown jewels: assets whose loss of confidentiality, integrity, or availability causes a significant impact. The team then builds plausible threat scenarios and defines evidence of success without causing real harm.
Examples of controlled objectives include:
- Demonstrating unauthorized access to a synthetic record.
- Validating whether a low-privilege account can reach an administrative function.
- Verifying whether exposed secrets provide access to a restricted environment.
- Simulating a transaction attempt using a test beneficiary, amount, and account.
- Measuring whether the SOC detects and contains an authorized sequence of events.
MITRE ATT&CK can organize techniques and detection coverage. OWASP ASVS, OWASP API Security Top 10, NIST SP 800-115, and PTES help structure controls and methodology. These frameworks are complementary; none of them replaces business flow analysis.
Critical areas in healthcare systems
Clinical applications rarely operate in isolation. They connect to electronic health records, laboratories, imaging systems, insurers, devices, and identity platforms.
HL7 v2 and FHIR
HL7 v2 defines integration messages and structures, but transport protection depends on the implementation. Legacy environments may use internal channels designed under assumptions of network trust. Testing must verify segmentation, system-to-system authentication, message validation, traceability, and access restrictions.
For FHIR APIs, the assessment must include:
- token authentication and expiration;
- authorization by user, organization, patient, and resource type;
- searches and pagination without excessive exposure;
- control of bulk operations;
- prevention of direct access to another patient’s resources;
- auditing of reads, changes, and exports;
- protection against rate abuse and enumeration.
The test must not alter real prescriptions, results, or clinical data. When production testing is unavoidable, preference should be given to previously identified synthetic accounts and records, with joint monitoring and non-destructive techniques.
Critical areas in financial applications
In financial systems, vulnerabilities often appear in business logic rather than in a classic infrastructure flaw. An API may be technically protected and still allow beneficiary changes, repeated requests, or a breakdown in account segregation.
The plan must assess, in a controlled manner:
- authorization by account, company, wallet, and profile;
- strong authentication and account recovery;
- operation idempotency;
- the binding between amount, beneficiary, and confirmation;
- webhook signing and validation;
- segregation between viewing, approval, and settlement;
- transaction limits and antifraud controls;
- consistency between balance, entries, and ledger;
- data exposure in reports, logs, and exported files.
No simulation should generate an unplanned real transfer. Financial operations must use sandboxes, controlled accounts, or previously approved reversal mechanisms.
How to test without interrupting the business
There are three main environment options:
- Production: provides the greatest realism, but also the highest operational and regulatory risk.
- High-fidelity staging: reduces risk, provided it reproduces relevant identities, policies, integrations, and configurations.
- Isolated laboratory: allows more invasive techniques, but may conceal flaws that only exist in real operations.
A common strategy is to perform discovery and destructive validations in a laboratory, test controlled exploitation in staging, and reserve production for non-destructive scenarios. Healthcare requires additional attention to equipment and patient care workflows; finance requires attention to queues, reconciliations, and asynchronous events.
Security controls during testing include request limits, lower-impact time windows, snapshots, verified backups, real-time monitoring, and automatic interruption in the event of latency, errors, or downtime above the agreed threshold.
How to measure results
Counting vulnerabilities alone does not measure defense effectiveness. An executive and technical report must connect each piece of evidence to its impact and to the controls that failed.
Useful metrics include:
- MTTD: time between the start of the activity and its detection.
- MTTC: time between detection and containment.
- Percentage of techniques detected, investigated, and blocked.
- Number of independent paths to the critical asset.
- Log coverage required to reconstruct the activity.
- Remediation time by severity.
- Recurrence rate after retesting.
CVSS helps standardize technical severity, but it must be combined with context. An authorization flaw in a health record or payment system may have a higher priority than a vulnerability with a similar technical score in an asset without critical data.
Deliverables that actually help remediation
The report must be reproducible without becoming a guide for abuse. For each finding, it should include the affected asset, preconditions, minimized evidence, impact, root cause, compensating controls, and technical recommendation.
A proper closure includes:
- an executive meeting on exposure and risk decisions;
- a technical session with development, cloud, security, and operations teams;
- a remediation plan with owners and deadlines;
- updates to alerts and response procedures;
- retesting of critical flaws;
- a Purple Team exercise to validate the new coverage.
Evidence containing personal data, tokens, or secrets must be encrypted, have restricted access, and have a defined disposal deadline. Screenshots and samples should show only the minimum necessary.
Checklist for hiring or approving a Red Team
Before starting, confirm:
- [ ] Is there formal authorization and a signed scope?
- [ ] Have critical assets and intolerable impacts been identified?
- [ ] Are synthetic data and test accounts available?
- [ ] Have third parties authorized testing of their assets?
- [ ] Has the kill switch been tested?
- [ ] Have backups and recovery procedures been validated?
- [ ] Do the SOC and clinical or financial operations teams know how to escalate incidents?
- [ ] Will the report include root cause, remediation, and retesting?
- [ ] Have evidence custody and destruction procedures been defined?
- [ ] Does the test cover business logic, APIs, identity, cloud, and observability?
How Predictor Solutions handles this
Predictor Solutions, a software house based in Lavras, Minas Gerais, performs offensive security integrated with application, cloud, and data engineering. In healthcare systems, its experience with HL7 v2, FHIR, dashboards, and hospital applications enables it to assess not only endpoints, but also clinical authorization, integrations, traceability, and operational risk. In financial platforms, its work considers identity, APIs, segregation of duties, and transactional logic.
The approach combines the definition of rules of engagement, threat modeling, controlled testing, root cause analysis, and retesting. When appropriate, the operation evolves into a Purple Team exercise, transforming offensive evidence into alerts, architectural improvements, and automated tests within the development lifecycle.
Predictor Solutions has served 9 medium-sized and large companies. Across its overall project portfolio, it has recorded average savings of R$ 1.32 million per client per year, an average productivity increase of 70%, and profit growth of 43% in six months. These results describe the company’s overall operations and should not be interpreted as a specific guarantee for a security project.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.