DC0105: Group Metadata
Group metadata includes attributes like name, permissions, purpose, and associated user accounts or roles, which adversaries may exploit for privilege escalation. Examples:
- Active Directory: `Get-ADGroup -Identity "Domain Admins" -Properties Members, Description` - Azure AD: `Get-AzureADGroup -ObjectId
*Data Collection Measures:*
- Cloud Logging: - AWS CloudTrail for IAM group-related activities. - Azure AD Sign-In/Audit logs for metadata changes. - Google Admin Activity logs for API calls. - Directory Logging: Log metadata access (e.g., Windows Event ID 4662). - API Monitoring: Log API calls to modify group metadata (e.g., Microsoft Graph API). - SIEM Integration: Centralize group metadata logs for analysis.
Analyst context for executives and security teams
Group Metadata is the evidence about security groups: names, permissions, purpose, membership, and associated users or roles. For leaders, this matters because groups often define who can administer systems, access sensitive data, or change cloud and directory resources. If this information is poorly monitored or inconsistently logged, teams may miss changes or reconnaissance around privileged access paths that influence identity risk and incident scope.
Executive priority
Prioritize this data component as part of identity governance, cloud security, and audit readiness. Executives should ask whether the organization can prove who changed group metadata, who queried or enumerated sensitive groups, and whether privileged groups such as administrative or high-impact access groups are monitored across directory, cloud, and collaboration environments. This is especially important for incident response because group metadata can help determine privilege exposure and access pathways during an investigation.
Technical view
SOC, detection engineering, and IR teams should validate collection of group metadata access and modification evidence from the relevant identity and cloud control planes referenced by ATT&CK: Active Directory, Azure AD, Google Workspace, AWS IAM, and Office 365/Microsoft Graph where present. Because ATT&CK provides no official detection logic for this object, teams should build local analytics around access to high-value groups, metadata changes, membership-related queries, permission or policy associations, and API activity involving group objects. Detection should distinguish normal administrative inventory and provisioning workflows from unusual access patterns, unexpected principals, or changes involving privileged groups.
Likely telemetry
- Cloud control-plane logs for IAM or directory group activity, including AWS CloudTrail for IAM group-related activity
- Azure AD audit and sign-in related logs for group metadata access or changes
- Google Admin Activity logs for group API calls
- Directory logging for group object access, including Windows Event ID 4662 where configured
- API monitoring for group metadata changes, including Microsoft Graph API activity
Detection direction
- Inventory which systems hold authoritative group metadata and confirm their logs are centralized in the SIEM.
- Define high-value groups locally, such as administrative, privileged, sensitive application, or regulated-data access groups, and tune monitoring around them.
- Alert or review unexpected metadata reads or changes involving privileged groups, especially when performed by unusual users, roles, service accounts, locations, or APIs.
- Correlate group metadata activity with identity events, cloud audit events, and administrative change records to reduce false positives from approved provisioning or audit tools.
- Watch for blind spots where API access is logged separately from directory activity, or where read access to metadata is not captured by default.
Mitigation priorities
- Establish clear ownership and documentation for privileged and business-critical groups.
- Limit who can read, modify, or administer sensitive group metadata based on role and business need.
- Enable and retain audit logging for group metadata access and changes across directory, cloud, and API surfaces used by the organization.
- Centralize logs into the SIEM and ensure fields needed for investigation are preserved, including actor, target group, action, timestamp, source, and API or tool used.
- Review privileged group configuration and permissions periodically as part of identity governance, compliance evidence, and incident response preparedness.
Analyst notes and limits
This object is a data component, not a technique. Its value is in confirming whether defenders collect and can analyze the evidence needed to understand group-related identity exposure. The official ATT&CK description provides examples across Active Directory, Azure AD, Google Workspace, AWS IAM, and Office 365/Microsoft Graph, plus collection measures, but no formal detection logic or relationship context.
Platforms, tactics, official detection, and relationships were not supplied. Any prioritization of specific groups, thresholds, suspicious patterns, or business impact requires local environment context, identity architecture, logging configuration, and administrative workflow knowledge.
Group Metadata
Group metadata includes attributes like name, permissions, purpose, and associated user accounts or roles, which adversaries may exploit for privilege escalation. Examples:
- Active Directory: `Get-ADGroup -Identity "Domain Admins" -Properties Members, Description` - Azure AD: `Get-AzureADGroup -ObjectId
*Data Collection Measures:*
- Cloud Logging: - AWS CloudTrail for IAM group-related activities. - Azure AD Sign-In/Audit logs for metadata changes. - Google Admin Activity logs for API calls. - Directory Logging: Log metadata access (e.g., Windows Event ID 4662). - API Monitoring: Log API calls to modify group metadata (e.g., Microsoft Graph API). - SIEM Integration: Centralize group metadata logs for 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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 2.0 | Current bundle | 1bc159a78413… |
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 DC0105Open 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.