Double UA Spammer

[TorontoBoy]

I have a bunch of content spammers that are posting with a UA that is repeated. Instead of a single UA they simply add a comma and repeat it, possibly with slight variation.

178.57.68.89 Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML like Gecko) Chrome/31.0.1650.63 Safari/537.36, Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36
178.159.100.247 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML like Gecko) Chrome/25.0.1364.152 Safari/537.22, Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36
181.215.39.102 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML like Gecko) Chrome/30.0.1599.69 Safari/537.36, Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36
185.252.219.97 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML like Gecko) Chrome/29.0.1547.57 Safari/537.36, Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36
185.252.219.97 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML like Gecko) Chrome/29.0.1547.57 Safari/537.36, Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36

These spammers seem to have some other tricks. The IP used does not GET before it PUTs, are unique for the day used, making verification of the IP problematic. They also somehow evade my header logging. Hmmm.

All UAs are unique, with small variations in each., but most are from QUALITY NETWORK CORP, RU
-178.57.68.0/24 QUALITY NETWORK CORP, RU
-178.159.100.0/24 QUALITY NETWORK CORP, RU
-181.215.39.102 QUALITY NETWORK CORP, RU
-181.215.39/24 Digital Energy Technologies Chile
-185.252.218.0 - 185.252.219.255 QualityNetwork Estonia

Has anyone else noticed these double UAs? Can you see a flaw in my Regex?
"Mozilla\/5\.0 \(Windows NT 6(.*?), Mozilla\/5\.0 \(Windows NT 6"

[lucy24]

Why not simply
", Mozilla"
?

:: quick detour to logs ::

Nope, definitely not present in any real human UA. The most recent ", Mozilla" I find are apparent transmission glitches: human request (as evidenced by surrounding log entries), but the duplicated UA--in my case a Mac, understandable if you know the files--was also missing headers. In fact the first one I found was slightly analogous to your situation, because it was requesting a downloadable file. This turned out to be a red herring, though. I also found some non-duplicated ", Mozilla"--but when a UA has "github" in the middle, it's probably no loss blocking the simple string.

Chrome < 30 is pretty iffy in any case, even if you say it twice. (Does it then add up to Chrome > 50?)

Edit: Is the RegEx being deployed in some engine that uses /blahblah/ as its delimiters? (Like javascript, or that one obscure Apache mod whose name I can never remember.) If no, you don't need to escape the slashes.

[TorontoBoy]

", Mozilla" , Uhn! (slaps forehead) So elegant.

Thanks!

[TorontoBoy]

POST /example/2010/06/03/does-motorcycle-mesh-gear/trackback/ HTTP/1.1
POST /example/2011/04/10/-chinatowns-downtown/trackback/ HTTP/1.1
POST /example/2010/06/03/does-motorcycle-mesh-gear/trackback/ HTTP/1.1

I just discovered that these are Wordpress trackback requests, used to post directly to WP, when your WP post has been linked to from another WP site. They often do not use a GET request, so they don't show up as your standard GET then POST behaviour. Also because they are trying to post directly to WP I would not see their behaviour in the header logs, as they do not request a web page. These trackback POSTs are a backdoor to spamming WP sites that do not go through the normal feedback form.

[TorontoBoy]

Interestingly, while this spam method uses the WP trackback route, from the WP admin console the comment posted does not render like a WP trackback, but just like a regular comment. It is interesting, however now busted.

[lucy24]

Yup, I remember /trackback/. In fact I'm pretty sure someone hereabouts explained it to me. It gives the requested file as referer, as would legitimately happen if someone went to your /contact/ page and then sent a message--except that then there would be the preceding GET request. For some reason they don't have a way of finding out ahead of time whether your /trackback/ file--or, I guess, the /trackback/ function, since it's WP--actually exists. Can't they tell if a site is WP or not? (Pro tip for robots: If a page lists more than eleven stylesheets, it's WP.)

If your site is not, in fact, WP, I don't think there's much harm they can do. But if you find the requests vexing, options include
--returning a manual 404 to any and all requests ending in /trackback/ so your server doesn't have to waste time looking for the nonexistent file
--blocking all POST requests except to pages that legitimately use POST (like your contact form, if you have one)

Poring over logged headers suggests that they don't send one header that humans normally send, so they get blocked regardless. They also send a Content-Length header, which I guess means they were attempting to post something with a length of {some small number, typically <200} bytes.

Edit: I overlapped your second post, so I didn't realize your site actually is WP.