Log4j: exploit attempts from all angles, including DMARC reports

If you’ve been online at all in the last week you’ll most likely have come across several articles about the log4j vulnerability. Companies around the world are still scrambling to assess whether they are vulnerable, and patching up their systems in an attempt to stay secure.

What is the log4j vulnerability?

Every software application produces logs that are used for various purposes including auditing, alerting about errors, checking that the system is working, etc. Making sense of this output and funneling parts of it to different systems can become quite complex, especially if there’s a requirement to change these rules dynamically. 

In 2013 a change was added to log4j, a popular logging library for Java systems, that allowed external systems to dynamically alter its behaviour. The side effect of this change was that this interface was now too permissive, allowing external systems to run any arbitrary code into the vulnerable system.

At first glance, it might seem that this is a network or web-based attack that could be trivially patched by a WAF (Web Application Firewall) rule. But the reality is that in today’s complex and interconnected systems there may well be several ways hackers can use to get to a vulnerable system. 

Security analysts are finding attempts to exploit via filename, metadata and contents, usernames, cookies, and more. In summary, any type of input that could potentially be read and executed by a machine could leave your systems vulnerable.

DMARC reports as another exploit attempt

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the modern email authentication standard used by all major email servers (Office 365, Google Workspace, and commercial secure email gateways) to authenticate outbound and inbound email. When implemented by an organization at the strongest policy of p=reject, it stops bad actors from impersonating its domain to send malicious emails. It’s an open standard and is used by organizations around the world to protect employees, customers, and supply chains from phishing attacks, and brand reputations from exploitation. 

As part of auditing our own systems to ensure that we were not affected by this vulnerability, we at Red Sift spotted another creative exploit attempt. Given the nature of the DMARC protocol, the email address of the reports’ processor for a given domain is public knowledge, and there is also a standard describing the format of such a report. And for this reason, our processing of DMARC reports includes careful validation of the various input fields to make sure they conform to the standard. 

Last week our validation engine flagged a few non-compliant reports and upon further investigation, we identified them to be attempts to exploit the log4j vulnerability. A malicious actor tried to compose a DMARC report that contained the JNDI exploit string as part of one of the fields:

Here, the hackers were hoping that one of our systems would somehow execute the <source_ip> line and trigger the exploit. However, in our case, we don’t use log4j as part of our software stack and have strong validation in place that would capture this attack even if we did. So, this record was rejected and this was an unsuccessful attempt.

Final considerations

The log4j vulnerability will still be around for some time and security teams will have a busy holiday season patching up systems. But our advice for organizations is to be thorough in their assessment. Don’t only look internally but also at your supply chain, given the number of ways this vulnerability can be exploited.

Ultimately this is another stark reminder that hackers will try all channels as a way to infiltrate a system, not only the obvious ones. But in light of such a serious issue, we’ll leave you with some (appropriate) humour about the nature of what we’re facing. Thank you internet creative hive.

To start protecting your business, brand, customers, and supply chain from impersonation attacks, why not sign up for a free trial of our award-winning product OnDMARC?


Randal Pinto

20 Dec. 2021



Recent Posts


The best tools to protect yourself from SubdoMailing

Francesca Rünger-Field

In late February 2024, ‘SubdoMailing’ became a trending search term overnight. Research by Guardio Labs uncovered a massive-scale phishing campaign that had been going on since at least 2022. At the time of reporting, the campaign had sent 5 million emails a day from more than 8,000 compromised domains and 13,000 subdomains with several…

Read more
Product Release

Red Sift’s Spring 2024 Quarterly Product Release

Francesca Rünger-Field

This early into 2024, the cybersecurity space is already buzzing with activity. Emerging standards, such as Google and Yahoo’s bulk sender requirements, mark a new era of compliance for businesses reliant on email communication. At the same time, the prevalence of sophisticated cyber threats, such as the SubdoMailing campaign, emphasizes the continual hurdles posed…

Read more

Navigating the “SubdoMailing” attack: How Red Sift proactively identified and remediated a…

Rebecca Warren

In the world of cybersecurity, a new threat has emerged. Known as “SubdoMailing,” this new attack cunningly bypasses some of the safeguards that DMARC sets up to protect email integrity.  In this blog we will focus on how the strategic investments we have made at Red Sift allowed us to discover and protect against…

Read more

Where are we now? One month of Google and Yahoo’s new requirements…

Rebecca Warren

As of March 1, 2024, we are one month into Google and Yahoo’s new requirements for bulk senders. Before these requirements went live, we used Red Sift’s BIMI Radar to understand global readiness, and the picture wasn’t pretty.  At the end of January 2024, one-third of global enterprises were bound to fail the new…

Read more