An IP address (188.190.7.111) 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

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.

2020-02-15 17:04:27.065530 IP (tos 0x0, ttl 54, id 2271, offset 0, flags [none], proto UDP (17), length 1052)
    188.190.7.111.36709 > 74.91.125.x.64062: UDP, length 1024
        0x0000:  4500 041c 08df 0000 3611 ec30 bcbe 076f  E.......6..0...o
        0x0010:  4a5b 7d39 8f65 fa3e 0408 4798 5fd0 92b2  J[}9.e.>..G._...
        0x0020:  9a7f 0503 6840 ecc8 6196 2025 b2aa 1401  ....h@..a..%....
        0x0030:  a5fc c529 f516 8083 7a0b 32a2 b464 d706  ...)....z.2..d..
        0x0040:  1f90 f100 4a19 4583 83bb 1eb1 d09b 510c  ....J.E.......Q.
        0x0050:  2d83                                     -.
2020-02-15 17:04:27.065636 IP (tos 0x0, ttl 54, id 56009, offset 0, flags [none], proto UDP (17), length 1052)
    188.190.7.111.50899 > 74.91.125.x.16952: UDP, length 1024
        0x0000:  4500 041c dac9 0000 3611 1a46 bcbe 076f  E.......6..F...o
        0x0010:  4a5b 7d39 c6d3 4238 0408 c434 11cc d9fa  J[}9..B8...4....
        0x0020:  8918 c031 948b 9215 4c69 5c13 7296 d127  ...1....Li\.r..'
        0x0030:  51c6 e416 3221 ab97 822c 4d67 1f44 84cc  Q...2!...,Mg.D..
        0x0040:  90c5 62fc 9fc9 0e32 60da 293c 46c5 63d2  ..b....2`.)<F.c.
        0x0050:  dfd4                                     ..
2020-02-15 17:04:27.071334 IP (tos 0x0, ttl 54, id 21219, offset 0, flags [none], proto UDP (17), length 1052)
    188.190.7.111.29382 > 74.91.125.x.22361: UDP, length 1024
        0x0000:  4500 041c 52e3 0000 3611 a22c bcbe 076f  E...R...6..,...o
        0x0010:  4a5b 7d39 72c6 5759 0408 3416 31f5 2abf  J[}9r.WY..4.1.*.
        0x0020:  f556 7c2e 1e91 78be 67ea 175c a91f 7cb4  .V|...x.g..\..|.
        0x0030:  2d3c 7b78 5da2 f102 b634 56e1 62fe 83b5  -<{x]....4V.b...
        0x0040:  ab26 b814 2b8d d49b 63e9 77cb 816e ad61  .&..+...c.w..n.a
        0x0050:  6191                                     a.
2020-02-15 17:04:27.084916 IP (tos 0x0, ttl 54, id 46332, offset 0, flags [none], proto UDP (17), length 1052)
    188.190.7.111.54927 > 74.91.125.x.41619: UDP, length 1024
        0x0000:  4500 041c b4fc 0000 3611 4013 bcbe 076f  E.......6.@....o
        0x0010:  4a5b 7d39 d68f a293 0408 9a3b d793 3364  J[}9.......;..3d
        0x0020:  b948 4894 d9e8 dc8d 43ce 4ca9 965d 1951  .HH.....C.L..].Q
        0x0030:  8cda c287 8d70 32ed be85 c322 9d99 adb9  .....p2...."....
        0x0040:  9e22 2a28 0e89 e256 1918 3268 f305 86bd  ."*(...V..2h....
        0x0050:  0ffe                                     ..
2020-02-15 17:04:27.088134 IP (tos 0x0, ttl 54, id 61400, offset 0, flags [none], proto UDP (17), length 1052)
    188.190.7.111.46126 > 74.91.125.x.32735: UDP, length 1024
        0x0000:  4500 041c efd8 0000 3611 0537 bcbe 076f  E.......6..7...o
        0x0010:  4a5b 7d39 b42e 7fdf 0408 d8ec 5b8f 3e65  J[}9........[.>e
        0x0020:  b305 8bf6 5827 8649 3080 6c2a 7196 b9bb  ....X'.I0.l*q...
        0x0030:  28ba b115 21e3 756d bf83 5623 ba93 2b54  (...!.um..V#..+T
        0x0040:  ed03 d3cc bd9d 7d0e b6ac a199 7b4a 1f91  ......}.....{J..
        0x0050:  deff                                     ..

(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 "57".)

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 at least 169 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.)