Active Directory Audit with PingCastle (Part 1)

Whenever we consider Information Security, our priorities are our crown jewels, these are our most critical assets that require the highest level of protection.

Typical examples of this are:

  • Databases (Patient Records, PII DBs …)
  • Identity and Access Management (DC (Microsoft AD DS), Okta …)

Although this are typical examples, your crown jewels are the things you identify as your crown jewels, it all depends on your organization.

So now that we’ve established Active Directory as being one of the core essential parts of our infrastructure, how do we secure it?

What’s that Bob? “Sometimes you just gotta sing along and hope for the best”, No! “This is the worst idea I’ve ever heard…and I’ve heard some doozies.”.

Let’s just solve this problem like adults… by yelling at each other and auditing until we’re secure, maybe not scream.

PingCastle is an Active Directory tool that helps audit our AD DS environment, which is free for personal use, and depending on additional professional needs, there are various editions of commercial packages. We’ll focus on using the free version, as we’re working on a personal environment.

So why are we auditing an Active Directory? (I know you’re not an Accountant Bob, Chill!)

So the reason for security auditing is mainly to identify security flaws in our environment, an audit highlights what misconfigurations, vulnerabilities, and weaknesses we have in our environment.

Once we know what our weaknesses are, we can then tackle those weaknesses one by one, (yes Bob’s first step in solving a problem is knowing there’s a problem.)

Now before we proceed let’s check PingCastle’s recommended methodology, which can be found here.


Understanding the Stakeholders: understanding different stakeholders and their needs is an important part of auditing systems for security.

  • Management
    • AD security level benchmark and standards in the industry, and how the current setup fairs compared to them. This helps them identify if more investment is needed or less.
    • Avoiding critical risks, it’s all about prioritizing and critical risks are always of concern for management.
    • Cost, management is always concerned with the cost of performing any action, and budgets for securing AD need to be defined as the budget is shared with other areas of interest.
  • Technical Ops
    • Always concerned with securing and making sure systems are always available for users.
    • Visibility, a key aspect of security and a huge concern of technical security teams is having visibility and ease of identifying security flaws is a major area of interest.
    • Concerned with making sure vulnerabilities are fixed but without causing problems, to do this testing changes aka sandboxing is a key aspect.

In PingCastle we follow Maturity Based Improvement.

Conduct Assessment/Audit: understand our strengths and weaknesses, and identify misconfiguration and inherent security flaws that exist.

Analyze the results: identify vulnerabilities, gaps in controls, critical flaws, and areas for improvement.

Prepare a Plan: auditing and securing AD is not a one-off task, it’s a continuous maturity-based improvement. As such we need to define our goal, timeline, resources needed for securing, and milestones & schedules.

  • Define the goal (Maturity level: basic, intermediate, advanced), multiple stakeholders are involved here.
  • Define the timeline for the process, milestones, and schedules for each task.
  • Define resources needed for the process
  • Prioritize: based on criticality.

Implement Plan: fix vulnerabilities, and security flaws and improve Active Directory security posture according to plan.

Measure Progress: assess the progress of implementing the plan and readjust if needed.

Continuous Improvement: information security is never a one-off project or task, it’s a continuous ongoing process. Regular auditing and reassessments are important for improving the maturity level or maintaining the existing level.

Alright, let’s dive in:

If you haven’t checked out the guide on how to build AD Lab for learning cyber security, checkout my lazy-ad project on github.

Download and Setup PingCastle

Go to PingCastle and grab the latest and greatest download link:

Now although this is a pingcastle audit blog, in reality, we’ll be auditing AD using a different set of tools, so for organizing our auditing, it’s better to contain the auditing in the same directory.

 mkdir AD_Audit
 cd AD_audit
 Invoke-WebRequest -Uri -Outfile
 Expand-Archive .\ PingCastle
 cd .\PingCastle\

Alriiiiight! We’ve successfully installed/downloaded PingCastle…

Everything’s better with cheese (I mean Audit, Darn It Bob)

So let’s run PingCastle, now there are different check options in it:

General Health Check

  • This is the default check, which essentially quickly collects the most important information about AD to establish an overview of it.
.\PingCastle --server <AD Server IP> --healthcheck --level Full --no-enum-limit
  • server: specifies the target server (if we’re running PingCastle we can use localhost or
  • healthcheck: type of check we’re performing
  • level: specify the amount of data found in the xml file (Full, Normal, Light)
  • no-enum-limit: remove the max 100 users limitation in html report

PingCastle has many more options, like sending html to emails, specifying exceptions and so much more, we can check that with the --help option.

  • Alriiiight! Let’s run the health check:
  • Well, it’s official we’ve our first report, however in an Enterprise environment a quick health check.


As mentioned earlier, we have several types of scanners we can run to gather better information about our domain environment.

  • aclcheck: checks authorization related to users or groups
  • antivirus: checks for computers without known antivirus installed.
  • computerversion: checks version of OS’s, which help determine if we’re using obsolete OS’s
  • foreignusers: use trusts to enumerate users located in domain denied such as bastion or domains too far away.
  • laps_bitlocker: check if LAPS and/or Bitlocker are enabled,
  • localadmin: Enumerate the local administrators of a computer.
  • nullsession: check if null sessions are enabled.
  • remote: check if an rdp solution is installed on computers.
  • share: scan for local share and the result shows if a share has been accessed by anyone.
  • smb: determines smb version available and if smb signing is applied.
  • spooler: checks if the spooler service is remotely active.
  • startup: retrieves the last date of startup.
  • zerologon: check for zerologon vulnerability.
.\PingCastle.exe --scanner antivirus
.\PingCastle.exe --scanner computerversion
.\PingCastle.exe --scanner laps_bitlocker
.\PingCastle.exe --scanner localadmin
.\PingCastle.exe --scanner nullsession
.\PingCastle.exe --scanner remote
.\PingCastle.exe --scanner share
.\PingCastle.exe --scanner smb
.\PingCastle.exe --scanner spooler
.\PingCastle.exe --scanner startup
.\PingCastle.exe --scanner zerologon

When running this scanners we’re prompted if we want to scan all computers or the domain we’d like to scan, it’s important to scan all computers in the domain and specify or use the default domain listed there, unless we’re auditing specific computers and/or other domains.

Now finally we’ve scanned and checked our AD, the only thing left for us is to check the reports generated and address the issues.

For convenience purposes, I like to collect and keep the generated reports in one directory and also organize the audit, an easy way to identify the generated reports is that all the reports have the name of our domain.

$today = Get-Date -Format "dd_MM_yyy"
mkdir audit_report_$today
Move-Item *<domain name>* <to this directory we created earlier>
  • Now let’s cd to our new report directory and check the html output.
cd audit_report_$today
  • As we can see above we have our reports here, now this report can be used differently, we can use the xml output to ingest other tools.
  • So let’s finally check our html report, (Got be honest Bob, super excited. This is going to be a burger flip)

I’ll take that back, Well this is just great!

No this is bad, but securing an Enterprise Active Directory isn’t a one-off job, As discussed earlier we need to be constantly improving it, updating and getting the latest and greatest paths, configurations, and so on. Maturity Based Improvement by itself is not a one-time achievable principle, rather it’s a continuous improvement en-devour. Saying that, let’s try and understand the different rules and risk categories.

Risk Model

We have about 4 categories of indicators checked against different rules. Each rule then has sub-rules that are checked against that specific indicator. The rules for each indicator are completely different.

Stale Object

Stale objects represent everything about the AD objects and their life cycle, computer and user creation, and delegation. In short, this particular indicator is concerned with operations related to users and computers.


Inactive user or computer: checks for inactive users or computers, if not treated well, the attacker may be able to use these accounts by taking them over from memory or if the same credentials are used.

Network topography: checks if all subnets are declared within the site’s tool.

Object configuration: checks for various misconfigurations that could potentially allow attackers to take over.

Obsolete OS: updates and patches are crucial aspects of security, this rule checks for phased-out operating systems, or those behind their life cycles. So we can upgrade to the latest versions and fix the vulnerabilities.

Old authentication protocols: The use of old and weak cryptographic authentication protocols can harm the security of our AD. (For instance, using NTLMv1 is highly advised against). This rule checks for such weaknesses.

Provisioning: checks on the authority of creating new objects in the Active Directory.

Replication: checks if there are duplicate objects due to collision of changes.

Privileged Accounts

This indicator as its name suggests, it’s about administrators’ accounts.

Account takeover: this rule is concerned with ensuring misconfiguration doesn’t allow privileged account takeovers, as that would be devastating and administrators are usually the ones targeted.

ACL Check: related to ensuring delegations are not abused and proper access control is maintained.

Control paths: relates to ensuring permissions are isolated and prevent admins from unintended access.

Delegation Check: using delegations one can escalate the privilege originally intended, delegations are very complex. This rule checks for delegation issues.

Irreversible change: checks if there are securities in place against accidental changes that are irreversible which can break domains, like schema changes, accidental object deletions, and so on.

Privilege control: privileges are granted to special groups to perform their duty. Sometimes, these privileges can be used to take control of the domain.

Read-Only Domain Controllers: Read-Only Domain Controllers are used in poorly physically secured zones. An incorrect protection level can leak sensitive data.


This is an indicator of trust between different domains in a forest, on AD can compromise another one via trust. Different rules are checked against however our lab is made of only one domain thus, we won’t be going over this indicator, and Pingcastle won’t have scores if we don’t have any trust and relationships in our AD.


Various security checks, that don’t fit into the above list of rules.

Audit: this checks if necessary key events are being collected for detection.

Backup: checks if backups are being taken for recovery plans.

Certificate takeover: certificates can function as replacements for passwords, and can be used in a backdoor.

Golden ticket: checks if our AD is susceptible to Golden Ticket attack, as the leak of key secrets in our AD could lead to total compromise of the domain.

Local group vulnerability: checks, if GPO deployed settings, are applied to computers locally, as they can be used to take control of individual computers

Network sniffing: checks there are mis-configs allowing attackers to perform network attacks, like LLMNR attacks.

Pass-the-credential: checks for configs allowing password secrets such as fingerprint hash can be used as if it was the password itself.

Password retrieval: checks if the password is stored in clear text or easily reversible password policy.

Reconnaissance: this rule is concerned with ensuring our configuration is tight so that information isn’t easily retrieved by anyone, which can significantly make the attacker’s life harder.

Temporary admins: the purpose of this rule is to ensure that there are no rogue admin accounts in the Active Directory

Weak Passwords: checks if proper protections are in place for our passwords, ensuring that credentials aren’t easily abused.

Alright, so we now have a report that we need to analyze and go over each rule and make proper changes, which we’ll be doing in part 2 of this blog. The report is uploaded on the github repo of our AD setup guide here.

Okay I’ve got to go, [Bob’s voice] Linda, Honey...Linda.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.