Home » Security Bloggers Network » When Worlds Collide

When Worlds Collide

by Alec Waters on November 8, 2013

ELSA is a powerful component of SecurityOnion; one can ~~waste~~ productively use many hours drilling through your logs. The more parsers and dashboards you write for your own specific log sources the more insightful it becomes and pretty soon you’ll be asking yourself questions you never knew you had.

Take the session below as an example:

This is Bro accounting for a TCP session, showing a local IP address (redacted) sending over 8MB of data to 92.232.36.19 on TCP port 25289. Something like this should raise an eyebrow or two and is certainly worthy of further investigation – why is a local machine having this kind of conversation? Can we rule out foul play? Or is there an innocent explanation? Deerstalkers on, sleuths…

The first thing we can do is find out some more about the remote IP address. You can’t trust rDNS and whois to be totally accurate (or truthful), but a quick whois and dig -x tells us that we’re dealing with what looks like a residential broadband IP address rather than a business (the rDNS lookup is cpc25-newt29-2-0-cust18.19-3.cable.virginm.net). If it were a business with whom we have a relationship there may be an easier answer, but at the moment it looks like our local IP address is talking with a computer in someone’s living room. We still don’t know what the traffic was, though. Exfiltration of Top Secret business plans, maybe?

Maybe we can get some answers by pivoting from ELSA into capME to get a transcript of the session:

Drat. The plot thickens! Our local IP address has sent over 8MB of data to a computer apparently in someone’s living room, and we can’t tell what it is because it’s quite possibly encrypted. We still can’t rule out a leak of our Top Secret plans! What if 92.232.36.19 is an innocent machine under the control of The Baddies who are using it to pillage all our stuff? Where’s my tinfoil hat?!

Unanswered questions bug me a great deal. Sometimes even NSM can lead you to a dead end. I can research 92.232.36.19 as much as I like by using ELSA et al to look for other log entries that reference it, or by going OSINT crazy, but in this instance I’m all out of clues. What I’d ideally like to be able to do is work out which process on the local IP address made the connection – perhaps this would solve the mystery.

Marching over to the local machine (EnCase dongle in hand) with the intent of seizing it and carrying out a full host examination probably isn’t the most productive use of time. The user of the machine will hate me for stopping them from working, the process will take a long time, and even then it might not answer my questions fully. Not to mention the fact that I don’t have an EnCase licence in the first place.

Enter Carbon Black. I’ll leave it as an exercise to the reader to peruse their website, but suffice to say running Cb on your systems is akin to running process monitor all the time on all your machines, centrally collecting things like process execution trees, file/registry modification attempts, network connections, etc. It’s basically carrying out host-forensic tasks all the time, capturing very volatile events that you may not be able to recover in retrospect.

Did I just say it collected network connections? I wonder if we can ask it about 92.232.36.19?

ELSA is a wonderfully extensible beast; amongst other things, you can write Plugins that can link to other systems to provide extra information based on ELSA searches. Carbon Black has a REST API and easily accessible search URLs – perhaps we can link ELSA and Cb together?

Happily, yes we can. We’ll get to the nuts and bolts of the plugin in a second, but the net result is something like this. By clicking on the “Info” link by our BRO_CONN log entry, we get a link into Carbon Black that will search on the dstip field:

Clicking on the Cb link will perform a search for the suspect IP address – provided our browser is logged in, we’ll see this:

Aha! It’s Spotify, which has a p2p-style protocol that makes use of “random” ports and encryption. According to the article, most of the music you listen to comes from other users’ machines – our mystery connection is likely the transfer of a song from one (local) Spotify user to another.

What we’re seeing above is a specific execution of Spotify, which means that all the events logged against it are those recorded at a specific time on a specific machine. Drilling down on the process, we can see:

…the process tree. We can see that explorer.exe started Spotify, and that Spotify itself has child processes. We can see that five other machines have the exact same version of Spotify on them, and that it’s a legitimately signed binary. If this were malware, being able to see at a glance how many other machines it’s executed on is a pretty handy thing. As it is, it’s not malware but we might like to speak to the users of the five machines in question if the use of Spotify represents a policy violation.

Searching the 3502 logged events for our suspect IP address:

…there it is. Drilling down onto the binary itself, we can see:

Note the convenient link to VirusTotal, and the Download link which you can use to investigate suspected malware in a sandbox.

To be able to go straight from a network-derived indicator to the process that caused it seems to me to be a pretty powerful ability!

Putting it into practice is fairly straightforward. Step one is to subclass the “Info” Perl class by creating /opt/elsa/web/lib/Info/Cb.pm as follows:

package Info::Cb;
use Moose;
use Data::Dumper;
extends 'Info';

sub BUILD {
    my $self = shift;
    if ($self-&gt;conf-&gt;get('info/cb/url_templates')){
        foreach my $template (@{ $self-&gt;conf-&gt;get('info/cb/url_templates') } ){
            push @{ $self-&gt;urls }, sprintf($template, $self-&gt;data-&gt;{dstip});
        }
    }
}

1;

The code above references configuration entries from /etc/elsa_web.conf. Add the following under “info” alongside the entries for “snort”, “url” and “windows”, altering the URL as appropriate for your Cb installation:

"cb": {
   "url_templates": [ "https://carbonblack/#search/cb.urlver=1&amp;q=%s" ]
 }

Finally, we need to tell ELSA which classes to apply the plugin to. Add the following under “plugins”:

"BRO_CONN": "Info::Cb"

That’s the lot. You might need to restart Apache, but once done you should be able to click “Info” on a BRO_CONN result and have a properly populated link into Cb, searching on BRO_CONN.dstip.

This is my first attempt to link ELSA and Cb, and it’s quite a basic one. ELSA also supports transforms to which results can be “piped” – examples that ship with the product include whois, dnsdb and cif. A Cb transform could perform more flexible queries, enriching an ELSA result set with supplementary information from Cb. Stay tuned; I’ll post again if I come up with something useful!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at [email protected]