Many of you may already be familiar with adPEAS, but for those who aren’t: adPEAS is a PowerShell-based Active Directory analysis tool. It identifies vulnerabilities and misconfigurations in AD environments.

When I started working with Active Directory security many years ago, it quickly became clear: there were already some excellent tools out there — BloodHound, PingCastle, PowerView, and others — but for day-to-day pentesting tasks, something was missing. Something that automates all those manual analysis steps. The focus should be on the actual testing, not on spending hours typing commands and parsing output.

And so adPEAS was born. The first version — let’s call it “adPEAS legacy” — was built on top of PowerView by HarmJ0y (Will Schroeder). Will’s work on PowerView was phenomenal and has had a lasting impact on the AD security community. adPEAS legacy was essentially a wrapper that leveraged PowerView to run the most important security checks automatically. That worked more or less well, because reality caught up pretty quickly: EDR and AV solutions have gotten significantly better over the past few years. PowerView signatures are now detected and blocked by almost every enterprise solution. AMSI, Microsoft’s Antimalware Scan Interface, identifies and blocks known patterns.

It was time for something new.

However — let’s be honest: the idea of building a complete rewrite from scratch was daunting (at least for me). Rewriting an entire tool from the ground up? With a native Kerberos implementation? Without any dependencies? That sounded like a project that would take years. Then AI entered the picture, and so the “vibe-coding” adventure with Claude began. It was an intense learning process — lots of trial and error in handling AI, hours upon hours of babysitting Claude. Sometimes Claude forgets what happened two minutes ago, and occasionally you get “creative interpretations” of the task at hand.

But in the end, it worked. adPEAS v2 is here. Completely rewritten in pure PowerShell, with numerous new features, and staying true to the most important goal: automating Active Directory analysis to a reasonable degree.

And up front: adPEAS v2 is not intended to replace dedicated tools like BloodHound, PingCastle, Certipy, and others. Those tools have their place and do their job excellently. adPEAS is the quick first look, the triage, the initial overview before the specialized tools come into play.

Can’t wait? Head straight to the adPEAS GitHub repository and get started.

The Episodes

This blog series walks through adPEAS v2 — from the basics all the way to the details of the native Kerberos implementation. Whether you’re a pentester, security analyst, or IT admin: there’s something useful here for everyone.

Episode	Title	What to Expect
01	This Episode	Introduction and Quick Start
02	Under the Hood	What happens when a scan starts? (coming soon)
03	Authentication	Kerberos, Pass-the-Hash, PKINIT (coming soon)
04	Security Checks	All checks in detail (coming soon)
05	Output & Reports	Console and HTML reports (coming soon)
06	Offensive Operations	PrivEsc & Persistence (coming soon)
07	Kerberos Internals	ASN.1, Encryption, Protocol Details (coming soon)
08	PAC & Ticket Forging	Golden, Silver, Diamond Tickets (coming soon)
09	Tips & Tricks	Hidden tools for everyday pentesting (coming soon)

The Two Major Changes

What actually changed from adPEAS legacy to adPEAS v2? The two most important points first:

1. LDAP Only - Almost

PowerView, and by extension adPEAS legacy, didn’t use LDAP consistently. Native API calls were made here and there, which tended to cause problems in client environments — especially when testing from non-domain-joined computers. In adPEAS v2, almost everything is now actually LDAP. The “almost” matters, because accessing SYSVOL (GPO analysis, Scheduled Tasks, etc.) still requires CIFS. But everything related to AD objects, ACLs, or schema information runs through a clean LDAP connection.

What does this mean in practice? Fewer compatibility issues and fewer points of failure. If something doesn’t work, it’s more likely a firewall rule than some obscure API problem.

2. Native Kerberos - The Real Revolution

The biggest change is native Kerberos support. And by native, I really mean native — no Rubeus running in the background, no Mimikatz, no external tools. adPEAS v2 implements the complete Kerberos protocol stack in pure PowerShell.

TGT requests, TGS requests, key derivation, AES encryption — all in PowerShell. Was this a good idea? Probably not. Did it work? Absolutely.

The big advantage: you can use native Kerberos authentication from non-domain-joined computers. Pass-the-Hash, Pass-the-Key, PKINIT — all possible.

If Kerberos doesn’t work (firewall blocking port 88, KDC unreachable, etc.), adPEAS automatically falls back to NTLM Impersonation (which supports LDAP Signing), and if that also fails, to LDAP SimpleBind. adPEAS always tries to take the best available path.

No Dependencies - Really

This point deserves special emphasis:

adPEAS v2 has no external dependencies. Zero. Nada. Zip.

This means:

No PowerView
No ActiveDirectory PowerShell module
No RSAT tools
No external DLLs

Everything adPEAS needs is already built into Windows PowerShell 5.1. The .NET Framework, which runs on every Windows system, provides all the building blocks:

System.DirectoryServices.Protocols for LDAP communication
System.DirectoryServices for ACL parsing
System.Security.Principal for SID handling
System.Security.Cryptography for Kerberos cryptography
System.Net for network operations

Copy a single PowerShell file to the target system, run it — done. No installation, no discussions with the client.

The Architecture Under the Hood

For those who want to know how it all fits together, here’s a quick look at the architecture. adPEAS v2 follows a clean layered architecture:

+----------------------------------------------+
|              adPEAS.ps1 (Main)               |
|               (The Conductor)                |
+----------------------+-----------------------+
                       |
    +------------------+------------------+
    |                  |                  |
+---v------+    +------v------+    +-----v-----+
| Helpers  |    |    Core     |    |  Checks   |
+----------+    +-------------+    +-----------+
| Convert  |<---|  Get-Domain*|<---| Security  |
| Ensure   |    |  Invoke-LDAP|    | Analyses  |
| Format   |    |  Connect-*  |    | Findings  |
+----------+    +------+------+    +-----------+
                       |
                +------v------+
                |  Reporting  |
                +-------------+
                | HTML Report |
                | Console Out |
                +-------------+

The main script sits at the top and orchestrates the flow. It parses the parameters, establishes the connection, and calls the check modules one after another.

The Core modules are the heart of the tool:

Connect-adPEAS handles the complete authentication
Invoke-LDAPSearch is the central entry point for all LDAP queries
The Get-Domain* functions return AD objects in a unified format
Get-ObjectACL analyzes Access Control Lists

The Helper modules provide utility functions:

ConvertFrom-SID translates SIDs into readable names (with caching)
Test-IsPrivileged checks whether an account is privileged
Kerberos-Crypto contains the complete cryptography library

The Check modules perform the actual security analysis. Over 40 dedicated checks covering different aspects of AD security.

The Reporting module brings everything together and outputs it — as color-coded console output and as an interactive HTML report.

The Build Variants

adPEAS v2 comes in several variants. Development happens in a modular fashion (separate files for each module), but the build process merges everything into a single standalone file:

Variant	Size	Use Case
`adPEAS.ps1`	~4-5 MB	Readable — for debugging and understanding the code
`adPEAS_min.ps1`	~3-4 MB	Minimized — for production use
`adPEAS_ultra.ps1`	~3 MB	Ultra-compressed — when every KB counts
`adPEAS_obf.ps1`	<1 MB	Obfuscated — for AV evasion

The obfuscated version is no Fort Knox. Anyone with some PowerShell knowledge can reverse-engineer it. But it’s typically enough to bypass signature-based AV detection — and that’s often all you need.

Quick Start - Let’s Go!

Prerequisites

Before we get started, a quick check of the prerequisites. Spoiler: you probably have everything already.

You need a Windows system with PowerShell 5.1 or newer. Every reasonably current version of Windows ships with this — Windows 10, Windows 11, Windows Server 2016 and newer all have it on board. You can check your installed version with $PSVersionTable.PSVersion.

You also need network access to the Domain Controller. Specifically, port 389 (LDAP) or port 636 (LDAPS) must be reachable. For full Kerberos authentication, port 88 should be open as well — but don’t worry, adPEAS has fallbacks when Kerberos doesn’t work.

And finally, you need a domain account. This can be your regular Windows login (when joined to the domain) or separately provided credentials. For most checks, a regular user account is perfectly sufficient — admin rights are not required to scan the domain for security issues.

That’s it. No additional software, no modules, no installation.

Downloading adPEAS

There are several ways to get adPEAS.

The Quick Way: Direct Download

The fastest way is a direct download with PowerShell:

# Navigate to a directory
cd C:\Tools

# Download adPEAS
Invoke-WebRequest -Uri "https://github.com/61106960/adPEAS/raw/main/adPEAS.ps1" -OutFile "adPEAS.ps1"

The Git Way

With Git installed, you can clone the entire repository:

git clone https://github.com/61106960/adPEAS.git
cd adPEAS

The Manual Way

You can also simply navigate to https://github.com/61106960/adPEAS in your browser, click on adPEAS.ps1, and save the file using the download button.

The First Scan

The file is in place. Time for the first scan.

Step 1: Load adPEAS

Import-Module .\adPEAS.ps1

Step 2: Start the Scan

# Windows auth with current user
Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth

# With credential dialog
Invoke-adPEAS -Domain "contoso.com" -Credential (Get-Credential)

# With username and password
Invoke-adPEAS -Domain "contoso.com" -Username "domain\user" -Password "P@ssw0rd"

# With a specific DC
Invoke-adPEAS -Domain "contoso.com" -Server "dc01.contoso.com" -UseWindowsAuth

That’s it. adPEAS enumerates the domain and displays its findings.

What Happens After Launch

When it starts, adPEAS greets you with the ASCII art logo:

               _ _____  ______           _____
              | |  __ \|  ____|   /\    / ____|
      ____  __| | |__) | |__     /  \  | (___
     / _  |/ _  |  ___/|  __|   / /\ \  \___ \
    | (_| | (_| | |    | |____ / ____ \ ____) |
     \__,_|\__,_|_|    |______/_/    \_\_____/
                                            Version 2.0.0

    Active Directory Enumeration
    by @61106960

    Legend
        [?] Searching for juicy information
        [!] Found a vulnerability which may be exploitable
        [+] Found some interesting information for further investigation
        [*] Some kind of note
        [#] Some kind of secure configuration

Understanding the Output

The console output of adPEAS is color-coded:

Symbol	Color	Meaning
`[!]`	Red	Finding — Security issue, action required
`[+]`	Yellow	Hint — Interesting, should be investigated
`[*]`	Green	Note — Informational
`[#]`	Red on Yellow	Secure — Good configuration
`[?]`	Blue	Header — Section heading

An Example

[?] Collecting domain information...
[*] Found domain information:
domainNameDNS:                               contoso.com
domainNameNetBIOS:                           contoso
domainSID:                                   S-1-5-21-1234567890-1234567890-1234567890
domainFunctionalLevel:                       Windows 2025
forestFunctionalLevel:                       Windows 2016
forestName:                                  contoso.com


[?] Analyzing Kerberos policy...
[+] Found Kerberos policy:
maxTicketAgeTGT:                             10 hours (default)
maxRenewalAge:                               7 days (default)
[+] krbtgtPasswordAge:                       224 days (last changed: 2025-07-04)


[?] Searching for Domain Controllers...
[*] Found 2 domain controller(s):
domainControllers:                           dc01.contoso.com [PDC Emulator, Schema Master, Infrastructure Master, Domain Naming Master, RID Master]
                                             dc02.contoso.com

Generating an HTML Report

Console output works well for a quick overview, but for documentation you need a report:

Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -Outputfile .\report -Format HTML

adPEAS generates an HTML file with:

Security Score — Overall assessment of the security posture
Finding Cards — Expandable details for each issue
Table View — Sortable table of all findings
Dark Mode — For the night owls
Export — Print / PDF (via browser)

The report is completely standalone — the HTML file can simply be sent via email.

Key Parameters

Authentication

Standard: Invoke-adPEAS (One-Liner)

# Windows auth
Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth

# Credential dialog
Invoke-adPEAS -Domain "contoso.com" -Credential (Get-Credential)

# Username and password
Invoke-adPEAS -Domain "contoso.com" -Username "domain\user" -Password "P@ssw0rd"

Session-based: Connect-adPEAS + Invoke-adPEAS

For advanced auth methods (Pass-the-Hash, PKINIT) or interactive work:

# Step 1: Establish session
Connect-adPEAS -Domain "contoso.com" -UseWindowsAuth

# Or with Pass-the-Hash
Connect-adPEAS -Domain "contoso.com" -Username "admin" -NTHash "32ED87BDB5FDC5E9CBA88547376818D4"

# Or with PKINIT (certificate)
Connect-adPEAS -Domain "contoso.com" -Certificate "user.pfx"

# Step 2: Run scan
Invoke-adPEAS

# Or individual checks
Get-KerberoastableAccounts
Get-PrivilegedGroupMembers
Get-ADCSVulnerabilities

# Step 3: Clean up
Disconnect-adPEAS

Connection Options

# Specific Domain Controller
Invoke-adPEAS -Domain "contoso.com" -Server "dc01.contoso.com" -UseWindowsAuth

# Force LDAPS (SSL/TLS)
Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -UseLDAPS

Controlling Modules

# Run only a specific module
Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -Module Accounts

# Multiple modules
Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -Module Domain,Accounts,ADCS

Available modules: Domain, Creds, Rights, Delegation, ADCS, Accounts, GPO, Computer, Application, Bloodhound

OPSEC Mode

Skips active Kerberos ticket requests and heavy LDAP queries — no Kerberoasting, no AS-REP Roasting, no BloodHound collection.

Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -OPSEC

Typical Scenarios

Security Quick Check

Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -Module Domain,Accounts

Full Audit with Report

# Creates both text AND HTML report
Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -Outputfile .\contoso_audit

# HTML report only
Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -Outputfile .\contoso_audit -Format HTML

Pentest with a Compromised Hash

# Establish session with Pass-the-Hash
Connect-adPEAS -Domain "contoso.com" -Username "svc_backup" -NTHash "A4F49C406510BDCAB6824EE7C30FD852"

# Run scan
Invoke-adPEAS

ADCS-Focused Analysis

Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -Module ADCS -Outputfile .\adcs_report

Troubleshooting

Connection Failed

# Is the DC reachable?
Test-NetConnection -ComputerName dc01.contoso.com -Port 389

# Does DNS work?
Resolve-DnsName contoso.com
Resolve-DnsName _ldap._tcp.dc._msdcs.contoso.com -Type SRV

Authentication Failed

# Use Verbose for more details
Connect-adPEAS -Domain "contoso.com" -Credential (Get-Credential) -Verbose

Scan Takes Too Long

For large domains, test individual modules separately:

Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -Module Domain
Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -Module Accounts

Episode 2: Under the Hood — coming soon

adPEAS v2 Blog Series: Active Directory Security Analysis with adPEAS