So what went on with the SANS email breach?
On the 11th of August 2020, the Information Security training organisation SANS disclosed that it had suffered a breach by way of phishing that had led to 28,000 records containing Personally Identifiable Information (PII) to be disclosed. The SANS disclosure stated that on August 6th as part of a systematic review of email configuration and rules, it had identified a suspicious email forwarding rule, and that that rule had resulted in 513 emails to be forwarded to a suspicious email address externally.
On the day of the announcement, not many additional details were available so speculation was rampant in the media and on social media. Many speculated that SANS had fallen victim to a malicious Office 365 application attack, the likes of which have been on the rise since November 2019. Additionally the speculation included questions about:
What PII was disclosed?
Were customer credentials breached?
When was the initial breach?
How long was the mail forward rule active?
If it wasn't a malicious Office 365 app, what was the attack vector?
Since the day of the release, SANS has provided some updates to the disclosure and most recently an excellent indicators of compromise document. The full list of what types of PII that have been disclosed has been provided and the fact that it does not include either credentials or financial information such as credit cards. Additionally, the attack entry point has been confirmed as being an 0ffice 365 application which:
Was authorised by a single staff member onto the tenant;
By a phishing email titled “Copy of sans July Bonus 24JUL2020.xls” on July 24th;
This Office 365 application was named Enable4Excel which is very similar to Enabler4Excel by Salesforce;
It created an auto-forward on the users mailbox called “Anti Spam Rule”;
The mail forward rule matched against financial terms.
This attack follows a very predictable path, our users are going to get phished and companies are going to get breached. There are some details in the advisories that show that SANS was lacking some protection and detection capabilities that would have allowed it to respond faster and reduce or even remove the impact.
Detection of new / changed Azure / Office 365 user consented applications, including changed permissions addition of “Read and write user mailbox settings”
Detection of user created auto-forward rules, particularly external forward rules. This should include new and changed rules.
Enabling the Office 365 DLP solution for “U.S. Financial Data” or “U.S. Personally Identifiable Information Data” either in notify or block mode. With 513 emails forwarded against that auto-forward rule, it’s highly likely the DLP rules would have triggered.
From the media releases, we can gauge that the attack happened on July 24th and was discovered on August 6th, a period of 14 days that resulted in 513 emails being exfiltrated. If SANS had had one or more of the above capabilities, investigations could have been started much earlier, the size and impact of the data loss reduced and therefore likely the entire breach notification avoided.
How can Detexian help?
Detexian provides features to reduce the risks of malicious applications:
Discovery of currently authorized marketplace and OAuth applications on Azure / Office 365;
Detection of permissions granted for each application, with excessive privileges being highlighted and notified;
Detection of user created auto-forward rules, both internally and externally;
Centralizing and normalisation of SaaS DLP events and alerts;
Continuous monitoring and detection of new applications being registered and auto-forward rules being created.
Find out how you can detect malicious Azure applications and user-created email auto-forward rules. Inquire now for a free trial.