Router Pentest with Claude: A Practical Security Assessment Methodology

Want to use AI to accelerate router security assessments? In this router pentest guide with Claude, you will see a practical methodology, common findings, and hardening actions.

I took my hands off the keyboard and watched. I gave Claude Desktop a lab target, an MCP server with limited tools, and a clear instruction: perform full recon and document it. No hints, no copilot. Just autonomous decisions.

The real setup

• Target: Huawei WiFi AX2 (WS7001-20/WS7001-40), firmware WS7001-20-2.0.0.322_SP1C947
• Attacker: Claude Desktop connected to a custom MCP server on Kali Linux in Docker
• Note: the MCP server was created through trial and error using Claude itself, with no public base project
• Environment: isolated lab, dedicated Docker network, full authorization, logs with hash and timestamp

What the AI did on its own in 17 minutes

Actual report timeline: started at 00:47 UTC, critical finding at 01:04 UTC.

The critical finding

The /api/system/deviceinfo endpoint exposed the following without login: csrf_param, csrf_token, SerialNumber a70eef7f, uuid, and a full capability map (TR-069, UPnP, remote management, port forwarding, IPv6, WPA3).

Practical impact: CSRF protection bypass on the LAN, exposed serial number feeding default passwords based on serials (a historical Huawei pattern), and full reconnaissance without credentials.

The AI correlated this with CVE-2022-48469 (traffic hijacking, CVSS 7.6), CVE-2023-7266 (LAN connection hijacking), and CVE-2022-48470 (HiLink), all with medium confidence due to the lack of official confirmation for the WS7001.

Huawei’s response and why I took time to publish

A responsible disclosure was submitted. Response: “this is not a vulnerability”. The vendor’s interpretation: expected behavior for a LAN-only interface. My interpretation: real risk in a compromised LAN scenario, poorly segmented IoT, or guest Wi-Fi.

Decision: publish the method and the finding, not a weaponized exploit. Transparency requires caution when the vendor disagrees.

What I changed in the workflow after the first test

1. Real isolation: Docker network with no egress, cap-drop, snapshot before each run
2. MCP guardrails: allowlist only for nmap, nikto, curl, dig, and parsers. Destructive actions blocked
3. Observability: tee with SHA256 hash, Markdown report in Obsidian generated by Claude

Lessons for red team and blue team

Offense

AI does not replace judgment, but it accelerates recon and correlation. It did in 17 minutes what would take 1 to 2 hours manually. The value is in structured documentation with confidence levels.

Defense

• Audit /api/system/deviceinfo on Huawei AX2/AX3 firmware
• Disable remote management, UPnP, and TR-069 if they are not used by the ISP
• Change the admin password; do not use a default derived from the serial number
• Segment IoT into a separate VLAN
• Monitor access to unauthenticated /api/* endpoints

How to reproduce safely (without turning it into a crime)

Legal notice: in Brazil, pentesting without authorization is a crime (Art. 154-A). Use this only on equipment you own.

1. Bring up Kali in Docker with an isolated network
2. Create an MCP server with recon-only tools
3. Connect Claude Desktop via MCP
4. Define the scope in writing: target IP, time window, allowed tools
5. Log everything. Do not test brute force or RCE without a controlled environment

Complete materials

• Report generated by Claude on GitHub: https://github.com/pog007/claude-report-huawei
• Full video: https://www.youtube.com/watch?v=5TnbHZLwqFo

I want to hear from you

If you work with AI in security: is the vendor’s refusal acceptable when the vector requires LAN access but exposes CSRF and the serial number without auth? Where do you draw the autonomy line: recon only, recon+scan, or assisted exploitation with a human in the loop?

Leave your thoughts in the comments.