itm4n/PrivescCheck

[Feature Request] Readd Compliance Field

dxxzero opened this issue · 4 comments

Hi!

Would it be possible to readd the "Compliance" field within the XML output?
On a previous version it was like this:

  <Object Type="System.Management.Automation.PSCustomObject">
    <Property Name="Id" Type="System.String">HARDEN_BITLOCKER</Property>
    <Property Name="Category" Type="System.String">Hardening</Property>
    <Property Name="DisplayName" Type="System.String">BitLocker</Property>
    <Property Name="Description" Type="System.String">Check whether BitLocker is configured and enabled on the system drive. Note that this check will yield a false positive if another encryption software is in use.</Property>
    <Property Name="Type" Type="System.String">Info</Property>
    <Property Name="Compliance" Type="System.Boolean">False</Property>
    <Property Name="Severity" Type="System.String">None</Property>
    <Property Name="ResultRawString" Type="System.String">

Now the Compliance field is missing:

  <Object Type="System.Management.Automation.PSCustomObject">
    <Property Name="Id" Type="System.String">HARDEN_BITLOCKER</Property>
    <Property Name="Category" Type="System.String">TA0001 - Initial Access</Property>
    <Property Name="DisplayName" Type="System.String">BitLocker configuration</Property>
    <Property Name="Description" Type="System.String">Check whether BitLocker is enabled on the system drive and requires a second factor of authentication (PIN or startup key). Note that this check might yield a false positive if a third-party drive encryption software is installed.</Property>
    <Property Name="Severity" Type="System.String">Medium</Property>
    <Property Name="ResultRawString" Type="System.String">
itm4n commented

Hello,

This change was intentional. This "compliance" thing was redundant with the severity level, so I got rid of it.

Rather than setting the severity to "none", and the "compliance" to "true" or "false", I decided to set the severity to "none" or "low/medium/high", depending on the nature of the finding. Treating checks as "compliance" or "vulnerability" checks added unnecessary complexity to the code.

So, basically, these are almost equivalent:

  • Compliance=false + Severity=None <=> Severity=Low or Medium or High
  • Compliance=true + Severity=None <=> Severity=None

I am sorry if this broke your parser, but I thought about this change for some time, and it is certainly a better decision for me as it reduces the code maintenance cost on the long term.

No worries, I just needed a way to determine if a check passed or if the host is vulnerable.

So as long as the Severity is not None the host should be vulnerable to some kind of check, right?

itm4n commented

Correct. That should be even easier to parse actually.

  • Severity = "None" => Info, or host not vulnerable
  • Severity = "Low/Medium/High" => Host is vulnerable

Thanks!