>Then we started showing some results we knew to the bots - if they entered wrong numbers, we would stop accepting the results.
>Then we started showing some results we knew to the bots - if they entered wrong numbers, we would stop accepting the results.
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.
Assuming you have the bandwidth to absorb the bot load, which sounded like it was an issue here.
It seems one should record all entries, but only update a canonical db if all entries fail to trip automated tampering detections.
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.