I've got a manually-unmanageable number accounts created by bot activity I'd like to inactivate (not purge) while we test out improved captcha. Can anyone point me to the code invoked by the constituent menu or possibly already have code written for this. I'm thinking there's probably more to it than updating inactive and inactive_reason in T_CUSTOMER.
Thanks!
I thought it might be useful to pass along an issue we recently dealt with. It's not exactly the same as this, but our experience may prompt others to take a deeper look at that's happening in their environments. The connection with this thread is that what happened to us did include the creation of some bogus accounts, although we have no reason to believe that the accounts were created by a bot since there were only three (3).
What concerned us was when we discovered thousands of attempted credit card transactions associated with these accounts. We stumbled on this occurrence while reviewing transaction logs on our payment gateway processor which we don't routinely do. We typically use the logs to help troubleshoot problems. We don't routinely review them. We recently switched payment processors and were reviewing all transactions in the logs after the switch to be sure transactions were flowing correctly. During that review we discovered a one hour period where there were thousands of failed transactions. These transactions also showed up in Tessitura and we were ultimately able to trace them back to bot activity on our web site where the bot was cycling through card number / expiration date / CVV combinations.
The point of mentioning this, is that bogus accounts were used for these transactions and had those accounts been either inactive or purged the bot activity would not have been possible (without creating additional bogus accounts). We're TNEW clients and the captcha functionality available readily handles stopping bot activity that creates accounts. However, it doesn't address bot activity that attempts to process a transaction - most likely to only test the validity of a card number / expiration date combination.
At the end of the day we discovered weaknesses with our AVS and CVV settings that we've tightened which has stopped the bot activity. But, it was distressing to discover that our systems had been used inappropriately to test card number combinations for further exploitation. Standard reconciliation practices didn't catch this activity because most of the authorizations failed and were automatically reversed. Those that were successful (3 transactions out of thousands) passed standard reconciliation audits since they were successful and the small transaction amounts were never disputed.
To help determine the scope of this activity we developed a fairly simple frequency analysis query that flags situations where we have more transactions in a period of time on a single account than would by considered normal. We are now looking at using this as a regularly run audit tool to expose these situations before they grow legs and result in any kind of significant loss.
Lesson? Use the available tools to rid your systems of bogus accounts. But also consider looking for bogus transactions that pass reconciliation audit.
Dan, We aren't TNEW and these got past our captcha a handful a day for months. No transactions found associated with any of these. The only non-bot appearing thing about any of them is legit eaddresses. We wondered about maybe eaddress laundering operation.