Winrm -p option worked instead of -H

[xpanoh]

Describe the bug Crackmapexec Winrm -p option worked with hashfile instead of -H

To Reproduce Steps to reproduce the behavior: Install https://cdimage.kali.org/kali-2022.4/kali-linux-2022.4-vmware-amd64.7z Run Crackmapexec winrm -u user -p hashfile against a target used -p option with hashfile

Expected behavior Output does not display (pwned) with -H flag Output displays pwned with -P flag

Screenshots HashFile used No Pwned output despite correct credentials Pwned output with wrong option used

Crackmapexec info

• OS: kali linux rolling
• Version of CME 5.4.0 Installed by default, ran apt update -y

Additional context Add any other context about the problem here.

[mpgn]

I don't recommand to use the version on apt, git clone the projet or use the binary directly :)

[twosevenzero]

@xpanoh I think the issue you are experiencing looks stranger than it truly is.

The hash expected by crackmapexec is just the NT hash (the hash after the colon). If you provide the correct hashes, it works as expected.

(.venv) ➜  CrackMapExec git:(master) ✗ cat hashes.txt 
392fbe2844cb258735c4cbf449d31709

(.venv) ➜  CrackMapExec git:(master) ✗ .venv/bin/crackmapexec winrm 192.168.81.134 -u administrator -p hashes.txt -d burn.lab
HTTP        192.168.81.134  5985   192.168.81.134   [*] http://192.168.81.134:5985/wsman
WINRM       192.168.81.134  5985   192.168.81.134   [-] burn.lab\administrator:392fbe2844cb258735c4cbf449d31709

(.venv) ➜  CrackMapExec git:(master) ✗ .venv/bin/crackmapexec winrm 192.168.81.134 -u administrator -H hashes.txt -d burn.lab
HTTP        192.168.81.134  5985   192.168.81.134   [*] http://192.168.81.134:5985/wsman
WINRM       192.168.81.134  5985   192.168.81.134   [+] burn.lab\administrator:392fbe2844cb258735c4cbf449d31709 (Pwn3d!)

You are likely thinking: "Well why does it work when I put the full NTLM hash for the -p command?".

I think this has to do with how the tools work under the hood. IIRC, they take your plaintext password and convert it to a hash before they execute the command so it is probably seeing that this is already the case and ignoring that. @mpgn can correct me if I am wrong here but it's probably related to that process.

@mpgn I think this issue can be resolved.