Fake Accounts

We had something similar happen a few years ago. We had a form on our website that a bot took advantage of, so we added a CAPTCHA to the form to prevent further misuse. I don't recall the steps we took to purge the accounts that were created.

Dan

To be clear, you have 18k customer accounts, right?  Not user accounts?  If the former then, yes, this is almost certainly a bot, not a breach.  Adding reCAPTCHA to your account creation process will probably prevent it from happening again.  You will want to review any transactions undertaken by these bot accounts.  After that I'm sure support can help you clean up the bot accounts.

If you have unwanted user accounts, that does suggest a breach, and you will need to undertake more serious action immediately.

You could create a list of accounts that have that email address and then inactivate or purge based on the list.  (Assuming the account as a whole isn't needed.)

For cleanup of user accounts, if they all have the same email address you might be able to merge them all into a single account before inactivating.

Hi Jason,

We had a similar thing happen to one of our consortium organizations a little over a year ago, so I feel your pain! The fraud event resulted in almost 8,000 records with dummy emails and address info and approximately $2,500 in small fraudulent donations. It was essentially a credit card testing scheme that exploited the org’s low minimum contribution amount on one of their donation pages.

Everyone's suggestions so far sound right on the money. We enforce reCAPTCHA in all available locations on our org’s TNEW sites, but somehow, they were able to get around it for some transactions. I forget the exact numbers, but if that wasn’t configured, we could have easily seen double or triple the number of fraudulent accounts created, so it’s definitely good to have that in place.

Here are the broad steps for what we did in terms of cleanup:

1. Identify all fraudulent records created. They all followed a similar email format, so this wasn’t too hard. We used a combination of some list pulls and reporting (New Record Summary, and On Account Tracking, etc.). The goal is to end up with one list of all fraudulent records created during the event.
2. To prevent further activity on these records, we quarantined them by inactivating them with a “Fraud Record” reason. We only did this to give the org time to deal with all of the refunds they had to process, so it may not be necessary in all instances.
3. Once any fraudulent transactions were delt with, we scheduled the records for purging and tried running the Purge Constituents Utility. We did encounter sluggishness and some blocking when running the utility from the front end (even on a smaller batch of 10 records). We asked the Network about it and they suggested running from SSMS. I believe they can even provide a stripped-down version of the procedure that should run faster, so I would reach out to them if you encounter similar issues.
4. This step hasn’t happened yet, but eventually these purged records will be picked up by our merge process and merged into our General Public record, so they don’t clutter the database. We schedule about 100 records for merging into the GP record weekly, so it’s going to be a little while until we are finally rid of them. In the meantime, they aren’t usable and are clearly marked, so they aren’t hurting anything.

Thank you so much for this. I/we greatly appreciate you and everyone else's time in helping us out with this.

-Jason