Event ID 4663 spiegato: auditing degli accessi a file e registry con le SACL
Il 4663 è l'audit per-accesso sugli oggetti. Le giuste SACL danno un log di chi tocca cosa — utile per ransomware, exfil e furto di credential store.
L'Event ID 4663 — «An attempt was made to access an object» — si attiva sul canale Security ogni volta che un file, una chiave di registry o un oggetto kernel auditato viene acceduto in un modo che corrisponde alla sua System Access Control List (SACL). A differenza della maggior parte dei record Security, il 4663 non produce nulla da solo — devi configurare la SACL sull'oggetto che ti interessa prima che esistano record 4663. Questo lo rende a costo zero di default e devastantemente efficace una volta tarato.
Se devi auditare una sola cosa col 4663, audita l'accesso ai credential store e agli share di dati ad alto valore. Il rapporto segnale-rumore è tra i migliori dell'intero catalogo di audit.
Dove si attiva
Sempre sull'host proprietario dell'oggetto — il file server per una SACL su file, la workstation per una SACL locale di registry, il DC per una SACL su un oggetto AD. Non c'è un record centrale; se vuoi visibilità a livello di estate su uno share sensibile, devi forwardare il Security dal file server che lo ospita.
Cosa contiene il record
<Data Name="SubjectUserSid">S-1-5-21-...-1107</Data>
<Data Name="SubjectUserName">alice</Data>
<Data Name="SubjectDomainName">CORP</Data>
<Data Name="SubjectLogonId">0x2a4c8</Data>
<Data Name="ObjectServer">Security</Data>
<Data Name="ObjectType">File</Data>
<Data Name="ObjectName">C:\Windows\System32\config\SAM</Data>
<Data Name="HandleId">0x4d0</Data>
<Data Name="AccessList">%%4416 %%4423</Data>
<Data Name="AccessMask">0x80</Data>
<Data Name="ProcessId">0x1d34</Data>
<Data Name="ProcessName">C:\Windows\System32\reg.exe</Data>
<Data Name="ResourceAttributes">-</Data>
I campi:
ObjectType—File,Key(registry),Process,Token,Directory,Section, o qualsiasi classe di oggetto che supporti SACL.ObjectName— il path completo. Per i file è un path Windows; per le chiavi di registry, il path completo sotto\REGISTRY\MACHINE\…(nota: non la notazioneHKLM\…che digiteresti in regedit).AccessList— cosa è stato tentato, come lista di nomi di access-right decodificati (uno per token%%NNNN). I valori decodificati comuni:%%4416=ReadData (or ListDirectory)%%4417=WriteData (or AddFile)%%4418=AppendData (or AddSubdirectory)%%4419=ReadEA/%%4420=WriteEA%%4423=ReadAttributes/%%4424=WriteAttributes%%4425=DELETE
AccessMask— la bitmask grezza diSTANDARD_RIGHTS_*e di diritti object-specific effettivamente richiesti.ProcessName+ProcessId— il processo che ha aperto l'handle. Il pivot verso 4688 / Sysmon 1 per il contesto di processo completo.SubjectLogonId— pivot al 4624 per la sessione originante, l'IP sorgente se logon di rete, e l'utente.
Configurare il 4663 — la parte che richiede lavoro vero
Ci sono tre layer di configurazione; se ne manca uno, niente record.
- Audit policy: abilita Object Access → Audit File System e/o Audit Registry per success e/o failure. Tramite Group Policy o
auditpol /set /subcategory:"File System" /success:enable /failure:enable. - SACL sull'oggetto: click destro → Properties → Security → Advanced → tab Auditing (GUI Windows), o tramite
Set-Acl/icacls /audit. Specifichi quale principal (spessoEveryoneoAuthenticated Users), quali diritti e se auditare success, failure o entrambi. - Per il registry: stesso flusso, accessibile via
regedit→ chiave → Permissions → Advanced → Auditing.
Senza (1) i record non vengono mai scritti. Senza (2) Windows non ha idea che tu volessi auditare qualcosa. Senza (3) stai auditando solo i file.
Le SACL da impostare su ogni server:
C:\Windows\System32\config\SAM,SECURITY,SYSTEM— credential store locali. AuditEveryone : ReadData : Success. Qualsiasi cosa legga questi diversa daLocalSystemè un tentativo di credential dumping.%TEMP%\lsass.dmpe qualsiasi*.dmpinC:\Windows\Temp— minidump di processo. AuditEveryone : WriteData : Success. Un processo che scrive un.dmpqui è o un crash dump (Windows) o un operatore Mimikatz (tutti gli altri).C:\ProgramData\Microsoft\Crypto\RSAeC:\Users\*\AppData\Roaming\Microsoft\Protect— directory delle DPAPI master-key. AuditReadData : Success. Chiunque legga questi dall'esterno della propria sessione utente sta rubando segreti protetti.HKLM\SECURITYeHKLM\SAM— equivalenti di registry. AuditReadData : Success.- Share di file sensibili — finance, legal, payroll. Audit
WriteData + DELETE : Successper intercettare gli sweep di cifratura ransomware e le cancellazioni di massa.
I pattern di triage
1. Lettura degli hive SAM / SYSTEM
Qualsiasi 4663 con ObjectName che termina in \config\SAM, \config\SECURITY o \config\SYSTEM, dove ProcessName non è services.exe / lsass.exe / wininit.exe e SubjectUserSid non è S-1-5-18. Questo è reg save HKLM\SAM, esentutl /y, vssadmin create shadow + copy, o qualsiasi tool di credential dumping con accesso a livello file all'hive.
2. File di dump LSASS scritto
Un 4663 WriteData per un file .dmp in C:\Windows\Temp\, C:\ProgramData\ o %TEMP%, con ProcessName di rundll32.exe, procdump*.exe, caller correlati a comsvcs.dll, o un binario rinominato. Questo è il pattern del minidump di LSASS. Cross-reference con 4688 per la CommandLine — comsvcs.dll MiniDump è l'encoding più comune.
3. Sweep di cifratura ransomware
Molti 4663 con AccessMask che include WriteData + DELETE contro file in uno share sensibile in pochi secondi, tutti dallo stesso SubjectLogonId e ProcessName. Un processo di backup reale tocca i file in un pattern misurabile e throttlato; il ransomware percorre un albero di directory alla velocità che il disco consente.
4. Furto di DPAPI master-key
4663 ReadData su file sotto \AppData\Roaming\Microsoft\Protect\<sid>\ da qualsiasi processo diverso dalla sessione dell'utente stesso. Il pattern classico è SubjectUserSid che è un SID diverso da quello nel path.
5. Lettura del file password delle Group Policy preference
4663 ReadData su file che matchano \SYSVOL\<domain>\Policies\*\Groups.xml (o Services.xml, Drives.xml). Questo è l'attacco Get-GPPPassword — vecchio, ma i file SYSVOL spesso esistono ancora nei domini legacy.
Esempio di regola Sigma — lettura dell'hive SAM
title: SAM Hive Read from Disk (Credential Dumping)
id: 5e1f9a3a-49a3-4f31-9c2e-8f5b1c2d3a4f
status: stable
description: A non-system process opened the SAM/SECURITY/SYSTEM registry hive file with read access.
references:
- https://attack.mitre.org/techniques/T1003/002/
- https://attack.mitre.org/techniques/T1003/004/
logsource:
product: windows
service: security
detection:
selection:
EventID: 4663
ObjectType: 'File'
ObjectName|endswith:
- '\config\SAM'
- '\config\SECURITY'
- '\config\SYSTEM'
AccessList|contains: '%%4416'
filter_system:
SubjectUserSid: 'S-1-5-18'
ProcessName|endswith:
- '\services.exe'
- '\lsass.exe'
- '\wininit.exe'
- '\smss.exe'
condition: selection and not filter_system
falsepositives:
- Volume Shadow Copy backup processes (track by ProcessName)
- Legitimate forensic agents (Velociraptor, GRR)
level: high
tags:
- attack.credential_access
- attack.t1003.002
Esempio KQL — sweep di cifratura ransomware
SecurityEvent
| where EventID == 4663
| where ObjectType == "File"
| where AccessMask in ("0x10000", "0x40000", "0x100", "0x2") // DELETE, WriteData
| summarize Files=dcount(ObjectName), Sample=any(ObjectName)
by SubjectLogonId, ProcessName, bin(TimeGenerated, 1m)
| where Files >= 100
| order by TimeGenerated desc
100 file distinti scritti-o-cancellati al minuto sotto una sola sessione di logon è uno sweep, senza eccezioni.
Esempio Splunk — accesso a DPAPI master-key
index=wineventlog EventCode=4663 ObjectName="*\\AppData\\Roaming\\Microsoft\\Protect\\*"
| rex field=ObjectName "Protect\\\\(?<owner_sid>S-[\\d\\-]+)\\\\"
| where SubjectUserSid != owner_sid AND SubjectUserSid != "S-1-5-18"
| table _time SubjectUserName ProcessName ObjectName
Mappatura ATT&CK
- T1003.002 — OS Credential Dumping: Security Account Manager: letture dell'hive SAM.
- T1003.004 — OS Credential Dumping: LSA Secrets: letture dell'hive SECURITY.
- T1003.001 — OS Credential Dumping: LSASS Memory: scritture di
.dmp(combinate con il contesto di processo). - T1555.004 — Credentials from Password Stores: Windows Credential Manager: accesso a
\AppData\Local\Microsoft\Credentials\. - T1552.006 — Unsecured Credentials: Group Policy Preferences: letture di SYSVOL
Groups.xml. - T1486 — Data Encrypted for Impact: pattern di WriteData + DELETE bulk (ransomware).
- T1565.001 — Stored Data Manipulation: scritture arbitrarie su share di dati monitorati.
Gestione del volume — la trappola delle SACL
Impostare ingenuamente Everyone : All access : Success+Failure su una directory occupata produrrà centinaia di migliaia di record 4663 al minuto e seppellirà la tua collection. Le SACL sono strumenti di precisione. Audita:
- Solo i tipi di accesso che ti interessano (
ReadDataper i credential store;WriteData + DELETEper gli share di dati; raramente entrambi). - Solo success — i failure sono più rari e raramente interessanti.
- File specifici, non interi drive. Il file SAM, non tutto
C:\Windows\System32\config\. Lo share HR, non tuttoD:\. - Principal specifici quando puoi — per oggetti SAM-class
Everyoneva bene perché l'accesso legittimo è comunque tramiteLocalSystem; per dati condivisi, audita solo i principal che toccano davvero i dati.
Una SACL ben tarata su cinque oggetti ad alto valore produce 50-200 record al giorno per host — totalmente gestibile.
Falsi positivi che sembrano esattamente attacchi
- Volume Shadow Copy (VSS) durante una finestra di backup genera traffico 4663 denso. Tagga il
ProcessNamedell'orchestratore di backup. - Le scansioni on-access degli antivirus aprono ogni file in una directory target; i service account del prodotto AV domineranno qualsiasi regola 4663 ingenua. Whitelist per SID.
- Servizi di indexing (Windows Search, stile Spotlight) toccano i metadati via
ReadAttributes— di solito filtrabili daAccessList. - Restore staged da backup sembrano scritture ransomware (molti file, un processo, in una directory) ma il processo è il tuo backup agent.
- Lo scan real-time di Defender legge tutto; se audi troppo ampiamente, è la fonte di rumore dominante.
Cosa il 4663 non ti dice
- Contenuto dell'accesso: vedi che un file è stato letto/scritto, non cosa è stato letto/scritto. Per questo serve un prodotto EDR o FIM (File Integrity Monitoring).
- Perché l'accesso è avvenuto: solo l'esito della syscall. Per correlare all'intento utente, abbina a 4688 / Sysmon 1 per il contesto completo del processo chiamante.
- Handle chiusi: il 4663 si attiva sull'apertura dell'handle. Gli eventi di chiusura sono 4658, raramente utili per la detection.
- Path di rete in modo trasparente: l'accesso SMB a uno share attiva il 4663 sul server; il client non vede nulla. Serve collection lato server.
- Accesso fallito per default: molti negozi auditano solo
Success; configuraFailuresolo se ti interessano genuinamente i tentativi di accesso sventati.
Dove il 4663 si colloca in una timeline
Catena classica di dump credenziali LSASS:
- 4624 — logon admin (LogonType 3 o 10).
- 4672 — SeDebugPrivilege concesso alla sessione.
- 4688 —
rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump <pid> C:\Windows\Temp\lsass.dmp full. - 4663 —
WriteDatasuC:\Windows\Temp\lsass.dmpdarundll32.exe. Oro forense — prova dello staging per l'exfil. - 4688 — file move / archiviazione (l'operatore che estrae il dump).
- 1102 — Security log cancellato (alcuni operatori lo fanno; molti se lo dimenticano).
Il 4663 al passo 4 è il segnale più economico e specifico della catena — identifica direttamente l'artefatto di furto credenziali per nome, su disco, con il processo chiamante allegato. Letture dell'hive SAM, accesso a DPAPI master-key e letture di SYSVOL Groups.xml funzionano allo stesso modo.