Windows DACL or ownership seized with a built-in permissions tool

1title: Windows DACL or ownership seized with a built-in permissions tool2id: bd80c2d3-662d-4202-bc6d-3b562611b2283status: experimental4description: |5  AN1177 describes a five-stage chain — a permissions utility launches, its6  command line reveals intent, a 4670 DACL change follows, a 4663 access7  succeeds, and persistence follows that. Only the first two stages survive the8  Sigma subset this corpus models: the analytic's own TemporalCorrelationWindow9  knob asks for a 300-second join across three event ids, and lib/sigma has no10  aggregation, no timeframe and no near, so the correlation is simply absent11  here and a match means one command ran, not that any access actually changed12  hands. The rule therefore takes the process-creation leg and gates it twice —13  the tool must be a DACL editor and the command line must carry an14  access-changing switch — because those binaries are also the standard way to15  *read* an ACL, and an unqualified `icacls C:\path` is a query, not a16  modification. The two tool families need separate gates because their switch17  vocabularies do not overlap: icacls takes /grant, /deny, /setowner and18  /inheritance:r, while the older cacls and xcacls spell the same operations19  /g, /r, /p and /d, so one switch list checked against both would leave the20  legacy binaries permanently unmatched. attrib.exe, which the analytic also21  names, is deliberately out of scope: it sets file attributes rather than a22  DACL, and hiding a file with attrib +h is T1564.001.23  takeown.exe gets its own selection24  with no argument gate: it has no read-only mode, so every invocation is an25  ownership seizure. A third selection covers the .NET/PowerShell equivalents26  the analytic names, matched on the command line of any process, which catches27  only one-liners — an ACL rewritten inside a .ps1 body or by a compiled binary28  calling SetSecurityInfo directly produces no process-creation record at all29  and is invisible here. Two deployment caveats. The brief maps this leg to30  Security EventID 4688, so the rule is written in the Sysmon-shaped31  `process_creation` vocabulary (Image, CommandLine) that Sigma backends map32  onto NewProcessName and CommandLine for 4688; if 4688 is the feed, *Audit33  Process Creation* must be enabled AND the separate *Include command line in34  process creation events* policy must be on, or every CommandLine term below is35  blind and the rule returns zero rows while looking healthy. MITRE's36  SuspiciousCommandLinePatterns and SensitivePathWhitelist knobs name where the37  tuning goes; the switch list and the tool list below were assembled here, not38  taken from MITRE.39  UNVERIFIED — derived from MITRE ATT&CK DET0418 and never executed against logs.40references:41  - https://attack.mitre.org/techniques/T1222/00142  - https://attack.mitre.org/detectionstrategies/DET041843author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)44date: 2026-08-1645tags:46  - attack.defense-evasion47  - attack.t1222.00148logsource:49  category: process_creation50  product: windows51detection:52  selection_icacls_tool:53    Image|endswith: '\icacls.exe'54  selection_icacls_switch:55    CommandLine|contains:56      - '/grant'57      - '/deny'58      - '/remove'59      - '/setowner'60      - '/inheritance:r'61      - '/reset'62      - '/setintegritylevel'63  selection_legacy_tool:64    Image|endswith:65      - '\cacls.exe'66      - '\xcacls.exe'67  selection_legacy_switch:68    CommandLine|contains:69      - ' /g '70      - ' /r '71      - ' /p '72      - ' /d '73  selection_takeown:74    Image|endswith: '\takeown.exe'75  selection_managed_acl:76    CommandLine|contains:77      - 'Set-Acl'78      - 'SetAccessRule'79      - 'AddAccessRule'80      - 'SetAccessRuleProtection'81      - 'SetOwner'82  condition: (selection_icacls_tool and selection_icacls_switch) or (selection_legacy_tool and selection_legacy_switch) or selection_takeown or selection_managed_acl83falsepositives:84  - "Application installers and MSI custom actions. A large share of line-of-business software, driver packages and game launchers run icacls /grant against their own Program Files subdirectory, log folder or ProgramData store during setup and again on every version upgrade, and many run icacls /reset or /inheritance:r first. On a fleet with active patching this is the highest-volume match by a wide margin and it is why this rule is scored medium rather than high."85  - "Helpdesk and migration remediation. Recovering a user profile, a departed employee's home directory or a moved file share is routinely done as takeown /f /r /d y followed by icacls /grant, which is exactly the two-command sequence this rule is shaped to catch, run by an administrator with a ticket number."86  - "Build agents and container image builds. CI workers and Dockerfile RUN steps call icacls /grant or /reset on a workspace, a NuGet cache or an IIS content directory on every job, so a busy pipeline produces the same event hundreds of times a day under a service account."87  - "Windows servicing and OEM provisioning scripts. SetupComplete.cmd, sysprep specialise-pass scripts and some cumulative-update cleanup routines invoke takeown and icacls under SYSTEM during boot, which trips the unconditional takeown selection on every freshly imaged host."88level: medium