How a 45-Day Tool Audit Reveals Your True Attack Surface

By ✦ min read

Introduction

Inside most organizations, the most dangerous activity no longer looks like an attack. It looks like administration. The same trusted utilities your IT team relies on daily—PowerShell, WMIC, netsh, Certutil, MSBuild—are also the preferred toolkit of modern threat actors. By spending 45 days observing how these tools are actually used within your environment, you can uncover the gap between perceived and real attack surface. This guide walks you through a systematic audit that reveals what attackers see: the built-in tools you trust but aren't monitoring.

What You Need

• Centralized logging infrastructure (SIEM or log aggregator)
• Access to event logs from all endpoints (Windows Event Log forwarding)
• Baseline documentation of authorized tool usage
• Script or tool to parse logs (e.g., PowerShell, Python, Splunk)
• 45-day commitment for continuous observation
• Cross-functional team: IT operations, security, and system owners

Step-by-Step Guide

1. Step 1: Inventory Your Trusted Tools

   Begin by listing every native tool your IT and development teams commonly use. This includes command-line utilities (PowerShell, WMIC, netsh, certutil, MSBuild), scripting languages, remote management protocols (RDP, WinRM), and administrative consoles. Document the intended business purpose for each tool. For example, certutil is used for certificate management, MSBuild for building applications, and netsh for network configuration. This inventory becomes your baseline of “known-good” usage.

2. Step 2: Enable Comprehensive Logging

   Configure your endpoints and servers to log every invocation of these tools. At minimum, enable:

   • Command-line process creation (Event ID 4688 on Windows, with command line included)
   • PowerShell script block logging and module logging
   • Windows Remote Management (WinRM) operational logs
   • Sysmon for detailed process and network activity
   Ensure logs are forwarded to your SIEM or centralized collector. Test logging coverage by running a few typical admin tasks to confirm they appear in your logs.

3. Step 3: Establish a 45-Day Observation Window

   The 45-day period is long enough to cover normal operational cycles (weekly patches, monthly reports, quarterly maintenance) while identifying outliers. During this phase, do not change any existing security controls. Your goal is passive observation, not disruption. Assign a team member to review daily logs or set up automated alerts for patterns you haven't seen before. Document every non-standard use—especially scripts that download content or tools invoked outside normal business hours.

4. Step 4: Categorize Observations Into Trusted vs. Suspicious

   After 45 days, review the collected data. Group every event into one of three buckets:

   • Expected usage: Matches your baseline. These are low risk.
   • Unexpected but legitimate: A developer used PowerShell to automate a one-time deployment, or a sysadmin ran netsh to troubleshoot a network issue. Still valid, but note that it wasn’t in your baseline.
   • Anomalous: Command lines that include obfuscation, file downloads (e.g., certutil -urlcache -f), execution from non-standard paths, or scripts that attempt to disable security tools.
   Pay special attention to tools like certutil and MSBuild—they are frequently abused to bypass application whitelisting.

5. Step 5: Map Each Observation to the Real Attack Surface

   For each anomalous event, ask: “If an attacker compromised an account with this tool’s permissions, what could they do?” This reveals your real attack surface—the sum of all actions a trusted tool can perform when misused. For instance, if PowerShell is used by a dozen admins across 500 servers to run scripts that download from external URLs, that’s a massive surface for lateral movement and data exfiltration. Document the potential impact of each finding: privilege escalation, credential theft, persistence, data exfiltration, or defense evasion.

   

6. Step 6: Prioritize Remediation Based on Risk

   Not every unexpected use is a crisis. Prioritize findings by:

   • Frequency of abuse potential (e.g., tools with known MITRE ATT&CK techniques)
   • Breadth of access (server counts, user accounts with permissions)
   • Ease of detection (often-used tools are harder to detect as malicious)
   • Impact if weaponized (e.g., can the tool move laterally or exfiltrate data?)
   Create a remediation timeline: immediate (block dangerous command-line patterns), short-term (restrict tool usage to specific accounts), and long-term (implement application control policies like Windows Defender Application Control).

7. Step 7: Continuously Repeat the Audit Every Quarter

   The 45-day audit is a snapshot. Attackers adapt, and so do your internal processes. Schedule quarterly audits to capture new tools, new scripts, and changes in user behavior. Rotate the focus: one quarter on network tools (netsh, netstat), another on development tools (MSBuild, csc.exe), and another on scripting environments (PowerShell, VBScript). Each rotation deepens your understanding of your real attack surface.

Tips for Success

• Start small: Focus on your most critical servers first (domain controllers, file servers, SQL servers) then expand to user workstations.
• Don’t confuse noise with intelligence: A high volume of expected admin logs can hide malicious behavior. Use baselines to filter out the mundane and spotlight the unusual.
• Involve the IT team early: Explain that this audit isn’t about surveillance—it’s about protecting them from attack. Their cooperation yields better data.
• Use existing frameworks: Map findings to MITRE ATT&CK techniques (e.g., T1059.001 for PowerShell, T1105 for Ingress Tool Transfer via certutil) to communicate risk to stakeholders.
• Automate detection: After the first audit, build rules that flag known suspicious patterns (e.g., certutil downloading from a non-internal URL, PowerShell launching encoded commands).
• Document everything: Keep a running log of each audit’s findings and actions taken. This builds a knowledge base you can reference when new threats emerge.

By following this 45-day audit process, you transform your understanding of attack surface from theoretical to practical. You’ll see exactly which trusted tools are at greatest risk—and you’ll have the evidence to justify tightening controls without disrupting critical operations.