DET0488: Detect abuse of Trusted Relationships (third-party and delegated admin access)
DET0488 is a detection strategy for spotting abuse of trusted relationships, such as third-party providers or delegated administrators. The business issue...
Analyst context for executives and security teams
DET0488 is a detection strategy for spotting abuse of trusted relationships, such as third-party providers or delegated administrators. The business issue is that legitimate external access can become an initial access path and may receive less scrutiny than normal remote access. Leaders should treat this as a governance and monitoring problem, not only a SOC rule problem: know who has trusted access, what privileges they hold, and whether their activity is visible enough to support fast incident decisions.
Executive priority
Prioritize this where external providers, delegated admins, or partner connections can reach internal systems, identity providers, or cloud environments. The key decision value is validating whether privileged third-party access is inventoried, monitored, reviewable, and revocable. This supports business continuity, incident response readiness, access governance, and compliance evidence because a trusted connection can bypass assumptions about perimeter-focused control coverage.
Technical view
The supplied ATT&CK object has no official description, detection text, tactics, or platforms of its own. Its relationship to T1199 Trusted Relationship places the relevant behavior in initial access and references IaaS, Identity Provider, Linux, and macOS in the related technique. SOC and IR teams should validate visibility around third-party and delegated administrator authentication, authorization changes, privileged sessions, and activity from external providers. Detection work should focus on distinguishing expected provider administration from unusual timing, source location, privilege use, resource access, or changes outside approved scope.
Likely telemetry
- Identity provider sign-in and audit logs for external, delegated, and privileged accounts
- Cloud control-plane audit logs for delegated administration and access to IaaS resources
- Privileged access management or session management records where available
- Account, group, role, and permission change events
- Remote administration, VPN, SSO, federation, or partner access logs where used
Detection direction
- Start with an inventory-driven approach: detection quality depends on knowing which third parties and delegated admins are authorized, what access paths they use, and what scope is normal.
- Baseline expected provider behavior, including source networks, authentication patterns, administrative actions, and maintenance windows; alert on deviations that materially increase risk.
- Correlate identity events with cloud and endpoint administration activity so a legitimate login is not treated as benign when followed by unusual privilege or resource activity.
- Tune for false positives from scheduled vendor maintenance, emergency support, and planned migrations, but require documented approvals so tuning does not hide unmanaged access.
- Look for blind spots where third-party access bypasses central identity, logging, privileged access workflows, or standard SOC monitoring.
Mitigation priorities
- Maintain a current inventory of trusted third-party and delegated administrator relationships, including business owner, access scope, and expiration or review cadence.
- Enforce least privilege and limit standing elevated access where operationally feasible.
- Centralize authentication and logging for third-party access paths to support monitoring and audit evidence.
- Review and remove unused, excessive, or undocumented delegated privileges and partner connections.
- Define incident response procedures for rapidly validating, suspending, or revoking trusted access when suspicious activity is observed.
Analyst notes and limits
This take is based on DET0488 and its stated relationship to T1199 Trusted Relationship. Because the detection strategy itself provides no official detection text, the guidance is framed as validation direction rather than a claim of specific analytic logic or coverage.
The ATT&CK detection strategy object does not specify platforms, tactics, description, or detection details. Platform and tactic context comes only from the related T1199 technique. Local architecture, identity design, third-party access models, and logging coverage are required to determine practical detections and control gaps.
Detect abuse of Trusted Relationships (third-party and delegated admin access)
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 | T1199 | Trusted Relationship | This object detects Trusted Relationship. |
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 | 73c790a72826… |
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 DET0488Open 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.