Red Team Ops: How to Safely Test Healthcare and Financial Systems

Red Team Ops in healthcare and financial systems should simulate real attacks under formal authorization, with clearly defined scope, operational limits, and interruption procedures. The goal is not merely to find vulnerabilities, but to verify whether preventive controls, monitoring, and response teams can prevent, detect, and contain an attack without exposing patients, transactions, or personal data.

What Differentiates Red Team Ops from a Conventional Pentest

A penetration test typically looks for vulnerabilities within a defined technical scope, such as a web application, API, or network. A red team operation, on the other hand, evaluates complete attack paths and business objectives: gaining unauthorized access to medical records, changing a prescription, reaching financial data, compromising a privileged account, or simulating transactional fraud.

The practical difference lies in the focus:

• Pentest: identifies and demonstrates technical vulnerabilities.
• Red team: tests people, processes, technology, detection, and response.
• Purple team: promotes collaboration between attackers and defenders to validate and improve controls.
• Vulnerability assessment: identifies potential flaws, generally with more automation and less manual exploitation.

Not every system needs to start with a full operation. If the organization does not yet have an asset inventory, vulnerability management, centralized logs, or an incident response plan, a risk-oriented pentest may deliver more initial value.

Why Healthcare and Finance Require Special Rules

In both sectors, confidentiality is only one part of the risk. Integrity and availability may be even more critical.

In healthcare, an unauthorized change to allergies, medications, laboratory results, or clinical parameters may affect care decisions. A poorly controlled offensive payload may also disrupt integrations, dashboards, equipment, or hospital workflows.

In financial systems, manipulating beneficiaries, limits, balances, reconciliations, or antifraud rules may cause losses and accounting inconsistencies. Concurrency testing or repeated requests may also create duplicate transactions if idempotency is not implemented.

The operation should consider at least four impacts:

1. Confidentiality: exposure of personal data, medical records, credentials, or financial information.
2. Integrity: alteration of clinical records, balances, transactions, or audit trails.
3. Availability: degradation of APIs, queues, databases, and critical services.
4. Traceability: inability to determine who performed an action and when it occurred.

The LGPD remains applicable during authorized testing. Authorization to test a system does not eliminate principles such as necessity, security, prevention, and accountability in the processing of personal data.

How to Plan a Safe Offensive Operation

1. Define Verifiable Objectives

Vague objectives, such as “break into the system,” produce results that are difficult to measure. Prefer concrete questions:

• Can a standard account access another patient’s or customer’s data?
• Can an attacker who obtains a credential reach the production environment?
• Is it possible to alter a transaction without triggering an alert?
• Does the SOC detect abnormal record extraction?
• Do secrets found in a pipeline enable lateral movement?
• Can teams contain the attack within the internally established time frame?

Each objective should have a success condition, permitted evidence, and maximum acceptable impact.

2. Formalize the Rules of Engagement

The Rules of Engagement must be approved by the technical, legal, and business stakeholders. The document should include:

• authorized assets, domains, IPs, applications, and APIs;
• permitted environments and time windows;
• techniques that are prohibited or subject to approval;
• limits for social engineering, persistence, and exfiltration;
• emergency contacts and a stop word;
• policy for data found during the test;
• test origin and addresses that should not be blocked without review;
• evidence cleanup and destruction procedures;
• criteria for immediately suspending the operation.

Denial-of-service attacks, alteration of real data, ransomware, indiscriminate phishing campaigns, and exploitation of third parties should remain out of scope unless there is specific authorization and a controlled environment.

3. Reduce Risk to Production

Staging environments do not always reproduce production controls, identities, and integrations. On the other hand, testing directly in production without safeguards may cause real incidents.

A balanced approach combines:

• synthetic data and accounts marked for testing;
• zero-value transactions or an explicitly reversible flow;
• isolated copies of critical services;
• validated backups before the testing window;
• request and concurrency limits;
• monitoring of latency, errors, queues, and databases;
• gradual execution, starting with lower-impact techniques.

Proof of access should use the minimum necessary. Instead of copying thousands of records, the team may record the identifier of a synthetic account or calculate a hash of previously agreed-upon evidence.

Critical Vectors in Healthcare Applications

Healthcare systems often combine web applications, devices, legacy integrations, and standards such as HL7 v2 and FHIR. This heterogeneity expands the attack surface.

FHIR APIs and Contextual Authorization

FHIR APIs should be evaluated beyond authentication. A valid token does not mean that the user may read any Patient, Observation, Encounter, or MedicationRequest resource.

Tests should verify:

• access control by patient, organization, and professional role;
• resource enumeration through predictable identifiers;
• excessively broad searches;
• exposure through _include and _revinclude parameters;
• misconfigured OAuth scopes;
• lack of limits, auditing, or token expiration;
• unauthorized access through references between resources.

The OWASP API Security Top 10 recommendations help structure tests against broken object-level and function-level authorization, unrestricted resource consumption, and improper API inventory management.

HL7 v2 Integrations

In HL7 v2 integrations, the risk is not limited to reading messages. Network segmentation, authentication between systems, sender validation, and the possibility of injecting or replaying messages must be assessed.

Manipulated messages may affect admissions, discharges, transfers, orders, or results. Therefore, active testing should preferably take place through an isolated channel, with synthetic identifiers and joint validation by the clinical and integration teams.

Critical Vectors in Financial Systems

Financial applications depend on consistent authorization, transactional integrity, and antifraud controls. Business logic flaws are often more relevant than vulnerabilities detectable by scanners.

An operation should evaluate:

• swapping identifiers to access third-party accounts or transactions;
• changing the amount, currency, beneficiary, or account after approval;
• reusing tokens, links, or confirmation codes;
• race conditions in withdrawals, redemptions, limits, or coupons;
• lack of idempotency in financial operations;
• account recovery susceptible to social engineering;
• excessive privileges for internal operators;
• secrets exposed in code, logs, CI/CD, or cloud infrastructure;
• discrepancies between events, the general ledger, and reconciliation.

When cardholder data is processed, PCI DSS may add segmentation, testing, and data environment protection requirements. Other obligations depend on the business model and applicable regulations; therefore, technical requirements should be validated with the legal and compliance departments.

Methodology and Expected Evidence

Execution may combine OWASP ASVS and WSTG for applications, OWASP API Security Top 10 for APIs, MITRE ATT&CK for mapping adversary techniques, and NIST SP 800-115 for organizing tests. These frameworks do not replace business analysis, but they reduce methodological gaps.

A practical workflow includes:

1. authorized mapping of the attack surface;
2. threat modeling and objective selection;
3. manual validation of vulnerabilities;
4. controlled exploitation;
5. simulation of lateral movement and actions on objectives;
6. assessment of alerts and defensive response;
7. removal of access, files, and persistence mechanisms;
8. technical and executive reporting, followed by retesting.

Each finding should present the affected asset, preconditions, reproducible steps, sanitized evidence, technical and business impact, likelihood, recommendation, and retesting criteria. An isolated CVSS score does not adequately represent clinical or financial risks; the asset context should adjust the priority.

Checklist for Hiring or Approving the Test

Before starting, confirm:

• [ ] Is there formal authorization from the asset owners?
• [ ] Are production, staging, and vendors clearly separated within the scope?
• [ ] Are synthetic accounts and data available?
• [ ] Are prohibited techniques and impact limits documented?
• [ ] Do the SOC, infrastructure team, and on-call personnel have an emergency channel?
• [ ] Do logs have synchronized timestamps and sufficient retention?
• [ ] Have backups and restoration procedures been verified?
• [ ] Does the vendor explain how evidence is encrypted and deleted?
• [ ] Will the report connect technical flaws to business risks?
• [ ] Is retesting planned after remediation?

How Predictor Solutions Solves This

Predictor Solutions conducts offensive security engagements with a controlled scope and integration across applications, APIs, cloud, data engineering, and DevOps. In healthcare, its experience includes systems with HL7 v2, FHIR, dashboards, and wearable data; in the Predictor Health and Predictor AI Hospitals products, the architecture must simultaneously account for privacy, clinical integrity, and availability.

The work begins with threat modeling and Rules of Engagement, proceeds to manual validation of authentication, authorization, business logic, APIs, and infrastructure, and concludes with reproducible evidence, impact-based prioritization, and retesting. When necessary, the team also supports remediation in code, pipelines, observability, and architecture, preventing the assessment from becoming disconnected from remediation.

The company, based in Lavras, Minas Gerais, serves software and artificial intelligence projects in Brazil. Its overall results include 9 medium and large companies served, average savings of R$ 1.32 million per client per year, an average productivity increase of 70%, and 43% profit growth in six months; these indicators cover its overall operations and should not be interpreted as metrics exclusive to red team engagements.

Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.