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 are on a custom site and not TNEW, but have dealt with similar issues in the past. We also have CAPTCHA in the login process to dissuade bots, but a while ago there was a very persistent human user who kept using our guest checkout flow to test credit cards (this was before we switched to TMS so the web payment iframe was not as sophisticated - if you're on Adyen/TMS now, I assume you're in better shape on that front).
Just a couple of thoughts - even though no orders are visible in Tessitura for these accounts, have you double-checked in the Adyen portal to see if any charges were attempted and failed? We've seen that before with pre-TMS carding attempts, where luckily every charge attempt is blocked so Tessitura looks clean, but there's a mess in the CC processor logs with all the failed tries.
You or someone with SSMS access can also check the suspicious customer_nos against the T_WEB_ORDER table, which will hold the record of an attempted order, even if the order was ultimately abandoned, to see if they were poking around with tickets or a donation at any point. I think you can also reference t_web_session_Session to try to track down the web session info and IP address of a given user. When we had one annoying bad actor hanging around on our website, we tracked down their IP address and blocked it entirely using our virtual waiting room, so they could never get over to the e-commerce side of our site. I'm not sure if TNEW has an equivalent functionality out of the box, or if Tessi support could help there. Of course, it's not that hard to cycle to a new IP address with a VPN or something, but doing an IP block at least forces them to start over from scratch, and at a certain point the goal is just to make it annoying enough that they give up and move on.
Hope that helps, and would love if anyone else has other tips!
Michael,
We are TNEW and use Recaptcha. We are also seeing accounts created with the word "stellard" in the email address. I have also noticed that the constituent numbers are often back to back, 5 or 6 accounts in a row which makes me suspicious that they are bots. Not much more to add but I thought it was interesting to hear that "stellard" is showing up in yours as well.
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.
Thanks for all of these great tips, Evan!
Just wanted to post my results so far in case it's helpful to anyone else with this issue - We're still using Windcave, so we checked there to see if there was an uptick in declined/failed credit card transactions. No luck. I also tried looking in T_WEB_ORDER and I'm seeing a lot of abandoned orders/contributions. Not much useful info in the site logs for those sessionkeys, but it definitely looks like they are trying to complete transactions. I was able to track down some IP addresses in t_web_session_Session, but I'm not finding a pattern there either. When I look up some of them, I'm seeing various countries of origin (e.g. India, Israel, Vietnam, etc.).
Thanks for letting me know I am not alone on this. But I am sorry you're dealing with this.
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.
Wanted to throw my experience in, to add to any possible pattern. Luckily I only have 63 in my entire db. they all have stellardl (that's an l at the end) and they're all gmail. All created between late April and early June, with the bulk mid May - early June. Based on the create date/time stamps, they look more human created than bot created. I'm checking with marketing and ticketing to see if we had any special promos at that time or anything...
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.
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
Eve Stavropoulos said: We are also seeing accounts created with the word "stellard" in the email address.
Interestingly, I am finding these, too, with "stallardl@gmail.com" being a common denominator:
No transactions, no interaction at all, just a junk constituent and garbage e-mail. Odd. I delete these as I find them.
Exactly. I'm doing manual inactivations at the moment and I'm also noticing some similar/sometimes the same phone number on them as well. Once I move through this round of inactivations, I'll do a duplicate phone search and see what comes up
Been following this thread out of interest, but we are not seeing any of this. Not a single "stallard" e-mail in our database outside of the four patrons who actually legitimately have that name. And in fact, the number of fake/bad accounts we have had created over the last few years has been exceedingly few.
In case it matters, TNEW on RAMP, no AVS and no reCAPTCHA. Also, pretty sure I asked for them to step up the anti-Bot activity for us from get go, whatever level of stuff that Nic mentioned below that ends up being. That said, I also DO have custom JavaScript on our account creation pages that auto-disables the "Create Account" button until they tick an additional box that I have entered there that says "Agree to Terms" at which point the patron is then able to create the account. Not sure how that might or might not affect bot/fake account activity (maybe these people just do not like my organization as much as they like yours), but I figured I would just throw that out there just in case it is useful as a counterpoint.
Best of luck to those dealing with this!
John A. Moskal II said: I also DO have custom JavaScript on our account creation pages that auto-disables the "Create Account" button until they tick an additional box that I have entered there that says "Agree to Terms" at which point the patron is then able to create the account.
That may be all it takes to deter most of these script kiddie type bot accounts.
If so then yay me. I initially thought it was overboard when I was first asked to do that, but we had gotten a new CEO who is a former trial lawyer and who said if we want to even pretend our Privacy Policy and Terms of Use held any kind of legal statute that we should really do this for people who create accounts, regardless of anything else (not sure that was correct, but he wanted to be over-cautious). And, seeing as I am not sure I have ever heard a single complaint about it; I guess no one out there really objects to it. So our lawyer CEO is happy and, one way or another, we are not getting a lot of bot accounts created. I can live with that.
Nic Boling said:if you’d like discuss stricter rules, let me know through a ticket.
I'd like to be included in this discussion; please see ticket 630808. Thanks, Nic.