Log4j Hunting & Indicators

A summary of the long weekend experienced by thousands of security professionals.

By Joshua Beaman
Founder & Lead Trainer at SBT
Incident Responder at ASOS.com

The purpose of this page is to assist Defenders with the on-going global incident surrounding the Log4j no authentication remote code execution (RCE). This page contains the following sections:

Summary of Log4j or "Log4Shell", CVE-2021-44228

Click Here – National Vulnerability Database Link
Click Here – CVE Details Link
Click Here – Vendor (Apache) Advisory Link
Click Here – CISA Advisory Link
Click Here – NCSC Advisory Link

The Apache Software Foundation has released a security advisory to address a remote code execution vulnerability (CVE-2021-44228) affecting Log4j versions 2.0-beta9 to 2.14.1. A remote, unauthenticated attacker could exploit this vulnerability via a single request to take control of an affected system by executing code. Log4j is an open-source, Java-based logging utility widely used by enterprise applications and cloud services.

The Log4j 2 library is included in Apache frameworks such as:

  • Apache Struts2
  • Apache Solr
  • Apache Druid
  • Apache Flink
  • Apache Swift

If you are using the Log4j 2 library as a dependency within an application that has been developed in-house, ensure you update to version 2.15.0-rc-2 or later (NOT 2.15.0 as previously thought) to mitigate the vulnerability.

Communicating with third-parties/vendors to confirm their acknowledgement of CVE-2021-44228 and if they are affected, as well as patching timelines, will help with scoping the attack surface. If you are using an affected third-party application, ensure you keep the product updated to the latest version.

The flaw can also be mitigated in previous releases (2.10 and later) by setting system property “log4j2.formatMsgNoLookups” to “true” or removing the JndiLookup class from the classpath.

If a system is showing indicators of successful exploitation, standard digital forensics and incident response practices should be utilised to contain, analyse, and eradicate any malicious foothold.

Log4j Exploitation

I have primarily seen four approaches to execution, including the standard format. Real-world examples can be found in the User-Agent Indicators section.

  • Standard/Initial Format:
  • Lowercase/Uppercase Lookups:
  • Utilising System Environment Variables:
    “${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}” If there is no ENV_NAME system environment variable, use text after :-
  • ::- Notations:
Image credit: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/

Hunting Tips

  • FA quick win is to look for User-Agents that start with “${jndi” as this is a commonality we’ve seen across public and private reporting. This is shown in the User-Agent Indicators section of this page.
  • With the above, HTTP 200s could show successful exploitation activity (provided the end system is actually vulnerable). Other status codes such as 500, 404, etc could help you collect source IP indicators for blocking.
  • If you have access to dirty machines, when looking at requests that attempt to drop files onto the victim system, you can curl the payload URL. This can help with intelligence gathering such as file name, hash, size, and contents. Using yarGen to create YARA rules could be useful for further hunting to identify any occurrences of the file inside your environment.
  • Security Operations teams should be focusing harder than ever on SIEM/EDR/other alerts, as these could be indicators of actions-on-objectives as a result of successful log4j exploitation.
  • Contact 3rd-party services utilised by your organisation to understand if their products or services are affected by the vulnerability, and what their remediation timelines are. You can cross off services/products that aren’t affected or have been patched, and remove them from the scope.
  • Use the below list of Source IP Indicators to look for incoming traffic from scanning/exploitation IPs in your perimeter firewall, WAF, proxy, or system logs.
  • Use the below list of Payload Indicators to look for outbound connections to these IPs/domains in your perimeter firewall, EDR, proxy, or system logs.
  • Actors are finding new ways to obfuscate the standard “${jndi:ldap” string to bypass WAF rules. Review your logs to identify new variants being used, such as “${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}:” – naughty, right?
  • If your systems have Sysmon logging and you use Microsoft Defender, try out the Advanced Hunting queries provided in this article.
  • Use the following grep/zgrep commands by Florian Roth to hunt for exploitation activity in /var/log and sub-locations.
  • A vast amount of IOCs have been consolidated in one GitHub page here.
  • Snort and Suricata rules for Log4j can be downloaded here.

Source IP Indicators

The following source IPs are related to resources that are conducting log4j vulnerability identification scanning and exploitation. Different IPs may be used to host payloads or act as call-back servers to listen for vulnerable systems identified during reconnaissance. SBT cannot confirm the quality of these indicators, so do not block them outright, do your own reputation checks.

Payload Indicators


SINKHOLE: http://kryptoslogic-cve-2021-44228[.]com








User-Agent Indicators

Please note that some indicators have been sanitised (using [.] on the last octet of IPs, or the TLD of domains) to prevent automatic hyperlinking. Ensure this is removed before running searches to retrieve accurate results.



















Closing Note

If you enjoyed this post, please consider following me on LinkedIn. A big shout out to the security teams and incident responders around the world that have been dealing with this mess since Friday – good luck to you all.