Security

Event ID 4670: Object permissions changed

Permissions on an object were changedSecurity event 4670 records a change to an object's permissions (DACL or owner), with old and new security descriptors in SDDL and the process responsible.

4670

Event ID: 4670
Channel: Security
Provider: Microsoft-Windows-Security-Auditing
Log file: Security.evtx
Category: Object access
Default logging: Needs configuration

What event 4670 means

Event 4670 is written when the permissions of a file, folder, registry key or security token object change. It carries both the previous (OldSd) and new (NewSd) security descriptors as SDDL strings, so the exact change can be reconstructed: which ACE was added or removed, and whether the owner moved.

For files and registry keys it depends on the object's SACL: file objects need Change Permissions and/or Take Ownership audited, registry keys need Write DAC and/or Write Owner. SACL changes are not covered here; they produce 4907.

Permission changes are a quiet but important signal: attackers grant themselves access to protected data or binaries, and ransomware or cleanup scripts sometimes reset ACLs before acting.

When it is logged

Audit policy / configuration

Advanced Audit Policy Configuration > Object Access > Audit File System or Audit Registry (Success) with a SACL auditing permission or ownership changes; token object changes fall under Policy Change > Audit Authorization Policy Change or Audit Authentication Policy Change.

Microsoft lists four subcategories that can generate 4670. Token-related records can be frequent and are rarely interesting; focus on file and registry objects.

Key fields

Field	What it tells you
SubjectUserName	Account that changed the permissions.
SubjectLogonId	Logon session of that account.
ObjectServer	Subsystem, normally `Security`.
ObjectType	`File`, `Key` or `Token`, for example.
ObjectName	Path of the file, folder or registry key whose permissions changed.
HandleId	Handle used for the change.
OldSd	Previous security descriptor in SDDL (owner `O:`, group `G:`, DACL `D:`).
NewSd	New security descriptor in SDDL. Compare it with `OldSd`; a new `(A;;FA;;;WD)` style ACE granting Everyone (`WD`) full access is a typical red flag.
ProcessName	Process that made the change, e.g. `icacls.exe`, `explorer.exe` or `powershell.exe`.
ProcessId	Hexadecimal PID of that process.

Common benign sources

Administrators adjusting folder permissions through Explorer or icacls.
Installers and Windows servicing setting ACLs on program and system files.
Applications creating per-user folders and setting their own permissions.

What attackers do that produces it

Granting a controlled account full control on sensitive files, shares or service binaries.
Taking ownership of system files or registry keys to replace or modify them.
Opening permissions on a folder (e.g. Everyone full control) to stage or share data.

Investigation tips

Diff OldSd and NewSd; identify the SIDs gained or lost and the rights they carry.
Check ProcessName and pivot SubjectLogonId to 4688 to get the exact command line.
Look for 4663 records on the same object shortly after, showing use of the new access.

MITRE ATT&CK techniques

Technique	Tactics
T1222.001 File and Directory Permissions Modification: Windows Permissions	Defense Impairment

MITRE ATT&CK v19.2. Technique and tactic names are MITRE's.

Sigma rules for this event

No bundled SigmaHQ rule targets this event ID specifically. Rules on related events may still cover the activity.

Run these rules on your logs

Drop a .evtx file into the viewer: all 2,395 bundled SigmaHQ rules run locally in your browser. Nothing is uploaded.

Open the viewer Filter a log on event 4670

Sources and further reading

Microsoft Learn — 4670(S): Permissions on an object were changed