NtMakeTemporaryObject

Prototyp

NTSTATUS NtMakeTemporaryObject(
  HANDLE Handle
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

4C 8B D1            mov r10, rcx
B8 19 01 00 00      mov eax, 0x119
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

Undokumentierte Hinweise

Striktes Gegenstück zu `NtMakePermanentObject`: ruft `ObSetPermanentObject(object, FALSE)` und gibt die zusätzliche Referenz frei, die Ob hielt, um das Objekt über Handle-Count null hinaus am Leben zu halten. Erforderlicher Zugriff auf das Handle: `DELETE`. Erfordert *kein* `SeCreatePermanentPrivilege` — die Rückwandlung eines permanenten Objekts in ein temporäres ist insofern asymmetrisch. Nach Entfernen prüft der Kernel, ob noch Handles oder Referenzen bestehen; falls nicht, geht das Objekt sofort in die Deferred-Delete-Queue. Hauptsächlich genutzt von Service-Shutdown-Pfaden (z. B. csrss baut Session-scope-benannte Objekte ab) und von Win32 selbst, wenn `CloseHandle` die letzte Operation auf einem ursprünglich mit `OBJ_PERMANENT` erzeugten Objekt eines mittlerweile beendeten Prozesses ist.

Häufige Malware-Nutzung

Geringes Malware-Signal. Zwei nennenswerte Vorkommen: (1) **Forensik-/EDR-Cleanup-Utilities** rufen es auf, um rogue permanente Objekte, die frühere Payloads hinterlassen haben, einzusammeln — `WinObj` selbst nutzt diesen Pfad, wenn man auf einem permanenten Objekt Make Temporary und dann Close wählt. (2) Einige Implant-Designs nutzen es defensiv, um eigene Staging-Objekte vor dem Beenden zu *zerstören* und Defendern die Möglichkeit zu nehmen, sie post-mortem zu dumpen — z. B. wurde eine permanente Section genutzt, um ein Payload an einen Higher-Integrity-Helper zu reichen, der Helper hat es konsumiert, und das Implant setzt dann `NtMakeTemporaryObject` gefolgt von `NtClose` ab, um sicherzustellen, dass in `\BaseNamedObjects` kein Rest verbleibt. Der Aufruf ist ansonsten inert.

Erkennungs­möglichkeiten

Kein dediziertes ETW-Event. Die *Folgen* zu prüfen — Verschwinden erwarteter benannter Objekte in `\BaseNamedObjects` — ist praktischer als auf diesen Syscall zu alarmieren. Kernel-Object-Handle-Close-Events mit Objekt-Naming korrelieren, um benannte Objekte zu finden, die verschwinden, bevor ihr Owner-Service eigentlich heruntergefahren werden soll. Die Paarung `NtMakePermanentObject` (oder Erzeugung mit `OBJ_PERMANENT`) gefolgt von `NtMakeTemporaryObject` aus demselben Prozess in einem kurzen Zeitfenster ist das kanonische Stage-IPC-und-Wipe-Muster.

Direkte Syscall-Beispiele

; Direct syscall stub for NtMakeTemporaryObject (SSN 0x119 on Win11 24H2 / Server 2025)
NtMakeTemporaryObject PROC
    mov  r10, rcx          ; syscall convention
    mov  eax, 119h         ; SSN — drifts; resolve dynamically for portability
    syscall
    ret
NtMakeTemporaryObject ENDP

// Cleanup pattern: open a permanent named event/section/mutex with DELETE
// access, strip OBJ_PERMANENT, then drop our handle so it's freed.
UNICODE_STRING name; RtlInitUnicodeString(&name, L"\\BaseNamedObjects\\Global\\__rogue__");
OBJECT_ATTRIBUTES oa;
InitializeObjectAttributes(&oa, &name, OBJ_CASE_INSENSITIVE, NULL, NULL);
HANDLE h;
if (NT_SUCCESS(NtOpenEvent(&h, DELETE, &oa))) {
    NtMakeTemporaryObject(h);   // clear OBJ_PERMANENT
    NtClose(h);                  // last close -> object freed
}

MITRE ATT&CK-Mappings

• T1106Native APImitre ↗
• T1070Indicator Removalmitre ↗