Skip to main content

Hey all,

We’ve been looking for a way to effectively audit what privileges are used by a user or application with an elevated token from EPM in order to better scope our custom tokens.  We have enabled privilege monitoring within our policies, but it doesn’t look like that generates information (or maybe it does, but it’s not aggregated anywhere).

 

The closest we’ve gotten is looking at the audit logs in ‘C:\ProgramData\Avecto\Privilege Guard Audit Logs\’.  This directory houses XML files which seem to contain some information about what happened when using an elevated token. Here are two samples:

<AuditLog>

    <Application Type="exe" FileName="c:\windows\system32\dllhost.exe" CmdLine="C:\WINDOWS\system32\DllHost.exe /Processid:{1F2E5C40-9550-11CE-99D2-00AA006E086C}" Description="COM Surrogate" FileHash="C521025C55687C1F29B1F3A3C69B3D152CE84981" Certificate="Microsoft Windows" />

    <AuditRecords>

        <AuditRecord Time="07/11/24 17:10:43" Type="EnablePrivilege" Privilege="SeSecurityPrivilege" />

        <AuditRecord Time="07/11/24 17:10:43" Type="EnablePrivilege" Privilege="SeTakeOwnershipPrivilege" />

        <AuditRecord Time="07/11/24 17:10:43" Type="EnablePrivilege" Privilege="SeBackupPrivilege" />

        <AuditRecord Time="07/11/24 17:10:43" Type="EnablePrivilege" Privilege="SeBackupPrivilege" />

    </AuditRecords>

</AuditLog>

 

 

<AuditLog>

    <Application Type="exe" FileName="c:\program files\powershell\7\pwsh.exe" CmdLine=""C:\Program Files\PowerShell\7\pwsh.exe&quot;" Description="pwsh" FileHash="97FCEC1C423CE4A2183A0115511A1AB8CF9417B1" Certificate="Microsoft Corporation" />

    <AuditRecords>

        <AuditRecord Time="07/11/24 16:41:19" Type="CreateFile" File="\Device\HarddiskVolume3\Windows\Temp\__PSScriptPolicyTest_gdlfm1bw.c2c.ps1" Mask="1074921600" />

        <AuditRecord Time="07/11/24 16:41:19" Type="CreateFile" File="\Device\HarddiskVolume3\Windows\Temp\__PSScriptPolicyTest_j2o1i3zo.om1.psm1" Mask="1074921600" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenFile" File="\Device\HarddiskVolume3\Windows\Temp\__PSScriptPolicyTest_gdlfm1bw.c2c.ps1" Mask="-2146303872" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenFile" File="\Device\HarddiskVolume3\Windows\Temp\__PSScriptPolicyTest_gdlfm1bw.c2c.ps1" Mask="1179776" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenFile" File="\Device\HarddiskVolume3\Windows\Temp\__PSScriptPolicyTest_gdlfm1bw.c2c.ps1" Mask="1179776" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenFile" File="\Device\HarddiskVolume3\Windows\Temp\__PSScriptPolicyTest_gdlfm1bw.c2c.ps1" Mask="1179776" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenFile" File="\Device\HarddiskVolume3\Windows\Temp" Mask="1179776" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenFile" File="\Device\HarddiskVolume3\Windows\Temp" Mask="1179776" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenFile" File="\Device\HarddiskVolume3\Windows\Temp" Mask="1179776" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenFile" File="\Device\HarddiskVolume3\Windows\Temp" Mask="1179776" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenFile" File="\Device\HarddiskVolume3\Windows\Temp\__PSScriptPolicyTest_gdlfm1bw.c2c.ps1" Mask="196736" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenFile" File="\Device\HarddiskVolume3\Windows\Temp\__PSScriptPolicyTest_j2o1i3zo.om1.psm1" Mask="196736" />

        <AuditRecord Time="07/11/24 16:41:19" Type="EnablePrivilege" Privilege="SeDebugPrivilege" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenKey" Key="\REGISTRY\USER\.DEFAULT" SubKey="Software\Microsoft\SystemCertificates\CA" Mask="196639" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenKey" Key="\REGISTRY\USER\.DEFAULT" SubKey="Software\Microsoft\SystemCertificates\CA" Mask="196639" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenKey" Key="\REGISTRY\USER\.DEFAULT\Software\Microsoft\SystemCertificates\CA" SubKey="Certificates" Mask="196639" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenKey" Key="\REGISTRY\USER\.DEFAULT\Software\Microsoft\SystemCertificates\CA" SubKey="CRLs" Mask="196639" />

        <AuditRecord Time="07/11/24 16:41:19" Type="OpenKey" Key="\REGISTRY\USER\.DEFAULT\Software\Microsoft\SystemCertificates\CA" SubKey="CTLs" Mask="196639" />

    </AuditRecords>

</AuditLog>

 

These files would work for our use case, but most of them are incomplete or invalid XMLs making them difficult to process.  Does anyone do anything similar to audit what privileges are being used in their tokens or have any ideas on how we could leverage this?

Privilege Monitoring is kind of legacy; it was used prior to the Quick Start policy to determine if applications required admin rights, etc. The Admin Guide does contain some information that might come in handy for this part (see Page 71 of the Privilege Management for Windows 24.6 Administration Guide

It is meant for monitoring administrators with the Discovery Workstyle and capturing the detailed information for policy design.

For testing and validation, I recommend getting the EPM Client Executable from the support portal along with the GPO Policy Editor, which is end-of-life (EOL). Here, you might be able to increase the level of auditing and get more details more easily.

You can ask support for information on how to set up a client with local policy. I remember creating a guide for that, which might still exist. Again, this is legacy, and you can likely monitor this with Procmon. I don’t see the option available in the WebPolicy Editor to increase the application activity.

If you want to deal with custom tokens, privileges, process access rights, etc., you are going down a difficult path for many to navigate and keep up with. Integrity is straightforward but powerful alone.

I do disagree with the need for a full admin token for installers. In many cases, a basic admin token with medium integrity and stripped debugging would suffice.


Thanks for the response.  Even before this was EOL there were issues with this feature.  We’ve set up that reporting in the past and ended up removing it because it simply didn’t work.  It sounds to me like there might not be a way to do this with EPM itself.


Thanks for the response.  Even before this was EOL there were issues with this feature.  We’ve set up that reporting in the past and ended up removing it because it simply didn’t work.  It sounds to me like there might not be a way to do this with EPM itself.

Correct, ever since the QuickStart policy got created this has become a legacy function. It expects the user having local Admin with the discovery workstyle and privilege monitoring turned on for capturing the privileges, But I don’t ever think it was intended to that level of detail.


Thanks for the response.  Even before this was EOL there were issues with this feature.  We’ve set up that reporting in the past and ended up removing it because it simply didn’t work.  It sounds to me like there might not be a way to do this with EPM itself.

Hello Zach - This may not be the answer you want, but I believe our new Insights Product can do what  you were after: https://www.beyondtrust.com/products/identity-security-insights.


Hello Zach - This may not be the answer you want, but I believe our new Insights Product can do what  you were after: https://www.beyondtrust.com/products/identity-security-insights.

 

We looked into insights and it didn’t seem to have what we were after.  It sounds like we may just need to do this out of band of beyond trust if it isn’t supported.


Thanks for the response.  Even before this was EOL there were issues with this feature.  We’ve set up that reporting in the past and ended up removing it because it simply didn’t work.  It sounds to me like there might not be a way to do this with EPM itself.

Hello Zach - This may not be the answer you want, but I believe our new Insights Product can do what  you were after: https://www.beyondtrust.com/products/identity-security-insights.

Not currently possible, as the information is not even collected on the Endpoint from the EPM client, which is what the Identity insights rely on to get its information.


Reply