Skip to main content

Circumstantial, Your Honor!

I love legal shows and movies in which an impossible case is made or innocence proven against all odds. I especially enjoy courtroom scenes in which attorneys passionately stand up, bang on the table, and ask the judge to dismiss a piece of evidence as circumstantial: “Circumstantial, your honor!”

Working in the security log analysis business for over 10 years, I realize that much of our work is similar to that of a courtroom judge, who hears both sides of an argument, weighs which is more plausible and makes a ruling. Unfortunately for us, we don’t have the benefit of direct evidence where someone tells us about the adversary’s malicious plans and intent. All we can rely on is the circumstantial evidence in the form of the logs they leave behind.

Here’s how Wikipedia defines circumstantial evidence:

“Circumstantial evidence is evidence that relies on an inference to connect it to a conclusion of fact—like a fingerprint at the scene of a crime. By contrast, direct evidence supports the truth of an assertion directly—i.e., without need for any additional evidence or inference.”

Logs are, by nature, circumstantial evidence since they don’t say “the user is doing something bad,” rather, they say “the user logged on a machine[1]. The analyst, or the “judge”, has to decide if this is sufficient to claim that something malicious is happening.

The problem with circumstantial evidence is that most of the time there can be more than one explanation for an activity. Often these interpretations can range from completely benign to absolutely malicious. As Wikipedia goes on to say:

“On its own, circumstantial evidence allows for more than one explanation. Different pieces of circumstantial evidence may be required, so that each corroborates the conclusions drawn from the others. Together, they may more strongly support one particular inference over another. An explanation involving circumstantial evidence becomes more likely once alternative explanations have been ruled out.”

I am sure that if you’ve ever analyzed logs, this explanation will sit very well with you. Essentially, we are trying to corroborate conclusions drawn from different logs and contexts to build a more complete picture of what is happening. The second part of this process is also critical – we become more confident with our analysis after all other possible explanations have been ruled out. As long as other explanations exist we will always have conditional inference.

Consider, for example, a Windows OS log that says: User X on machine 1 is executing process C:\Windows\System32\wbem\WMIC.exe to access a service on machine 2.

Good or bad?

WMIC.exe is used for controlling Windows Management Instrumentation (WMI) from the command line and is part of the default programs in Windows. WMI is Microsoft’s tool for accessing system management information in an enterprise environment. It’s a very powerful tool that essentially allows control of a Windows machine. Using it from the command line on a remote machine would be a preferred hacking technique.

On the other hand, there are many legitimate reasons for using such a tool remotely.

Without corroborating this information with other evidence there is no was of knowing if the CISO should be alerted immediately, or if this case can be safely closed. You will have to know things such as whether this user ever accessed this, or any, machine in that manner? Who else has accessed machines in that manner, and how related are they to our user? What is the user’s role in the organization and is it typical for this role to be using these tools? What else has occurred with this machine and this user around the time of this event, are any of these things suspicious, and if so, can they be tied to this activity?

How about this one: User X is using process C:\Windows\System32\dkzalrt.exe to log onto host 1.

This can easily be overlooked considering user X has logged into this host many times, both locally and remotely. However, the process dkzalrt.exe is not part of the System32 by default, has never been used in the organization, and in fact, googling it returns no results. More suspicious now.

These inferences can change with more circumstantial evidence we collect. For example, the user may be a developer responsible for new secure authentication code, whose initials are DK.

You get the point.

So what can you do?

Exabeam is the only company that exists today that understands the circumstantial nature of the security logs, and built its product from the ground up to address it. We present the “evidence” in a way that clearly lays out the reason for “convicting” or “exonerating”, while bubbling up the most obvious and dangerous cases first. Exabeam instantly delivers the evidence that would take humans hundreds of man hours to compile. If the charge is being the best at what we do, then we are guilty as charged. Schedule a demo today.

 —————-

[1] One might claim that an alert from a security device such as host or network based intrusion detection system can be considered as direct evidence. While this is true to a certain extent, these products do not tell the full picture of the attack, but merely certain, narrow aspects of it. In addition, it is well known that these products tend to throw alerts aggressively, reducing the sensitivity of the analyst and thus creating false alarms.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Topics: SECURITY