Handles, Pipes and Mutexes
A handle is how a process reaches an object Windows keeps for it, such as a file, a registry key, another process, a named pipe or a mutex. Each handle carries what the process may do with that object, so a handle list reads as a list of what the process is touching. Normal is files in the program's own folders, its own registry keys, and handles to other processes that many programs hold only to read basic details. Look first at any Process handle into another process, lsass.exe above all, and at the rights it grants.
What It Is
A handle is a numbered ticket Windows gives a process when it opens something Windows owns, such as a file, a Registry key, a pipe or another process.
- Why Windows Needs It
- A program cannot touch a file or another process directly, because Windows keeps them. So the program asks, Windows checks the program's token, and if the account may, it hands back a ticket marked with what the program may do.
- An Everyday Example
- When Notepad opens notes.txt for alice, Windows hands it a ticket, say 0x1A4, marked read and write. Notepad shows that ticket each time it reads or saves, and hands it back when the file closes. So a handle list is a list of what a process has open right now.
0x1A4File, read and writeC:\Users\ alice\ notes.txt 0x1B0Key, readHKEY_CURRENT_ USER, alice's settings 0x1C8File, read and writeA named pipe to another program- Another program
0x2C4Process, read its memorylsass.exeWorth a look. lsass.exe keeps sign-in secrets, so few programs need to read its memory.
- Kept by the Kernel
- The kernel keeps each process's handle table, with the access each handle was granted when it was opened.
Each handle points to an object of one type, and the type says what the process can reach through it. These are the types a handle list shows most.
The object types a handle list shows most
| Type | What It Is | Normal | Worth a Look |
|---|---|---|---|
| File | An open file, folder or device, with named pipes among them | Files in the program's folders, profile and logs | An archive growing in Temp, held by a process with no reason to write one |
| Key | An open registry key, by its full path | Keys under the program's own Software key | A Run or service key held by a process with no business there |
| Process | Another process, with the rights the handle grants | Limited query rights, held by parents, services and security tools | Rights to read or write the memory of lsass.exe or a system process |
| Thread | One thread of a process | A process's own threads | Rights to set the context of another process's thread |
| Token | An access token | Services and the sign-in components | Another account's token held by a person's program |
| Section | Shared memory, such as a file mapped into memory | Image and data file sections, and shared memory | A section mapped into another process to deliver code |
| Mutant | A mutex, a lock that one thread holds at a time | Many, from Windows and programs | A name that matches intelligence |
Object Types and Access Rights
Windows names the object behind each handle by its type, and the table above lists the types a handle list shows most. Read a handle to another process first, because its access mask says what the holder can do there.
Each handle carries a number, its access mask, that encodes what it allows. You only need the handful below, read as Microsoft's process access rights. A protected process refuses rights to read or write its memory.
Process access rights a defender reads in a granted mask
| Right | Mask | What the Holder Can Do |
|---|---|---|
PROCESS_QUERY_LIMITED_INFORMATION | 0x1000 | Read basic details only |
PROCESS_VM_READ | 0x0010 | Read its memory |
PROCESS_VM_WRITE | 0x0020 | Write its memory |
PROCESS_CREATE_THREAD | 0x0002 | Start a thread in it |
PROCESS_ALL_ACCESS | 0x1FFFFF | Every right |
Named Pipes
A named pipe carries data between a pipe server and its clients, on one machine or across the network. A file system driver serves pipes, so an open pipe shows among a process's File handles under \Device\NamedPipe.
Most pipe names are ordinary. PsExec is a free Sysinternals tool that administrators use to run programs on other machines. It creates a service named PSEXESVC there by default, with a pipe of the same name, which SigmaHQ names in a public rule.
ws-042's PSEXESVC.exe holds \Device\NamedPipe\PSEXESVC open, and where PsExec has no business, that name is the lead. Sysmon events 17 and 18 in its Operational log record pipes created and connected to, where pipe events are configured, and Defender's NamedPipeEvent does too. PipeList lists every pipe on a live machine.
Mutexes
A mutex, which Windows calls a mutant, is held by one thread at a time, and a named one can be opened by any process that knows the name. Asked for a mutex whose name is taken, Windows hands back the existing one, so a program can tell that another copy got there first.
Some malware makes one to mark a machine it has already reached, so a second copy exits. A name is a lead only when it matches intelligence, or looks random in a process that should not hold it.
windows.mutantscan finds mutex objects in a memory image. Live, Windows.Detection.Mutants finds who holds a named one, and Windows.Events.Mutants alerts on new ones whose name matches a pattern you set.
From a Handle to the File
A File handle names a file the process holds open, and its mapped executables and DLLs sit in its memory regions. In a memory image, windows.dumpfiles with the process ID writes out the cached copies of both.
Hash what comes out, check its signature and scan it offline, as you would a file taken from disk.
What Normal Looks Like
On a healthy machine this part looks like this.
- Files in the program's own folders, its profile and its logs, and registry keys under its own Software key and the user's settings.
- Parents, service hosts, security products and management tools hold handles to other processes, many with limited query rights only.
- Many named mutexes from Windows and programs. A name is a lead only when it matches intelligence or looks random in an unexpected process.
- Browsers built on Chromium, and Teams, create mojo pipes named with process and thread ids, and PowerShell hosts create pipes starting PSHost.
Why It Matters
A handle to lsass.exe from an unexpected program can be the first sign of credential theft, and a pipe or mutex name can point to the tool behind it. Handles show only what is open now, so pair them with records of opens.
Normal and Suspicious
A clean machine sits beside a suspicious one, and the pointer marks where to look.
Normal
A clean Windows 11 install
| Type | Name | Access |
|---|---|---|
| Process | spoolsv.exe | 0x1000: read basic details (PROCESS_ |
Suspicious
ws-042,
| Type | Name | Access |
|---|---|---|
| Process | spoolsv.exe (PID 3268) | 0x1FFFFF (PROCESS_ |
| AccessWrite and thread rights into the spooler: updsvc64.exe is no security or management tool. Remote Thread Injection | ||
What a Malicious Example Shows
Each card is what malicious use of this part looks like, and where it shows.
- A program that is not a security or management tool holding lsass.exe open with the right to read its memory.Where it shows: windows.handles, or Handle with every type and the granted access. For an open since closed, Sysmon event 10 or Open
Process Api Call. - A Process handle with rights to write another process's memory and start threads in it, as updsvc64.exe holds into ws-042's spooler.Where it shows: windows.handles' GrantedAccess, Handle with the granted access, or Process Explorer's handle view.
- A named pipe matching a remote execution tool's default, on a host where that tool has no business.Where it shows: File handles under \
Device\ Named Pipe in windows.handles, PipeList, or Sysmon events 17 and 18 where Sysmon runs. - A named mutex made to mark a machine as already reached, so a second copy exits.Where it shows: windows.
mutantscan in a memory image, or Windows. Detection. Mutants live. - An archive growing in Temp or a user folder, held open by a process with no reason to write archives.Where it shows: File handles in windows.handles or Handle, and the file itself, written out with windows.
dumpfiles.
Live and in Memory
Each question has the tools that answer it on a running machine, and in a memory image, a copy of its memory saved to a file.
Live tools and windows.handles list the handles a process has open at that moment, with the access each grants. A process holding lsass.exe open with the right to read its memory stands out. A handle closed a second earlier leaves nothing, so pair them with Sysmon event 10 and Defender's OpenProcessApiCall, which record opens as they happen.
Which processes hold another process open, lsass.exe above all, and with what access?
On a Running Machine
- Handle (documentation, opens in a new tab)Live Machine A free Microsoft tool that lists the handles each process holds open. Lists every process's open handles, files by default and every type when asked, with the access each grants when asked for that too. It needs admin rights.
- Process Explorer (documentation, opens in a new tab)Live Machine A free Microsoft tool that works like a detailed Task Manager. It shows each process under the one that started it, with its DLLs and handles. Its handle view lists what the selected process holds open, and its search finds which processes hold a named object.
In a Memory Image
windows.handles(documentation, opens in a new tab)Memory Image A Volatility 3 plugin. It is one check run on a saved copy of a Windows machine's memory. Each process's handles at the moment of capture, with type, name and granted access. Read the Process handles that name lsass.exe.
Who opened lsass.exe earlier, before anyone looked?
On a Running Machine
Open(documentation, opens in a new tab)Logs and Records A Defender XDR action type, which is one kind of event Defender for Endpoint records in its DeviceEvents table. Defender's record of a process opening another, lsass.exe included, with the access it asked for in AdditionalFields.Process Api Call Asr(documentation, opens in a new tab)Logs and Records A Defender XDR action type, which is one kind of event Defender for Endpoint records in its DeviceEvents table. The ASR rule that locks down lsass.exe, in audit or block mode, recording the process that reached for it.Lsass Credential Theft Audited, Asr Lsass Credential Theft Blocked
In a Memory Image
windows.handles(documentation, opens in a new tab)Memory Image A Volatility 3 plugin. It is one check run on a saved copy of a Windows machine's memory. Only handles still open at capture, so an open that was closed again leaves nothing here.
Which named pipes and mutexes does a process hold, and do their names point to a tool?
On a Running Machine
- Handle (documentation, opens in a new tab)Live Machine A free Microsoft tool that lists the handles each process holds open. With every handle type shown, the named pipes and mutexes a process holds, by name.
Windows.(documentation, opens in a new tab)Live Machine A Velociraptor artifact. It is a ready-made question Velociraptor asks of running machines, named from general to specific. File and Section handles of matching processes across many machines by default, and registry keys when asked. Named pipes show among the files.System. Handles Windows.(documentation, opens in a new tab)Live Machine A Velociraptor artifact. It is a ready-made question Velociraptor asks of running machines, named from general to specific. Named mutexes held by chosen processes, across many machines.Detection. Mutants
In a Memory Image
windows.handles(documentation, opens in a new tab)Memory Image A Volatility 3 plugin. It is one check run on a saved copy of a Windows machine's memory. File handles under \Device\NamedPipe are named pipes, and Mutant handles are mutexes.windows.(documentation, opens in a new tab)Memory Image A Volatility 3 plugin. It is one check run on a saved copy of a Windows machine's memory. Mutex objects found by scanning memory, with their names.mutantscan
A handle list shows only what is open now. These records keep each open and each pipe as it happened, where they are switched on.
Records of one process opening another, and of named pipes
| Record | Fields to Read | What It Tells You |
|---|---|---|
| Sysmon event 10 | Source | Which process opened which, and the access it was granted as a mask of Microsoft's process access rights. One that includes PROCESS_VM_READ (0x0010) can read the target's memory |
| Open | Initiating | Defender's record of one process opening another, with the access asked for in AdditionalFields |
| Sysmon events 17 and 18 | Pipe | A named pipe created (17) and a connection to one (18), with the process at that end |
What It Misses
Every way of looking has gaps, so cover these from another source.
- Handles show only what is open at that moment. An open of lsass.exe that was closed again leaves nothing in a live view or a memory image, so read Sysmon event 10 or Defender's records of opens for it.
- Sysmon event 10 records only the opens its configuration asks for, since logging them all is noisy, so check that it covers lsass.exe.
False Positives
These look odd but are normal, so rule them out before you act.
- Security products, Windows itself and many other programs open lsass.exe and other processes, so judge the opener's path, signer and the access it was granted.
- Diagnostic and monitoring tools open other processes again and again to query their state. Filter out the opens you expect, as Sysmon's own page advises, and read what is left.
Red Flags It Explains
Each red flag below is confirmed by reading this part.
- Extra or Missing Instances For a second lsass.exe, find what opened the original. Sysmon event 10 in Microsoft-Windows-Sysmon/Operational, where its configuration logs process access, and Defender's OpenProcessApiCall rows in DeviceEvents name the process that asked.
- Remote Thread Injection Find who holds the process open with the rights to write its memory and start threads. In memory, windows.handles lists that Process handle, and live, Handle lists it with every handle type and the granted access shown. Where Sysmon runs, event 10 records the open.
- Parent Process Spoofing Look for the creator opening the named parent just before, in Sysmon event 10 where Sysmon runs, with GrantedAccess that includes PROCESS_CREATE_PROCESS (0x0080).
- Abused Built-In and Admin Tools For PSEXESVC.exe, list its handles. Handle or Process Explorer live, or windows.handles in memory, shows PsExec's default pipe, \PSEXESVC. Then read System event 7045 for the service install and, where Sysmon runs, event 17 for the pipe, and find the account and machine that drove it.
Checks That Use It
These checks read this part as one of their steps.
Hunt It
The same hunt is written for four tools, so pick the one you use. Defender XDR and Sentinel queries are in KQL, which you paste into Advanced hunting in the Defender portal or into Sentinel's Logs page. Splunk queries are in SPL, for its Search page, and Velociraptor queries are in VQL, which you run as a hunt.
Needs Defender for Endpoint. Microsoft lists DeviceEvents action types only in the portal, so confirm OpenProcessApiCall with DeviceEvents | distinct ActionType, and do not read an empty result as proof that nothing opened lsass.exe. Security products and many other programs open it too, so rare openers come first, and an open does not show what was read.
// Processes that opened a handle to lsass.exe, with the access they asked for, rarest firstDeviceEvents| where Timestamp > ago( 30d)| where ActionType == "OpenProcessApiCall" and FileName =~ "lsass.exe"| extend DesiredAccess = strcat( "0x", tohex( tolong( parse_json( AdditionalFields).DesiredAccess)))| summarize Devices = dcount( DeviceId), Opens = count( ), Accesses = make_set( DesiredAccess, 10), FirstSeen = min( Timestamp), LastSeen = max( Timestamp) by InitiatingProcessFileName, InitiatingProcessFolderPath| order by Devices asc, Opens ascSources
- Microsoft Sysinternals: Handle (opens in a new tab)
- Microsoft Sysinternals: Process Explorer (opens in a new tab)
- Microsoft Sysinternals: Sysmon (opens in a new tab)
- Microsoft Learn: process security and access rights (opens in a new tab)
- Microsoft Learn: handles and objects (opens in a new tab)
- Microsoft Learn: !handle debugger extension (opens in a new tab)
- Microsoft Learn: named pipes (opens in a new tab)
- Microsoft Learn: mutex objects (opens in a new tab)
- Microsoft Learn: section objects and views (opens in a new tab)
- Microsoft Learn: event 4656, a handle to an object was requested (opens in a new tab)
- Microsoft Sysinternals: PipeList (opens in a new tab)
- Microsoft Sysinternals: PsExec (opens in a new tab)
- SigmaHQ: PsExec Tool Execution From Suspicious Locations, PipeName (opens in a new tab)
- Microsoft Learn: DeviceEvents table (opens in a new tab)
- Microsoft Learn: attack surface reduction rules reference (opens in a new tab)
- FalconForce FalconFriday: LSASS Dumping using Debug Privileges (opens in a new tab)
- Velociraptor: Windows.System.Handles (opens in a new tab)
- Velociraptor VQL reference: handles (opens in a new tab)
- Velociraptor: Windows.Detection.Mutants (opens in a new tab)
- Volatility 3: windows.handles (opens in a new tab)
- Volatility 3 source: handles.py (opens in a new tab)
- Volatility 3: windows.mutantscan (opens in a new tab)
- Volatility 3 source: dumpfiles.py (opens in a new tab)
- Velociraptor: Windows.Events.Mutants (opens in a new tab)
- SigmaHQ: Potentially Suspicious GrantedAccess Flags On LSASS (opens in a new tab)
MITRE ATT&CK is a free public catalogue of the techniques attackers use. Each technique has an ID, such as T1055 for Process Injection, so defenders can name the same behaviour the same way. Reading this part helps find these techniques.
- T1003.001 (opens in a new tab) OS Credential Dumping: LSASS Memory
- T1055 (opens in a new tab) Process Injection
- T1569.002 (opens in a new tab) System Services: Service Execution
- T1021.002 (opens in a new tab) Remote Services: SMB/Windows Admin Shares
- T1480.002 (opens in a new tab) Execution Guardrails: Mutual Exclusion
- T1074.001 (opens in a new tab) Data Staged: Local Data Staging