Completed Project Part II

Part II: Penetration Testing
Something I learned from the book Metasploit: The Penetration Tester's Guide was that penetration testers work through certain phases while they are looking at their targets. They consist of:

1. Pre-engagement Interactions: discussing the scope of the penetration test with the client
2. Intelligence Gathering: learning how an organization operates. This can include Google searches, exploring their social media pages, LinkedIn connections, and beginning to probe systems to see protections in place
3. Threat Modeling: using the information from intelligence-gathering to identify vulnerabilities on a target system. In this stage, the tester begins to decide what information they are after. 
4. Exploitation: using previous information to fire off an exploit to a vulnerable target machine. Exploits need to be researched and should only be tried once the tester is certain that they are going to work. 
5. Post Exploitation: begins after compromising one machine. At this point, the penetration tester moves to multiple machines and tries to capture as much as they can. 
6. Reporting: the most important part. This shows the client where their weaknesses are and what they need to change to prevent future attacks. 

NMAP Scanning
The first thing I did on my network was scan all the different hosts to see what services were running. NMAP is built into Kali and it is a port scanner and it returns open ports, running services, and operating system information. More information about NMAP can be found here: http://tools.kali.org/information-gathering/nmap

Below is a network diagram again:

Here are the results of the NMAP scan of the server:

And below is the scan result of the client machine

Not pictured but NMAP also returned the operating system information along with the computer name and domain name. I also scanned with Zenmap and the results were very similar to above. I also tried opening ports and turning on different services to see how that changed the results.

Nessus Scanning: 
Moving on from NMAP, I started to vulnerability scan the machines on my network. For this I used Tenable Security's Nessus Vulnerability Scanner. This scanner is a lot more powerful than NMAP because it can return very detailed information about target machines. It also shows vulnerabilities and explains what exploits could be run against the system. I was able to download a free trial of this software and use it for my project but otherwise you have to pay for it.


Below is a screenshot of the scan results. Overall, everything looked pretty good. Even without updating or patching my test machines the scanner didn't return much.

Below is a detailed view of the scan results from the Windows Server 2012.

If the first two "critical" listing were exploited they could crash the server and force a reboot. More information about those can be found here https://technet.microsoft.com/en-us/library/security/ms14-066.aspx and here https://technet.microsoft.com/en-us/library/security/ms15-034.aspx. I decided to go a different route and the two that items that caught my eye were Telnet and SMB (Server Message Block) Remote Host. I knew that Metasploit had a scanner for SMB and decided to go that route.

Server Message Block is a network protocol used for sharing files, folders, and printers in a network setting. The connections are based on authentication between clients but using Metasploit the logins can be brute forced or dictionary attacked.

SMB Logins
Using a custom word list I was able to successfully login to the server's administrator account using the password: test.

Here's the successful login results. 

This test test just shows the importance of strong passwords and why defaults should always be changed. This test also shows why it is important to monitor logs on the server side and watch for numerous failed login attempts. In a real world setting, brute forcing most likely would not be used because it is noisy and hopefully would alarm administrators.

On the server side, it is also important to set Password Policies for complexity and length. Depending on the environment account lockout policies are also important. If I had these in place my attack would have been a lot harder.

And every failed attempt showed up in the server logs.

SSH Logins
Moving on from SMB logins, I was able to attack SSH. On my pfSense router, I had SSH enabled and using a tool called Hydra I was able to login to the router. More information about Hydra can be found here: http://tools.kali.org/password-attacks/hydra. Since the pfSense box was configured using the default credentials, attacking it was simple.

Previously, I only had to find a valid password; this time I had to get both the username and password.

Below is the username word list

Below is the password word list






And as expected the router accepted the credentials and I was able to use these to SSH to it later on.

Again this just shows how important it is to use something other than a default or common password. You'd be surprised too by how many devices on the Internet today still are using default credentials to login. This was even proven recently after examining the attack on the DNS provider Dyn. According to Brian Krebs, "The malware, used to perform a DDOS attack on the DNS provider Dyn relied on factory default or hard-coded usernames and passwords for IOT devices". This was taken from his October 1 blog post for Krebs on Security https://krebsonsecurity.com/2016/10/source-code-for-iot-botnet-mirai-released/. 

Meterpreter

After realizing that there probably wasn't going to be an exploit for my test network, I decided to again go a different route. Other ways that hackers target machines is by installing a backdoor on systems. This can be done through various methods but it is commonly done through emails, flash drives, or file downloads. For this test, I was able to use the Metasploit framework to create an executable to place on the target machine. 

To better understand how this works I referenced this guide https://www.exploit-db.com/docs/18532.pdf. In the end, I was able to use a payload containing a Meterpreter Reverse TCP session and then encode it using the Shikata ga nai encoder in MSVenom. 

Below shows the encoding of the file and then the payload to be delivered when the target opens the file. 

Here my Kali machine is listening for when the target opens the file and ready to begin a Meterpreter session. 

Here is how the setup looked. The target machine would connect back to the Kali box once the file was opened. At this point, the Windows machine was able to be controlled from Kali.

Here is a video showing what this actually looked like live. The window on the left is the Kali VirtualBox instance and the window on the right is the Windows 8.1 VirtualBox machine. The first time I tried to open the file it failed because Windows Defender caught it and flagged it as malware. after disabling Windows Defender it worked as expected. In the video, I start a keylogger on the target machine then I remotely open Chrome and send them to Facebook. The target enters their credentials and those are stored for later. This was just one example of what could be done. In a real world environment, hopefully there would be other monitoring devices in place before this could even be done.