What researchers are calling a “horde” of miner bots and backdoors are using the Log4Shell bug to take over vulnerable VMware Horizon servers, with threat actors still actively waging some attacks.
On Tuesday, Sophos reported
that the remote code execution (RCE) Log4j vulnerability in the
ubiquitous Java logging library is under active attack, “particularly
among cryptocurrency mining bots.” Besides cryptominers, attackers are
also prying open Log4Shell to deliver backdoors that Sophos believes are
initial access brokers (IABs) that could lay the groundwork for later ransomware infections.
History of Log4Shell Nightmare-ware
The Log4j flaw was discovered in December, vigorously attacked within
hours of its discovery and subsequently dubbed Log4Shell. Sophos’s
findings about VMware Horizon servers being besieged by threat actors
leveraging the bug is in keeping with what’s been happening since then:
In fact, cyberattacks increased 50 percent YoY in 2021, peaking in December, due to a frenzy of Log4j exploits.
With millions of Log4j-targeted attacks clocking in per hour since the flaw’s discovery,
within just a few weeks, there was a record-breaking peak of 925
cyberattacks per week per organization, globally, as Check Point
Research (CPR) reported in early January.
Log4Shell has been a nightmare for organizations to hunt down and
remediate, given that the flaw affected hundreds of software products,
“making it difficult for some organizations to assess their exposure,”
noted Sophos researchers Gabor Szappanos and Sean Gallagher in Tuesday’s
report. In other words, some outfits don’t necessarily know if they’re
vulnerable.
Why Attackers Have Zeroed in on Horizon
In particular, those attacks have included ones targeting vulnerable VMware Horizon
servers: a platform that serves up virtual desktops and apps across the
hybrid cloud. These servers have been important tools in organizations’
arsenals over the past few years, given that the pandemic triggered the
necessity to provide work-from-home tools, the researchers pointed out.
Although VMware released
patched versions of Horizon earlier this month – on March 8 – many
organizations may not have been able to deploy the patched version or
apply workarounds, if they even know that they’re vulnerable to begin
with.
“Attempts to compromise Horizon servers are among the more targeted
exploits of Log4Shell vulnerabilities because of their nature,” Sophos
said.
Even those organizations that have applied the patches or workarounds
may have been already compromised in other ways, given the backdoors
and reverse-shell activity Sophos has tracked, the researchers
cautioned.
In late December and January, VMWare’s Horizon servers with Log4Shell vulnerabilities came under Cobalt Strike attack, as flagged by researchers at Huntress. Other attacks included those that installed web shells.
Those attacks used the Lightweight Directory Access Protocol (LDAP)
resource call of Log4j to retrieve a malicious Java class file that
modified existing, legitimate Java code, injecting a web shell into the
VM Blast Secure Gateway service and thereby granting attackers remote
access and code execution. Sophos has seen these attacks show up in
customer telemetry since the beginning of January, the researchers said.
The attacks against Horizon servers grew throughout January. Beyond
attempts to deploy cryptocurrency-mining malware, other attacks were
potentially designed either to grant threat actors initial access or to
infect targets with ransomware, Sophos said. Such attacks have continued
into this month: the security firm shared a bar chart, shown below,
that shows the ebb and flow of the attacks that have bled into
mid-March.
VMware Horizon server attacks since the beginning of January. Source: Sophos.
“The largest wave of Log4J attacks aimed at Horizon that we have
detected began January 19, and is still ongoing,” the researchers said.
But this wave hasn’t relied on the use of one of cybercrooks’
favorite tools, Cobalt Strike: a commercial penetration-testing tool
that can be used to deploy beacons on systems in order to simulate
attacks and test network defenses.
Rather, “the cryptominer installer script is directly executed from
the Apache Tomcat component of the Horizon server,” Sophos said, with
the most frequently used server in the campaigns being 80.71.158.96.
The Payloads
Sophos found a slew of miners being dumped on targeted Horizon
servers, including z0Miner, the JavaX miner and at least two variants –
the Jin and Mimu cryptocurrency miner bots – of the XMRig commercial
cryptominer,. Speaking of which, Uptycs reported in January that
cryptojackers had figured out how to inject XMRig into VMware’s vSphere services, undetected. For its part, back in September 2021, Trend Micro found that z0Miner operators were exploiting the Atlassian Confluence RCE (CVE-2021-26084) for cryptojacking attacks.
Sophos also found several backdoors, including several legitimate
testing tools. One such was implants of Sliver: a tool used by red teams
and penetration testers to emulate adversarial tactics. Sliver showed
up as a precursor to the Jin miner in all the cases where Sophos was
able to investigate further, leading the researchers to suspect that
it’s actually the payload. Either that, or maybe the actor behind Sliver
might be a ransomware gang, the researchers hypothesized, given that
the same servers deploying Sliver also hosted files to deliver the Atera
agent as a payload.
Atera is another common, legitimate remote monitoring and management
tool. However, the threat actors aren’t attacking existing Atera
installations, per se, the researchers said. Rather, “they install their
own Atera agents in order to use the Atera cloud management
infrastructure to deploy additional payloads in the future,” they
explained.
Sophos also found the legitimate Splashtop Streamer remote-access
tool being downloaded and installed on infected systems, “probably as an
automated task for the new clients.”
As well, there were several PowerShell-based reverse shells in the payload mix that had been dropped by the Log4Shell exploits.
Two Types of Reverse Shells
Sophos found two types of reverse shell: one, a shorter script that
opens a socket connection to a remote server and executes the received
buffer, which is supposed to be a PowerShell command.
They also found a larger variant of a reverse shell: one that can
reflectively load a Windows binary, with the loader as an encrypted and
base64 encoded blob, as depicted below:
Base64 encoded blob. Source: Sophos.
Sophos telemetry showed that while z0Miner, JavaX and some other
payloads were downloaded directly by the web shells that had been used
for initial compromise, the Jin bots were tied to use of Sliver and used
the same wallets as Mimo, “suggesting these three malware were used by
the same actor,” Sophos said. Researchers believe that Jin is, in fact,
“simply a rebranded version of Mimo.”
Loads of New Malware Loaders
New malware loaders are springing up like dandelions in the spring.
Besides the ones covered by Sophos in Tuesday’s report, security
researchers at Symantec today also published a technical report on a new malware loader tracked as Verblecon that’s escaped detection due to the polymorphic nature of its code.
Verblecon has likewise been seen in attacks that install cryptocurrency miners on compromised machines.
Saryu Nayyar, CEO and founder of Gurucul,
told Threatpost that in order to fight the legitimate assessment tools
being used to breach organizations, it’s also “critical” to employ
sophisticated technologies – namely, self-training machine learning and
behavioral models – to sniff out exploitation of exposed vulnerabilities
as well as to detect the remote surveillance done by attackers with
tools such as Cobalt Strike, et al.
“Current [extended detection and response, or XDR] and traditional
[security information and event management, or SIEM] solutions, even
with claims of User Entity Behavior Analytics rooted in known patterns
and rule-based artificial intelligence, are unable to adapt to these
methods,” she told Threatpost via email. “Organizations need to invest
in solutions that employ transparent non rule-based machine learning
models to more rapidly identify new attacks.”
Chris Olson, CEO of digital safety platform The Media Trust, told
Threatpost on Tuesday that polymorphic techniques “are just another way
to hide malicious intentions, along with checks for security tools and
live environments.”
This attack provides another example of how the risks of Web 2.0 are being replicated in Web 3.0, he said via email.
“Today’s embryonic beginnings of Web 3.0 are eerily reminiscent of
the Web as it existed in the 1990s, showing sporadic signs of
vulnerability that may well foreshadow a future era of cyber chaos,”
Olson said.
To prevent that from happening, we must learn from our past mistakes,
he warned. “Today’s digital ecosystem is riddled with threats because
Web 2.0 was not designed for cybersecurity from the outset. Untrusted
third parties were allowed to proliferate, leading to phishing attacks,
malicious advertising, rampant data privacy abuse and other threats that
are hard to fix in the present. With Web 3.0, we have a chance to
account for potential attack vectors by design – otherwise, the same
issues will replicate themselves with greater potency than ever.”
