The recent Log4j vulnerability (CVE-2021-44228) is unprecedented in its global scope and impact. This open source logging framework for Apache is found buried in everything from the Mars Helicopter to Minecraft. The exploit is as simple as getting the system to log a message containing a specific string, which can be done as easily as changing your iPhone’s name, sending a chat message, or visiting a website.
As developers and administrators scramble to identify affected systems to implement patches and fixes, threat intelligence vendors like GreyNoise are busy identifying malicious systems attempting to exploit the vulnerability. As these attacks become increasingly scripted, automated, and self-propagating, the list of malicious IP addresses continues to grow.
In this blog post, we describe how Recon’s SOC quickly built a playbook within our Siemplify SOAR platform that takes advantage of the intelligence GreyNoise is providing to continually hunt for Log4j attackers in our customers’ environments. This rapid and tactical precaution freed up our time to take care of everything else that this disaster requires.
A GreyNoise result for "Apache Log4j RCE Attempt"
The only way to completely mitigate the threats posed by Log4j is to patch or remove vulnerable software. As of Dec 14, that means version >=2.16.0. Read Recon's Guide to Testing for the Log4j Vulnerability if you're concerned about testing a particular application.
First, why build SOAR playbooks?
At Recon, we’re committed to maintaining a high-performing security operations team focused on finding and stopping threats. There's a lot that goes into that, but in many cases it means building better playbooks. Siemplify's SOAR platform allows us to conceive, build, and improve a powerful collection of playbooks. These playbooks run against our alerts to perform triage, enrichment, initial investigation, and escalation.
By the time an alert lands in front of our analysts, it is ready for human-level thinking. Anything that can be automated has already been automated and simple decisions have already been made. Things like copy-pasting IP addresses from one screen to another wastes time, is inconsistent, and prone to mistakes. It’s also boring, low-leverage work. These playbooks ensure every alert is handled through a consistent workflow backed by our best thinking and processes; all while keeping our analysts' brains on human-worthy problems.
The Log4j/GreyNoise Siemplify Playbook
Our goal was simple: take advantage of the valuable intelligence GreyNoise was providing about the growing list of attackers found exploiting the Log4j vulnerability. We wanted to search our SIEM for any evidence of these IP addresses in our customers’ environments. However, it wouldn’t be enough to do this once: it had to happen continuously as GreyNoise updated their intelligence. We also wanted to continue searching for historical events, so just building alerts for future events from these IP addresses would also be insufficient.
Here’s what we came up with. We'll take a look at each step in turn.
1. The Trigger
Siemplify playbooks are executed through triggers. This yellow box sets this playbook's trigger to any alert coming from our GreyNoise integration. We'd like GreyNoise to only create alerts for IP addresses related to the Log4j exploit. Helpfully, GreyNoise marks those IP addresses with the tag "Apache Log4j RCE Attempt" so we can configure Siemplify to create alerts with the latest list of today's attackers. The query is last_seen:today tags:"Apache Log4j RCE Attempt". You can see the live results from GreyNoise here.
2. Assign to Tier 1
At this point, the alert is not ready for human-level thinking. All that really needs to be done is to have someone copy-paste it into our SIEM and review the results (along with a couple hundred of its friends). That's why we assign the alert to our Siemplify-powered Tier 1 analyst, affectionately known as SOC Bot. Recon doesn't have any Tier 1 human analysts because we don't believe humans should be doing work traditionally associated with Tier 1. In fact, we don't have analyst tiers at all, but that's a story for another post...
3. Query the SIEM
At this point, SOC Bot has everything it needs to query our SIEM. This is where we need to put some of the leg work into thinking about what this query should look like. Standardizing the playbook to a well-thought-out query highlights the consistency we're able to achieve through playbooks. The initial query is simple and we continue to tweak it as new results come in: destination.ip:"[Event.SourceAddress]". Siemplify replaces [Event.SourceAddress] with the actual IP address in the alert.
4. Make a Decision
So what is our Tier 1 SOC Bot to do with the results of the SIEM query? Well, if nothing was found then great! We can close the alert and no one has to worry about it. However if it found something, we need to follow up. From here we can add any level of additional logic, enrichment, and decision making support. Once that's done, we need to hand it over to a real analyst. Let's mark the alert as important (so Siemplify escalates it in the queue) and get it in front of the team.
5. Escalate to Humans
First, we assign the alert to the SOC. This puts it in the Siemplify queue watched by the smart folks on our team. Next, we trigger notifications in PagerDuty and Slack. These notifications include everything SOC Bot has learned so far, including which malicious IP was spotted, details about the IP address from GreyNoise, the results of the SIEM query, and a pre-populated link to our Kibana investigation dashboard. We don't want anyone to repeat the work that SOC Bot has already done, so we include as much context and decision-making support as possible. From here, it's up to our crack team of analysts to take over.
Conclusion
As we investigate the cases generated by this playbook, we continue to tweak and refine how it works and what it does. Our playbooks should represent our best-level of thinking about a problem. Continuing to tweak and improve our playbooks ensures this thinking is consistently applied to each and every alert. This playbook represents a small but important part of what responding to this Log4j vulnerability requires. By automating what can and should be automated, our analysts are free to apply themselves toward the more important challenges this complex problem requires, like threat hunting, securing our customers' environments, and responding to incidents.
