DET0373: Detection Strategy for Addition of Email Delegate Permissions
This detection strategy is tied to monitoring when email delegate permissions are added, a behavior ATT&CK associates with persistence and privilege escala...
Analyst context for executives and security teams
This detection strategy is tied to monitoring when email delegate permissions are added, a behavior ATT&CK associates with persistence and privilege escalation. For leaders, the business issue is that mailbox delegation can let an intruder keep access to sensitive communications even after passwords are changed, making email governance, admin activity review, and incident response validation important.
Executive priority
Prioritize this as an identity and messaging-system control question: can the organization prove who granted mailbox access, to whom, when, and whether the change was authorized? This matters for executive communications, legal and compliance evidence, fraud risk, and recovery decisions during an email compromise investigation.
Technical view
ATT&CK links this strategy to T1098.002, Additional Email Delegate Permissions, with related platforms listed as Windows and Office Suite and related tactics of persistence and privilege escalation. SOC and IR teams should validate logging and alerting for mailbox permission changes, especially administrative actions such as permission grants in Exchange or Office 365 contexts referenced by the related technique. Because the object provides no official detection logic, teams should build detections from local audit events, administrative command logs, and change-management context rather than assuming ATT&CK supplies a ready rule.
Likely telemetry
- Mailbox audit logs showing delegate or mailbox permission changes
- Administrative audit logs for email platforms and directory-integrated messaging services
- PowerShell or administrative command logging where mailbox permissions can be modified
- Identity provider sign-in and administrator activity logs tied to the actor making the change
- Change-management or ticketing records to distinguish approved delegation from suspicious changes
Detection direction
- Baseline normal mailbox delegation patterns for executives, shared mailboxes, service accounts, and administrative teams.
- Alert on new or unusual delegate permission grants, especially where the granting account, target mailbox, or delegate account is uncommon or high risk.
- Correlate permission additions with recent suspicious sign-ins, privilege changes, password resets, or incident-response activity.
- Tune for legitimate help desk, migration, and shared-mailbox administration workflows to reduce false positives.
- Review whether logs are retained long enough to support investigations, since delegate access can be used for persistence over time.
Mitigation priorities
- Restrict who can grant mailbox delegate permissions and review those roles regularly.
- Require approval and evidence for delegation changes, especially for sensitive or executive mailboxes.
- Use periodic access reviews to identify stale, excessive, or unexplained mailbox delegation.
- Protect administrative accounts with strong identity controls and monitoring.
- Include mailbox permission review in email-compromise incident response and recovery checklists.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with no official description, no official detection text, and no tactics or platforms directly specified on the strategy itself. The practical guidance here is derived from the supplied relationship to T1098.002 and its provided context around additional email delegate permissions, persistence, privilege escalation, Windows, Office Suite, Exchange, and Office 365.
This take does not assert active exploitation, attribution, or existing detection coverage. Local email platform architecture, audit logging configuration, administrator workflows, and retention settings are required to turn this into a reliable detection or control assessment.
Detection Strategy for Addition of Email Delegate Permissions
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1098.002 | Additional Email Delegate Permissions Sub-technique | This object detects Additional Email Delegate Permissions. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 6e6edd3060f4… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0373Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.