A Credential Harvesting Attack – How it was Detected & Stopped is a real-world example demonstrating the attack and how to stop this attack. This example was documented by Barracuda Networks, a GBS technology partner, to demonstrate how a Credential Harvesting works and why it’s so important to understand the anatomy of an attack. The case is dissected below.
The attack that was stopped by Barracuda Sentinel. To protect the privacy of the Barracuda customer, certain confidential information has been removed.
Barracuda Sentinel, is a security solution designed specifically to protect companies from phishing and account takeover attacks. Sentinel is one of the key email protections that are part of Barracuda’s Total Email Protection bundle. It integrates directly into Office 365 and works silently in the background to learn the unique communication patterns of your company. This allows Sentinel 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.
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. The attack was discovered only after it bypassed the customer’s non-Barracuda email gateway. Barracuda Sentinel 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 Office 365 tenant, but it was sent from another Office 365 account. The customer’s cloud-based 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 <email@example.com>; 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
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 that was caught by Barracuda Sentinel. 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.
As you can see in the URL, this is an SSL encrypted website. And to reiterate, it’s not being flagged as malicious.
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 Office 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.
Hopefully, this little example serves as a reminder for a few crucial truths in e-mail security:
- 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.
- 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.
- Sentinel’s AI engine has caught and eliminated this threat. It did it NOT by using traditional detection algorithms like hashes or patterns, but by using a context-aware natural language processing algorithm that was able to instantly protect the customer from this and many other attacks.
This post was originally published on barracuda.com