Days of the Honeynet: Attacks, Tools, Incidents

By Anton Chuvakin, Ph.D., GCIA, GCIH 4/22/2003 16:07 WRITTEN: 2003 DISCLAIMER: Security is a rapidly changing field of human endeavor. Threats we face literally change every day; moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even though I hope that this document will be useful for to my readers, please keep in mind that is was possibly written years ago. Also, keep in mind that some of the URL might have gone 404, please Google around. Among other benefits, running a honeynet makes one acutely aware about "what is going on" out there. While placing a network IDS outside one's firewall might also provide a similar flood of alerts, a honeypot provides a unique prospective on what will be going on when a related server is compromised used by the intruders. As a result of our research, many gigabytes of network traffic dumps are piling up on the hard drives, databases are filling with alerts, rootkits and exploit-pack collections are growing. This paper is an attempt to informally summarize what was happening to our exposed Linux machine connected to the Internet. The moment is even more appropriate since we are now changing the platform of the victim machine.. Our Linux honeypot survived dozens, if not more, system compromises including several massive outbound denial-ofservice attacks (all blocked by the firewall!), major system vulnerability scanning and serving as an Internet Relay Chat (IRC) server for Romanian hackers - and other exciting stuff. I. Battleground: services and ports First, let us summarize the common exploits hurled at the exposed Linux machine. It won't likely be news to people who monitor activity outside their firewalls, but it may provide some insight into current security threats to others. Scans, "innocuous" connection attempts and various spam (on port TCP 25 and UDP 13x) are not included. a. RPC statd - the attack is SO ancient, that one might think that nobody will hope to find a vulnerable box with that flaw. After all, who in his right mind will be fielding (for example) Linux RedHat 6.0 when half a dozen RedHat releases have come out since that time. We are talking August 2000 - it was indeed during the last millennium. Heavy scanning for this vulnerability was going on all through 2001 and even parts of 2002. One might think that all machines with that hole are either secured by the owners or by the intruders, upgraded or taken offline. However, lots of "hopefuls" are still trying the long cemented "door". Thus, the log files continue to be peppered with the classic:

Mar 4 11:51:31 victim 29>Mar 4 11:51:31 rpc.statd[493]: gethostbyname error for ^X...^X...^Z...^Z...%8x%8x%8x%8x% 8x%8x%8x%8x%8x%62716x%hn%51859x%hn................................................ .................................................................................. .................................................................................. .................................................................................. .................................................................................. .................................................................................. .................................................................................. ....................../1..|Y.A^P.A^H...A^D.....^A.f...^B.Y^L.A^N..A^H^P.I^D.A^D^L. ^A.f...^D.f...^E0..A^D.f......1..?..

and snort continue spewing forth the good old:
Jan 24 20:46:41 bastion snort: [1:1282:1] RPC EXPLOIT statdx [Classification: Attempted Administrator Privilege Gain] [Priority: 1]: {UDP} ->

And here is how this attack looks to the anomaly-based Bro NIDS, recently deployed in our honeynet:
1047644757.152094 > bad_RPC_program 1047644757.152094 > bad_RPC

Bro detects a different stage of the same attack. b. WU-FTPD - this attack can also be categorized as "Stone Agey", but it is still very popular among the amateur attackers. It is this attack that led to those impressive statistics publicized by the Project Honeynet - default RedHat box will be "owned" within 3 days from being connected to the internet. An extremely popular choice, this attack is used in countless autorooters, exploit scanners and other "tools for beginners". Here is how the attack looks to snort:
Jan 26 20:37:16 bastion snort: [1:1378:7] FTP wu-ftp file completion attempt { [Classification: Misc Attack] [Priority: 2]: {TCP} -> Jan 26 20:37:16 bastion snort: [1:1622:5] FTP RNFR ././ attempt [Classification: Misc Attack] [Priority: 2]: {TCP} ->

and to Bro:
1048402337.496125 FTP_ExcessiveFilename > #94 excessive filename: 00000000000000000000000000000000..[494]..

c. IIS exploits - we have observed dozens of different Unicode strings and .ida requests aimed to hurt the Microsoft IIS web server. Starting from the classic one used by the worms in 2001 to the more obscure modern variant: Here is the excerpt of the HTTP protocol decode by Bro:
/scripts/..%2f../winnt/system32/cmd.exe?/c+dir /scripts/..%35c../winnt/system32/cmd.exe?/c+dir /scripts/..%5c %5c../winnt/system32/cmd.exe?/c+dir /scripts/..%5c../winnt/system32/cmd.exe?/c+dir /scripts/root.exe?/c+dir /scripts/..\xc0/../winnt/system32/cmd.exe?/c+dir /scripts/..\xc0\xaf../winnt/system32/cmd.exe?/c+dir /scripts/..\xc1\x1c../winnt/system32/cmd.exe?/c+dir /scripts/..\xc1\x9c../winnt/system32/cmd.exe?/c+dir /_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir /msadc/..%5c../..%5c../.. %5c/..\xc1\x1c../..\xc1\x1c../..\xc1\x1c. ./winnt/system32/cmd.exe?/c+dir /MSADC/root.exe?/c+dir /_vti_bin/..%5c../..%5c../.. %5c../winnt/system32/cmd.exe?/c+dir /default.ida? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%uc

bd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090 %u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a

It is obvious that those cannot affect the Linux Apache web server of the honeypot and are provided here only due to their extreme volume. It is interesting to note that some IP addresses receive much more than their share of such hits. This phenomenon is not explained yet. d. OpenSSL flaw that allows the non-root access is a very popular choice as of today. While not giving root, it seemingly helps the script kiddies to learn about local exploits. It is suspected that its popularity is in part due to readily available and reliable exploit openssl-too-open (...) Here is the log trace of the openssl hit in Apache errror_log:
[Mon Mar 3 06:40:48 2003] [error] mod_ssl: SSL handshake failed (server, client (OpenSSL library error follows) [Mon Mar 3 06:40:48 2003] [error] OpenSSL: error:1406908F:lib(20):func(105):reason(143)

And here is the snort message:
Feb 2 00:45:53 bastion snort: [1:1887:1] EXPERIMENTAL WEB-MISC OpenSSL Worm traffic [Classification: Web Application Attack] [Priority: 1]: {TCP} ->

e. MS-SQL Slammer, while being called a flash worm, is still knocking on the UDP 1434. The volume has subsided as most of the affected hosts are taken offline, butol Slammer is till there, slamming away at closed ports of the Linux honeypot. Here is what snort says upon seeing it:
Mar 10 22:01:11 bastion snort: [1:2003:2] MS-SQL Worm propagation attempt [Classification: Misc Attack] [Priority: 2]: {UDP} ->

f. Here are some other less frequent attacks that flash by. A number of hits against vulnerable PHP were observed. The attack did not succeed and was seen only once or twice:
Mar 10 14:57:15 bastion snort: [1:1425:6] WEB-PHP content-disposition [Classification: Web Application Attack] [Priority: 1]: {TCP} -> Mar 10 14:57:15 bastion snort: [1:1423:7] WEB-PHP content-disposition memchr overlfow [Classification: Web Application Attack] [Priority: 1]: {TCP} ->

g. What is not there? Old bind attacks (very popular in 1999) are gone, hopefully for good, and new ones (based on the recent Bind bigs) failed to materialize. SSH bugs are not actively exploited, while version surveying is observed pretty often. It is not clear why this is the case. Here is a summary of all events and attacks: The color indicates alarm severity. It resembles what is reported by Web attacks (80,443) "top the charts", and are followed by the recent MS-SQL hits (1434) and FTP (21) - the all time favorite. Proxy scans (1080, 3128,8080) are also very popular. Strangely, SNMP (161,162) is also in the picture, though appear to be just probes and not exploit attempts. II. Artifacts - exploits, rootkits and tools

Intruders who visit our friendly neighborhood honeynet, rarely come empty-handed. They bring all sorts of gifts, such as exploit scanners, autorooters, rootkits, DoS tools and other goodies. Adetailed analysis of some of the Linux rootkits we captured is provided here. Most of the captured kits are very simple, use only publicly available technology and carry all the signs of being created by unskilled people. They often corrupt the system and utilize such amazingly "stealthy" capabilities as using the root directory of the system to store their files or changing the root password ("owned means owned, right?") Exploits and automated exploitation tools, while seeming impressive, use very old attacks (such as those described above) and are not even attempting to hide their activities. Most of those tools are designed to scan huge pools of IP addresses for one or two vulnerabilities, manifesting the ultimate "opportunity hack" of going for the "lowhanging fruit". However, new and innovative tools do get brought in by the tide. For example, the covert channeling binary or the IPv6 tunnel tool were discovered by the Honeynet Project. III. Example Incidents Here are brief descriptions of several incidents that recently occurred in our honeynet. The classic WU-FTPD incident starts from an anonymous login to the FTP server. Then in a few minutes or hours the server is hit by the TESO "wurm" exploit. It has a recognizable signature of trying to create a directory 7350 (TESO). In a few seconds, intruder tries to get his rootkit from a drop site (often some free storage site or even a Yahoo account) which is then deployed. Most observed rootkits start a ssh daemon on high port as a main backdoor method. On the next session (which occurs within hours or even days), we often see him getting scanners and trying to exploit more machines. The more recent openssl incidents are more interesting since the attacker does not have root upon breaking into the system (such as, user "apache"). One might think that owning a system with no "root" access is useless, but we usually see active system use in these cases. Here are some of the things that such non-root attackers do on such compromised systems: 1."IRC till you drop" Installing an IRC bot or bouncer is a popular choice of such attackers. Several IRC channels dedicated entirely for communication of the servers compromised by a particular group were observed on several occasions. Running an IRC bot does not require additional privileges. 2."Local exploit bonanza" Throwing everything they have at the Holy Grail of root access seems common as well. Often, the attacker will try half a dozen different exploits trying to elevate his privileges from mere "apache" to "root". 3. "Evil daemon" A secure shell daemon can be launched by a non-root user on a high numbered port. This was observed in several cases. In some of these cases, the intruder accepted the fact that he will not have root. He then started to make his new home on the net more comfortable by adding a backdoor and some other tools in "hidden" (".. " and other non printable names are common) directories in /tmp or /var/tmp. 4. "Flood, flood, flood"

While spoofed DoS is more stealthy and harder to trace, many of the classic DoS attacks do not require root access. For example, ping floods and UDP floods can be initiated by non-root users. This capability is sometimes abused by the intruders, using the fact that even when the attack is traced the only found source would be a compromised machine with no logs present. 5. "More boxes!" Similar to a root-owning intruder, those with non-root shells may use the compromised system for vulnerability scanning and widespread exploitation. Many of the scanners, such as openssl autorooter, recently discovered by us, do not need root to operate, but is still capable of discovering and exploiting a massive (thousands and more) system within a short time period. Such large networks can be used for devastating denial of service attacks (for example, such as recently warned by CERT). Worms and other automated entities are also common. We observed many different OpenSSL worms (for their taxonomy, see this), including some with novel components such as Windows OpenSSL exploit, DoS agents, IRC bot deployment by the worm, automated local exploitation via ptrace bug, different backdoors, etc. Windows worms are also on the prowl. CodeReds, MS SQL and others are not gone. Their traces surface in the logs on the regular basis. They seem to be leading their own lives with ups and downs, sudden bursts of activity, and never seem to go away. Many other "fun things" are also hitting the shores of our honeynet. Among them are such beasts as the packets from, port 31337, various kinds of spam (email, MS RPC, web forms), a lot of various reconnaissance attempts (mostly scans and pings). Scans for proxies (1080,8080, 3128) are also extremely popular, as mentioned above. ABOUT THE AUTHOR: This is an updated author bio, added to the paper at the time of reposting in 2010. Dr. Anton Chuvakin ( is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books "Security Warrior" and "PCI Compliance" and a contributor to "Know Your Enemy II", "Information Security Management Handbook" and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list . His blog is one of the most popular in the industry. In addition, Anton teaches classes and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on the advisory boards of several security start-ups. Currently, Anton is developing his security consulting practice, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.

Sign up to vote on this title
UsefulNot useful