HYLAS // HANDLEREF

// HANDLE — OVERVIEW

Handle.exe displays information about open handles for any process in the system — or searches all processes for handles to a named resource. It answers "which process has this file locked?" and "what objects does this process have access to?"

Critical for incident response (find who has the SAM hive open), forensics (what files did this process touch?), and system administration (find the process locking a file you can't delete).

// HANDLE — SYNTAXCLI

handle64.exe                     ; List all handles for all processes
handle64.exe -p lsass           ; Handles held by lsass.exe
handle64.exe -p 1234            ; Handles held by PID 1234
handle64.exe C:\Windows\Temp    ; Which processes have handles in Temp
handle64.exe -a                 ; Show all handle types (not just files)
handle64.exe -u                 ; Show owner username for each handle
handle64.exe -v                 ; CSV output for scripting
handle64.exe -c 0x4 -p 1234   ; Close handle 0x4 in process 1234 (careful!)
handle64.exe -s                 ; Print count of each type of open handle
handle64.exe -nobanner          ; Suppress banner for scripting

; Common investigation workflow:
handle64.exe -a -p lsass -nobanner > lsass_handles.txt
; Look for: Process handles from unexpected PIDs = credential dumping attempt
; Look for: SAM / SECURITY / SYSTEM hive handles from non-system processes

// HANDLE — SECURITY RELEVANCEATTACKER USE

Suspicious Handle Target	Why Suspicious	Likely Technique
\REGISTRY\MACHINE\SAM	SAM hive contains local password hashes. Only SYSTEM should hold it open.	Credential dumping (reg save SAM)
\REGISTRY\MACHINE\SECURITY	Contains cached domain credentials and LSA secrets.	LSA secret extraction
lsass.exe process handle	Process handle to LSASS from non-OS process = memory reading for credentials	Mimikatz, pypykatz, lsassy
C:\Windows\Temp\*.tmp	Staging files for payload delivery or data exfil	Dropper, beacon staging
\Device\PhysicalMemory	Direct physical memory access — extreme privilege, rootkit territory	Kernel-mode rootkits
Unusual pipe names	Named pipes used for C2 comms (e.g. Cobalt Strike default pipes)	C2 framework comms channel

Known Cobalt Strike default named pipes (change in your Malleable C2 profile):

\pipe\msagent_*
\pipe\MSSE-*-server
\pipe\postex_*
\pipe\status_*
\pipe\mojo.*

// LISTDLLS — OVERVIEW

ListDLLs lists every DLL currently loaded in one or all running processes. It shows the full path, version, load address, and whether the DLL is loaded from disk or injected. Key use: finding DLLs that shouldn't be there — DLL injection, DLL hijacking, and malicious DLL side-loading.

// LISTDLLS — SYNTAXCLI

Listdlls.exe                    ; List DLLs for all processes
Listdlls.exe lsass              ; DLLs in lsass.exe
Listdlls.exe -p 1234            ; DLLs in PID 1234
Listdlls.exe -u                 ; Show only UNSIGNED DLLs — key for triage
Listdlls.exe -d badlib.dll      ; Find which processes have badlib.dll loaded
Listdlls.exe -v                 ; Verbose: show DLL version info
Listdlls.exe -r                 ; Flag DLLs not loaded from base address (rebased)
Listdlls.exe -nobanner          ; Suppress banner for scripting

; Triage shortcut — unsigned DLLs in all processes:
Listdlls64.exe -u -nobanner > unsigned_dlls.txt

// DLL HIJACKING — HOW IT WORKSTECHNIQUE

Windows DLL search order (for applications without absolute DLL paths):

KnownDLLs registry key (bypasses search order entirely)
Application directory (where the .exe lives)  ← ATTACKER TARGET
System directory (C:\Windows\System32)
16-bit system directory (C:\Windows\System)
Windows directory (C:\Windows)
Current working directory
PATH environment variable directories

DLL Side-loading — place malicious DLL in application directory with the name of a DLL the application expects but doesn't include:

; Example: VMware host app side-loading
; Legitimate: C:\Program Files\VMware\vgauth.dll (not present, loads from System32)
; Attack:     C:\Program Files\VMware\vgauth.dll (attacker-placed, loads first)

; How to find vulnerable applications:
; Run Procmon, filter for: PATH NOT FOUND + .dll extension
; Every "NAME NOT FOUND" for a DLL = potential hijack point

DLL Search Order Hijacking via PATH manipulation:

; If attacker controls a directory earlier in PATH than System32,
; any DLL not in KnownDLLs can be hijacked.
; Listdlls -u will show the injected DLL as unsigned when loaded.

Using ListDLLs to detect hijacking:

Listdlls64.exe -u          ; Find unsigned DLLs loaded in any process
; Then manually check:
; - Is the DLL path expected for that process?
; - Is the DLL in AppData, Temp, or a writable user directory?
; - Does the DLL name match a known system DLL but load from non-system path?

// RED TEAMATTACKER

▶DLL side-loading — plant malicious DLL alongside legitimate signed executable. The signed binary loads and executes the malicious DLL. Entire process appears signed.

▶Reflective DLL injection — DLL loaded from memory, never touches disk. Won't appear with a file path in ListDLLs — shows as memory region.

▶Phantom DLL hijacking — target DLLs that are in the search order but don't exist on the system. Safe to plant without overwriting.

// BLUE TEAMDEFENDER

▶Run Listdlls -u regularly — unsigned DLLs in LSASS, svchost, or other system processes are high-priority IOCs.

▶Restrict write access — ensure application directories are not world-writable. Only administrators should write to Program Files.

▶Enable SafeDllSearchMode — registry: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SafeDllSearchMode = 1