An IP address (85.10.200.201) under your control appears to have attacked one of our customers as part of a coordinated DDoS botnet. We manually reviewed the captures from this attack and do not believe that your IP address was spoofed, based on the limited number of distinct hosts attacking us, the identicality of many attacking IP addresses to ones we’ve seen in the past, and the non-random distribution of IP addresses.
It is possible that this host is one of the following, from the responses that others have sent us:
— A compromised router, such as a D-Link that is running with WAN access enabled; a China Telecom which still allows a default admin username and password; a Netis, with a built-in internet-accessible backdoor (http://blog.trendmicro.com/trendlabs-security-intelligence/netis-routers-leave-wide-open-backdoor/); or one running an old AirOS version with a vulnerable and exposed administrative interface
— An IPTV device that is vulnerable to compromise (such as HTV), either directly through the default firmware or through a trojan downloaded app
— A compromised webhost, such as one running a vulnerable version of Drupal (for instance, using the vulnerability discussed at https://groups.drupal.org/security/faq-2018-002), WordPress, phpMyAdmin, or zPanel
— A compromised DVR, such as a «Hikvision» brand device (ref: https://www.hikvision.com/en/support/cybersecurity/security-advisory/security-notification-command-injection-vulnerability-in-some-hikvision-products/security-notification-command-injection-vulnerability-in-some-hikvision-products/)
— A compromised IPMI device, such as one made by Supermicro (possibly because it uses the default U/P of ADMIN/ADMIN or because its password was found through an exploit described at http://arstechnica.com/security/2014/06/at-least-32000-servers-broadcast-admin-passwords-in-the-clear-advisory-warns/)
— A compromised Xerox-branded device
— Some other compromised standalone device
— A server with an insecure password that was brute-forced, such as through SSH or RDP
— A server running an improperly secured Hadoop installation
— A server running a pre-13.10.3 GitLab instance that is vulnerable to CVE-2021-22205
— A compromised Microsoft DNS server (through the July 2020 critical vulnerability)
The overall botnet attack was Nx10Gbps in size (with traffic from your host as well as some others) and caused significant packet loss for our clients due to external link saturation. It required an emergency null-route operation on our side to mitigate.
Attacks like this are usually made very short, intentionally, so that they are not as noticeable and slip past certain automatic mitigation systems. From your side, you would be able to observe the attack as a burst of traffic that likely saturated the network adapter of the source device for perhaps 30 seconds. Since the source device is a member of a botnet that is being used for many attacks, you will see many other mysterious bursts of outbound traffic, as well.
This is example traffic from the IP address, as interpreted by the «tcpdump» utility and captured by our router during the attack. Source and destination IP addresses, protocols, and ports are included.
Date/timestamps (at the very left) are UTC.
2023-07-23 17:51:01.574760 IP (tos 0x0, ttl 56, id 12095, offset 0, flags [DF], proto UDP (17), length 1428)
85.10.200.201.34849 > 216.52.148.x.53: 37166 notify+ [b2&3=0x2101] [56322a] [24571q] [60301n] [62716au][|domain]
0x0000: 4500 0594 2f3f 4000 3811 840d 550a c8c9 E…/?@.8…U…
0x0010: d834 9404 8821 0035 0580 8e1a 912e 2101 .4…!.5……!.
0x0020: 5ffb dc02 eb8d f4fc 333f 27b1 20da 7ab9 _…….3?’…z.
0x0030: 53c8 995c fe8d 5a04 e1f4 0c8c 9a94 c8e3 S..\..Z………
0x0040: e003 8171 5345 64a1 6206 244a f827 efed …qSEd.b.$J.’..
0x0050: a6a7 0894 a926 …..&
2023-07-23 17:51:01.574987 IP (tos 0x0, ttl 56, id 12121, offset 0, flags [DF], proto UDP (17), length 1428)
85.10.200.201.34849 > 216.52.148.x.53: 51816 updateD FormErr- [33764q][|domain]
0x0000: 4500 0594 2f59 4000 3811 83f3 550a c8c9 E…/Y@.8…U…
0x0010: d834 9404 8821 0035 0580 a315 ca68 d041 .4…!.5…..h.A
0x0020: 83e4 fc5b e934 88c3 4b14 fc0a e6bb a8c8 …[.4..K…….
0x0030: 8c86 cc74 80db 61f6 4bd7 d51c bc28 2f91 …t..a.K….(/.
0x0040: f324 c781 9052 8279 64bd 5fcb 7b06 dd23 .$…R.yd._.{..#
0x0050: 4f5e 859b 7d89 O^..}.
2023-07-23 17:51:01.614222 IP (tos 0x0, ttl 56, id 15472, offset 0, flags [DF], proto UDP (17), length 1428)
85.10.200.201.34849 > 216.52.148.x.53: 21154 updateA Resp11*-|$ [41821q][|domain]
0x0000: 4500 0594 3c70 4000 3811 76dc 550a c8c9 E…<p@.8.v.U…
0x0010: d834 9404 8821 0035 0580 5aa4 52a2 ce2b .4…!.5..Z.R..+
0x0020: a35d d83d 8407 85ef 8c7a 9a90 ff86 18ce .].=…..z……
0x0030: daef d231 4377 acf6 003d a1b5 357a 84bf …1Cw…=..5z..
0x0040: 20fe 8e19 3d84 0d8c 81e1 f830 7960 31ac ….=……0y`1.
0x0050: 21f4 20c2 34ac !…4.
2023-07-23 17:51:01.662579 IP (tos 0x0, ttl 56, id 19514, offset 0, flags [DF], proto UDP (17), length 1428)
85.10.200.201.34849 > 216.52.148.x.53: 49451 notify NXRRSet-$ [19955q][|domain]
0x0000: 4500 0594 4c3a 4000 3811 6712 550a c8c9 E…L:@.8.g.U…
0x0010: d834 9404 8821 0035 0580 64c7 c12b a168 .4…!.5..d..+.h
0x0020: 4df3 9e5a 4fec 549a 40da 409c 2a15 defd M..ZO.T.@.@.*…
0x0030: 4795 7750 923d 7c6d a778 74f7 2654 0efa G.wP.=|m.xt.&T..
0x0040: 8d3b 3f16 7504 239a d6e6 c6ce 4c34 e146 .;?.u.#…..L4.F
0x0050: 4e8c eda9 aa35 N….5
2023-07-23 17:51:01.666760 IP (tos 0x0, ttl 56, id 19852, offset 0, flags [DF], proto UDP (17), length 1428)
85.10.200.201.34849 > 216.52.148.x.53: 26992+% [b2&3=0x75d] [60856a] [7139q] [8623n] [2575au][|domain]
0x0000: 4500 0594 4d8c 4000 3811 65c0 550a c8c9 E…M.@.8.e.U…
0x0010: d834 9404 8821 0035 0580 faed 6970 075d .4…!.5….ip.]
0x0020: 1be3 edb8 21af 0a0f 77dd 6712 6a63 8574 ….!…w.g.jc.t
0x0030: daa3 a7a3 2863 8ef9 0b95 2ed5 f722 ef8a ….(c…….»..
0x0040: 03f9 c814 914f d59e 8d17 f23f 1e72 f9cc …..O…..?.r..
0x0050: 638a aa9f c0f7 c…..
(The final octet of our customer’s IP address is masked in the above output because some automatic parsers become confused when multiple IP addresses are included. The value of that octet is «4».)
Based on the size, number of samples, and timestamps of received packets from your host in our capture, we estimate that your host was sending 126 Mbps of attack traffic at the peak of this coordinated attack. The peak of the attack may have lasted only a few seconds. (Most traffic graphing systems show numbers that are averaged over 30s or 5m, and it may appear to have been less in such a system; but, our estimate is generally accurate as a minimum bound.)
-John
President
NFOservers.com
(We’re sending out so many of these notices, and seeing so many auto-responses, that we can’t go through this email inbox effectively. If you have follow-up questions, please contact us at noc@nfoe.net.)
