Je vois bien apparaître "Presence of Windows 2008" dans la beta, par contre il n'y a pas d'alerte pour les Windows 7.

Hello,
There is a typo in the section header for this rule (the clickable hyperlink to expand/collapse the section).

"At least one privileged group can be reavealed on RODC"
reavealed -> revealed

Keep up the excellent work.

The "Foreign domain involved" table in the "Control path analysis" seems malformed in my case:

Datatable doesn't like it and it triggers an error which prevents Datatable from being applied to remaining tables :(

Uncaught TypeError: Cannot set property '3' of undefined

I'd like to suggest a PR but I'm not really sure how this table should look like (I noticed that rowspan is used)

Hello,

We have been using Pingcastle in our environment, but lately, we are getting an error when trying to consolidate the data. The error we get is 'Exception: Object reference not set to an instance of an object.' The complete error is below:

[12:56:28 PM] An exception occured when doing the task: PingCastle report consolidation (HealthcheckData)
Note: you can run the program with the switch --log to get more detail
Exception: Object reference not set to an instance of an object.
at PingCastle.Healthcheck.HealthcheckAccountData.Add(HealthcheckAccountData x) in c:\git\PingCastle\Data\HealthcheckData.cs:line 305
at PingCastle.Report.ReportHealthCheckConsolidation.GenerateUserInformation() in c:\git\PingCastle\Report\ReportHealthCheckConsolidation.cs:line 349
at PingCastle.Report.ReportBase.GenerateSectionFluid(String title, GenerateContentDelegate generateContent, String selectedTab, Boolean defaultIfTabEmpty) in c:\git\PingCastle\Report\ReportBase.cs:line 710
at PingCastle.Report.ReportHealthCheckConsolidation.GenerateContent(String selectedTab) in c:\git\PingCastle\Report\ReportHealthCheckConsolidation.cs:line 128
at PingCastle.Report.ReportHealthCheckConsolidation.GenerateBodyInformation() in c:\git\PingCastle\Report\ReportHealthCheckConsolidation.cs:line 94
at PingCastle.Report.ReportBase.GenerateReportFile(String filename) in c:\git\PingCastle\Report\ReportBase.cs:line 61
at PingCastle.Tasks.b__13T in c:\git\PingCastle\Tasks.cs:line 417
at PingCastle.Tasks.StartTask(String taskname, TaskDelegate taskdelegate) in c:\git\PingCastle\Tasks.cs:line 787

We also made use of the matrix xlsx file, which I dont seem to be able to generate (even if it works) without the PingcastleReporting executable from version 2.7. How can I generate this file using the new version 2.8.1?

Thank you

Hello,
i do compile pingcastle from source, everything is fine with this output:
2> PingCastleAutoUpdater -> C:\temp\pingcastle\bin\Debug\PingCastleAutoUpdater.exe
1> PingCastle -> C:\temp\pingcastle\bin\Debug\PingCastle.exe

but i dont see anymore the pingcastlereport.exe like the previuos release (2.7.1.1) in order to build ppt report.
i miss something ?

using vstudio2019 enterprise edition, but even downloading the release from github that section is missing.
i just found it on the rel 2.7.1.1

thanks

Hello,
what is "Check the process of registration of computers to the domain" actually verifying?

according to best practices we have our default domain controllers policy unmodified, so it reads

Add workstations to domain | NT AUTHORITY\Authenticated Users

to harden this setting, we have create a new GPO, linked to Domain Controllers OU, higher precedence than the DDCP, and it contains:

Add workstations to domain | BUILTIN\Administrators

so the pingcastle report should not flag this finding, but it does. is this a false positive?

Is the ''--graph" command line deprecated in v2.8.1? It seems to work in v2.7 but getting error - "unknown argument: --graph" error when using the following:

PingCastle.exe --graph --server mydomain.com

LAPS passwords are protected by ACLs which are sometimes misconfigured thus allowing everyone (or too many people) to read them!
I suggest adding a check for this. For example by searching for:

(ms-mcs-admpwd=*)

Of course it's not ideal as it relies on the fact that the current user doesn't have legitimate access (false positive, maybe add a note in the vulnerability description), and that the current user is in the "too many people" group (risk of false negatives). But that should help catch some obvious cases!

I think the following references are unrelated to LDAP signing:

Hello, I wanted to say I love this program. I ran a scan and it's reporting that I have an Intermediate certificate using SHA1. It was found in GPO NTLMStore. I have looked everywhere on all of my servers and I cannot find it. I am hoping you can explain what/where the GPO NTLMStore is. Or am I getting a false positive?

It's not possible to use the domain FQDN (e.g. corp.domain.com) to establish a connection to a DC in environments where NTLM authentication is blocked. PingCastle uses the domain FQDN as the default unless a DC has been explicitly specified. The problem appears to be two-fold:

ADWS connection
PingCastle first attempts to connect to a DC via ADWS using Negotiate authentication. Kerberos authentication fails as the provided SPN is the IP address of the target DC (e.g. host/1.2.3.4). I'm guessing this is determined by a (probably cached) A record DNS query for the domain FQDN. SPNs for the IP address(es) of DCs are not registered by default and so the DC's computer account is not mapped to the SPN. NTLM authentication is subsequently tried but fails as expected. The process appears to repeat for each DC in the domain, but I've only tested this against a domain with two DCs so there may be a maximum number of attempts I haven't witnessed.

It's possible this could be handled by performing a reverse DNS query for the IP address being connected to and using the result to construct the SPN for the Kerberos request. This may work in environments with appropriately configured DNS reverse lookup zones.

LDAP connection
After the ADWS connection attempt(s) fail LDAP is attempted. This also fails but in a different way. As with ADWS the Negotiate protocol is used but the Kerberos SPN takes the form of host/fqdn (e.g. host/corp.domain.com). This is also an invalid SPN as DCs do not register an SPN for the FQDN of their domain, presumably because it would result in duplicate SPNs for any domain with >1 DC.

The LDAP connection is only attempted once and I'm unsure how the target DC is selected (first A record returned by DNS query or maybe the IP address of the local system's logon server?). When the Kerberos authentication fails NTLM is attempted but fails as expected.

I'm unsure if there's a simple approach to workaround this as I don't have a suitable environment available where I can easily decrypt the signed LDAP messages. The initial unauthenticated bind to the domain's root DSE works, and there's a bunch of LDAP traffic leading up to the failed GSSAPI LDAP bind.

Notes
This is admittedly probably an edge-case as I expect the vast majority of domains do not disable NTLM authentication. But it occurs to me that this means when using the domain FQDN it will only work if NTLM is allowed. Kerberos is presumably always tried, but always fails, as the SPNs used are never valid except in unusual configurations where the required SPNs have been manually added.

The new audit policy configuration check appears to be a little buggy. I'm frequently seeing numerous audit policies being flagged as missing in the Check if there is the expected audit policy on domain controllers check. However, they're definitely applied (verified by auditpol /get /category:*) and PingCastle does successfully discover all the audit policies defined in GPOs as they're listed in the Audit Settings summary later in the report.

I suspect PingCastle might be failing to factor in merging of advanced audit policies across multiple GPOs? All testing performed with PingCastle v2.8.1.0. And as always, keep up the great work :-)

The v2.9.0.0 Beta is returning an incorrect result for the Max Password Age of some Fine-Grained Password Policies. When no maximum password age is configured for an FGPP the report shows the Maximum Password Age as 10675199 day(s) instead of the expected Never expires (correctly displayed when configured as such in the Default Domain Policy).

If helpful the relevant attributes as shown in ADSI Edit for the affected msDS-PasswordSettings object are:

• msDS-MinimumPasswordAge : (none)
• msDS-MaximumPasswordAge : (never)

The changelog for the v2.9.0.0 Beta states the krbtgt account password rotation check has been updated to trigger only after a year but generated reports still reference 40 days:
The password of the krbtgt account should be changed twice every 40 days using this script

It's not clear if this is intentional or an oversight. If intentional, the wording could be tweaked to make it clear this is a recommendation but not a vulnerability and will only be flagged after 1 year without rotation.

The v2.9.0.0 Beta flags some issues with audit policy on DCs which are questionable:

Account Logon / Other Account Logon Events
The referenced event is captured by success events from the Audit Logon/Logoff -> Audit Logon sub-category. Microsoft's documentation states the Account Logon -> Audit Other Account Logon Events sub-category doesn't presently log any events.

Audit policy change
The referenced event is captured by success events from the Policy Change -> Audit Audit Policy Change advanced audit policy sub-category. It's correct that the policy is not set, but it's also redundant when the corresponding advanced audit policy sub-category is enabled, so shouldn't be a detection?

Audit object access
The referenced events are captured by by success events from the Object Access -> Audit Other Object Access Events advanced audit policy sub-category. Same general issue as the Audit policy change detection above.

I've just faced the following case:

A couple of groups have Generic All rights over an OU that contains a privileged User. This user is protected by AdminSDHolder so these rights are removed from the object.

However, PingCastle doesn't seem to have this into account and still shows this as a valid and existing path?

Pingcastle flags a missing audit policy setting for event id 4908

Audit Policy Change | No GPO check for audit success | Collect event 4908, to track special groups such as "administrators"

in our GPO -> advanced audit policy -> policy change -> audit audit policy change is set to successs

auditpol.exe /get /category:* reports
Policy Change
Audit Policy Change Success

https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4908 says "This event is always logged regardless of the "Audit Policy Change" sub-category setting."

the same is true for

Audit object access | No GPO check for audit success | Collect event 4698, 4699, 4702 to track schedule tasks lifecycle

in gpo we have "audit other object access events" set to "success"
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698
auditpol.exe /get /category:* reports
Object Access
Other Object Access Events Success

what am i missing?
all other audit settings report correctly and do not get flagged in pingcastle (2.8.1.0)

In the description of Obsolete OS (Windows 7) you talk about Vista instead of Win7:

Description:
The purpose is to ensure that there is no use of the obsolete and vulnerable OS Windows Vista for the workstations within the domain

There is a small bug where the help output says the default number of users for null session enumeration is 5, but it is actually int.MaxValue.

Help Output:

--nslimit : Limit the number of users to enumerate (default: 5)

Parser code in Program.cs:

if (!int.TryParse(args[++i], out NullSessionScanner.NullSessionEnumerationLimit))
{
	WriteInRed("argument for --nslimit is not a valid value (typically: 5)");
	return false;
}

Default value in NullSessionScanner.cs:

public static int NullSessionEnumerationLimit = int.MaxValue;

There are no other places in the code where the value is set.

I'm searching for a path parameter in command line mode to specify the output folders for the HTML and XML files of a health check. It seems like this is not implemented yet? Would be great if this could be added in the next release.

La méthode ExtractGPPPassword gère plusieurs fichiers XML avec champs cpassword.
Selon le fichier, le nom d'utilisateur peut se trouver dans des attributs différents.
Sont gérés les cas accountName et userName :

                XmlNode accountNameNode = node.SelectSingleNode("Properties/@accountName");
                XmlNode userNameNode = node.SelectSingleNode("Properties/@userName");
                PasswordData.UserName = (accountNameNode != null ? accountNameNode.Value : userNameNode.Value);

Cependant les Scheduledtasks.xml utilisent le champ runAs qui n'est pas géré et qui déclenche un crash.

Pour référence : https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Get-GPPPassword.ps1#L158

It looks like that this rule "The Denied RODC Password Replication Group group has some of its default members missing" has false positives for those groups:

• Enterprise Administrators
• Schema Administrators

I don't have the code to check but I guess it's because those are defined at forest root level, instead of within the current domain :)

Hello,

I've tested the latest release on a parent forest and the report was missing users in the following groups:

• Administrators
• Domain Administrators
• Enterprise Administrators

The tool only reports the account Administrator.
I've launched pingcastle.exe with --log and the trace.log contains the missing users when the program enumerates these groups.

Could you help fix this problem?

Thank you

Running v2.6.0.0 from cli with command "pingcastle --scanner localadmin", the result creates text file containing only the local admins of the domain controller.

Expected behaviour like v.2.5 where the same command outputs a text file with the local admin of all domain-joined computers.

After executing the pingcastle with the option(2) which is 2-permissions-Analyze admin groups and delegations with diagrams shows the below error with the path of ** e:\git\PingCastle\Graph\Reporting\ReportGenerator.cs** which never exist on my system. Attached is the error screenshot.

Kindly check this error and let me know what are the workarounds for this ?

Tested on pingcastle 2.7.10 latest from release section in github,

The HTML report contains a Content-Security Policy which is a good thing. Hashes are computed for imported scripts:

Including inline scripts, for example:

However, I noticed a warning in the Chrome console:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'sha256-t+xSDjAl7us/fSDwXMOUEX9O//OSNHhrky8hNs6bz6Q=' 'sha256-PgJlwxywHc63YBGsq97e404DO74MOKtKwEeTHyvPybI=' 'sha256-4aSc9Sgpav/KkHR9Etdg091GCnpW2pXdZAbCOIAwKxE=' 'sha256-Yt4VyG+DwKljtX/ozxDNG8QGP8x73pm7mkSE5m4RIU0=' 'sha256-+6QIuqOxYuMrW8s/xpzzzYSymjfvJYQ3yzV/UKyokEU=' 'sha256-vGrCRkYPwv1G/K8Y22/y1aWwBVPXBwFkF5KYwVutiJI=' 'sha256-6Y3BjZXxsrbZfGSuW0JCUYQ2ua1X1Tm8FsBzFKyJg50=' 'sha256-oh9nNTrYGBinUFrNl9SzIpKK4yR2iqIHbJjzX6Rl5ho='  'unsafe-inline'". Note that 'unsafe-inline' is ignored if either a hash or nonce value is present in the source list.

The mentioned line refers to this code:

I think the computed hash is incorrect.

Moreover, even if I don't think it's the cause of the issue here, unsafe-inline is specified:

Note that 'unsafe-inline' is ignored if either a hash or nonce value is present in the source list

Engine version: 2.7.1.1

In Healthcheck/Rules/RuleDescription.resx line 392

The LDAP search texte sould have be : (sAMAccountName=$$$) instead of (sAMAccountNmae=$$$)

First time reporting issue. Let me know if you need more information.

Great Tool by the Way 👍

Pingcastle doesn't work with Wine or Mono. Maybe this helps:

$ mono PingCastle.exe
the license couldn't validate

Program launched in interactive mode - press any key to terminate the program

With command line debug:
mono PingCastle.exe --debug-license
Starting the license checking
License: omitted_key_here
.....
starting the license analysis
License info uncompressed
data Type = 1
EndTime
data Type = 3
CustomerNotice
data Type = 0
Signature
hashing license info
hashing done
loading rsa key
loading rsa key
verifying the signature
License: exception SHA1 is an unsupported hash algorithm for RSA signingthe license check failed - please check that the .config file is in the same directory
the license couldn't validate
[Red]the license couldn't validate

$ gacutil -l | grep System.Security
System.Security, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

Thank-you for your work on a fantastic AD security auditing tool.

The T-TGTDelegation test added in the v2.7.0.0 release for checking TGT delegation across forest trusts uses test logic which is naive, resulting in false positives in common configurations. This isn't altogether surprising, as the changes that Microsoft has implemented to address the underlying issue are poorly documented, and some official management tools even give incorrect or misleading output.

This is going to be a long post to explain the relevant background to ultimately arrive at the suggested test change and mitigation guidance. Bear with me!

Relevant TDO trust attributes

The trust flags of interest stored in the trustAttributes attribute of TDO objects are:

• 0x200: CROSS_ORGANIZATION_NO_TGT_DELEGATION
• 0x800: CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION

The 0x200 flag and associated feature (Enforcement for Forest Boundary for Kerberos Full Delegation) was introduced in Windows Server 2012 but backported to Windows Server 2008 and 2008 R2 as part of the March 2019 security updates.

The 0x800 flag does not appear to be documented publicly, including in Microsoft's Open Specifications documentation for the trustAttributes attribute. I believe it was added by the May 2019 security updates to all supported Windows Server releases but haven't confirmed this. Of note, this means no current Windows Server release has awareness of this flag without applying the relevant security updates.

TGT delegation across forest trusts behaviour

This is where it gets complicated as the behaviour is dictated not just by the configured trustAttributes flags but also the security updates installed on the DC responding to a cross-forest request.

Prior to March 2019 security updates

TGT delegation across forest trusts is allowed by default. It can be disabled on Windows Server 2012 or newer by setting the CROSS_ORGANIZATION_NO_TGT_DELEGATION flag (a non-default configuration).

After March 2019 security updates

As above, but can now be disabled on Windows Server 2008 and 2008 R2.

After May 2019 security updates

Newly created forest trusts default to disabling TGT delegation. However, this does not mean the CROSS_ORGANIZATION_NO_TGT_DELEGATION flag is set in the TDO's trustAttributes. I'm guessing some other attribute of the TDO is used to determine if the new default behaviour should be used. Perhaps by checking the whenCreated attribute?

After July 2019 security updates

All forest trusts default to disabling TGT delegation. This effectively means that unless the CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION flag has been set in the TDO's trustAttributes then TGT delegation across the trust will be blocked.

Suggested detection approach

The current approach is checking that the CROSS_ORGANIZATION_NO_TGT_DELEGATION flag is set for each TDO object in the target domain, but as the above shows, this isn't entirely accurate.

I'd suggest the following approach to more accurately communicate the current configuration:

1. If the CROSS_ORGANIZATION_NO_TGT_DELEGATION flag is set on the TDO the issue is effectively mitigated, provided all DCs are running Windows Server 2012 or newer. If Windows Server 2008 or 2008 R2 DCs are present they must have the March 2019 security updates.
2. If the CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION flag is set on the TDO the domain is vulnerable. DCs with the relevant updates to understand this flag will allow TGT delegation while DCs which don't will use the previous default behaviour of allowing it anyway.
3. If neither flag is set, which I'd expect to be the default on the vast majority of domains, the domain's vulnerability comes down to whether the latest security updates are installed on all DCs (and the DCs are running supported Windows Server releases). This is a "maybe" state, in that if you have good security patching processes you're fine, but if you have any DCs which are not updated with at least the May 2019 security updates you're in trouble.

Changing the relevant TDO trust attributes

This is where it gets outright silly and needlessly confusing.

netdom

Assume a TDO without either of the referenced flags set. If you check the TGT delegation status on a patched system you'll see something like this:

netdom trust trusting_domain /domain:trusted_domain /EnableTgtDelegation
TGT Delegation is enabled.

OK, that's actually wrong, but let's try disabling it anyway:

netdom trust trusting_domain /domain:trusted_domain /EnableTgtDelegation:No
TGT delegation is already disabled.

So in contrast to Microsoft's own documentation, the only way to explicitly set the CROSS_ORGANIZATION_NO_TGT_DELEGATION flag via netdom is to temporarily enable TGT delegation and then immediately disable it. This will set the flag as you'd expect on the TDO.

PowerShell

There's no Set-ADTrust cmdlet but you can enumerate the configuration of existing trusts:

Get-ADTrust -Identity domain.com | select -Property TGTDelegation

Name        TGTDelegation
----        -------------
domain.name          True

But we just disabled TGT delegation? Turns out, the underlying cmdlet is checking for the CROSS_ORGANIZATION_NO_TGT_DELEGATION flag not realising it's an "inverted" flag. If it's set, the TGTDelegation property gets set to True.

Further, the ActiveDirectory module has no awareness of the new CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION, and so will incorrectly report TGT delegation is not enabled when it is.

Post the July 2019 security updates, if either of the TGT behaviour flags are set on an enumerated TDO, the ActiveDirectory module will tell you the exact opposite of the actual configuration. Prior to the July 2019 security updates it would always be wrong, so I guess this is an improvement overall.

ADSI

The only reliable and secure way to be sure the ideal fix (setting the CROSS_ORGANIZATION_NO_TGT_DELEGATION flag on each TDO) is implemented is to do so by directly checking the trustAttributes value using ADSI or similar. Ideally it could also be set if needed via ADSI, but I was unable to do so with the directory server always rejecting the update. Maybe updates to TDO settings must be performed via the LSA interface which netdom uses?

Suggested mitigation advice

The advice should be updated to note the bugs in netdom. The only reliable way to set the CROSS_ORGANIZATION_NO_TGT_DELEGATION flag on TDOs which I've found is by toggling TGT delegation on and off with netdom. Inspecting the current value of trustAttributes for a given TDO will determine if toggling the TGT delegation setting with netdom is necessary.

Hello,

I executed the pingcastle 2.8 on a windows 2019 core AD servers.

The reports is showing me that the audit kerberos authentication service is not enable on the GPO level

By applying the missing Audit logon settings and the "Audit Kerberos authentication service" into the GPO, part of the problem is solve.

Only the "Audit Kerberos authentication service" seems missing from the report.

I executed that remotely and locally on the server and i have the same report.
Did i miss something ?
Thanks for your help

First of all thanks for that awesome tool you've created.

I'am a little confused by this Topic right now.

I do have Trusts which looks like the following:
TGTDelegation : False
TrustAttributes : 8
WinServer2016 all patches installed.

With this info I would assume that this trust is not in a secure state.
Even PingCastle 2.7.1.0 told me that.

So I asked our Microsoft contact and he referred to your social.msdn article with the line "by default this flag is clear, meaning the unconstrained delegation is disabled across forests".

Now I assume that my trusts are in a secure state because the attribute value is only set to 8.

So in my understanding PingCastle has still a bug. Am I wrong with this assumption?

Hi,
I love your work, thanks for this incredible tool.
After an AD audit at a customer, I noticed a slight problem in the report regarding Fine Grained Password Policy lockout duration.
The account lockout duration is set to 30 minutes and the report tells me 6 minutes.
I don't know if it's a bug or a calculation you're doing.
I have reproduced the problem in a lab just to be sure.

See attached pics
Thanks again

changelog.txt is missing changes for v2.8.1.0

I noticed that Crowdstrike is missing from the AV check the tool performs.

Name - CSFalconService
DisplayName - CrowdStrike Falcon Sensor Service

In reports generated by v2.9.0.0 Beta the PingCastle logo (top left of report) is also a hyperlink in the form:
https://www.pingcastle.com/reports/<id>//#

The <id> appears to uniquely identify the scanned domain. Accessing the link itself returns a 403 response and a blank page.

EDIT: This affects other hyperlinks in the report as it's set in the <base> tag within <head>.

NullSessionScanner outputs a mix of TSV and CSV:

DisplayAdvancement(computer,"Null session is disabled");
sb.Append(computer);
sb.Append(",None,");

Notice it outputs comma. I also think the comma after "None" might be a bug.
The same thing applies to NullSessionTrustScanner, except it outputs CSV only.

It looks like that the BSI (German gov) changed some links...

I didn't find an exact equivalence to suggest

I noticed a false positive with the DCSubnetMissing rule where a DC IP was indeed in a declared subnet. I debugged the issue and found that GenerateNetworkData only collects the first 1500 Subnets of a Site. This looks similar to the default LDAP query policy which limits results to 1500, but I do not know how it is handled by ADWS. I see that the code supports paging, but maybe it should be applied to results' properties too?
Sorry for not proposing a PR...

The "Presence of unknown accounts" rule is triggered if I run PingCastle between forests. There is no trust between them.
The rule is triggered because it can't resolve SIDs correctly, even well-known one.
The user I'm using is a standard authenticated user, nothing special.

Interestingly these 4 SIDs appear in all forest with the same setup (no trust/readuser).

.\PingCastle.exe --healthcheck --server contoso.com --user readuser --password ([System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR))

At the bottom of a report we have a few sections with tables including many detailed info. For example "Audit settings", "Privileges", "GPO Login script", etc.
In large domains those tables can have many entries which makes it harder to skip them and reach the next section.
Therefore I suggest adding a pagination feature to the tables (to limit them to 10 visible entries for example), or a way to skip the section and go to the next (for example by "folding" the section).

J'ai vérifié les sorties d'un même domaine avec les versions 2.8.1.0 et v2.9.0beta.
L'item: Relatively high number of inactive user acounts (more than 15%) a disparue de la beta.

Hello,

PingCastle is able to detect the "GPP passwords" cases (encrypted "cpassword" field in some XML files of the sysvol).
But it doesn't seem to cover the "GPP autologon" cases. It's even easier since only "registry.xml" files are concerned and the login is in "DefaultUsername" and password in "DefaultPassword".

See this implementation example:
https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Get-GPPAutologon.ps1

Currently PingCastle shows in the report data about the object itself, but we have to fetch the unusual primary group ID and name ourselves.
It would be easier to have this info directly in the report :)

This rule isn't working correctly. It's showing me a number that doesn't match the computer section of the report.

Hi,

Clamav see PingCastle_2.9.1.0.zip as a virus

$ clamscan -r /mnt/c/Users/e/Downloads/PingCastle_2.9.1.0.zip /mnt/c/Users/e/Downloads/PingCastle_2.9.1.0.zip: Win.Exploit.CVE_2020_1472-9765784-0 FOUND

same for the html report generated and for pingcastle.exe !

Hi,

I think that the text displayed in the Trusts section inside the health check report is incorrect.
Text presents in indicators section is correct by the way.

I tried to run pingcastle 2.8.1.0 on a DC that does not have ADWS available and the following message appeared:

An exception occured when doing the task: Perform analysis for [DOMAIN] Exception: Connection to net.tcp://[DC]:9389/ActiveDirectoryWebServices/Windows/Resource impossible. The connection attempt lasted for a period of 00:00:21.0520035. TCP error code 10060: A connection attempt failed because the connected party did not respond properly after a certain amount of time, or an established connection failed because the connection host did not respond [IP]:9389.

I had to go the options to force the usage of LDAPOnly in order to run the tool properly. It however should switch automatically with the default option (ADWSThenLDAP) ?

Hello,
running the 2.7.0 version we receive
License valid for PingCastle 2.6.0.0 (Basic Edition)
don't know if it's by design, but I expected to read something like
License valid for PingCastle 2.7.0.0 (Basic Edition).

Regards.

Red.

Hi,
I noticed that in couple places were hardcoded names of privileged groups (Schema Administrators, Domain Admins, etc.). In my case names of them are different (e.g. Schema Administrators are Schema Admins) + due to language (e.g. German, Spanish) settings they very often totally don't match.

Is it possible to modify code a bit and use Well-Known SIDs instead?
https://support.microsoft.com/en-au/help/243330/well-known-security-identifiers-in-windows-operating-systems

Howdy,
Version: 2.6.0.0

Under the Privileged accounts rule details section:
Section "A bogus Windows 2016 installation has granted to much right to the Enterprise Key Admins group" should read as "A bogus Windows 2016 installation has granted too many rights to the Enterprise Key Admins group"

In the same section sub-title of "Ensure that boggus Windows 2016 AD prep did not introduce vulnerabilities" should read as "Ensure that a bogus Windows 2016 AD prep did not introduce vulnerabilities"