The anatomy of an Infrastructure Penetration Test

6 October 2023 Time to read: minutes

Author: Emad Mohamed – Trustmarque Penetration Tester

Dominating internal networks

In this article I will describe how during an infrastructure penetration test I was able to gain access to the first Windows host and work around basic AppLocker restrictions, finding and exploiting a vulnerability to dump the administrative credential, and then perform a pass-the-hash attack to gain administrative control.

I will provide a detailed account of the steps I took to identify and exploit these vulnerabilities. By sharing the methodology and techniques used, I hope to provide an insight into the value of infrastructure penetration testing and the importance of maintaining strong security measures to protect against potential attacks.

Methodology
Gaining credentials
Remote command execution
What is WSMAN and why it is important?
AppLocker restrictions workaround
System enumeration
Persistence
Conclusion
Mitigation steps

As the client’s network was internal and not reachable from the internet it was assumed that no attackers would have connectivity. Therefore security was not a consideration for the client. The whole attack chain, even though classic and basic in nature, demonstrates how internal networks can be insecure and vulnerable to various types of attacks targeting potentially sensitive data and resources.

For the purposes of this blog post, all attacks were replicated on a local test machine to ensure no customer data was revealed.

Methodology

To begin the engagement, I conducted a host discovery scan of the client’s network infrastructure using the provided network addresses to identify live hosts. I then scanned the default 1000 ports to gain a quick overview of the services listening on the hosts identified in the previous stage. This allowed me to investigate the service names and versions of the running services to identify potential vulnerabilities while the full Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports scan was in progress.

Gaining credentials

While conducting the initial scanning and reconnaissance activities, I set up the Responder spoofing tool to attempt to capture the credentials of vulnerable hosts that use insecure protocols such as Link-Local Multicast Name Resolution (LLMNR).

Before carrying on let me explain briefly what LLMNR is:

LLMNR is a Microsoft protocol used to resolve names of host computers on the network. It allows computers to resolve the hostnames of other computers without relying on a DNS server. When a computer needs to resolve a hostname using LLMNR, it sends out a broadcast query on the local network. If a computer with that hostname is available on the network and using LLMNR, it will respond with its own IP address.

So, why is LLMNR insecure? Since LLMNR is a broadcast-based protocol that relies on other hosts to provide the right answer, this arrangement makes the transaction vulnerable to a spoofing attack, where a host can respond with an incorrect answer. In Microsoft Windows, name resolution priority is achieved according to the following order:

Local hosts file is checked.
DNS query to the configured DNS server.
NetBIOS Name Service (NBT-NS) query is sent to the configured WINS server.
LLMNR query is sent to all hosts in the same network.

The responder tool can intercept LLMNR requests and respond from the attacker’s IP address with an authentication challenge. The affected Windows host responds to that authentication challenge with a NetNTLM or NetNTLMv2 hash that is captured and displayed to the attacker as can be seen below.

Figure 1 Responder Hash for infrastructure penetration test

Figure 1: Responder tool captured and displayed the user’s password hash.

The above hash was a NetNTLMv2 belonging to the “test” user. I saved it in a file and began trying to crack it using the “hashcat” tool with several leaked password lists available online and documented by several websites. The password was eventually found in “realhuman_phill.txt” password list provided by “hackstation”.

Remote command execution

Gaining user’s credentials in clear text opened the door to several attack opportunities against the Windows host. The first thing I wanted to try was to gain access to the affected machine. Looking at nmap scan I found the TCP port 5985 was open which is the default port for wsman service.

What is WSMAN and why it is important?

Windows Remote Management (WSMAN) is a protocol used in Windows operating systems for remote management and control of servers and workstations. It enables system administrators to remotely execute commands, run scripts, transfer files, and perform other management tasks on Windows systems from a central location. It is based on the simple object access protocol (SOAP) and uses HTTP and HTTPS for its transport.

PowerShell Remoting was potentially enabled on the host and by default only available for users with administrator-level privileges. However, it can be available too for users added to the Windows local group “Remote Management Users”. The first thing to try is to attempt establishing a PowerShell remoting session, and one of the tools that can be used to do that is “evil-winrm”.

The tool implements the PowerShell Remoting Protocol to establish a PowerShell session on the system using valid user credentials and it can be used as follows:

evil-winrm -i 192.168.120.133 -u test -p ‘<password>’

Figure 2 Login As Test for infrastructure penetration test

Figure 2: Remote PowerShell session established using the evil-winrm tool using the user’s credentials.

The successful infiltration of a system means that an attacker can use it to gain a foothold in the network and launch attacks against other systems in their quest to maximise their impact and potentially gain full control. Often, this involves trying to elevate their privileges on the initial compromised system, which is exactly what I attempted.

AppLocker restrictions workaround

I attempted to run some system enumeration tools designed to discover potential vulnerabilities and attack vectors for privilege escalation but found that was not possible due to and “AppLocker” policy restrictions on the host. The error can be seen in the screenshot below:

Figure 3 Applocker Denied Execute for infrastructure penetration test

Figure 3: An AppLocker policy blocked the execution of the winpease.exe binary.

As can be seen above there appeared to be a group policy restricting executables on the system. To enumerate that restriction policy and find a way of potentially circumventing it I looked at the registry using the command:

“Get-ChildItem -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Exe”.

The result can be seen in the screenshot below:

Figure 4 Applocker Default Rules for infrastructure penetration test

Figure 4: Displaying the configured AppLocker policy on the system.

As can be seen in the image above there are only three default rules configured on the system with the following descriptions:

(Default Rule) All files: This allows those in the administrator group to execute all executables and the path is set to (*) meaning from anywhere on the system.
(Default Rule) All files located in the Windows folder: This allows users in the “Everyone” group to run executables files from the Windows folder where the path would be “%windir%*”
(Default Rule) All files located in the Program Files folder: This allows users in the “Everyone” group to execute files from the “Program Files” folder where the path would be “%programfiles%*”.

The current privilege level for my user “test” as can be seen below shows the current user doesn’t have administrative access to the system and is a member of only the two local groups “Remote Management User” and “Users”.

Figure 5: Displaying the groups the user is a member of.

Taking all this into consideration I decided to look for a workaround that involves locating a directory within either the “Program Files” or the “Windows” directories that can be writable to store my files and start the enumeration. The following is a list of potential folders that are known to have a lax permission:

C:\Windows\Tasks
C:\Windows\Temp
C:\windows\tracing
C:\Windows\Registration\CRMLog
C:\Windows\System32\FxsTmp
C:\Windows\System32\com\dmp
C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\spool\drivers\color
C:\Windows\System32\Tasks\Microsoft\Windows\SyncCenter
C:\Windows\System32\Tasks_Migrated (after performing a version upgrade of Windows 10)
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\com\dmp
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\SyncCenter
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System

Investigating the permissions on these directories was achieved using the Windows utility tool “icacls”. It revealed that the “C:\Windows\Temp” was readable and writable by the “BUILTIN\Users”.

Figure 6: Showing the group “users” have read and write permissions on the directory.

System enumeration

I carried out system enumeration looking for privilege escalation vectors I could exploit and found a few misconfigurations. However, one vulnerability in particular was worth investigating further.

This vulnerability affected all Windows 10 and 11 from version 1809 up to version 20H1 and 20H2. The continuity of this vulnerability demonstrated poor code management that allowed it to affect several versions of the Windows operating system.

Poor file permissions allowed non-administrative users to read sensitive files such as those in the system directories. “%windir%\System32\config” contains a sensitive registry hive including the “SAM, SECURITY, SOFTWARE, and SYSTEM”.

The vulnerability was first disclosed on July 14, 2021, by the security researcher Jonas Lyk and it was documented under “CVE-2021-36934”. This was commonly known as Hive Nightmare, or “SeriousSAM”.

To exploit this vulnerability the following conditions must be satisfied:

Standard users are allowed read access to the file path.

System protection must be enabled.
Shadow copies must exist on the system as a result of creating at least one restore point.

Testing for the first condition is as easy as executing the tool “icacls” on the file path and investigating the output to make sure the “Users” group has necessary rights as can be seen in the following screenshot:

Figure 7: Showing the “Users” group has read and execute permissions on sensitive files.

The remaining two conditions can be tested using the “vssadmin” which requires administrative privileges; however, knowing the default path for the shadow copy on the system will make confirmation possible.

The default file path for the shadow copy is: (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy{NUM}), where the number value at the end corresponds to the subsequent restore point created by the user. A value of “1” corresponds to the first restore point and so on.

The following is a breakdown of the path and what each component means:

\? \: A prefix that is used to access hidden system objects.
GLOBALROOT: A special directory that is used by the Volume Shadow Copy Service.
Device: The name of the physical device that contains the volume that you want to create a snapshot of.
HarddiskVolumeShadowCopy: The name of the Volume Shadow Copy Service.
{NUM}: The is a placeholder for a numerical value denoting the shadow copy number.

Knowing this information makes it easy to loop over the path several times and look for sensitive files using a PowerShell script. However, as running PowerShell scripts is restricted by the system, I used the following one-liner on each for the SAM and SYSTEM hives:

for($i = 1; $i -le 10; $i++) {try{[System.IO.File]::Copy((“\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy” + $i + “\Windows\System32\config\sam”), (“C:\Users\test\Documents\hives\” + “SAM.hive” + $i));write-host “SAM.hive$i Copied”}catch{}}

I then repeated the same one-liner by swapping the SAM for the SYSTEM hive and got all the SAM and SYSTEM files on the system.

The PowerShell one-liner found five instances of files and copied them to the current working directory as can be seen below.

Figure 8: Showing the five instances of Shadow Copy that were successfully copied.

To gain access to the hashes on the system, the last copy of the files was passed to the tool “Impacket-secretsdump”. The following command was used: “Impacket-secretsdump -sam SAM.hive5 -system SYSTEM.hive5 LOCAL”. This resulted in dumping the hashes as can be seen below:

Figure 9: Showing the “Impacket-secretdump” successfully dumps the stored user’s hashes.

While cracking the hashes was in progress, I decided to establish an administrative session on the machine using “pass-the-hash” attack technique, which utilises the NTLM hashes to authenticate to the target machine. To understand “pass-the-hash” attack technique an explanation of the hashes dumped in the previous step is important. Let’s examine one line of the above hashes, for example, the “guest” account shown in the above image:

Guest: This is the username representing the user account owning the hash.
501: This is the user’s unique security identifier on the system
aad3b4<SNIP>1404ee: This is the “LM” hash which is an algorithm used in older Windows systems. In this case, the hash value is null as the system was configured to not use it.
31d6<SNIP>e0c089c0: This is the NTLM hash representation of the user’s password. This hashing algorithm supports longer and more complex passwords which offer more security against brute-force attacks. However, it is considered insecure by modern standards and is vulnerable to “pass-the-hash” attacks.

“NTLM” authentication on Windows is a challenge /response protocol that attempts to verify a user’s password when they request to access a service without having to send the password across the network. The following simple overview can be used to summarise the process:

The client sends the username to the server.
The server responds with a 16-bit random value (nonce).
The client then encrypts this “nonce” with the user’s password hash and sends it to the server.
The server then inspects the value and decides whether to allow or deny the request.

Several attack tools such as “evil-winrm, crackmapexec, Metasploit framework and Impacket” among others are equipped to handle hashes instead of passwords to authenticate and create a login session with the target computer system. For the purpose of this demonstration, I used the same tool “evil-winrm” to establish a login session with the target system.

Figure 10: Showing the “evil-winrm” tool was used to establish a login session using the administrator password hash.

Persistence

Persistence on a Windows host can be achieved using several techniques, including modification of registry “Run” keys and the “start-up” folder, configuring and setting up a “scheduled task”, and creating a local account among others. I created a backup local account named “admin1” on the host which had local administrator rights, which I could document and later request for it to be deleted at the end of engagement.

Conclusion

This article detailed the journey I took, in my role as a Penetration Tester at Trustmarque, during an infrastructure penetration test from an insider perspective with no privileges in the internal network to achieve remote access. Once I had access to the first target, I then escalated my privileges on that system and gained access to more sensitive information that could be used in further attacks within the network.

I began the infrastructure penetration test with network scanning to gain visibility into what was exposed and the services names and versions running on the live host. I then set up an “LLMNR” spoofing attack using the tool “responder” and gained a set of credentials in the form of a username and a cryptographic hash which was later cracked to reveal the plain text password of the user.

I then used these newly found credentials to gain a foothold on the target, enabling me to enumerate the system further to locate a privilege escalation vector which was later used to obtain administrative-level access to the system.

Mitigation steps

All successful attacks conducted against the system was the result of misconfiguration, and lax permission on sensitive file system path, which would have been avoided if proper patch management had been in place and a defence-in-depth strategy had been followed.

This is a list of mitigation steps required to avoid such an attack:

Network spoofing attack:

Disable LLMNR: Disabling LLMNR is the most effective way to prevent LLMNR spoofing attacks. This can be done via Group Policy or by modifying registry settings on Windows systems.
Use DNS instead of LLMNR: DNS (Domain Name System) is a more secure name resolution protocol than LLMNR and should be used whenever possible. Configure clients to use DNS instead of LLMNR by specifying the DNS server IP address in the network settings.
Disable WPAD: WPAD (Web Proxy Autodiscover) is another protocol that can be exploited by attackers to conduct spoofing attacks. Disabling WPAD via Group Policy or registry settings can mitigate this risk.
Implement network monitoring: Use network monitoring tools to detect and alert on anomalous LLMNR traffic patterns. This can help to identify potential insider threats and take appropriate action to prevent further damage.

Password cracking:

Use strong passwords: Strong passwords should be long, complex, and unique. Avoid using dictionary words or easily guessable personal information. Consider using a password manager to generate and store strong passwords.
Monitor leaked passwords and ban users from using them anywhere in the network.

Gaining unauthorised access:

Disable remote login protocols such as “WinRM” if not needed or restrict access to it to only members of the administrative group.
Monitor user’s logins to computers and aggregate this to a central system to gain further insights into potential nefarious activities in the network. An event log with the log ID 91 is created when a “WinRM” connection is received on the target host. Other notable operational log events to consider are the “Microsoft-Windows-PowerShell” module logging with the event ID 4103, and script block logging with the event IDs 4104, 4105, and 4106. When these are used together, they can help identify potential lateral movement within the network.

System enumeration:

Implement an efficient “AppLocker” strategy on systems with the following considerations:
- Implement whitelisting: Whitelisting is a technique that allows only authorised applications to run and blocks all other applications. Implementing a comprehensive whitelist can prevent unauthorised binaries from being executed on the system.
- Use digital signatures: Use digital signatures to verify the authenticity and integrity of applications and binaries. Digital signatures can provide assurance that the binary has not been tampered with and is from a trusted source.

Limit user privileges: Limit user privileges to prevent unauthorised users from installing or executing binaries. This can help to reduce the risk of unauthorised binaries being used on the system.
Regularly update and patch software: Regularly updating and patching software can help to mitigate vulnerabilities that could be exploited to install or execute unauthorized binaries.
Monitor for suspicious activity: Use security monitoring tools to detect and alert on suspicious activity related to the execution of binaries. This can help to identify potential attacks and take appropriate action to prevent further damage.

Vulnerability mitigation

To mitigate against the (CVE-2021-36934) install the official fix described by Microsoft here (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934).

List all the shadow copies created on the system using the command:
- vssadmin list shadows /for=%systemdrive%
Delete all shadow copies on the system:
- vssadmin delete shadows /for=%systemdrive% /Quiet.
Restrict access to contents of the %windir%:
- icacls %windir%\system32\config\*. * /inheritance:e.
Then create new restore points if desired.

Pass the hash attack:

The following mitigation steps can be considered:

Enable Windows Defender Credential Guard.
Use Microsoft Local Administrator Password Solution (LAPS).
Disable NTLM if possible and use a secure protocol such as Kerberos.

See our penetration testing solutions

About the author: Emad Mohamed is a penetration tester at Trustmarque who holds a BSc in Computing and IT, Offensive Security Certified Professional (OSCP), CREST Practitioner Security Analyst (CPSA), CREST Registered Tester (CRT), and Cyber Scheme Team Member (CSTM) qualifications.

References

Cyber security