Cracking WMI-exec in Rust by turning impacket into a byte-level oracle

A developer building ADhammer, an Active Directory audit toolkit in Rust, implemented wmiexec from scratch by using impacket as a byte-level debugging oracle. The project, built with Claude Code, involves a from-scratch DCE/RPC, NTLM, SMB2, and Kerberos stack, and the developer diffed wire bytes against a real domain controller until they matched byte-for-byte.

How I implemented wmiexec from scratch in Rust — DCOM activation, OXID resolution, and MS-WMIO object marshaling — by using impacket not as a library but as a debugging oracle, and diffing my wire bytes against it until a Windows DC accepted them byte-for-byte. https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fd4lajsjzsvobz7sfpywd.gif This is a build log from ADhammer, an Active Directory audit + validation toolkit I'm writing in Rust on a from-scratch DCE/RPC · NTLM · SMB2 · Kerberos stack think "impacket for Rust" . The whole project is built with Claude Code, and this post is the single best example of what that actually looks like — not autocomplete, but a tight loop of hypothesis → capture live traffic → diff → fix against a real domain controller. The goal: wmiexec, from scratch wmiexec is the classic "quiet" remote-code-execution technique: 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 flavour of pain: