My next class:
Reverse-Engineering Malware: Advanced Code AnalysisOnline | Greenwich Mean TimeOct 28th - Nov 1st 2024

Who Are Those Bots?

Published: 2022-02-15. Last Updated: 2022-02-15 06:19:32 UTC
by Xavier Mertens (Version: 1)
3 comment(s)

I’m operating a mail server for multiple domains. This server is regularly targeted by bots that launch brute-force attacks to try to steal credentials. They try a list of common usernames but they also try targeted ones based on a list of email addresses that have been crawled. The mail server is protected by several security controls. One of them is an automatic blocking of offending IP addresses to slow down such kinds of attacks (brute-force) but I noticed that this technique was less and less relevant. Indeed, when a new wave of connections is launched, they are coming from a lot of different IP addresses that just test a few credentials and, therefore, do not trigger the automatic blocking. I extracted the list of IP addresses that generated authentication failures for the last 30 days and got a list of 11K addresses. They are part of botnets used to launch these attacks. But who are those bots? What kind of host are we facing?

I performed a scan of the 11K IP addresses and tried to extract some useful information about them.

First, there are spread all over the world:

Top-20 of source countries:

Numbers Country
   1964 Brazil
   1439 United States
    839 India
    596 Argentina
    457 South Korea
    308 South Africa
    275 Poland
    245 Russia
    234 Iran
    230 Spain
    223 Taiwan
    223 Vietnam
    183 United Kingdom
    148 Canada
    136 France
    113 Hong Kong
    104 Thailand
     96 Italy
     90 Germany
     80 Israel

Most of the IP addresses were not reachable or protected by any kind of packet filtering, however, I collected interesting info. Here are some of them.

Interesting domains found by resolving PTR records for all IPs:

agri.gov
effi.org
gouv.fr
gov.la
gov.np
mit.edu
rit.edu

Many devices are from the same brand and have an SSH service exposed. They share the same SSH keys:

43:a1:56:fb:8a:8b:31:95:9f:c1:d1:81:f1:88:1d:99
e6:69:15:e5:87:a1:1b:54:41:d2:77:03:88:e7:1e:11
f3:b8:a8:76:2f:f7:6c:55:7e:f6:7b:cb:4e:07:0e:d9
79:22:d3:cc:e9:f7:32:79:0e:0c:7a:30:86:43:aa:3b
a9:89:a5:d1:4c:52:a7:d7:ab:1d:ec:6b:f9:b8:2c:9f
d0:01:0b:2b:e8:4b:72:b8:ef:a2:9b:23:ed:60:47:7b
eb:46:ab:9a:11:7f:10:5c:9a:f0:1c:5b:9e:39:cf:ec
ef:d7:16:bf:cd:62:ba:0a:5f:56:b6:e4:ac:4d:8d:6e
f5:84:ab:48:3c:ba:7c:22:71:b3:c3:95:9b:da:9c:e3
54:9f:e6:91:af:41:a0:80:80:90:ab:95:1a:b3:83:b2
35:47:3c:e0:44:14:fb:39:ec:95:a4:a8:9a:28:29:ce
4e:22:4a:03:ca:10:99:5c:3e:8d:c8:4f:3a:05:db:7e
57:8c:9c:09:91:9a:54:8d:6a:88:88:98:5c:3c:87:e0
d3:46:7f:23:58:63:62:e4:35:c5:5e:99:ca:c9:6a:3a
a2:88:9a:23:d0:bf:f0:f9:3e:af:77:6d:02:86:7b:3a
f6:13:34:6f:3e:99:34:ed:f9:8c:27:10:a1:1d:e6:d1
a8:6a:24:5d:e6:f2:8e:00:e3:cc:2b:ec:76:7c:bc:e8
9d:c9:02:25:d6:73:b2:6f:54:b4:16:7f:eb:0f:1d:20
45:a9:db:56:75:df:c2:e6:b7:f2:14:41:a4:fe:85:e0
00:34:07:d9:c1:f5:01:f0:e9:b3:3d:e3:be:1d:f3:28
b6:5d:f7:0d:5e:f6:9b:de:60:0e:43:cf:bc:4b:20:4a
30:b6:29:06:27:62:bb:cd:a1:aa:65:84:08:62:31:ab
16:f8:8c:fe:cf:9b:51:92:1a:9e:39:d5:db:f6:17:d4
84:c8:13:c4:be:a5:04:af:39:1f:42:ea:0c:32:70:39
21:45:57:55:75:41:b3:cc:fc:61:df:18:61:8f:9e:a0
0e:ec:f4:f9:29:78:1d:9d:9c:45:86:6c:9c:a6:69:cf
88:24:9b:f6:7f:bb:63:40:06:fd:60:ea:7c:7f:32:c6
25:14:1f:ec:80:8a:79:94:b3:bb:af:96:8e:d3:78:78
e9:33:e6:7e:f9:c3:55:2b:3f:0f:ab:ab:75:7d:e2:f6
6b:16:a7:87:4a:18:06:33:82:14:95:33:ab:67:b5:06
3b:9d:e5:a9:28:4a:e2:fd:6e:f8:02:17:e8:03:94:39
f0:46:ee:7e:36:e8:18:c9:3c:1f:6a:dd:92:16:67:a1
87:71:51:36:a9:5f:cb:7f:08:15:30:58:cb:0c:68:4f
4a:42:82:80:56:e0:74:38:b5:6d:17:9b:a8:87:1c:fb
02:59:bd:a0:50:8d:b4:1e:79:2f:21:d4:01:b2:40:d8
06:4a:19:93:08:86:06:8c:91:c3:39:ae:3b:98:b6:db
a9:7b:bd:93:a0:22:a7:f5:d4:a8:22:d0:7f:48:ae:ce
52:59:2c:10:4a:7e:8f:b8:e8:29:4c:b1:53:ca:38:ea
c0:9a:94:4f:9e:ad:07:4d:62:a7:6c:f6:db:a3:5f:80
af:53:90:6c:00:8b:7a:34:4a:2f:54:a0:7d:63:37:15
29:9e:ae:af:0e:6f:61:60:45:49:ad:00:00:2b:f6:b9
73:3a:03:c7:8e:31:42:8f:df:04:1a:d2:94:c0:d9:0a
12:14:fc:bc:b0:13:10:a3:45:ee:39:13:c5:75:2a:01
47:25:71:67:e2:95:4a:13:b2:df:3d:97:7b:55:ae:08
fc:a2:df:a7:61:ac:74:13:94:4c:dd:0c:78:02:d5:ad
fd:92:53:03:b7:76:30:20:6b:c8:b5:19:70:1a:4f:62
b8:af:88:4c:da:6f:98:a9:b8:49:7c:29:d4:9a:72:52
b2:b8:7f:2c:89:bd:98:60:b6:71:4e:58:73:a0:fa:93
44:30:15:f7:a8:27:73:6a:3f:e7:ca:12:b7:c3:1d:6d
17:60:bb:44:2f:36:d8:df:6b:98:fb:63:7f:52:a7:a1
2c:8f:45:59:7b:17:3c:c1:c6:b8:c4:24:00:b3:fe:b4
e0:08:48:a0:e1:ea:91:a0:7a:a2:de:b9:d7:14:7a:06
a6:03:ad:51:a4:84:4a:f2:32:fb:77:46:c7:25:0f:eb
f0:22:60:cc:5c:65:97:eb:c6:24:02:7c:24:9b:42:50
4a:b0:16:7c:c5:46:ea:75:1e:24:8d:70:e5:99:47:bc
65:6e:fb:a7:48:e5:c5:fe:b0:46:1d:e6:09:6f:55:0a

Now, let's have a look at the models of devices that are scanning. To achieve this, I had a look at the CPE ("Common Platform Enumeration"). I removed most of the data and kept vendors. Note that it can be wrong if the bot is running behind a NAT'd network.

Numbers Vendor
   1110 linux
     63 google
     46 ubnt
     38 freebsd
     37 hp
     24 linksys
     24 dlink
     23 asus
     22 juniper
     21 synology
     20 crestron
     16 netgear
     16 microsoft
     15 axis
     13 geovision
     13 cisco
     12 windriver
     12 dell
     11 apple
     11 3com
     10 mikrotik
     10 kemp
     10 infomir
      8 grandstream
      8 alliedtelesyn
      7 directv
      7 cyanogenmod
      6 canon
      5 tenda
      5 oracle
      5 openbsd
      5 micronet
      5 lexmark
      5 iomega
      5 epson
      5 aerohive
      4 watchguard
      4 symantec
      4 smc
      4 ibm
      4 extremenetworks
      4 avm
      3 xerox
      3 vodavi
      3 sun
      3 siemens
      3 ruckus
      3 rockwellautomation
      3 pirelli
      3 oneaccess
      3 ironport
      3 huawei
      3 gemtek
      3 arubanetworks
      2 tranzeo
      2 toshiba
      2 tandberg
      2 supermicro
      2 sonyericsson
      2 lacie
      2 ipxe
      2 iptime
      2 io-data
      2 hikvision
      2 fujitsu
      2 brocade
      2 arris
      2 adtran
      1 zyxel
      1 zonealarm
      1 vodafone
      1 utstarcom
      1 tp-link
      1 thomson
      1 sphairon
      1 sony
      1 sonos
      1 sonicwall
      1 shoretel
      1 scientific_atlanta
      1 riverbed
      1 raritan
      1 qtech
      1 qnap
      1 philips
      1 pheenet
      1 olivetti
      1 netgem
      1 netasq
      1 motorola
      1 kyocera
      1 ipfire
      1 igel
      1 fortinet
      1 enterasys
      1 ecoscentric
      1 drobo
      1 dish
      1 comtrend
      1 citrix
      1 checkpoint
      1 belkin
      1 airmagnet

The most interesting one for me: "rockwellautomation", related to industrial devices!

What about the "open" TCP ports? (Note: I did not scan UDP ports to reduce the scan time)

On average, one bot has 18.8 TCP ports publicly facing the Internet. The worst one had 74 ports exposed!

Here are the top-10 ports:

Numbers Port
    574 22
    408 80
    180 8080
    104 443
     94 2000
     84 8000
     82 53
     77 23
     68 10001
     51 2222
     51 1723
     46 8022
     45 81
     44 554
     39 8291
     27 8081
     26 4444
     25 8888
     24 161
     18 85

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Keywords: Bot Botnet Scan
3 comment(s)
My next class:
Reverse-Engineering Malware: Advanced Code AnalysisOnline | Greenwich Mean TimeOct 28th - Nov 1st 2024

Comments

Great minds must think alike. I did something very similar several years ago while working for SGI, though I wasn't nearly as thorough. But all the IPs I looked at that tried brute-forcing email accounts either had ports 80, 443, or 22 exposed and so I assumed (I think rightly) that they were just compromised ssh servers that (sigh) allowed username/password authentication (and didn't require multi-factor) or were compromised IoT devices or consumer-grade network kit exposed to the interwobble.

For me, it was simply further justification for A) keeping our email servers INSIDE our corporate networks (requiring a VPN connection with multi-factor auth to access) and B) setting up a log analysis module that would watch for IPs trying brute-force attacks and updating an internal RBL (why accept email from an IP that's trying to break in), update DNS RPZ zone (why allow hostnames that resolve to an IP trying to attack us), and update a log-analysis engine (I want to know about anyone suddenly sending non-attack-related traffic to/from an IP that's been attacking us). :-)

When the internet is giving you lemons, make lemonade!

PS. I found that auto-updating the RPZ filters DID pay off too. On more than one occasion I found malicious URLs in spam/phish pointing to an IP that had been previously seen doing brute-force attacks on our email gateways. Interesting, no? It confirmed (for me anyway) that the IPs in these botnets are not ONLY used for port-scans and brute-force attacks, but hosting malware, landing pages, phishing pages, etc as well.

PPS. I dunno what I'm doing wrong, but my reply is flagged as "anonymous" again even tho I was logged in when I sent it. Weird.
Hi There
I have actually seen the same thing. This is still happening a lot.

Some information additional information others can use.

When attacking over TCP port 465 - The following JA3 is observed.
JA3: f17ca639ecdcaa65b4521c49e3515ef9

Pcap file with an attack.
https://networkforensic.dk/images/2021/BotNet/IOT-Attack.zip
SHA1: 0c8b31996bba6c5668292ad111fbedf55199040f

Some attacking IP's:
https://networkforensic.dk/images/2021/BotNet/RAW-IP-LIST-IOT-BOTNET.zip
SHA1: 95325e453bf44d15e97523b7f749a66ec608e185

SNORT IDS SIGS
alert tcp $EXTERNAL_NET any -> $HOME_NET [465,993] (msg:"NF - IOT BotNet Attacking - Password Attacks"; flow:to_server,established; ssl_state:client_hello; content:"|00 33 00 32 00 31 00 30 00|"; reference:url,networkforensic.dk; reference:url,www.guardicore.com/labs/fritzfrog-a-new-generation-of-peer-to-peer-botnets; metadata:06122021; classtype:attempted-user; sid:5027901; rev:3;)

alert tcp $EXTERNAL_NET any -> $HOME_NET [465,993] (msg:"NF - IOT BotNet Attacking - Password Attacks"; flow:to_server,established; ssl_state:client_hello; content:"|35 00 2f 00 39 00 33 00 3d 00 3c 00 6b 00 67 00 6a|"; reference:url,networkforensic.dk; reference:url,www.guardicore.com/labs/fritzfrog-a-new-generation-of-peer-to-peer-botnets; metadata:21122021; classtype:attempted-user; sid:5027902; rev:1;)


Written in danish (Sorry)
You can see more i believe is related to what have been seen here.

19 Januar 2022 - Blog Post # 812
16 December 2021 - Blog Post # 806
10 December 2021 - Blog Post # 805

Happy hunting
That's a great share! Thanks!

Diary Archives