Lion Cipher Lab

Detect privileged group changes in Windows logs

• SOC Analyst / Blue Team
• Intermediate
• ~50 min
• Free · no account required

Why it matters

When an attacker or a rogue insider quietly adds an account to Administrators, Domain Admins, Enterprise Admins or Backup Operators, they have just handed themselves the keys to the estate — and Windows writes down exactly what happened. Membership of a privileged group is, in most environments, the single clearest line between an ordinary user and total control, so a change to that membership is one of the highest-signal events a defender can watch. It maps to two of the most common techniques in the whole ATT&CK matrix — T1098 Account Manipulation (modifying permission groups to keep or…

What you'll learn

• explaining why 'who was added to an admin group, and who did it' is one of the highest-fidelity signals in a SOC, and mapping it to MITRE ATT&CK T1098 (Account Manipulation) and T1078 (Valid Accounts)
• confirming the right auditing is on with `auditpol /get /category:*` and ensuring the 'Security Group Management' subcategory logs Success
• generating the telemetry safely on your OWN machine: creating a benign local test user and adding it to the local Administrators group, then watching a 4732 appear
• reading and parsing the event with `Get-WinEvent -FilterHashtable` — pulling out MemberSid (who was added), TargetUserName/TargetSid (which group, e.g. S-1-5-32-544 = local Administrators), and SubjectUserName (who did it)
• knowing the whole family: 4732 (local group), 4728 (global, e.g. Domain Admins), 4756 (universal, e.g. Enterprise Admins), plus companions 4720/4726/4767, and the well-known RIDs 512/519
• writing a portable Sigma rule that fires on 4732/4728/4756 against privileged group SIDs/names, and converting it to Splunk or Elastic with sigma-cli / pySigma
• stating the honest negatives out loud: the identical event fires for legitimate admin work (a lead, not a verdict), nested groups are a blind spot, add-then-remove evades a snapshot, and an attacker can clear the log
• delivering the measured before/after: no event -> the 4732 you generated -> the rule that catches it, plus the baseline-the-actor tuning that makes it usable

Steps in this lab

1. The signal: who joined an admin group, and who put them there
2. Turn on (or confirm) the auditing that records it
3. Measure BEFORE, then generate the event on your own machine
4. Read the event: which group, who was added, who did it
5. Write the detection as a portable Sigma rule
6. The honest negatives: why this is a lead, not a verdict
7. Do it better: how a pro tunes and operationalises this

Open the full interactive lab →