In February 2022, Darktrace detected the compromise of three SaaS accounts within a customer’s Office 365 environment. This incident provides an effective use case for highlighting how Darktrace/Apps and Darktrace/Email can work together to alert to unusual logins, app permission changes, new email rules and outbound spam. It also emphasizes an instance where Darktrace RESPOND/Apps could have been set to autonomous mode and stopped additional compromise.
Account Compromise Timeline
February 9 2022
Account A was logged into from a rare IP from Nigeria with the BAV2ROPC user agent which is commonly associated with SaaS account attacks. BAV2ROPC stands for ‘Basic Authentication Version 2 Resource Owner Password Credential’ and is commonly used by old email apps such as iOS Mail. It is often seen in SaaS/email account compromises where accounts have ‘legacy authentication’ enabled. This is because, even if multi-factor authentication (MFA) is activated, legacy protocols like IMAP/POP3 are not configured for MFA and so do not result in an MFA notification being sent.
Account A then created a new email rule which was named as a single full stop. Attackers commonly create new email rules to give themselves persistent access by using the ability to forward certain emails to external email accounts they own. This means that even if the account’s password is changed or MFA is turned on, the attacker keeps getting the forwarded emails as long as the rule remains in place. In this case, the attacker configured the new email rule using the following fields and features:
- AlwaysDeleteOutlookRulesBlob – hides any warning messages when using Outlook on the web or Powershell to edit inbox rules. It is likely that the attacker had a set list of commands to run and didn’t want to be slowed down in the exploitation of the account by having to click confirmation messages.
- Force – hides warning or confirmation messages.
- MoveToFolder – moves emails to a folder. This is often used to move bounced emails away from the inbox in order to hide the fact the account is being used to send emails by the attacker.
- Name – specifies the name of the rule, in this case a single full stop.
- SubjectOrBodyContainsWords – emails with key words are actioned.
- StopProcessingRules – determines whether subsequent rules are processed if the conditions of this rule are met. It is likely in this case the attacker set this to false so that any subsequent rules would still be processed to avoid raising suspicion.
Account A was then observed giving permission to the email management app Spike. This was likely to allow the rapid automated exploitation of the compromised account. Attackers want to speed up this process to reduce the time between account compromise and malicious use of the account, thus reducing the time security teams have to respond.
The account was then observed sending 794 emails over a 15 minute period to both internal and external recipients. These emails shared similar qualities including the same subject line and related phishing links. This mass spam was likely due to the attacker wanting to compromise as many accounts and credentials as possible within the shortest timeframe. The domain of the link sent in the emails was spikenow[.]com and was hidden by the text ‘View Shared Link’. This suggests that the attacker used Spike to send the emails and host the phishing link.
Within 15 minutes of this large volume of outbound email from Account A, Account B was accessed from the same rare IP located in Nigeria. Account B also created a new email rule which was named a single full stop. In addition to the previous rules, the following rules were observed:
- From – specifies that emails from certain addresses will be processed by the rule.
- MarkAsRead – specifies that emails are to be marked as read.
Due to the short timeframe between the phishing emails and the anomalous behavior from Account B, it is possible that Account B was an initial phishing victim.
February 10 2022
The next day, a third account (Account C) was also accessed from the same rare IP. This occurred on two occasions, once with the user agent Mozilla/5.0 and once with BAV2ROPC. After the login at 13:08 with BAV2ROPC, the account gave the same permission as Account A to the email management app Spike. It then created what appears to be the same email rule, named a single full stop. As with Account B, it is possible that this account was compromised by one of the phishing emails sent by Account A.
Whilst the motive of the threat actor was unclear, this may have been the result of:
- Credential harvesting for future use against the organization or to sell to a third party.
- Possible impersonation of compromised users on professional websites (LinkedIn, Indeed) to phish further company accounts:
- Fake accounts of one user were discovered on LinkedIn.
- Emails registering for Indeed for this same user were seen during compromise.
How did the attack bypass the rest of the security stack?
- Compromised Office 365 credentials, combined with the use of the user agent BAV2ROPC meant MFA could not stop the suspicious login.
- RESPOND was in Human Confirmation Mode and was therefore not confirmed to take autonomous action, showing only the detections. Disabling Account A would likely have prevented the phishing emails and the subsequent compromise of Accounts B and C.
- The organization was not signed up to Darktrace Proactive Threat Notifications or Ask The Expert services which could have allowed further triage from Darktrace SOC analysts.
Cyber AI Analyst Investigates
Darktrace’s Cyber AI Analyst automates investigations at speed and scale, prioritizing relevant incidents and creating actionable insights, allowing security teams to rapidly understand and act against a threat.
In this case, AI Analyst automatically investigated all three account compromises, saving time for the customer’s security team and allowing them to quickly investigate the incident themselves in more detail. The technology also highlighted some of the viewed files by the compromised accounts which was not immediately obvious from the model breaches alone.
Darktrace RESPOND (Antigena) actions
The organization in question did not have RESPOND/Apps configured in Active Mode, and so it did not take any action in this case. The table below shows the critical defensive actions RESPOND would have taken.
Nonetheless, we can see what actions RESPOND would have taken, and when, had the technology been enabled.
The above tables illustrate that all three users would have been disabled during the incident had RESPOND been active. The highlighted row shows that Account A would have been disabled when the internal phishing emails were sent and possibly then prevented the cascade of compromised email accounts (B and C).
SaaS accounts greatly increase a company’s attack surface. Not only is exploitation of compromised accounts quick, but a single compromised account can easily lead to further compromises via an internal phishing campaign. Together this reinforces the ongoing need for autonomous and proactive security to complement existing IT teams and reduce threats at the point of compromise. Whilst disabling ‘legacy authentication’ for all accounts and providing MFA would give some extra protection, Darktrace/Apps has the ability to block all further infection.
Credit to: Adam Stevens and Anthony Wong for their contributions.
List of Darktrace Model Detections
User A – February 9 2022
- 04:55:51 UTC | SaaS / Access / Suspicious Login User-Agent
- 04:55:51 UTC | SaaS / Access / Unusual External Source for SaaS Credential Use
- 04:55:52 UTC | Antigena / SaaS / Antigena Suspicious SaaS and Email Activity Block
- 04:55:52 UTC | Antigena / SaaS / Antigena Suspicious SaaS Activity Block
- 14:16:48 UTC | SaaS / Compliance / New Email Rule
- 14:16:48 UTC | SaaS / Compromise / Unusual Login and New Email Rule
- 14:16:49 UTC | Antigena / SaaS / Antigena Significant Compliance Activity Block
- 14:16:49 UTC | Antigena / SaaS / Antigena Suspicious SaaS Activity Block
- 14:45:06 UTC | IaaS / Admin / Azure Application Administration Activities
- 14:45:07 UTC | SaaS / Admin / OAuth Permission Grant
- 14:45:07 UTC | Device / Multiple Model Breaches
- 14:45:08 UTC | SaaS / Compliance / Multiple Unusual SaaS Activities
- 15:03:25 UTC | SaaS / Email Nexus / Possible Outbound Email Spam
- 15:03:25 UTC | SaaS / Compromise / Unusual Login and Outbound Email Spam
User B – February 9 2022
- 15:18:21 UTC | SaaS / Compliance / New Email Rule
- 15:18:21 UTC | SaaS / Compromise / Unusual Login and New Email Rule
- 15:18:22 UTC | Antigena / SaaS / Antigena Significant Compliance Activity Block
- 15:18:22 UTC | Antigena / SaaS / Antigena Suspicious SaaS Activity Block
User C – February 10 2022
- 14:25:20 UTC | SaaS / Admin / OAuth Permission Grant
- 14:38:09 UTC | SaaS / Compliance / New Email Rule
- 14:38:09 UTC | SaaS / Compromise / Unusual Login and New Email Rule
- 14:38:10 UTC | Antigena / SaaS / Antigena Significant Compliance Activity Block
- 14:38:10 UTC | Antigena / SaaS / Antigena Suspicious SaaS Activity Block