On The Virtues Of Log Checking

You can catch flies with honey, but you can catch more honeys bein’ fly.

Keegan Large

Like roadkill, you should always use every part of the honeypot to glean some valuable information about your attackers. In doing so, you might learn something in addition to what you can found in the binaries alone. In this week’s brokesec, we talk about that concept and how to squeeze some juice out of your logs, in particular.

0.0 Logs

In Dionaea, there are a couple different places we can go to find something that looks and acts enough like logging to get some value out of them. The ways that we will use these logs are slightly different though. In one set of logs, we have broader session information (bistreams). In the other, we have much more detailed logging that will be a little bit better for us to search on.

I know I’ve made it sound like binaries are the end all be all of honeypotting in past blogposts. Ignore that. It’s still kind of true, because that’s what I usually want to get out of my pots. But we can also get a lot of the goods out of our logging.

So what can we get out of the logs? Well, for one, we can get more binaries. That’s right! you thought you could just sit back and collect things that fall into your lap? Well sure, you could do that if you’re a lazy yokel without any scruples. But if you want to see some metadata on attack TTPs (Tools Techniques & Procedures) there are ways we can find that goodness in the logs.

So let’s dive right in and learn about these puppies;

0.1 Bistreams

Located in <install dir>/dionaea/var/lib/dionaea/bistreams, bistreams are more or less a record of the sessions that touch your honeypot services. The logs are then stored with a set of information about what occurred during the session and with who it occurred with. Now I know what you’re thinking, “yeah idiot, that’s what logs are.” You’re not wrong. But bistreams are different than the kinds of logs you might expect to see in a standard linux log file. Bistreams are stored like this:

If you’re observant (and I know you aren’t) the bistreams are stored in directories marked by day. Neato. So what do we see when we go into one of the directories and see the flood of poo inside?

The format of the bistreams are pretty self explanatory, but I will point out that what’s beneath the hastily scribbled out blackness are the IP addresses of my honeypot, and the machine contacting the honeypot. When we open the bistream, we notice that the format is also a bit different that we’re used to for a traditional logfile:

In my opinion, these logs are turboshit. You could translate the escaped hex out of your bistreams. I didn’t because I’m too lame, but there’s probably some value in them that I haven’t fully realized yet. So let’s examine another set of logs that might be a bit more useful in getting them binaries.

0.2 Dionaea.log

When I do log analysis on my pots, I much prefer to use dionaea.log (located at <install_location>/dionaea/var/log/dionaea/) . It’s a bit easier for me to search on without having to think too hard about what I’m doing, which is great for my lazy ass.

What my logs look like when attackers drop dem wannacries

1.0 Grep Yo Logs

So run your grep command (in my case, I’m running ‘grep curl dionaea.log‘ [blow my FUC*ING mind rite??] in the log directory) and this is what comes out:

Look at the attention whore circles to understand the value of checking logs for malware. What’s happening here is an attacker has attempted to force the pot to download a file (in this case a file called ‘DNS2.exe‘) off a share at 58.218.67.78 port 80. Why do we care about this? That’s the malware, bb.

2.0 Techniques

If all you ever do as a researcher is use the same techniques to check the same logs every day, there’s no chance you’re going to find an interesting new technique being used against your honeypot. So from time to time, read the logs in detail and see if there’s something else untoward happening.

So what we want to do when we comb through the logs to find new malware sources is grep for native download methods. Why do we do this? Because forcing a remote machine to download something from somewhere else is a classic “living off the land” technique. If you grep through dionaea.log for ‘wget’ or ‘curl’ then there’s a good chance you’ll see evidence of an attacker trying some funny business.

2.1 wget & curl

Understanding what’s happening with wget and curl in your logs might be a little confusing if your eyes haven’t adjusted to the light of security logs, but the technique happening here is simple. The attacker is using SQL injection to drop a native linux command to download a file from a remote system, which is then typically followed by a command to execute, and/or sometimes change the permissions on the file.

What we see with wget and curl are the “low hanging fruits” of native command use being leveraged for baddie bad uses, which is why they’re so easy to find. Techniques that use more unconventional approaches to file download and injection will be a bit harder to spot, but there should be logging to cover even the weirder stuff.

2.2 Certutil

One thing I found recently is an attempt by attackers to use a native tool called certutil to download a malicious file from a remote host. Certutil’s real purpose is to download and view certificate information, but in the wrong hands pointed at a server over yonder, you can pull down whatever you want to with it. It’s true! See?

It’s a clever technique that doesn’t get used often, but when it does get used, probably works pretty reliably.

3.0 Take Aways

We’ve pried open the lid and found out a bit about what attackers tend to do day-to-day against unprotected servers and seen what we can expect from our own logging. It’s easy to forget or get lazy with log checking, but the logs have a great deal of detail in them. So don’t neglect your logs! You never know what you might find.