Windows 7 Eternal Blue Iso

0 views
Skip to first unread message

Rolando Kumar

unread,
Aug 3, 2024, 11:35:39 AM8/3/24
to nonpverrentgang

Failed to get version of 'C:\WINDOWS\system32\Drivers\srv.sys'.
We are unable to tell if your computer is vulnerable.
I get this message every time I use the eternal blue checker, how to check manually or fix this?

Also I realized why srv.sys no longer exists on my device. Windows will auto remove SMBv1 10 days after installation if it is not used. Additionally if srv.sys exists on later Win 10 installations, you are not vulnerable since this driver has been patched against this exploit.

I've tried recently to run the EternalBlue exploit via metasploit (on VirtualBox lan), and I've spotted that if the victim PC uses the most naive windows-firewall than the attack would fail. That got me thinking - how initially attackers used this exploit to run WannaCry-like ransomware, how did they bypass firewalls to execute the exploit ?

If you attack an open port that is allowed to receive connections from your particular host -- and the target is exploitable -- you should be able to retrieve a reverse shell from the target, provided you used the correct settings.

Eternalblue targets tcp port 445 running SMB, and in some cases 139 as well. Windows firewall don't normally block access to this port as it's supposed to be used for internetworking between domain users. A sure way to check would be to scan and see if the port appears as open. If it does and you are able to identify it as SMB, then windows firewall is definitely not blocking any connection to it.

The easiest way to find an environment to test on, is to get Hack The Box VIP and attack the Blue machine which is already vulnerable to this exploit.To setup up your local vm, try Metasploitable 3 Metasploitable3I will go with the Metasploitable for now. For the EternalBlue to work I had to disable the firewall on metasploitable3.Metasploitable IP: 10.0.2.15

Running the exploit code will execute and create C:\pwned.txt on the machine.We can log in and check the file. It should be there. That is ok but vagrant is an admin user. If we have credentials then we probably do not need this exploit at all.


Adding these credentials to our exploit and running it, will once again create the file pwned.txt This means that we have non-admin credentials but we could still execute commands as admin.We can see on the included picture below that the user test cannot delete the file.

This way when the file gets downloaded with powershell, we will immediately call the Invoke-PowerShellTCP function with our ip address and port to connect back to. I also renamed the file to test.ps1Next we need to download the file with our exploit. For this we only need one line in our function.

Here we spawn cmd and from there we will call powershell to download and execute the ps1 script that is hosted in our machine. Notice that by adding the extra line to the script, we just need to download the file to get a revers shell.Finaly we need to host the script somehow. For this go into the folder where the test.ps1 is located and create a http server. For example with:

We will need 3 command window for this to work. one to host our PowerShell Payload, one for the Reverse Shell listener and one which will execute the exploit itself.We can observe it worked. The exploit pulled the file from our server and we got the reverse TCP powershell back.

We looked at various ways to exploit eternal blue with a valid pipename. But what if whe have no pipe name. We need a way to still exploit it. We have one but it is more likely to crash the target.To make this work, first we need to clone the full repo of MS17-010 from worawit.

We will focus on the shellcode first. Going into the folder shellcode and reading the file eternalblue_sc_merge.py we can get an idea how to create our shellcode and use it with this exploit.First we need to assemble the shell code

We will create our exploit in raw format and add an exit function to try to make a clean exit and minimise the chances of a crash.Now we need to combine our payloads with the created shellcode then merge them.

We now have our exploit binary. All we have to do is to execute the exploit and wait for our shell.Going back one folder and executing the exploit, we are getting and error and a successful reverse shell.


It probably would be fine to use just the x86 version and not merge the two exploits. But in case we only want to use one exploit then we should scan carefully for the windows version and architecture.

In this long blog post, We looked at multiple ways to use the exploit EternalBlue with and without pipename. We created reverse shells and injected our own administrator user. I hope this blog post clears the confusion among the people trying to Eternal Blue without Metasploit. This is part 1 of this series and more blog posts are on their way. Cheers!

Operating System vulnerabilities are very common especially with Microsoft Windows. These vulnerabilities can be exploited in different ways which can give system-level access to the adversaries trying to break into the system. One such vulnerability is going to be discussed in this article. As a proof of concept, I would be exploiting a very famous vulnerability found in Microsoft Windows which is known as Eternal Blue. The machine I am going to exploit is available on the TryHackMe Platform. So without much further ado lets start!

Getting a shell is not enough, we have to escalate our privileges to perform administrator-level operations on the system. First, we need to upgrade our shell to meterpreter as it gives a lot of functionalities as compared to normal shell. For this purpose, we need to search for POST exploit in Metasploit.

Now that we have complete access to the NT Authority system via the migration of higher privileged process. Its time to crack some passwords to login using the credentials of the user. Use hash-dump to dump all the hashes from the SAM database. From this, we get the name of the non-default user (Task1).

To find the second flag look for the folder that is utilized to store the passwords of windows. You should find the location by simply googling. Navigate to the folder and there you will find the flag2.

To find out the last flag, you have to be smart. So what I did was search for the file name starting with the flag, from the results that came out I was able to navigate to that particular folder and get my last flag. If you are unable to access the directory as shown below use \\ before the directory and file name and this will solve the non-access issue.

The eternal blue vulnerability was very famous and many systems were compromised using this vulnerability. Microsoft released fixes to patch up these vulnerabilities for different Operating systems. With this, we conclude that using such vulnerabilities systems can be compromised and the adversary could use it in any way he pleases. So it is recommended to always keep your software and windows updated with the latest version, fixes, and patches to reduce the risk of being compromised by such vulnerabilities.

If you enjoyed this article or found it helpful please consider making a U.S. tax-deductible donation, Secjuice is a non-profit and volunteer-based publication powered by donations. We will use your donation to help cover our hosting costs and keep Secjuice an advertisement and sponsor free zone.

If you enjoyed this article or found it helpful please consider buying us a coffee, Secjuice is a non-profit and volunteer-based publication powered by caffeine. We will use your coffee money to help cover our Ghost Pro hosting costs and keep Secjuice an advertisement and sponsor free zone.

The primary issue I am trying to resolve is getting eternalblue data to traverse the socks proxy using "set ReverseAllowProxy true", it may be a case where is it not even supported.
The socks setup itself does work, I am able to run the setup on Windows and successfully tunnel (IP range scan) through the tunnel using Proxify.
It looks like the route is attempting to use the public IP address of the sock proxy and/or target machine, rather than the loopback socks path.

A couple of things to note:
I have removed the public IP addresses from the output.
I have attempted setting PROCESSINJECT = lsass.exe and also TARGETARCHITECTURE = x64 .... These gave the same results as posted.
10.7.0.62 is the private address of tun0/vpn
port 8484 is open through the vpn via port forwarding. It is not in use prior to running.
Kali Version - 2020.1
Kali Installation - Virtubox VM , running installed version.

c80f0f1006
Reply all
Reply to author
Forward
0 new messages