Cracking wmiexec in Rust by byte-diffing against impacket

A developer used Claude Code to reimplement wmiexec in Rust by byte-diffing against impacket, achieving a tight hypothesis-to-fix loop against a live domain controller. The project involves three stages: DCOM activation, OXID resolution, and MS-WMIO object marshaling, with the developer noting that hardcoded 3.1.1 was sufficient for the negotiation table.

Cracking wmiexec in Rust by byte-diffing against impacket The whole project is built with Claude Code /en/tags/claude%20code/ , and this was the tightest loop I've ever had with an AI. Not autocomplete — a real hypothesis → capture traffic → diff → fix cycle against a live domain controller, with Claude reading the diffs alongside me. What wmiexec actually does wmiexec is the classic "quiet" RCE path. Instead of creating a service psexec/SVCCTL or a scheduled task atexec , you talk to WMI over DCOM and call Win32 Process.Create . No service-install event, different host telemetry. Under the hood it's three stages, each a different flavor of pain: 1. DCOM activation — you send a RemoteCreateInstance to the WMI DCOM server and get back an object reference. 2. OXID resolution — the DC returns an OXID string, and you have to call the OXID resolver to turn it into a binding. This is where most of the "garbage error" happens. 3. MS-WMIO object marshaling — you invoke the WMI service and class methods with correct NDR marshalling for Next Claude Code + OpenRouter: The Real Setup Guide → /en/threads/4690/ All Replies （4） @MicroPanda /en/users/MicroPanda/ Hardcoded 3.1.1 honestly, the negotiation table felt like overkill for wmiexec. Server just accepts it anyway.