Not working INVALID_PARAMETER

[chosenonehacks]

Hi I have tested it on vulnerable Windows 7 and Windows 2008 none of them worked:

SMB1 session setup allocate nonpaged pool success SMB1 session setup allocate nonpaged pool success good response status: INVALID_PARAMETER done

no shell back in msf

[3ndG4me]

Hey @hal9k2 would you mind running the eternalblue_checker.py against the machines your testing and sharing the output?

The output that you're seeing is standard and not indicative of any errors (although I do think it should be modified and I will look into it), but if you're not getting a shell back then something is obviously wrong. Windows7 and Windows Server 2008 are the two versions I have tested on the most and had the most success.

Like I stated above send me the output of the checker, and I'll look into this further.

[chosenonehacks]

Hi, thanks for the answer. So below resutls of checker:

root@kali:~/Dropbox/Tools/exploits/AutoBlue-MS17-010# python eternalblue_checker.py 10.XX.XX.XX Target OS: Windows Server 2008 R2 Standard 7601 Service Pack 1 The target is not patched

=== Testing named pipes === spoolss: STATUS_ACCESS_DENIED samr: Ok (64 bit) netlogon: Ok (64 bit) lsarpc: Ok (64 bit) browser: STATUS_ACCESS_DENIED root@kali:~/Dropbox/Tools/exploits/AutoBlue-MS17-010# python eternalblue_checker.py 10.XX.XX.XX Target OS: Windows 7 Ultimate N 7600 The target is not patched

=== Testing named pipes === spoolss: STATUS_ACCESS_DENIED samr: STATUS_ACCESS_DENIED netlogon: STATUS_ACCESS_DENIED lsarpc: STATUS_ACCESS_DENIED browser: STATUS_ACCESS_DENIED

Nmap smb-vuln for Windows 7

Host script results:	smb-vuln-ms17-010:	VULNERABLE:	Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)	State: VULNERABLE	IDs: CVE:CVE-2017-0143	Risk factor: HIGH	A critical remote code execution vulnerability exists in Microsoft SMBv1	servers (ms17-010).
Disclosure date: 2017-03-14
References:
https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/
https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
_ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0143

And for Windows 2008 Host script results:	smb-vuln-ms17-010:	VULNERABLE:	Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)	State: VULNERABLE	IDs: CVE:CVE-2017-0143	Risk factor: HIGH	A critical remote code execution vulnerability exists in Microsoft SMBv1	servers (ms17-010).
Disclosure date: 2017-03-14
References:
https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/
_ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0143

I used shell created with help of shell_prep.sh My command was like: python eternalblue_exploit7.py 10.XX.XX.XX sc_all.bin

[3ndG4me]

Perfect, thanks for your help. You seem to be doing everything correctly as far as tool usage is concerned. I’ll be able to use the version information to look into this and see if perhaps there are some version specific issues that are unaccounted for.

Thank you for bringing this issue to my attention hopefully I’ll resolve it ASAP! If you happen to determine and solve the problem in the mean time, feel free to contribute your solution in a pull request related to this issue.

[halfluke]

It happened to me as well, while I was trying to exploit without Metasploit, the HacktheBox retired machine named Blue - preparing for the OSCP :-) At first it was due because I used the wrong IP as listener (my eth0 interface instead of the vpn interface), but then it still happened. What I noticed is that the metasploit module, that never fails, doesn't always succeed in the same way. Sometimes it needs a couple of tries (that does automatically), and it tries of different values of what in eternalblue_exploit7.py is called GroomConn. It turns out that there is a 4th parameter in the python script, that if you do not specify, defaults to 13. The metasploit module starts with 12 and then tries 17 (at least for 'Blue'...) The technical details of this are far beyond my current level, but I ran the script with 12 (and 17) as 4th parameter and I got a shell. If I exit the shell and try again without any GroomConn parameter (which means 13), this time I get a shell. Similarly, using the metasploit exploit, the first time it succeeds with 12. If I exit meterpreter and try again, 12 fails and it has to try again with 17, then it succeeds. As I said, I'm not sure what this means. The exploit looks pretty reliable but I don't know if an explanation to this behavior is simple or something that needs a deep understanding of how the exploit and the shellcode work. A final note is that the metasploit module compatible payloads (show payloads) returns only x64 payloads. Blue is an x64 machine. Hope this helps...

[3ndG4me]

@halfluke Thanks for your feedback!

You are right, in order to get success with this exploit you may have to try running it more than once and sometimes even with variable Groom Connections, even with the metasploit module.

Groom Connections are connections you are opening up to try and chain together kernel pool memory so that you can write to the buffer from a desired location. It gives the exploit some on the fly consistency in attempting to write to the buffer. I will update the docs to include this parameter, it was not originally included in the instructions/documentation because I assumed most people were aware of the optional feature from the original version that this code is forked from.

As far as stability, this exploit is actually not very stable or consistent at all. Varying success is expected. It will always work on a vulnerable system, but like you said sometimes it takes a few tries, so the frequency of success is variable and the exploit is also very unstable and is known to crash the exploitable service and sometimes even crash the box itself, so keep that in mind when applying this in the real world on pen-tests and even on the OSCP as it does have the potential to knock over a box. I personally am still researching the more stable variants on this exploit like eternalromance.

If you would like some more technical knowledge in regards to this exploit there is a fantastic write up paper by RiskSense that I recommend: https://www.risksense.com/_api/filesystem/466/EternalBlue_RiskSense-Exploit-Analysis-and-Port-to-Microsoft-Windows-10_v1_2.pdf

As far as this issue is concerned I will hopefully get around to testing it very soon just in case it is legitimate, but to anyone else having the same problem please try the advice from @halfluke and re-run the exploit more than once.

[halfluke]

Thanks for your reply. I will read the pdf! I've just fixed my previous post where I messed up some GroomConn values :) Perhaps it looked reliable to me because it always works on 'Blue' (via metasploit) Thanks again.

[3ndG4me]

After some research, I have been able to determine this is not a bug with these scripts, but more of a stability issue with the exploit as discussed above. If you run into this problem in the future, try adjusting groom connections or retry the exploit. Keep in mind that retrying the exploit without success could indicate the service has crashed and is no longer exploitable.

If there are further optimizations around this anyone would like to contribute feel free, otherwise there is no general issues with the code itself as far as I can tell.

[mhindman]

The RiskSense link looks like its old here is the replacement one @3ndG4me if interested :)

https://risksense.com/wp-content/uploads/2018/05/White-Paper_Eternal-Blue.pdf