Novel O365 Application Breach: Would You Click on My Little Quarantine?

O365 Application Breach

In our early 2020 state of quarantine, we thought it was interesting to see attacks exploiting a different kind of quarantine: Microsoft anti-virus quarantine messages. This quarantine message contained a link that side loads a malicious Office 365 (O365) application. This type of attack against O365 was first reported by Phishlabs in December of 2019, but instead of using a quarantine message, Phishlabs observed the use of SharePoint and OneDrive links.

Why are these attacks so interesting? In short, because password resets don’t help. This attack uses a malicious application that gets its permissions from a hijacked security token. We think that is pretty clever. All while maintaining proper social distancing guidelines.

So, let’s put on our masks and dive a little deeper into this.

In this attack, threat actors took a four-step approach:

  1. Lure the user with a phishing email that poses as a legitimate quarantine email from Microsoft.

  2. Once the user clicks on the phishing link, direct the user to a legitimate Microsoft login page.

  3. After the user signs in and fully authenticates, redirect the authentication token provided from Microsoft back to the threat actor.

  4. Use the authentication token to set up the malicious application with full permissions to the user’s mailbox.

Delivering the Phishing Email:

A phishing email appearing to be from Microsoft’s Quarantine service, “quarantine@messaging.microsoft.com,” was delivered to the victim. To compare how the phishing email differs from Microsoft’s typical quarantine messages:

  • The legitimate email Microsoft typically sends appears as:
  • The phishing email (shown in Figure 1 below) appeared as:

    • Subject: X messages were quarantined as of M/DD/YYYY hh:mm:ss AM (UTC)

    • Display Name: Quarantine@messasging.microsoft.com <user@domain.com> (Quarantine@messaging.microsoft.com via server.domain.com)

      • The legitimate email does not use the Display Name field. Also the capital “Q” is not used in the legitimate email

    • From: user@domain.com

    • Body of Message: Quarantine notification. X messages were quarantined as of M/D/YYYY hh:mm:ss AM/PM (UTC). Review them within 15 days of the received date by going to the Quarantine page in the Security & Compliance Center.

      • Important Note: Some of the “quarantined” messages appear with subjects that would enable the user to click on the link. Example: 2020 Bonus from HR, Bonus Form .xls

    • Link In Body: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=14113242-bce9-44a0-ac40-daa4f1bb2c23&response_type=id_token+code&redirect_uri=https://officehnoc.com:8081/office&scope=offline_access contacts.read user.read mail.read notes.read.all mailboxsettings.readwrite Files.ReadWrite.All openid profile&state=12345Ajtwmd&response_mode= form_post&nonce=YWxsYWh1IGFrYmFy&data=01|01|user@domain.com|fcbc958d2c1a4448260e08d7a2703c3d|066eab4ded6347ab813df489984d83cb|0&sdata=EkFAlbuyVr ww4QcxqxLj6yBI30g07lZ2T4u0toNtrc=&reserved=0

Illegitimate Email 

Figure 1: Phishing Email

Digging Deeper into the Attack:

In the message headers of the phishing email, our team found the line “by server.domain.com (8.14.7/8.14.7).” Based on the version number, we suspect that the threat actor used the Linux tool Sendmail version 8.14.7 to create the phishing email. This cmdline tool would allow the threat actor to add values to the “Display Name,” “Subject,” and “From” fields. This is how the threat actor disguised their email to appear as if it were coming from Microsoft’s quarantine service. An important additional note: the threat actor set the “From” field to the victim’s email address. We also noticed another pair of identifiers in the message headers, “root@localhost,” and “server.domain.com.” It is possible that these values are the default values assigned by Sendmail, and that the threat actors did not change them in order to leave as few tracks as possible. The phishing email was pushed out by a local email server stood up by the threat actor.

The link mentioned in the previous section is the malicious link found in the threat actor’s phishing email. The first part of the link, “https://login.microsoftonline.com/common/oauth2/v2.0/authorize”, directs a user to a legitimate Microsoft Office sign-in page.

The next part of the link, “response_type=id_token+code&redirect_uri=https://officehnoc.com:8081/office&scope”, takes the authentication token created by Microsoft and redirects it to the threat actor’s site. Once the token reaches the malicious site, the token and the following parameters are applied to an application that the threat actor will use to connect to the users mailbox:

  • offline_access 

  • contacts.read 

  • user.read 

  • mail.read 

  • notes.read.all 

  • mailboxsettings.readwrite 

  • Files.ReadWrite

Checking for IOCs:

To recognize this attack in your own environment, look for evidence of successful connections and permissions granted to the third-party applications, which can be found in Microsoft's Unified Audit logs. The following operations are recorded by Microsoft in regards to applications connecting to a mailbox:

  •  "Adding OAuth2PermissionGrant"

    •  Important Note: The consent type given to the application will indicate if the application has access to only the authenticated mailbox or the entire tenant

      • Principal: Access only to the authenticated mailbox

      • AllPrinciples: Access to the entire tenant

  • “Consent to application”
  • “Add app role assignment grant to user”

By searching these operations in the Unified Audit logs, an analyst can determine if a third-party application has connected successfully to a mailbox and which permissions it was assigned.

Washing Up:

During this attack, the attacker was able to exploit traditional O365 security measures by harvesting an authentication token designed to be used by applications. Using this method, the threat actor does not need the user’s credentials. This attack highlights and reminds us of the importance of employee vigilance in preventing successful phishing attacks. And also, as a reminder, don’t forget to wash your hands.

How to Protect Against This Attack:

  • Revoke user security tokens for accounts suspected of compromise

  • Institute a robust employee security awareness culture and training program that is tailored to employee roles and responsibilities

    • Conduct employee and leadership security training bi-annually to ensure continuous security awareness

    • Make the training incrementally harder to train on more sophisticated tactics

  • Review third-party applications and block the use of illegitimate applications. Consider blocking all third-party applications if not needed for business functions

  • Upgrade all Microsoft applications

  • Use anti-spoofing and email authentication techniques, like Sender Policy Framework (SPF)

  • If not needed for normal business operations, block account logins based on geographic regions

  • Adopt advanced phishing protection/machine learning solutions like those offered through Microsoft Office 365 Advanced Threat Protection or other third-party solutions to detect and deter sophisticated phishing campaigns

  • To prevent threat actors from circumventing Multi-Factor Authentication (MFA), disable legacy authentications/protocols and confirm that MFA is not only deployed, but that employees are also using it correctly

Topics: Security Insights