I’ve operated on both sides of the fence regarding phishing.
Whilst in Blue Teams, I’ve seen ransomware close schools, malware disrupt business and stolen data sold on the dark web. These all resulted from phishing campaigns that convinced users to click malicious links.
Working in Red Teams testing organizations, I’ve created phishing campaigns to raise awareness to their users, verified technical mitigations in an attempt to stem the flow of phishing messages and demonstrated social engineering techniques used by phishers.
It always surprised me just how easy it was to mimic or circumvent controls which allowed me to send emails purporting to be from legitimate organizations, simply by switching letters around or using obscure characters. While testing, there were several instances when I used genuine email domains of large organizations, only to find the messages were successfully delivered as they had neglected to implement any controls preventing imitation.
Often this is more than enough to convince users to click on the links I’d created, and which unfortunately means a compromise of some sort was going to be inevitable.
It is 2019, we are still being phished and we are not learning from it. Why is this?
This question led me to look at genuine emails I’d received from legitimate, established organizations such as social media companies, payment solutions, pensions and banks. In doing so, I discovered a worrying trend.
To prevent blacklisting their corporate domains on third party email blacklisting services, they use alternative domains when sending bulk emails to their user bases. Generally, if you follow this practice, you would publish the alternative email domain on the corporate website, allowing the user base to verify that the email originated from a genuine and expected source.
Of the 10 corporates I recently checked, 50% didn’t have a properly implemented policy to deal with phishing or email identity management. Two companies did not list the domain I’d received the email from, and two produced a 404 page and didn’t have any domain validation. One company had none of the above, and had a Sender Policy Framework (SPF) DNS record which allowed every IPv4 address worldwide to send emails from their domain. Most failures were financial-based organizations.
One case took me around 15 minutes to verify whether an email I’d received was genuine. It involved determining the owner of the IP address that the message was originally routed through, which was an affiliate agency sending emails legitimately on behalf of the organization.
How is any normal everyday user supposed to know if an email is legitimate?
This demonstrates the failure throughout industry to get a grip on this issue, not just technically but also with policy and management. There isn’t one fool-proof method for dealing with this client-side. Many AV software’s have tried, and there have been a few good attempts at mitigating obvious phishing emails, but we always fall back to relying on the end-user and training, which has inevitable consequences.
Whilst there are technical solutions available, they are solely based on sender responsibility and they are not effective unless they are implemented correctly and used in conjunction with other controls. They have been available for many years but adoption by big business and corporates appears incredibly slow.
The questions to ask your IT messaging teams are:
- Do we have a Sender Policy Framework (SPF) for ALL domains? Is it correct?
- Do we allow third party affiliates to send email on our behalf? Do they have a SPF?
- Have we implemented DKIM for ALL domains that we send email from?
- Have we implemented DMARC for ALL domains we send email from?
- Do we have an email messaging security policy? Is it effective?
- Do we provide our user-base (not internal users) with a resource where they can check if an email is genuine? Does it work?
If you answered ‘No’ to any of the above questions, then you are contributor to the problem. Fortunately, this is easily resolved. There are many guides, publications and resources available to assist designing and implementing SPF, DKIM and DMARC.
Until corporations employ these controls then phishing isn’t going to disappear, and we will likely see an increase in sophistication, number and ferocity of attacks and their consequences. This is a problem of our own making, but one that we can seek to resolve by simply implementing the control mechanisms that are already available. In many cases, the solution doesn’t rely on propriety or licensed products. An all-encompassing solution for end-users based on AI/machine learning/blockchain isn’t going to solve this issue no matter what vendors promise.
If you are not sure where the email came from, leave the link Blue!
Helpful references:
DMARC – Domain Based Message Authentication, Reporting and Conformance
https://dmarc.org/
DKIM – DomainKeys Identified Mail
http://dkim.org/
Sender Policy Framework (SPF)
https://www.gov.uk/government/publications/email-security-standards/sender-policy-framework-spf