Office 365Demystifying SPF/DKIM/DMARC

Agenda

1. Phishing and Spoofing
2. Fighting Phishing
3. How to read a Message Header and a Message Trace

What is email?

A method of exchanging digital messages from an author to one or more recipients
Email is defined by the following standards:
RFC 5321 defines the host-to-host protocol (Envelope)
RFC 5322 governs the content of messages (Header and Body)
The P1 header is used to route a message, and is not displayed as part of the message. It contains values in the MAIL FROM and RCPT TO commands of the SMTP connection
MAIL FROM: sender@contoso.com
RCPT TO: recipient@fabrikam.com
The P2 header is what you see when you open a message in your email client.
FROM: sender@contoso.com
TO: recipient@fabrikam.com

What is Phishing?

A targeted attack to corporate users to harvest Personal information or username and passwords
Evolution of Phish
If its Targeting Individual the motive is mostly financial
if the target is an organization then the motive is mostly Network compromise

What to find for in a Phishing Email?

1. A bank or financial institution.  Phishes come from banks or online financial institutions like Paypal or eBay where money can change hands.
2. Your account has been compromised or is about to expire. In the sample above, the bank claims to have noticed that your account has had some suspicious activity.  This plays on your fear that maybe someone did break into your account.  After all, haven’t we heard stories that banks have been losing people’s personal information?
3. A threat.  If you don’t fix this problem within a certain period of time, your account will disabled and then you’ll really be in trouble.
4. Don’t worry, click here to fix it.  To remedy the problem — that your account will expire, or to lock down your account or change your password — follow the link in the message which will take you a web page to fix it.
5. A fake link. You’ll see a link in the message that appears to be from the bank (in the example, it’s supposedly a secure site going to woodgrove) but if you hover your mouse over it, the link actually points somewhere else.  This is simply a trick using HTML coding.
6. Poor grammar.  I’ve italicized this because it does not occur in every phishing message.  However, if you get a message from a bank that contains lots of spelling mistakes and poor verb tenses (you know, the complete opposite of my blog), then you can be certain it didn’t come from the purported source.

The common types of phishing we see today

Spoofing your exact domain in the From: address

From: Mr William <william@christopher.com>
To: Mr Abhinav <abhinav@christopher.com>

These attacks are really tricky. When you use Exchange and Outlook, and an email comes in that looks like it’s from someone in your Global Address Book, Outlook will show that person’s photo from Active Directory. This can trick you into thinking the email is real, even if it’s not.
This problem affects the whole industry. To fix it on your own, you can set up SPF, DKIM, and DMARC records for your domain. If you can’t do that, don’t worry. Exchange Online Protection (EOP) has an anti-spoofing feature that works even if you don’t have those records. It’s going to be turned on for everyone automatically, so your domain will be safe right from the start

Lookalike spoofing

From: Mr William <william@christ0pher>
To: Mr Abhinav <abhinav@christopher.com>

Lately, there’s been a rise in a certain type of email attack, about 1 in every 10 spear phishing attempts. These attacks involve email domains that look correct at first glance because they use Numeric characters which replaces “o”. This means the fake domain has one or more letters that are different, but it’s hard to notice at first.
Scammers do this to bypass security measures like SPF, DKIM, and DMARC. They’re counting on the fact that a legitimate domain can’t possibly register every similar-looking domain. One downside for these scammers is that if you reply to their email, your response won’t go through unless they’ve set up a receiving email server for that fake domain. Moreover, if you’re using Exchange and Outlook, you won’t see a photo next to the email address because the fake domain won’t be in your Global Address Book. This gives away the scam because it lacks this extra layer of deception.

‘Display From’ attacks

From: Mr William <william@gmail.com>
To: Mr Abhinav <abhinav@christopher.com>

In this scam, the fraudster sends an email to the company’s CFO from a common free email service, like Gmail, Yahoo, or Outlook.com, pretending to be the CEO. The CFO might think the CEO is emailing from his personal account because he can’t access his work one, perhaps using a mobile phone.
These kinds of attacks work because it’s quite easy to make email accounts that look real. Scammers can find names from LinkedIn, then set up accounts with those names at free email services. These messages can even pass through security checks like SPF, DKIM, and DMARC, because they’re sent from trusted IPs. They use everyday language, which can trick people into thinking the email is genuine.
However, there’s a catch, much like the one mentioned earlier. If the company uses Exchange and Outlook, the CEO’s photo won’t show up in the email because the scammer’s email address isn’t in the Global Address Book. Also, the recipient is likely to see the full email address, which might not be recognized since it’s not in their address book, revealing that it’s not the actual CEO.

Phishing vs Spoofing

Spoofing involves pretending to be someone else to deceive the person receiving the message into doing something they wouldn’t normally do.

Phishing attack is when the person sending the message attempts to deceive the recipient into revealing private information that leads to financial profit for the attacker.

It’s important to understand the distinction: while phishing often involves impersonating a credible entity to gather information, spoofing doesn’t always aim to collect data. Sometimes, the goal of spoofing is just to manipulate the recipient into installing harmful software.

How to Fight them?

There are three mechanism which can help us fight Spoofing.

• SPF
• DKIM
• DMARC

What is SPF?

•Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain’s administrators

•Sender Policy Framework is defined in RFC 7208

•The list of authorized sending hosts for a domain is published in the Domain Name System (DNS) records for that domain in the form of a specially formatted TXT record

•A receiving mail server performs an SPF check by confirming that the connecting IP address is in the SPF record for the 5321.MailFrom domain.

Ex. christopher.com TXT v=spf1 ip4:103.309.10.23 ip4:120.90.2.9 include:spf.protection.outlook.com include:sharepointonline.com -all

How does SPF work?

SPF and MX records that do not point to EOP

•The advanced spam filtering (ASF) option SPF record: hard may generate lots of false positives for users who have the option enabled if the primary MX record doesn’t point to Exchange Online Protection (EOP)

•Within EOP, the SPF check is performed on IP address 2. (This is the on-premises mail server’s relaying IP address.) However, the SPF check should have been performed on IP address 1. (This is the original connecting IP address.) Because EOP uses IP address 2 instead of IP address 1, any domain that publishes an SPF hard fail will fail SPF and will be marked incorrectly as spam. This occurs even if the domain would originally have passed SPF if the messages had been sent first through EOP and then to the on-premises mail server.

SPF is not enough… What else?

Email forwarding breaks SPF check

Problem: Forwarding email breaks SPF check. Weak SPF check on shared IP. The 5322.From address can be spoofed

Weak SPF validation on shared IP

Solution: Authenticated digital signature – DKIM
Sender authentication – DMARC

What is DKIM?

•DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is authorized by that domain’s administrators.

•DKIM is intended to prevent forged sender addresses in emails, a technique often used in phishing and email spam.

•DKIM allows the receiver to check that an email claimed to come from a specific domain was indeed authorized by the owner of that domain which is done using cryptographic authentication.

•Verification is carried out using the signer’s public key published in the DNS

•The DKIM-Signature header field consists of a list of tag=value parts:

• b = the actual digital signature of the contents (headers and body) of the mail message
• bh = the body hash
• d = the signing domain
• s = the selector
• h = the order of selected header fields that are hashed

Ex. v=1; a=rsa-sha256; c=relaxed/relaxed; d=christopher.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HLYdM5QF/Xh6qSCBbxOV29tQIzSp+Tt42Ey6ncnY++8=; b=Ed+ltN/9S3+JX+I6wIgvqqUZGRc/eh+ECwQltwTJQQyYQtD2A0xDyeCsYQ5Es2W+RJz4/6ZsD5CNqCHaDpw08DoZp6DY33JoDfVgVDYtbuErzUhi97A/9CeaPi9nfFGUxDoEhj7TXE1ROJvWHQpQBLy8/nCEYc5/SNriK7uBNpg=

How to enable DKIM

The first step would be to publish two CNAMEs in the public DNS in the following form:
Host name: selector1._domainkey
Points to address or value: selector1-.domainkey.
TTL: 3600

Host name: selector2._domainkey
Points to address or value: selector2-.domainkey.
TTL: 3600

The usage of two CNAMEs is directly related to the key rotation performed in Office 365 every 365 days.

The Customer has to perform this for each domain (that needs outbound signing) that you are hosting in Office 365.

Next, the Customer has two options: PowerShell or GUI. From PowerShell we will have to enable the DKIM signing policy:

New-DkimSigningConfig –DomainName <domainGUID> –Enabled $true

How does DKIM work?

DKIM – Domain Key Identified Mail

Email content is signed using private key. The recipient decrypts using public key. Public key look up based on DNS of signing domain in the DKIM header

DMARC does not fail when being forwarded

The advantage of DKIM is that it can survive being forwarded

Check DKIM status in Email Header

If the DKIM-signature ever fails to validate, it should be stamped in the header after the dkim=<result> value in parenthesis, and all in lower-case. Below is an Example Header information that shows the status of DKIM.

spf=pass (sender IP is 209.85.216.49) smtp.mailfrom=tripathi.com; dkim=pass (signature was verified) header.d=tripathi.com;dmarc=pass action=none header.from=aaddress.in;compauth=pass reason=100

Composite authentication

The results of Microsoft 365’s implicit authentication checks are combined and stored in a single value named composite authentication or compauth for short. The compauth value is stamped into the Authentication-Results header in the message headers. The Authentication-Results header uses the following syntax:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Different Authentication-Results bases on Scenario

Scenario: The Tripathi.com domain has no SPF, DKIM, or DMARC records

Result: Messages from senders in the fabrikam.com domain can fail composite authentication

Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=tripathi.com; christopher.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=tripathi.com; compauth=fail reason=001
From: Abhinav@tripathi.com
To: william@christopher.com

Scenario: The tripathi.com domain has an SPF record and no DKIM record. The domains in the MAIL FROM and From addresses match.

Result: The message can pass composite authentication, because the domain that passed SPF matches the domain in the From address

Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=tripathi.com; christopher.com; dkim=none
  (message not signed) header.d=none; christopher.com; dmarc=bestguesspass
  action=none header.from=tripathi.com; compauth=pass reason=109
From: abhinav@tripathi.com
To: william@christopher.com

Scenario: The tripathi.com domain has a DKIM record without an SPF record. The domain that DKIM signed the message matches the domain in the From address.

Result: The message can pass composite authentication, because the domain in the DKIM signature matches the domain in the From address

Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=tripathi.com; christopher.com; dkim=pass
  (signature was verified) header.d=outbound.tripathi.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=tripathi.com; compauth=pass reason=109
From: abhinav@tripathi.com
To: william@christopher.com

Scenario: The domain in the SPF record or the DKIM signature doesn’t match the domain in the From address.

Result: The message can fail composite authentication

Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; christopher.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=christopher.com;
  compauth=fail reason=001
From: william@christopher.com
To: Abhinav@tripathi.com

Different Status of DKIM in Email Header

• Pass: DKIM validation passes
• Fail: DKIM validation fails (message contains a DKIM header but validation fails)
• Ignore: DKIM validation not performed because the public key is less than 1024 bits, or the DKIM-signature exists but the signature was not verified
• Timeout: Message contains a DKIM header but DNS lookup times out
• Error: Message contains a DKIM header but DNS lookup returns an error
• None: Message does not contain a DKIM header. In this case, the header.d= should be none

There are several causes for the following two errors:

• body hash did not verify
• signature did not verify

Possible causes:

• The message may have been modified (perhaps by a mailing list or forwarder) in transit;
• The signature or hash values may have been calculated or applied incorrectly by the signer;
• The wrong public key value may have been published in DNS; or
• The message may have been spoofed by an entity not in possession of the private key needed to calculate a correct signature.

Logs we can check when DKIM Fails:

We can run the following PowerShell command to check the status

Get-DkimSigningConfig -Identity <yourdomain.com> | fl *publickey*, *cname*, status

What is DMARC?

• Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email-validation system designed to detect and prevent email spoofing.
• It provides a mechanism which allows a receiving organization to check that incoming mail from a domain is authorized by that domain’s administrators and that the email (including attachments) has not been modified during transport.
• DMARC is intended to combat certain techniques often used in phishing and email spam, such as emails with forged sender addresses that appear to originate from legitimate organizations.
• DMARC is specified in RFC 7489
• DMARC policies are published by domain owners and applied by mail receivers to the messages that don’t pass the alignment test. The domain being queried is the author domain, that is the domain to the right of @ in the From: header field. The policy can be one of none the so-called monitor mode, quarantine to treat the message with suspicion according to the receiver capabilities, or reject to reject the message outright. Reject policy is fine for domains that don’t have individual human users, or for companies with firm staff policies that all mail goes through the company mail server, and employees don’t join mailing lists and the like using company addresses, or the company provides a separate less strictly managed domain for its staff mail. Strict policies will never be appropriate for public webmail systems where the users will use their mail addresses any way one can use a mail address.

How Does DMARC Work

DMARC uses Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to authenticate the 5322.From address.

DMARC will pass if an SPF or DKIM check passes and the domain in the 5321.MailFrom and 5322.From addresses match. This means that DMARC will always fail if the domain of the 5321.MailFrom does not match the domain of the 5322.From.

DMARC Reporting – Feedback loop

The 5322.From and the domain that is authenticated (using either SPF or DKIM) must be the aligned 

DMARC Policy

• A DMARC policy allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes, such as quarantine or reject the message. DMARC removes guesswork from the receiver’s handling of these failed messages, limiting or eliminating the user’s exposure to potentially fraudulent and harmful messages.
• Another great feature of DMARC is that it also provides a way for the email receiver to report back to the sender about messages that pass or fail DMARC evaluation. To ensure the sender trusts this process and knows the impact of publishing a policy different than p=none (monitor mode), the receiver sends daily aggregate reports indicating to the sender how many emails have been received and if these emails passed SPF and/or DKIM and if they were aligned. This greatly helps organizations deploying SPF and DKIM as they can slowly deploy these features and monitor them without first blocking or rejecting any emails.
• DMARC policies are published using DNS TXT resource records and announce what an email receiver should do with non-aligned mail it receives. Because the specification is available with no licensing or similar restriction, any interested party is free to implement it.

Below is an example of DMARC Record which is a TXT in office 365

_dmarc.christopher.com

v=DMARC1; p=quarantine; rua=mailto:dmarkreport@christopher.com; ruf=mailto:dmarkreport@christopher.com; adkim=r; aspf=r; pct=20; rf=afrf; sp=quarantine

Lets Understand What each values in the above TXT record means: