Azure
Minimal required privileges to access logs / perform a security review
The following privileges / roles are required in the Azure AD tenant and Exchange Online instance:
Azure AD tenant:
Global Reader
("Lecteur Général") role.Exchange Online environment:
View-Only Audit Logs
role ("Journaux d’audit en affichage seul") role. This role is by default granted to theCompliance Management
andOrganization Management
role groups (for which members can be assigned). Members can be assigned to the aforementioned groups through the Exchange administration portal.Azure subscription (for retrieving
Azure Activity logs
for the given subscription):Log Analytics Reader
role.Azure DevOps organization (for retrieving
Azure DevOps Activity logs
for the given Azure DevOps organization):Auditing\View audit log
permission.
Office365 security review
Licensing plans
The licensing plans in use will define the level of logs available. For instance, MailItemsAccessed
mail access events will only be available for users with an E5 license.
The license plans in use, and their associated users, can also be visualized from the Microsoft 365 admin center (https://portal.office.com/Adminportal/Home/?#/licenses).
Mailbox auditing configuration
Mailbox auditing is on by default for the entire Office365 tenant, but can be turned off. Turning off mailbox auditing will result mailbox actions no longer being audited (even if auditing is enabled on at a mailbox level). Existing mailbox audit records will however be retained until the audit log age limit for the record expires.
The following logon types are used to classify the audited actions on a mailbox:
Owner
: The account that's associated with the mailbox.Delegate
: A user who's been assigned theSendAs
,SendOnBehalf
, orFullAccess
permission to another mailbox.Admin
: The mailbox is searched with aMicrosoft eDiscovery
tool or is accessed with theMicrosoft Exchange Server MAPI Editor
.
While mailbox auditing cannot be disabled for a specific mailbox if mailbox auditing is enabled tenant-wide, mailbox audit logging can still be bypassed by defined users. In such circumstances, mailbox Owner
, Delegate
, or Admin
aren't logged.
Emails forwarding
Mailbox Email Forwarding
Mailbox Email Forwarding can be configured by any user for their mailbox, allowing forwarding to external (ForwardingSmtpAddress
) or internal (ForwardingAddress
) email addresses.
The email forwarding configured on a given mailbox can also be visualized from the Microsoft 365 admin center (https://portal.office.com/Adminportal/Home/?#/users).
Mailbox Inbox rules
Mailbox Inbox rules can be configured by any user for their mailbox, allowing forwarding to external or internal email addresses as well as deletion of received emails.
Mailbox Mail Flow / Transport rules
Mailbox Mail Flow / Transport rules can only be configured by Exchange Admin
users, and allow actions to be taken on in transit emails. For instance, a blind copy (i.e with out disclosure to the sender or recipients) can be send to external or internal email addresses.
Mailbox delegations
The following level / scope of delegations can be configured:
Mailbox permissions: to allow items viewing at the mails box level (but not the right to send emails).
Recipient
SendAs
permissions: to delegate the right to send emails from the mailbox (that transparently appear to come from the specified mailbox to the recipients).Recipient
SendOnBehalf
permissions: to delegate the right to send emails on behalf of the mailbox (and will appear as such to the receiving recipients).Folder-level permissions: to delegate the rights to interact with items at the mailbox's folder level.
Mailbox access rights / permissions
Mailboxes are securable objects with a set of possible access rights / permissions.
The available access rights are:
ChangeOwner
: change the owner of the mailbox.ChangePermission
: change the permissions on the mailbox.DeleteItem
: delete the mailbox.ExternalAccount
: indicates the account isn't in the same domain.FullAccess
: open the mailbox, access its contents, but can't send mail.ReadPermission
: read the permissions on the mailbox.
The permissions defined on that level allow for emails viewing at the mailbox scope but do not allow sending emails (which is defined through the ).
Recipient (or SendAs
) access right / permission
Recipient, or SendAs
, permission does not allow for emails viewing but allow a user, or group members, to send messages that appear to come from the specified mailbox. The email received from the mailbox owner or through a SendAs
delegation are indistinguishable by the receiving end-user.
Note that the Get-EXORecipientPermission
/ Get-RecipientPermission
is not included by default in the cmdlets allowed for the View-Only Organization Management
role group.
Folder-level permissions
Permissions / access rights can also be defined at the folder-level in mailboxes, to grant delegate the rights to interact with items at the mailbox's folder level.
The following individual permissions are available:
None
: The user has no access to view or interact with the folder or its contents.CreateItems
: The user can create items within the specified folder.CreateSubfolders
: The user can create subfolders in the specified folder.DeleteAllItems
: The user can delete all items in the specified folder.DeleteOwnedItems
: The user can only delete items that they created from the specified folder.EditAllItems
: The user can edit all items in the specified folder.EditOwnedItems
: The user can only edit items that they created in the specified folder.FolderContact
: The user is the contact for the specified public folder.FolderOwner
: The user is the owner of the specified folder. The user can view the folder, move the folder and create subfolders. The user can't read items, edit items, delete items or create items.FolderVisible
: The user can view the specified folder, but can't read or edit items within the specified public folder.ReadItems
: The user can read items within the specified folder.
The following roles, that group individual permissions, are available:
Author
: CreateItems, DeleteOwnedItems, EditOwnedItems, FolderVisible, ReadItems.Contributor
: CreateItems, FolderVisible.Editor
: CreateItems, DeleteAllItems, DeleteOwnedItems, EditAllItems, EditOwnedItems, FolderVisible, ReadItems.NonEditingAuthor
: CreateItems, DeleteOwnedItems, FolderVisible, ReadItems.Owner
: CreateItems, CreateSubfolders, DeleteAllItems, DeleteOwnedItems, EditAllItems, EditOwnedItems, FolderContact, FolderOwner, FolderVisible, ReadItems.PublishingAuthor
: CreateItems, CreateSubfolders, DeleteOwnedItems, EditOwnedItems, FolderVisible, ReadItems.PublishingEditor
: CreateItems, CreateSubfolders, DeleteAllItems, DeleteOwnedItems, EditAllItems, EditOwnedItems, FolderVisible, ReadItems.Reviewer
: FolderVisible, ReadItems.
OAuth Permissions
OAuth
is a protocol to delegate access and grant third party websites or applications access to users data and perform operations on their behalf. With OAuth
, users don't have to reveal their credentials to the third party service, as access is granted through the Identity Provider (IdP)
(Azure AD
in Azure
case). In an OAuth
abuse attack, a victim authorizes a malicious third-party application to access their account data.
Microsoft Graph supports two access types, delegated permissions and application permissions. With delegated permissions, the application calls Microsoft Graph on behalf of a signed-in user. With application permissions, the application calls Microsoft Graph with its own identity, without a signed in user.
The delegated and application permissions available are referenced in the Microsoft documentation.
Microsoft-Extractor-Suite
's Get-OAuthPermissions
PowerShell cmdlet can be used to enumerate delegated permissions (OAuth2PermissionGrants
) and application permissions (AppRoleAssignments
) for all accounts:
Azure AD, Office365, and Azure logs overview
Note that accessing Azure AD logs through the MS Graph API
requires at least one user with an Azure AD Premium P1
or AD Premium P2
license. These license can be included in other license plans, such as Microsoft 365 E3 / E5 / F3
. The other to which is associated the license does not matter.
Azure AD, Office365, and Azure logs search and collection
Remark: if only a day is specified, as StartDate
and EndDate
for some cmdlets for instance, PowerShell will initialize the corresponding DateTime
objects at 12:00 AM (midnight) in the system local timezone (whereas records in the UAL are stored in UTC
). The results retrieved, by Search-UnifiedAuditLog
for example, will thus be bound by the local system timezone. Timestamps should thus be provided directly in UTC
or with timezone information.
[Office365] Unified audit and Mailbox Audit logs manual search
The Search-UnifiedAuditLog
cmdlet of the ExchangeOnlineManagement
module can be used to search and export the Office365 Unified Audit Logs
. The cmdlet returns a maximum of 5000 results for direct queries, 50 000 (unsorted) results for paged queries. Requests that would return a large number of events should thus automated (for instance with DFIR-O365RC
or Microsoft-Extractor-Suite
).
[Azure AD, Office365, & Azure] Microsoft-Extractor-Suite
The Microsoft-Extractor-Suite
PowerShell module can be used to extract logs from Azure AD and Office365.
[Azure AD, Office365, & Azure] DFIR-O365RC collector
DFIR-O365RC
is a PowerShell module that implement a number of cmdlets to retrieve Office 365 / Azure logs. As DFIR-O365RC
supports PowerShell Core, it can be used on both Windows or Linux endpoints.
The logs are retrieved in JSON
from the following sources of information:
Office 365 Unified Audit Logs
Mailbox Audit Log
Azure AD sign-ins logs
Azure AD audit logs
Azure Activity logs
Azure DevOps Activity logs
Manual installation
DFIR-O365RC
depends on the MSAL.PS
and PoshRSJob
modules, that must be installed before usage.
On PowerShell Core, the installation of the WSMan
client may also be required:
The DFIR-O365RC
directory of the DFIR-O365RC
project can then be placed in in one of the system modules path (retrievable using $env:PSModulePath
) and imported with Import-Module DFIR-O365RC
.
DFIR-O365RC cmdlets
Note that whenever using PowerShell Core, the -DeviceCode:$true
parameter must be specified for all DFIR-O365RC
cmdlets in order to authenticate to the Azure AD tenant. The authentication should be done using a web browser at the https://microsoft.com/devicelogin
URL and the device code obtained passed to the executed DFIR-O365RC
cmdlet.
[Azure AD & Azure] Log Analytics workspace or storage account with Diagnostic settings
Through the Diagnostic settings
, Azure logs at tenant, subscription(s), or resource(s) level can be either:
Exported to json formatted files in a
storage account blob
. Logs exported to a blob will be inPT1H.json
files, and can be downloaded using theAzure Storage Explorer
utility (among others).Send to a
Log Analytics workspace
to be processed directly in the Cloud withKQL
queries.
Once a storage account
or Log Analytics workspace
has been created, the procedure to export logs from different sources is as follow:
AzureAD
tenant logs (sign-ins and audit logs) - P1 / P2 license required:Subscription activity logs:
Resources logs:
If exported to a storage account blob
, logs will be available in the following folders:
Azure AD audit logs:
insights-logs-auditlogs
Azure AD sign-ins logs:
insights-logs-signinlogs
insights-logs-noninteractiveusersigninlogs
insights-logs-managedidentitysigninlogs
insights-logs-serviceprincipalsigninlogs
Subscription:
insights-activity-logs
Resources:
Storage accounts:
insights-logs-storageread
Key vaults:
insights-logs-auditevent
NSG flows:
insights-logs-networksecuritygroupflowevent
...
Office 365 logs analysis
Exchange Online Services workload
The following operations are notable for the Exchange
workload:
The list of actions logged (depending on the logon type) and information on whether the action is logged by default, can be found in the official Exchange documentation.
TODO: Sync vs Bind
Microsoft Flow / Power Automate workload
SharePoint workload
Anonymous links
Azure applications in AAD audit logs
Can be used to maintain persistence in M365 as applications can access applications in the subscription with out MFA
Others
Consent grant allows applications to access resources in the tenant. Permissions that can be granted: Application, Delegated, and Effective permissions.
Azure logs analysis
Activity log key fields
The key fields in the subscription / activity log schema are:
identity.claims
: nested JSON with information about the identity that performed the action and its authentication method.identity.claims.http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
: theUPN
of the identity that performed the action.identity.claims.groups
: the AzureAD groups of which the identity is a member.identity.claims.ipaddr
: the IP address the identity authenticated from.
callerIpAddress
: the IP address the action was performed from.resourceId
: the unique resource identifier of the resource. TheresourceId
follows the format:/SUBSCRIPTIONS/<SUBSCRIPTION_ID>/RESOURCEGROUPS/<RESOURCEGROUP_NAME>/PROVIDERS/<PROVIDER>/<RESOURCE_NAME>
.The provider can for example be
/MICROSOFT.COMPUTE/VIRTUALMACHINES
orMICROSOFT.STORAGE/STORAGEACCOUNTS
.operationName
: the name of the operation.Examples:
MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE
MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE
MICROSOFT.COMPUTE/VIRTUALMACHINES/START/ACTION
MICROSOFT.COMPUTE/VIRTUALMACHINES/DELETE
MICROSOFT.COMPUTE/DISKS/WRITE
MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTKEYS/ACTION
...
resultType
andresultSignature
(more verbose): the result of the operation.correlationId
: an unique identifier that can be used to map the different events associated with a single operation.
References
https://learn.microsoft.com/en-us/microsoft-365/compliance/audit-mailboxes?view=o365-worldwide
https://www.real-sec.com/2020/07/obscured-by-clouds-insights-into-office-365-attacks-and-how-mandiantmanaged-defense-investigates/
Thirumalai Natarajan & Anurag Khanna - Threat Hunting in M365 Environment - DFIR Summit 2022
https://redcanary.com/blog/email-forwarding-rules/
Last updated