Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
Resources Blog Threat detection

Diary of a Detection Engineer: Exposing and shutting down an inbox heist in action

Here’s what we discovered while responding to and investigating a compromised email account.

Justin Schoenfeld
Originally published . Last modified .

One day in January 2023, Red Canary detected the creation of a suspicious email rule in one of our customer’s Microsoft 365 environments. After a thorough investigation, we worked with the customer to better understand what had happened (post-credential compromise) and how to resolve it. We hope the following article helps you better understand how to detect, investigate, and respond to suspicious email activity.

Email rules: a primer

A time-saving hack to organize and filter mailboxes automatically, email rules exist to make our lives easier. Ask most executives, engineers, or anyone else that receives hundreds of emails a day for that matter, and they’ll likely jump at the opportunity to provide their pro tips on how best to utilize this feature. But every light has its shadow. While these rules are mostly leveraged by legitimate users within our customer environments, we’ve also observed adversaries making use of email rule creation following credential compromises.

Here at Red Canary, we see some form of creation, modification, or deletion of an inbox rule across our customer base roughly 27,000 times a day. That’s a crap ton of rules! Thanks to our ability to restrict the aperture of our detection analytics, however, we’re able to manage by homing in on only those rules we commonly associate with suspicious activity.

The investigative lead

The initial data presented to the detection engineer who investigated this recent threat read something like this:

An email rule named “xx” was created 
Filters email with the following properties:
     “From” address contains “amazon”
     “Subject” or “Body” contains “amazon”  
Move the email to the “RSS Subscriptions” folder
Mark that email as read 
The rule was created via the Application Office 365 Exchange Online (00000002-0000-0ff1-ce00-000000000000)
Stop Processing other email rules
Browser Type: Firefox
User located at IP Address X.X.X.X in Minneapolis registered to “Private Internet Access VPN” 
     Known VPN
     Known Proxy
     High abuse velocity

When it comes to identity events, we first seek to answer some simple triage questions and then move on to a more in-depth investigation if warranted. Generally, we’ll start the preliminary inquiry with the session ID from the native log source (when available), and attempt to identify any other suspicious activity from the same time period. This step is crucial as it may reveal concurrent activity from both the user and the adversary. The primary objective here is to get to a place where we can answer the following: Is this user behavior normal? With this in mind, our detection engineers discovered that the answer in this particular case was no.

After some digging into the logs, we noticed a few interesting facts about the user’s login behavior that led us to investigate this a bit deeper:

  • They normally logged in from a different state in the U.S.
  • They’ve never used a VPN
  • The ISP used for the suspect logins was different
  • They normally used the Microsoft Edge browser
  • They hadn’t created an inbox rule in the last 90 days
  • The victim user was logged into their mailbox at the same time as the adversary

 

At this point, we knew we were likely dealing with compromised credentials, but we needed to exercise due diligence and dive a bit deeper to verify. The new question to answer at this point: What else was this user (or the adversary masquerading as them) up to after their initial logon, prior to the creation of that suspicious email rule?

The deep dive

Immediately after logging in, the adversary performed some reconnaissance on the victim’s mailbox. Our login data (in this case) came directly from the Audit.AzureActiveDirectory content type from the Unified Audit Logs (UAL), denoted by the UserLoggedin operation. We know the adversary logged into Microsoft 365 Exchange Online due to a quick lookup of the application ID 00000002-0000-0ff1-ce00-000000000000. Microsoft published a nice, non-exhaustive list of application IDs you can expect to see in your logs, although hundreds of other Microsoft-owned applications do exist.

From this vantage point, we noticed the adversary accessing a bunch of mailbox folders via bind mailbox access for “Sent Items” and “Inbox.” We discussed the bind and sync MailItemsAccessed operation methods in-depth in a previous blog, which you can read for additional context. At a high-level, using the bind operations means that the adversary didn’t download the entire mailbox (as is the case with sync mail access types). With bind logs, we can see all of the individual mail items the adversary may have viewed via the InternetMessageId values. sync, on the other hand, doesn’t display all the InternetMessageIds just the folders accessed.

Next, the adversary started to enumerate some interesting email attachments. Some of the mail attachments contained terms such as “Docusign” and “payment confirmation.” We can tell they viewed mail attachments by the Update operation, which includes valuable forensic data such as attachment names, email folders, subject lines, and the InternetMessageId.

Sidebar

If your organization is investigating an email-based threat, performing some auditing, or auto-enriching your threat detections with email contents, it may be helpful to retrieve the email content via the InternetMessageId using the following Graph API request with the proper token permissions:

https://graph.microsoft.com/v1.0/me/messages?$filter=internetMessageId eq '<_your_internet_message_id_value>'

Back to the action

The adversaries eventually logged into the My Profile application identified by the application ID 8c59ead7-d703-4a27-9e55-c96a0054c8d2, which displays some of the user’s account information such as job title, sign-in data, and devices used. Exactly what they viewed (or potentially modified) within this application was not displayed in any log we had available to us at the time. However, we suspect it was part of their account reconnaissance steps as we’ve also witnessed this pattern in other account compromises.

Meanwhile, while all this activity was unfolding, the victim was also using their account. We confirmed this by cross-referencing the IP address, geo-location, and user agent from this and their previous logins. So, while the adversary was reading attachments and creating the inbox rule, the unwary user was still sending and reading emails and performing their day-to-day tasks. Further analysis also revealed that the user was accessing their email through the Outlook desktop client, while the adversary was leveraging the SaaS-based Outlook on the Web (OWA). With this in mind, we decided to pivot and drill down on the session ID from our adversary, which allowed us to filter out the noise from the legitimate user within the given timeframe of our investigation.

While the adversary was reading attachments and creating the inbox rule, the unwary user was still sending and reading emails and performing their day-to-day tasks.

As the adversary continued to sift through emails, we took note of their particular interest in the user’s Amazon-based messages, denoted in the logs as the InternetMessageId <redacted@email.amazonses.com>. With the realization that the victim may have an Amazon account, they promptly created the new Amazon-related inbox rule (displayed in the investigative lead section above). The creation of which was the catalyst to this very investigation.

Just prior to that activity, we noticed a HardDelete operation for an email labeled “Outlook Rules Organizer.” We’re pretty confident this was not manually performed by our adversary. Though the contents or purpose of deleting this email is unknown, it appears to be a common pattern with email rules created within a user’s mailbox across our customer base. While it does not appear to occur with every new inbox rule, it is nonetheless a good indication that a rule was created and may serve as a low-noise hunting idea.

A trimmed-down example of the email being deleted looked like this in the audit log retrieved from the Office 365 Management API:

    "CreationTime": "2023-01-01T00:00:00",
    "Operation": "HardDelete",
    "RecordType": 3,
    "ResultStatus": "Succeeded",
    "Workload": "Exchange",
    "ClientIP": "X.X.X.X",
    "UserId": "victim@customer.com",
    "AppId": "00000002-0000-0ff1-ce00-000000000000",
    "ClientIPAddress": "X.X.X.X",
    "ClientInfoString": "Client=OWA;Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0;",
    "ExternalAccess": false,
    "InternalLogonType": 0,
    "LogonType": 0,
    "MailboxOwnerUPN": "victim@customer.com",
    "SessionId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
    "AffectedItems": [
        {
            "Id": "<redacted>",
            "InternetMessageId": "<redacted>",
            "ParentFolder": {
                "Id": "<redacted>",
                "Path": "\\Inbox"
            },
            "Subject": "Outlook Rules Organizer"
        }
    ],
    "CrossMailboxOperation": false,
    "Folder": {
        "Id": "<redacted>",
        "Path": "\\Inbox"   }

Having successfully forwarded Amazon-related emails to a separate folder, the adversary went on to dubiously reset and change the user’s Amazon password. They did this by accessing the RSS Subscriptions folder, then waited to receive the Amazon password reset link before moving it to the Deleted Items folder. Realizing the email wasn’t necessarily deleted—and therefore able to be recovered—they proceeded to perform a SoftDelete on the email. To further cover their tracks, they then performed a HardDelete on the email from the \Recoverable Items\Deletions\ folder as seen in the log below:

{
  "CreationTime": "2023-01-01T01:00:00",
  "Id": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "Operation": "HardDelete",
  "OrganizationId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "RecordType": 3,
  "ResultStatus": "Succeeded",
  "UserType": 0,
  "Version": 1,
  "Workload": "Exchange",
  "ClientIP": "X.X.X.X",
  "UserId": "victim@example.com",
  "AppId": "00000002-0000-0ff1-ce00-000000000000",
  "ClientIPAddress": "X.X.X.X",
  "ClientInfoString": "Client=OWA;Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.0.0 Safari/537.36;",
  "ExternalAccess": false,
  "InternalLogonType": 0,
  "LogonType": 0,
  "MailboxOwnerUPN": "victim@example.com",
  "OrganizationName": "example.onmicrosoft.com",
  "SessionId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "AffectedItems": [
    {
      "Id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
      "InternetMessageId": "<redacted@email.amazonses.com>",
      "ParentFolder": {
        "Id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
        "Path": "\\Recoverable Items\\Deletions"
      },
      "Subject": "Amazon password assistance"
    }
  ],
  "CrossMailboxOperation": false,
  "Folder": {
    "Id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "Path": "\\Recoverable Items\\Deletions"
}

Their final cleanup action was to remove the inbox rule to cover up any tracks they left, which was denoted by a Remove-InboxRule operation.

Once we detected this activity and informed the customer, they swiftly disabled the user’s account, revoked their refresh tokens, and changed their password. The adversary continued to attempt to login, but was met with failed logon screens.

Conclusion

Given how much sensitive data is stored in mailboxes, attacks such as this will only continue. As we saw in this case, adversaries will increasingly cross the boundary of personal and business accounts. Had the user implemented multi-factor authentication (MFA) on their account prior to the incident, they could have avoided this headache. With the adversary’s access promptly cut off, we helped our customer avoid what could have been an even more destructive incident: the adversary resetting corporate application passwords, launching additional phishing attacks internally, or gaining access to sensitive information.

Attacks like this one are unfortunately common. So common, in fact, that our upcoming Threat Detection Report includes extensive research on email threats, identity, and malicious MFA request generation. If you sign up for our weekly blog email, we’ll send you a copy of the report when it’s published later this month.

Resources

Some of our favorite resources for furthering your hunting knowledge with Microsoft’s UAL:

 

The Trainman’s Guide to overlooked entry points in Microsoft Azure

 

Inside the 2024 Threat Detection Report

 

Better know a data source: Files

 

Why adversaries have their heads in the cloud

Subscribe to our blog

 
 
Back to Top