Is it possible to find the link somewhere?

Hello,

Thanks for using WPS Hide Login.

You’re right, your secret slug is only saved in database.

Is your website clean of malware etc ?

Are you using any membership plugin ?

Are you sure any public link is placed on your website ?

I am having the same problem. Despite using an unguessable slug, one IP is constantly hitting my brute force login plugin.

That is locking them out, but I don’t understand how they got to the login page in the first place.

I have used this plugin for years and every now and then someone gets through. So there is obviously a way to do it, one that we don’t know about.

There is no way anyone could guess the slug I’m using. There must be a black hat way to defeat this plugin. The fact it’s the same IP tells me they know something we don’t.

Hello @spade and @sandgroper

If only one IP has found your secret slug, are you sure your website isn’t compromised ?

I have just noticed my .htaccess files for my latest sites have dropped the code I put in to disable xmlrpc.php

I put it in when I created them, but it appears to have been stripped out since.

So the sites were vulnerable to xmlrpc attack. This means your plugin was probably not bypassed and is doing its job.

No the sites could not have been compromised, because I have brute force login protection that permanently blacklists an IP after 2 failed login attempts.

I unblocked that IP, but of course they came straight back because of the missing code.

@sandgroper

It doesn’t matter. The hack can come from a vulnerable plugin, theme or from an old WordPress version even if it has been updated after the hack.

It has been my experience that if xmlrpc.php is not blocked, that is how a login is attempted. They do not try via the normal login screen at all.

With or without your plugin, they try to get in that way. I can see that in the raw access logs, which is why I realized my .htaccess wasn’t doing its job.

@sandgroper

My last post concerned your answer about the fact your website couldn’t be compromised.

For xmlrpc, you’re right. It can come from here. Enable xmlrpc makes a vulnerability fail on your website.

Yes, couldn’t is probably not the right word. “Most likely wasn’t” would be more correct.

I think they just tried to login through the back door and once they were blocked, couldn’t access the site any more.

Touch wood, I have never had a site hacked since I started making them in 1998. I use various methods to lock them down. No one method will cover everything.

I got 194 login attempts from all different users and countries within 24 hours, despite the fact that my htaccess file says:
<files xmlrpc.php>
Order Allow,Deny
Deny from all
</files>
and I got a 19 character login URL from a password generator.
What could be wrong?

• This reply was modified 1 year, 11 months ago by Frank Spade.
• This reply was modified 1 year, 11 months ago by Frank Spade.

@spade

Going to your site and adding /xmlrpc.php returns:

XML-RPC server accepts POST requests only.

That means xmlrpc has not been disabled.

The files tag should be capitalized – Files, not files. May be reason?

• This reply was modified 1 year, 11 months ago by Graham.

@spade The order is also the wrong way round. Should be:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Thanks a bunch.

Thanks a bunch!

You’re welcome.