Windows Security Log · Event 4663

Event 4663: Something accessed a file, folder, or registry key

This is the event people reach for when they need to know who deleted a file. It records an access that was actually exercised — but only on objects you marked for auditing beforehand, and the word 'attempt' in Microsoft's title is misleading: a success here means the access happened.

Also written as Event ID 46634663 file access auditing

How oftenFires often
Vendor calls itAudit Success
LogSecurity
SourceMicrosoft-Windows-Security-Auditing

What it means for you

On a personal computer

Not enabled by default and not something a personal machine needs. If you are trying to find out what happened to a file on your own PC, File History or Previous Versions will get you further than this will.

For an analyst

The distinction that trips people up is 4656 versus 4663. 4656 is the handle request — it records what a process asked permission for, which is frequently everything the API bothered to request rather than what it intended to do. 4663 is the access being used, which is much closer to reality. Chase 4663 for what happened and 4656 only when you need the requested-versus-granted difference. Also note that DELETE on a file often shows as a rename to a Recycle Bin path rather than a delete, so a deletion hunt that filters on the delete access mask alone misses the ordinary case.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample

An attempt was made to access an object.

Subject:
  Security ID:    CORP\jbrooks
  Account Name:   jbrooks
  Account Domain: CORP
  Logon ID:       0x4A21C9

Object:
  Object Server:  Security
  Object Type:    File
  Object Name:    D:\Finance\Payroll\2026-Q3.xlsx
  Handle ID:      0x8f4

Process Information:
  Process ID:     0x1cf4
  Process Name:   C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Access Request Information:
  Accesses:       DELETE
  Access Mask:    0x10000

The fields that decide it

Everything else in the log line is context.

Object Name: The full path of the file, folder, or registry key. This is the field that decides whether the event matters.
Accesses: What was actually done. The single most important field, and the one most often skimmed.
Subject Account Name and Logon ID: Who did it. The Logon ID is the reliable join back to the Event 4624 that started the session, and it survives where usernames are ambiguous.
Process Name: Which program performed the access. Explorer looks very different from powershell.exe or an unfamiliar binary in a temp folder.
Object Type: File, Key, or another kernel object type. The same event ID covers filesystem and registry, so filter on this before assuming which you are looking at.
Handle ID: Ties this access back to the 4656 that opened the handle and forward to the 4658 that closed it, letting you reconstruct how long the object was held open.

Ordinary reasons this happens

Most of the time it is one of these.

Ordinary users opening and saving documents in an audited folder.
Backup software reading every file it protects, which produces a very large and very regular burst.
Antivirus scanning, which touches everything and is the usual reason people abandon file auditing.
Search indexing walking audited paths.
Applications reading their own configuration files thousands of times a day.
File replication and synchronisation agents, which both read and write continuously.

When it is not ordinary

Bulk collection of documents before exfiltration.

What gives it awayOne account reading a very large number of distinct files in a short window, from a process that is not the user's normal application.

ATT&CK T1005

Ransomware encrypting an audited share.

What gives it awaySustained WriteData across many files by a single process, frequently paired with deletes and renames.

ATT&CK T1486

Permissions being widened on a sensitive path.

What gives it awayWriteDAC or WRITE_OWNER accesses on a folder, which almost no legitimate workflow performs.

ATT&CK T1222.001

Evidence removal.

What gives it awayDELETE accesses on log or backup paths, particularly by an account with no reason to touch them.

ATT&CK T1070.004

What to do next

Read the Accesses field before anything else. A read and a delete on the same path are entirely different events and the path alone will not tell you which happened.
Take the Logon ID and find the Event 4624 that started that session — that gives you the source address and logon type behind the access.
Check the Process Name. An access through Explorer is a person; an access through a script host or an unfamiliar binary is not.
For a suspected deletion, do not filter on DELETE alone. Look for accesses on the file and for a rename into a Recycle Bin path, which is how Windows deletes files interactively.
Count distinct Object Names per account per hour. Bulk collection shows up as breadth, not as any individual event.
If the volume is unusable, narrow the SACL rather than the query — audit specific sensitive folders for write and delete only, not entire shares for everything.
Correlate with Event 5145 for accesses that arrived over a network share, which tells you the access came from another machine.

Queries to run

kql DELETE, WRITE_DAC and WRITE_OWNER — %%1537, %%1539 and %%1540. These three have the poorest ratio of legitimate to interesting of any access right.

SecurityEvent | where EventID == 4663 | where AccessList has_any ('%%1537','%%1539','%%1540') | project TimeGenerated, Computer, SubjectAccountName = Account, ObjectName, ProcessName, AccessList

kql Bulk access by breadth rather than by any single event. Tune the threshold to your backup window.

SecurityEvent | where EventID == 4663 and ObjectType == 'File' | summarize files = dcount(ObjectName) by Account, ProcessName, bin(TimeGenerated, 1h) | where files > 500 | order by files desc

powershell Local read on a single server when you are chasing one specific file.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663; StartTime=(Get-Date).AddHours(-1)} | Select-Object TimeCreated, @{n='Object';e={$_.Properties[6].Value}}, @{n='Access';e={$_.Properties[9].Value}} | Format-Table -AutoSize

sigma 0x10000 is DELETE. Pair it with a path filter — unscoped, this fires on ordinary temp-file cleanup all day.

detection:
  selection:
    EventID: 4663
    ObjectType: 'File'
    AccessMask: '0x10000'
  condition: selection

Common questions

How do I find out who deleted a file using Event 4663?

You need auditing to have been configured before the deletion — this cannot be answered retrospectively. With a SACL in place, filter the Security log for 4663 on that path and read the Accesses field. Do not filter on DELETE alone: deleting a file in Explorer moves it to the Recycle Bin, which Windows records as a rename, so the event you want may name a path under $Recycle.Bin instead.

What is the difference between Event 4656 and Event 4663?

4656 records a handle being requested — what a process asked for, which is often much broader than what it intended to do, because APIs commonly request every access they might need. 4663 records an access actually being used. For working out what happened, 4663 is far closer to the truth; 4656 matters mainly when you need to see a request that was refused.

Why do I get no Event 4663 even though object access auditing is on?

Because the audit policy is only half the configuration. Each file, folder or registry key you want audited also needs a system access control list — set through the object's Properties, Security, Advanced, Auditing tab. The policy says the system may audit; the SACL says what to audit. Neither works alone.

Does Event 4663 mean the access succeeded?

Yes. Despite Microsoft's title using the word 'attempt', a 4663 records an access that was actually performed — Microsoft's own documentation notes that this event has no Failure variant at all. That is the difference from Event 4656, which does record failures: a refused access shows up as a failed 4656 and never as a 4663.

Is Event 4663 too noisy to use?

Unscoped, yes — auditing a whole file server for all access will bury you, largely thanks to backup and antivirus reading everything. Scoped, it is one of the more precise events available. Audit a small number of genuinely sensitive folders, for write and delete rather than read, and the volume becomes manageable and nearly every event means something.

Mentioned by

Vendor documentation

Last reviewed 6 September 2026