Stop CEO/CFO Domain Spear Phishing
Pretty bold title… While it is nearly impossible to stop any motivated attacker/phisher, I also believe in doing every bit you can to improve your environment and these steps will go a long way to helping your situation. I will talk about two primary ways to put an end to CEO/CFO spear phishing. Realize upfront that you should not do one step without the other. I will also talk about the ins and outs of these techniques as well as some of the remaining phishing issues that you would need to still be wary of.
The CEO/CFO spear phishing scheme has seen another significant uptick and there’s a good likelihood they are going to continue increasing in numbers.
Even Brian Krebs raised awareness as early as August 2015 to this growing trend.
https://krebsonsecurity.com/2015/08/fbi-1-2b-lost-to-business-email-scams/
Brian then followed it up in April 2016 with a report about how $2.3 billion (yes, with a ‘B’) have been lost to CEO email scams.
https://krebsonsecurity.com/2016/04/fbi-2-3-billion-lost-to-ceo-email-scams/
Suffice to say that if Brian is writing about it, it is a huge problem and he is usually a little ahead of the curve!
Most solutions come from necessity and this one is no different. The “novel” 2nd solution hit me after what could have been a disastrous event. I honestly can’t say I’ve ever seen anyone mention it and it’s so simple that after you read about it, you’ll wonder why not. Anyway, a customer was sent a single spear phish email from a homoglyph domain. A homoglyph is a character or character combination that look similar. For example, the number ‘1’ looks like the letter ‘l’, 2 consecutive of the letter ‘v’ look like a ‘w’ in many fonts, ‘r’ followed by ‘n’ looks like an ‘m’, etc. Suffice to say, a homoglyph domain has absolutely no purpose on this earth except for sending phishing emails.
Fortunately, the customer recognized the spear phish and alerted us so we could look into it (break out the happy dance). Within minutes of running a whois on the new domain, I easily found it was a Vista Print created domain with Tucows acting as the registrar. I then looked at the Vista Print website and found exactly what I suspected. Right on the page you can sign-up for a free, 30-day trial domain name and domain hosting account. Barrier to entry… zero. What’s the worse that can happen?
So @Vistaprint, let’s have a little talk about bad folks abusing your 1 month free website/domain trial for #phishing attacks. CC @tucows
— Dallas Haselhorst (@oneoffdallas) March 31, 2016
I sent the tweet above and to my surprise, both companies replied rather quickly. I sent them both DMs explaining what I found and I waited… and waited… and waited… As of several weeks later, still nothing. At the same time, I also sent an email to domainabuse@ for Tucows and they responded 8 days later that it wasn’t their domain; of course, in their reply email they clearly show they are checking the whois for the actual domain rather than the homoglyph-ed domain. <SMH> Either their support didn’t see the homoglyph themselves when re-typing it or they grabbed the first domain in the email they saw even though if they actually read the email, they would have seen I said the bad guys were copying domain XYZ. Regardless, still nothing more from that front either…
Update: I still haven’t heard anything from either one, but I’ve seen multiple reports across the internet that they have cleaned up their act and closed this apparent “loophole.” I would like to think I might have had something to do with this, but probably not! 😉
It was pretty clear early on I wasn’t going to get any help from them. Still, the underlying issue was even if they shut the domain (or free account) down, what about the next spear phish domain created by the crooks? I wanted something that was going to provide some level of protection and I didn’t care if it was a homoglyph, character substitution, character omission, etc. Was I doing everything I could to stop this type of attack? I quickly discovered the answer was ‘no.’ I’ll go into two separate techniques that you need to employ today in order to combat this issue before you and your organization fall victim. The good news is that it doesn’t take long to implement both and both solutions cost absolutely nothing other than time to implement. In fact, if you are familiar with many of the technologies and your environment, you can likely have both solutions up and going within 30 minutes.
#1 – Sender Policy Framework (SPF)
If you know what SPF is and you are using it, congratulations! Skip ahead to #2. If you are not sure, skip ahead to the section below on “Testing for SPF.”
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. [1]
There are tons of resources on SPF that describe what it is so I’m not going to re-hash it. Worth mentioning is that SPF not only prevents others from spear phishing you, it also prevents someone from spoofing your domain and damaging your reputation so it really is a win-win.
http://www.openspf.org/Introduction
I’m also not going to get into the individual configuration of devices for SPF because that would be a book, not a blog post. Suffice to say, you need to have an anti-spam server, firewall, or mail server that respects SPF. Contact your vendor to find out for sure if you don’t know.
At a high level, you are going to create a TXT DNS record and that entry is going to get referenced by other spam servers (including your own) when the mail is received. When an email is received, the anti-spam server (or firewall or mail server) checks the SPF record and determines whether the originating IP address or host name is “valid.” This is best shown in the image below.
Image from dmarc.org
Creating the SPF Record
There are many ways to figure out how to use this and determine the formulation of the TXT string you should use, but by far the easiest is to use SPF Wizard at the site below. The site does a great job explaining what each individual item means and it also walks you through building the TXT record.
I would argue the SPF below (substitute your domain of course) would probably work for most setups.
| linuxincluded.com. IN TXT “v=spf1 mx a -all” |
You absolutely need to double and triple-check this. If you get it wrong, it will likely result in valid emails getting rejected! If you have another IP address or hostname that send mail on your behalf, you will need to add them to this line as well. Also keep in mind that if those IP addresses or hostnames ever change, you would need to change it in the TXT record.
If your hosting provider uses cPanel, follow the few steps below and you will be in business.
1) Go to “Advanced DNS Zone Editor”
2) Add the information you created in the prior step(s) and click “add record.
Assuming you did everything correct, your new TXT record will show up at the bottom of the zone file records section.
If you use some sort of graphical interface for your DNS such as GoDaddy, Wix, etc. please refer to their support on how to add a custom TXT entry. In most cases, you need to create a TXT record for your domain and add *just* the line below. It’s worth mentioning that some systems will require the beginning and ending double quotes while others do not. That is the importance of testing!
| “v=spf1 mx a -all” |
Testing the SPF Record
In my experience, your SPF records will start showing up within 10 minutes if they are newly created. This is perfect as it will give you an opportunity to check it for correctness before emails are potentially blocked.
Windows Command Line Testing
If you open a command prompt in Windows, type the following commands to test whether your newly added SPF record is there. Red is what you will need to type while blue is what you should expect back if it is working. In this example, I’m testing against Google’s public DNS server at 8.8.8.8.
| C:\Users\Dallas>nslookup Address: 192.168.1.1> server 8.8.8.8Default Server: google-public-dns-a.google.com Address: 8.8.8.8> set type=txt > linuxincluded.com Server: google-public-dns-a.google.com Address: 8.8.8.8Non-authoritative answer: linuxincluded.com text =“v=spf1 mx a -all” |
As you can see, the proper SPF record comes back. If you didn’t receive anything, either a) your DNS didn’t propagate yet or you have something wrong.
Linux Command Line Testing
Open a command prompt in Linux, type the following commands to test whether your newly added SPF record is there. Again, red is what you will need to type while blue is what you should expect back if it is working. In this example, I’m testing against Google’s public DNS server at 8.8.8.8 again.
| dallas@deb:~# dig linuxincluded.com TXT @8.8.8.8 ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> linuxincluded.com TXT @8.8.8.8 ;; OPT PSEUDOSECTION: ;; ANSWER SECTION: ;; Query time: 78 msec |
Other Testing Methods
If you’re not a command line person, you can also test via some websites and they work very well too. They also evaluate whether your SPF records are formatted properly, which your eyeball test on the TXT records from the command line might overlook. I’ve included a couple of free sites that do this service as well as many more.
https://mxtoolbox.com/NetworkTools.aspx – Simply type in your domain next to the SPF box
http://www.kitterman.com/spf/validate.html? – Not as pretty, but same concept and it does the trick
#2 – Blacklisting
So you understand SPF, but you wanted something more? You want to protect against the previously mentioned absolutely evil domains, i.e. the type that use character substitution, character omissions, homoglyphs, etc. Blacklisting often gets a bad rap because it often doesn’t go far enough to block the bad guys (and I would mostly agree), but this is an example where blacklisting works perfectly.
If you have a place to enter blacklisted domains on your mail server, firewall, or anti-spam server, then you are in business because that is all you need! But what can you use to create your blacklist? No reason to dream them up yourself… Instead, create your blacklist with a tool that comes by default on Kali Linux called URLCrazy. The tool is also available on Github (link below) if you don’t have access to a Kali system or your current Linux distro doesn’t have it in the repository.
https://github.com/Eisler/URLCrazy
Open a command prompt in Linux, type the following commands to output which domains are similar to yours. As you can see, the linuxincluded.com domain has a total of 184 variations. Ouch! That’s a lot of potential for spear phishing! Make sure you look through the domain names and their aren’t any that you use and/or you may potentially communicate with. I would say the mostly likely example is if you own both a .com version of your domain as well as the .net version.
| dallas@deb:~# urlcrazy linuxincluded.com URLCrazy Domain Report # Please wait. 184 hostnames to process Typo Type Typo DNS-A CC-A DNS-MX Extn |
Interested in getting a little cleaner list of domains that you can copy/paste into your blacklist? With a few options and our friend cut and tail, you can get a rather nicely formatted output.
| dallas@deb:~# urlcrazy –format=CSV linuxincluded.com | cut -d’,’ -f2 |tail -n +2 linuincluded.com |
Last but not least, if you happen to have a system that has somewhat of an odd duck format, not a problem. Just add sed followed by a ^ and the string to insert. For example, one particular system I’m familiar with requires the text “blacklist_from *@” (minus the quotes) before each individual domain name. Note the red text should all be on one line in order to work properly!
| dallas@deb:~# urlcrazy –format=CSV linuxincluded.com | cut -d’,’ -f2 |tail -n +2 | sed ‘s/^/blacklist_from *@/’ blacklist_from *@linuincluded.com |
That’s it! Easy as pie!
Other Types of Phishing
Obviously, the only phishing attacks that were covered above were ones that specifically used your domain name or ones that used variations of your domain name. I would be remiss to not mention other types of phishing. What I mean by this is none of the techniques above will stop an email from [yourorganization]@gmail.com, [yourhelpdesk]@hotmail.com, or the millions of other possibilities — fake UPS, FedEx, etc. For those types, nothing beats a healthy security awareness plan and making sure your users know the difference.
Next Steps And Additional Thoughts?
As with anything, the techniques are not perfect and you could do more if you choose to do so.
The first thought one might consider is the “newness” of the domain. As you might have guessed, the domain from the example above was just a day old when the spear phish email was sent. If the anti-spam system had a “newness” test it would have likely caught it. But what if the spear phish was highly targeted and the attackers decided to sit on the domain for a few days, a few weeks, or even a few months? Would the “newness” check have worked? What if a similar domain name expired and the attacker just backordered that domain which was originally registered in 1999?
Second, these techniques do end the ridiculousness of having to purchase 10+ like domains for fear of getting spear phished by one of them, which is a recommendation I’ve heard at least once… maybe the person worked for a domain registrar? 😉 That being said, I would still strongly suggest buying similar domains where mis-types might land your customer on a competitor’s page. A mis-typed domain URL similar to gooogle.com (with the extra ‘0’) comes to mind.
Finally, you’ve added the 100 or so domain name variations generated from your domain name as specified above. Now, do you have a way to receive notifications when your anti-spam server blocks an email from one of those domains? This could prove to be ridiculously useful if you start seeing multiple emails come in from those domains because it would give you an opportunity to raise awareness across your organization. It’s like seeing the enemy congregate at the gates before the real attack! Security awareness FTW… again!
[1] https://en.wikipedia.org/wiki/Sender_Policy_Framework
[2] https://dmarc.org/2015/07/email-authentication-basics-slide-deck-now-available/
Dallas Haselhorst has worked as an IT and information security consultant for over 20 years. During that time, he has owned his own businesses and worked with companies in numerous industries. Dallas holds several industry certifications and when not working or tinkering in tech, he may be found attempting to mold his daughters into card carrying nerds and organizing BSidesKC.
4 thoughts on “Stop CEO/CFO Domain Spear Phishing”
Another idea is to use a Levenshtein distance function to calculate the number of character changes needed to get from your domain to the look-alike. If the distance is small it may be a phishing attempt.
I wasn’t familiar with the Levenshtein distance function, but it absolutely makes sense in this discussion. I couldn’t find any references within urlcrazy that states it specifically uses the function for its own operation, but it sounds so eerily close that I would almost bet that is the case. Good discussion and thanks for the recommendation!
Our CEO has a unique last name, so we added a Email Flow rule like this: If the CEO’s last name is in the sender name or email address, BUT it is not actually from the CEO, block it and flag to IT.
Once SPF, DKIM, and DMARC are implemented, every little bit helps!