Hacking Windows using Eternalblue - [THM] Walk-through

In 2017 the EternalBlue exploit was leaked to the public by a hacker group known as the Shadow Brokers. EternalBlue is a software vulnerability in Microsoft's Windows operating system Server Messaging Block (SMB) protocol, specifically SMBv1, and also happens to be the name of the exploit that the Shadow Brokers claim was developed and weaponized by the National Security Agency (NSA) to take advantage of this vulnerability.

This walk-through will demonstrate how EternalBlue can be leveraged to exploit the EternalBlue vulnerability in the Windows SMB protocol allowing an attacker to manipulate flaws to remotely execute code, gain access, and elevate privileges on the remote target. 

Enumerate the target 

We begin by enumerating our target using rustscan. RustScan is an open-source scanning tool, written in the Rust language, that works with Nmap but turns a 17 minute Nmap scan into about 60 seconds give or take. Either way it is much faster. The -- in the command signifies the end of rust commands and the beginning of Nmap scripts command. In this case we are running Nmap's "vuln" script.

 

We can see from the output that the target system is listening on ports 139 (NetBIOS) and 445. Therefore, we can deduce that this system most likely has SMB running which we also confirmed using Nmap's vuln script as it identified that the target is indeed vulnerable to SMB remote code execution (RCE) vulnerability MS17-01.

Armed with this knowledge we can now move on to the...

Exploitation Phase

To start the exploitation phase we will fire up the Metasploit Framework (MSF) on our Kali attack system and execute a search for "eternal".

 

 

The search provides us with several results. The first one is an SMB Remote Windows kernel pool corruption exploit. We will choose that one. Next, we run show options to see what we have to configure for the attack. Looks like we have to set the remote host (RHOST- victim) and the local host (LHOST -  attacker)

 

Our victim's IP address (RHOST) is 10.10.22.244, now we have to find out IP address (LHOST). 

 

Next we configure and launch the exploit in MSF. The port settings (LPORT) will default to 4444.

The exploit runs and....Winner winner chicken dinner! The exploit was successful and we now have a reverse TCP shell as the NT System account.

Although we landed in a meterpreter session we can us the shell command to get a Windows shell and run whoami to further validate we are NT AUTHORITY\SYSTEM. CNTRL-Z sends shell to background and brings us back to Meterpreter.

 

Privilege Escalation 

Just because we are system doesn't mean our process is. So we want to find a process  that is running at NT AUTHORITY\SYSTEM. We executed the "ps" command and see that winlogon.exe runs as system. We use the "migrate" command to migrate to the winlogon.exe process. Now that we are sure that we are in an elevated Meterpreter shell we will execute a hashdump to dump the non-default user's password and crack it.

 

Once we have the hash for "Jon" there are a couple of ways to go about cracking the password. For the first way we can use a site called CrackStation. 

 

Another way to crack the password would be to use a tool that is local to our Kali attack box. The tool is John the Ripper. 

Now that we have cracked the password it is time to capture the flags. All the flags on TryHackMe have a clue as to where they are located. The clue for the first flag is that it can be found at the system root. 

Flag2? This flag can be found at the location where passwords are stored within Windows.

flag3? This flag can be found in an excellent location to loot. After all, Administrators (our "Jon" account is a local admin) usually have pretty interesting things saved.

Finally and easier way to find the flags using the Windows command line would be to cd to the top-level drive and run the following command C:\ dir /s *flag* this will show you the location of all the flags.

I appreciate you taking the time to read through and comment on this walk-through. I have taken you all the way to the point of locating the flags. I will leave it up to you to figure out the last step. How to read them #tryharder ;-). Thanks again! and until next time...Happy Hunting!

Nmap: Use the -sn, - -top-ports, and -sV options to Identify Active Hosts and Vulnerable Services

If you are just starting out in cybersecurity and considering the area of penetration testing (Red Teaming) you may be wondering how do pentesters (or attackers for that matter) know what ports are open on a system? Or how do they identify what services are running on a particular system? If you are considering a career in cybersecurity, particularly related to network security or penetration testing then there is a handy little tool that you should become familiar with. That tool is Nmap. 

Nmap is a free and open source network scanning utility that has many uses that include basic network scanning, identifying what services a host is running, "fingerprinting" both the operating system and applications that are on a host, vulnerability scanning and much more. In this tutorial, I will cover at a high level some of the basics of using Nmap. Utilizing its command-line interface (CLI) (it does have a GUI) I will provide some examples that you can use quickly as a beginning security professional.

One of the first and most basic scans you can do with Nmap is to execute a ping sweep (-sn) scan. This type of scan is used to attempt to identify active hosts that are up on the network.

Fig. 1 nmap -sn 

Another useful scanning technique is to utilize the --top-ports tag. From the Nmap website…

 

“The –top-ports option lets you specify the number of ports you wish to scan in each protocol and will pick the most popular ports for you based on the new frequency data. For both TCP and UDP, the top 10 ports get you roughly half of the open ports. The top 1,000 (out of 65,536) will find roughly 93% of the open TCP ports and more than 95% of open UDP ports.”

93%...I’ll take that any day! But for this particular example, we are only going to look for the top 10 TCP ports and we will only scan a range of ten hosts. Notice in the output that we scanned a range of ten hosts but only three responded. This is not uncommon. Also, notice the otherwise very interesting output. There are several services running that should be making you want to follow up with our next example.

Fig. 2 nmap -sT --top-ports=10

The last scan identified a hand full of services running on the three systems and a couple of them should look very interesting if you are a security professional. With that said, the last scan we will go over in this post will show you how to follow up on the previous scan. This next scan will attempt to identify the service versions (-sV) running on the hosts identified previously.

Fig. 3 nmap -sT -sV --top-ports=10 

At this point as a security professional, depending on which team you are playing for you will either be extremely excited or extremely worried. If you are a RED TEAMER then you are so excited and should be rushing to launch your exploitation tool of choice. But, if you are a BLUE TEAMER then you are probably, picking yourself up off of the floor and transitioning into more of an Incident Response mindset.

SECURITY.TXT

While listening to a recent episode of Security Now Steve Gibson discussed some help that is on the way for securing web sites and services. I have not seen much mention of it anywhere else but I feel that it is definitely something worth noting.

When it comes to identifying security risks in web sites and services a major problem in the industry has been two-fold. First security researchers have been weary of testing the security of a sites and services because of legal action that may be taken against them and second when and if they do test a site, and they discover a vulnerability in the site or service, there often lacks a way to properly disclose the vulnerability to the developers. Because of the lack of disclosure options often the identified vulnerability just goes unreported and therefore remains out in the wild providing the adversary with many avenues and vulnerabilities to attack.

This is where a web developer and security researcher, Ed Foudil, and what he has submitted to the IETF, steps in to save the day. Mr. Foudil has graciously submitted to the IETF a draft that seeks to standardize SECURITY.TXT. According to securitytxt.org "The main purpose of the security.txt file is to help make things easier for companies and security researchers when trying to secure platforms. Thanks to security.txt, security researchers can easily get in touch with companies about security issues."

Security.txt is a simple text file, similar to a robot.txt file, located in the root directory of a website that defines a standard to help organizations define the process for security researchers to securely disclose security vulnerabilities that they have identified. Not only does this file provide you with the proper contact information but it also provides one with a secure way to transfer the information as outlined below taken from the draft IETF which can be read HERE

2.4.  Encryption:
   This directive allows you to add your key for encrypted
   communication.  You MUST NOT directly add your PGP key.  The value
   MUST be a link to a page which contains your key.  Keys SHOULD be
   loaded over HTTPS.
   <CODE BEGINS>
   Encryption: https://example.com/pgp-key.txt
   <CODE ENDS>

As Steve Gibson said "this is so simple it's brilliant" and should be applauded!

CYBER SECURITY LAB USING MICROSOFT HYPER-V PART 1

CYBER SECURITY LAB USING MICROSOFT HYPER-V

PART  1

This series of blog posts will outline the steps taken to stand up a cyber security lab using Microsoft's Hyper-V. This lab will be used for everything from running Kali LINUX penetration testing tools, offensive countermeasures and techniques using tools like Active Defense Harbinger Distribution, cyber forensics, and anything else that I may choose. I will be using a hosted Hyper-visor for the lab, Microsoft's Client Hyper-V running on Windows 10 Professional. Anyway, enough is enough let’s get started!

The first thing we have to do is to navigate to Control Panel -> All Control Panel Items  ->  Programs and Features.

Next enable the Hyper-V option

After Windows installs the Hyper-V feature you will need to reboot your host system. Once the host comes back up we will begin customizing some of the Hyper-V settings. The first setting that will be configured will be the Server settings. The server settings affect how the Hyper-V server functions.

The first server setting that we will configure is Virtual Hard Disks (VHD). The VHD setting identifies where on our host system the vhd (or vhdx) files will be stored.

After identifying where to store the vhd and vhx files we will do the same for Virtual Machines. On the left pane select Virtual Machines. This setting specifies the default folder to store vm configuration files.

Next is Physical GPUs. This setting determines whether or not VMs with have direct hardware access to any installed GPUs on our host system. This setting is not applicable to our environment so we will make sure that Use this GPU with RemoteFX is unchecked.

We will also leave the next setting, NUMA Spanning and Storage Migrations alone as it too is not applicable to our environment (if you want to know more about this setting you can read about it at https://technet.microsoft.com/en-us/library/dn282282(v=ws.11).aspx). We will also not be doing anything with the Storage Migrations setting as we really don’t have a need to move or migrate any VMs in our lab environment.

The final server setting, Enhanced Session Mode Policy, is one of the most import. You can find out more about it HERE but in a nutshell this setting provides functionality similar to the way RDP allows access to local resources and Enhanced Session Mode brings similar functionality using VMConnect. One needs to be very careful with this feature because this is where one can break segmentation and isolation between the VM host and the VMs in the lab setup. And since we will be using this lab for all sorts of nefarious things as a precaution we will NOT be enabling this feature. We can always enable it in the future should it be needed.

Finally, we have the User Settings. These are pretty straight forward and do not require any customizing. The only thing to check and verify is ensure that the Use enhanced session mode box is unchecked. Once complete click APPLY and then OK

DID SOMEBODY SAY KRACK?!

DID SOMEBODY SAY KRACK?!

What is KRACK?

KRACK is the acronym for Key Reinstallation Attacks.

Earlier this week it was revealed publicly that computer security researcher Mathy Vanhoef (@vanhoefm) had discovered a “serious weakness” in the Wi-Fi Protected Access 2 (WPA2) protocol. This is indeed important because WPA2 is by far the most popular encryption standard for Wi-Fi networks in use today and is pretty much the de facto standard for securing all Wi-Fi networks. Everything from home Wi-Fi to public hotspots up to enterprise wireless networks rely on the confidentiality and integrity provided by the WPA2 protocol.

How an attack using KRACK works?

The vulnerabilities identified by Vanhoef is in the Wi-Fi standard itself and not in any one individual product. This means that any attack that is successfully able to exploit these vulnerabilities will work against any properly configured WPA2 protected network.

The main attack vector is against the WPA2 protocol’s 4-way handshake. This handshake is performed when a client requests to join the targeted Wi-Fi network. The handshake is used to authorize a device, through a credentialing process, when connecting to an access point. At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all traffic from the newly connected device.

Vanhoef explains the attack method at a high level on his site krackattacks.com. He states that “In a key reinstallation attack, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying cryptographic handshake messages. When the victim reinstalls the key, associated parameters such as the incremental transmit packet number (i.e. nonce) and receive packet number (i.e. replay counter) are reset to their initial value. Essentially, to guarantee security, a key should only be installed and used once. Unfortunately, we found this is not guaranteed by the WPA2 protocol. By manipulating cryptographic handshakes, we can abuse this weakness in practice”.

Is this the end of secure Wi-Fi?

For the sake of brevity, I will keep my answer short. Individuals and enterprises should be concerned but no this is not the end of secure WiFi...Yet.

For starters, Although Vanhoef shows that these exploits are possible they are still primarily academic, as there has yet to be seen an attack exploiting the recently disclosed vulnerabilities in the wild. It was noted by security architect Kevin Beaumont, on his blog, that there is currently no publicly available code to carry out the attack and that it would require an “incredibly high skill set” to execute this type of attack (KRACK). Additionally, it has been identified by other researchers that KRACK may require a threat actor to be in close proximity to the victim they are attempting to compromise. This greatly limits the potential for a widespread attack but it does leave the door open for more targeted attacks.

So, what are we to do?
                                                                       

First and foremost, the obvious. The first thing anyone should be doing is looking out for vendor patches. The bright side to all of this, if there is one, is that KRACK was first disclosed to vendors back in July (2017) and revealed to the Community Emergency Response Team (CERT) Communication Center as well. CERT then distributed a comprehensive exposure of KRACK back in August thus providing more than adequate time to vendors to prepare patches before disclosure to the public. As I sit here and prepare this post Microsoft has indicated that it has already patched the KRACK vulnerability. In a statement to The Verge Microsoft said “We have released a security update to address this issue. Customers who apply the update, or have automatic updates enabled, will be protected. We continue to encourage customers to turn on automatic updates to help ensure they are protected.”

At the enterprise level mitigations for KRACK attacks (or any type of eavesdropping) should start at the foundation with a secure design of the wireless infrastructure. This should include the use of range-limiting antennas, limiting signal output strength on radio cards, and placing wireless access points away from the exterior walls of buildings thus reducing the amount of wireless traffic that is sent outside of a buildings physical boundary. Another strong mitigation is the use of a VPN when not on a trusted Wi-Fi network. A VPN will protect the data in transit encrypting the connection between the device and the remote server. This will shield the data from anyone on the untrusted public network. Including an attacker that may be attempting to exploit KRACK.