Is it a Duck: Detection in Depth

Security professionals are quite familiar with the concept of Defense in Depth. Detection Engineering has a similar concept known as Detection in Depth. Detection in depth describes the act of leveraging multiple data sources and analytics to detect a single technique. When planning data sources and building analytics it’s important to consider the depth of your detections.

The 5 senses Methodology

We unconsciously make sense of the world around us using multiple senses almost every minute of our lives. Our understanding can be heightened when provided with more sensory input. Seeing cloudy skies makes you think rain. Seeing cloudy skies and hearing thunder makes you think storm. Seeing cloudy skies, hearing thunder, and feeling high winds makes you think hurricane. Using one of your senses may give you the ability to predict unusual weather conditions but using multiple allow you to better understand the specific type of weather conditions to prepare for. From a cybersecurity perspective, we can think of data sources as the senses of the SIEM. They give us different types of data that works together to help us better understand events and adversarial activity in our environment. Leveraging relevant data from multiple data sources will allow us to better detect malicious behavior. Let’s look at a non-cybersecurity example of this. My favorite example is the "Is it Duck" example.

Is it a Duck?

Say our goal is to determine if an animal is a duck. Naturally, we would use our 5 senses to make this decision. We would apply our prior knowledge of a duck to the animal in question to say with high confidence that it is in fact a duck. Let’s also say we must do so using only one of our senses at time. This is the equivalent of relying on one data source or one analytic to make a confident decision about technique.

Using One Sense

I don’t know about you, but I have no idea what a duck smells like... when it’s alive. But let’s pretend ducks smell like any other bird. In walks a chicken, a dog, a fish, and a duck. Remember we can only use our sense of smell to pick out the duck. In this example we would be able to rule out the dog and the fish quickly. They don’t spell like bird. However, the chicken does smell like bird. So, we have no way of distinguishing between the chicken and the duck. So, we write our rule based on this data. If the animal smells like bird, then it must be a duck. With this analytic we will likely correctly identify every duck (True Positives). However, we’ll also catch every other bird as well (False Positives). From cybersecurity perspective this is like writing detection analytic for malicious scheduled task creation based solely on the use of schtask.exe We’ll be able to detect all malicious use schtask.exe but, we’ll generate several false positives for benign usage. Now let’s see what happens when we add other senses (data sources) are better at bringing use to a confident decision.

(Duck) Detection in Depth

Okay let’s say in addition to smell, we can now feel for the next test in this exercise. Let’s also say you can see but it’s limited to colors and silhouettes because resource limitations. Along with the chicken and duck that are already there, an eagle, a pigeon, an ostrich, a goose, and bird shaped pillow with feathers are now on the table. Your goal is to determine which bird is a duck. You’ll likely be able to rule out the pigeon which is much smaller than duck and ostrich which is much larger than the duck right away. Next you rule out the also rule out the eagle because it’s body shape is relatively different. However, the chicken, the goose, the duck, and the pillow are relatively the same size and shape. Applying our previous hypothesis allows u to rule out the pillow because it does not smell like bird. So, you bring in a new sense. Sound. You have each remining item make a sound. You have each bird make a sound. You easily eliminate the eagle and the chicken because they sound nothing like the duck. Finally, while the goose looks, feels, and is shaped like a duck the honk of goose is distinguishable from the quack of a duck. So, you rule it out.

How Does This Apply to Cybersecurity

Using the logic from the previous paragraph and the malicious scheduled task example from earlier, let's look at the several data sources we can apply to detect a malicious scheduled task. Process creation data from sysmon could inform us that a local PowerShell process spawned a child process using the schtask.exe. This may not be common if we normally deploy scheduled task via GPO. It's suspish, but certainly doesn't mean it's malicious. We could also use command line logging to detect the flags and arguments used in the command. We could uncover detection logic based on the the binary image the task is running. If we normally deploy scheduled task via GPO AND the binary the command points to is anomalous, this could be further evidence the task is malicious. We could also use DNS or DHCP logging to identify the source and destination host of the task. If we normally deploy via GPO AND the binary is anomalous AND the source host shouldn't be scheduling task on the destination host we have even more evidence that the task is likely malicious. Finally, we may look at Windows Event Log xml data to identify abnormalities in the source and destination user. If we normally deploy via GPO AND the binary is anomalous AND the source host shouldn't be scheduling task on the destination host AND the source and destination users are not as expected. We can with a high degree say that the scheduled task is likely malicious.

While this example is not exempt from false positives or exceptions, by using multiple data sources, we can be more confident in determining if a scheduled task is malicious. I completely understand how ridiculous this example is and I’m woefully aware of my lack of knowledge when it comes to water fowl. However, I hope you can apply this logic to your Detection Engineering methodology and create deeper and more valuable detections. Have fun and #DetectTheThings.