Cross-source coverage
T1098.002 / ATT&CK
Account Manipulation: Additional Email Delegate Permissions
10 rules across 4 sources.
From MITRE ATT&CK 19.2
Adversaries may grant additional permission levels to maintain persistent access to an adversary-controlled email account.
For example, the Add-MailboxPermission PowerShell cmdlet, available in on-premises Exchange and in the cloud-based service Office 365, adds permissions to a mailbox. In Google Workspace, delegation can be enabled via the Google Admin console and users can delegate accounts via their Gmail settings.
Adversaries may also assign mailbox folder permissions through individual folder permissions or roles. In Office 365 environments, adversaries may assign the Default or Anonymous user permissions or roles to the Top of Information Store (root), Inbox, or other mailbox folders. By assigning one or both user permissions to a folder, the adversary can utilize any other account in the tenant to maintain persistence to the target user’s mail folders.
This may be used in persistent threat incidents as well as BEC (Business Email Compromise) incidents where an adversary can add Additional Cloud Roles to the accounts they wish to compromise. This may further enable use of additional techniques for gaining access to systems. For example, compromised business accounts are often used to send messages to other accounts in the network of the target business while creating inbox rules (ex: Internal Spearphishing), so the messages evade spam/phishing detection mechanisms.
- Tactics
- Persistence · Privilege Escalation
- Platforms
- Windows · Office Suite
- Telemetry
-
m365:unifiedWinEventLog:Security
How MITRE says to detect it DET0373
Detection Strategy for Addition of Email Delegate Permissions
Office Suite Analytic 1051
Detection of anomalous or unauthorized mailbox delegation activity (e.g., Add-MailboxPermission, Default/Anonymous mailbox permissions, Gmail delegation setup).
m365:unifiedAdd-MailboxPermission, UpdateFolderPermissions
Windows Analytic 1052
Execution of PowerShell commands that modify mailbox permissions using Exchange cmdlets (e.g., Add-MailboxPermission), often tied to BEC or post-compromise persistence.
WinEventLog:SecurityEventCode=4688m365:unifiedPowerShell: Add-MailboxPermission
splunk/security_content
6 rules| Detection | Severity | Format |
|---|---|---|
| Azure AD FullAccessAsApp Permission Assigned | Undefined | SPL |
| O365 ApplicationImpersonation Role Assigned | Undefined | SPL |
| O365 Elevated Mailbox Permission Assigned | Undefined | SPL |
| O365 FullAccessAsApp Permission Assigned | Undefined | SPL |
| O365 Mailbox Folder Read Permission Assigned | Undefined | SPL |
| O365 Mailbox Folder Read Permission Granted | Undefined | SPL |
elastic/detection-rules
2 rules| Detection | Severity | Format |
|---|---|---|
| New ActiveSyncAllowedDeviceID Added via PowerShell | Medium | Elastic TOML |
| M365 Exchange Mailbox High-Risk Permission Delegated | Low | Elastic TOML |
Bert-JanP/Hunting-Queries-Detection-Rules
1 rule| Detection | Severity | Format |
|---|---|---|
| List MS Graph Mail Permissions Added | Undefined | KQL |
Wazuh Core Ruleset
1 rule| Detection | Severity | Format |
|---|---|---|
| Office 365: User got FullAccess permissions in Exchange · office365.Parameters = \"Value\":\s*\"FullAccess\" | High | Wazuh XML |