Windows Objects

The Object Manager, kernel objects, handles, reference counting, named objects, and the object namespace — how Windows represents every resource as a typed, access-controlled object

What Is a Windows Object

In Windows, every kernel resource — a file, a process, a thread, a mutex, a semaphore, an event, a registry key, a device — is represented as a kernel object. Objects are the fundamental unit of resource management in the Windows Executive. Rather than having ad-hoc structures for each resource type, the Object Manager provides a uniform framework for creating, naming, sharing, protecting, and destroying all kernel resources.

An object has three parts:

• Object header: Common metadata managed by the Object Manager — name, type, reference counts, security descriptor, quota charges
• Object body: The type-specific data — for a file, this is the file control block; for a process, this is the EPROCESS structure; for an event, this is the signaling state
• Object type: Defines the object's behavior — what operations are valid, what quotas apply, what cleanup runs when the last reference is released

  Kernel Object Layout in Memory
  ─────────────────────────────────────────────────────────────────
  ┌──────────────────────────────────────┐
  │         OBJECT_HEADER                │  ← Object Manager metadata
  │  TypeIndex      : 7 (Process)        │
  │  HandleCount    : 3                  │
  │  PointerCount   : 5                  │
  │  SecurityDescriptor pointer          │
  │  Name: "\\Sessions\\1\\csrss.exe"    │
  │  CreatorInfo (optional header)       │
  │  QuotaInfo   (optional header)       │
  └──────────────────────────────────────┘
  ┌──────────────────────────────────────┐
  │         OBJECT BODY                  │  ← Type-specific data
  │                                      │
  │  (For Process: EPROCESS structure)   │
  │    DirectoryTableBase                │
  │    UniqueProcessId                   │
  │    ActiveProcessLinks                │
  │    ImageFileName                     │
  │    ...                               │
  └──────────────────────────────────────┘

  

Object Header Fields

The OBJECT_HEADER structure precedes every kernel object body in memory. The pointer to an object body can be converted to the header by subtracting the body offset.

Handles — The User-Mode Reference

User-mode code cannot hold a pointer to a kernel object directly — those pointers are kernel-mode addresses. Instead, user-mode code holds a handle: a 32-bit or 64-bit integer that the kernel maps to a kernel object pointer internally.

When you call CreateFile(), the kernel:

1. Creates or opens a File object in kernel memory
2. Increments the object's PointerCount and HandleCount
3. Allocates an entry in the calling process's handle table pointing to the object
4. Returns the handle index to the caller

  Handle to Kernel Object Mapping
  ─────────────────────────────────────────────────────────────────
  User Mode (Process A)              Kernel Memory

  Handle 0x14 ──────────────────────► OBJECT_HEADER
                                      + File Object Body
                                        (path: C:\secret.txt)
                                        PointerCount: 2
                                        HandleCount:  1

  Handle 0x18 ──────────────────────► OBJECT_HEADER
                                      + Process Object Body (EPROCESS)
                                        (notepad.exe, PID 1234)
                                        PointerCount: 4
                                        HandleCount:  2
                                               ▲
  Process B's Handle 0x4C ──────────────────────┘
  (Both processes have a handle to notepad.exe's EPROCESS)

  

Handle Values

Handle values are always multiples of 4 on 64-bit Windows (the lowest 2 bits are used as flags). A few special handles are recognized by the OS:

The Handle Table

Each process maintains a handle table in kernel memory (pointed to by the EPROCESS structure). The handle table maps handle values to kernel object pointers. It's a three-level paged structure similar to page tables, allowing up to 16 million handles per process.

// Inspecting handles with WinAPI (enumerate all handles in current process)
// Use GetProcessHandleCount() for a quick count
DWORD handle_count;
GetProcessHandleCount(GetCurrentProcess(), &handle_count);
printf("Open handles: %lu\n", handle_count);

// For forensics: NtQuerySystemInformation with SystemHandleInformation
// lists ALL handles in ALL processes (requires SYSTEM privileges)
// This is how Process Explorer and handle.exe work
NTSTATUS status = NtQuerySystemInformation(
    SystemHandleInformation,    // 0x10
    buffer,
    bufferSize,
    &returnedLength
);

Handle Inheritance and Duplication

Handles are process-local by default. To share an object between processes, use DuplicateHandle() or create the handle with SECURITY_ATTRIBUTES.bInheritHandle = TRUE (child processes inherit marked handles). Malware uses DuplicateHandle to obtain handles to privileged processes — a technique that bypasses some EDR monitoring since the duplicated handle doesn't show up in the original process.

Reference Counting and Object Lifetime

The Object Manager tracks two reference counts: HandleCount (number of open handles) and PointerCount (total references including internal kernel pointers). The object is freed only when PointerCount reaches zero. HandleCount dropping to zero triggers name removal from the object namespace and calls the Close procedure, but the object body persists until all kernel pointers are released.

  Object Lifetime
  ─────────────────────────────────────────────────────────────────
  CreateEvent()       PointerCount = 1, HandleCount = 1
                      Object name "MyEvent" registered in namespace

  OpenEvent()         PointerCount = 2, HandleCount = 2
  (second handle)     Two processes can now signal/wait

  CloseHandle() ×1    PointerCount = 1, HandleCount = 1

  CloseHandle() ×2    PointerCount = 1, HandleCount = 0
                      Name REMOVED from namespace (no new opens possible)
                      Object body still exists (kernel still holds PointerCount=1)

  Kernel releases     PointerCount = 0
  internal pointer    DeleteProcedure called → object memory freed

  

Named Objects and the Object Namespace

Objects can have names, making them discoverable by other processes using a path-based namespace. Named objects live in the Windows Object Namespace, which is separate from the file system but uses a similar hierarchical structure with backslash separators.

  Windows Object Namespace (partial)
  ─────────────────────────────────────────────────────────────────
  \                              ← Root directory object
  ├── \Device                    ← Device objects (disk, keyboard, etc.)
  │   ├── \Device\HarddiskVolume3
  │   └── \Device\Null
  ├── \Driver                    ← Driver objects
  ├── \KnownDlls                 ← Known DLL objects (pre-mapped)
  ├── \Windows                   ← Window stations
  ├── \Sessions                  ← Per-session objects
  │   ├── \Sessions\0            ← Session 0 (services)
  │   └── \Sessions\1            ← Session 1 (first logged-in user)
  │       └── \Sessions\1\BaseNamedObjects\
  │           └── MyMutex1234    ← Per-session named mutex
  └── \BaseNamedObjects          ← Global namespace
      ├── Global\MyMutex1234     ← Globally visible named object
      └── Local\SomeName         ← Local alias (same as \Sessions\N\BaseNamedObjects\)

  

Global vs Local Namespace

Named objects created with plain names (no prefix) go into \Sessions\N\BaseNamedObjects\ — visible only within the session. The Global\ prefix routes to \BaseNamedObjects\ — visible across all sessions, including Session 0 (services). The Local\ prefix is an alias for the current session's namespace.

This is exactly what the malware mutex example uses: Global\\MyMutex1234 goes into the global namespace, ensuring the mutex is visible even if the malware runs in Session 0 (as a service) and checks against an instance in Session 1 (interactive user), or vice versa.

// Creating a named mutex — malware single-instance check pattern
HANDLE hMutex = CreateMutexA(
    NULL,              // no security attributes (inheritable = FALSE)
    FALSE,             // don't take initial ownership
    "Global\\MyMalwareMutex2024"  // name in global namespace
);

if (GetLastError() == ERROR_ALREADY_EXISTS) {
    // Another instance is running — exit silently
    CloseHandle(hMutex);
    return 0;
}
// First instance — proceed with malicious activity

Common Object Types

Inspecting the Object Namespace with WinObj

Sysinternals WinObj is the essential tool for exploring the Windows Object Namespace. It provides a GUI tree view of the entire namespace, showing object names, types, and security descriptors. Run it as Administrator to see all objects.

; Useful WinObj investigations:
; \BaseNamedObjects — global named mutexes, events, semaphores
; \Sessions\1\BaseNamedObjects — per-session objects for interactive user
; \Device — all device objects (see what drivers are loaded)
; \KnownDlls — DLLs that are pre-loaded at system startup
; \ObjectTypes — all registered object type objects

From a forensics perspective, named mutexes in \BaseNamedObjects are IOC gold — malware families often use consistent mutex names, and finding a known malware mutex name in WinObj confirms active infection without needing to find the executable.

// Checking for known malware mutex names programmatically
// OpenMutex with SYNCHRONIZE access returns NULL if mutex doesn't exist
HANDLE hMutex = OpenMutexA(SYNCHRONIZE, FALSE, "Global\\MyMalwareMutex2024");
if (hMutex != NULL) {
    printf("INFECTED: mutex found!\n");
    CloseHandle(hMutex);
} else {
    printf("Mutex not found: %d\n", GetLastError());
    // ERROR_FILE_NOT_FOUND (2) = mutex doesn't exist
    // ERROR_ACCESS_DENIED (5) = mutex exists but can't open it
}

Q & A