PARAnoia

Written By James Thew

Imagine stealing a laptop, and just getting.. everything…

This scenario was proposed after reading an interesting message from another red-teamer. To summarize it: "Could a stolen domain-joined laptop be used against itself to authenticate to a rogue domain controller, and get full access to it?"

Answer: Yes, and we will demonstrate how.

This mini-project is both an adventure of discovering this weakness, and instruction for how to do so, explicitly for ethical security purposes.

Setup

Requirements for test:

  • 2x Windows Servers (2022 Standard used in this example)
  • 1x Windows Workstation OS (Windows 11 Enterprise used in this example) All operating systems were up-to-date before testing.

A Windows 2022 Standard domain controller is configured (testing.local) on address 192.168.57.3, with a DHCP server scoped to 192.168.57.0/24. The domain controller has two user accounts, Administrator (DA), and testuser (standard user). No additional configurations were made to the AD domain.

A computer was added to the domain (Windows 11 Enterprise), with the domain logon user testing/testuser. It was given an IP by DHCP of 192.168.57.5. All communications to the DC were set up to provide DHCP (setting DC to DNS provider, etc etc)

A rogue Kali server was added to the LAN, and obtained a DHCP address of 192.168.57.6. It is successfully able to reach the client computer, which is a necessary requirement for this test.

Testing without DC

In the case of a stolen computer, it's likely that bitlocker does not require a pin on each OS boot. In this case, there is a machine that is domain joined, but has an unknown password, so the OS is functionally inaccessible. The theory behind this test is that using a rogue DC, a rogue Domain Admin (from rogue DC), and the laptop, the Kali machine could create a NetLogon pass-though authentication via NTLM to the rogue DC, get Domain Administrator permissions, and log into the machine remotely. This was my original assumption behind this test.

To test this, the domain joined Windows 11 test machine will be locked, and the necessary information to build a DC will be gained, just over a LAN connection (that is sandboxed from internet).

The legitimate DC was shut down, to be inaccessible for the rest of the tests.

Extracting Domain Details

The following details will be needed to create a rogue DC that is "identical" to the legitimate DC. The following Powershell script was generated after the initial DC was created:

Import-Module ADDSDeployment
Install-ADDSForest
    -CreateDnsDelegation:$false
    -DatabasePath "C:\Windows\NTDS"
    -DomainMode "WinThreshold"
    -DomainName "testing.local"
    -DomainNetbiosName "TESTING"
    -ForestMode "WinThreshold"
    -InstallDns:$true
    -LogPath "C:\Windows\NTDS"
    -NoRebootOnCompletion:$false
    -SysvolPath "C:\Windows\SYSVOL"
    -Force:$true

The majority of this information is standard (e.g., NTDS location, forestmode), so the primary information that is needed is the Domain name and Netbios name. Luckily, this should be easy to extract, as the DNS name is usually the same as the Netbios name.

The entire infrastructure (excluding the DC) was moved to a different subnet to replicate "stealing" a machine. It was then rebooted, to take the new network DHCP configuration. In doing this, we discovered that the Windows "Public" firewall was taking precedence over the "Domain" firewall. This closes off normally open ports, utilized in the next steps (namely 445). Other tests can be performed to try to bypass this, but the private firewall will be disabled for the purpose of this testing. This is a major issue if you want to use this guide as a full walk-through. The following steps could be fulfilled via other means through network access to a corporate entity, but that is not this specific use case.

I created a fake session on the windows 11 machine with impacket-smbclient, using a bogus domain/user combination with a password that we will use to decrypt the captured traffic. First, go to Wireshark, then type Ctrl+Shift+P to get to Preferences. Then drill into Protocols > NTLMSSP, and enter the NT password given by the impacket-smbclient. This will decrypt all packets, allowing inspection.

NOTE: This was on a seperate LAN range than the DC (which was also shutdown to ensure no communications), but still maintains the DNS name of the DC in it's SMB data. After extracting the NETBIOS name of the DC, this can be used to create a new rogue DC with these attributes.

The rogue DC was created using a duplicate of the Powershell script mentioned earlier, now that all references required were retrieved. After that, the rogue DC deployed a DHCP server for the LAN.

UPDATE: Impacket tooling

After going through the manual process of doing this, I discovered the impacket-DumpNTLMInfo module, which easily interrogates this information. It is not as opsec friendly as the previous, but still a good option, depending on the EDR provider:

Exploiting the Workstation with a Rogue DC

After configuring a Domain Admin, realadmin, on the rogue DC, it was attempted to login via impacket. However, it returned an error of STATUS_NO_LOGON_SERVERS:

Attempting to use a hash resulted in the same error:

This is the result of attempting an interactive logon:

It appears that the workstation can "see" the DC that it is attempting authentication against, but there is not an implicit trust between the two. A new computer is added to the rogue DC, DESKTOP-NND8N77:

This machine account may be able to be synced via a manual hash synchronization in the msDS-ManagedPassword attribute of the machine account of the target computer. If this hash is gained, then it may be possible to restore trust to the DC and get access to the computer via rogue Domain trust. For the purpose of this test, the hash was manually extracted under the assumption that this hash could be gained through coercion/listening on responder, but this not testing that, but the results of machine synchronization with rogue domain.

When the machine account NT hash is captured, it can be inserted into the DC with mimikats lsadump::setntlm

The machine account NT hash injection is confirmed with an impacket-secretsdump from the kali machine to the rogue DC:

Still, no love:

So, what is needed to get the computer to "trust" the domain controller?? Turns out, everything worked. Just had to reboot the DC and the workstation, in that order. Interactive login worked with the testing\realadmin account:

To further validate, a second account, da, was created as a Domain Administrator:

Let's attempt to login remotely with password, PTH, and combination:

No luck. However, interactive logon on-machine worked:

Running a net user da /domain:

So we have Domain Admin permissions...

But when we launch anything with Administrative permissions, it "works", but does not establish an actual "Administrative" context. ... so we do not have actual administrative ability on this machine? What's that about?

The DA is trusted:

Domain Admins not being able to do Domain Admin things appear to be a fallout of this kind of hijack. Seems that something breaks in Windows' ACL management when hijacking a domain. We have user access to the machine, so what now? Well, we proved that the computer "Trusts" the DC with the above command. We could use an LPE to escalate to SYSTEM, but that doesn't feel right in this context. I want to be able to properly access the computer as an Admin.

I created an OU for my target computer called "targets" on the rogue DC:

Then I created a GPO called localadmin that was linked to the targets OU, and added from the Domain Admins group user testman\da to the restricted group, BUILTIN\Administrators.

After enforcing a gpupdate /force, and rebooting the machine a few times (because AD loves taking time), we get the following (SUCCESS):

Now, from the kali machine, we can dump the loot with impacket-secretsdump!

In combination with administrative permissions locally, which can be elevated to SYSTEM with a tool like psexec, among other methods:

With these permissions, all sensitive internal data can be exfiltrated from the computer. This computer could additionally be backdoored with a SYSTEM level beacon, and returned to normal operations, as the domain information was not altered on the workstation itself. This would provide a deep implant into a corporate network, assuming that the laptop is not wiped: e.g., laptop broken into after-hours and compromised before anyone noticed it missing

Additional attacks can be performed by using the gathered hashes to attack the enterprise (real) domain:

  • Using machine hash depending on configuration from kerberos (delegation types)
  • Cracking the domain cached credentials (hashcat -m2100), and using those for network based attacks on enterprise
  • Dumping and stealing browser data

Conclusion

This kind of attack is deeply disturbing. It proves that a computer, either stolen, or physically accessible, can be fully compromised and backdoor-ed in a short period of time. We are actively working on an automated tool to perform this attack. Assuming that an NT hash can be gained, downgraded, or coerced, this attack can be performed quickly compared to the manual testing performed in this POC.

All testing was performed with Microsoft defender enabled, on up-to-date Windows Server 2022 Standard and Windows 11 enterprise. These are not end-of-life/end-of-support operating systems. This is a proper issue that affects ALL Active Directory/Windows based enterprises.

The only mitigation is to completely remove the capability to capture NTLM hashes, by supporting only NTLMv2 or Kerberos. Due to the fact that there are function mitigations, it is not considered a "zero day", as it is utilizing Microsoft's very loved and exploited authentication protocol.

In the end, it always comes back to the saying: "Physical Access is Root Access". This is why we named this attack vector PARAnoia.

James Thew