Log4Shell Targeted by Email Attackers in Two Campaigns


The Zix | AppRiver team spotted two campaigns in which email attackers attempted to exploit a recently disclosed Log4j vulnerability on susceptible systems.

A Bit of Background on Log4j

As explained by the U.S. Cybersecurity & Infrastructure Security Agency (CISA), the Log4j vulnerability (detected as CVE-2021-44228 and dubbed “Log4Shell”) is a critical remote code execution flaw that affects versions 2.0-beta9 to 2.14.1 of Log4j, Apache’s Log4j software library which services can use to log security and performance information. Those services include background modules that that help to process email header information as well as perform analytics and reporting.

CVE-2021-44228 affects Log4j’s Java Naming and Directory Interface (JNDI) insofar as some of its features “do not protect against adversary-controlled LDAP [Lightweight Directory Access Protocol] and other JNDI related endpoints.” Malicious actors can use a specially crafted request to exploit the flaw and execute arbitrary code for the purpose of infecting the system, exfiltrating information, and/or deploying ransomware. For the purposes of this article, they can launch an email attack where Log4j parses a string, executes malicious code, and compromises a system that attempts to log information about the email.

Campaign #1: A Slack Workplace Invitation

As soon as it learned of the Log4j vulnerability’s disclosure on December 10, 2021, the Zix | AppRiver team prepared itself for attack attempts to begin spreading over organizations’ email systems. It was just four days later when the team detected the first such attempt. In the weeks that followed, those attacks grew in frequency and creativity.

Which brings us to one campaign flagged by the Zix | AppRiver team in the beginning of January. For this attack, someone by the name of “Smith John” invited a recipient to join a Slack workplace. The invite came with a unique workplace name crafted to exploit CVE-2021-44228.


Screenshot of the Slack workplace invitation. (Source: Zix | AppRiver)
Screenshot of the Slack workplace invitation. (Source: Zix | AppRiver)


“I assume the attacker is hoping that the attempt would be logged by a vulnerable system and trigger the exploit,” noted Troy Gill, senior manager of threat intelligence at Zix | AppRiver. “We don’t know for sure if that was strictly intended as an email attempt or if the attacker was trying to send the exploit via Slack and that action triggered an email. Or both maybe?”

Campaign #2: An AWS Attack

It was around that same time when the Zix | AppRiver team came across another attack that attempted toe exploit the Log4j vulnerability. Whoever designed this attempt dispensed with concealing their efforts behind a well-known brand like Slack. Instead, they sent out an email with the exploit code for Log4Shell included not only in the subject line but also in the body of the attack email.


Screenshot of the attack email. (Source: Zix | AppRiver)
Screenshot of the attack email. (Source: Zix | AppRiver)


Gill and his team analyzed the email and found that its sender had data theft on their mind.

“It was trying to retrieve multiple AWS items along with java and virtual machine information,” he pointed out. “This AWS attack tried to retrieve the secret access key, session token, shared credentials file, web identity token file, profile, config file, and access key ID. I’m not sure about the efficacy of this attack, but it is certainly being attempted.


Screenshot of some of the AWS items targeted by the attack email. (Source: Zix | AppRiver)
Screenshot of some of the AWS items targeted by the attack email. (Source: Zix | AppRiver)


How to Defend Against Email Attacks Targeting CVE-2021-44228

The campaigns described above highlight the need for organizations to defend themselves against attack attempts that seek to exploit CVE-2021-44228. One of the ways they can do that is by using an email security solution that can analyze incoming messages for known vulnerabilities and other malicious indicators. Simultaneously, organizations should seek to patch Log4Shell using their vulnerability management programs.