Buying a cheap DDoS booter service does not require any technical knowledge or brilliance. It’s rather a trivial task to make smaller services on the internet unavailable, but the person performs it with pride and a sense of superiority. The reason for this, however, lies only in the lack of understanding of the area.
It is common knowledge that one should never disclose their identity, as doing so could result in legal consequences. Operations security (OPSEC) is the “process by which potential adversaries can be denied information about capabilities and intentions by identifying, controlling, and protecting generally unclassified evidence of the planning and execution of sensitive activities.”1
After analyzing a recent DDoS attack, I found a quite interesting but textbook bad example for OPSEC.
The attack
DDoS attacks are not rare and happen a few times every week on popular gameservers. But this particular attack caught my eyes as it reached 9.000 mbps.
The attack was however not noticeable for the players due to a defense mechanism I described in a previous post. My implementation was written in Python. More details are avaliable here.
At the beginning of each attack a tcpdump will be performed for 2 seconds for later analysis.
The capture contains ~2,000,000 packets. All of the top-talkers reverse DNS point to *.amazonaws.com:
Unlike another amplified attack I’ve discussed, this one was directly initiated by VPS.
Looking at the packets we see that all have the exact same 512 byte UDP data length:
Even wore, that the “special and high-performance hardware stack, including a VAC DDoS mitigation node […] via deep analysis and mitigation by VAC, in the case of suspicious traffic”2 did not catch this blatantly obvious attack. And yes: We did already contacted OVH and handed them a capture of normal traffic for finetuning.
OPSEC mistakes
The attack itself does not directly point to a natural person. One could collect all data and report the case to Amazon, who is the hoster of all attacker systems. Sadly it is not worth the effort as abuse reports might at best suspend the attackers account but is far distant from legal consequences.
But how does the attacker even know, that the attack was successful or not? He has to use the service itself or use tests.
After filtering out all UDP packets we are left with some HTTP (TCP) traffic. Within those 2 seconds, an ICMP (“ping”) catched my attention. During an attack one might run a continuous ping in the background and observe the impact in the response time of the server:
The reverse DNS for this IP is 185.254.75.38.dus.mullvad.net. Mullvad is VPN service. IMHO not a bad one.
This seems like a dead end. But after searching for this IP address in the logs of the gameserver we find the following:
████@████:/var/lib/pterodactyl/volumes/████/garrysmod/logs# grep -nw "185.254.75.38" *
2025-02-21.log:44005:2025-02-21T14:09:04.965198641Z Client "████" connected (185.254.75.38:27005).
2025-04-18.log:25563:2025-04-18T11:16:02.749994933Z Client "████" connected (185.254.75.38:27005).
2025-04-18.log:25569:2025-04-18T11:16:09.700207380Z Client "████" connected (185.254.75.38:27005).
2025-04-18.log:26124:2025-04-18T11:17:09.200038204Z Client "████" connected (185.254.75.38:27005).It is quite common for an attacker to connect to the server itself that he is attacking to directly observe the impact on performance.
One might ask: “Is it reasonable to conclude, that this individual is the one behind the attack because he sent a ping request during an DDoS attack?”
The answer: A clear “it depends”.
The player, in this case, did connect right before and disconnected right after the attack occured. It is, in my experience, unlikely, but not ruled out, that this happened by chance.
An this is where the first mistake happened. Garry’sMod is a multiplayer game on Steam. Each player therefore has an unique SteamID. Searching the in logs from 2024 for his SteamID, we can see, that this very player connected to the server without using a VPN:
████@████:/var/lib/pterodactyl/volumes/████/garrysmod/logs# grep -n '"████" connected' *
2024-12-21.log:<SNIP> Client "████" connected (83.█.█.█:18087).
2024-12-21.log:<SNIP> Client "████" connected (83.█.█.█:18087).
2024-12-28.log:<SNIP> Client "████" connected (83.█.█.█:14612).
2024-12-28.log:<SNIP> Client "████" connected (83.█.█.█:14612).
2024-12-28.log:<SNIP> Client "████" connected (83.█.█.█:14576).
2024-12-28.log:<SNIP> Client "████" connected (83.█.█.█:14576).
2024-12-28.log:<SNIP> Client "████" connected (83.█.█.█:14539).
2024-12-29.log:<SNIP> Client "████" connected (83.█.█.█:14539).
2025-04-18.log:<SNIP> Client "████" connected (185.254.75.38:27005).
2025-04-18.log:<SNIP> Client "████" connected (185.254.75.38:27005).
2025-04-18.log:<SNIP> Client "████" connected (185.254.75.38:27005).
2025-04-18.log:<SNIP> Client "████" connected (185.254.75.38:27005).The second, and even worse, mistake leads us to the donation system of the server. As the system administrator we can easily search the database and do indeed find, that this person donated 10 € via Paypal. The payment information includes E-Mail and full name:
Great, now let us check, if he has registered an account in the forum of the server:
Great, now we know his first and last name, E-Mail, date of birth, sex and that he is a talented Lua developer. As the first name did not match the name on the invoice, we can assume, that he used the PayPal account of his parents.
- “SC-38. OPERATIONS SECURITY”. Security and Privacy Controls for Information Systems and Organizations (Information security standard). Joint Task Force. p. 323. doi:10.6028/NIST.SP.800-53r5 ↩︎
- https://us.ovhcloud.com/security/anti-ddos/ddos-attack-mitigation/ ↩︎