CERT-In: payout API attacks from trusted company infrastructure

On October 9, CERT-In/CSIRT-Fin described campaigns causing unauthorised payouts through APIs. Its warning covers fintechs, lending platforms and payment providers, among others. Attackers stole integration credentials and invoked operations from infrastructure on the organisations’ allowlists.

Breachroad’s conclusion is to check who confirms the business justification for each payout when reviewing a payment integration. An allowed connection source and valid credentials are security measures, but do not replace approval of the operation. Below, we propose a way to discuss this risk with finance, IT and the product owner.

Map the payout decision

OWASP Transaction Authorization recommends server-side enforcement, control of step ordering and a final check before transaction execution. For an integration team, this means identifying where the binding decision to release a payment is made.

Our proposal is to draw the path from instruction to execution at a working session. For every step, record the responsible system, owner and approach to resolving errors. Include paths handled by employees, partners and automated processes. The outcome should be a shared understanding that makes sense to both the developer and the person reconciling the operation.

Add an example of a successfully completed case and one held for investigation to the documentation. Establish who can change a status and where the reason is recorded. This keeps the review grounded in the actual workflow, rather than endpoint names and assurances that the integration is protected. Colleagues should be able to follow the decision without relying on the original designer’s memory.

Exercise: money moved, but nobody can trace the case

Imagine a fictional platform processing customer payouts. An operator receives a report of a completed payment, but finance cannot identify the person responsible for approving it. IT sees a call from the expected server. Each team holds part of the information, while nobody has the complete history.

This is Breachroad’s discussion scenario, rather than a reconstruction of a reported incident. Ask participants to identify the initial coordinator, the route for contacting the partner and the information needed to make a decision. Also establish who communicates with the customer, when the manager becomes involved and how handovers between teams are recorded.

The exercise can use synthetic data and descriptions of screens. It requires neither real transfers nor production keys. Check whether the procedure works during on-call coverage and staff absence, when the person who designed the integration is unavailable. Participants should leave with a specific escalation route and a clear understanding of their responsibilities.

Assess the entire business process

OWASP API6:2023 describes unrestricted access to sensitive business flows. It connects business identification of risk with engineering selection of protections. Breachroad proposes using this division when assigning responsibility for an integration and its exceptions.

In our review process, every unresolved question receives an owner, deadline and description of the evidence needed to close it. For example, the reconciliation owner confirms access to the required history, while the service owner checks that on-call staff have current partner contacts. Sending a question to another department does not complete the task. The responsible person should confirm the answer and its operational consequence.

CERT-In also mentions possible use of AI-assisted offensive tools. Treat this as the source’s assessment, rather than proof of an autonomous attack or use of a particular model. A justified suspicion of an unauthorised operation is sufficient to initiate the response procedure; identifying the attacker’s tools can follow later.

Prepare people to respond together

For today, we recommend choosing one important integration and discussing this scenario with its owners. Check whether the agreed procedure can be handed to a new colleague and whether it identifies decisions needed outside office hours. Record discrepancies rather than finish with a general assurance of security. Turn the findings into assigned follow-up work.

Our API security guide can help organise the technical discussion. Through cybersecurity training for organisations, finance, IT and management teams can practise assessing an unusual operation, assigning responsibilities and reporting events.