On many real Windows fleets—and plenty of AD labs—WinRM is left on HTTP 5985 but configured with AllowUnencrypted=false. Authentication can succeed while the first real command dies: the host refuses plaintext SOAP after NTLM.
Erebus already sealed the password path via masterzen's NTLM encryption helper. The NT hash / pass-the-hash path did not. That gap showed up the moment operators tried PTH against a sealed host and had to jump to an external client just to run whoami.
This week we closed that gap on main (7d54bae): the hash transport negotiates Sign/Seal, builds a security session, and wraps SOAP in the same SPNEGO multipart envelope Windows expects.
Erebus is for authorized red team, internal security testing, and research labs with explicit permission. This post is product engineering—not a walkthrough of any live ranked machine.
What broke before
Password-based WinRM used library encryption. Hash-based WinRM completed NTLM, then posted unencrypted SOAP. On sealed hosts that looks like:
- HTTP 415 or encryption-related faults after auth looks fine
- Operator (or AI agent) wrongly assumes the hash is wrong, when the real issue is message encryption
- Forced detour to pypsrp / evil-winrm / other tooling mid-engagement just for lateral
That is not a nice-to-have. Lateral movement is where AI-assisted workflows either stay inside one C2 surface—or leak context into a pile of one-off scripts.
What shipped
Hash path seals SOAP
The custom NTLM-hash WinRM transport now:
- Negotiates NTLM with Sign / Seal / Key Exchange flags so session keys exist
- Derives a security session after TYPE3 (including MIC when the DC requires it)
- Wraps SOAP in WinRM's
multipart/encryptedSPNEGO envelope - Unwraps encrypted responses on the same sticky session (single connection, keep-alive)
Permissive fallback
Labs and fleets are not uniform. Some hosts allow unencrypted WinRM. Some reject our seal attempt for edge reasons. The transport is intentionally prefer encrypt, then fall back:
- Try sealed SOAP when Sign/Seal was negotiated
- On 415 / encryption-related rejection, retry once with plain SOAP and prefer plain for later posts on that client
- Soft-accept responses that look like SOAP/XML even when unseal is imperfect
- Soft-fail security-session setup so auth still works on hosts that never grant Seal
# Operator-style lateral (hash path)
lateral winrm <host> "whoami" \
--user ACCOUNT --domain NETBIOS --hash <32-hex-NT>
# Prefer DOMAIN\user or explicit NETBIOS domain — NTLMv2 cares
Password vs hash (operator view)
| Path | Before | Now |
|---|---|---|
| Password | NTLM seal via masterzen Encryption | Unchanged — still preferred when password is available |
| NT hash (PTH) | Auth only; plaintext SOAP | Seals when negotiated; plain fallback if rejected |
| Sealed host | External tool detour for PTH | Stay on Erebus lateral when eng-verify is green |
What we still call unfinished
Unit tests cover wrap/unwrap round-trips, MIME framing, MIC TYPE3 layout, and the fallback heuristics. That is necessary—not sufficient.
Live eng-verify against a host with AllowUnencrypted=false remains the gate for calling parity "done forever." Windows is the real peer; our crypto self-tests are not. If a sealed lab still rejects the sealed path, the plain fallback keeps the engagement moving while we capture wire diffs.
That honesty is deliberate. Erebus is supposed to be engagement-shaped: ship the capability, document the remaining lab gate, and avoid marketing checkboxes that lie.
Get it
Source is on GitHub. Pull main, rebuild the Go implant / operator path you use, and exercise WinRM lateral with a 32-hex NT hash on an authorized lab host.
$ git clone https://github.com/KKingZero/Erebus.git
commit: 7d54bae — WinRM PTH message encryption
scope: authorized labs and engagements only
If you are building AI-assisted offensive workflows, this matters because lateral is where autonomy either stays inside the C2 control plane—or fragments into tools the agent cannot see. Sealed WinRM on the hash path is one more place the operator (and the agent) can stay on-framework.