Tag: Virtualized Network

AD Series: How to Perform Broadcast Attacks Using NTLMRelayx, MiTM6 and Responder
Now that we setup an AD test environment in my last post, we’re ready to try out broadcast attacks on our vulnerable test network.

In this post we will learn how to use tools freely available for use on Kali Linux to:
- Discover password hashes on the network
- Pivot to other machines on the network using discovered credentials and hashes
- Relay connections to other machines to gain access
- View internal file shares
For the attacker machine in my lab, I am using Kali Linux. This can be deployed as a virtual machine on the Proxmox server that we setup in my previous post or can be a separate machine as long as the Active Directory network is reachable.

Most tools we will use are preinstalled on Kali:
- MiTM6: Download from GitHub
- Responder: Installed on Kali
- CrackMapExec: Installed on Kali
- Ntmlrelayx: Installed on Kali (run using impacket-ntlmrelayx)
- Proxychains: Installed on Kali
Setting up the Attack

Within Kali, first we’ll start MiTM6:
```
sudo mitm6 -i {Network Interface}
sudo mitm6 -i eth1
```
MiTM6 will pretend to be a DNS server for a IPv6 network. By default Windows prefers IPv6 over IPv4 networks. Most places don’t utilize the IPv6 network space but don’t have it disabled in their Windows domains. Therefore, by advertising as a IPv6 router and setting the default DNS server to be the attacker, MiTM6 can spoof DNS entries allowing for man in the middle attacks. A note from their GitHub even mentions that it is designed to run with tools like ntlmrelayx and responder.

Next we start Responder:
```
sudo responder -I {Network Interface}
sudo responder -I eth1
```
Responder will listen for broadcast name resolution requests and will respond to them on its own. It also has multiple servers that will listen for network connections and attempt to get user computers to authenticate with them, providing the attacker with their password hash. There is more to the tool than what is covered in this tutorial, so check it out!

With MiTM6 and Responder running, next we start CrackMapExec (CME):
```
crackmapexec smb {Network} –gen-relay-list {OutFile}
```
CME is a useful tool for testing windows computers on the domain. There are many functions within CME that we won’t be discussing in this post, so I definitely recommend taking a deeper look! In this post we are using CME to enumerate SMB servers and whether SMB message signing is required and also to connect to and perform post exploitation activities.

First we will use CME to find all of the SMB servers on the AD network (10.80.0.0/24) and additionally to find those servers which do not require message signing. It saves those which don’t to the file name relay.lst.

Now we’re ready to start ntlmrelayx to relay credentials:
```
impacket-ntlmrelayx -tf {File Containing Target SMB servers} -smb2support
impacket-ntlmrelayx -tf relay.lst -smb2support
```
Ntlmrelayx is a tool that listens for incoming connections (mostly SMB and HTTP) and will, when one is received, relay (think forwarding) the connection/authentication to another SMB server. These other SMB servers are those that were found earlier by CME with the –gen-relay-list flag, so we know they don’t require message signing. Note that the smb2support flag just tells ntlmrelayx to setup a SMBv2 server.

Almost immediately we start getting traffic over HTTP:

Running the Attack

So far the responder, mitm6 and ntlmrelayx screens just show the initial starting of the program. Not much is actually happening in any of them. The CME screen is just showing the usage to gather SMB servers that don’t require message signing.

To help things along with our demo, we can force one of the computers on the network to attempt to access a share that doesn’t exist.

While a user looking for a share that doesn’t exist is not needed for this attack, it’s a quick way to skip waiting for an action to occur automatically. Many times on corporate networks, machines will mount shares automatically or users will need a share at some point allowing an attacker to poison the request them. If responder is the first to answer, our attack works, but, if not, the attack doesn’t work in that instance.

Responder captures and poisons the response so that the computer connects to ntlmrelayx, which is still running in the background.

Below we see where responder hears the search for “newshare” and responds with a fake/poisoned response saying that the attacker’s machine is in fact the host for “newshare.” This causes the victim machine to connect to ntlmrelayx which then relays the connection to another computer that doesn’t require message signing. We don’t need to see or crack a user password hash since we are just acting as a man in the middle (hence MiTM) and relaying the authentication from an actual user to another machine.

In this case the user on the Windows machine who searched for “newshare” turns out to be an administrator over some other machines, particularly the machine that ntlmrelayx relayed their credentials to. This means that ntlmrelayx now has administrator access to that machine.

The default action when ntlmrelayx has admin rights is to dump the SAM database. The SAM database holds the username and password hashes (NTLM) for local accounts to that computer. Due to how Windows authentication works, having the NTLM hash grants access as if we had the password. This means we can login to this computer at any time as the local administrator WITHOUT cracking the hash. While NTLM hashes are easy to crack, this speeds up our attack.

If other computers on the network share the same local accounts, we can then login to those computers as the admin as well. We could also use CME to spray the local admin password hash to check for credential reuse. Keep in mind that the rights and access we get to a server all depends on the rights of the user we are pretending to be. In pentests, we often do not start with an admin user and need to find ways to pivot from our initial user to other users with more access until we gain admin access.

The following screenshot shows ntlmrelayx dumping all of the local SAM password hashes on one device on our test network:

While getting the local account password hashes and and gaining access to new machines is a great attack, ntlmrelayx has more flags and modes that allow for other attacks and access. Let’s continue to explore these.

Playing around with –interactive

Ntlmrelayx has a mode that will create new TCP sockets that will allow for an attacker to interact with the created SMB connections after a successful relay. The flag is –interactive.

When the relay is successful a new TCP port is opened. We can connect to it with Netcat:

We can now interact with the host and the shares that are accessible to the user who is relayed.
```
nc 127.0.0.1 11000
nc 127.0.0.1 11001
```
Playing around with -SOCKS

With a successful relay ntlmrelayx can create a proxy that we can use with other tools to authenticate to other servers on the network. To use this proxy option ntlmrelayx has the -socks flag.

Here we use ntlmrelayx with the -socks flag to use the proxy option:

Below we see another user has an SMB connection relayed to an SMB server. With the proxy option ntlmrelayx sets up a proxy listener locally. When a new session is created (i.e. a user’s request is relayed successfully) it is added to the running sessions. Then, by directing other tools to the proxy server from ntlmrelayx, we can use these tools interact with these sessions.

In order to use this feature we need to set up our proxychains instance to use the proxy server setup by ntlmrelayx.

The following screen shows the proxychains configuration file at /etc/proxychains4.conf. Here we can see that, when we use the proxychains program, it is going to look for a socks4 proxy at localhost on port 1080. Proxychains is another powerful tool that can do much more than this. I recommend taking a deeper look.

Once we have proxychains set up, we can use any program that logs in over SMB. All we need is a user that has an active session. We can view active sessions that we can use to relay by issuing the socks command on ntlmrelayx:

In this example I have backup.admin session for each of the other 2 computers. Let’s use secretsdump from impacket’s library to gather hashes from the computer.

When the program asks for a password we can supply any text at all, as ntlmrelayx will handle the authentication for us and dump the hashes.

Since I am using a private test lab, the password for backup.admin is “Password2.” Here is an example of logging in with smbclient using the correct password:

Using proxychains to proxy the request through ntlmrelayx, we can submit the wrong password and still login successfully to see the same information:

Next Steps

All of the tools we discussed are very powerful, and this is just a sampling of what they can be used for. At Raxis we use these tools on most internal network tests. If you’re interested in a pentesting career, I highly recommend that you take a deeper look at them after performing the examples in this tutorial.

I hope you’ll join me next time when I discuss Active Directory Certificate Services and how to exploit them in our test AD environment.

Want to learn more? Take a look at the next part in our Active Directory Series.
June 19, 2023
How to Create an AD Test Environment

Lead Pentester Andrew Trexler walks us through creating a simple AD environment.

Whether you use the environment to test new hacks before trying them on a pentest, or you use it while learning to pentest and study for the OSCP exam, it is a useful tool to have in your arsenal.

The Basics

Today we’ll go through the steps to set up a Windows Active Directory test environment using Proxmox to virtualize the computers. In the end, we’ll have a total of three connected systems, one Domain Controller and two other computers joined to the domain.

Setting up the Domain Controller (DC)

The first step is to setup a new virtualized network that will contain the Windows Active Directory environment. Select your virtualization server on the left:

This is a Windows based environment, but we’re using a Linux hypervisor to handle the underlying network architecture, so under System, select Network, and then create a Linux Bridge, as shown in Figures 2 and 3:

After setting up the network, we provision a new virtual machine where we will install Windows 2019 Server. Figure 4 shows the final configuration of the provisioned machine:

The next step is to install Windows 2019 Server. While installing the operating system make sure to install the Desktop Experience version of the operating system. This will make sure a GUI is installed, making it easier to configure the system.

Now that we have a fresh install, the next step is to configure the domain controller with a static IP address. This will allow the server to function as the DHCP server. Also make sure to set the same IP as the DNS server since the system will be configured later as the domain’s DNS server.

In order to make things easier to follow and understand later, let’s rename the computer to DC1 since it will be acting as our domain controller on the Active Directory domain.

Next, configure the system as a domain controller by using the Add Roles and Features Wizard to add the Active Directory Domain Services and DNS Server roles. This configuration will allow the server to fulfill the roles of a domain controller and DNS server.

After the roles are installed, we can configure the server and provision the new Active Directory environment. In this lab we will use the domain ad.lab. Other than creating a new forest and setting the name, the default options will be fine.

Setting Up the DHCP Service

The next step is to configure the DHCP service. Here we are using a portion of the 10.80.0.0/24 network space, leaving enough addresses available to accommodate static IP addressing where necessary.

There is no need for any exclusions on the network, and we will set the lease to be valid for an entire year.

Adding a Domain Administrator and Users

Additional configuration is now required within the domain. Let’s add a new domain administrator and some new domain users. Their names and passwords can be anything you want, just make sure to remember them.

First we create the Domain Administrator (DA):

Here we also make this user an Enterprise Admin (EA) by adding them to the Enterprise Admins group:

Next we will add a normal user to the domain:

Creating Windows PC

At this point we should have a functional Active Directory domain with active DHCP and DNS services. Next, we will setup and configure two other Windows 10 machines and join them to the domain.

The first step is to provision the resources on the Proxmox server. Since our test environment requires only moderate resources, we will only provision the machines with two processor cores and two gigabytes of RAM.

Then we install Windows 10 using the default settings. Once Windows is installed, we can open the Settings page and join the system to the ad.lab domain, changing the computer name to something easy to remember if called for.

Adding the system to the domain will require us to enter a domain admin’s password. After a reboot we should be able to login with a domain user’s account.

SMB Share

At this point, there should be three computers joined to the Active Directory domain. Using CrackMapExec, we can see the SMB server running on the domain controller but no other systems are visible via SMB. So let’s add a new network share. Open Explorer.exe, select Advance Sharing, and share the C drive.

I don’t recommend sharing the entire drive in an environment not used for testing, as it’s not secure: the entire contents of the machine would be visible. Since this is a pentest lab environment, though, this is exactly what we are looking for.

Creating the share resulted in the system exposing the SMB service to the network. In Figure 20 we verified this by using CrackMapExec to enumerate the two SMB servers:

Conclusion

At this point, our environment should be provisioned, and we are ready to test out different AD test cases, attacks, and other shenanigans. This environment is a great tool for ethically learning different exploits and refining pentesting techniques. Using a virtual infrastructure such as this also provides rollback capability for running multiple test cases with minimal downtime.

I hope you’ll come back to see my next posts in this series, which will show how to use this environment to test common exploits that we find during penetration testing.

Want to learn more? Take a look at the next part in our Active Directory Series.

April 27, 2023