When investigating a crime in the physical world, the successful detectives are able to piece together individual pieces of evidence to unveil a criminal’s patterns of behavior. A single footprint, is interesting; it gives you the size of the bad guy’s foot and what type of shoes they wore.
The bad guy can change his shoes between crimes, of course, but he probably won’t come up with a new technique for breaking into individual houses. An understanding of their behavior, their “patterns,” if you will, can give investigators a level of insight that will immediately catch that criminal the next time he attempts to do something bad, new shoes or not.
This way of approaching the problem can also tie together multiple incidents that were previously thought unrelated, perhaps because the weapons or descriptions of the individuals performing the crimes weren’t exactly the same.
In the cyber security world, we call these behavior patterns: “Patterns of Attack,” (POAs) and they are revolutionizing the way breach detection and incident response are being conducted around the world.
You’re Looking for Answers, Not Indications
You’ve no doubt heard the term “Indicators of Compromise” or “IOCs.” IOCs are – in the way the security community typically thinks about them – atomic pieces of information or singular attributes. Examples of IOCs are IP addresses, domain names, URLs, file hashes, and similar metadata around tools or actions that occurred during an attack. But context matters, a lot, and it’s hard to know context when all you have is an IP address or file hash.
Solving cyber crimes (or any crime, really) requires context, and to get context, you have to look at relationships. Relationships between IOCs and other events are often patterns of behavior, and that’s why the shift beyond IOCs is occurring.
When your company’s intellectual property and reputation are on the line, the CEO wants to hear something a lot more confident than: “We have an indication of how we might have been attacked.” Instead, she wants to hear: “We have a precise record of what this attacker tried to do. We know exactly what they actually did. We’ve closed the gap.
They cannot attack us this same way again.”
Indicators offer hope. Patterns provide confidence.
“Patterns of Attack” provide investigators with the precise sequence of events as a cyber crime unfolds. There is clear cause-and-effect insight into where an attacker gained access, what he tried to do, how he attempted exfiltration and, ultimately, what the exact root cause of the attack was. If an investigator does not understand the root cause of attack, he’s provided no additional insight into how an organization can be better protected in the future.
Consider this physical-world to cyberworld analogy when it comes to differentiating between IOCs and POAs.
Convenience Store Robbery
Investigating Using IOCs: Investigators come to find that during this robbery, the criminal used a crowbar to break the glass on the front door; wore a blue shirt; had short, light-colored hair and used a hiking backpack to stash the cash from the register.
What exactly have the investigators learned, if anything?
- That crowbars are sometimes used in smash-and-grab robberies?
“Ok, let’s make sure to look out for anyone carrying a crowbar in plain sight.”
- That, sometimes, people wearing blue shirts with short, light colored hair may commit crimes.
“Ok, let’s look out for anyone wearing a blue shirt that has light-colored hair.”
- That hiking backpacks are sometimes a tool used during burglaries.
“Ok, let’s try to monitor hiking backpack sales in this area moving forward.”
That’s not a lot of substance to go on for this investigation. We have an incomplete picture.
Investigating the Same Crime Using POAs: Investigators come to find that for the past two weeks, someone has been parked in the store parking at night noting what time the clerk locks up for the night and what time the rent-a-cop security detail passes by the store. The burglar drives to the store at precisely the right time of night to break in. He knows there’s an archaic alarm system on the door so he successfully cuts power to the building prior to entering to deactivate the alarm. Once inside, he approaches the register, opens the register drawer, takes the cash and exits the store.
What patterns has the burglar exhibited here?
- In order to get to the store, the burglar needs to drive to (or close to) the store’s location.
- He has to enter the building before getting access to the real goal, the cash register.
- He has to deactivate the alarm.
- He has to open the register drawer.
- He needs to leave the premises with the cash in hand.
Individually, these single “indicators” of an attack tell an incomplete picture. Driving to, or near, a store doesn’t reveal a whole lot to investigators.Thousands of people do that every single day. What about entering the store? Same idea.Thousands of people. And while deactivating an alarm or opening a register drawer appear to be a lot closer to “burglary-type” activity, there are numerous instances where both are done on a regular basis. These are simply indications that a crime might be committed.
It’s only when this sequence, or “pattern,” of attack behaviors shows up do we really start to see what is happening from an investigation standpoint.
“When someone drives near the store late at night THEN attempts to enter the building THEN attempts to deactivate the alarm THEN opens the register drawer, we almost CERTAINLY have an attempted burglary on our hands.”
Also notice how none of the behavior “patterns” exhibited can be changed. Failure to do any one of the steps will result in a failed mission for the robber. It’s ripe for disruption-in-depth, but we’ll leave that for another day.
Patterns reveal exponentially more relevant information about attempted malfeasance than singular indicators of an attack ever could. Context, relationships, and the sequence of events all matter. If you’re just looking for one item in the sequence of events, that’s when issues like too many tips or, in the cyber world, false positives start becoming a bigger issue than the malicious behavior itself. After all, if you cannot respond to a tip or an alert, it’s just noise.
The Cyber World Parallel
In simple terms, malicious activity might involve an unsigned binary or misuse of svchost.exe. Or, it might involve using the Google DNS server (126.96.36.199). But looking for any of these as an independent indicator is largely going to blow up your SIEM. That’s why context and the relationships between patterns of events, really matter.
Example: Outlook spawns Acrobat as a child to handle an attachment. That Acrobat then spawns an unsigned binary in a temporary user directory, which in turn spawns svchost.exe. That svchost is running as a non-typical user for that process (local Administrator in this case).
Now, if we just looked for svchost.exe running, we would get many instances of that on every Windows system. If we just looked at Acrobat spawning a process, we would still get many hits; the huge majority of which would be legitimate. And Outlook spawns lots of child processes to handle attachments, so we can’t look at just that. The pattern of attack – using email to spawn a vulnerable document handler (Acrobat), which then spawns a binary, which then spawns svchost using an unexpected user-account and with that unexpected parent is VERY telling.
Note that we don’t care which unsigned binary was involved (don’t care about the hash). We don’t care about the version of Acrobat or svchost, or even which email client. We care about the overall pattern of attack – the killchain if you will – and are very confident that this does not occur in this environment for legitimate means. So we can turn up the severity and prioritize the response to it. In some ways you can automatically kill or prevent in the first place, but how you handle malicious behavior is a decision you have to make fit within your culture and environment.
Patterns don’t have to be complicated, either. You can start with the easy stuff, focusing on context. Notepad is spawning child processes? Strange parent processes have PowerShell as children? Find these sequences that are not typically legitimate, tune them a little bit for your environment (since every environment is a little different), and automatically find bad.
In order to combat the quantity of attacks (let alone the quality of some of them), we need intelligence and we need collaboration. But we need to move beyond IOCs to POAs, to look for those patterns that are harder to change. Think about ways you can do that – where context and relationships matter. “Is this the Dropbox app connecting to Dropbox.com?” “Or is it an unknown binary spawned from Word that is then making that connection?”
Contemplate how POAs can help you more effectively do detection and response and once you have some POAs that are effective, SHARE THEM!
We can only win by fighting together, and fighting together involves sharing our intelligence and lessons learned. Start by integrating your products to have more context, and make sure the data you collect can look for POAs.
Remember, indicators offer hope. Patterns deliver confidence.
What is “Collective Defense?” Click here to learn more.