mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
Cisco Secure Endpoint alarms about access to lsass.exe #461
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SergeyYmb on GitHub (Sep 4, 2024).
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 --whkdwas 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 commented on GitHub (Sep 4, 2024):
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 commented on GitHub (Sep 5, 2024):
@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:
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 commented on GitHub (Sep 5, 2024):
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 commented on GitHub (Sep 7, 2024):
@LGUG2Z ,
I've found the root cause of the issue!
The problem is not in komorebi.exe, it's in
komorebic.exe startcommand.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 commented on GitHub (Sep 7, 2024):
Thank you for this deep dive @SergeyYmb!
The code for the
startcommand is here:c06d9afa3b/komorebic/src/main.rs (L1882)Is there a way that we can pass a flag to the PowerShell command to explicitly never set
SeDebugPrivilege? 🤔@LGUG2Z commented on GitHub (Sep 7, 2024):
Did a quick search and this might be relevant? https://github.com/PowerShell/PowerShell/issues/15562
@SergeyYmb commented on GitHub (Sep 8, 2024):
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 SeDebugPrivilegeFrom 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.
@LGUG2Z commented on GitHub (Jan 23, 2025):
If you're interested you can now manage komorebi and other processes with wpm. There are no plans to remove or change the PowerShell-based
komorebic startcommand due to its widespread adoption.