Cisco Secure Endpoint alarms about access to lsass.exe

[SergeyYmb]

Cisco Secure Endpoint alarms about access to Local Security Authority Subsystem (lsass.exe)

System process protection was triggered by C:\Program Files\komorebi\bin\komorebi.exe (PID 11124) attempting to access C:\Windows\System32\lsass.exe (PID 1184) (SD.Block.SPP). The action was blocked.

Please, see more details about Cisco System Process Protection option here:
https://docs.amp.cisco.com/en/SecureEndpoint/Secure%20Endpoint%20User%20Guide.pdf

Steps to reproduce the behavior:
The alarm seems appears on start of komorebi.
komorebic start --whkd was run by windows scheduler task with options "Run only when user is logged on" and "Run with highest privileges".

OS Name: Microsoft Windows 11 Pro

Additional info:
I've tried to analyze the code to find which action could trigger such alarm.
I found that komorebi.exe calls OpenProcess WinAPI function with PROCESS_QUERY_INFORMATION
(komorebi\src\windows_api.rs, line 730).
Seems it's better call OpenProcess function with PROCESS_QUERY_LIMITED_INFORMATION desired access if process handle is only need for following call of QueryFullProcessImageName function.
See this description https://learn.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights#protected-processes

I also added some additional logging and found that sometimes OpenProcess is called with PID=0.

I've tried to rebuild komorebi with option PROCESS_QUERY_LIMITED_INFORMATION, but unfortunately this was not help to avoid new alarm from Cisco.

I don't know how to classify this issue (bug or not), but it's definitely disallow usage of the application in my case.

[LGUG2Z]

Pretty good chance that this is a false positive from Cisco, but just in case I think we can probably introduce a global blacklist of executables against which no Win32 API calls are ever made by komorebi.

Edit: Actually we can't do that because we need to call OpenProcess to get the Exe to filter against 😅

Your best bet is to take this up with Cisco as this is most likely a bug with their software and not with komorebi, which only interacts with other processes through the publicly available Win32 APIs, and only does so to look up executable names and paths.

[SergeyYmb]

@LGUG2Z , thank you for quick respond.

The idea with blacklist of system protected processes sounds very good.
I see it will require some refactoring in architecture because there are many places in code where WindowsApi functions are calling by komorebi.

I've added tracing names of accessing widows/processes in various places of komorebi code.
I've not yet reproduced access directly to lsass.exe.
But my test with starting of admin console (with enabled UAC) has shown access to C:\Windows\System32\csrss.exe,
which is also from the list of Cisco Protected System Processes:

Session Manager Subsystem (smss.exe)
Client/Server Runtime Subsystem (csrss.exe)
Local Security Authority Subsystem (lsass.exe)
Windows Logon Application (winlogon.exe)
Windows Start-up Application (wininit.exe)

Off cause I can miss some places in the codebase of komorebi, the project is new for me and I'm not familiar with Rust (I'm from C++ world).

PS:
Call of OpenProcess function with PROCESS_QUERY_INFORMATION flag fails for protected system processes, so need to change the flag to PROCESS_QUERY_LIMITED_INFORMATION to show the process names.

[SergeyYmb]

Update:
My additional logging shown that csrss.exe window seems appears in komorebi when I'm starting Windows Task Scheduler (I've also opened and edited scheduled task during the test).
The window comes from win_event_hook function in komorebi\src\windows_callbacks.rs.
Later in logs I've found that WindowsApi::raise_and_focus_window was called for window of csrss.exe process.
I hope my investigation could be helpful.

[SergeyYmb]

@LGUG2Z ,
I've found the root cause of the issue!

The problem is not in komorebi.exe, it's in komorebic.exe start command.
When the command runs with administrative priviledges, it starts komorebi process with enabling SeDebugPrivilege.

This privilege provides complete access to sensitive and critical operating system components.
None of antiviruses will happy with such option.
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debug-privilege.

The privilege can be shown for running process for example by using Process Explorer https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer.
(Right-click on komorebi.exe process and select Properties then switch to Security tab)

When I run komorebi.exe directly, it runs without enabling SeDebugPrivilege and Cisco do not alarm about access to lsass.exe process.

Of course, it's better to not run komorebi.exe with administrative rights at all, but in this case it loose part of functionality when I often need to work with administrative windows.

[LGUG2Z]

Thank you for this deep dive @SergeyYmb!

The code for the start command is here:

komorebi/komorebic/src/main.rs

Line 1882 in c06d9af

let script = if flags.is_empty() {

Is there a way that we can pass a flag to the PowerShell command to explicitly never set SeDebugPrivilege? 🤔

[LGUG2Z]

Did a quick search and this might be relevant? PowerShell/PowerShell#15562

[SergeyYmb]

Is there a way that we can pass a flag to the PowerShell command to explicitly never set SeDebugPrivilege? 🤔

If the question is addressed to me, I'm not an expert in PowerShell.
Quick search shows that SeDebugPrivilege is raised by powershell itself and then just inherited by the child process.
https://www.leeholmes.com/why-is-sedebugprivilege-enabled-in-powershell/

There are methods which allows to disable these privileges inside of powershell script.
https://github.com/jborean93/PSPrivilege/blob/main/docs/en-US/Disable-ProcessPrivilege.md
Disable-ProcessPrivilege -Name SeDebugPrivilege

From another side, involving of powershell to just spawning a process seems unnecessary.
I would suggest to consider replacing of powershell call by some native method, either provided by Rust or WinAPI libraries.