Account added to a privileged local or domain group

1title: Account added to a privileged local or domain group2id: cb61e4d7-bf63-4bdf-b6ae-cc166cd01bc03status: experimental4description: |5  AN0865 is the directory's own record of this technique: the six group6  membership events that Security logging emits when a principal is added to or7  removed from a security-enabled group. This rule keeps the three additions —8  4728 for a global group, 4732 for a local or builtin group, 4756 for a9  universal group — and drops the matching removals 4729, 4733 and 4757, because10  removing a member is the cleanup half rather than the persistence, and carrying11  it would roughly double the volume for events that describe the opposite act.12  MITRE's `TargetGroup` knob is what the second selection implements, populated13  here with well-known relative identifiers rather than with group names: the14  event's `TargetSid` is the group, and matching on the RID suffix (-512 Domain15  Admins, -519 Enterprise Admins, -518 Schema Admins, -520 Group Policy Creator16  Owners, -544 the builtin Administrators, -548/-549/-550/-551 the operator17  groups, -555 Remote Desktop Users, -580 Remote Management Users) survives a18  localised Windows install and a renamed group, both of which defeat a list of19  names. The technique description calls out Remote Desktop Users and the20  administrators group specifically, and the operator groups are included because21  each is a documented route back to domain admin. The RID suffixes cannot22  collide with a custom group: RIDs for new objects begin at 1000, so a value23  such as 2544 does not end in `-544`.24  Limits and prerequisite. What this cannot see is the group that matters most in25  many estates — a delegated helpdesk or application group with a site-specific26  RID, or DnsAdmins, which has no well-known RID. Adding those RIDs or switching27  the selection to `TargetUserName` is the first tuning step. MITRE's `TimeWindow`28  and `UserContext` knobs — fire only outside a change window, or only when the29  modifying account is not a known provisioning identity — are a schedule and a30  per-identity baseline, and lib/sigma models neither, so nothing here encodes31  them; the event does carry `SubjectUserName` and `MemberName`, which is where32  that filtering belongs once the site knows its own provisioning accounts. The33  Linux and macOS arms AN0866 and AN0867 are not attempted here: they are a34  different log source with a different vocabulary and belong in their own rule.35  Prerequisite: these events require *Audit Security Group Management* (Success),36  which unlike Process Creation auditing is on by default on current Windows37  client and server builds, so the events are usually being written. The gap is38  collection, not policy: 4728 and 4756 are written on the domain controller that39  serviced the change, so all DCs must be forwarded or the change is simply40  missed, and 4732 for a local Administrators addition — the single most common41  form of this technique — is written only in the Security log of the member42  server or workstation it happened on, which many estates do not ship at all.43  Where a hardening baseline or a legacy policy has turned the subcategory off,44  this returns zero rows, and zero rows there reads as quiet when it means blind;45  confirm with `auditpol /get /subcategory:"Security Group Management"` rather46  than assuming either way.47  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0310, not hand-written and not tested by its author. Any lab result is on this rule's own page.48references:49  - https://attack.mitre.org/techniques/T1098/00750  - https://attack.mitre.org/detectionstrategies/DET031051author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)52date: 2026-08-1753tags:54  - attack.persistence55  - attack.privilege-escalation56  - attack.t1098.00757logsource:58  product: windows59  service: security60detection:61  selection_member_added:62    EventID:63      - 472864      - 473265      - 475666  selection_privileged_group:67    TargetSid|endswith:68      - '-512'69      - '-518'70      - '-519'71      - '-520'72      - '-544'73      - '-548'74      - '-549'75      - '-550'76      - '-551'77      - '-555'78      - '-580'79  condition: selection_member_added and selection_privileged_group80falsepositives:81  - "Identity provisioning and access-request automation. Joiner-mover-leaver workflows, IGA connectors and self-service access tools add accounts to Remote Desktop Users and to delegated administrator groups continuously and in bulk, so in any organisation with automated provisioning this is by far the highest-volume match and the reason the rule is medium rather than high."82  - "Server and application installers that grant their service account rights during setup. Backup, monitoring and database products add the account they run as to the local Administrators or Backup Operators group as a documented install step, producing one match per host during a rollout."83  - "Endpoint build and imaging. Domain join scripts, golden-image provisioning and lab rebuilds add the support or engineering group to local Administrators on every machine they touch, so a hardware refresh or an OS upgrade wave emits a burst of 4732 events with nobody at the keyboard."84  - "Routine directory administration inside a change window. Adding a new administrator to Domain Admins or nesting a role group under an operator group is ordinary work for the identity team, and the event is indistinguishable from the adversary's apart from the account that performed it and the ticket behind it."85level: medium