Inside nullbind’s Other-Projects: A Veteran Pentester’s Windows Security Script Arsenal
Hook
Sometimes the most useful security tools aren’t polished frameworks with CI/CD pipelines—they’re battle-tested scripts a penetration tester threw together at 2 AM during an actual engagement and decided to share.
Context
The penetration testing landscape is littered with comprehensive frameworks: Metasploit, Empire, Cobalt Strike, PowerSploit. These tools are excellent for structured operations, but they share a common problem—they’re designed for the common case. When you’re deep in a Windows environment and need to enumerate something specific that doesn’t fit neatly into a framework module, you’re left writing custom scripts.
nullbind’s Other-Projects repository emerged from this gap. Created by Scott Sutherland, a well-known penetration tester and researcher at NetSPI, this collection represents the organic evolution of tools developed during real security assessments. Unlike frameworks built with grand architectural visions, these scripts solve specific, often annoying problems: extracting credentials from obscure locations, enumerating Active Directory in novel ways, or automating repetitive manual tasks during engagements. The repository’s honest ‘dumping ground’ description undersells its value—these aren’t academic exercises but practical utilities forged in the fire of actual penetration tests.
Technical Insight
The repository’s architecture—or deliberate lack thereof—reflects its pragmatic origins. Each script is self-contained, typically focusing on a single enumeration or exploitation task. Let’s examine some representative examples to understand the technical approach.
Many scripts focus on Windows privilege escalation enumeration, a perpetual pain point in penetration testing. Rather than building abstraction layers, these tools embrace directness. For instance, scripts often leverage WMI (Windows Management Instrumentation) and PowerShell to extract system information that manual enumeration would miss. A typical pattern involves using WMI queries to enumerate services, scheduled tasks, or registry keys with weak permissions:
# Example pattern from registry enumeration scripts
$RegPaths = @(
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
)
foreach ($Path in $RegPaths) {
Get-Item $Path | Select-Object -ExpandProperty Property | ForEach-Object {
$Value = (Get-ItemProperty -Path $Path -Name $_).$_
$ACL = Get-Acl -Path $Path
# Check for weak permissions
$WeakPerms = $ACL.Access | Where-Object {
$_.IdentityReference -match 'Users|Everyone' -and
$_.FileSystemRights -match 'FullControl|Modify'
}
if ($WeakPerms) {
[PSCustomObject]@{
Path = $Path
Key = $_
Value = $Value
VulnerableACL = $WeakPerms.IdentityReference
}
}
}
}This script pattern demonstrates the repository’s philosophy: focus on output, not elegance. There’s no error handling framework, no logging abstraction, no unit tests. The code assumes you’ll run it, review the results, and integrate findings manually. This approach makes the scripts lightweight and easy to modify on-the-fly during engagements.
Another common pattern involves batch file wrappers around native Windows commands. These scripts chain together built-in utilities like net, wmic, and reg to perform complex enumeration without requiring PowerShell execution, which is increasingly monitored or restricted by EDR solutions. The batch file approach is particularly clever for environments with strict application whitelisting—Windows’ own command interpreter is always available.
The collection also includes Active Directory enumeration scripts that leverage LDAP queries and .NET assemblies to extract information about domain trusts, group memberships, and service accounts. These scripts often solve the ‘I need just this one piece of information’ problem without spinning up BloodHound or PowerView. For instance, extracting all domain computers with unconstrained delegation—a significant security risk—might require a targeted LDAP query that’s easier to run as a standalone script than configuring a full framework.
What makes these scripts valuable isn’t technical sophistication but operational awareness. They’re written by someone who understands the friction points of real penetration tests: time constraints, detection avoidance, and the need for quick answers. The code tends to favor PowerShell one-liners that can be typed directly into a command prompt, avoiding the need to upload files that might trigger antivirus alerts. Many scripts output results in formats that copy-paste easily into penetration testing reports—CSV files or formatted text that require minimal cleanup.
The repository also contains scripts for extracting credentials from various Windows subsystems beyond the standard SAM database—think cached credentials, LSA secrets, and credentials stored in registry hives. These scripts often wrap well-known techniques but automate the tedious parts, like parsing binary output or handling different Windows versions’ registry structures.
Gotcha
The repository’s biggest limitation is its documentation philosophy: there isn’t one. Each script assumes you’ll read the code to understand what it does, what parameters it accepts, and what output to expect. For experienced penetration testers who regularly read PowerShell and batch scripts, this isn’t a dealbreaker. For junior security professionals or developers unfamiliar with Windows internals, it’s a significant barrier to entry. You’ll spend time reverse-engineering the author’s intent from code comments and variable names, which range from self-documenting to cryptic.
Maintenance and compatibility represent another substantial concern. Many scripts appear to have been written for specific Windows versions or Active Directory configurations encountered during particular engagements. There’s no indication of which scripts are actively maintained, which have been superseded by better tools, or which might fail on modern Windows 10/11 systems with current security patches. Windows security features evolve rapidly—UAC, AMSI, Constrained Language Mode, and EDR solutions all affect script execution. Without version information or compatibility matrices, you’re testing blind. Some scripts might trigger antivirus alerts, fail silently on newer systems, or produce incorrect results due to changed Windows internals. This is acceptable for a personal toolkit but requires validation before operational use. You’re essentially inheriting technical debt from someone else’s engagements without the context of when or where these tools were proven effective.
Verdict
Use if: You’re an experienced penetration tester or red teamer who needs quick, purpose-built scripts for specific Windows enumeration or testing scenarios, you’re comfortable reading code to understand functionality, you work in time-sensitive engagements where writing a custom script would take longer than adapting an existing one, or you want examples of practical approaches to common Windows security testing challenges that you can learn from and modify. This repository shines when you need inspiration for solving specific problems or a starting point that’s 80% of what you need. Skip if: You’re looking for production-ready, well-documented tools with active maintenance and support, you’re a beginner who needs extensive documentation and usage examples, you require guaranteed compatibility with modern Windows versions and security features, or you need tools with established testing and validation for compliance-driven engagements. For those scenarios, invest in established frameworks like PowerSploit, BloodHound, or commercial penetration testing platforms that provide the polish and reliability this collection explicitly doesn’t promise.
