- The target: not a website, but the core of a payment infrastructure
- Phase one: a replay attack using stolen transaction data
- Phase two: a Layer 7 flood with one session per IP
- Origin: Indonesia, China, Russia — and Western infrastructure as a waypoint
- How mitigation took effect — and where its limits were
- What this case reveals about modern attack methodology
- Three takeaways for IT decision-makers
Shortly after half past eleven at night, the dashboards of the Security Operations Center showed everything was green. Initially, there were only a few requests per minute, which was in line with what one would expect for a .de domain at that hour. However, within five minutes, the numbers exploded, reaching over 900,000 requests against a single API. This sudden-looking attack was not sudden at all. The attack had already begun earlier; it had simply taken its time.
The target: not a website, but the core of a payment infrastructure
When people think of DDoS attacks, they usually picture overloaded websites and inaccessible homepages. However, this attack targeted the API of a European financial service provider that uses this interface to authenticate card terminal transactions in real time. Every payment made at a checkout terminal goes through this exact interface: the terminal sends a request, the server verifies it, and then either approves or declines the transaction.
APIs of this kind are considerably more sensitive than traditional web applications. An outage doesn’t just mean an unreachable page; it means failed payments. This suggests that the choice of target was no coincidence.
Learn more about an easy-to-implement and highly effective WAAP solution.
Everything from a single source, and available as a fully managed service upon request.
Phase one: a replay attack using stolen transaction data
This case is special because of how it began. The attackers did not start with brute force. In a replay attack, an attacker intercepts legitimate data transmissions — such as authentication requests from a real credit card transaction — and resends them to the target system. The system recognizes these requests as valid and processes them because they are structurally identical to genuine transactions.
Therefore, the attackers had previously intercepted real requests and used them as templates to mass-produce requests that appeared legitimate. To protection systems, these requests looked like genuine traffic because they were technically genuine.
Signature-based detection systems, which check for known attack patterns, did not trigger because the requests carried no known attack signatures. They contained what appeared to be genuine transaction data.
Phase two: a Layer 7 flood with one session per IP
Following the initial replay phase, which tested the defenses, the attack escalated, with over 900,000 requests directed at a single endpoint. The traffic pattern was designed to appear organic, with one session per IP address distributed across a global network of autonomous systems.
Shortly before the peak, there were more than 12,000 unique sessions and IP addresses from simultaneous sources. Bandwidth reached a peak in the single-digit gigabit range. No single source stood out immediately, but together, they generated a load that led to error messages. The server could no longer process the volume of requests.
Origin: Indonesia, China, Russia — and Western infrastructure as a waypoint
Most of the traffic came from Indonesia, China, and Russia, followed by the United States, Brazil, Colombia, and several European countries. However, there is barely any regular customer base in Indonesia for a .de domain belonging to a European financial service provider. In the middle of the night, an attack from widely scattered sources hit an API endpoint for card authentication.
The ASN profile of the attacking networks is also notable: it includes large hosting providers, transit networks, and smaller autonomous systems — a classic sign of a distributed botnet using legitimate infrastructure as a “waypoint.”
How mitigation took effect — and where its limits were
Detection relied on behavioral controls rather than signatures. As soon as the thresholds were exceeded, the mitigation process began. The decisive factor was the additional rules set up specifically for credit card transaction paths, which limited the number of unique identifiers per source IP address. This increased the granularity of the detection precisely where the attack was strongest.
What this case reveals about modern attack methodology
This attack is a textbook example of a trend that has accelerated in recent years. The classic image of a DDoS attack—massive flood traffic clogging up connections—falls short. Attackers who possess stolen transaction data operate on a different level because they can use it as a basis of legitimacy for their requests.
They know the targeted service. They know what valid requests look like. They are also patient enough to use phase one, the replay attack, as reconnaissance before increasing the load in phase two.
Three takeaways for IT decision-makers
API protection requires its own baseline profiles. Generic rate limits do not adequately protect transaction-critical APIs. Without knowledge of what normal traffic looks like for a specific endpoint—including time of day, session depth, and regions—anomalies cannot be reliably detected. Per-endpoint baseline monitoring is a prerequisite, not an option.
Signature-based detection alone is insufficient. This attack did not trigger any known signatures because it carried none. Behavioral detection, which analyzes behavioral patterns instead of payload signatures, was the only effective mechanism. Those who rely exclusively on WAF signatures have no effective defense against replay attacks using valid payloads.
Incident response requires collaboration with the customer. In this case, quickly involving the customer was critical. Those who wait until an attack is underway to sort out communication channels, escalation paths, and shared monitoring dashboards lose valuable time.
Sometimes, traffic can be deceptive. The goal is to recognize when that is the case sooner and set up the right tools so that this question can be asked in the first place.
Would you like to review your systems and set up your tools accordingly? Feel free to reach out to us at any time to speak with one of our experts.
You might also like:
