SotM #30

Write-up by Anton Chuvakin, netForensics Honeynet
version 0.2

Contents

• Background
• Answers
• Conclusion
  

Background:

This section gives some background on what was really going on. Considering that we have access to the actual honeynet system as well as full packet captures, and not just the firewall logs, this write-up should be read as the correct answer and possibly not like the best approach to the given task.

1. Here are a few words on the honeynet network architecture.
   
• The address ending in 67 is an actual IP address of the only honeynet machine - a Linux RedHat 7.x system.
  
• The addresses 69-73, 75, 80-85, 87, 89, 90, 95, 100, 105, 110, 115, 120, 125 are virtual IP aliases (raised via /sbin/ifconfig eth0:X) command
  
• The 65 is a router. There is an iptables GenII honeynet bridge  between the router and the honeynet machine
2. Honeynet machines runs some of the following services: HTTP, HTTPS, FTP, SMB and others.
3. IPtables on a bridge is set to block outbound connections after a pre-set limit and allow all inbound connections
4. On Feb 8, the honeynet was compromised and destroyed by the attackers. Due to the high volume of outbound traffic that followed as a result of a compromise, the access to honeynet was automatically shutdown. Thus, the change in logs from regular INBOUND messages to INBLOCK on Feb 10 13:50:22
5. Overall, honeynet logs contain several major traffic types:
• INBOUND ICMP, TCP, UDP, Other: indicates a connection attempt from the Internet to the honeynet logged and allowed by the bridge
  
• OUTG CONN TCP, UDP: indicates a connection attempt from the honeynet to the Internet logged and allowed by the bridge
• Drop TCP, UDP after X attempts: indicates a connection attempt from the honeynet to the Internet logged and blocked by the bridge
• Legal DNS: indicates a connection attempt from the honeynet to one of the few allowed DNS servers
  
• Legal Broadcast: indicates a broadcast attempt from the honeynet logged and allowed by the bridge
6. Tools used for our analysis include netForensics SIM, which handles all the data flowing from the honeypot from various sensors, such as bridge firewall and multiple IDS sensors.
   

Q/A:
Summary

1. Q1
2. Q2
3. Q3
4. Q4
5. Q5
6. Q6
7. Q7
8. Q8
9. Q9
10. Q10
    

Details

1. What are the high-level trends in connectivity to/from the honeynet?
• Daily message count:
  
• Protocol dynamics:
  
• TCP:
• UDP:
  
• ICMP:
  
2. What possible evidence of malware is there?
• We can track evidence of malware by using a well-known ports utilized by malware, provided a large message counts suggests a widespread malware and the ports is not used for a known legitimate application. For example, 3127 TCP (MyDoom) is the cleanest example of such trend. Also, we can look at the inbound ICMP traffic and recognize some of it as Nachi worm. Other classic malware signatures include ports 1434 (Slammer) and some others below.
  
• MyDoom (TCP 3127):
  
• Kuang (TCP 17300):
• Dameware (TCP 6129):
  
• Slammer (UDP 1434):
3. Most of the honeynet noise is related to recon activity or various probes. Firewall logs are full of traces of such activity. Examples include:
• Host sweeps: if a source touches all 24 of the honeynet IP addresses on one or multiple ports (or via ICMP), we classify it as a sweep. The easier way to detect sweeps is to look for multi-host access patterns from a single source
  
• Port scans (discussed in detail in the next item)
• Open shares hunting: a large set of Windows TCP-UDP 135-139 and 445 accesses is likely related to looking for Windows machines potentially with opn shares. Some malware is known to do that automatically as well.
  
• Proxy hunting: accesses to ports 8080 and 3128 (very common in the logs) indicating looking for open (allowing access from the Internet) proxies (such as WinGate or Squid). Such proxies are used to launded connection to sites as well as by spammers.
  
• Trojan hunting: accesses to the above malware ports (such as TCP 6129, 3127 and many others) often indicate the attackers looking for machines infected by other attackers. Some trojans use default usernames/passwords (or even offer no authentication) and are harvested by lazy attackers for further abuse.
  
• Relay hunting: mail relay check for spammers likely accounts for most of the SMTP TCP 25 accesses
  
• Warez sites hunting: looking for anonymous misconfigured FTP servers to store warez likely accounts for most of the FTP TCP 21 accesses (trend below): 
  
4. The honeynet data pool has a large set of scan traces
• Simple scan pattern recognition is a task that is easy to perform using a relational database. For example, we look for single source touching a high number of the honeynet machines and then focus on the details of such access.  That allows us to cover sequential (touches all hosts in order on multiple or even all ports), horizontal (touches all hosts in order on a single port) or even random (runs a sequential or horizontal scans in random order of the destination hosts) scans.
  
• Slow scans are much harded to look for. We look for one sources touching multiple destinations or multiple ports on the same destination. Such events are indeed present in the data sample. Some events of that sort are downrigh weird, such as this one:
  
• Scan tools are harder to identify from  just a firewall logs. Tools do have signatures, that become apparent from the full packet dumps or at least the IDS logs. However, the proxy scan pattern (TCP 80-3128-8080) seems to be occuring very often to indicate a common tool to hunt for proxies
  
5. Other noise
   
• NetBIOS spam: most of the port UDP 445 activity is MSN Messenger spam. While a part of UDP 445 is looking for various Windows vulnerabilities, the majority is messager spam.
  
• FTP activity: while one can classify such activity as probing,
  
• Telnet and SSH access: a small but significant percentage of the data sample is attempts to access various remote services. Telnet TCP 23 and SSH TCP 22 are such examples
  
6. Anomalies
• Private addresses: an occurence of 10.x and 192.168.x addresses reserved by the RFC 1918 is an obvious anomaly.
  
• 127.0.0.1: similarly, a lot of 127.0.0.1 sources are anomalous and are known to originate due to Blaster workaround implmented by some companies
  
• Muticasts: OUTG OTHER connections from the honeynet are due to some system software misbehaving on the machine during the boot phase
• Obscure port accesses:  in addition to common ports we see many probes for high ports (such as 1318, 1558 and other seemingly random numbners all the way to 65535). It is not clear what such probes are trying to accomplish as such ports do not have common uses and each port is touched a small number of times
  
7. The honeypot was indeed compromised, as we hinted in the challenge description. The main clue is OUTBOUND FTP and HTTP connections (not ident TCP 113 or DNS UDP 53)
• Compromise activity summary:
• Attack over SSL -a large number of inbound connection to port TCP 443 from 66.60.166.84 - on Feb 7 and 8
  
• Downloads - outbound connections to various sites on TCP 80 and TCP 21 - by the attacker on Feb 8
  
8. If such logs are obtained from a production system, lots of different factors will contribute to threat prioritization. Among them are:
• Open ports and running services
  
• System vulnerabilities
  
• Firewall policy
  
• In general, we should consider the higher threat from:
  
• Top event producers (sources with the highest event sources):
  
• Top scanners and sweepers (sources that touched maximum number of ports and hosts):
  
• Obviously, the IP address that exploited the honeyport should be considerdd a major threat as well
  
9. Some honeypot IP addresses (still the same system!) were touched more than others. This largely remains a mystery. The only sensible explanation is that some sort of inheritance from previous IP owners is takinhg place. IDS alerts display a similar picture: a wildly different attack types and counts are thrown at different IP addresses in close range.
   
• Reliable open port discovery is not likely from the available data since IPTables bridge didn't log the response to commnucation. While the incoming SYN packets are always recorded, the resulting ACK (for open port) or RST (for closed) is not. However, a very rough estimate is possible
  
10. Some data metrics are shown below
    
• Selected top sources

  SOURCE IP	EVENT COUNT
  66.60.166.84	21829
  66.186.83.178	10217
  63.13.135.27	8121
  63.123.70.166	7281
  63.125.10.7	6932
  127.0.0.1	6401
  63.123.38.103	4000
  63.126.133.117	2801
  67.123.234.132	2351
  63.126.190.227	2240
  194.128.177.225	1973
  61.48.11.170	1820

• Top ports (any protocol)
  

  DESTINATION PORT	EVENT COUNT	NOTE
  135	87122	Windows
  3127	28854	MyDoom
  445	28301	Windows
  443	26478	HTTPS
  53	18158	DNS
  80	10392	HTTP
  137	6799	Windows
  1434	6000	MS SQL
  139	5262	Windows
  113	3720	identd
  6129	3469	Dameware
  901	3266	Trojan
  1433	2493	MS SQL
  17300	2095	Kuang
  1026	1938	Windows
  4899	1402	???
  21	1119	FTP
  1080	746	Proxy
  27374	588	Subseven
  23	408	Telnet

• TCP activity by hour of the day:
  
• ICMP by time of the day:
  

Conclusion:
This challenge proves that firewall logs are a great untapped source for information about intrusions. However, the ways to analyze the data need to be a bit more sophisticated than those used for IDS payload analysis due to high volume and low content of useful actionable information in firewall logs.

---

Anton Chuvakin
netForensics Honeynet
Honeynet Research Alliance
04/13/2004