Home>Blog>Log4Shell Vulnerability: What Security Operations Teams Need to Know Now and How SOAR Can Help You Detect and Respond

Log4Shell Vulnerability: What Security Operations Teams Need to Know Now and How SOAR Can Help You Detect and Respond

8 Min read
Last Updated Tuesday, December 21, 2021

Written by Dan Kaplan

Written by Dan Kaplan

For security professionals, 2021 will conclude with them racing to respond to one of the most grave internet vulnerabilities in recent memory. The Log4Shell vulnerability, an input-validation flaw in the omnipresent Apache logging library Log4j and disclosed by the open-source company on Thursday, exposes  “the world’s most popular applications and services” to remote code execution.

Despite an update now available, companies worldwide are already under mass bombardment by attackers exploiting the vulnerability with everything from crypto-mining to ransomware to credential theft (including with variants that may be able to evade newly introduced protections) . Administrators of thousands of government websites, for example, have chosen to pre-emptively shut them down rather than face an exploit, and the sheer number of systems impacted globally virtually guarantees that businesses and users will face torment from this bug for many years to come.

According to Check Point Software Technologies:

The Log4j library is embedded in almost every Internet service or application we are familiar with, including Twitter, Amazon, Microsoft, Minecraft and more. At present most of the attacks focus on the use of a cryptocurrency mining at the expense of the victims, however under the auspices of the noise more advanced attackers may act aggressively against quality targets.

To help your security operations team detect and respond to this threat, the Siemplify team has prepared a FAQ:

What is Log4j?

Log4j version 2 is a Java library that provides advanced logging capabilities for Java applications. It is an (open-source) Apache product and thus has been implemented in a majority of applications that utilize Java. The first version of Log4j was released Jan. 8, 2001.

What impact can successful exploitation of the vulnerability cause?

  • Allows remote-code execution on vulnerable systems.
  • Allows an LDAP ( Lightweight Directory Access Protocol) request to be called.
  • Can result in complete takeover of the targeted device.
  • In milder cases, can result in data leakage.
  • Both internet-facing and internal-facing assets are at risk, and the vulnerability can be used to facilitate lateral movement.

What is the rough timeline of the event?

Dec. 1-2: Both Cisco and Cloudflare reported cases of the exploit in the wild, starting mostly with the Microsoft-owned Minecraft video game.

Dec. 3-9: Researchers apparently privately share information about the vulnerability with Log4j developers before it is publicly known.

Dec. 9-10: Apache discloses CVE-2021-44228, quickly followed by proof-of-concept code being publicly published.

Dec. 10-11: Computer emergency teams worldwide confirm that a proof-of-concept of Log4j 2 exploit was released on GitHub. Meanwhile, various vendors rush to provide guidance and patches, while botnets such as Mirai begin to utilize the vulnerability. The Siemplify Security Operations Platform begins to assist in the automation of detection, hunting and remediation of the threat.

Try SOAR for Free With the Siemplify Community Edition

Dec. 10 and 13: Apache releases Log4j 2.15.0 to patch the vulnerability, shortly thereafter releasing 2.16.0 to amend one issue.

Ongoing: A massive rise in scans for the vulnerability means the associated risk is rising at an alarming rate.

Are playbooks available?

Siemplify partner Recon Infosec has published a playbook leveraging the Siemplify SOAR platform. From the post, which contains the complete playbook:

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.

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…

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.

What are the biggest takeaways?

The largest challenge of dealing with the vulnerability is the sheer amount of attack surface. So many applications, Servers and other devices use Log4j that a full inventory will take most organizations quite a lot of resources to compile.

The most important patching targets will be internet-facing assets. Next an organization should think about how an adversary will move laterally in its environment. Remember, they could get in through, for instance, a traditional phishing attack and then exploit Log4j.

But it is not as simple as “just patch.” Most organizations face both organizational hurdles and monetary barriers to fix all possibly affected systems, especially during the holiday season.

Automation will play a huge role in dealing with the crisis. The above-mentioned Recon playbook enables organizations to review logs for both past, present and future exploitation with little to no analyst intervention.

What other intelligence exists to aid SOC teams?

In true collective fashion, the security community is uniting to share intelligence about the threat, including efforts such as this:

In addition, you can map the threat to the MITRE ATT&CK framework:

T1595.002: Active Scanning: Vulnerability Adversaries may scan victims for vulnerabilities that can be used during targeting. 
T1588.006: Obtain Capabilities: Vulnerabilities  Adversaries may use POC of given vulnerabilities instead of developing in-house tools
T1190: Exploit Public-Facing Application Adversaries may use a known exploit on applications with public internet traffic.
T1203: Exploitation for Client Execution  Exploit of code vulnerabilities leading to command execution on a remote system.


What should Siemplify customers know?

Siemplify’s stack technology is not based on Java, and our core product is not affected by this vulnerability. There are, however, a few third-party components, such as Tableau, that we work with that might be impacted. We are conducting a complete investigation and will share more details as we progress.

(This blog post will be updated as more information becomes available.)

UPDATE DEC. 20, 2021: Many organizations are still reporting to be in the process of completely identifying which assets are vulnerable to the original exploit. Vendors, in particular, are having trouble both patching their own environments and providing automated patch solutions for customers. Despite the problems caused by these events, it is essential that security teams keep and a watchful eye on more common attack vectors that many adversaries will surely be hoping evade the noise of the crisis and upcoming holidays.

UPDATE DEC. 21, 2021: A third vulnerability, which allows for denial-of-service, has been discovered. Log4j must now be updated to the newest version 2.17.

Dan Kaplan is director of content at Siemplify. Solutions Engineer Ivan Ninichuck and Product Marketing Director Kristen Cooper contributed to this post.

Sign up for our newsletter and join thousands of your peers who receive monthly security operations tips and tricks.