To most administrators, analyzing the collected data is the best reason for running and managing a honeypot. The honeypot is a means to an end. Each forensic analysis is its own “police investigation,” with puzzles and clues. Depending on how you conduct your analysis, you can either look like a seasoned pro or a bumbling Inspector Clouseau.
This chapter will discuss how to analyze honeypot data, covering a range of tools and techniques. It also includes examples of the analysis of two real-life honeypot systems, to demonstrate the various methods.
Why should you bother analyzing the honeypot data? Isn’t it enough to simply scan the log files, note the events that seem interesting, make some quick conclusions, and react rapidly? Well, that’s one way of looking at it, and if you are operating a honeypot for the sole purpose of acting as an early warning system (EWS) for your network, that may be the best first approach.
An EWS honeypot is placed inside your network to warn you of hackers and malware that go through your other defenses. It should alert the administrator to any traffic it receives. Since an EWS’s primary purpose is early warning, rapid response is a natural conclusion. Learn about the hacker or malware, stop it, and then close the hole that allowed it into your network in the first place. But even a rapid response requires a more sophisticated approach.
Here are a few questions to ask yourself before the analysis:
What is the primary purpose of the honeypot?
What are you trying to protect?
Are you interested in any attacks, or just ones that could be successful?
Are you interested in learning how the hacker or malware was initially successful?
Are you interested in identifying the hacker or origination point of the malware?
Are you interested in what the hacker or malware did (or wanted to do) after the initial exploit gained entrance to the honeypot?
Are you interested in what tools, techniques, or mechanisms were used?
EWS honeypot administrators are more concerned about how the initial exploit happened than what the hacker or malware did after the attack. Administrators of high-interaction honeypots are more interested in what the hacker did after the initial exploit. By providing a rich content environment, you give hackers a place to upload and download files, and practice their craft.
Is the honeypot trying to protect specific computer assets, or is it designed to guard the whole network? If you’re interested in protecting just specific assets, then attempts or attacks that would be successful only against other assets aren’t as relevant. For example, if you are trying to protect web servers only, your honeypot should mimic a production web server.
If you use an EWS honeypot, then you want to close the hole that allowed the hacker or malware to be successful in the first place. A quick forensic solution is to locate the destination IP address of the attack and investigate that asset. For example, if an Internet-scanning worm begins to probe the honeypot from another local machine, investigate the originating local machine. It’s the one with the weakness. How did the worm enter the system: through e-mail, an open port, a file attachment, or a malicious HTML link? What defenses did the hacker or malware bypass in order to be successful? How can it (or they) be stopped? Are more computers on the network infected or exploited? In order to answer the last question, you’ll need to do an IP address distribution analysis (covered in the “Analyzing Network Traffic” section later in this chapter). With an EWS honeypot, you’ll discover the hole that allowed the malware or hacker to gain entrance in the first place, close the hole, and then wait again.
The rest of this chapter will assume that you are interested in more than just closing the hole that allowed the malware or hacker to thrive. It will assume that you want to learn exactly how the exploit happened, and even more important, what happened after that.