It is no secret that one of the major attack vectors is phishing. While some of the success of this is due to a lack of user education and awareness, the other side of the coin are missing basic controls. There is no shortage of enterprise level phishing controls out there, Mimecast and Proofpoint for example. However, these are not silver bullets when it comes to protecting against phishing. In fact I would be hard-pressed to find any control that would alleviate any organization from the susceptibility of phishing. That being said it is important to have layered security to help mitigate the risk.
One of the concepts behind social engineering is rapport, the level of relationship the social engineer has with their target. Rapport can take time to build but the pay off can be well worth it. However, when phishing, rapport can be gained fairly quickly by spoofing and impersonating. An attacker does not have to physically interface with their target, so it is easier for them to claim to be whoever they need to be for the situation. The easiest way to do this is to take advantage of misconfigured or missing sender policy framework (SPF) records and Domain-based Message Authentication, Reporting and Conformance (DMARC). Let us look at the basic setup of these two records and how they help prevent domain spoofing.
Sender Policy Framework
When setting up email for a domain this should always be the first record implemented. It does exactly what it says. It is a policy to determine who is allowed to send on behalf of the domain. If there is no record for a domain, then an attacker could spoof the domain and send phishing email from any server they choose. The record itself is just a text record that goes in to DNS. The basic syntax for an SPF record is:
v=spf1 <mechanism> <qualifier>
The way to think about is the beginning of the record declares the version of SPF to use. Followed by who/what is allowed to send, and then finally what to do if the sender does not meet the preceding condition.
There are a total of eight mechanisms, but for the sake of this walkthrough we are only going to use two of them. The reason for the two that we will be using is because they are the most common implemented. There is flexibility with having the additional mechanisms that may work better in different environments. We will be using ip4and All. Before we go about creating our record it is important to be familiar with the qualifiers, which is what most of our phishing attacks take advantage of.
There are four qualifiers to be familiar with:
+Accept – If the the sending origin is not list in the record allow it through anyway.~Soft fail – Note that the sender was not authorized, but allow it through and leave it up to the user. This is meant for debugging purposes but tends to be the most common qualifier used in the wild.-Hard fail – The sender is not allowed, so deny it.?Neutral – The sender is not authorized, but we don’t care. Think of this is a ‘meh’ record, it will acknowledge the failure but take no action against it.
Ideally the only record we should be using from a security perspective is the hard fail. Indicating that we will declare which server(s) we allow to send on behalf of the domain, while all others should be denied. So let us say that our mail server exists on 198.51.100.1 and that is the only server we want sending mail. So our actual text record should be:
v=spf1 ip4:198.51.100.1 -all
The above record indicates that 198.51.100.1 is authorized to send email on behalf of the domain, and if any other address attempts to send that it should be denied. Notice that no qualifier proceeds the ip4 mechanism, but default the + will be applied to it. This record would be placed on the DNS. We can see below how to add this via a service like Digital Ocean.
DMARC
Now that we have an SPF record, we will need a DMARC record in order to properly handle any SPF failures. It is important to note that DMARC is actually built to to handle both SPF and DKIM (DomainKeys Identified Mail). However DKIM is beyond the scope of this blog and requires more advanced server configurations. We will discuss DKIM in greater detail in a later post. For now, know that DKIM signs messages and the recipient queries the server to conduct a keypair-match.
DMARC, much like SPF, is just a text record that exists on the DNS server. In the record we will state what to do in the event a message fail SPF/DKIM checks and how to report these incidents. The following are the are the parameters of the record we will use:
v– the DMARC version to usep– the policy to enforce on failuresNone– this is the default setting, even if no DMARC record existsQuarantine– Mark the message as suspiciousReject– reject the message entirely
pct– the percentage of bad emails to apply the policy to (defaults to 100%)rua– where to send the reports to
When a message is received, the server will check SPF and DKIM and then refer to the DMARC policy on how to handle any failures. The two most important tags we want to look at are the p and the pct tags. From a maximum security perspective we would like reject any email that fails the checks, and to apply this to 100% of the failed emails. So our DMARC would look like this:
v=DMARC1; p=reject; pct=100
Now of course any failures should be logged and reported on. So having a dedicated inbox for this to aggregate them would be ideal. If we add this into the policy, it would ultimately look like this:
v=DMARC1; p=reject; rua=mailto:dmarc@hacme.com; pct=100
With our record generated, we need to publish it on the server. Again, the record is only a text record. So by creating a text record with the subdomain of _dmarc, then we will have a functioning DMARC record. Below is another example in Digital Ocean on how this would be published.
Of course once these records are published, give it time for them to fully propagate on the DNS. Once up, you can test if they are working properly.
Conclusion
More often than not on assessments we see the implementation of SPF records with soft fails, combined with no DMARC records. This typically results in successful spoofing of domains, either through directly sending from addresses or the manipulation of email headers. Having these two basic records properly generated and published is an easy way to help protect an organization from spoofing. There are more tags that you can use in DMARC, but the basics are a great starting point for this type of protection. Another layer to this protection is DKIM. This setting takes a bit more time and configuration to setup than SPF and DMARC, which we will discuss in a later post. You can also check your records through sites like MxToolbox or even utilize either King Phisher‘s included SPF tool, or the DMARC plugin.
Happy hunting!
