Frequently Asked Questions

The incident severity levels align to the likelihood that an unsuspecting mail receiver will accept maliciously spoofed emails using your domain

1. Secure Mitigated The domain either has no mail authentication issues associated with it, or all issues have been mitigated by a superceding mail authentication protocol.
2. Low In most cases, this issue won't adversely impact the security posture of the target domain. It may however adversely impact the delivery of legitimate mail due to mail receivers significantly increasing spam reputation ratings.
3. Medium Mail receivers with relaxed spam/spoof reputation checks will receive maliciously spoofed emails from the target domain. Recipients can rely on authentication checks, however may still accept spoofed emails due to the lax authentication configurations set by the spoofed domain.
4. High Mail receivers with moderate spam/spoof reputation checks will receive maliciously spoofed emails from the target domain. Recipients have minimal to no capability to perform authentication checks.
5. Very High Mail receivers with hardened spam/spoof reputation checks will receive maliciously spoofed emails from the target domain. Threat actors are able to send SPF authenticated emails.

“Email spoofing is when the sender of an email forges (spoofs) an email headers 'From' address, so the message appears to have been sent from a legitimate email address.”

Email spoofing is typically a key component of successful phishing campaigns and given the ever-looming threat of Business Email Compromise (BEC), we each need to do our part to ensure domains we own aren’t capable of being maliciously spoofed.

Keeping this in mind, email spoofing comes in many forms and may incorporate phishing techniques to trick a recipient into thinking the email originates from a legitimate address. Various email spoofing/phishing mechanisms are detailed below:

1. Domain spoofing through abuse of inadequately configured SPF records
2. Domain spoofing through SPF-bypass, abusing an inadequately configured DMARC record
3. Domain spoofing through SPF domain take-over
4. Domain spoofing through SPF IP address take-over
5. Domain spoofing through DKIM private key compromise
6. Domain spoofing through mail server compromise

CanIPhish looks to provide visibility over techniques 1, 2 and 4. Available mitigations for the remaining items have been detailed in this CanIPhish Article.

The Senders Policy Framework (SPF) has historically been a key source of truth for identifying where authorised mail senders are located (e.g. X.X.X.X IP address is authorised to send emails on behalf of XYZ.com). Unfortunately, there’s an inherit weakness in the SPF protocol whereby threat actors can trick mail receivers and ultimately bypass SPF checks.

To fix this loophole the DMARC protocol was introduced which includes a security fix ensuring SPF-bypass attacks can’t occur. To allow DMARC to enforce these protections, the DMARC policy for a domain needs to be set to a ‘quarantine’ or ‘reject’ configuration.

I won't delve too deep into this as it's an entire topic on its own – See this GitHub Project for further explanations and a demonstration.

Note: Due to recent changes in the way many mail clients operate, users can be taught through security awareness training to identify spoofed emails utilising SPF-bypass mechanisms (see highlighted text). Spoofed emails utilising this technique may have the "From:" field appear as follows:

From: John Doe <spoofed@domain.com> (John Doe via malicious-domain.com)

The Sender Policy Framework (SPF) is an email authentication method designed to detect forging sender addresses during the delivery of the email. SPF allows the receiving mail server to check during mail delivery that a mail claiming to come from a specific domain is submitted by an IP address authorised by that domain's administrators. The list of authorised sending hosts and IP addresses for a domain is published in the DNS records for that domain.

SPF alone, though, is limited only to detect a forged sender claimed in the envelope of the email (hidden from end-users) which is used when the mail gets bounced. Only in combination with DMARC can it be used to detect the forging of the visible sender in emails, a technique often used in business email compromise attacks, phishing emails, email scams and other cyber threat activities.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorised use (i.e. spoofing). The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing emails, email scams and other cyber threat activities.

DMARC extends two existing email authentication mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It allows the administrative owner of a domain to publish a policy in their DNS records to specify which mechanism (DKIM, SPF or both) is employed when sending email from that domain; how to check the From: field presented to end users; how the receiver should deal with failures - and a reporting mechanism for actions performed under those policies.

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in emails (email spoofing), a technique often used in phishing and email spam.

DKIM allows the receiver to check that an email claimed to have come from a specific domain was indeed authorised by the owner of that domain. It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message. The recipient system can verify this by looking up the sender's public key published in the DNS. A valid signature also guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed.

Usually, DKIM signatures are not visible to end-users, and are affixed or verified by the infrastructure rather than the message's authors and recipients.

The Filter Status indicates whether the Email Spam and/or Malware Filter is vulnerable to bypass through either a Direct Mail Attack or a Bounce Attack. Read this CanIPhish Article for a full breakdown of the Bounce Attack. Read this Blog Post for a full breakdown of Direct Mail Attacks.

1. Bounce Attack: In summary, this vulnerability occurs when organisations are using Exchange On-premise (i.e. Exchange Server 2010/13/16/19), Exchange Online or a third-party Secure Email Gateway with the default Non-Delivery Report (NDR) set for their Email Postmaster. The vulnerability itself allows threat actors to see what spam and malware filtering technologies are in-use, the rules, the actual scoring and the version of said technologies.
2. Direct Mail Attack: In summary, this issue specifically relates to organisations who are using cloud-hosted third-party filtering providers with a cloud-hosted mail exchange service (e.g. Exchange Online, Gmail, etc.). Target organisations typically incorporate third-party mail filters by updating their MX record to direct in-bound mail to the filtering provider for analysis (e.g. *.glsb.pphosted.com for ProofPoint). The problem with this is that unless the appropriate lockdowns are applied, threat actors can simply configure their mail server to send emails directly to the cloud-hosted exchange, effectively bypassing the third-party spam/malware filter.

The IP Status indicates whether the IP address is Secure or associated with:

1. Unsolicated Bulk Emails, Spam Operations & Spam Services (i.e. Low Reputation Senders)
2. Snowshoe spam, whereby spammers are actively attempting to evade spam detection (i.e. Low Reputation Senders)
3. Hijacked endpoints infected by illegal 3rd party exploits, including open proxies (HTTP, socks, AnalogX, wingate, etc), worms/viruses with built-in spam engines, and other types of trojan-horse exploits.
4. End-user (non-MTA) addresses which are dynamically allocated to residential users (i.e. Low Reputation Senders)