Project HoneyNet Scan of the Month #17 (July, 2001)
Analysis by Ted Hale ted@tni.net
Challenge: To review and analyze a month's worth of data collected by a Honeynet.
To perform the analysis of the snort log I used a text editor to break the log into separate "events" by
searching for unique source IP addresses. Then I printed the result and made notes as I read the listing.
(While sitting on a plane waiting for an opening into LGA :-) The results, with explanations and links
for further info may be found here: LogAnalysis.html
1. What trends did you identify?
A total of 49 unique events were identified in the log.
Some events fall into multiple categories, so the percentages will add up to over 100%.
| Event |
# occurrences |
% of total events |
| portmap scan |
14 |
29% |
| Port Scan (FTP) |
15 |
30% |
| Port Scan (Telnet) |
6 |
12% |
| CGI/phf attack |
3 |
6% |
| DNS probe |
2 |
4% |
| Port Scan (WinGate) |
1 |
2% |
| Port Scan (PassGo) |
1 |
2% |
| Port Scan (Web) |
1 |
2% |
| Port Scan (unknown) |
7 |
14% |
| Ping |
1 |
2% |
| Portmap Exploit |
2 |
4% |
| FTP Exploit |
1 |
2% |
The portmap and FTP services appear to be of the greatest interest.
This makes sense because there are well known exploits against these services.
2. What does this activity tell us about the blackhat community?
The blackhat community is aggressively searching for exploitable systems.
The timing of several of these attacks indicates that an automated scan and exploit system is in use.
Programs of this type have been covered in previous Scan of the Month challenges.
3. What if anything happened in the firewall and IDS logs that gave us a clue of what was coming?
Could any of the attacks been predicted ahead of time.
If so, how?
Port scanning and portmap queries are frequently a prelude to attack on the services identified.
The remote exploit on Nov. 4 was preceded by several portmap requests on Nov. 3.
The remote exploit on Nov. 7 was preceded by several portmap requests on Nov. 6.
The FTP exploit on Nov. 30 was preceded by many FTP port scans in the previous days.
Guardian is a system that works with snort and uses ipchain rules to deny the attacker further access.
Use of this type system is highly recommended.
4. What data did you find more valuable, the Snort alerts or the firewall logs of unique scans? Why?
The snort logs were, by far, more valuable, since they contained far more detailed information.
The primary use I found for the firewall log was to identify the port targeted by a port scan.
This was needed because the port scan module in snort doesn't show which ports were scanned.
5. What lesson did you learn from this?
I learned that if I were to analyze logs like this frequently (especially large logs) I would want to have some perl
scripts to do the majority of the work.
There seem to be some good starting points to be found on the snort web site, but I haven't looked at them yet.
6. How long did this challenge take you?
1 hour to analyze the log.
2 hours to format and annotate the log file (see link at top)
1 hour to write this report.
TOTAL - 4 hours
Bonus Question:
Both the Snort alerts and the inbound firewall logs missed a successful attack.
The only reason the Honeynet Project detected this successful attack was because the
compromised system attempted an outbound connection (by definition this means a system was compromised).
The Honeynet Project did a writeup on this incident, can you identify the attack and why the
Honeynet failed to alert to the attack (though the attack was captured).
Hint: the attack is written up and posted somewhere on our site.
You may have stumped me on this one.
I never found any outbound connection in the logs.
At the risk of looking foolish, I will make a guess.
You mention that you're not logging netbios scans.
If you were attacked by a Windows worm (as discussed in SOM #7) then the traffic related to it would not be logged.
So my guess is that you were hit by the "Win32.Bymer Worm" or something similar.