
99% of DDoS-DFIR (primary the forensic part) consist of botnet-analysis and dealing with the „usual suspects“ like booter-services and smaller botnets.
But every once in a while we come across an interesting attack like this with attackers who either play tricks with the Os-people or are able to attack efficiently.
as in this case, which we want to report on here, where the attacker:
- shut down the VPN-gateways to deny access for tech and ops
- shut down the inter-datacenter routers/transfer-routers
- shut down the authoritative dns-infra that affected all clients
all within minutes.
The attacker used his OSINT-FOO to get the information needed for steps 1 and 2, and was able to achieve his goal through a small but fatal misconfiguration. But more on that later.
Disclaimer: All screenshots were taken with the help of our DDoS analysis platform, with which we are able to analyse log files (firewall, sflow, web/access logs) and evaluate them from a DDoS point of view. For an overall view and assessment of the attacker, it is always important to know: what happened when, how and why, and in what order, especially when you need to know if an attack happened by a scriptkiddie or an advanced attacker.
dissecting a DDoS-attack, identifying targets and attacktimes
Prelude 1st Wave: Attack on the VPN dialins and corerouters
In the first wave, neuralgic points were attacked:
- the VPN gateway for the service staff
- 2 corerouters, which were responsible for the data transfer between the individual locations/datacentres of the company.
With this attack, the service staff was quickly incapacitated, as 70% of the technicians work from home and were dependent on the VPN endpoint.
In addition, „shooting down“ the corerouters prevented any intra-DC data traffic, so rerouting and using fallbacks from the backup DC and many other things did not work.
How did the attacker get this information? Insider? crystal ball?
The first impulse would be „insider knowledge“.
Well, as we have seen in the State of DDoS-Summary 2021, there are more and more attackers with a professional approach, such as recon and enumeration via OSINT and clever target selection.
Because in this case, attacked systems and approach can be easily clarified by the following assumption:
- it was a targeted attack
- the actual target is to remain disguised
- maximum impact needed
Since there was no blackmail letter or ransomnote, but the attack otherwise did not give the impression of a sledgehammer method, we assumed a targeted attack by an experienced attacker. And experienced attackers know Recon and target selection.
So we performed a mini-recon ourselves, checked all the IPs available online via shodan and then had reverseDNS for all IPs and parsed for „[fw|gw|vpn]“, et voila!
rDNS reveals target-selection
In total, we found more than a handful of firewalls and VPN gateways, but these could be assigned to customers rather than directly to the data centre, and a total of 4 from the datacentre itself.
This clarifies the first point, how the attacker could potentially obtain the information regarding the VPN endpoint for technicians.
The second point, how the corerouters used for the inter-DC traffic could be identified, is similarly easy to answer; we will use a traceroute from Hetzner as an example.
Here you can see the EdgeRouter „versatel-gw.hetzner.com“, then the intra-DC corerouters between Frankfurt (fra) and Nuremberg (nbg), which shouldnt normally be reached or pinged.
But in the case of the attack we analysed, it did. And so the attacker was able to limit the ability to act for the technical staff and the intra-DC communication in a very short time, headshot!
2nd Wave: Attack on the Authoritative DNS Infrastructure
The second wave hit the DNS infrastructure, and since the datacentre utilizes CNAMES heavily and is the Auth-DNS for more than 30,000 domains, this part of the attack affected all customers.
Successful DDoS attacks on DNS infrastructure always have devastating effects.
Nothing more to say here, except that, due to the 1st wave, technicians couldnt mitigate the attack as fast as execpted.
That Little Misconfig-Detail
This post does not end here. Continued here.
Fachartikel

Wenn Angreifer selbst zum Ziel werden: Wie Forscher eine Infostealer-Infrastruktur kompromittierten

Mehr Gesetze, mehr Druck: Was bei NIS2, CRA, DORA & Co. am Ende zählt

WinDbg-UI blockiert beim Kopieren: Ursachenforschung führt zu Zwischenablage-Deadlock in virtuellen Umgebungen

RISE with SAP: Wie Sicherheitsmaßnahmen den Return on Investment sichern

Jailbreaking: Die unterschätzte Sicherheitslücke moderner KI-Systeme
Studien

Deutsche Unicorn-Gründer bevorzugen zunehmend den Standort Deutschland

IT-Modernisierung entscheidet über KI-Erfolg und Cybersicherheit

Neue ISACA-Studie: Datenschutzbudgets werden trotz steigender Risiken voraussichtlich schrumpfen

Cybersecurity-Jahresrückblick: Wie KI-Agenten und OAuth-Lücken die Bedrohungslandschaft 2025 veränderten
![Featured image for “Phishing-Studie deckt auf: [EXTERN]-Markierung schützt Klinikpersonal kaum”](https://www.all-about-security.de/wp-content/uploads/2025/12/phishing-4.jpg)
Phishing-Studie deckt auf: [EXTERN]-Markierung schützt Klinikpersonal kaum
Whitepaper

ETSI veröffentlicht weltweit führenden Standard für die Sicherung von KI

Allianz Risk Barometer 2026: Cyberrisiken führen das Ranking an, KI rückt auf Platz zwei vor

Cybersecurity-Jahresrückblick: Wie KI-Agenten und OAuth-Lücken die Bedrohungslandschaft 2025 veränderten

NIS2-Richtlinie im Gesundheitswesen: Praxisleitfaden für die Geschäftsführung

Datenschutzkonformer KI-Einsatz in Bundesbehörden: Neue Handreichung gibt Orientierung
Hamsterrad-Rebell

Cyberversicherung ohne Datenbasis? Warum CIOs und CISOs jetzt auf quantifizierbare Risikomodelle setzen müssen

Identity Security Posture Management (ISPM): Rettung oder Hype?

Platform Security: Warum ERP-Systeme besondere Sicherheitsmaßnahmen erfordern

Daten in eigener Hand: Europas Souveränität im Fokus










