DC0099: Group Enumeration
Extracting group lists from identity systems identifies permissions, roles, or configurations. Adversaries may exploit high-privilege groups or misconfigurations. Examples:
- AWS CLI: `aws iam list-groups` - PowerShell: `Get-ADGroup -Filter *` - (Saas) Google Workspace: Admin SDK Directory API - Azure: `Get-AzureADGroup` - Microsoft 365: Graph API `GET https://graph.microsoft.com/v1.0/groups`
*Data Collection Measures:*
- Cloud Logging: Enable AWS CloudTrail, Azure Activity Logs, and Google Workspace Admin Logs for group-related actions. - Directory Monitoring: Track logs like AD Event ID 4662 (object operations). - API Monitoring: Log API activity like AWS IAM queries. - SaaS Monitoring: Use platform logs (e.g., Office 365 Unified Audit Logs). - SIEM Integration: Centralize group query tracking.
Analyst context for executives and security teams
Group enumeration is the discovery of identity groups, roles, and permission structures. For leaders, this matters because group membership often defines who can administer systems, access sensitive data, or change cloud and SaaS configurations. Even without a supplied ATT&CK tactic or detection analytic, the data component is important because visibility into group-query activity can help confirm whether identity reconnaissance is observable across Active Directory, cloud IAM, and SaaS administration planes.
Executive priority
Prioritize this as an identity and cloud security visibility question: can the organization prove who is querying group and role information across directory, cloud, and SaaS platforms? The business value is in reducing blind spots around privilege mapping, supporting incident response scoping, and producing audit-ready evidence that sensitive identity structures are monitored. Security leaders should ask whether high-privilege group discovery is logged centrally and whether those logs are retained long enough to support investigations.
Technical view
SOC and IR teams should validate collection of group-related query activity from identity systems and administration APIs. The official object references AWS IAM group listing, Active Directory group enumeration, Google Workspace Admin SDK Directory API, Azure group queries, and Microsoft Graph group access as examples. Since no official detection logic is provided, teams should focus first on telemetry completeness, then baseline normal administrative behavior, service account behavior, and unusual volume, timing, or source context for group enumeration events.
Likely telemetry
- AWS CloudTrail records for IAM group-related actions
- Azure Activity Logs and Azure identity administration activity
- Google Workspace Admin Logs for Directory API group activity
- Office 365 / Microsoft 365 Unified Audit Logs for group-related activity
- Microsoft Graph API audit evidence for group queries where available
Detection direction
- Validate that group-query activity is logged before building alerts; lack of logs is the primary coverage gap implied by the object.
- Correlate group enumeration with user, service account, source IP/device, application, and administrative role context to separate normal administration from suspicious discovery.
- Tune for unusual breadth or frequency of group queries, unexpected principals, nonstandard source locations, or activity outside normal change/admin windows.
- Review privileged and sensitive group queries with higher priority, especially where group names imply elevated permissions or critical business access.
- Account for false positives from legitimate IAM administration, directory synchronization, inventory tooling, compliance reporting, and help desk workflows.
Mitigation priorities
- Ensure cloud, directory, and SaaS audit logging is enabled for group-related administrative and API activity.
- Centralize identity and group-query logs into a SIEM or comparable monitoring workflow with sufficient retention for incident response.
- Limit who can enumerate or administer sensitive groups using least privilege and role-based access controls where supported by the identity platform.
- Review high-privilege groups and misconfigurations regularly so enumeration of those groups does not expose unnecessary privilege pathways.
- Document normal administrative and automation sources for group queries to support alert tuning and audit evidence.
Analyst notes and limits
This data component is most useful as a coverage validation item. It tells defenders what evidence class should exist when identity group structures are queried, but it does not provide a specific ATT&CK tactic, technique relationship, platform list, or detection analytic. Glexia would treat this as a control-evidence checkpoint for identity monitoring, cloud logging, SaaS audit readiness, and IR scoping.
The supplied object has no tactics, no platforms field, no relationships, and no official detection. The examples and collection measures support discussion of Active Directory, AWS, Azure, Google Workspace, Microsoft 365, and API/SIEM logging, but local implementation details determine what events are actually available and reliable.
Group Enumeration
Extracting group lists from identity systems identifies permissions, roles, or configurations. Adversaries may exploit high-privilege groups or misconfigurations. Examples:
- AWS CLI: `aws iam list-groups` - PowerShell: `Get-ADGroup -Filter *` - (Saas) Google Workspace: Admin SDK Directory API - Azure: `Get-AzureADGroup` - Microsoft 365: Graph API `GET https://graph.microsoft.com/v1.0/groups`
*Data Collection Measures:*
- Cloud Logging: Enable AWS CloudTrail, Azure Activity Logs, and Google Workspace Admin Logs for group-related actions. - Directory Monitoring: Track logs like AD Event ID 4662 (object operations). - API Monitoring: Log API activity like AWS IAM queries. - SaaS Monitoring: Use platform logs (e.g., Office 365 Unified Audit Logs). - SIEM Integration: Centralize group query tracking.
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.1 | Current bundle | 505881fdf5f6… |
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 DC0099Open 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.