As we look back at the past year in cyber security, it’s impossible to forget how Log4Shell (CVE-2021-44228) turned cyber space upside down. In December 2021, we learned that a critical zero-day vulnerability was found in the Apache Log4j2 Java-based logging library. The vulnerability is known as Log4Shell and is an unauthenticated remote code execution (RCE) vulnerability that allows for complete system takeover on systems with Log4j 2.0-beta9 up to 2.16.1. Log4Shell could allow attackers to install crypto miners, as well as steal data and credentials.
Almost every network security system runs on some kind of logging process and the Log4j2 logging library is extremely popular, given its vast reach. Millions of applications use Log4j2 for logging and if an attacker has the Log4j2 app, he can compromise it by logging a special string of characters.
Initially seen on sites hosting Minecraft servers, attackers discovered the vulnerability could be triggered by hosting chat messages. The first attacks were observed two weeks before they were publicly disclosed, and mass exploitation began a day after the vulnerability was made public. Those exploits originated from professional crypto-mining and DDoS botnets, like Muhstik and Mirai. Additionally, Microsoft observed Log4Shell being used to deploy webshells with Cobalt Strike beacons, which are backdoors.
Major enterprises like Amazon, Apple, and Tesla were all affected by Log4Shell, and cyber security professionals were in a hurry to come up with a solution to this massive problem. The situation quickly went from bad to worse when it was discovered that the first patch Apache issued for CVE-2021-44228 didn’t exactly fix the problem. Although rated lower in severity, the new exploit (CVE-2021-45046) gave attackers the capability to craft malicious input data using a JNDI Lookup pattern, resulting in a denial of service (DOS) attack. The vulnerability was patched, but it wasn’t long before a third vulnerability reared its head.
CVE-2021-45105 addressed Apache Log4j2 version 2.15.1, which allowed for crafted input that could manipulate Context Lookup functionality that leads to a stack-overflow and crash. Soon after Apache released the patch for CVE-2021-45105, a fourth vulnerability was found, CVE-2021-44832. This vulnerability affected Log4j2 version 2.16.0 which was vulnerable to a RCE attack when a configuration uses JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
This final update to the logging library may have patched a few issues, but it is just the beginning of a long string of exploits to come. Attackers (veterans and newcomers) have been exploiting Log4Shell since the news broke and they will more than likely continue to exploit it. As we gear up for the year ahead, let’s take a look back at Log4Shell and see what lies ahead for cyber security specialists in 2022.
Logging is a process in which applications keep a running list of activities they have performed that can later be reviewed in case of an error. Although home users have turned away from Java based software like Apache’s Log4j2, popular games like Minecraft still use it. The vulnerability was initially reported to Apache by an Alibaba Cloud Security team member in November 2021, but it wasn’t taken seriously until recently. After the news broke about how easy it was to exploit Log4j2, threat actors made swift moves. Log4Shell resulted in massive world-wide scanning with the payloads running from miners, Unix DDoS malware, and framework stagers pushed to compromised hosts.
Becoming the first sophisticated ransomware group to actively exploit Log4Shell, Conti has built up a holistic attack chain. When Log4Shell came to light, Conti just so happened to be in the right place, at the right time, and with the right tool kit.
Typically, Conti leverages a Fortinet VPN vulnerability (CVE-2018-13379) as an initial attack vector and lateral movement – targeting unpatched devices. According to our partner, AdvIntel, Conti also likes to use PrintNightmare privilege elevation (CVE-2021-34527/CVE-2021-1675), as well as Zerologon (CVE-2020-1472), and ms17_010 for local privilege elevation and lateral movement on compromised hosts.
Within two days of the Log4Shell fiasco, Conti was already trying to figure out how to exploit it as a new initial attack vector. So far, they’ve been successful. As of today, Conti’s attack chain looks like this:
Emotet -> Cobalt Strike -> Human Exploitation -> (no ADMIN$ share) -> Kerberoast -> vCenter ESXi with log4shell scan for vCenter.
AdvIntel observed the following from Conti from November 1, 2021, to December 15, 2021:
Image 1: Conti Attack Vector Timeline
Although a smaller, relatively unknown ransomware gang named Khonsari was the first to attempt to exploit Log4Shell, Conti was the first major ransomware gang to weaponize it. If you recall, we mentioned earlier that Log4Shell was initially seen being exploited on Minecraft servers. Khonsari was seen locking up Minecraft players via unofficial servers. However, their ransomware note didn’t have a way to contact the operators to pay the ransom. This made Khonsari appear as if they were trolls taking down Minecraft users’ servers, instead of a ransomware gang determined to get paid.
Last year, we watched Conti successfully attack and breach the data of several healthcare and first responder organizations. They belong to a ransomware family (Wizard Spider) and are comprised of several teams. Conti is a professional cyber crime unit, and they are always looking for ways to expand. So far, the Russian speaking gang has made over $150 million in six short months.
Although Russian cyber spy groups are at the top of the list of threat actors exploiting Log4Shell, as of December 14, 2021, Mandiant observed Chinese and Iranian state-sponsored threat actors exploiting the vulnerability as well. A cyber security rating and risk management company named Security Scorecard observed reconnaissance activity linked to Chinese and Russian APTs. The company named China APT10 and the names associated with Russia are APT28, Turla, Ursnif and Grizzly Steppe.
During the summer of 2020, Drovorub, a piece of malware, was linked to several IP addresses. U.S. intelligence agencies linked the malware to Russia’s APT28. Mandiant stated that they believe other state actors will leverage Log4Shell and work quickly to create footholds in desirable networks for follow-on activity. That activity could last for quite a while, and threat actors could work from a wish list of targets that existed before Log4Shell did.
John Hultquist, VP of Intelligence Analysis at Mandiant, stated that the Iranian threat actors are aggressive and have taken part in ransomware operations that were meant to cause chaos and disruption. This is alarming considering most ransomware gangs seek financial gain.
In June of 2021, Cox Media Group (CMG) became a victim of a ransomware attack. The Iranian attacker, Dev-0270 aka Phosphorous, is a group that’s been linked to multiple attacks of U.S. companies. DEV-0270 successfully exploited Log4Shell in Log4j2 for initial access to CMG’s systems. Apparently, the attackers had access to the systems since May 2021.
The ransomware gang was able to deploy their ransomware and encrypt internal servers – impacting radio and TV stations and crippling the ability of some stations to broadcast live streams. CMG didn’t confirm the attack until four months later. DEV-0720 has engaged in both intelligence collection operations and financially motivated attacks, which makes their motivation for attacking CMG unclear.
Now that we know how Log4Shell is being exploited and who is exploiting it, let’s look into one of the ways threat actors could reap financial rewards.
Earlier, we mentioned that threat actors have started using Log4Shell to deploy cryptomining malware. Dridex, a malware banking trojan, was designed to steal online banking credentials from victims. Overtime, Dridex has evolved and now downloads various modules that are used to perform different malicious behavior, like taking screenshots and installing additional payloads.
Currently, attackers are using Dridex to infect devices with ransomware via Log4Shell. The cyber security research group, Cryptolaemus, observed Log4Shell being used to infect Windows devices with the Dridex Trojan and Linux devices with Meterpreter.
Image 2: Tweet Regarding Dridex and Log4Shell
Dridex ransomware attacks are known to be led by the Evil Corp cyber criminal group. However, the group has not been confirmed to be the culprit behind these recent Log4Shell attacks. Joseph Roosen, a member of the cybersecurity research group, Cryptolaemus, stated that the threat actors behind this activity use Log4j2 RMI (Remote Method Invocation) exploit variant to force vulnerable devices to load and execute a Java class from an attacker-controlled remote server.
After execution, the Java class attempts to download and launch an HTA file from various URLS, which then installs the Dridex trojan. If the Java class doesn’t execute the Windows commands, it assumes that the device runs on Linux/Unix and a Python script is downloaded and executed to install Meterpreter. This move provides the threat actors with a remote shell that they will use to deploy more payloads or execute commands. According to BleepingComputer, we can expect to see more threat actors use this vulnerability to compromise internal corporate networks.
In many cases, Log4Shell isn’t exploited until months after initial exploitation attempts. Right now, a campaign is targeting energy companies in countries across the world, including the United States, Japan, Canada, and many others. Additionally, Lazarus, a North Korean state-sponsored threat actor, is exploiting Log4Shell as an initial attack vector against VMWare Horizon servers.
Lof4Shell’s impact has been felt by companies big and small - many major cybersecurity vendors have been impacted by Log4Shell, including:
All of the providers quickly released an updated version of their product and advised users to patch the vulnerability immediately.
For example, once Log4Shell was detected in AWS, they issued a series of patches to address the issue - unfortunately, those patches left users vulnerable to attack as well. Due to Log4Shell’s immediately dangerous nature, companies were left scrambling to patch it quickly and at scale - leaving environments at risk elsewhere. Since the initial patches, AWS has resolved the issues so that both Log4Shell and the other vulnerabilities are now addressed securely.
Open-source software like Apache’s Log4j library, is software that is used extensively behind the scenes on the internet but isn’t well-known to the average person. If given access, this kind of software can be like a treasure chest for attackers. The vulnerability found within Log4j2 was so simple, yet threatened the security of many industries, including technology, banking, and government.
While cyber security professionals raced to fix the problem that could plague the internet forever, they seemingly forgot about a similar situation that occurred in 2014 when Heartbleed, a flaw found in OpenSSL, allowed attackers to trick a vulnerable web server into sending them encryption keys and other sensitive information. Like Log4j2, OpenSSL has a vast reach and is (by VentureBeat’s definition) one of the most popular open-source code libraries for executing the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols used in encrypting websites and software. The flaw found within OpenSSL led to an attack on a large U.S. hospital operator that resulted in the theft of 45 million healthcare records.
|
Log4Shell Timeline |
||
|
CVE # |
Date |
Severity Level |
|
CVE-2021-44228 |
12/10/2021 |
Severity – 9.3 |
|
CVE-2021-45046 |
12/14/2021 |
Severity – 5.1 |
|
CVE-2021-45105 |
12/18/2021 |
Severity – 4.3 |
|
CVE-2021-44832 |
12/28/2021 |
Severity – 6.0 |
Log4Shell and Heartbleed have left many questioning the security of all open-source software. These programs rely on a multitude of code and have become easy targets for attackers. It’s also important to note that Apache’s Log4j2 is overseen by two volunteers, which is not unusual for open-source software. Because most organizations rely on open-source programs to some degree, they aren’t going anywhere any time soon. So, what can be done to secure these kinds of programs?
When the news broke about Log4j2, Avertium began hunting for evidence of vulnerable or exploited Log4j instances in customer environments. Avertium continues to hunt for threats as the situation continues to unfold. Take a look at how we controlled our customer environments and the services we continue to offer:
There are many available tools and techniques to detect Log4Shell - as the vulnerability has evolved and spread, many security teams and experts have scrambled to develop solutions and tools to combat its spread. However, as time has gone on, many of these mechanisms have become obsolete or downright damaging to affected networks.
To quickly and reliably detect whether your system has been impacted by Log4shell, here’s what we recommend:
All organizations scan for vulnerable applications that use Log4j2 and update them to the latest versions.
As this situation continues to develop, new IOCs will be added to the following links:
Conti Ransomware Gang Has Full Log4Shell Attack Chain | Threatpost
Russian Cyberspy Groups Start Exploiting Log4Shell Vulnerability | SecurityWeek.Com
Chinese, Iranian State Hackers Exploiting Log4j Flaw: Mandiant | SecurityWeek.Com
Ransomware Advisory: Log4Shell Exploitation for Initial Access & Lateral Movement (advintel.io)
Iranian hackers behind Cox Media Group ransomware attack - The Record by Recorded Future
Log4j vulnerability now used to install Dridex banking malware (bleepingcomputer.com)
What Log4Shell teaches us about open source security | VentureBeat
This document and its contents do not constitute and are not a substitute for, legal advice. The outcome of a Security Risk Assessment should be utilized to ensure that diligent measures are taken to lower the risk of potential weaknesses be exploited to compromise data.
Although the Services and this report may provide data that Client can use in its compliance efforts, Client (not Avertium) is ultimately responsible for assessing and meeting Client's own compliance responsibilities. This report does not constitute a guarantee or assurance of the Client's compliance with any law, regulation, or standard.