Closed 0xSeanG closed 4 years ago
Hmm, wondering if this is due to out-of-date impacket submodule or what exactly. Can you check what responder's runfinger shows for the smb_signing? https://github.com/lgandx/Responder/blob/master/tools/RunFinger.py
i see a commit in april in impacket changing how the signing flag was obtained in smb3.py (smb3 covers v2+v3) so that might be it? ill try and test myself soon.
I'm guessing --gen-relay-list is showing the host as not requiring signing as well?
Correct on gen-relay-list... I'll check on runfinger in the morning and report back
tested on win7 and its working as it should, must be win10 specific. testing that next
Having issues with RunFinger.py... which makes me think the issue may be on my end and not the tool... Some of the w10 machines finger printed accurately.
starting to test on win10. Trying to get a baseline and getting weird results though.
Using regedit to flip flags on and off and just so we're on the same page. hklm\system\currentcontrolset\services\lanmanserver\parameters
It's an issue in impacket, which cme uses for smb connection stuffs.
Fixed in the latest version though so you need to update the submodule. then rebuild cme
To manually do this:
from the root of where you have cme cloned i.e. /opt/CrackMapExec
# cd cme/thirdparty/impacket/
# git fetch
...stuff...
# git pull
...stuff...
# cd ../../../ (change back to root folder of cme)
# ./setup.py install
Should be fixed so i'm closing, thank you @awsmhacks :)
Steps to reproduce
Command string used
cme smb [target]
CME verbose output (using the --verbose flag)
n/a - cme error
CME Version (cme --version)
4.0.1dev
OS
Kali
Target OS
Windows 10
Detailed issue explanation
confirmed local sec pol matches the nmap results