NtRequestPort
Sendet eine Fire-and-Forget-LPC-Message auf einem verbundenen Port — ohne Antwort zu erwarten.
Prototyp
NTSTATUS NtRequestPort( HANDLE PortHandle, PPORT_MESSAGE RequestMessage );
Argumente
| Name | Type | Dir | Description |
|---|---|---|---|
| PortHandle | HANDLE | in | Handle auf einen verbundenen LPC-Port, zuvor von NtConnectPort / NtSecureConnectPort zurückgegeben. |
| RequestMessage | PPORT_MESSAGE | in | PORT_MESSAGE-Header gefolgt vom Inline-Payload (≤ 256 Bytes); wird beim Server eingereiht und der Call kehrt zurück. |
Syscall-IDs pro Windows-Version
| Windows-Version | Syscall-ID | Build |
|---|---|---|
| Win10 1507 | 0x15D | win10-1507 |
| Win10 1607 | 0x164 | win10-1607 |
| Win10 1703 | 0x16A | win10-1703 |
| Win10 1709 | 0x16D | win10-1709 |
| Win10 1803 | 0x16F | win10-1803 |
| Win10 1809 | 0x170 | win10-1809 |
| Win10 1903 | 0x171 | win10-1903 |
| Win10 1909 | 0x171 | win10-1909 |
| Win10 2004 | 0x177 | win10-2004 |
| Win10 20H2 | 0x177 | win10-20h2 |
| Win10 21H1 | 0x177 | win10-21h1 |
| Win10 21H2 | 0x179 | win10-21h2 |
| Win10 22H2 | 0x179 | win10-22h2 |
| Win11 21H2 | 0x181 | win11-21h2 |
| Win11 22H2 | 0x184 | win11-22h2 |
| Win11 23H2 | 0x184 | win11-23h2 |
| Win11 24H2 | 0x186 | win11-24h2 |
| Server 2016 | 0x164 | winserver-2016 |
| Server 2019 | 0x170 | winserver-2019 |
| Server 2022 | 0x17F | winserver-2022 |
| Server 2025 | 0x186 | winserver-2025 |
Kernel-Modul
Verwandte APIs
Syscall-Stub
4C 8B D1 mov r10, rcx B8 86 01 00 00 mov eax, 0x186 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
NtRequestPort ist die asynchrone, antwortlose Variante von NtRequestWaitReplyPort auf dem Legacy-**LPC**-Pfad. Der Kernel kopiert die Inline-PORT_MESSAGE in die Empfänger-Port-Queue und kehrt sofort zurück — der Caller blockiert nie auf eine Server-Antwort. Typisch für einseitige Benachrichtigungen (z. B. CSRSS-Event-Posting auf Pre-Vista-Builds). Inline-Payload ist auf PORT_MAXIMUM_MESSAGE_LENGTH (256 Bytes) gedeckelt; größere Payloads erfordern eine zuvor ausgehandelte gemeinsam genutzte PORT_VIEW.
Häufige Malware-Nutzung
Auf modernem Windows ist die Malware-Nutzung von NtRequestPort *vernachlässigbar*. Historisch nutzten ein paar Pre-Vista-User-Mode-Rootkits es als einseitiges Fan-out-Signal (z. B. einer co-residenten Komponente einen Zustandswechsel signalisieren), gerade weil kein Win32-Wrapper existiert und Userspace-Tools LPC-Verkehr selten sichtbar machen. Heute greift ein Angreifer für diese Semantik auf NtAlpcSendWaitReceivePort mit `ALPC_MSGFLG_RELEASE_MESSAGE`, einen schreibbaren Mailslot oder einen Named-Pipe-Write zurück. Jeder rohe LPC-Request aus einem unsignierten Prozess ist schon für sich anomal.
Erkennungsmöglichkeiten
Es gibt keinen dedizierten ETW-Provider für Legacy-LPC analog zu `Microsoft-Windows-Kernel-ALPC`. Kernel-EDRs können den Syscall direkt hooken; User-Mode-EDRs hooken `ntdll!NtRequestPort`. Die Baseline legitimer Caller auf Windows 10/11 ist praktisch null (kaum noch ein Inbox-Bestandteil nutzt rohes LPC), daher ist *jeder* Treffer aus einem unsignierten oder gesandboxten Prozess hochaussagekräftig. WinObj zeigt lebende Port-Objekte, jedoch keine Messages in Flight.
Direkte Syscall-Beispiele
asmx64 direct stub
; Direct syscall stub for NtRequestPort (SSN 0x186 on Win11 24H2)
NtRequestPort PROC
mov r10, rcx ; PortHandle
mov eax, 186h ; SSN — verify per-build
syscall
ret
NtRequestPort ENDPcFire-and-forget LPC datagram
// Send a one-way LPC message on a connected port.
#include <windows.h>
#include <winternl.h>
typedef NTSTATUS (NTAPI *pNtRequestPort)(HANDLE, PVOID /*PPORT_MESSAGE*/);
NTSTATUS LpcNotify(HANDLE hPort, void *msgBuf) {
pNtRequestPort fn = (pNtRequestPort)GetProcAddress(
GetModuleHandleA("ntdll.dll"), "NtRequestPort");
return fn(hPort, msgBuf); // returns once the kernel queues the message
}MITRE ATT&CK-Mappings
Last verified: 2026-05-20