The X11 / Ubuntu Firefox/62.0 botnet is back

and it's really persistent

[SumGuy]

I'm not quite sure when I started to see this UA:

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0

It couldn't have been much before 2019 or 2018. I didn't see it a lot, 37 hits in 2021, 46 hits in 2022 and those ended in April. Then, starting just a few days ago on Jan 17, it's 59 hits now and counting (Jan 17, 18, 19). It pokes around trying to see if these paths exist:

/_ignition /a /js/mage /0 /arx /new /00 /backup /old
/01 /blog /shop /02 /blogs /temp /1 /dev /tmp
/123 /js /wordpress /www /wp

I'm blocking a lot of IP's in the router, probably 1/4 or 1/3 of all IPv4 space, that includes china, southeast asia, latin and south america, east europe, the garbage ranges of MSFT, AMZ, GOOG, and the other usual suspects. So these hits are coming from IP's that are not on my bad list. From what I can see, looks like residential or maybe commercial ISP's in the first world, maybe mostly South Korea and Europe but some US and Canada.

I don't like the idea of them polluting my web logs, I really can't block them (seems to never be the same IP or /24) so no use blocking them in the router. I wonder what sort of malware and infected devices are hosting this botnet.

Anyone else seeing this?

[lucy24]

:: detour to logs ::
Gosh, there are hundreds of them, every last one happily a 403. Oh, and a sole human 200 at the very beginning of 2022, but it wasn’t Ubuntu, it was a different FF/62. Mine tend to ask for assorted wp-related files, and sometimes other predictable cms.

:: further detour to headers ::
The 403s are due to assorted header deficits, hurrah. And then around mid-year my old_firefox value was either set up in the first place, or explanded to include /6x (I should keep records, but I don’t), so that's further grounds for door-slamming.

[blend27]

If you are still getting real visitors using Firefox/62.0 I'd be very, very surprised. Who in their right mind be running FF62 on Ubuntu?

Why not just cut it just below the knee, and get it over with.

I experimented a bit(for a year) with older Browser UAs and pulled the plug on all IE below 11(don't get me started), All Chrome below 72 and all FF below 68.

The result was Beautiful.

If some one trying to connect they see:

This site can’t be reached
The connection was reset.

Request gets dropped and visitor gets 0 bytes in return. I get Clean logs = No junk at all from FF 3.6 old school UAs and such.

On the other hand, try getting around the web with that UA, you will be either blocked or butchered to death with CAPTCHA. Try it on any site that is routing thru CLOUDFARE.

On the other foot, FF & Chrome pretty much are running on AutoUpdate unless it is disabled, so the only reason someone would be on FF that old is that MOZILLA is not updating it due to hardware limitations of the device or it is on Mobile OS only(Something like Android 4.2.2 - Last update is 68 & I own one of these devices).

I am not loosing any sleep over it. I don't see it my IIS logs at all.

P.S:
My favorite was:

Mozilla/5.0 (Linux; U; Android 2.2; ja-jp; SC-02B Build/FROYO) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

From all over Japan. and it is still going strong!

[tangor]

Pick and chose your method!

I find it easier to address the REQUEST (which does not appear on my site) rather than the zillions of IPs that MIGHT make that request.

Don't get me wrong, I do filter by browser version and that handles a great mess of IPs as well.

Last thing I want---though I have a growing list---is a bunch of IP denies, either in .htaccess or the firewall.

Not as handy as others with the header thing, but working on that. :)

[SumGuy]

I have seen this activity stop last week. I thought they were going to go through a dictionary-type scan for folder names, they had finished some numbers (like 1, 10, 100, 2, etc) and had started on the "a" 's but then it just seemed to stop. Again this was from IP's that I ordinarily wouldn't block, like western or first-world residential IP's and I rarely rarely rarely see bot activity from this class of IP's. If this activity was also coming from third-world / SE-Asia or latin / south american IP's then I wouldn't have seen it because I'm blocking those IP's in the router.

Given the class of IP's that I know was participating in this activity, I'm really curious as to what were the devices that were obviously part of an organized botnet. I wonder if this is yet another example of the well known microtik router problem or if it's something else.

[System]

The following message was cut out to new thread by not2easy. New thread at: search_engine_spiders/5089674.htm [webmasterworld.com]
9:54 am on Jul 8, 2023 (atl -4)