Skip to main content

Hi All,
I am trying to get more details on how EPM handles the privileges ( there are few helpful KB articles. Thanks BT team).

Q.1 How the agent assigns elevated token? Is there a local admin user created by EPM or the defendpoint service assigns the elevated tokens to processes when requested.

Q.2 How the  OS log ( and SIEM log monitoring will be affected) . In Widows Event Viewer I see two additional events per elevated action e.g. if I run an installer that needs elevated right I see
1. ID 4688 The standard user account as subject who ran installer with elevated token.
     I also see two additional EPM events -
2. ID 4688 - Create process “PGMessageHostExt.exe” by creator “ DefendpointService.exe”
3. ID 4733 Primary token assigned by DefendpointService.exe to the installer service. Token has standard user.
I think event number 1 stays as is (with EPM / without EPM while user is local admin)

Q3. How AV scanning is affected. 
As AV typically works at kernel level will it get priority in hooking and if the file is blocked it will never come to EPM

#1 How the agent assigns elevated token?

The EPM-W agent (DefendpointService) assigns elevated tokens to processes when configured to do so via policy rules. This agent runs at SYSTEM level and has the necessary privileges to create and assign tokens.

 

#2 How the  OS log ( and SIEM log monitoring will be affected?

The security auditing events raised are dependent on policy configuration.

When a process is allowed to run a 4688 event is expected for the process itself, this is expected without EPM-W in use as you identified. If the policy rule has a message configured then another 4688 event would be expected for "PGMessageHostExe.exe" (as you identified). There are other processes that EPM-W may launch that would trigger a 4688 event but they are much less likely than PGMessageHostExe.exe.

When EPM-W assigns a token to a process (e.g. applying "Add Admin Rights") I believe a 4696 event would be expected. As I understand it, event 4733 which you mentioned is related to when a user was removed from a local group and not something I’d expect EPM-W to trigger outside of the JIT Admin feature.

For reference, here are the links to the events discussed:
ID 4688 is raised for new process creations.
ID 4696 is raised when a primary token is assigned to a process.
ID 4733 is raised when a member was removed from a security-enabled local group.

 

#3 How AV scanning is affected.

EPM-W also utilises a kernel driver to be informed of process creations, similar to most AV vendors. To my understanding, the priority order for the OS to notify drivers of new processes is entirely dependent on the order in which those drivers registered themselves for notifications; i.e. the driver who registers for notifications first will be notified first.

When a driver blocks a process from starting any other driver that has not yet received the notification will not be informed about the process creation. So, in your example, if an AV driver registered for process notifications earlier than EPM-W then, yes, the AV driver would be able to block a process and EPM-W would not be aware; the vice-versa would also be true.


Hi ​@AdamS Thank you so much for your response. 
You are correct , I put 4733 by mistake instead of ID 4696 in Q2. point 3 - Primary token assigned to app process.
 


Microsoft assigns Altitude to drivers and that determines the load order and who have first priority.

Which is why there is always a recommendation to create exclusions from one another.
There is a nice KB with regards to AV 3rd party exclusions I created back in the days working for BT.
it does need an update for the Package Manager.
https://beyondtrustcorp.service-now.com/csm?id=kb_article_view&sysparm_article=KB0017099

Driver Altitude MS KB

https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes

 


Thank you so much ​@Jens Hansen  You are awesome!!


Reply