How to Protect Against Phishing Attacks

I came across an interesting example of a phishing attack. Well, I’ve actually come across quite a few attacks recently bearing striking similarities.

It brought up some big security concerns. 

Here’s the story:

One day, a company’s CEO emailed a Director at their company asking to wire transfer a significant amount of money. It sounded urgent. After asking a few questions, he transferred the money. 

A couple days later, the Director bumped into the CEO and said something like, “Oh, by the way how’d that thing turn out with the money I transferred?” 

The CEO had no idea what he was talking about. He hadn’t requested a wire transfer. 

They launched an investigation to see if they were hacked and if they were vulnerable in any other areas.

Once the dust had settled, I got a chance to be part of the investigation, starting with the email that began it all. 

The original message appeared to have come from the CEO’s email, but looking at the logs it was actually spoofed from a 3rd party server. They knew exactly who in the company to contact to arrange a wire transfer, and they had even registered a domain that was very similar to the original to route the return messages to so that it would appear as normal when the Director hit the reply button. They had copied the CEO’s email signature. There were no visible red flags. 4 emails went back and forth before the wire transfer actually happened. 

This was not a hack. This was social engineering, with maybe a bit of spear phishing. Through the logs, I could find no evidence that the perpetrator had ever actually accessed the CEO’s account.

It was likely that someone at a lower level had their account compromised through a targeted phishing attack, which yielded email addresses, names, and positions through their address list. The CEO probably sent out the occasional all-company email, or happened to have sent one to the person who was phished. This would have yielded his signature information and confirmed his email address.

With this information in hand, and some basic knowledge of email, it’s not terribly tricky to craft a message that looks like it came from someone else. Requests not just for money, but credentials or classified information can even more damaging. 

So, interesting story right? 

What can you do to protect your company from these sorts of attacks? There’s no silver bullet that can eliminate all phishing as a threat, but I have some steps that can greatly reduce your vulnerability.

The Human Part:

A large number of malicious attacks are simply social engineering attempts (duping users to do something they shouldn’t). Users must be educated and reminded about what not to do online.  If something seems fishy, it likely is (phishing). In the event that message slips through the cracks in the technical defenses, users need to understand threats, know how to identify them, and how to react when they do find them.

We can’t reasonably expect Larry from facilities to question every request to order more of that pink sawdust stuff. But making them suspicious of emails that may not make total sense, or lacking in details may help save your pink sawdust supplies.

And remember, this sort of threat reaches everyone from the CEO to Billy in the mailroom. Any user of an email system that gets compromised can provide inside information that can lead to significantly more targeted and harder to detect attacks down the road. Simple things like the global address book can deliver valuable information on active email accounts, organizational makeup, reporting structures, or phone numbers. Even finding an email from the CEO can provide a copy of their signature, making a targeted attack seem even more authentic. 

No one should be exempt from security training. 

Looking out for the following red flags can help: 

1. Badly written emails

In the age of mobile devices, these are getting harder to use as a red flag as everyone misspells and autocorrects, but be aware of a message that doesn’t read right. Simply reaching back out to someone before opening a link, document or other attachment can save the day. 

This is an actual phishing attempt:



2. Are you expecting this?

I rarely get attachments or links to documents that I’m not aware of ahead of time. I would have heard about it in a meeting or in an email chain before it shows up. Getting a link with something vague like “take a look at this” or “I need your input” even if it’s from someone you trust can easily be an attempt to gather information. Replying with something quick like “What is it?” can be the difference between safe and compromised.

3. Use a lifeline: call a friend

If someone emails you to urgently transfer money, call them on a known number to confirm before you make the transfer -- not the one listed in their email signature. The best way to thwart social engineering attempts is to refrain from doing as the scammer requests. Instead confirm the request is legit by contacting the requester over a different platform than they used to contact you.

4. Fake sites/bad urls

This is the most prevalent thing we see these days. Long gone are the days where attachments were the biggest threat thanks to Google’s excellent scanning and filtering. Instead, Hackers use links in emails to try and grab your data, specifically your login and password information. Thankfully, most of these scam sites have most of the same fatal flaws that the emails do. Badly written and poorly edited, but anyone questioning things will feel out of place as soon as the page loads. When in doubt, login to If going to loads, then you’re already logged in. If the link you’re clicking still asks you to login, it’s probably an imposter page trying to grab your information.

While these are strong basic tips, you can now effectively test your organization’s phishing readiness using services like PhishMe and ThreatSim who will run non-malicious phishing campaigns against your organization, offering results and additional training should anyone take the bait.

The Technical Part

Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) are two methods used to authenticate that messages came from where they said they came from. SPF is easier to deploy of the two, and more widely accepted. But it’s also easy to improperly configure, allowing too much to get through due to soft rules. 

Sender Policy Framework

I highly recommend reviewing SPF Syntax (here) and running your own SPF record through a validator like the one found here.

DomainKeys Identified Mail

DKIM is a little less widely supported, but for our case here, it’s well supported by Google Apps. So in the effort to protect yourself from people pretending to be you, it’s the most effective method by a long shot. Unlike SPF that operates entirely on the origin IP of the server sending the message, DKIM actually has a rolling key-based system with cryptography that can’t be replicated. Every time you send a message, there’s a secure check against that key to make sure the message truly came from where it claims it did.

It’s a bit more tricky to set up, as it involves generating some keys for your domain as well as some DNS records, but it’ll be worth for the times phishing attempts get blocked. Check out Google’s how-to article on setting up DKIM here.


The IPLock method is creating a mail rule on your own server (Google Apps) that says exactly who gets to send as your domain. It’s like creating your own SPF rule internally. In this rule, you’ll define all the servers that you as an admin permit to send on behalf of your domain(s) and block messages coming from other sources. 

Trying to send a message as from a server that’s not whitelisted? Sorry, that’s not going anywhere. Google has a great help article on how to set this up here.

Setting up all three of these options will give your users the best possible protection you can have… from the technical side.

The Ultimate Safety: Two-Factor Authentication

You knew this was coming. You absolutely cannot have a security discussion without talking about two-factor authentication. 

Two factor authentication is easily the most effective method of securing any account from intrusion. By using a separate authentication application, a physical key, or SMS messaging codes required at the time of login, it prevents anyone without physical hands-on access to a personal device get into an account, even if they do have the password. It’s the last line of defense, but it’s one of the most effective ones you can have. 

Unfortunately, it’s also one of the most intrusive to end users. In the efforts to keep everyone happy, it’s rarely enforced. 

Google helps to take some of the load off two-factor users by allowing specific machines to be remembered for up to 30 days. Having to pull a code from your phone a few times a month if you use multiple devices, seems like a small hassle when it offers the level of security this can offer.

At minimum, we recommend mandatory enforcement of two-factor authentication for any users in positions of authority or administration, as these are easily the most targeted users when it comes to phishing campaigns, but enforcing it across your entire domain will significantly reduce your risks.

Again, Google has an excellent article on setting up and using two-factor authentication here

If you have any questions regarding this article, please feel free to reach out to us at