Traditional detection techniques are based on indicators of compromise (IOCs). The problem with this method is that many attacks can slip through the cracks; attackers can fairly easily change IOCs, like IP addresses and file hashes, to avoid detection. What they can’t change so easily are behaviors—their tactics, techniques, and procedures (TTPs) used in an attack.
Detections based on behaviors tell a story and provide analysts with much more context—plus they’re more troublesome for attackers to avoid. Using the MITRE ATT&CK framework, which outlines TTPs commonly used by attackers, security engineers can build behavior-based threat detections. Osquery gathers the endpoint telemetry needed to build them.
Raja Jasper, SOC manager at a financial institution, and Saurabh Wadhwa, an Uptycs senior solutions engineer, discuss how to craft detections based on behavior, rather than IOCs. Their presentation from osquery@scale 2022 demonstrates how to use osquery to build a behavior-based detection using Emotet malware as an example.
Raja: I’ve been managing a security operation center at a financial institution for over 10 years. I’m on call 24/7, teach part-time at University of Maryland, and brew beer on the weekends.
Saurabh: I’ve been a senior solutions engineer at Uptycs for a little over two years and come from a security background. I've worked in the UBA space, threat intel, SIEM, and XDR. In my free time I love watching USC football and spending time with my family.
Raja: We are not osquery experts at all, having just learned it three weeks ago. But we’re pretty good at building detections.
Raja: An alert is essentially all these log lines that get generated and sent out to your SOC. Your analysts sort through it all looking for a needle in the haystack—whether it's compliance or audit logs, or perhaps settings. We put out a logline we're going to be using as our example; it’s from osquery, where someone downloaded a piece of malware.
Raja: A detection is an alert’s behavior. Rules inform us what an analyst needs to look for. As we write our detection we're selecting the time, and doing some script text within the PowerShell event.
Raja: Our approach is to go traditional versus nontraditional. Many smaller shops will go the traditional route. They'll take the IOCs, put them in a detection and fire it off. IOC-based detections are easy to build and easy to change. But it makes it really tough to do that over time as your SOC grows. You can't really base each detection on every single malware, where you look at all the IOCs to build them. But looking at it from a different angle, how do you examine behavior? That's where we're introducing the nontraditional piece.
"You can't really base each detection on every single malware, where you look at all the IOCs to build them. But looking at it from a different angle, how do you examine behavior? That's where we're introducing the nontraditional piece."
"We want to custom craft detections based on IOC behavior. Each one tells you a story. If you craft detections based on behavior, you'll have a greater advantage using MITRE."
Raja: Our nontraditional way to do this is with the MITRE Framework. But we're not looking at MITRE as a whole, because it might be different for me compared to your situation. We want to custom craft detections based on IOC behavior. Each one tells you a story. Is PowerShell spawning Mshta? That’ll work across many malware groups. If you craft detections based on behavior, you'll have a greater advantage using MITRE.
Raja: Citing a ransomware example, we used the attack navigator within GitHub to check out MITRE there. You can see the reconnaissance, you can see the resource open, where it's hitting between the TTPs. Let’s walk through this with osquery.
Raja: We're gonna go a little bit deeper into Emotet, which was talked about yesterday. Email comes in and a recipient clicks on it. They click on an attached document that comes down, spawns PowerShell, goes into the registry, auto keys, starts emulation, goes to C2 domains to collect data, comes back, and starts propagating within the environment. What does this look like with an osquery?
Saurabh: For this example we ran the malware on a Windows 2019 host. There were some challenges. We tested it using osquery 5.4, the latest version. File integrity monitoring wasn’t working. I had to downgrade the version and restart, this time with the most basic important osquery functionality, which is file integrity monitoring (FIM). I used a simple file path, which is C:\Users\Administrator\Downloads. Typically, whenever you click a document to download it, it goes into Downloads, unless a different folder is specified.
FIM: User Downloading and Opening
Saurabh: We see that someone downloaded Virus.doc.zip into their Downloads folder, and it's a singular FIM configuration that we use. You can have multiple ones by putting them in your configuration file, where it can start using those FIM packs.
"File integrity monitoring can detect if a file gets opened, someone changes its ownership, or modifies it."
Here the user double-clicked on the attached Word document. Its multi-thread process spawns other processes. File integrity monitoring can detect if a file gets opened, someone changes its ownership, or modifies it.
In this Emotet example, the document spawned PowerShell, which dropped a process that opens up a backdoor channel to a command and control (C2) IP address. We’re detecting all the processes along with the user who's running that process. We see that svchost.exe is running as admin.
Raja: Usually, service host is running based on the local NT or the system account. It's not really running as admin, until you run the application's admin. That means if something's running as admin, you want to investigate that within the given endpoint.
"We see PowerShell dropped this IEAPFLTR.exe process. It's reaching out to a remote IP address over port 8080…And we have the MITRE ATT&CK mapping that references the techniques related to Windows processes."
Saurabh: Here, we see PowerShell dropped this IEAPFLTR.exe process. It's reaching out to a remote IP address over port 8080. During our testing, as we repeatedly refreshed the query, the remote address origin fluctuated all over the world—Mexico, United States, Argentina.
We’re looking for any remote process where the remote port is not equal to zero. The process dropped by PowerShell is trying to communicate with the remote address over port 8080. And we have the MITRE ATT&CK mapping that references the TTPs related to the Windows processes.
Raja: You can take this query and scale it to all the endpoints. Since you're looking at SVC hosts or these other executables or processes that are reaching out, you can surmise it’s not the endpoint that’s communicating with those IPs. If it's going anywhere external, or even if your firewall is blocking 8080 or filtering 443, you need to look into it.
"If I look at MITRE ATT&CK anew, it's like boiling the ocean… Within Osquery, you can map all your detections (queries) to MITRE ATT&CK. You can then put them in configuration files that tie back to the tactics, techniques, and procedures."
Raja: So, what does it mean to be using MITRE ATT&CK in osquery? If I look at MITRE ATT&CK anew, it's like boiling the ocean. I can't go and look at every aspect and determine what I need to solve. I need to figure out my organization; what threats is it facing? And how do I combine high false positive detections; what are the things I care about? What are my crown jewels?
Within Osquery, you can map all your detections (queries) to MITRE ATT&CK. You can then put them in configuration files that tie back to the tactics, techniques, and procedures. Each time you run them, it’ll be toward the technique. And wherever you're sending the data, you can have that correlated as well.
Raja: Many have talked about Linux or macOS. It was challenging running this in Windows, because we didn't really know in which tables the data would reside. It was hard to figure that out, unless you're sending it somewhere because we're working natively within osquery. And then, it didn't work in the new version for Windows. We had to go back two versions, and then everything just magically started working.
Participant 1: You had some challenges with Windows, and the newer versions, with running osquery. Did you have any issues installing it? Did you have any operational problems with osquery and Windows at all?
Saurabh: No, it was fine. Installation was still fine. But the surprising thing is the FIM and eventing framework wasn't working.
Participant 2: Did you guys set up a detection sandbox—Cuckoo or whatever? If so, do you have the Ansible code available or...?
Saurabh: No, we just used Windows 2019 VM on my localhost.
Raja: No, I worked with Emotet data forensic analysis before. I knew that all the file paths existed within the registry. It was easy to look through all of it and know exactly what changes occurred.
Participant 3: You mentioned the problem of boiling the seas, looking at the TTPs. What are your thoughts on using MITRE D3FEND to prioritize defensive measures?
Raja: We started using D3FEND in my current company, but we already started mapping everything to the TTPs first, and then did a gap analysis on the data brought in. I think that will help you out. D3FEND is newer.
Participant 4: You said that first you want to look at your critical log areas, then the other criteria. What are the noisy alerts?
Raja: And also the threats that you're facing.
Participant 4: The combination of the two—that's why you picked Emotet, because it would apply to other ransomware. Are there any other types of use cases coming next to help people understand what we should prioritize?
Raja: One of the challenges I'm currently facing is, you have all these server logs, and then you have non-user IDs or service accounts, and they make these random changes... it's taking that, plus machine learning, and figuring out which changes are legitimate and which are not, because every change is going to look legitimate. That's the next challenge, maybe leveraging osquery to see if we can help with that.