byt3bl33d3r/CrackMapExec

Winrm -p option worked instead of -H

xpanoh opened this issue · 2 comments

xpanoh commented

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
image
No Pwned output despite correct credentials
image
Pwned output with wrong option used
image

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 commented

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

twosevenzero commented

@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.