DKIM Replay Attacks: Preventive Measures to Protect Email Deliverability

Malicious actors are always looking for a means to get their spam into the inboxes of unsuspecting victims. Just recently we reported on how domain reputation was being stolen (shared) for all domains under certain unofficial top-level domains (or TLDs). While that pattern is still on-going, we are now seeing other domain reputation theft trends emerge. 

DKIM Replay is Being Used as an Attack Vector Again

Stealing sender reputation from legitimate email senders is critical to attacking modern anti-spam systems since they rely so heavily on reputation for inbox delivery. One of the primary domain reputation hijack mechanisms is an old technique commonly referred to as DKIM Replay.

The concept of this attack is that DKIM signing creates a relationship between message content and a domain. If a malicious actor can generate a single message with their desired content, and that message has a DKIM signature applied, then that same message can be resent (“replayed”) repeatedly. And if the content of the message doesn’t change, the DKIM signature should still validate properly, making spam and malicious emails appear legitimate.

DKIM was designed to authenticate mail in a non-path-based mechanism, and the ability for a message to be signed once and then be re-sent is a feature, not a flaw. In fact, mailing lists, distribution lists, mail forwarding, and other message redistribution mechanisms rely on DKIM and its ability to persist through multiple transit hops.

Abusing DKIM signed messages via these replay attacks is not a new abuse technique. The popularity of these attacks has risen and fallen over time. For whatever reason there are some spam groups that picked up this technique in the last few months and have been hopping from one Email Service Provider (or ESP) to another over the last few months. The attacks all follow a very specific pattern:

1. The attacker signs up for a free trial or free account at an Email Service Provider
2. The attacker sends one single message to themselves often through a test message feature, which is DKIM signed by the Email Service Provider
3. The attacker’s account doesn’t set off any traditional red flags for being a spam account as far as the ESP is concerned. Only one message was sent and it was delivered successfully. There are no spam complaints because the message was sent to the attacker’s own email address. Finding these accounts can be difficult without the proper resources.
4. The attacker takes that resulting message and resends it using bullet-proof hosted mail servers or botnet compromised machines it can access. This is outside the control of the original ESP that sent the message.
5. A mailbox provider receives the spam message, verifies the legitimate DKIM signature from the ESP and treats the message with additional trust because of that signature.
6. The Email Service Provider is left with little recourse to stop the flow of the spam and prevent damage to domain reputation.

How to Know if you are Being Attacked

Today, it appears these attacks are mostly focused at Gmail. This may be because Google’s spam filtering logic is more heavily weighted on domain reputation than other top providers. When a filter focuses so heavily on a metric, it makes that metric an attractive target for malicious actors to manipulate. It is unclear if other mailbox providers would be as susceptible as Google is to these specific attacks, given they all use their own, less domain-focused spam filtering logic.

When a service provider is attacked there are very few signs of the abuse. One of the best means of identifying an attack is by monitoring data in Google Postmaster Tools. The domains used by an ESP to DKIM sign messages may experience a rapid drop in overall domain reputation at Google. The degree to which reputation decreases is dependent on the volume of replay spam that is distributed. Some other interesting side effects are the appearance of new, unrelated bad reputation IP addresses appearing in Google Postmaster Tools, a reduction in Encryption rates, and an increase in Delivery Errors.

 How Service Providers Can Fight Back

There are a few key aspects of this attack that must exist for it to be successful to bad actors:

1. The attacker must be able to easily create an account with an email provider for this to work. Enterprise-tier ESPs with complex sales-led on-boarding processes are significantly less likely to be abused via DKIM Replay.
2. The attacker must be able to have control over the message body.
3. The ESP must use their own DKIM signature on the message and that DKIM signing domain must have a very good reputation. Email Service Providers that send non-permissioned “cold” email and have poor reputations are less likely to be targeted since their domains hold less value to attackers.

One interesting aspect to these attacks is that messages are commonly modified by the attacker. This is interesting because changing message content usually would break a DKIM signature. The attackers are very clever though, and they are simply adding duplicate headers. The redundant headers they add are often ones like the subject line. These header fields are added to the messages by the attacker prior to resending them, but after they have been DKIM signed.

To help our customers combat DKIM replay attacks here at SocketLabs, we’ve taken the following actions:

1. Implementation of DKIM over-signing to protect against attackers adding an additional subject, to, from, date or reply-to headers to a message. The concept of DKIM over-signing is that you can sign headers that do not already exist in a message. So you can DKIM sign the subject field twice – once for the actually present subject, and once for an essentially NULL subject. If an attacker adds another subject line to a message then this second entry will cause the original DKIM signature to break as the second subject isn’t NULL.
2. We have reduced the signature validation time window. This is the X= timestamp in the DKIM signature. In previously generated DKIM signatures we would specify the signature expiration to be 30 days after the signature was generated. We’ve reduced this to just 3 days now for most SocketLabs cloud customers. Since our proprietary Hurricane MTA performs DKIM signing at the last possible moment right before delivery of a message we are investigating if there is any value in further reducing the validation period possibly restricting the window which signatures can be replayed.

Additional Measures to Protect your Company’s Sender Reputation

Feeling a little uneasy? Not to worry! There are things you can do to dissuade these attackers from using your platform as their jumping off point for a DKIM Replay attack.

Don’t permit unvetted users control over the subject line. In combination with DKIM over-signing, removing control over the subject line from test messages generated in a WYSIWYG or in a campaign creation tool goes a long way in dissuading attackers from using your platform in these types of attacks. Attackers are marketers at heart and understand the value of a subject line in generating engagement from recipients of their spam.

Make yourself a less attractive target by globally suppressing the recipient addresses being used in the attacks. DKIM Replay attacks really only work at scale since most of the attacker’s tasks are automated. While suppressing the initial target (I.e., recipient addresses associated with the attack) will not prevent the attacks, it forces the attacker to adjust their automations and scripts, making you less attractive to abuse.

Shut down the links they generate ASAP. The length of time you allow links (such as call-to-action buttons, or CTAs) to remain viable determines how interesting you are as a target. The initial messages are generated and then abused at scale very quickly. We’re talking about a mere couple of minutes here. But the attackers can’t control when unsuspecting email recipients will engage with a given message, so the length at which links are live is watched closely by the attackers. Shutting them down quickly will reduce their interest in you as a target—you’re simply not worth the effort. If you are not already open and click tracking test messages, then you may want to consider adding this and monitoring related data closely. This data may be an alternate avenue to identifying attacks outside of Google Postmaster Tools.

Rotate DKIM keys. These attacks happen very quickly, so while rotating your DKIM keys regularly is a best common practice supported by M3AAWG, it isn’t a full stop mitigation method for DKIM Replay attacks. It can however be extremely useful when used in combination with other mitigation methods. Rotating DKIM keys after implementing over-signing for example will make sure the attacker can’t replay older messages. Also, in the case that you can identify and shut down a large volume of malicious accounts replicating this behavior, you can rotate DKIM keys to prevent messages from those accounts from being replayed. Ultimately though rotation alone doesn’t stop the attacker from creating new accounts and messages.

Make it harder for malicious accounts to generate even one single message. Most of the accounts being created to generate the messages for these attacks are done with throw-away email addresses or brand-new Gmail accounts. We are finding they use anonymizing VPNs (also known as virtual private networks) or TOR connections to obfuscate detection. Stepping up fraud detection at the point of account creation with a tool like Maxmind, E-hawk, or Sift goes a long way towards preventing these attacks. These fraud tools make the accounts created to generate DKIM Replay attack messages (and other types of spam) more obvious and much easier to catch both in real-time, and after the fact.

Don’t DKIM sign test messages or any message that looks like spam. While this is easier said than done for most ESPs, you can look for common traits of the attack messages, such as short URLs in the body of messages and route those messages, along with other potential spam messages, through a transit path where DKIM signing is disabled, or where you sign with a different domain. Here at SocketLabs we are working on more advanced pathway routing tools to better help customers and Email Service Providers accomplish more complex tasks like this.

Need Professional Guidance?

If you think you may have been affected and are looking for a responsive email delivery partner who can help with deliverability and compliance issues, check out our Concierge Email Solution. This email package combines our best reporting and analytics with hands-on expert guidance at every step in your email journey. From migration to deliverability, compliance and strategy, we have the dedicated resources you need to get your email where it needs to be. Learn more here.