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
Thanks for posting about this issue. Our in-house security team is tracking this activity and the more intelligence we receive from our members, the better we can curtail it.
My assessment is that the bogus accounts are being created in a “tool-assisted” way, i.e. not entirely automated. This accounts for the relatively low number of accounts being created (dozens of accounts per day instead of hundreds or thousands), the fact that both reCAPTCHA and the CAPTCHA triggered by our WAF are being solved, and our bot protection system not being confident enough that the sessions are automated to block them in real time.
So far, we’ve tried to block the scammers based on a combination of session characteristics and IP address range or internet service provider. We do this instead of blocking a single IP address because it’s harder for the scammer to bypass and reduces the chance of false positives. I really want to avoid blocking real customers—I know exactly how much work that creates for frontline teams at member organizations.
Bogus accounts are a headache, but the real risk comes when the scammer goes to use those accounts. The long game could something like using stolen card numbers to buy and resell tickets or testing stolen card numbers for validity.
Fortunately we have other controls in place to make it harder to transact using stolen card numbers. If a scammer is creating accounts in advance to use for future fraudulent transactions, controls like the Address Verification System, payment gateway risk rules, card issuer block lists, and velocity checks will all combine to make that difficult for them. Which of these controls you use will depend on which payment gateway you use and, taking AVS as an example, whether you’ve turned it on and how strict you’ve set its pattern matching.
That said, I also want to stop the bogus accounts being created. That’s more complex because there’s likely a human involved, but the rules engines in our web application firewall and bot protection system provide very granular control that our security team uses to block activity like this.
My next step is to speak directly with member organizations who are seeing this activity, including those on this thread, to ask whether they’re comfortable with Tessitura putting in stricter rules. Because as the rules get stricter, the rate of false positives will increase.
As I was following up this investigation today, I saw that one of the flags we want to use to block this scammer is also generated by legitimate uptime and performance monitoring systems. A different kind of false positive. That reinforces for me that we should only setup the rules for members who are seeing the bogus accounts created and that we should try to modify the rules to allow for specific exceptions.
Michael and Mark, I see that you have support tickets open about this activity, the security team will use those to ask for your permission to implement stricter rules. Evan, Eve, and Kathleen, I don’t see support tickets about this issue for your organizations (though I’m not an expert at finding support tickets); if you’d like discuss stricter rules, let me know through a ticket.
Best wishes
Nic
Nic Boling
Vice President, IT & Security
Tessitura Network
Hello! We also are seeing some of these accounts. I have also submitted a Support Ticket as I am curious as to what our options might be. Please see Tess Support Ticket #631103 Thanks! Sarah McLain
AT&T Performing Arts Center