Anatomy of an anti-phishing catch

Barracuda Email Protection is more than an email security gateway. It includes several advanced threat protection features, including protection specifically designed to defend companies from phishing and account takeover attacks.  This protection integrates directly into Microsoft 365 and works silently in the background to learn the unique communication patterns of your company.  This allows it to identify and stop communication anomalies like a spear-phishing attack.  This is real-time protection against email threats that get through traditional security gateways.

To show you how this works and why it’s so important, I’ve dissected a spear-phishing attack that was stopped by Barracuda Email Protection.  We have removed the details to protect the privacy of the customer.

The attack

This attack was directed at the customer’s Chief Financial Officer (CFO). It’s a classic credential harvesting attempt with an interesting twist:  the landing page of the attacker is SSL encrypted with a valid Microsoft signed certificate. Even a trained user that would investigate the certificate could easily be tricked by this.

At the time of the attack, the customer was using a non-Barracuda email gateway. The Barracuda phishing protection, formerly known as Barracuda Sentinel, was deployed as a separate anti-phishing solution. This solution is now included in Barracuda Email Protection.

After the attack bypassed the customer’s gateway, the Barracuda solution  caught two anomalies and alerted the administrator that it had quarantined a spear-phishing attack on the CFO:

The email header

The attack was sent from outside of the customer’s Microsoft 365 tenant, but it was sent from another Microsoft 365 account.  The customer’s third-party gateway email security solution identified this as a legitimate message and allowed the threat into the network.

Received: from xx-xxxx.xxxxxxxx.com (205.1xx.110.1xx) by BL2NAM02FT019.mail.protection.outlook.com (10.152.77.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1750.16 via Frontend Transport; Thu, 28 Mar 2019 18:51:15 +0000
Received: from yy.yy (80.2xx.x.116 [80.2xx.x.116]) (Using TLS) by relay.xxxxxxxx.com with ESMTP id us-mta-24-XXLzexyzxyzxyzCje8Q-1; Thu, 28 Mar 2019 14:51:14 -0400
Received: from yy.yy (localhost [127.0.0.1]) by yy.yy (8.14.4/8.14.4) with ESMTP id x2SMZxxxx26782 for <dxxx@voxxxx.yyy>; Thu, 28 Mar 2019 18:35:08 GMT
Received: (from root@localhost) by yy.yy (8.14.4/8.14.4/Submit) id x2SMZXYZXY780; Thu, 28 Mar 2019 18:35:07 GMT
Received-SPF: Pass (protection.outlook.com: domain of
voxxxx.yyy designates 205.1xx.110.1xx as permitted sender)
X-XX-Unique: XXLzexyzxyzxyzxyzCje8Q -1
X-XXXXXXXX-Spam-Score: 0

As you can see in the partial headers above, there are a few reasons why this email made it through the gateway:

• The SPF check returned a “pass” result. SPF, or Sender Policy Framework, is an authentication method that can help prevent email address forgery.  Because this message was sent from another Office 365 account, this was not detected as a domain forgery.
• There was no malicious attachment in the message
• The message did not appear to be spam and was assigned a spam score of 0.

As you can see, traditional gateway solutions simply cannot catch every type of email threat.

The harvesting website

I created a test environment so that I could evaluate the suspicious link included in this message.  This webpage displayed like a normal safe page would, both in Google Chrome and Microsoft Edge.  There were no browser warnings that the site was malicious, likely because we caught the threat before it was widely known.

Google Chrome:

  Microsoft Edge:

As you can see in the URL, this is an SSL encrypted website. And to reiterate, it’s not being flagged as malicious.

Certified Evil?

I didn’t get a certificate warning when I opened this website.  That’s a problem because it means that my computer trusts the entity that signed the certificate of this credential harvesting website.  Taking a look at the certificate, we can see that it was signed by Microsoft themselves:

To sum up, an Microsoft 365 email attack is sending victims to a credential harvesting site that has an SSL certificate signed by Microsoft.

How is this possible?

Scammers always look for new ways to entice an unsuspecting user to fall for a phishing message. The more legitimacy the scammers can project into their emails, the more effective they are at exploiting their recipients. As part of Microsoft’s cloud offering, customers have the ability to configure a custom domain name for Azure storage accounts. This feature certainly has legitimate use cases, but as you see here, it can be extremely useful for malicious actors as well.

What now?

Hopefully, this little example serves as a reminder of a few crucial truths in e-mail security:

1. Securing e-mail at the gateway level is not enough anymore. It’s still important to leverage gateway security to protect against traditional attacks (viruses, 0-day ransomware, spam, etc.) but it’s defenseless against targeted attacks like the one we saw above.
2. SSL certificates are NOT an indicator if a website is legitimate or safe. Talk to your users, and over 80% will tell you they look at “the lock” in the URL bar to determine if it’s a safe website. 10% will be a little more cautious, and the remaining 10% don’t care either way and click everything anyways.
3. Barracuda’s AI engine has caught and eliminated this threat. It did this by using a context-aware natural language processing algorithm that was able to instantly protect the customer from this and many other attacks.

Visit our website for more information about Barracuda Email Protection or a free email threat scan.

Note: This post was originally published in September of 2020.