Cloud coverage: Detecting an email payroll diversion attack

What follows are a pair of examples illustrating the log data you would see from a UserLoggedIn and MailboxLogin operation.

Exchange MailboxLogin log sample

Azure Active Directory UserLoggedIn log sample

A pivot point is a piece of data that can expand or narrow down the scope of an investigation. Audit logs that stem from the Cloud may be totally new to defenders, particularly as cloud security research expands and as organizations invest more in cloud system visibility. Some of the fields we’re about to discuss may be new to those who are less familiar with cloud data, but they offer fantastic context that help us see the bigger picture when responding to incidents.

IP addresses in the audit logs overlap slightly between Exchange and Azure. Microsoft documentation explains how they are different and where you can find them, including the following table:

The IPs mainly help us understand if there might be other victim email accounts within the organization or other customer environments. Although easily changeable by the adversary, it’s a simple pivot point. Enriching the IP with context like geolocation, known vpn/proxy/tor services, ISP, and fraud activity helps detection engineers decide to pursue or ignore potential leads.

Another great field for targeting suspicious adversary behavior within a given logon period is the Session ID. These can be found in the SessionId field of the Exchange logs, but within AzureActiveDirectory they’re an embedded value found in the DeviceProperties JSON blob, as seen in the UserLoggedIn example above. Pivoting on Session ID is not a new concept and is also applied with endpoint telemetry to help develop timelines of adversary activity. In the example attack we’re about to return to, the adversary had one single logon session that we’ll use to follow their exact actions.

The ApplicationId, or AppID, helps identify what service the attackers targeted or logged into. This ID value is a unique representation of a Microsoft 365 resource in which defenders can use the CloudAppEvents table within Microsoft Defender for Cloud Apps to query for more detailed information on the application. While custom or third-party applications will have unique IDs, first-party Microsoft services have standard IDs that can be correlated to identify activity related to Microsoft services. The Application ID in our case was 00000002-0000-0ff1-ce00-000000000000, which Microsoft clearly defines as “Office 365 Exchange Online” in their catalog of commonly used Applications.

Lastly, the User Agent can help scope incidents, but is not necessarily considered a high-fidelity indicator since, these tend to have a large overlap with devices using the same browser and operating system versions. The User Agent is listed as the ClientInfoString in Exchange logs but in Azure Active Directory they’re found within the ExtendedProperties JSON, also seen in our log example listed above. In this particular investigation, the User Agent was pretty fruitful, as it was uniquely found within this one session.

Back to the attack

The following is a timeline of the adversary’s activity from our example detection, which we’ll detail further and use to explore relevant audit log telemetry.

It’s usually a good idea to open the aperture on an investigation like this to figure out if there are any suspicious logs that preexist overtly malicious activity. You can do this by turning off operations or specific Session ID filters. Doing so in incidents like this often reveals failed logon attempts. The AppId field in the following example informs us that the failed logons occurred from the Office Home application. The following Exchange log shows relevant information about the failed logon:

Note: the LogonError field suggests that the logon attempt was blocked because of a custom configuration

We can now inspect the audit logs further for any operations that came in after the initial spike of logon activity. Using the SessionID acquired from the successful login we previously identified, we can then modifying our Splunk search to show all Exchange and Azure Active Directory operations associated with that SessionID that occurred with 15 minutes:

From this list we can see the New-InboxRule operation that initially tipped our Detection Engineering team off to unusual activity—as well as the Set-InboxRule operation that was used to modify the rule that was created. We can also see a large number of MailItemsAccessed, Create, Send, and Move operations. Let’s dive into each of these operations.

The Create operation is interesting. According to Microsoft, this event should not have been logged because creating, sending, or receiving a message isn’t audited. In our case, this does not appear to be true. This log shows that Outlook created a new entry in the “\Drafts” folder of the user mailbox within the same logon session that created the abnormal email rule. We can also see the subject of the email: “Direct Deposit Update”. More to come on that…

Send operations are generated when a user sends, replies to, or forwards an email message. In order to log this activity, the user must have an active Office 365 or Microsoft 365 E5 license applied to their account. Unfortunately this event does not provide who the message was sent to. To identify who the email was sent to, we use the InternetMessageId field to track the email in Exchange via the Get-MessageTrackingLog PowersShell module.

Now let’s talk about  MailItemsAccessed. This operation tells us that within this logon session, a number of emails were actually accessed. To generate these logs, like the Send operation, the user must have an active Office 365 or Microsoft 365 E5 license. Within this operation, there is a key piece of information we need to identify: the access type that generated the log. There are two access methods that can be logged within MailItemsAccessed: sync and bind.

Sync logs indicate that an Outlook desktop client or other Exchange ActiveSync compatible client was used to synchronize messages between Exchange and the Client device. Sync logs only provide the mailbox folder that was synced. If you see an adversary sync a user’s inbox, you must assume that ALL emails in that user’s inbox are compromised. The same is true for any other folder within the user’s mailbox.

Bind logs work slightly differently than sync logs. They log individually accessed messages. Bind events will be generated for protocols such as POP, IMAP, EWS and REST. Within the log we can see the specific emails that were accessed based on their InternetMessageId. However, bind logs collect telemetry two minutes at a time, so a single bind log can show that multiple messages have been accessed. Another thing to note about bind logs is that they can be throttled. Throttling occurs when more than 1,000 MailItemsAccess logs are generated in less than 24 hours. Throttling is denoted in the log under the IsThrottled field.

There are a number of JSON blobs within one of these logs that contain the interesting information we need to identify what access type was used and the folders and messages accessed. The Folders blob will provide the mailbox folders that were accessed for both bind and sync logs, but bind logs will also have a FolderItems blob that contains the information for individual messages that were accessed. The OperationCount field provides the number of accessed items contained in the log (remember that MailItemsAccess rolls a 2-minute window of activity into a single log). Finally, the OperationProperties blob tells us the access type and indicates if the log is being throttled. In this particular case, we had 141 MailItemsAccessed logs resulting in the actor accessing over 1,500 emails in less than 20 minutes.

Note: we’re continuing to research why 141 logs were generated in this case, as Microsoft’s documentation seems to suggest that this activity ought to have been aggregated in a single audit record.