XF 2.2 Old users are becoming SPAM everyday !

Sadiq6210

Well-known member
Hello

Recently I upgraded our forum from 2.2.8 to latest version and I noticed that many old users are becoming SPAM everyday (5 to 10 old memberships are stolen everyday and posting spam threads). I can't see any relation between the upgrade and the issue, however, this is what happened. Is it a coincidence? Is this a new method of SPAM attacking to steal the users accounts instead of new registration? I mean I am moderating this forum since 2006, moved to Xenforo since 2015 and I didn't face something similar.

Currently I am trying to control the SPAM posts by banning many valuable old users everyday.
Anyone is facing same issue? and advise?
 
I thought about that, but it's really not very convenient. Especially for support forums.
Put all guests into the approval queue. it means they have to wait until you have approved their accounts.
Make a new usergroup called inactive users where they can post but they go into post approval.
 
Best solution for me: A CAPTCHA integration for the login form. I use an add-on by @DragonByte Tech for this:


No more such attacks anymore. :)

The add-on also logs login attempts. If you look at this log without login captcha activated, you might see a lot of random login attempts if you are "under attack". Each login attempt will most likely use a new IP address and new login credentials. In the end very few of the login attempts will be successful, but these accounts will be used for spam.
 
I'm using mentioned add-on as well, but I cannot seem to find that option? Could you point me in the right direction?
It's at the bottom of the options for that add-on (admin.php?options/groups/dbtech_security/):

Bildschirmfoto 2024-05-15 um 21.46.55.webp

btw: I suppose that the install/ folder can also be used for login attempts, so you should use a (.htaccess) password protection for that folder.
 
It's at the bottom of the options for that add-on (admin.php?options/groups/dbtech_security/):
Awesome, thank you! Was searching (and looking) for "login" and not "logging in" heh

btw: I suppose that the install/ folder can also be used for login attempts
Yeah, probably. I don't suppose that can be touched by @DragonByte Tech's addon to add a captcha there, too?
 
Put all guests into the approval queue. it means they have to wait until you have approved their accounts.
Make a new usergroup called inactive users where they can post but they go into post approval.
That's not the case here. Registered users, they never post, just leave the images in the quick editor as a draft. Then they use the image URL for spamming.
 
Best solution for me: A CAPTCHA integration for the login form. I use an add-on by @DragonByte Tech for this:
I don't think this is a good approach:
CAPTCHAs are usually really annoying - forcing them on every login could have a significantly negative impact on usability, especialy for users that like to clear their cookies whenever they close their browser.

Requiring a CAPTCHA to continue after a suspicious login might not be too bad though (but is still just a mitigation; if an account is compromised it is compromised and this needs to be addressed)
 
Awesome, thank you! Was searching (and looking) for "login" and not "logging in" heh


Yeah, probably. I don't suppose that can be touched by @DragonByte Tech's addon to add a captcha there, too?
I can certainly look at it for the XF 2.3 version :)

I wouldn’t hold my breath though as I strongly doubt the install area is addon-enabled, as obviously we wouldn’t want a broken addon to interfere with the ability to (re)install XF 😅
 
I wouldn’t hold my breath though as I strongly doubt the install area is addon-enabled, as obviously we wouldn’t want a broken addon to interfere with the ability to (re)install XF 😅
Yeah, figured as much, but maybe there's a way to have some functionality inside of it (maybe for stock 2.3 @Chris D ?). The way I see it adding a captcha to the admin cp login wouldn't prove that much more secure because a captcha would be missing from the install path anyway (which could/should be renamed or otherwise restricted by htaccess, but I digress) and an attacker could actually do a serious amount of damage there (for example by doing a fresh install). Not saying that couldn't be remedied by restoring from backups, but it'd be damage nonetheless.
 
Top Bottom