Offensive security tests in healthcare and financial systems must validate not only technical vulnerabilities, but also authorization, data segregation, fraud, resilience, and detection capabilities. Execution requires a formal scope, rules of engagement, operational limits, and reproducible evidence because a poorly controlled test can disrupt care, expose sensitive data, or move real funds.
Red team, pentest, and application assessment are not the same thing
A pentest looks for vulnerabilities within a defined scope, such as a web application, API, or mobile application. A red team operation, on the other hand, simulates an adversary’s objectives and assesses people, processes, applications, infrastructure, and incident response.
In critical environments, three approaches are commonly combined:
- Application pentest: identifies flaws such as injection, broken access control, data exposure, and insecure configurations.
- Business logic testing: looks for ways to abuse legitimate workflows, such as changing beneficiaries, accessing another patient’s medical records, or duplicating transactions.
- Red Team Ops: verifies whether an attacker can achieve an objective and whether the SOC, SIEM, EDR, WAF, and internal teams detect and contain the activity.
The choice depends on the question that needs to be answered. If the organization wants to know which vulnerabilities exist in an API, a pentest is appropriate. If it wants to determine whether an attacker could access medical records or manipulate a financial transaction without being detected, an objective-driven exercise is required.
Why healthcare and finance require additional controls
Clinical and financial data have a significant individual and operational impact. An exploit can compromise confidentiality, integrity, and availability at the same time.
In healthcare, the risks include:
- unauthorized access to medical records, test results, or prescriptions;
- modification of information used in clinical decisions;
- unavailability of healthcare systems;
- abuse of HL7 v2, FHIR, or connected device integrations;
- identification of patients from pseudonymized data.
In the financial sector, the following must be considered:
- modification of the beneficiary account or amount;
- transaction duplication and replay attacks;
- race conditions involving balances, limits, or redemptions;
- fraud through account recovery abuse;
- breakdown of isolation between customers or companies;
- manipulation of webhooks, reconciliations, and asynchronous routines.
The LGPD requires technical and administrative measures to protect personal data. However, documentary compliance does not replace offensive validation: a policy may state that access is segregated while the API allows users to query other users’ resources by changing an identifier.
How to define rules of engagement
The Rules of Engagement must be approved before any activity begins. At a minimum, the document must answer the following questions:
- Which domains, applications, APIs, IP addresses, and accounts are authorized?
- Will the test take place in production, staging, or a dedicated environment?
- Which techniques are prohibited, such as denial-of-service attacks or social engineering?
- Which data may be accessed, copied, or only viewed?
- What is the execution window, and who can stop the test?
- How will critical vulnerabilities be communicated in an emergency?
- How will evidence and temporary credentials be stored and destroyed?
There must also be a kill switch: a channel and procedure for immediate suspension. In healthcare, signs of degradation in patient care must end the test. In finance, any possibility of moving real funds, changing accounting records, or affecting customers requires interruption and joint validation.
Production or staging?
Testing in staging reduces operational risk, but it can produce an incomplete view. Test environments often use configurations, data, integrations, and controls that differ from production.
A balanced approach is to perform destructive tests in an isolated environment and use only previously approved, low-impact techniques in production. Synthetic accounts, reversible transactions, reduced limits, and real-time monitoring reduce risk without eliminating the validity of the exercise.
Controls that must be tested in critical applications
References such as the OWASP ASVS, OWASP Web Security Testing Guide, and OWASP API Security Top 10 help structure coverage. They do not replace business-specific threat modeling.
Identity, sessions, and authorization
Strong authentication does not fix weak authorization. Tests must verify:
- MFA bypass or fatigue;
- account recovery and device changes;
- token expiration and revocation;
- session fixation, reuse, and hijacking;
- horizontal and vertical privilege escalation;
- isolation between organizations, branches, physicians, patients, and accounts;
- excessive permissions in service accounts.
BOLA, or Broken Object Level Authorization, deserves particular attention in APIs. Changing a resource identifier must not provide access to a medical record, invoice, or transaction belonging to another user.
APIs, integrations, and asynchronous processing
APIs must be assessed beyond their published endpoints. It is important to look for legacy versions, exposed documentation, administrative routes, GraphQL with excessive queries, and internal services that are externally accessible.
Webhooks and queues require testing of signatures, timestamps, idempotency, ordering, and replay. A critical operation must not be executed twice because the same message was resent. The application must also reject tampered messages or messages outside the accepted time window.
Financial logic
In financial workflows, testing must cover:
- negative, extreme, or unexpectedly precise amounts;
- rounding and discrepancies between the frontend and backend;
- modification of the beneficiary after approval;
- reuse of receipts or requests;
- concurrency between withdrawals, purchases, redemptions, or transfers;
- approval by the same user who initiated the operation;
- discrepancies between displayed balance, available balance, and the general ledger.
Tests must not move real funds without explicit authorization. Whenever possible, a controlled account, minimum amounts, and a previously defined reversal mechanism should be used.
HL7 v2, FHIR, and healthcare applications
HL7 v2 is a messaging standard, not a complete security mechanism. MLLP-based integrations typically depend on network segmentation, protected tunnels, additional authentication, and monitoring to reduce risk.
In FHIR, OAuth scopes, SMART on FHIR, patient compartments, and search and export operations must be verified. Broad filters, poorly implemented pagination, or excessive scopes may allow enumeration and bulk extraction.
Other relevant scenarios include:
- modification of patient or encounter identifiers;
- incorrect association between test results and medical records;
- access by professionals outside the care relationship;
- continued access after termination or a change of role;
- data exposure in logs, URLs, notifications, and observability tools.
How to execute a controlled offensive operation
A verifiable process can be organized into seven stages:
- Threat modeling: identify assets, threat actors, trust boundaries, and impacts.
- Objective definition: establish concrete proofs, such as demonstrating unauthorized access without extracting real records.
- Preparation: create accounts, synthetic data, monitoring, and stop procedures.
- Authorized reconnaissance: map external and internal attack surfaces within the scope.
- Controlled exploitation: obtain the minimum evidence required while avoiding unnecessary persistence or lateral movement.
- Defensive validation: measure alerts, investigation, containment, and response time.
- Remediation and retesting: technically confirm that the fix eliminates the root cause, not only the payload used.
A proof of concept must collect the minimum amount of data. Instead of downloading thousands of medical records, for example, it may be sufficient to demonstrate that a synthetic account can access a synthetic resource belonging to another profile.
How to prioritize findings
CVSS helps describe technical severity, but it does not represent business risk on its own. Prioritization must consider at least five dimensions:
- ease of exploitation and prerequisites;
- public or internal exposure;
- scope across users, organizations, or records;
- clinical, financial, and regulatory impact;
- current ability to detect and contain the abuse.
A flaw with a moderate technical score may be a priority if it allows someone to modify a prescription or divert a financial approval. Likewise, a critical vulnerability in an isolated component may present a lower risk when verifiable compensating controls are in place.
Each finding must include the affected asset, preconditions, reproduction steps, minimum evidence, impact, root cause, recommendation, and retesting criteria. Screenshots without context and automatically generated lists are not sufficient to guide remediation.
Checklist for hiring or approving an offensive security test
Before execution, confirm:
- [ ] formal authorization and technical scope;
- [ ] inventory of APIs, integrations, and access profiles;
- [ ] synthetic data and controlled accounts;
- [ ] emergency contacts and a kill switch;
- [ ] explicit exclusion of unauthorized destructive techniques;
- [ ] evidence protection and destruction deadline;
- [ ] plan for critical vulnerabilities;
- [ ] participation from application, infrastructure, and security teams;
- [ ] retesting included in the acceptance criteria;
- [ ] executive report and reproducible technical report.
The primary trade-off is between realism and operational safety. The closer the exercise is to production, the more representative the results will be—and the greater the required control over impact, data, and the ability to interrupt the test.
How Predictor Solutions solves this
Predictor Solutions, a software house based in Lavras, Minas Gerais, works with offensive security, custom development, artificial intelligence, data engineering, cloud, and DevOps. In healthcare, it works with HL7 v2 and FHIR systems and integrations, in addition to the Predictor Health and Predictor AI Hospitals products; this experience makes it possible to assess both conventional vulnerabilities and flaws specific to clinical workflows and interoperability.
The approach combines threat modeling, architecture review, application and API testing, business logic validation, and retesting. Exercises are bounded by rules of engagement, minimum evidence, and stop criteria, preventing the test itself from creating an incident.
Across its technology projects, Predictor Solutions has served 9 medium-sized and large companies, with reported results of R$ 1.32 million in average savings per client per year, an average productivity increase of 70%, and 43% profit growth in six months. These figures represent overall project results and do not replace specific security metrics, which must be defined for each operation.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.