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:
\${(\${(.*?:|.*?:.*?:-)('|"|`)*(?1)}*|[jndi:lapsrm]('|"|`)*}*){9,11}
- 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 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
| 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/tree/main/mitigation/Log4j%20Attack%20Detection%20Guidance%20-%20Release.pdf |