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.
Hello Michael (and everyone in this thread). I wanted to give you an update on this issue as to where things stand at this point, knowing how disruptive and frustrating it is for all of you impacted by it.
Our security team has been vigilantly observing this behavior and trying to find anything that might give us a clue as to how to block this tool, but so far there isn't a discernable pattern that can be stopped at the firewall level. We have various alerts in place to look for suspicious activity (repeated patterns from a single origin or headers, velocity, etc.), but these bad actors mix up their point of origin enough that it's difficult to come up with anything systematic. We have gotten pretty good at dealing with bad actors who a) just use bots, or b) go after the transaction path, but it is very difficult to deal with human-assisted bots (which this appears to be) as they pass the recaptcha tests issued by our firewall and that are just doing nuisance account creation.
The recommendation at this point is to use List Manager to generate a list of these junk constituents, using either the EAddress Like filter with '%stellard%' as the criteria or by using the below SQL in the Show Query tab:
SELECT e.customer_noFROM T_EADDRESS AS eWHERE e.address LIKE '%stellard%'
NOTE: This will require that you carefully check the results to avoid catching anyone who might actually be legitimate. You may be able to add an exclusion list to remove folks who you know to be real people.
You can then run the Purge Utility with that list to remove these junk accounts. You could also do a simple SQL query to simply inactivate these constituents, if that fits better into your data santiziation practices.
We are continuing to discuss what other measures we might be able to take to block or deter this behavior and I will update you all here when I know more. You are also more than welcome to submit a support ticket to address your specific concerns, as many of you in this thread have already done.
Thank you all for your feedback so far. More as soon as I have it!
Matt BelangerSupport Escalation ManagerTessitura Network
Matt-
I've spent a bit of time (probably too much time) looking at this issue over the past few days. I agree with most of the points in your assessment. Between our WAF, bot mitigation and the IPs in T_WEB_SESSION_SESSION, I have a couple of ideas if your team wants to discuss. I've managed to get this traffic to a trickle in our system. I'll know how successful it is in a week or so. I'll be off next week, but would be happy to discuss with your team after the New Year if you want to reach out.
Best,
Patrick
Sounds good, Patrick. I'll be in touch!