An IP address (94.130.120.11) 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: http://www.coresecurity.com/advisories/hikvision-ip-cameras-multiple-vulnerabilities)
— 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 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.
2021-06-19 19:06:49.077035 IP (tos 0x0, ttl 55, id 22856, offset 0, flags [DF], proto UDP (17), length 1428)
94.130.120.11.56890 > 216.52.148.x.15588: UDP, length 1400
0x0000: 4500 0594 5948 4000 3711 a24a 5e82 780b E…YH@.7..J^.x.
0x0010: d834 9404 de3a 3ce4 0580 fb03 7eb7 af06 .4…:<…..~…
0x0020: 35a3 1d5e 494b 784d cba8 c94e 2bf2 a635 5..^IKxM…N+..5
0x0030: a1fb 1186 29ca bc09 25b4 300a e228 0508 ….)…%.0..(..
0x0040: b016 c001 2379 c2ee 4269 dc61 a31f bf40 ….#y..Bi.a…@
0x0050: 92f4 cb41 e996 …A..
2021-06-19 19:06:49.093967 IP (tos 0x0, ttl 55, id 25536, offset 0, flags [DF], proto UDP (17), length 1428)
94.130.120.11.56890 > 216.52.148.x.15588: UDP, length 1400
0x0000: 4500 0594 63c0 4000 3711 97d2 5e82 780b E…c.@.7…^.x.
0x0010: d834 9404 de3a 3ce4 0580 7ea4 54fe 238c .4…:<…~.T.#.
0x0020: 8067 9025 7fb7 10c3 cf6d 3901 e2e2 7b92 .g.%…..m9…{.
0x0030: 4a3b 7134 f4d9 9c72 7d95 01b8 6d1c 20f5 J;q4…r}…m…
0x0040: e8c2 3648 63e1 f1dc fd2d ef68 f997 d99d ..6Hc….-.h….
0x0050: 2827 0663 d228 (‘.c.(
2021-06-19 19:06:49.094904 IP (tos 0x0, ttl 55, id 25774, offset 0, flags [DF], proto UDP (17), length 1428)
94.130.120.11.56890 > 216.52.148.x.15588: UDP, length 1400
0x0000: 4500 0594 64ae 4000 3711 96e4 5e82 780b E…d.@.7…^.x.
0x0010: d834 9404 de3a 3ce4 0580 c158 4704 9655 .4…:<….XG..U
0x0020: 9c12 8eca 0a7b 3983 490f 5a0f d986 0bea …..{9.I.Z…..
0x0030: f673 ab50 c2b3 0218 ccd7 fdc7 a4bc 7671 .s.P……….vq
0x0040: bf45 497a 9775 d877 178f b25e f98b e59a .EIz.u.w…^….
0x0050: a741 b1aa abed .A….
2021-06-19 19:06:49.126108 IP (tos 0x0, ttl 55, id 29205, offset 0, flags [DF], proto UDP (17), length 1428)
94.130.120.11.56890 > 216.52.148.x.15588: UDP, length 1400
0x0000: 4500 0594 7215 4000 3711 897d 5e82 780b E…r.@.7..}^.x.
0x0010: d834 9404 de3a 3ce4 0580 94b3 ccec 4a83 .4…:<…….J.
0x0020: d22a 2d70 45d6 d524 129d 89b7 a32b 7163 .*-pE..$…..+qc
0x0030: a5e6 137a 5c70 fef0 5c02 640b a01c a2e1 …z\p..\.d…..
0x0040: ffe8 6104 bf04 1e07 e290 432c d6ce f5dd ..a…….C,….
0x0050: 87e3 d8d6 1f3e …..>
2021-06-19 19:06:49.143839 IP (tos 0x0, ttl 55, id 32016, offset 0, flags [DF], proto UDP (17), length 1428)
94.130.120.11.56890 > 216.52.148.x.15588: UDP, length 1400
0x0000: 4500 0594 7d10 4000 3711 7e82 5e82 780b E…}.@.7.~.^.x.
0x0010: d834 9404 de3a 3ce4 0580 e82e 3fd6 5ebb .4…:<…..?.^.
0x0020: 6355 2089 0edb 4409 f619 3bd1 c0c2 999c cU….D…;…..
0x0030: 7d17 9917 2b22 2a38 7178 d731 4933 0a63 }…+»*8qx.1I3.c
0x0040: aae2 f7bc 65b4 a5d5 504a 3b5f 85aa 996d ….e…PJ;_…m
0x0050: 2ef7 786e 1860 ..xn.`
(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 171 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.)
