At the Dutch Tax and Customs Administration, we’ve worked for years to build a strong relationship with taxpayers based on trust.
We believe improving and sustaining this relationship will help us to collect taxes in an improved and sustained way, and supporting initiatives such as #NoMorePhishing is one important way we continue to do this.
As a high-profile public-sector organization, we deal with phishing emails, like the one below, every day.
Van: Belastingdienst belastingaangifte@belastingdienst.nl Datum:23-08-2015 11:05:10 CEST Aan: xxxxxx@planet.nl Onderwerp: Belastingaangifte 2014 Bij controle van onze administratie hebben wij geconstateerd dat er een betalingsachterstand is ontstaan van uw belastingaangifte 2014. Wij hebben geprobeerd om het openstaande bedrag te incasseren, helaas is dit niet gelukt op het rekeningnummer dat bij ons bekend staat. Het huidige openstaande bedrag bedraagt 83,04 euro. U ontvangt ook een schriftelijke herinnering die vandaag per post is verstuurd. Thans verzoeken wij u vriendelijk om dringend het openstaand bedrag van ... Te betalen u kunt het bedrag overmaken naar bankrekeningnummer NL62ABNA XXXXXXXXX tnv belastingdienst" onder vermelding van betalingskenmerk BTW038372293N Als u deze betaling heeft voldaan kunt u de brief als niet verzonden beschouwen. Als u binnen acht dagen deze rekening niet heeft voldaan dan verzenden wij geen aanmaning en hierbij worden incasso kosten gerekend Ik hoop u voldoende geinformeerd te hebben. Wij zien uw betaling graag tegemoet en danken u voor uw medewerking. Met vriendelijke groet, Robert Versteegen Directeur Belastingdienst N.B. Dit is een automatisch verzonden e-mail, het is niet ogelijk deze e-mail te beantwoorden.
Figure 1 — An example of a real-life phishing email.
In the above real-life example, a targeted Dutch taxpayer received an email stating they had to pay a tax installment of €83.04 via a money transfer to a bank account (which was that of a money-mule) or extra collection costs would be charged.
Normally the first giveaway of this being a phishing email would be the email address, but in this instance it is the same as the Dutch Tax and Customs Administration — belastingdienst.nl. Because we had not yet implemented the standards below it was possible to misuse our email address.
By using best current practices such as RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email — we have developed a universally applicable technique to identify phishing attacks that are carried out under the guise of the Dutch Tax and Customs Administration. This technique — a precondition is access to DNS logging — can provide insights into where the phishing emails are sent from and to whom the phishing emails are sent.
In this post, we will discuss the freely available standards, policies and protocol we used, including STARTTLS, SPF, DKIM, DMARC, DANE and MTA-STS. We firmly believe that if these techniques are used everywhere, it will lead to a significant decrease in phishing emails.
STARTTLS
STARTTLS is a method of upgrading a plain text communication channel to a secure, encrypted communication channel. It makes it possible to create a secure, encrypted Simple Mail Transfer Protocol (SMTP) connection between mail servers.
However, there is a serious issue with STARTTLS — it is vulnerable to Man-in-the-Middle (MITM) attacks. This issue can be mitigated by using either DNS-Based Authentication of Named Entities (DANE) for SMTP or SMTP Mail Transfer Agent Strict Transport Security (MTA-STS).
DANE
DANE is an alternative to Public Key Infrastructure (PKI) Certificate Authorities. It complements Domain Name System Security Extensions (DNSSEC) by which you must implement DNSSEC before using DANE. Without DNSSEC there is no DANE.
As a standard, it allows you to associate a fully qualified domain name (FQDN) with an X.509 certificate securely making a Transport Layer Security (TLS) connectionless, vulnerable to MITM attacks.
In the case of SMTP, the authoritative mail servers for a domain are stored in mail exchanger (MX) records. The X.509 certificate of the mail server is also stored in the DNS zone file as a TLS Authentication (TLSA) record. By comparing the X.509 certificate used during the STARTTLS negotiation with the one stored in the DNS zone file, the sending email server can detect MITM attacks.
DANE for SMTP solves the problem that TLS is entirely optional with SMTP. Because of DNSSEC, self-signed X.509 certificates may be used.
MTA-STS
MTA-STS can be seen as a way to implement HTTP Strict Transport Security (HSTS) for SMTP.
It is a mechanism to declare the ability to support TLS for SMTP and to specify whether sending mail servers must refuse to deliver an email to an authoritative receiving mail server that does not offer TLS with a trusted X.509 certificate.
MTA-STS solves the problem that TLS is entirely optional with SMTP. With MTA-STS, DNSSEC is not required but is, of course, highly recommended. A valid X.509 certificate is required. Self-signed certificates are not allowed to be used in combination with MTA-STS. As mentioned before, DANE allows users of self-signed certificates, but a full DNSSEC implementation is required.
SMTP TLS Reporting is also a relatively new standard. It defines a reporting mechanism and a format by which sending mail servers can share information about the TLS connection with the recipient domain. The reporting schema covers misconfiguration in your MTA-STS implementation, failures in email routing, DNS resolution, TLS negotiation and policy validation errors for both DANE and MTA-STS. Recipient domains can then use the information to both detect unintentional misconfigurations and also potential attacks. One of the potential attacks could be a MITM attack.
SPF
Sender Policy Framework (SPF) is a method for email authentication and is designed to detect fraudulent mail servers. SPF allows the recipient’s mail server to check that an authorized mail server sent the email.
It is a robust and safe protocol. Nevertheless, when you implement SPF incorrectly the receiving mail server cannot query the DNS server for a list of authorized mail servers, meaning your domains can be abused for sending phishing emails and even worse, you will lose legitimate emails.
Furthermore, it is possible to add macros to the SPF record.
SPF with macros
SPF has a rarely used feature to implement an advanced email track-and-trace system based on configuring macros in your SPF records.
Macros are used in DNS records by wrapping them between delimiters. For SPF, there are several macros defined — see RFC 7208 for the full list and instructions on how to implement them.
By using macros in the SPF TXT resource records, you get visibility on:
- %s Complete sender email address
- %h HELO/EHLO of the sending email server
- %l Local-part of the sending email address
- %o Domain-part of the sending email address
- %i IP address of the sending email server
Two important things to note when you’re %l or %s:
- You will be collecting and storing sensitive information in the resolver logs, including valid email addresses that may cause privacy issues. There is work in progress to overcome this privacy issue. RFC 7816 is about DNS Query Name Minimization of resolver logs. This RFC was published in March 2016. However, the implementation rate is shallow. So please ask your Internet Service Providers (ISPs) to implement RFC 7816.
- You will have to either create a DNS record for every valid email address or use a wildcard. However, the wildcard doesn’t work well in combination with DNSSEC.
Below are two example implementations of SPF with macros:
- The SPF redirect resource record:
belastingdienst.nl. IN TXT "v=spf1 redirect=_spf.belastingdienst.nl"
The SPF exists resource record and macros:
_spf.belastingdienst.nl IN TXT "v=spf1 \
exists:_i.%{i}._h.%{h}._o.%{o}._spf.belastingdienst.nl -all" _i.85.159.101.15._h.smtp2.belastingdienst.nl._o.belastingdienst.nl.\
_spf.belastingdienst.nl. IN A 127.0.0.1 _i.85.159.101.15._h.belastingdienst.nl._o.belastingdienst.nl.\
_spf.belastingdienst.nl. IN A 127.0.0.1
As mentioned, this functionality is used rarely on the Internet — according to research done by spf-all.com and rfcanalyzer.net, less than 0.1% of 240M domains have implemented macros in their SPF record — but is compelling. Below is how we implemented it as part of our phishing identification technique.
How we’ve implemented SPF macros
First, we created a SPF redirect record — we recommend using a redirect modifier from a management perspective. With this redirect modifier, it is possible to share a SPF policy between multiple domains, and changes to the SPF policy only need to be implemented in one place.
The redirect modifier points to spf.belastingdienst.nl. The spf.belastingdienst.nl DNS record is a SPF record with macros. In our case, the macros represent the IP address of the sending mail server, and the HELO string and domain name of the sender email address.
Next, for each mail server, two A records have to be created with the macros filled in. In our case, the mail server smtp2.belastingdienst.nl has the IP address 85.159.101.15 and a HELO string of smtp2.belastingdienst.nl. The second A record is needed because several mail server implementations use the HELO string derived from the SMTP headers, and in that case, the HELO string is belastingdienst.nl.
Below is a diagram showing the flow in the GOOD situation.
It shows:
- Mail server A sending an email to Mail server B.
- Mail server B requesting the SPF record of the domain name belonging to the sender email address.
- DNS server A will then send a DNS response containing the SPF record.
- Mail server B will fill in the SPF macros.
- The next DNS query will be done by Mail server B. This DNS query contains the expanded A record.
- When there is an A record configured in the DNS zone, the DNS response will be an IP address. This should be interpreted by Mail server B as an SPF PASS. Any valid IP address is OK.
For comparison, Figure 7 shows the flow in a BAD situation.
In this case, the perpetrator sends an email on behalf of soc@belastingdienst.nl. The same flow as in the GOOD situation will be executed.
However, in this case, there is no match against an A record in the DNS zone file. The DNS result will be an NXDOMAIN. Mail server B must handle an NXDOMAIN as SPF FAIL because it knows that the mail server of the perpetrator is not an authorized mail server of domain belastingdienst.nl. This email should be handled as SPAM. The DNS queries and responses are stored and can be ingested in your log management and SIEM tooling for further processing.
DKIM
Domain Keys Identified Mail (DKIM) is a method for detecting forged sender addresses in emails, a common technique used in phishing attacks.
DKIM signs the body and selected parts of the SMTP header with a digital signature. The digital signature itself is transmitted in the DKIM-Signature header. Namespaces are available in the form of selectors, and you can have multiple DKIM signatures. The sender must use the secret key of the DKIM key pair to sign the email, and the receiver must use the public key to validate the digital signature.
DMARC
Domain-based Message Authentication, Reporting and Conformance (DMARC) is designed to protect against direct domain spoofing.
The policy allows a sender domain to indicate that SPF and DKIM protect their emails. Furthermore, it tells a recipient what to do if neither of those authentication methods passes. It also specifies how the recipient’s mail server can report to the sender domain about how the policy is executed from the recipient side.
We use the reporting feature of DMARC heavily in the implementation we have done in Splunk; you can ingest the DMARC report also in the ELK stack for further processing.
Be aware of the RUF-tag
A RUF report can contain a complete copy of the rejected email in Abuse Reporting Format and can lead to privacy issues.
Security is everyone’s responsibility, so do your part
As mentioned in the beginning, we firmly believe that if these techniques are used everywhere, it will lead to a significant decrease in phishing emails.
As such, we encourage everyone to talk to their ISP and mail provider and convince them to implement these standards.
In the Netherlands:
- We are reaching out to ISPs to urge them to implement the standards in their infrastructure.
- Government organizations need to comply with a number of these standards specified in the Dutch Standardisation Platform or explain the list. And yes, there are ways to avoid broken mailing lists and forwarding issues.
- SIDN, which is the registry organization of the NL top-level domain, has a financial incentive that a registrar gets a discount on a domain when they implement DMARC and STARTTLS. DMARC gives a discount of €0.16 and STARTTLS €0.04. The wholesale price of an NL domain is €3.40 per year.
Further, we have created a Splunk Dashboard, which gives you visibility over these standards. There is also a wizard for generating the correct DNS records. The wizard can be found in the Splunk App we’ve also created.
These and other helpful tips will be found on spf-all.com and our soon to be launched website: www.rfcanalyzer.net.
Finally, please reach out to us if you have any questions about our implementation and need advice about protecting you and your users from phishing.
Contributors: Arnold Hölzel, Senior Security Consultant, SMT.
Karl Lovink is the SOC technical lead of the Dutch Tax and Customs Administration.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.