Why Good Logging is Critical

To one degree or another, operating systems, network appliances, software applications, and software services all create diagnostic logs. By cross-referencing the timestamps in the logs you can build up an accurate picture of what was happening in your network at any point in time.

User activity, inter-process communication, file access, the network traffic moving through your network, connections into and out of your network, and more are all logged. There’s no sinister agenda behind this. Logging—and the subsequent analysis of those logs—is standard operating procedure when you’re diagnosing operational problems or cybersecurity incidents.

When you’re trying to discover how a system was compromised and what a threat actor did when they had access to your system, examining logs is always one of the first steps. Being able to refer to a detailed record of events beats trying to piece together what happened from user testimony alone.

The users are limited to describing what they experienced and what they saw the system do. Although they’re trying to be helpful all they can give you is their recollection of the visible symptoms of the incident. That doesn’t provide any insight into what the affected devices and systems were doing internally—or thought they were doing—at that the time of the incident. And investigators need that level of information to determine the root cause of the incident.

Obviously, the more detailed your logs are the more useful they will be in a forensic or diagnostic situation. The more granular the information the devices provide and the more frequently that information is written to the log, the better.

You Need an E5 or G5 License

Microsoft have recently made another event type— MailItemsAccessed —appear in the Advanced Audit Logs in Microsoft 365. This is important because it allows investigators to see which mail items have been accessed in a cyberattack. This event has existed previously, but it has only recently been exposed and allowed to filter through to the logs.

Knowing which email items were accessed during a cyberattack might help you prevent exploitation of the data contained in those emails. It might also be a data protection requirement for you to be able to identify the compromised emails, the senders, and recipients of those emails.

The MailItemsAccessed event will let you do just that, but Advanced Audit isn’t available to everyone on Microsoft 365. It is available for organizations with an Microsoft 365 Enterprise E5 or G5 subscription. These licenses provide the Advanced Audit functionality and retention of log files for one year. You can choose to extend that to 10 years if you wish. This 10-year retention option allows organizations to perform investigations into historical events and to satisfy data protection, legal, or other obligations.

The MailItemsAccessed Event

The MailItemsAccessed event is triggered when emails are accessed. If a threat actor gains access to a Microsft 365 account the MailItemsAccessed action will be triggered—and logged—even if there is no explicit indication that the compromised emails were read. Just accessing the emails is enough to raise the event. Of course, the event is raised when a regular user legitimately accesses their email, too, but an investigation is going to be zeroing in on particular time periods, allowing the actions of the regular user to be discarded.

The MailItemsAccessed mailbox event replaces an older event called MessageBind, and provides several enhancements:

 MailItemsAccessed applies to all login types. MessageBind couldn’t report on regular users and email delegates. It reported on AuditAdmin logins only. The MailItemsAccessed event is triggered by sync events and bind events. A sync event is raised when mail is synced to an email client. This can affect many emails. A bind event is raised when a single email is accessed. MessageBind events were only raised for sync events. The MailItemsAccessed event is less noisy. The MessageBind event could trigger repeatedly for the same email.

Across an organization, there can be many bind events raised in a continuous stream all day. Microsoft 365 reduces the number of events by aggregating them into two-minute sequences. If a single mailbox generates more than 1000 bind events in a 24-hour period, Microsoft 365 throttles the event logging for that mailbox for the next 24 hours. It’s important that you take this into account in an investigation.

Using MailItemsAccessed in Searches

To search the Advanced Audit logs in Microsoft 365 you need to have either the View-Only Audit Logs or the Audit Logs roles assigned to you. Searches are performed using Exchange Online Powershell or the Microsoft Security and Compliance Center.

If it isn’t already enabled, you’ll need to turn on the audit search capability:

This is the generic command to search the mailbox audit logs for MailItemsAccessed events, during a specified period, for a specified user account.

Investigating a Compromised Mailbox

The first step is to check whether the mailbox was throttled. If it was, you have to assume the worst-case scenario and treat all emails to that user account in that 24-hour period as compromised.

This will return MailItemsAccessed records that were generated while the mailbox was throttled, for the specified period, for a specified user account.

You need to know whether any sync events took place. If they did, the threat actor has downloaded the email to their local email client. They can then disconnect from the server and review and search the email without generating any more events on the server.

This commands searches for sync events during a specified period, for a specified user account.

If any sync events are found you need to determine from the IP address whether that action was performed by the threat actor. If that is the case, again you need to assume the worst-case scenario and work on the premise that the entire mailbox has been compromised.

You should also search for bind events for the compromised umailbox, for the period of interest.

Microsoft 365 email messages are identified by an internet message id, held in their InternetMessageId value. You can use the bind search results to identify the individual emails. You can then review them to see whether they contained any sensitive or company confidential information.

You can do this the other way round too. If you know the InternetMessageId of emails that are known to contain sensitive information, you can search the results for those InternetMessageIds .

A Real-World Example

The Cloud Forensics team of the Cybersecurity and Infrastructure Security Agency (CISA) has released a script designed to help detect possible compromised accounts and applications in Microsoft Azure and Microsoft 365 environments.

The script will install any PowerShell modules that it needs that are not present on the machine used for the investigation. It then:

Checks the unified audit log in Azure/Microsft 365 environments for typical signs of compromise. Lists the Azure AD domains. Checks the Azure service principals and their Microsoft Graph API permissions to try to identify threat actor activity. Creates multiple CSV files for further review.

The MailItemsAccessed event is referenced several times in the script. This is a short section from the script that uses the MailItemsAccessed event to check whether mail items have been accessed.

The script and some other useful tools are freely available, along with comprehensive guidance on how to use them.