Deploy PingCastle: Get reports for all domains

PingCastle has been designed to be scalable and used in a decentralized architecture.

To be the most effective, PingCastle needs to have the risk reports for all domains. Because PingCastle doesn’t need an account in the domain to audit, you can take benefits of trusts to perform this task.

Management involvement

The management involvement is a critical factor of success. Here is how you can proceed.

You can start the project by running the tool without notifying the domain administrators to get a first overview. The health check mode run on all trusted server (server set as “*”) or the carto mode can help built a big picture of all domains involved.

Then you can deploy officially in a small perimeter and use the report results to challenge the domain administrators. Based on the risk indicators or on the delay required to fix the problems, you can take the opportunity to involve the management here.

Here some arguments which can help you to involve the management about this kind of project:

  • Active Directory’s security is crucial: the probability that an auditor compromise an Active Directory is about 90%
  • Management has to prove to external auditors that actions are being made on that topic
  • The tool doesn’t need any setup, installation, server, project, … Cost & effort are minimal
  • The risk indicators can be used to prove that the situation has been improved and it can be used for benchmarking (an effective management method)
  • The tool returns anomalies which 80% of them can be fixed within 5 minutes

Decision to take

We recommend that the decision made by the management is about:

  • Deploy the tool on 100% of the domains
    For example set the initial deadline to 3 months and assign discovered trusted domain to the AD owner.
  • Request the implementation of SID Filtering on 100% of the trusts except official migrations
    For example set a list of critical domains and list the trusts linked to that domains without SID Filtering.
  • Follow the progress of these actions on the management meetings.
    For example set a monthly follow up meeting with the people involved.


Even if the management reporting is done on a monthly basis, we recommend to setup a scheduled task on a weekly basis. This frequency is justified to:

  1. See the improvement almost in real time and avoid tunnel effect
  2. Detect newly created trusts and be able to remove them if needed with a limited business impact.

Getting to 100%

Bellow is a list of reasons an entity can invoke (or remain silent) to be excepted:

  • Minority share holding company
  • Migration and removal of the domain in the upcoming months
  • Regulations
  • “Confidential information” included in the script

To handle the migration cases, PingCastleReporting supports a “migration” status for the domain auditing & a “migration” status for SID Filtering. In the SID Filtering case, an end date has to be defined. We recommend 3 to 12 months. Migration should be an excuse for removing anomalies, not running the script (a 5 minutes effort !).

For “confidential information”, the xml report doesn’t include any personal information nor administrator accounts. If the level of information included is too high, a configuration switch exists to lower the level of information. If the problem is about the transfer of the data in an unsafe channel, the tool can encrypt the xml report to solve this problem.

For other issues, we recommend to insist if there are trusts to existing domains. Indeed, a trust facilitates the attacker job because he knows that there is a domain via the trust information, that there can be credentials in memory (mimikatz) or that he can absuse network connection (LLMR spoofing with Python Responder). If you can’t get a report, we suggest to remove the trust to these domains.

Then for domains without a trust, you can formally transfer the responsibility of the Active Directory compromise and put the domain status to “Out Of Scope”.

Here is some template in English or French to transfer the responsibility.

Deploying PingCastle in decentralized locations

PingCastle can be run on every domain of a company using the command:

PingCastle --healthcheck

Reports can then be regrouped to produce a global view. See below for the technics (encryption, transfert by email) to centralize the reports.

Deploying PingCastle in centralized locations

PingCastle can be run on a Bastion Active Directory, generally used to perform administration tasks. In this case, all the domains will be scanned.

PingCastle --healthcheck --server *

The program can be run on every forest root and be limited to that perimeter

PingCastle --healthcheck --server *.forest.root

The tool can be run on every forest child and explore the child and its trusted domains. In this case the forest root is excluded.

PingCastle --healthcheck --explore-trust --server child.forest.root

PingCastle can explore all the domains of all the trusted forests from another forest. This is useful when the root and child doesn’t share the same name.

PingCastle --healthcheck --explore-forest-trust --server anotherforest.root

If needed, exceptions can be set to not scan domains. For example to not scan the Bastion domain multiple times. In this case use the option –explore-exception <domains> where domains are comma separated domain name.

Centralizing reports


Sometimes, domains are unconnected or it is not possible to make the schedule tasks centralize in a single share all the reports. To deal with this case, PingCastle can encrypt the reports to send them in an unsafe channel.

A RSA key pair need to be generated and the public key needs to be shared with all the instance of the program. When producing risks reports and generating the .xml files, add the flag –encrypt to perform the encryption.

You can generate a keypair using the following command and copy the public key in the .config file to be deployed.

PingCastle.exe --generate-key

Starting the task: Generate Key
Public Key (used on the encryption side):
<encryptionSettings encryptionKey="default">
 <!-- encryption key -->
 <KeySettings name="default" publicKey="&lt;RSAKeyValue&gt;&lt;Modulus&gt;h
 <!-- end -->
Private Key (used on the decryption side):
<encryptionSettings encryptionKey="default">
 <!-- decryption key -->
 <KeySettings name="39b5d076-17be-4999-b43e-b894a55446a1" privateKey="&lt;R
 <!-- end -->
Task Generate Key completed

Then copy the private key section in the PingCastle and PingCastleReporting configuration file (.config) used to consolidate the results. PingCastle will perform the decryption automatically.

The program can generate an encrypted copy of a report (public key needed) and a decrypted copy of a report (private key needed) using the following commands:

PingCastle --reload-report report.xml --encrypt
PingCastle --reload-report encrypted-report.xml

Note: Only one key can be specified for encryption but multiple keys can be used for decryption. Their selection is automatic.


PingCastle can contact if specified a SMTP server to send the reports by email. If the encryption is set, the program will encrypt the reports. Use –sendXmlTo <email> to send only the xml report, –sendHtmlTo <email> to send only the html report and –sendAllTo <email> to send both html and xml report. Email addresses are comma separated ones and the previous flags can be combined.