As the year winds down, it was inevitable that someone was going to release something that was going to cause a bit of a panic before the New Year. What we didn’t know is just how big that panic could be with Log4j (aka Log4Shell, CVE-2021-44228). This is a relatively innocuous Java library that is used for application logging, seemingly everywhere. And the adversaries have been much quicker this time to pivot and begin exploiting it. What was truly interesting to me, however, is that it seems a proof of concept of this exploit was publicly available since at least April 2021. And the community missed it.
Now, this isn’t to blame the community for this. Far from it. But I do think it warrants re-examining the current model we use in the infosec world. Typically, when one of these high-profile vulnerabilities, like Log4j, pops up, the first question people ask is “how can we detect malicious activity?”
Now, that isn’t a bad question, but the answer is often a laundry list of indicators of compromise (IoCs), and with vulnerabilities like Log4j, which really isn’t fully understood how deep that rabbit hole goes, focusing exclusively on detecting the malicious activity reactively might not be enough. Especially if this activity may have been ongoing for months.
This is where threat hunting can help organizations take a new approach to these high-profile vulnerabilities. A structured threat hunt is a formal search for tactics, techniques, and procedures (TTPs) —specifically, those often used by threat groups deemed to be a significant risk to the organization. It’s a search for behaviors rather than indicators or artifacts. This means that organizations no longer have to focus on the initial exploitation.
Even APTs are Lazy
TTPs are right at the top of the Pyramid of Pain. Even Advanced Persistent Threat (APT) groups are prone to reusing TTPs across their operations. Attackers develop these capabilities over years and may also be constrained by standard operating procedures. As a consequence, TTPs are far harder to change than infrastructure.
Let’s take the Log4j zero-day as an example. Right now, it is being exploited by groups to drop cryptominers, RATs, and ransomware (oh my!). While you could collect IOCs for all of this activity, all it takes is a newly spun up VPS and recompiled binary and the security team would likely miss it entirely. However, by looking at common behaviors, such as persistence and lateral movement techniques, you can feel confident that even if you miss the initial exploitation, you will still see the malicious activity.
A structured, hypothesis-driven hunt can identify this behavior even if the adversary or malware isn’t associated with any known indicators or artifacts.
When you deny attackers the use of their favorite TTPs, you force them to develop new behaviors and tools. This costs time and resources and may even prompt them to look for easier targets.
The structured hunting process uses custom queries designed to look for behaviors that are then applied to various datasets to identify possible malicious or suspicious activity. Before that, though, there’s a critical preliminary step.
Each structured hunt is built around a central hypothesis about specific attackers and their associated TTPs. This hypothesis takes the form of a clear, falsifiable statement, often driven by external CTI. For example:
Our CTI team has identified that multiple groups are targeting the Log4j vulnerability. One is dropping a known ransomware package. This ransomware is known to use a particular persistence mechanism, and the group responsible has also used three common lateral movement techniques. This hunt will look for these techniques to determine if we have been impacted.
Notice the definite language. This hypothesis is either correct or incorrect; there’s no middle ground. The threat hunter researches the threat to understand its characteristics, gathers CTI, and writes a query to find specific host enumeration techniques and procedures in the environment.
A hypothesis can be derived from several different sources, including:
- CTI — e.g., prompted by information from an open or privileged source such as media coverage of an emerging threat or from government agencies.
- TTPs — e.g., to provide coverage of a tactic or technique in the MITRE ATT&CK or other frameworks.
- Risk assessment — e.g., to provide coverage of an identified ‘blind spot’ in the organization’s security controls.
Once the hypothesis is set, the threat hunter develops a query to search for associated threat behaviors in an existing data set—for example, in the organization’s SIEM, EDR, data lake, or IDS. Depending on the threat, the hunter may run this query sporadically, or they may set it to run continuously in the background.
The Log4j vulnerability, without a doubt, is pretty bad. This is because, as a library, it isn’t as simple as compiling a list of affected applications or operating systems. It could be in almost anything. Similarly, it still isn’t known all the different methods of exploiting it. This means that the impact of this vulnerability will probably be felt by organizations for years to come. But, by taking a different approach and using threat hunting proactively, organizations can feel more confident in their ability to detect malicious activity regardless of the point of initial access.
Want to try out structured threat hunting but aren’t sure where to start? We’ve got you covered. Use promocode ‘Log4Shells’ and the link below to claim your free Community Edition of the threat hunting content platform, HUNTER and get access to detection content for Lof4j as well as dozens of other behavioral threat hunting packages.
Sign up here, today!
