DET0179: Behavioral Detection of Permission Groups Discovery
This detection strategy matters because permission and group discovery is often how an intruder decides where to move next: which identities, groups, or ro...
Analyst context for executives and security teams
This detection strategy matters because permission and group discovery is often how an intruder decides where to move next: which identities, groups, or roles may unlock higher-value systems. Even though the ATT&CK detection object does not provide detailed detection logic, its relationship to T1069 makes it a useful prompt for leaders to verify whether identity, cloud, Linux, and container environments produce enough evidence to recognize suspicious permission enumeration before it turns into privilege abuse or broader compromise.
Executive priority
Treat this as an identity and cloud visibility control question, not just a SOC rule. Leaders should ask whether teams can prove who queried group membership and permission settings, from where, and whether the activity was normal for that user or workload. This supports incident scoping, audit evidence for privileged access oversight, and prioritization of logging across Identity Provider, IaaS, Linux, and container environments associated with the related ATT&CK technique.
Technical view
The supplied detection strategy has no official detection text or platform list, but it detects T1069 Permission Groups Discovery, which is associated with discovery activity across Containers, IaaS, Identity Provider, and Linux. SOC and detection teams should validate behavioral analytics around enumeration of groups, memberships, roles, and elevated-permission principals. Useful logic will usually depend on baselining normal administrative discovery, identifying unusual principals or workloads performing broad queries, and correlating permission enumeration with authentication context, source host, cloud account/project, container namespace, or recent access changes.
Likely telemetry
- Identity provider audit logs for group, role, membership, and directory lookups
- IaaS/cloud control-plane audit logs showing permission, role, group, or policy enumeration
- Linux process, command, authentication, and audit logs where available
- Container platform audit logs for service account, role, binding, namespace, or permission queries
- Privileged access management or identity governance records that distinguish approved administrative activity from unusual discovery
Detection direction
- Confirm that relevant identity, cloud, Linux, and container control-plane logs are collected with actor, source, target, timestamp, and result fields sufficient for investigation.
- Baseline expected administrative and automation-driven permission discovery to reduce false positives from legitimate inventory, IAM governance, compliance scans, and help desk workflows.
- Look for unusual breadth, frequency, timing, source location, or first-seen use of group and permission enumeration by users, service accounts, or workloads.
- Correlate discovery with nearby events such as new logins, role changes, access failures, privilege escalation attempts, or lateral movement indicators where telemetry exists.
- Document blind spots explicitly, especially environments where read-only directory or permission queries are not logged or where logs lack the requesting identity.
Mitigation priorities
- Prioritize logging and retention for identity provider, cloud control-plane, Linux, and container authorization events tied to group and permission visibility.
- Limit unnecessary visibility into sensitive group membership and privileged role assignments using least privilege where supported by the local platform.
- Separate and monitor administrative, automation, and service account activity so expected discovery can be distinguished from anomalous behavior.
- Maintain current inventories of privileged groups, roles, and service accounts to support faster incident response scoping when discovery is observed.
- Use detections as compliance evidence only after validating telemetry completeness, tuning assumptions, and investigation runbooks in the local environment.
Analyst notes and limits
The decision value of DET0179 is in validating behavioral coverage for permission-group enumeration associated with T1069. Because the object lacks official detection guidance, teams should treat this as a coverage assessment and detection-engineering starting point rather than a complete analytic.
The official detection strategy description, detection text, tactics, and platforms are not provided. Platform and tactic context comes from the supplied relationship to T1069 only. Local command names, API calls, log schemas, normal administrative patterns, and control availability must be validated in the customer environment.
Behavioral Detection of Permission Groups Discovery
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 | T1069 | Permission Groups Discovery | This object detects Permission Groups Discovery. |
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 | 9c14ca6453c0… |
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 DET0179Open 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.