NtDeleteObjectAuditAlarm

Prototype

NTSTATUS NtDeleteObjectAuditAlarm(
  PUNICODE_STRING SubsystemName,
  PVOID           HandleId,
  BOOLEAN         GenerateOnClose
);

Arguments

Syscall IDs by Windows version

Syscall stub

4C 8B D1            mov r10, rcx
B8 DD 00 00 00      mov eax, 0xDD
F6 04 25 08 03 FE 7F 01   test byte ptr [0x7FFE0308], 1
75 03               jne short +3
0F 05               syscall
C3                  ret
CD 2E               int 2Eh
C3                  ret

Undocumented notes

Generates Security event 4660 ("An object was deleted"). The audited subsystem invokes this syscall after a successful delete operation on a SACL-monitored object so the Security log carries an explicit deletion record (the open/close pair alone does not distinguish a normal close from a delete). 4660 is the canonical event that incident responders correlate with 4663 (delete-access exercised) and 4656 (open with DELETE) on the same HandleId to fully reconstruct an attacker's destructive activity. SSN `0xDD` on Win11 24H2 (and matching values on earlier builds — note this is one of the few audit-alarm syscalls whose SSN drifts because it sorts alphabetically among the renumbered group).

Common malware usage

None observed in commodity malware. Destructive operations performed by ransomware/wipers (Conti, Royal, AcidRain) never call NtDeleteObjectAuditAlarm — they call NtSetInformationFile with FileDispositionInformation, or NtDeleteFile, directly, leaving the Object Manager to apply the SACL or not. Whether 4660 fires depends entirely on whether the *audited subsystem path* was used; bypassing the Win32 wrapper means no 4660. This is exactly why defenders should not rely solely on 4660 for ransomware detection — file-system mini-filter telemetry (FltMgr ETW provider, EDR file-write hooks) is more reliable.

Detection opportunities

Event 4660 must be paired with 4663 (DELETE access granted) and a preceding 4656 sharing the same HandleId to reconstruct who deleted what. On SACL-monitored shadow-copy stores, the registry hives under HKLM\SECURITY, and the Defender configuration keys, 4660 spikes are direct ransomware indicators. Absence of 4660 in the presence of mass file deletion (observable via Sysmon Event ID 23) implies the deletion path bypassed the audit-alarm subsystem — itself a strong signal of a sophisticated actor (T1070.004).

Direct syscall examples

; Direct syscall stub for NtDeleteObjectAuditAlarm (SSN 0xDD, Win11 24H2)
NtDeleteObjectAuditAlarm PROC
    mov  r10, rcx          ; syscall convention
    mov  eax, 0DDh         ; SSN
    syscall
    ret
NtDeleteObjectAuditAlarm ENDP

// Service holding the handle has just performed a privileged delete via
// NtSetInformationFile(FileDispositionInformation). Now record the 4660.
UNICODE_STRING sub = RTL_CONSTANT_STRING(L"Security");

NTSTATUS s = NtDeleteObjectAuditAlarm(
    &sub,
    (PVOID)hHandleId,   // same value used in the matching NtAccessCheck*AuditAlarm call
    TRUE);              // matches the GenerateOnClose flag returned earlier

// Resulting Security event 4660 carries object DN/path and the deleting subject.
NtClose(hFile);

use windows_sys::Win32::Security::Authorization::ObjectDeleteAuditAlarmW;

unsafe {
    let ok = ObjectDeleteAuditAlarmW(
        windows_sys::w!("Security"),
        handle_id as *mut _,
        gen_on_close as i32,
    );
    // ok != 0 -> 4660 emitted (subject to "Audit Object Access" policy).
}

MITRE ATT&CK mappings

• T1562.002Impair Defenses: Disable Windows Event Loggingmitre ↗
• T1070.004Indicator Removal: File Deletionmitre ↗