Closing the loop

I am working with honeypots for some time now, and every now and then I get questions like “How are honeypots going to protect my network?” At first I would say “They won’t”.

So, then what’s the use installing and maintaining one? Two major reasons:

They can help you to understand how malware works and, by understanding that, you can justify investments in defensive measures to your management.

They do deliver more results than knowledge alone. They actually catch stuff and stuff caught by them can be used as input for the systems which are installed as the defensive line.

An example

I’ve written before about theDionaeahoneypot (made by Markus Koetter). I’ve also talked about it invariouspodcasts. It emulates known Microsoft OS weaknesses. By “playing along” with the offered malware, one can actually obtain a copy from the attacking malware, because Dionaea logs everything and saves everything it gets chucked at.

So, you have a live sample caught from the wires using the dionaea honeypot. Now what? First of all,be careful with it. It islive malwareafter all. So do take protective measures.

NEVER work in the production environment.

Use Airgaps whenever possible.

Use virtual environments whenever possible. (yes, I know there’s malware out there which specifically looks if it’s running in a virtual environment to prevent detection. I’m still trying to figure out how to get at those without running on bare iron.)

By editing the dionaea.conf file (/opt/dionaea/etc/dionaea/) Dionaea gan be directed to submit the malware automatically to different analysis sites like, for instance,AnubisorCWsandbox. And when you subscribe toVirustotalfor an account, you get your own identifying key. Putting that key in dionaea.conf file will upload the malware files to Virustotal for antivirus vendor detection. There are also some other good documented API’s for automated uploads and analysis to be used.

A realization

The files saved by the Dionaea honeypot are malware. They don't hit the honeypot by accident, one can be sure about that because the Dionaea system doesn’t do anything useful for any person. So, as stated above: any and all bitstreams picked up by Dionaea is either malware or junk. Junk gets chucked out, malware gets saved. But with all the variants of malware (usuallype32files) and the measures taken to obfuscate them (e.g. Packing), it could be that only one or two AV vendors registered at Virustotal actually recognise the files as potential malware.

To get an idea, a real live VirusTotal example:

And after two days:

File name: app.exe

Submission date: 2011-02-15 13:42:07 (UTC)

Current status: finished

Result: 1 /43 (2.3%)

File name: winfixer.exe

Submission date: 2011-02-17 16:02:45 (UTC)

Current status: finished

Result: 25 /43 (58.1%)

As you can see it took two whole days for the malware to be detected by 25 out of 43 AV vendors. The MD5 checksum for the malware is ca86f875c2a85f72a315e61bb784a91c so you can look it up.

It is good practise to use more than just one AV product. But even if you use more than one, there’s always a timegap in which malware stays under the radar, leaving your infrastructure vulnerable for that particular nasty piece of code. Let’s call this code “0day Malware”. Malware which is out there, but isn’t recognized (yet).

Here, Dionaea is used for both the catching of the malware and the analysis (Artifact Analysis). Having the malware at hand doesn’t help you with Vulnerability Management, yet. It also doesn’t help you with the Protect Infrastructure bit, or the Detection of Events. That’s what the AV is for, right?

But, what if one not only has a piece of malware at hand, but actually feeds it back into the defensive mechanisms already in place? What if that nasty code can be fed to the AV?

Closing the loop

While an interesting question in and of itself, one usually hears a standard response: “That’s why you feed it to VirusTotal. That’s where the AV vendors get their signal from that something new has been detected”. True though it might be, we still see a timegap between the moment a piece of malware is found and the time it’s recognized by AV products. Then there’s a timegap between the actual recognition and the update, delivered by said AV vendor.

When one looks at aforementioned processes, described by CERT/CC, one can see it’s possible to create a feedback-loop. The outcome of the process can be fed back into itself.

In this particular case, the malware found by Dionaea (in the Artifact Analysis stage) can be fed back at two stages:

By updating the AV products already in place. This should be done even without a security organization in place. Just common knowledge and regular management. This has a potential timegap though.

By declaring the unknowns being Malware (which it has to be, considering it’s dropped on a Honeypot, remember?) and feeding said malware into the AV products by a custom process.

This effectively closes the loop between signalling the malware and the AV vendor's update.

A Possibility

The free AVClamAVcomes with a interesting tool called “Sigtool” wich allows you to generate your own signatures. The easiest way to create signatures for ClamAV is to use MD5 checksums. However this method can be only used against static malware. To create a signature for test.exe use the --md5 option of sigtool:

That’s it! The signature is ready for use. Copy the .hdb file to the location (in my case /var/lib/clamav/) where the main.cvd and daily.cvd folder and test.exe will be recognised and blocked.

Clamscan will produce output like this:

clamscan test.exe

test.exe: test.exe FOUND

----------- SCAN SUMMARY -----------

Known viruses: 1

Scanned directories: 0

Engine version: 0.92.1

Scanned files: 1

Infected files: 1

Data scanned: 0.02 MB

Time: 0.024 sec (0 m 0 s)

ClamAV now detects unknown malware!

ClamAV is also known for its ability to scan email for malware. By using this tool you can effectively protect your infrastructure from 0day Malware. Of course, there are more ways and methods to generate your own signatures. These methods are well described in the Sigtool documentation.

Summary

So, in this case I used Dionaea results, combined with the sigtool from ClamAV to take extra protective measures. Even if major AV vendors don't detect the malware (yet), my system gets nervous anyway and raises the alarm. I’ve closed the loop in my processes and improved the defense of my infrastructure.

Honeypots are not designed to protect, it's designed to fail and get attacked, YOUR actions are the ones that gonna protect the system.

Using the malware samples the honeypot collected to generate a signature then feed that to the AV will work against most malware out there.

Another thing i imagine doing is reversing that piece of 0day-malware and making sure the payload it has is obsolete or has a patch somewhere otherwise there is a still a risk of a worm using a 0day-vulnerability, you might be able to block that specific binary but you still have a door open.

The way I look at it: Basically everything which generates some form of checksum or identifiable string can be used to feed in-house AV. So your pdf-analyzer should work, Kamerazukleber. Keep us posted when you have it working.

This is really a great article! I was thinking about doing something similar but not with a honeypot but with a pdf-analyzer like pdf-parser.py (http://blog.didierstevens.com/programs/pdf-tools/). I think there are some more tools out there, that could be used for such an approach. And have you already checked out Razorback? If I understand this correctly, the idea of Razorback is to have some kind of framework to tie all this together, right.