Kali Linux ships with every tool you need to run a thorough web application security scan. The part it doesn't solve is the analysis — interpreting output, filtering false positives, deciding what to chase next, connecting findings across tools, and turning raw scan results into something actionable. That gap is exactly where running Claude from the Kali terminal pays off.
Getting Started
Claude Code is Anthropic's CLI and runs in any terminal. Install it with npm:
npm install -g @anthropic-ai/claude-code
Then launch it from your Kali terminal:
claude
From here, you're talking to Claude with full shell access. It can run any Kali tool, read output files, follow up with additional scans, and write findings to markdown files.
The Workflow
When you launch Claude Code directly in your Kali terminal, it has full access to every tool on the system. It runs scans, reads output, and surfaces findings. However, this is not a set-it-and-forget-it process. The human running the session is essential. You know things Claude doesn't: how the application is architected, which endpoints are internal-only, what a 503 from a particular route actually means in context, whether a flagged behavior is a real concern or an intentional design decision. Claude handles the mechanical work and the initial analysis; you provide the judgment. The best sessions are a conversation, not a handoff.
Think of each prompt in this article as the opening line of that conversation. Where it goes from there depends on what you know about the system you're scanning and what you discover along the way.
The Tools
whatweb / Technology Fingerprinting
OWASP: A05 Security Misconfiguration, A06 Vulnerable and Outdated Components
whatweb identifies the technology stack — server software, JavaScript frameworks, CMS platforms — by reading HTTP headers and page content. It's the right first step because what it finds shapes every scan that follows.
Prompt:
Run whatweb on example.com. Tell me what the stack looks like and flag any version numbers or technology disclosures that would help an attacker.
wafw00f / WAF Identification
OWASP: A05 Security Misconfiguration
wafw00f goes beyond detecting whether a WAF is present — it identifies which one. That distinction matters. Different WAF products have different signature sets, different bypass histories, and different coverage gaps. Knowing you're behind Cloudflare versus ModSecurity versus nothing at all changes how you interpret everything else in the scan.
Prompt:
Run wafw00f against example.com. If a WAF is detected, tell me which product it is and what that means for our testing — what it typically catches well and where its coverage tends to be thin. If nothing is detected, flag that as a finding.
sslscan & sslyze / TLS Configuration
OWASP: A02 Cryptographic Failures
These two tools cover TLS from complementary angles. sslscan gives a readable summary of supported protocols and cipher suites. sslyze goes deeper on certificate details and session configuration. Running both takes a couple of minutes.
Prompt:
Run sslscan and sslyze on example.com. Identify any TLS weaknesses — deprecated protocols, weak ciphers, certificate issues, missing HSTS. For each finding, tell me whether it needs immediate attention or whether it's low priority given how modern browsers actually behave.
That last qualifier matters. Not every TLS finding carries the same weight. Claude distinguishes between a protocol that real clients are still negotiating versus one that's technically present but ignored by every browser in use.
nikto / Web Server Misconfiguration Scanning
OWASP: A05 Security Misconfiguration, A06 Vulnerable and Outdated Components
nikto checks for misconfigurations, exposed files, and outdated software signatures across a broad surface. It generates significant noise against modern web apps, particularly SPAs, where client-side routing causes the server to return HTTP 200 for every path — including ones that don't exist.
Nikto scans take time. Claude will run it as a background task and monitor the output file while it works on other things.
Prompt:
Run nikto against example.com. The site is a single-page app, so flag any findings that are likely false positives from the SPA catch-all routing — paths returning 200 that are actually just serving index.html. Confirm suspicious ones with curl before including them as findings. Rank the real findings by severity.
This is where Claude adds the most value over running nikto alone. It correlates the 200 responses against the actual page content, confirms or dismisses each flag, and produces a filtered list rather than a wall of raw output.
gobuster / Directory and File Enumeration
OWASP: A05 Security Misconfiguration, A07 Identification and Authentication Failures
gobuster discovers endpoints that aren't linked from the UI — API routes, admin paths, authentication flows, and internal service paths. On a well-configured app it surfaces the real backend structure.
The SPA catch-all problem applies here too. Claude will handle it by establishing the wildcard response size first and excluding it from results:
Prompt:
Run gobuster against example.com using the common wordlist. First probe a non-existent path to get the wildcard response size, then exclude that length from the scan. For each real path you find, tell me what it likely does and what you'd want to probe next.
Gobuster is often the pivot point in a session. What it finds tells you where to dig — OAuth endpoints suggest auth bypass testing, unknown service paths suggest further enumeration, API roots suggest method and parameter probing.
Follow up prompt:
Gobuster found /oauth/ on example.com. Test it for common OAuth vulnerabilities — redirect_uri bypass, missing state parameter, token leakage in referrer headers. Show me what you find.
What Kali Tools Cannot Cover
Several OWASP Top 10 categories don't have meaningful automated coverage from scanning tools. Worth understanding before assuming a clean set of scans means a clean bill of health.
A01 — Broken Access Control requires understanding what the application is supposed to do and testing whether it enforces that. A scanner can find that an endpoint exists; it cannot determine whether the authorization logic on that endpoint is correct. This is a code review and manual testing problem.
A04 — Insecure Design is an architecture problem. No tool detects it.
A08 — Software and Data Integrity Failures — dependency vulnerabilities — are caught with tools like cargo audit and pnpm audit / npm audit run against the codebase, not from the outside. These aren't scanning tools; they're part of your build process.
A09 — Security Logging and Monitoring Failures requires access to logs and observability infrastructure. Not testable from the outside.
For these OWASP categories, you will need to run Claude on the same machine as the code, and come up with prompts of your own. Claude is very good at discovering vulnerabilities, but it needs the code, not a scan target.
What Claude Adds Across the Whole Session
The most useful thing Claude does in this workflow isn't interpreting any single tool's output. It's maintaining context across all of them. It remembers that the 200 responses nikto flagged are explained by the SPA catch-all confirmed earlier. It knows that a 502 on a path gobuster found means a real upstream service is down, not that the path doesn't exist. It connects what whatweb showed about the server configuration to what gobuster found about the backend structure.
By the end of a session you have a set of findings that already know about each other — not a pile of individual scan outputs. Claude can write those up as GitHub issues as it goes, one per finding class, with severity ratings, reproduction steps, and fix recommendations. The output is directly actionable without a second pass to make it so.
A Note on Scope
A basic familiarity with web security concepts will get you a lot further with this workflow. You don't need to be an expert, but understanding what a WAF is, why TLS configuration matters, and what an authentication flow looks like will help you ask better follow-up questions and recognize when a finding is significant. Similarly, the more you know about how your application is architected — what's behind each path, what services are running, how authentication is handled — the more useful you'll be when Claude surfaces something it can't evaluate on its own. Discovery is a collaboration, and your knowledge of web security and your system is half of it.
Everything here also assumes you own the sites you're scanning or have explicit written authorization to test them. Running these tools against sites you don't control is illegal regardless of what you find. Start with a staging environment if you have one — nikto in particular generates traffic patterns that look like an attack in your own logs.