NtAddAtom
Fügt eine Zeichenkette in die globale Kernel-Atomtabelle ein (oder erhöht den Refcount) und liefert deren 16-Bit-Atom-ID.
Prototyp
NTSTATUS NtAddAtom( PWSTR AtomName, ULONG Length, PRTL_ATOM Atom );
Argumente
| Name | Type | Dir | Description |
|---|---|---|---|
| AtomName | PWSTR | in | Zu registrierende UTF-16-Zeichenkette. **Kein NUL erforderlich** — Length ist in Bytes und der Kernel speichert die rohe Sequenz. |
| Length | ULONG | in | Größe des Puffers in Bytes. Erlaubt beliebigen Binärinhalt (Atom-Bomb-Shellcode-Upload-Primitive). |
| Atom | PRTL_ATOM | out | Empfängt die 16-Bit-Atom-ID (RTL_ATOM ist USHORT). Bereich 0xC000-0xFFFF für User-Atome. |
Syscall-IDs pro Windows-Version
| Windows-Version | Syscall-ID | Build |
|---|---|---|
| Win10 1507 | 0x47 | win10-1507 |
| Win10 1607 | 0x47 | win10-1607 |
| Win10 1703 | 0x47 | win10-1703 |
| Win10 1709 | 0x47 | win10-1709 |
| Win10 1803 | 0x47 | win10-1803 |
| Win10 1809 | 0x47 | win10-1809 |
| Win10 1903 | 0x47 | win10-1903 |
| Win10 1909 | 0x47 | win10-1909 |
| Win10 2004 | 0x47 | win10-2004 |
| Win10 20H2 | 0x47 | win10-20h2 |
| Win10 21H1 | 0x47 | win10-21h1 |
| Win10 21H2 | 0x47 | win10-21h2 |
| Win10 22H2 | 0x47 | win10-22h2 |
| Win11 21H2 | 0x47 | win11-21h2 |
| Win11 22H2 | 0x47 | win11-22h2 |
| Win11 23H2 | 0x47 | win11-23h2 |
| Win11 24H2 | 0x47 | win11-24h2 |
| Server 2016 | 0x47 | winserver-2016 |
| Server 2019 | 0x47 | winserver-2019 |
| Server 2022 | 0x47 | winserver-2022 |
| Server 2025 | 0x47 | winserver-2025 |
Kernel-Modul
Verwandte APIs
Syscall-Stub
4C 8B D1 mov r10, rcx B8 47 00 00 00 mov eax, 0x47 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
SSN `0x47` ist von 1507 bis 24H2 vollständig stabil — Atoms sind ein altes Subsystem, das niemand umnummeriert. Der Kernel pflegt eine **globale Atomtabelle**, prozessagnostisch: jeder Prozess kann `NtAddAtom` mit einem Namen aufrufen und jeder andere kann `NtFindAtom` zur Wiederbeschaffung der ID nutzen, dann `NtQueryInformationAtom` zum Auslesen des Namens. Die Win32-Wrapper `GlobalAddAtom*` / `GlobalFindAtom*` / `GlobalGetAtomName*` routen über diese Syscalls. Entscheidend: `Length` ist in **Bytes** und der Kernel erzwingt nicht, dass der Puffer eine gültige NUL-terminierte Unicode-Zeichenkette ist — er speichert die rohen Bytes, das ist die Grundlage von Atom Bombing.
Häufige Malware-Nutzung
**Atom Bombing** (enSilo, Tal Liberman, Oktober 2016) — die kanonische Code-Injection-Technik auf Basis dieses Syscalls. Stage 1: Shellcode in die globale Atomtabelle schreiben, indem `GlobalAddAtomA` (landet in NtAddAtom) mit den Shellcode-Bytes als 'Name' aufgerufen wird. Stage 2: APC in den Zielprozess einreihen, der `GlobalGetAtomNameA` (intern NtQueryInformationAtom) aufruft; der Kernel schreibt den Atom-'Namen' — also den Shellcode des Angreifers — in einen Puffer im Adressraum des Ziels. Stage 3: ein Folge-APC oder ein ROP-Gadget transitioniert den Puffer nach RWX (über NtSetContextThread + ROP-Calls zu `ZwProtectVirtualMemory`). Da **der Schreibvorgang im Zielprozess vom Kernel selbst durchgeführt wird**, sehen gehookte User-Mode-Funktionen im Ziel (NtWriteVirtualMemory, WriteProcessMemory) die Daten nie — was EDRs schlägt, die auf User-Mode-Injection-Hooks setzen. Übernommen von Dridex (2017er Welle, FireEye-Writeup) und seither als Basis-Technik in mehreren privaten RATs verbaut.
Erkennungsmöglichkeiten
Telemetrie zu NtAddAtom aus dem User Mode ist dünn — Atoms sind 90er-Jahre-Technologie, die historisch wenige Produkte instrumentiert haben. Moderne EDRs (CrowdStrike, SentinelOne, Defender) ergänzten ab 2017-2018 Verhaltensregeln, die nach Folgendem suchen: (1) `GlobalAddAtomA/W`-Aufrufe mit `Length` > ~250 Bytes (echte Atoms sind kurze Window-Class-Namen oder DDE-Strings); (2) Atom-Namens-Bytes, die nicht als gültiges UTF-16 roundtrippen (Binärinhalt); (3) `GlobalGetAtomNameA` aufgerufen aus einem Thread, der gerade über NtTestAlert / KiUserApcDispatcher in einem frisch allozierten Kontext aufgewacht ist — das Atom-Bomb-APC-Muster. ETW Microsoft-Windows-Kernel-Audit-API-Calls deckt diese Syscalls ab. WinDbg / Live-Forensik: die Extension `!atom` dumpt die globale Tabelle — lange Einträge mit nicht druckbaren Bytes sind ein starkes IOC.
Direkte Syscall-Beispiele
asmx64 direct stub
; Direct syscall stub for NtAddAtom (SSN 0x47, all builds)
NtAddAtom PROC
mov r10, rcx ; syscall convention
mov eax, 47h ; SSN
syscall
ret
NtAddAtom ENDPcAtom Bombing — stage 1 shellcode upload
// Atom Bomb stage 1: smuggle shellcode bytes into the global atom table.
// The Length is in bytes and the kernel does not require a NUL terminator,
// so arbitrary binary content rides in as the atom 'name'.
#include <windows.h>
#include <winternl.h>
typedef NTSTATUS (NTAPI *pNtAddAtom)(PWSTR, ULONG, PUSHORT);
USHORT AtomBombUpload(const BYTE* shellcode, ULONG cb) {
pNtAddAtom NtAddAtom = (pNtAddAtom)GetProcAddress(
GetModuleHandleA("ntdll.dll"), "NtAddAtom");
USHORT atomId = 0;
// PWSTR is just a cast — the kernel reads `cb` raw bytes regardless
// of UTF-16 validity. Real Atom Bomb POCs round cb up to even.
NTSTATUS s = NtAddAtom((PWSTR)shellcode,
(cb + 1) & ~1u, // even byte count
&atomId);
return NT_SUCCESS(s) ? atomId : 0;
}rustLightweight global atom (legitimate-style)
// Cargo: ntapi = "0.4", widestring = "1"
// Register a normal short string atom — same syscall, benign use.
// Demonstrates the Length-in-bytes convention.
use ntapi::ntexapi::NtAddAtom;
use widestring::U16CString;
pub unsafe fn add_atom(name: &str) -> Option<u16> {
let w = U16CString::from_str(name).ok()?;
let mut atom: u16 = 0;
let bytes = w.len() * 2; // UTF-16 byte count, excluding NUL
let s = NtAddAtom(w.as_ptr() as _, bytes as u32, &mut atom);
if s >= 0 { Some(atom) } else { None }
}MITRE ATT&CK-Mappings
Last verified: 2026-05-20