Inside the NSA's PowerShell Toolkit for Stopping Pass-the-Hash Attacks
Hook
The NSA released PowerShell scripts to solve a Windows security problem so pervasive that penetration testers can traverse entire enterprise networks in minutes using nothing but stolen password hashes—no plaintext passwords required.
Context
Pass-the-Hash (PtH) attacks have plagued Windows environments since the early 2000s. The attack exploits Windows authentication protocols by capturing NTLM password hashes from memory and reusing them for authentication without ever cracking the actual password. Once an attacker compromises a single workstation, they can extract local administrator hashes and laterally move across the network by authenticating to other machines that share the same local admin password—a configuration depressingly common in enterprise environments where IT departments image thousands of machines from the same template.
The NSA Cybersecurity Directorate released Pass-the-Hash-Guidance as part of their public mission to share defensive capabilities with critical infrastructure operators. Before Microsoft LAPS gained widespread adoption, organizations had limited options for addressing the local administrator password reuse problem at scale. This toolkit emerged from real-world incident response experiences where attackers weaponized PtH techniques to compromise entire Active Directory forests. The repository packages NSA's mitigation strategies into executable PowerShell commands that domain administrators can deploy immediately, addressing not just password reuse but also subtle vulnerabilities like smartcard hash persistence that even security-conscious organizations overlook.
Technical Insight
The PtHTools module architecture centers on four operational domains: event log forensics, network access control, password lifecycle management, and smartcard hash mitigation. Each function wraps complex Group Policy operations and Active Directory queries into single commands that implement specific NSA recommendations.
The Find-PotentialPtHEvents function demonstrates the forensic approach. It correlates Windows event logs across multiple sources to identify authentication patterns consistent with PtH attacks. The function searches for Event ID 4624 (successful logon) with logon type 3 (network logon) using NTLM authentication, specifically filtering for suspicious patterns:
# Simplified example of PtH event detection logic
$PtHIndicators = Get-WinEvent -FilterHashtable @{
LogName = 'Security'
ID = 4624
} | Where-Object {
$_.Properties[8].Value -eq 3 -and # Logon Type 3 (Network)
$_.Properties[10].Value -like '*NTLM*' -and # NTLM auth
$_.Properties[18].Value -ne $env:COMPUTERNAME # Remote source
} | Select-Object TimeCreated,
@{N='Account';E={$_.Properties[5].Value}},
@{N='SourceIP';E={$_.Properties[18].Value}},
@{N='AuthPackage';E={$_.Properties[10].Value}}
The real power emerges when combining event analysis with Invoke-DenyNetworkAccess, which modifies Group Policy to prevent local accounts from authenticating over the network. This implements a fundamental PtH defense: even if attackers steal local administrator hashes, those credentials become useless for lateral movement. The function creates or modifies GPOs to add local accounts to the "Deny access to this computer from the network" user rights assignment, effectively compartmentalizing each machine's local accounts.
The Edit-AllLocalAccountPasswords function addresses the password reuse problem by remotely rotating local administrator passwords across all domain-joined computers. Unlike Microsoft LAPS, which requires schema extensions and dedicated infrastructure, this approach uses native PowerShell remoting and WMI:
# Core password rotation logic (simplified)
function Edit-AllLocalAccountPasswords {
param(
[string]$AccountName = 'Administrator',
[int]$PasswordLength = 20
)
$Computers = Get-ADComputer -Filter * -Properties DNSHostName
foreach ($Computer in $Computers) {
$NewPassword = Generate-ComplexPassword -Length $PasswordLength
Invoke-Command -ComputerName $Computer.DNSHostName -ScriptBlock {
param($Account, $Password)
$SecurePassword = ConvertTo-SecureString $Password -AsPlainText -Force
Set-LocalUser -Name $Account -Password $SecurePassword
} -ArgumentList $AccountName, $NewPassword
# Store password in secure location (implementation varies)
Export-PasswordRecord -Computer $Computer.DNSHostName -Account $AccountName -Password $NewPassword
}
}
The smartcard-specific functions (Find-OldPasswordOnSmartCardRequiredAccount and Reset-MyPasswordAndUpdateSmartCard) address an architectural quirk in Active Directory. When you enable the "Smart card is required for interactive logon" setting on an account, AD generates a random password—but that password's NTLM hash remains stored in the directory and never expires. If attackers obtain this hash through DCSync attacks or database compromise, they can use it indefinitely for network authentication despite the smartcard requirement. The toolkit's solution forces password resets through controlled smartcard authentication flows, ensuring fresh hashes replace potentially compromised ones.
All functions leverage PowerShell's Active Directory and Group Policy modules, requiring domain admin privileges or equivalent delegated permissions. The design philosophy prioritizes operational safety: functions include -WhatIf parameters, generate detailed logs, and implement validation checks before making changes. This reflects the NSA's understanding that defensive tools deployed carelessly can cause more damage than the attacks they prevent.
Gotcha
The most critical limitation is the operational impact of mass password rotation. Running Edit-AllLocalAccountPasswords across your domain will immediately break any service accounts, scheduled tasks, or management tools that authenticate using local administrator credentials. I've seen organizations execute this command during business hours and trigger cascading failures across monitoring systems, backup agents, and configuration management tools that all relied on the old local admin password. You need comprehensive asset inventory and service account documentation before touching this function.
The toolkit also lacks rollback mechanisms and centralized orchestration. If password rotation fails halfway through your 5,000-machine environment due to network issues or insufficient permissions, you're left with a partially updated infrastructure and manual cleanup work. There's no web interface, no central management console, and no integration with password vaults—just PowerShell scripts that you orchestrate yourself. The event log analysis functions can generate false positives in environments with legitimate NTLM usage, and tuning the detection logic requires PowerShell expertise and deep understanding of your authentication patterns. Additionally, these tools don't replace comprehensive endpoint detection; they won't catch attackers who use PtH techniques in memory without generating the expected event log signatures.
Verdict
Use if: You're managing Windows Active Directory environments without Microsoft LAPS deployed and need immediate PtH risk reduction; you're implementing NSA cybersecurity guidance for compliance requirements; you have smartcard-required accounts and need to audit for hash persistence vulnerabilities; or you need lightweight forensic tools for investigating potential PtH incidents without deploying full EDR solutions. This toolkit shines in resource-constrained environments where you need effective mitigations using native Windows capabilities. Skip if: You've already deployed Microsoft LAPS and have mature privileged access management; your organization uses modern EDR platforms with built-in PtH detection and automated response; you lack the PowerShell expertise and change management processes to safely execute mass password rotations; or you operate primarily non-Windows infrastructure. These are tactical tools for specific problems, not a comprehensive privileged access security platform.