Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1350: Analytic 1350

Behavioral chain: (1) delegated administration offers/relationships created or modified by partner tenants; (2) mailbox delegation/impersonation enabled; (3) follow-on access from partner IPs.

EnterpriseAN1350AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because it focuses on a high-risk trust path in office-suite environments: partner or delegated administration relationships that lead to mailbox delegation or impersonation, followed by access from partner-associated IP addresses. For executives and security leaders, the decision value is validating whether third-party administrative trust and mailbox access are governed, logged, and reviewable before they become an incident-response blind spot.

Executive priority

Treat this as a control-assurance and incident-readiness priority for Office Suite environments that use partner or delegated administration. Leaders should ask who can create or modify delegated administration relationships, how mailbox impersonation or delegation is approved, whether partner-originated access is distinguishable in logs, and whether audit evidence exists for periodic review. This is especially relevant to third-party risk, identity governance, compliance evidence, and business continuity for email-dependent operations.

Technical view

SOC, detection engineering, and IR teams should validate visibility across the full behavioral chain described by the analytic: creation or modification of delegated administration offers or relationships by partner tenants; enabling mailbox delegation or impersonation; and subsequent mailbox or office-suite access from partner IP addresses. Because no official detection logic or ATT&CK tactics are supplied, teams should translate this into local detections using available Office Suite administrative audit logs, mailbox permission and impersonation events, partner relationship changes, sign-in records, and source IP context. The key validation question is whether these events can be correlated by tenant, account, partner relationship, mailbox, time window, and source network.

Likely telemetry

  • Office Suite administrative audit logs for delegated administration offer or relationship creation and modification
  • Mailbox permission, delegation, and impersonation configuration events
  • User and administrator sign-in logs, including source IP address and tenant or partner context where available
  • Mailbox access events associated with delegated or impersonated access
  • Change records or approval evidence for partner administration and mailbox delegation

Detection direction

  • Build or validate correlation across the three-part chain rather than alerting only on a single administrative change.
  • Tune for authorized partner operations by comparing events with approved partner relationships, change tickets, and expected support windows.
  • Review blind spots where partner tenant activity, mailbox impersonation, or delegated mailbox access is not retained or not forwarded to the SOC.
  • Validate whether partner IP context is reliable in the local environment; absence of known partner IP mappings can weaken this analytic.
  • Use the analytic as a hunting and assurance pattern because the supplied ATT&CK object does not provide official detection logic.

Mitigation priorities

  • Inventory and periodically review delegated administration relationships in the Office Suite environment.
  • Restrict who can approve or modify partner administration and mailbox delegation or impersonation settings.
  • Require documented business approval and time-bounded use for mailbox delegation or impersonation where feasible.
  • Ensure administrative, mailbox, and sign-in logs are retained and available for investigation and compliance evidence.
  • Include partner-admin and mailbox-delegation scenarios in incident response playbooks and access review procedures.
Analyst notes and limits

The supplied ATT&CK object is a detection analytic, not a technique, and no relationship context or official detection implementation is provided. The strongest defensive value is governance and telemetry validation around partner trust, mailbox delegation, impersonation, and follow-on access in Office Suite environments.

This take is limited to the official STIX fields provided. No active exploitation, attribution, specific vendor implementation, tactic mapping, or guaranteed detection coverage is implied. Local tenant configuration, logging availability, partner operating model, and retention settings are required to determine practical coverage.

Official MITRE ATT&CK definition

Analytic 1350

Behavioral chain: (1) delegated administration offers/relationships created or modified by partner tenants; (2) mailbox delegation/impersonation enabled; (3) follow-on access from partner IPs.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
4fc8a439642dc966...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 4fc8a439642d…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1350
    Open source URL
Source and licensing

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.