Despite receiving a patch two years ago, the Log4Shell vulnerability remains a popular attack vector even for sophisticated threat actors. An example is a recently documented attack campaign against companies from several industries by the North Korean state-run Lazarus APT group. The Lazarus attackers exploited Log4Shell (CVE-2021-44228) in publicly facing and unpatched VMware Horizon servers and used their access to deploy custom remote access trojans (RATs) written in DLang, a programming language that’s not commonly used in malware development.
The campaign, dubbed Operation Blacksmith by researchers from Cisco Talos, appears to have started in March and continues to date. The attacks are more likely opportunistic in nature rather than targeted with recorded victims in the manufacturing, agricultural, and physical security sectors.
Custom remote access trojans built with uncommon technologies
The Lazarus group (APT38) is one of North Korean government’s hacking teams and is usually tasked with cyberespionage and sabotage objectives. The group’s malicious activities span back many years and it shares some of its toolset and infrastructure with other North Korean APT groups.
In fact, the Talos researchers believe the Lazarus APT today is most likely an umbrella for different sub-groups that operate their own campaigns that develop bespoke malware for their targets. These sub-groups might have different objectives and don’t always coordinate with each other, despite the occasional overlap.
“During our analysis, Talos found some overlap with the malicious attacks disclosed by Microsoft in October 2023 attributing the activity to Onyx Sleet, also known as PLUTONIUM or Andariel,” the Talos researchers said in their new report on Operation Blacksmith. The Andariel campaign documented by Microsoft exploited CVE-2023-42793, a critical vulnerability in JetBrains TeamCity server, a CI/CD tool used in DevOps. The overlap with Lazarus’ Blacksmith operation was the use of a custom proxy tool dubbed HazyLoad that has only been observed in these two campaigns. However, the other malware implants were different.
In Blacksmith, the attackers deployed three different malware programs written in DLang, a programming language originally released in 2001 that uses C++ as inspiration but adds many features and paradigms borrowed from other languages. DLang is an unusual choice for malware development, but Lazarus is known for adopting non-traditional technologies with previous examples including QtFramework and PowerBasic.
One of the DLang-based implants deployed in the post-exploitation stage is dubbed NineRAT and is a RAT that uses Telegram as a command-and-control (C2) channel. “With NineRAT activated, the malware becomes the primary method of interaction with the infected host,” the Talos researchers said. “However, previously deployed backdoor mechanisms, such as the reverse proxy tool HazyLoad, remain in place. The multiple tools give overlapping backdoor entries to the Lazarus Group with redundancies in the event a tool is discovered, enabling highly persistent access.”
By using the NineRAT samples as a reference, the Talos researchers managed to locate two additional implants that used similar code. One is a downloader also written in DLang that the researchers dubbed BottomLoader. Its purpose is to download an additional payload from a hardcoded URL by using a PowerShell command.
The second implant is more sophisticated and is both a payload downloader and remote access trojan that was dubbed DLRAT. Unlike NineRAT, DLRAT doesn’t use Telegram for C2 but sends information about the infected host over HTTP to a C2 web server. In return the attackers can instruct it to upload local files to the server, to rename files and to download additional payloads.
“The threat actors also created an additional user account on the system, granting it administrative privileges,” the researchers said. “Talos documented this TTP earlier this year, but the activity observed previously was meant to create unauthorized user accounts at the domain level. In this campaign, the operators created a local account, which matches the user account documented by Microsoft: krtbgt.”
Log4j is the gift that keeps on giving
Log4Shell was originally reported on December 9, 2021, and is in a highly popular Java library called Log4j. Because of the library’s widespread use, the vulnerability impacted millions of Java applications — both applications that companies developed in-house, as well as commercial products from many software developers.
Patches became available for Log4j days after the flaw was announced, but it took months for all impacted vendors to release patches and for organizations to update their internal apps. Despite the big publicity that the flaw received, two years later a large enough number of systems appear to remain vulnerable for groups like Lazarus to still use the exploit. According to software supply chain management company Sonatype that also operates the Central Repository for Java components, over 20% of Log4j downloads continue to be for vulnerable versions.
Application security firm Veracode reports that based on its own telemetry only 2.8% of tested applications are still using versions of Log4j with the Log4Shell vulnerabilities. However, an additional 3.8% use a version of Log4j 2.x vulnerable to another high-severity issue tracked as CVE-2021-44832 and a third of all applications that include Log4j continue to use the older 1.x series of the library that has reached end of life and has not received security patches for a long time. While Log4j 1.x is not affected by Log4Shell, it currently has seven other high and critical vulnerabilities that remain unfixed.
“Our research also found that once developers are alerted to a vulnerable library through a scan, they fix them relatively quickly: 50% of vulnerabilities are fixed in 89 days overall, in 65 days for high severity vulnerabilities and in 107 days for medium severity vulnerabilities,” Veracode’s chief research officer Chris Eng said in a blog post. “This contradicts the Log4j data above, which shows that remediation is not happening quickly for this open-source library, especially for Log4j 1.2.x.”