invictus-ir/Microsoft-Extractor-Suite

[Feature Request] Get Mailbox Auditing configuration

Passimist opened this issue · 6 comments

Passimist commented

Hi there,

as you probably know mailbox auditing is enabled by default configured with a default set of logged event types, which is documented here: https://learn.microsoft.com/en-us/purview/audit-mailboxes#mailbox-actions-for-user-mailboxes-and-shared-mailboxes

To verify that the compromised users mailbox auditing is configured in a way that is useful for forensics I like to use the following commands:
This one returns which audit sets are running on default configuration. For a default setup the expected output is
"DefaultAuditSet : {Admin, Delegate, Owner}"
Get-Mailbox -Identity <MailboxIdentity> | Format-List DefaultAuditSet

If the mailbox is not running with default configuration I use the following command to get a list of logged actions:
For the owner set:
Get-Mailbox -Identity <MailboxIdentity> | Select-Object -ExpandProperty AuditOwner
Delegate set:
Get-Mailbox -Identity <MailboxIdentity> | Select-Object -ExpandProperty AuditDelegate
Admin set:
Get-Mailbox -Identity <MailboxIdentity> | Select-Object -ExpandProperty AuditAdmin

I belive this configuration check would be a nice feature for this project. What do you think about it?

JoeyInvictus commented

Hi,

Thank you for the suggestion! Microsoft will, starting from April 30, deprecate the following cmdlets:

  • Search-AdminAuditLog
  • Search-MailboxAuditLog
  • New-AdminAuditLogSearch
  • New-MailboxAuditLogSearch

You can still retrieve the Mailbox Audit Logs via the Search-UnifiedAuditLog cmdlet. Therefore, we are planning to remove the Get-MailboxAuditLog option from the Extractor Suite in the near future.

Source:
https://techcommunity.microsoft.com/t5/security-compliance-and-identity/important-announcement-deprecation-of-search-adminauditlog-and/ba-p/4036537

Feel free to reopen the issue if you have any questions or remake.s

Passimist commented

Hi,

thank you for your quick responses to my issues!
Microsoft deprecating those cmdlets is an interesting information that I was not yet aware of. But I have always been using the UAL only since it contains all the events that are logged in the AdminAuditLog and MailboxAuditLog, correct?

Thought I believe to use case for my suggestions still exists, if I understand the future situation correctly:

From what I understand the Mailbox Auditing Configuration that is set per mailbox in EXO also determines which mailbox activity types are logged in the UAL. Is that right?
If this is correct I think in a forensic investigation we need a way to verify the mailbox auditing configuration because if e.g.:
We do not see MailItemsAccessed events in the UAL for a E5 user this could have two reasons.

  1. The attackers did not access any emails
  2. The mailbox is configured to not log those activities
    And all analysis results are worthless if we don't know which of those two is the reason for the absence of MailItemsAccessed events.

Let me know what you think.

Passimist commented

@JoeyInvictus sadly I can't re-open issues if they were closed by someone else but I would like to do so. :)

JoeyInvictus commented

Hi, I've reopened the issue @Passimist .

There were previously minor differences between the Unified Audit Log and the Mailbox Audit Log. Specifically, one could determine if a mailbox had been synchronized by using the Mailbox Audit Log. However, it's been some time since I last checked, and I'm unsure if these differences still are there.

What also is interessting, though not directly related to our current discussion, is that the session ID is available in login events within the Unified Audit Log (UAL), and not in the sign-in events from Entra Identity. It would be cool/valuable to analyse to explore the differences between collecting information through the Graph API, PowerShell Exchange module, and GUI interfaces at a future date (So many things to do so little time:( ).

You're right in pointing out that the logs available vary between the E3 and E5 plans. But you can even assign E5 advanced auditing licenses to specific user accounts, which means it might not cover every user in the organization. It's important for forensic investigators to verify the available license type before utilizing the tool to understand the extent of data retention and the functionality available to them.

What is your vision regarding implementing this? Would there be a seperate function to check what sort of data is available? I think this would be challenging since it depends on a variety of different license modules, which vary per function. For instance, certain functions, like the Get-RiskyUsers function, are not compatible with P1 AD licenses. Therefore, it might be better to include a section in the documentation that outlines the prerequisites and potential limitations for each function.

Passimist commented

Hi,

This is a very interesting discussion because it is exactly like you said "too many things that need testing and want to be found out, but too little time". I will split the different topics by numbers so we don't get confused.

  1. I did not know that Mailbox Sync was previously only logged in the Mailbox Audit Log and not in the UAL.
    I did a quick search through my historical splunk data and found this in an UAL:
    August 2023, Operation: MailItemsAccessed, MailAccessType: Sync
    I see more such events but this is my earliest, so I suppose this means that at least since August 23 the Mailbox Sync is visible in the UAL. Microsoft also tells us to search the UAL for mailbox sync in step 2 of this guide: https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts#use-mailitemsaccessed-audit-records-for-forensic-investigations

  2. Regarding the session ID in login events only appearing in the UAL and not the Entra SignIn-Logs I can confirm that is still the case and very annoying during analysis. You mentioned differences between logs gathered via GUI and cmdlet. For a long time I hoped there would be no difference but then I read this part of Microsofts docs stating that: "users without E5/A5/G5 license generate mailbox audit log events but they are not available via GUI but only PowerShell." https://learn.microsoft.com/en-us/purview/audit-mailboxes#more-information

  3. The original topic of this issue. :) My suggestion is not about differences in logging due to licenses. I agree one of the first steps during forensics is to identify the used license so you know what features and log types are theoretically available. But regardless of the users license there is the option (for admins pre-incident) to en-/disable certain mailbox event types in the mailbox audit log. This Microsoft docs link shows the default configuration: https://learn.microsoft.com/en-us/purview/audit-mailboxes#mailbox-actions-for-user-mailboxes-and-shared-mailboxes
    So theoretically an admin could have altered this configuration and e.g. disabled the logging of "HardDelete" actions for a specific user. This would cause the "HardDelete" events to not appear in the Mailbox Audit Log anymore and I am assuming that this also affects the UAL. Now when I try to investigate the incident I might be wondering: "Are there no HardDelete events because the attackers did not delete anything or because they are disabled via this configuration?
    Do you agree with this example scenario?
    If yes, my suggestion for this project is to use the cmdlets I mentioned above to identify if:
    a) The mailbox audit log configuration deviates from the default using the Get-Mailbox cmdlet like this:
    Get-Mailbox -Identity <MailboxIdentity> | Format-List DefaultAuditSet
    This command returns DefaultAuditSet : {Admin, Delegate, Owner} if all audit sets of this user are on default configuration.
    b) If either Admin, Delegate or Owner are missing from the first output you can use the following commands to see which action types are configured to be logged for specific audit set of the user.
    For the owner set:
    Get-Mailbox -Identity <MailboxIdentity> | Select-Object -ExpandProperty AuditOwner
    Delegate set:
    Get-Mailbox -Identity <MailboxIdentity> | Select-Object -ExpandProperty AuditDelegate
    Admin set:
    Get-Mailbox -Identity <MailboxIdentity> | Select-Object -ExpandProperty AuditAdmin

invictus-korstiaan commented

Thanks for the response, I'll try to respond to your points.

For point 1 it's not necessarily just syncing mailbox items but differences between what was recorded in the MAL vs the UAL. If you're talking about the MailItemsAccessed operation, as far as I know this always has tracked both sync/bind access to emails.
For point 2, don't think there's an issue/disagreement here, I think we can agree on the 'interesting' nature of licensing in M365.
For point 3, definitely an interesting use case. As we're mostly doing incident response cases we tend to investigate after the fact with what we have. And an investigator should be able to determine whether 'expected' logs are missing. Additionally, changes to auditing settings are actually also audited which should be something that an investigator looks for.
If you want a proactive check on deviation of the settings, you can create a PR and we will check if we can incorporate it into the toolset.