Content
87%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A tight, highly actionable operational reference that uses matrices and real ntlmrelayx/hashcat commands to convey a lot with few tokens. The main gap is the absence of explicit validation/verification steps in the destructive relay chains.
Suggestions
Add an explicit verification checkpoint after each destructive chain, e.g. check that msDS-AllowedToActOnBehalfOfOtherIdentity was set before running getST, or confirm the KeyCredentialLink was written before certipy auth.
For the multi-relay and MSSQL xp_cmdshell examples, note how to confirm a relay succeeded (expected ntlmrelayx output lines) so the operator can detect failure mid-chain.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Lean and efficient — tables for the target/signing matrices and copy-paste code blocks with no padding explaining what NTLM or relay is; every section adds operational value and assumes competence. | 3 / 3 |
Actionability | Provides fully executable commands such as `impacket-ntlmrelayx -t ldap://dc.target.local --delegate-access --escalate-user 'lowpriv'`, `impacket-getST ...`, `crackmapexec smb ... --gen-relay-list`, and `hashcat -m 5600`, copy-paste ready with expected outcomes in comments. | 3 / 3 |
Workflow Clarity | Chains are sequenced (coerce → relay → S4U2Proxy) with inline comments, but the destructive operations (RBCD, shadow creds, Domain Admin escalation) lack explicit verification checkpoints, capping workflow clarity at 2 per the destructive-ops guideline. | 2 / 3 |
Progressive Disclosure | A focused, self-contained ~110-line reference organized into clear sections (target matrix, signing, chains, crack-vs-relay, mitigations, OPSEC, references) with one-level external references and no nested/2+-level-deep references; no bundle files exist to score against. | 3 / 3 |
Total | 11 / 12 Passed |