Hits to wp-login.php and xmlrpc.php from residential IP space

what exactly is behind these hits?

[SumGuy]

I usually see at least a once a week if not once every few days a pair of hits like this:

/wp-login.php
/xmlrpc.php

from IP's that resolve to something like what-ever.lightspeed.milwwi.sbcglobal.net or something.nycmny.fios.verizon.net. IP's that I would say are in the consumer / residential space.

I really would like to know what's running on the other end that is leading to these hits. A trojanized windoze box?

[not2easy]

Try to see what UA is used - though that is easily manipulated. It could be kids or students playing with scripts. Is the site on a WP platform? I see them hitting even non-WP sites requesting those common WP targets.

[tangor]

^^^ so true (for non wp sites). Only I don't get a few, I get a bunch. Must be special? Doubt it. Just probes. One or three I ignore per month, more than that kicked to the curb. (my 403 is smaller than my 404). Bandwidth costs money.

[jmccormac]

It may be a compromised box, a box running a web proxy or just someone looking for vulnerabilities.

Regards...jmcc

[dstiles]

I get loads of these, plus other probes for things I never had, such as wordpress. The intention is to see if your site is hackable - there are a lot of unpatched wp servers around.

A lot of the probes come from various (often dubious) servers plus a fair quota of DSL ranges around the world. I have a trap set up to check for certain common probes and run the IPs through a lookup to see who they are. Server ranges get bunged into iptables (port 443 only because of letsencrypt) and often I shove in a DSL range as well, if it's one of the baddies such as china, russia etc.

[SumGuy]

No, I don't run a WP site. I get a ton of wp-login hits over the years from all sorts of hosting-related IP's and over time I've added huge amounts of their IP's to my router's blocking list so at this point very few garbage hits get to my web server. Which is why these wp-login / xmlrpc hits are more noticable to me when I look at the logs. When they come from commercial / hosting IP's (or third-world residential ISP's) I don't bat an eye, just look up their AS IPv4 assignment range and block all of them. When they come from residential IP space, I'll just add the /24 to my blocking list, and wonder what's going on at the source IP.

[not2easy]

Years ago I put a bot trap named "/wp-login.php" on a non-WP site just to keep up with where they are coming from. Today I can say that they learn because that trap gets maybe one hit a year now.

[lucy24]

Try to see what UA is used

If it’s a compromised machine, they could easily use the actual UA of whatever browser they first got in through. More plausible than having everyone claim to be Chrome/41.

Years ago I put a bot trap named "/wp-login.php" on a non-WP site just to keep up with where they are coming from.

You don’t even need an actual file, though, do you. Malign robots will ask for it regardless.

:: detour to archived logs ::

My test site alone--which is 100% roboted-out and gets less than 10 human visits in a typical month--shows 144 requests beginning in /wp so far this calendar year (10 months). My “real” site has well over 30,000 in the same time period. Of these, something like half of one percent received a manual 404, my fallback for those that aren’t blocked by other means.

Memo to self: Add pattern ^\w+\. to bad_ref list.

[not2easy]

You don’t even need an actual file, though, do you.

No, not it you prefer to deal with them in other ways. I don't like script bots seeking points of entry and the trap lets them be blocked on the spot. "No more stuff for you!" I do not get around to examining logs every day. If I need to, yes, but it just isn't my favorite thing to be doing. ;)

[lucy24]

the trap lets them be blocked on the spot

Ooh, nice. What’s the procedure?

I just ran last month’s logs for my test site. I have a honeypot page that I created ages ago (invisible link from front page) and this month several robots headed straight for it. But there are not nearly as many requests for this actual page, linked from the site, as for the nonexistent /wp-login.php. That tells us something about malign-robotic behavior: definitely weighted toward shopping list rather than spidering.

Interestingly, there's a particular user-agent--IPs all over the map--that seems only to be used by this site’s robots. Usually when I find something in the test site’s logs, I find at least a hundred times as many on the “real” site. Huh.

[not2easy]

What’s the procedure? Well, it is from this WebmasterWorld site.

It is old and might use some modernization but it still functions fine: (2004) [webmasterworld.com...]

[lucy24]

Hm. Somewhere in the heart of that, you’re writing directly to htaccess. Brr. I can see where it helps to have a test site, so there’s no risk of breaking a real htaccess ;) (I also see that three-quarters of the thread involves making a roboted-out file, which we can happily ignore since nobody has any business requesting wp-login.php in any case!) And Fetch claims everything already has a “UNIX equivalent” of 644, which is good because I have no idea what it means.

[tangor]

For sites that don't use php putting .php in a deny solves a lot of problems ... but then again, that's probably a pretty small number of sites.

[not2easy]

The reason for roboting out the trap is because it is intended to catch non-compliant robots. Compliant robots won't request the file since it is denied in robots.txt.

The normal name of the file is not wp-login.php but there's no reason not to call it that either (unless it is used on a WP site). And there are commonly .php extension (includes) files used on .html sites for headers, footers and menus.

It blocks a dozen scrapers a month or so and sends me an email to update the htaccess file. So far they are nearly all data center IPs with an occasional rare Microsoft or Verizon hosted bot. The UAs are rarely any known bot, they wear human clothing.

[dstiles]

I block, via regex, the following wp, which seems to cover most of them, but I have over 100 other commonly-seen snippets in the kill file.

wordpress
wp[_-]
/wp/

[lucy24]

The normal name of the file is not wp-login.php but there's no reason not to call it that either (unless it is used on a WP site).

Yeah, that was my thought. If anyone at all is requesting wp-login on a non-WP site--or anyone other than an authorized user on a WP site--you already know they’re up to no good. You won’t see legitimate search engines requesting files of this type.

And there are commonly .php extension (includes) files used on .html sites for headers, footers and menus.

Easily handled in, say, mod_rewrite with a condition looking at THE_REQUEST, and/or a [NS] flag.