Offensive testing in healthcare and financial systems must validate real attack paths without putting patients, transactions, or sensitive data at risk. To accomplish this, a Red Team operation must combine formal authorization, technical scope, impact limits, defensive monitoring, and a remediation plan guided by business risk.
What Is Red Team Ops?
Red Team Ops is a controlled operation that simulates the techniques, tactics, and procedures of real adversaries to assess whether an organization can prevent, detect, investigate, and contain attacks. The goal is not only to find vulnerabilities, but also to demonstrate how distinct flaws can be chained together to cause significant impact.
An operation may assess web applications, APIs, identities, cloud infrastructure, devices, third-party integrations, and Security Operations Center, or SOC, controls. The work commonly uses references such as MITRE ATT&CK, the OWASP Application Security Verification Standard, the OWASP API Security Top 10, and testing methodologies such as PTES.
Red Team Is Not Synonymous With Pentesting
The three most common approaches have different purposes:
- Vulnerability scanning: automatically identifies outdated versions, insecure configurations, and known exposures.
- Pentesting: tests a defined scope, such as an API or application, looking for exploitable vulnerabilities and evidence of impact.
- Red Team: simulates an attacker’s objectives, chains techniques together, and also measures detection and response capabilities.
A payment API may pass a vulnerability scan and still allow business rule abuse. Likewise, a hospital system may have no known vulnerabilities but still present inadequate authorization across medical records, facilities, or professional roles.
Why Healthcare and Finance Require Specific Rules
Healthcare and financial applications process assets with direct real-world consequences. In healthcare, downtime can interrupt appointments, prescriptions, reports, or ICU workflows. In finance, a flaw may allow unauthorized transactions, changes to beneficiaries, fraud, or exposure of banking data.
Health data is classified by the LGPD as sensitive personal data. Financial information may also involve personal data, contractual confidentiality, and regulatory requirements. Depending on the context, testing must consider applicable standards and obligations, such as the LGPD, Central Bank rules, PCI DSS for card environments, and contracts with operators or partners. The legal team and data protection officer must validate which requirements actually apply.
This changes the offensive strategy. Instead of simply asking “is it exploitable?”, the operation must answer:
- Which asset can be reached?
- What would the clinical, financial, operational, and regulatory impact be?
- Was the attack detected and correlated?
- How long did the team take to contain the activity?
- Which controls prevent the same chain from working again?
How to Define the Scope Without Creating Operational Risk
Every test must begin with a rules of engagement document approved by the responsible parties. It must establish the systems included, testing hours, permitted techniques, data that may be accessed, emergency contacts, and stop conditions.
Minimum Checklist Before Execution
- Formal authorization from asset owners and involved third parties.
- List of authorized domains, APIs, IP addresses, accounts, environments, and integrations.
- Explicit definition of what is out of scope.
- Test accounts with representative roles and permissions.
- Synthetic or anonymized data whenever possible.
- Verified backups and a restoration procedure.
- Active monitoring of availability, errors, and queues.
- Emergency channel available throughout the operation.
- Stop criteria for degradation, patient risk, or financial movement.
- Policy for evidence collection, encryption, retention, and destruction.
Destructive testing, denial of service, modification of medical records, and movement of real money should normally be prohibited in production. When validation must occur in the live environment, the technique should be adapted to produce minimal, reversible, and previously agreed-upon evidence.
Offensive Testing in Healthcare Systems
The healthcare ecosystem frequently combines modern applications with legacy systems, medical devices, HL7 v2 integrations, FHIR APIs, files, databases, and external vendors. The attack surface does not end at the portal accessed by the user.
Authorization and Medical Record Isolation
Testing must verify whether a user can view or modify records belonging to another patient, facility, or organization. In APIs, this includes vulnerabilities such as BOLA, or broken object-level authorization, and BFLA, which is related to privileged functions.
The following must also be assessed:
- Separation between clinical, administrative, and technical roles.
- Restrictions based on facility, specialty, and care relationship.
- Inactive, shared, or overprivileged accounts.
- Bulk export of medical records and reports.
- Logging of queries, changes, and administrative actions.
- Open sessions on shared devices.
HL7 v2 and FHIR
HL7 v2 messages may travel through integrations that place excessive trust in the internal network. The protocol and MLLP transport do not, by themselves, guarantee authentication, authorization, and encryption; these controls must be implemented in the architecture, for example through segmentation, secure tunnels, gateways, and source validation.
In FHIR APIs, testing must assess authentication, scopes, consent, pagination, broad searches, and access to resources such as Patient, Observation, and DiagnosticReport. Implementations using OAuth 2.0, OpenID Connect, or SMART on FHIR must correctly validate tokens, audience, expiration, redirects, and granted permissions.
Testing must not insert false clinical results into active care workflows. Controlled changes must occur in a segregated environment or use clearly identified synthetic records.
Offensive Testing in Financial Applications
Financial systems require validation beyond traditional code vulnerabilities. Many serious flaws appear in business rules, concurrency, asynchronous integrations, and differences between what the interface displays and what the API accepts.
Flows That Deserve Priority
- Registration, account recovery, and device replacement.
- Multifactor authentication and privilege elevation.
- Addition and modification of beneficiaries.
- Creation, confirmation, cancellation, and reversal of transactions.
- Limits by user, device, time, and amount.
- Partner webhooks and callbacks.
- Reconciliation and queue processing.
- Administrative roles and manual operations.
The operation must verify object-level authorization, request replay, idempotency, race conditions, value manipulation, and token reuse. In architectures based on OAuth 2.0 and OpenID Connect, redirects, audience validation, key rotation, mTLS, and signatures must also be analyzed when adopted by the system.
Safe evidence can demonstrate that a validation was bypassed using a test account and a fictitious transaction. There is no need to transfer real money or access customer data to prove the risk.
How to Measure the Results of an Operation
Counting vulnerabilities is not enough. Ten informational findings may be less relevant than a single chain that enables the takeover of a privileged account.
Useful metrics include:
- Percentage of techniques detected by the SOC.
- Average time between execution, alert, and investigation.
- Time to contain the compromised account, session, or source.
- Number of viable paths to critical assets.
- Log coverage across applications, APIs, identity, and cloud.
- Percentage of findings remediated within the SLA.
- Recurrence rate after retesting.
Severity must consider likelihood, impact, and exposure. CVSS helps with technical standardization, but it does not replace context: a flaw with a moderate score may be critical if it alters a prescription, releases a report, or bypasses a financial limit.
The Report Must Guide Remediation
Each finding must present the affected asset, preconditions, evidence, impact, root cause, and a verifiable recommendation. Evidence containing personal data, tokens, or secrets must be minimized and protected.
Remediation must prioritize structural causes. If five endpoints have inconsistent authorization, fixing only the exploited routes leaves the risk in place. The ideal approach is to centralize access policies, add automated tests, and block regressions in the delivery pipeline.
An objective workflow can use four internal timelines: immediate containment for active critical risk, priority remediation for exploitable vulnerabilities, planned treatment for moderate risks, and formal acceptance for residual risks. The exact timelines must reflect the organization’s criticality and operational capacity.
Retesting closes the cycle: it confirms the fix, looks for alternative paths, and verifies whether new controls appear in the logs. Red Team Ops must feed the engineering backlog, threat modeling, detection rules, and incident response exercises.
How Predictor Solutions Addresses This
Predictor Solutions performs offensive security integrated with application, API, cloud, and DevOps engineering. In healthcare environments, this work is combined with experience in HL7 v2 and FHIR integrations; in financial systems, the work prioritizes identity, authorization, transactional rules, traceability, and external integrations.
The approach begins with scope and rules of engagement, progresses through manual and automated testing, and concludes with reproducible evidence, impact-based prioritization, and retesting. When the root cause lies in the architecture or code, the remediation can be incorporated into development, security testing, and the delivery pipeline.
The company is a software house based in Lavras, Minas Gerais, Brazil, and also works with applied artificial intelligence, data engineering, cloud, and custom systems. Across its overall portfolio, it serves 9 medium-sized and large companies, with documented 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; these figures represent the company’s projects as a whole and are not a standalone guarantee of security outcomes.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.