Comment by Spare_account
3 years ago
This approach was part of their strategy:
>Then we started showing some results we knew to the bots - if they entered wrong numbers, we would stop accepting the results.
3 years ago
This approach was part of their strategy:
>Then we started showing some results we knew to the bots - if they entered wrong numbers, we would stop accepting the results.
It seems to me that when combating bots or hackers, the wrong approach is to provide immediate negative feedback. Giving an immediate error code lets them know that their current strategy is not working and to try something different.
It seems like a better approach would be to make them think you were accepting the results, when in fact they were going to the bit bucket. Hackers trying to get into your corporate database should be presented with a table full of false (but plausible) data rather than an error. Let them waste time trying to use all those fake SS numbers or account numbers before they figure out they got duped.
As scary as it can be, but yes. It's similar to strategy games at a point - sometimes it's better to let the enemy push you around for a bit as long as nothing important is damaged. I don't really care if I have to scale up the LBs a bit to handle all of the requests for some time. However, this allows your attacker to commit more of their resources, so you can block and ban more once you react or so you can learn more about their behavior, so you can mislead, slow-lorry and generally mess with them more effectively.
There have also been funny defcon-talks about messing with attackers about this, by returning all kinds of messed up return codes, slow-lorry'ing the bot, ... I'm kind of wondering if you could SSRF (or rather, CSRF) a bot like this by returning a redirect to e.g. the AWS metadata API... could be a fun topic to mess with.
For sure, shadow-banning is a great strat here. Raise their costs, and don’t give them any signal to learn from.
Assuming you have the bandwidth to absorb the bot load, which sounded like it was an issue here.
It's also evidence of a crime. I wonder how that relates: if you just drop those entries from the database (or from the app prior to entry into the main db) then that seems like destruction of evidence of a crime?
It seems one should record all entries, but only update a canonical db if all entries fail to trip automated tampering detections.