Protected in the Middle of an Attack.

Forged payment notifications

When a customer pays, the payment provider tells the store with a callback, and the store completes the order. Someone was sending oynal.net forged callbacks: requests made to look like the payment provider confirming orders. One of the goals was to shop with stolen credit cards.

The store's own checks refused every one, so no order was faked. But each request still reached its server, and they came from more than 11,000 residential addresses that looked like ordinary browsers.

Now and then the attacker also tried to flood the store, with up to 1,076 requests a second. Each time Shieldify switched on mitigation by itself and stopped almost every request at the edge.

15 October, in UTC

1. 10:07 oynal.net goes live on Shieldify.
2. 10:25 A first flood, up to 875 requests a second. Shieldify switches on mitigation by itself.
3. 11:32 Strict Mode: the requests claimed to be Chrome on Windows and macOS, but Shieldify saw through them. They got a CAPTCHA, and the forged notifications reaching the server fell from about 60 a minute to none within a minute.
4. 17:58 The attacker switches to automated browsers on rented servers, which pass a normal browser check.
5. 19:03 One of oynal.net's own custom rules blocks the first server. The attack moves to another.
6. 19:09 Refused Requests goes live: Shieldify stops a client whose requests the website keeps refusing. Seconds later the new server is stopped at the edge, then banned.
7. 19:40 A last flood, up to 1,076 requests a second. Mitigation switches on by itself and stops almost every request at the edge.
8. 19:58 The attack stops.
9. 20:05 Automated browsers now get a CAPTCHA before they open pages or send forms.

Built during this attack, now on everywhere

Refused Requests and the CAPTCHA for automated browsers were built during this attack. They are now on for every website protected by Shieldify, with a switch for each under DDoS settings. See the changelog for the details.