Zero to Domain Admin: Bypassing NAC and getting the goods

Over last three years I have performed a number of penetration testing assessments. These include wireless, web application, mobile application etc.

None of them however give the adrenaline rush of an internal penetration testing. You get the keys to the kingdom!

The objective is straight forward: get access to the client’s corporate network and get the Crown Jewels ( the most critical systems ) as quickly as possible.

This post describes the most recent internal pentest we did for a consumer goods company.

1. Getting access

We reached the premise and given it was not a typical IT company, we were hoping to get an IP address by simply plugging the LAN cable.

If only.

The target network had Network Control Access (NAC) mechanism implemented for wired and wireless network. One of the quick wins is to bypass it using MAC spoofing. You take a VoIP phone or a printer, use their MAC address on your attacking machine and you should be provided with an IP address from the DHCP server.

Why? Because these devices are whitelisted as they do not support 802.1x authentication. In this particular instance though, it wasn’t that straightforward.

Next, we proceeded to try VLAN hopping, jumping from the voice VLAN to data VLAN. This can be achieved by plugging the laptop into the network port of VoIP phone and using a utility such as voiphopper (pre installed in Kali Linux). However, no luck!

Little disappointed, we took a walk around the campus to get a lay of the land. While most of the employees were using laptops, there were a few in the organisation’s design department who had some fancy workstations. Time for some social engineering.

We pretended to be from the vendor who was providing the network support and patiently waited for lunch time. When it was 10 minutes to lunch time, we approached the user and politely asked if they would mind us using the system to run some network diagnostics. The user looked at her watch and realized it was going to be lunch time soon anyway. She happily cooperated. Hacking the humans.

We immediately plugged in the a USB and live booted into Kali. The workstation had unencrypted hard disk which allowed us to dump the SAM and SYSTEM files. We capitalized upon this access into the network and started Responder to get hashes. 2 domain user hashes were obtained in 20 odd minutes. These were NetNTLMv2 hashes which essentially meant, unless they cracked, won’t do us any good.

Note: You can only perform a pass the hash with NTLM hashes. Refer this excellent guide by to know more about different types of hashes https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html

Both the hashes were At this point we unplugged our USB and went back to the room we were working out of. Using JTR and rockyou.txt, the local admin hash cracked. This was good as long as we had access to the workstation. We still needed connectivity into the corporate network to use it. The domain user hashes could not be cracked via rockyou. So we created a custom, target specific dictionary. This is a common theme across organisations. People use passwords which are easy to remember and a lot of times these passwords are some alphanumeric combinations involving brands related to the target. For example, someone working in General Motors will definitely have a password with “chevy” or “camaro” in it.

To create our custom dictionary we leveraged an excellent GUI based utility, Mentalist. The dictionary size in this particular case turned out to be a whopping 22 GB. Couple of minutes into cracking via JTR and et voila, one of the two hashes cracked. One is good enough.

So now we had a local admin hash and a domain user hash. The domain user creds were tried in our Windows and Linux systems to get into the wireless network but failed. The same credentials however, worked for our mobile device. Awesome! Immediately we performed USB tethering to share mobile’s network on our attacker machine.

Corporate wireless network access obtained. Adios NAC!

2. Recon

Now that we had access, next step was enumeration:
— IP for workstations, server ranges
— DNS and DHCP servers
— Critical servers

This can be done with built in kali tools such as, nslookup, dig, dnsrecon, nbtscan, adldapenum etc.
Running a dnsrecon -r x.x.x.x/y will give you the name of systems in that network. This can easily help you prioritize the sensitive systems. Also, running enum4linux showed that null sessions were allowed on the Domain Controller and allowed enumeration of users in the domain and the groups they belonged to.

Status check: Access to corporate network, network enumeration to find critical servers and IP ranges, list of all domain users and groups..

3. Lateral movement

Now that we knew the workstation and server ranges, we needed to know what all can be accessed using the local admin creds we had from the workstation had live booted into. So we ran crackmapexec and sprayed the local admin creds across the workstation range. This gave us 75 successful administrative logins. Similar results can be obtained via metasploit’s smb_login module as well.

Note: be careful to specify the domain when using crackmapexec or smblogin. A spray with domain creds generating multiple failed attempts might cause account lockout and alert the SOC. Also, in sophisticated environments, keep the number of threads low. The stealthier the better.

Admin access on workstations is fine but what about the server ranges, can we get into any of the servers?
Out of 4 network ranges for servers that we had discovered, 3 gave nothing. In the last one, out of 130 servers in range, crackmapexec identified one server which allowed administrative access using local admin creds.

One is all that matters.

We did a RDP into the server and looked around for sensitive documents. It is not uncommon to find business sensitive documents with encryption and passwords stored in plain text files. There was a SQL management studio running and had customer PII. Seemed like someone had disconnected recently. We also identified Trend Micro and McAffee security solutions running on the server. Once the ‘look around’ was complete, next step was to dump the LSASS process to get creds from memory. Given that we had administrative access on the server, we could have dumped the LSASS process remotely via command line as well but the chances of getting detected through RDP based LSASS dumps are comparatively low.

LSASS dump gave us creds for a few more domain users which we mapped against the user list we had obtained by exploiting null sessions. Not a single privileged user. Disappointment.

We went back to the server to look around for sensitive information that we can use later in the report. Doing a win+R showed that mstsc was the last command that was run. The RDP window indicated 6 IP addresses which the users would have connected to from that system.

Out of 6, for 2 server we got the “saved credentials will be used for this connection” message. We immediately took RDP session and repeated the process. Look around for information and dump the LSASS process. Few more credentials were obtained but one stood out. We had seen this one before. Where? Went back to the user listing and……..a Domain Administrator.

One hop and Domain Administrator access.

4. Getting the goods

Now that we had the DA, it was time to get the crown jewels to create the business impact. We proceeded to gain access to the critical servers, databases and a lot of Personally Identifiable Information (PII).

Finally to test the incidence response capabilities, we dumped the NTDS using Volume Shadow Copy (VSS). Once the NTDS was on attacker machine, secretsdump.py was used to extract all password hashes. Using Mimikatz and the krbtgt hash we created a golden ticket. This ticket was then used to create a rogue user in AD for backdoor access.

Now, going back to the part where we obtained initial access into the network, one can argue (and the client did!) if live booting was not involved, we might not have proceeded to become DA. Well, that would be incorrect because without social engineering, it would simply increase the time to get DA.

So, as a POC we ran evil twin attack on the corporate wireless network across the client’s regional offices to obtain domain user credentials and get access to the network. There was no network segmentation which meant an attacker sitting in a regional office by compromising the wireless network is as good as one inside the HQ.

The key takeaway here is that internal penetration testing is a point in time assessment. You try multiple ways to get in and take the first feasible attack vector.