How T1069 permission groups discovery shows up in your environment
T1069 Permission groups discovery is the adversary activity of listing the groups, roles and permission sets that exist in an environment so they can see who holds which privileges. It matters because it is often the first quiet step after an account is compromised: the attacker is not yet changing anything, only learning which identities are worth targeting next. In MITRE ATT&CK, this technique sits under the Discovery tactic (TA0007), whose stated purpose is that the adversary is trying to figure out your environment. T1069 has three sub-techniques, one each for local groups, domain groups and cloud groups, and each leaves traces on different platforms: hosts and directory services for the first two, and identity providers and cloud control planes for the third.
For a SOC lead, the practical question is where the behavior appears. On Linux and other host platforms, it shows up as process creation and command execution events for standard account and group inspection utilities, often run from an account that has no business reason to query privileged groups. In directory and identity environments, the same intent appears as read activity against group objects and membership data, which is why identity provider audit logs and directory query logs matter as much as endpoint telemetry. In cloud environments, the signal is enumeration of roles and policies through the provider's API, usually from a session that has never made that call before. Confirm with your identity and platform teams which of these sources you actually collect today, because a sub-technique you cannot see is a sub-technique you cannot detect.
The decision to make now is which baseline to measure against. Ask each platform owner to list the accounts that normally read group membership (service accounts for provisioning, administrators for access reviews) and to confirm whether those reads are logged with enough detail to attribute them to a user and source host. Those lists become the allowlist that separates routine administration from discovery. Detection logic for each sub-technique should be mapped to the ATT&CK version you target, since ATT&CK releases can rename or deprecate techniques, and to the data components named in the current detection strategies.
Which telemetry reveals permission group enumeration
This table maps the data sources ATT&CK links to T1069 and its sub-techniques to the signal each one exposes, the platforms where it applies and the open-source collector that gathers it. Read each row as a starting point: confirm sub-technique and platform coverage against the ATT&CK version you target, since releases can change mappings. The main takeaway is that process and command logging cover most hosts, while identity and cloud enumeration logs are needed for directory and SaaS group queries.
| Telemetry source | Signal to look for | Platform and collector |
|---|---|---|
| Process Creation (DC0032) | Launch of group-listing utilities or directory query tools, with the parent process and user context recorded | Linux and Windows hosts; Wazuh agent or Sysmon for Linux, with auditd rules for execve events |
| Command Execution (DC0064) | Command line arguments that request group membership lists or group details, captured as full text | Linux and container hosts; auditd or Wazuh command monitoring, Velociraptor artifacts for on-demand collection |
| File Access (DC0055) | Reads of local group definition files, such as the group database on Linux, by processes that do not normally touch them | Linux hosts; auditd file watches or Wazuh file integrity monitoring on the group file path |
| Identity provider audit logs | Queries for group objects or membership, especially bulk or non-administrative enumeration by a single account | Directory services and identity providers; ingest vendor audit logs into Wazuh or Security Onion, confirm event names with the provider |
| Cloud service enumeration logs | List or describe calls against IAM groups, roles or policy bindings from an unexpected identity or source address | IaaS and SaaS control planes; collect cloud audit trails with a log forwarder, confirm which API events the provider records |
| Container and orchestrator audit logs | Requests that list role bindings, service accounts or group subjects inside a cluster | Containers; Kubernetes audit policy shipped to Wazuh or Security Onion, confirm the audit level per resource |
| Network Traffic Content (DC0085) | Directory protocol queries that enumerate group objects, seen from hosts outside the admin baseline | Enterprise networks; Zeek logs for LDAP and Kerberos activity, Suricata rules for directory query patterns |
Detection ideas for permission group enumeration
T1069 Permission Groups Discovery is hard to separate from normal administration, because the same group queries come from help desk tools, provisioning jobs and monitoring agents. The approaches below pair a behavioral signal with a baseline, so analysts can tune each rule against known good callers before alerting. Each rule can be written in Sigma and run in Wazuh or Security Onion once the telemetry it depends on is confirmed in your environment.
Group queries by non-administrative accounts
Alert when an account with no administrative role, or no history of directory administration, runs commands that list group membership on a Linux host or queries group objects in a directory. The logic relies on Process Creation and Command Execution telemetry, plus the account's role from your identity source. Tune first against the accounts that run inventory, reporting and onboarding scripts, and exclude named service accounts only after reviewing their scope. Confirm which hosts forward command-line arguments before relying on this rule.
Bursts of group queries per session
Count distinct group lookups within one logon session or process tree over a short window, and alert when the count rises well above the host's own baseline. A single lookup is normal, while a rapid series of membership checks across many groups is a stronger discovery pattern. Set the window and threshold from observed administrative activity, not from a fixed number. Common false positives include login scripts, endpoint management agents and vulnerability scanners that enumerate groups on every run.
Enumeration from container hosts and pods
Watch for group file reads and group listing commands run inside containers or from pods that have no business reading identity data. The signal comes from Process Creation inside container workloads and from audit events for the pod's service account. Compare against the pods that legitimately run sidecars, backup agents or configuration tools. Ask your platform team which images are expected to read group data, and document that list as the allow baseline.
Identity provider reads by unusual principals
Alert when a principal that is not an identity administrator, provisioning connector or known reporting job reads group or role objects through the identity provider's administrative API. The logic compares the principal, client application and source address against a known caller list. Expect false positives from SCIM connectors, access review tools, HR synchronization and backup jobs that export directory state. Confirm which audit events your identity provider writes for group reads, because not every product logs read operations by default.
How to validate that the T1069 detection fires
This sequence proves that the T1069 detections fire on the right telemetry, at an acceptable speed and noise level, before anyone relies on them. It produces a documented validation record tied to a named ATT&CK version, with tuning decisions and a repeat run that confirms the changes held.
Agree scope and written authorization
The detection owner, the platform owner and the cyber range lead agree in writing which test host, test identity provider tenant and container cluster are in scope, which accounts may be used, and when the exercise runs. Legal or the system owner signs off so that benign enumeration activity on production-adjacent assets is never mistaken for a live intrusion. The step is done when the signed scope names every asset, identity and time window, and the emergency contacts are listed.
Map the emulation plan to the ATT&CK version
The team selects an approved emulation plan that covers the three T1069 sub-techniques for the platforms in scope: local, domain and cloud group enumeration. Each step is recorded against the ATT&CK version the detections target, so later changes to technique names or mappings do not break the comparison. The output is a plan table listing each step, its platform, the expected data component and the alert rule expected to fire, with no commands copied into the record.
Establish a telemetry baseline before the run
Before any emulation, the team confirms that process creation and command execution events from the test host, identity provider audit logs and container audit logs arrive in Wazuh, Security Onion or the chosen SIEM with the expected fields. They also record normal enumeration activity by administrators and service accounts over the same window so that expected noise is known. The step closes when a sample of each log source is reviewed and the baseline noise list is approved.
Run benign enumeration on test assets
A named operator runs the approved benign group enumeration steps on the test host, against the test identity provider tenant and in the test cluster, following the emulation plan in order and logging the start time of each step. The operator does not deviate from the plan or add unapproved activity. The step is complete when every planned step has a recorded timestamp and the operator confirms which steps were run.
Confirm which alerts fire and when
The detection owner checks each expected alert against the operator log and records whether it fired, which rule or analytic produced it, the matching event fields and the time to alert measured from the operator's timestamp. Any step that produced no alert, or an alert on a different data source, is logged as a gap. The output is a results table with one row per planned step showing fired or missed, the time to alert and the source event.
Measure false positives against the baseline
The team compares alerts raised during the run against the baseline from the earlier step and against the operator log to separate expected alerts from unrelated firings caused by administrators or scheduled jobs. The false positive rate is calculated over the window and recorded with the number of alerts reviewed, so the figure can be repeated later. The step is done when every alert in the window is labeled as expected, unrelated or unexplained, with a named reviewer.
Tune rules and re-run the exercise
Rules that missed steps or produced unrelated alerts are adjusted through the normal change process, such as narrowing a condition to an approved administrative account or adding a missing log source, and each change is linked to the result that prompted it. The same emulation plan is then run again on the same assets. The step closes when the second run shows the intended alerts firing, the false positive count has moved in the expected direction, and the before and after results are filed together.
Preventive controls that reduce permission group discovery
Permission group discovery succeeds when an attacker can read group membership and privilege structure without friction. The four ATT&CK mitigations below shape what that enumeration reveals, how much of it is allowed, and how quickly it is noticed. Each one needs to be confirmed against the client's own directory, Linux hosts and network design rather than assumed from the mitigation name.
Constrain account management rights
User Account Management (M1018) limits who can create, modify or query accounts and group memberships. For T1069, the question is whether ordinary user, service and CI identities can list privileged groups in the identity provider, on Linux hosts or in container clusters. Review which roles can read group membership beyond what their job requires, separate administrative accounts from daily use, and confirm that service accounts used for directory lookups hold read-only scopes. Ask the platform owner to show the effective permissions for a sample of non-admin identities.
Tighten operating system configuration
Operating System Configuration (M1028) covers the host settings that decide what a local user can read. On Linux, the group database and the commands that print it are readable by default, so the practical control is to review file permissions on account databases, restrict access to directory integration tools, and limit which accounts can run privileged helpers. Confirm the baseline with your hardening standard and check that changes are applied through configuration management so drift is visible. Verify results on a sample host rather than relying on the policy document alone.
Enable and retain audit records
Audit (M1047) does not stop enumeration, but it determines whether group queries leave evidence. For T1069 the useful records are process creation events for directory and group lookup utilities, directory service query logs where the identity provider offers them, and access events for group objects. Confirm which of these your environment generates, where they are forwarded, and how long they are kept. Without them, the Process Creation and Command Execution detections described in this guide have nothing to match against.
Segment management and directory paths
Network Segmentation (M1030) reduces where a discovery query can reach. Group and directory queries travel to domain controllers, identity endpoints and cluster API servers, so restricting which subnets, namespaces and workloads can reach those services narrows what an attacker on a foothold can enumerate. Confirm that workloads without a directory need cannot reach directory ports, that build and management networks are separated from user networks, and that container clusters limit API access by network policy. Test the segmentation from a non-privileged foothold position in a range, not only in design documents.
Triage steps when a permission group discovery alert fires
Start by deciding whether the alert describes a person, a service or an automation job, because that choice determines every later step. Pull the source account and its active session from the identity provider and the host audit trail: the user or service principal, the originating host or IP address, the authentication method, and the session start time. Then compare the activity against your change calendar, approved administrative runbooks and the owner list for service accounts. Ask the account owner or the on-call administrator to confirm, in writing and with a timestamp, whether they launched the queries. A confirmed match closes the alert with a note; an unconfirmed match stays open and moves to the next step.
Next, pivot to authentication and process history for the same identity over the surrounding window. In your Wazuh or Security Onion case, look for the Process Creation records that preceded the enumeration, the parent process, the working directory and any new logon sessions or privilege changes for that account. Confirm which group-listing commands ran and on which hosts, then widen the search to every host and identity that account touched in the same period, including cloud consoles and directory queries. Record what the enumeration returned to the attacker, if you can establish it, because a list of privileged groups often precedes a targeted credential or role change. Treat the scope as unknown until you have checked it.
Choose containment based on the evidence, not on the alert severity alone. Revoking the active session and forcing re-authentication is usually the least disruptive first move when the account is a person and the activity is unexplained. Locking the account is justified when the owner cannot be reached and the pivot shows further suspicious use, but a lock on a shared service account can stop production jobs, so confirm the dependency first. Hand the case to incident response with the account name, the time window, the affected hosts, the containment actions taken and their exact times, and the questions still open. Preserve the raw audit logs, identity provider sign-in records, host process telemetry, relevant directory exports and the alert itself with hashes before any rotation or cleanup, and keep a record of who accessed them.
Rehearsing T1069 detection in a private cyber range
On a Linux host, T1069 activity usually shows up as local group and membership listings run from an ordinary user session. In a private range, build a small set of hosts with realistic group structures, forward process creation and command execution telemetry to Wazuh or a similar collector, and confirm that audit records include the executing user, parent process and working directory. Schedule a benign inject where a designated test account lists local group membership in an approved window, so the team can see the exact event shape they will need to match.
- Range setup: Two or three hosts with local and privileged groups, auditing enabled for process execution, and a log path confirmed with the platform owner.
- Benign inject: A scheduled, labeled session run by the test account that performs routine group queries, documented with a start time and an expected event count.
- Good detection: A rule alert fires within the agreed window, enriched with the user, host, parent process and the group names queried.
- Good response: The analyst confirms whether the account is expected for that role, checks recent logons and escalates only on mismatch.
- Check: Confirm the rule logic against the ATT&CK version you target, since detection strategies and data components can change between releases.
On a container platform, group and account queries can run inside a pod or from a node-level shell, and the telemetry you need may come from the container runtime, the orchestrator audit log or host process records. In a private range, deploy a non-production cluster that mirrors your namespace and role layout, and confirm which events reach your collector. Without that check, a query issued from inside a container may leave no trace at the level your rules expect.
- Range setup: A non-production cluster with at least two namespaces, service accounts with differing permissions, and audit logging turned on at the API server.
- Benign inject: A scheduled exec or query by a designated service account in one namespace, with the expected identities and times recorded.
- Good detection: An alert correlates a container process event with an orchestrator audit entry, and names the namespace, pod and service account.
- Good response: The responder checks whether the service account role allows the query, reviews role bindings and isolates the workload if the activity is unexplained.
- Check: Confirm with your platform team exactly which audit levels and runtime events your distribution produces, because coverage varies by configuration.
Identity providers record T1069 activity as directory and group read operations tied to a named administrator or application. The detection problem here is less about process telemetry and more about separating legitimate directory reads from enumeration by an account that should not be reading group structures. In a private range, connect a test tenant or self-hosted directory to your collector, then rehearse both expected administrative reads and out-of-role reads.
- Range setup: A test directory with sample groups, a read-only reporting account, a helpdesk role and an administrator role, all forwarded to the log platform.
- Benign inject: A scheduled group listing by the reporting account and a helpdesk account, performed in the agreed window and logged with the ticket reference.
- Good detection: An alert fires on a directory group read by an account outside its role baseline, and enrichment adds the user, source address, application and recent sign-in history.
- Good response: The analyst checks the ticket queue, confirms the account owner, reviews sign-in risk and requests a session review or credential reset if the read is unexplained.
- Check: Confirm which directory events your identity platform exposes and at what detail, and whether group read operations are logged by default.
In a cloud IaaS account, permission group discovery appears as reads of identity and access management objects, such as group, policy and role listings, made through the provider's control plane. A private range should use a sandbox account or project that is separated from production, with the provider's control-plane logging enabled and routed to your collector. Rehearse the detection with an approved benign inject so the team learns the event names and fields before relying on them.
- Range setup: A sandbox account with IAM groups and roles of different privilege, control-plane logging enabled, and a separate log bucket or stream for the range.
- Benign inject: A scheduled listing of groups and policies by a named automation role, recorded with the expected event count and time.
- Good detection: An alert fires on an identity listing from a principal without a recorded need, enriched with the principal, source network, user agent and account ID.
- Good response: The responder reviews the principal's recent activity, confirms whether the role should hold that permission and restricts it if not.
- Check: Confirm with the provider which control-plane events are logged by default and which require an explicit setting, since retention and fields differ by service.
Questions SOC leads ask about T1069 detection
How do I separate administrator tooling from attacker enumeration for T1069?
Start by building a documented baseline of which accounts, hosts and parent processes legitimately query group membership, such as directory management consoles, configuration management agents and scheduled access reviews. Alert on group enumeration from accounts or hosts outside that baseline, and on unusual volume or timing even when the account is expected. Process Creation and Command Execution telemetry (ATT&CK data components DC0032 and DC0064) give you the parent process, user context and command line needed to make that split. Review the baseline with platform owners after each change window so tuning reflects what administrators actually run.
How do I handle identity provider logs with short retention?
Export directory audit and sign-in events to your own SIEM or log store on a schedule, so detection and investigation do not depend on the provider's retention window. Confirm the retention period and export options for your specific identity platform in its current documentation or with the vendor, because these settings differ by edition and tenant configuration. Prioritize events that show group membership reads, group changes and privileged role queries, and keep those fields in a normalized schema so the same Sigma logic runs across hosts and cloud identity sources. Test the export path during a cyber range exercise to confirm events arrive within the timeframe your alerting requires.
Do container hosts need separate T1069 detection rules?
In most environments, yes, because enumeration from inside a container can look different from the same action on a virtual machine. Container host Process Creation logs, container runtime audit events and orchestration API audit records should each feed rules, so you can see whether a query came from a workload, a node or an operator session. Confirm that your collection agents capture the container identifiers and namespace fields you need, since default configurations often omit them. Map each rule to the platform it covers so gaps are visible when your environment changes.
How should Sigma rules be versioned against ATT&CK releases?
Record the ATT&CK version each rule targets in its metadata, and review every rule when MITRE publishes a new release, because releases can rename, deprecate or revoke techniques and update detection strategies. ATT&CK v18 was released on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, so a rule written for one release needs a documented review before you rely on it under another. Keep the rule's technique and sub-technique tags, its data source references and its test notes in the same repository, and tag each change with the version it was checked against. The ATT&CK updates page lists what changed in each release.
How do I measure detection coverage for permission groups discovery?
Measure coverage by platform and sub-technique rather than with a single headline number, because a rule that works on Linux hosts says nothing about your identity provider. For each platform the technique covers, record whether the required telemetry is collected, whether a rule exists, and when the rule last passed a replay test in the cyber range. Gaps in telemetry matter more than gaps in rules, so start with collection checks. Report results against the ATT&CK version your mappings target, and avoid presenting coverage as a guarantee that an attacker would be caught.
Which mitigations reduce the number of T1069 alerts?
The mitigations ATT&CK most often maps to this family of Discovery techniques are User Account Management (M1018), Operating System Configuration (M1028) and Audit (M1047). Tighter account management limits which identities can query group membership in the first place, which lowers the volume of ambiguous events your analysts must review. Operating system configuration and audit policy determine whether the events you need are generated and retained at all. Confirm how each mitigation applies to your identity provider, container platform and Linux estate, because the implementation details differ by platform.
How DeployOpen builds T1069 detections and range exercises
DeployOpen starts every T1069 engagement with a written scope that names the platforms where permission groups matter to you, such as Linux hosts, container clusters, IaaS control planes and the identity provider, along with the telemetry you can actually collect from each. The scope also records the ATT&CK version the detection logic targets. This matters because ATT&CK v18 replaced detections in technique pages with detection strategies and analytics, and releases can rename or deprecate content, so a detection written against an unnamed version is hard to audit later. Before any rule is written, the client confirms which Process Creation, Command Execution and identity audit sources are available, who owns each one, and how long they are retained. Those answers determine whether the T1069 coverage can be built at all.
From that scope, DeployOpen maps each sub-technique to specific observable events and writes the detection logic in plain words first, then as Sigma rules or Wazuh decoders and rules that run in the client's own environment. Collectors and rules are deployed inside the client's cloud accounts, data centers or air-gapped networks, and the configuration is kept under version control so changes to group-enumeration logic are reviewed like any other code. Where a platform does not expose a needed field, the engagement records that gap and the compensating control instead of assuming coverage. Tuning is planned against the client's administrators, who run legitimate group queries as part of normal operations, so the team knows which baseline activity to expect.
Detections are then validated in a private cyber range that mirrors the client's platforms, where DeployOpen runs controlled permission group discovery exercises and records which alerts fire, how quickly, and which sub-techniques are missed. Results go into a handover package with the detection logic, data source mapping, known gaps, response steps for the security operations team and a rehearsal plan for repeating the exercise after upgrades. DeployOpen prepares these systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so the handover is designed to give them clear, reproducible evidence.
