Hello! We have an ongoing (and potentially fraudulent) problem with online constituents being created with gibberish names and bogus addresses. AND there are never any orders associated with the new accounts. I cannot figure out the purpose, if this is a preemptive attempt at setting up fraudulent order, and are they BOT created. I run a New Record Summary report everyday, and everyday go through the list of new online accounts that were created the day before. The bogus accounts are pretty easy to spot, but sometimes number in the teens or twenties each day. I then go into each account and deactivate them, which can be quite laborious. Does anyone else have this issue and do you have any other way of dealing with them. More often than not, they have emails with the word stellard in the address. I have an ongoing ticket trying to find a pattern that might help create some preventative measures in keeping these accounts from being created. Any shared experiences are welcome.
Hi Michael! We're seeing the same thing on a couple of TNEW sites in our consortium. We have reCAPTCHA enabled on all pages, but these same "stellard" records seem to keep popping up in increasing numbers. I was able to track down the first couple instances of them to as early as November 2022. Then we saw about 30 or so in May 2023. This month has been the worst. We are approaching about 80 of these records created this month alone.
We're basically doing the same thing as you. Checking the New Record Summary report and inactivating. We also have a ticket open with the Network and they made some firewall adjustments. So far that hasn't seemed to stop the issue.
Hi Mark. Something I wanted to confer with you on. I was first deleting login and email address, then inactivating. Then I thought that by deleting the login, I am allowing another bogus account to be created with that email/login. So I am just deactivating. Do you concur that keeping the login in tact keeps another account from being created with that login? All I am seeing now are variations on the stellard email address. We had some firewall adjustments made too. They seem to work temporarily. But soon enough we are back where we started, and even worse at times.
Hi Michael,
That's a good question. We're still figuring out the best way to deal with these on our end, so this may change, but up until now, we've just been inactivating the records. We didn't touch the logins/emails. This is what the Network suggested. I did have some concerns that the bad actor(s) could continue to make further attempts from the same login and learn new information even after their record has been inactivated. We have the setting in T_DEFAULTS for allow_inactive_login set to "Yes", so even if the entire constituent record is inactive, they can still login online if they have an active login on the record. If you have this setting in T_DEFAULTS set to "No" that may be good enough to stop them from using the same login for repeated attempts.
When I looked in T_WEB_ORDER, I saw multiple sessions for the same constituent over the course of 5 or 6 days, so it does seem like they are frequently returning to test using the same record/login. I don't know what exactly they're doing, but in the interest of making things more difficult for them, we've started to inactive the logins as well as inactive the record. That should prevent them from repeatedly using the same record/login, but preserve the audit trail while we try to get to the bottom of this. One day, if we get this to stop, we'll purge all of these from the database to clean things up and the emails/logins will be deleted then.
Your concern about them creating duplicates if you delete the email/login is valid though. I think if you inactivate, they shouldn't be able to create a duplicate. They'll get a message saying that the email is already in use and they either need to reset their password (which I don't think will work for an inactive login) or use a different email, which they probably will do. In the end, I don't know if inactivating or deleting the login will have a huge effect one way or the other, but it seemed like the safer approach for now instead of letting them continue to return to the same account.
I hope that helps! I’ll be sure to let you know if we learn anything new and our approach changes.
I did some testing on this in Test when trying to figure out the best approach - inactivating the login will stop that email address from being used again, deleting it can result in new accounts being created with the email address. You can also inactivate the record entirely and it will work the same as if the email address has been inactivated.