Revisiting Accessing Protected Content using Windows Domain Controllers and Workstations

We love receiving feedback about how our customers have accessed protected (or otherwise difficult to access) content with Arsenal Image Mounter, by launching disk images from Windows servers and workstations which were on the same network into virtual machines:

“I had a disk image obtained from a Windows server’s 4TB RAID array that failed to launch into a virtual machine using my existing tools and methods. I needed the server running in a virtual machine because it hosted an important CRM application. I also had disk images from Windows workstations which ran the CRM client. While I had used Arsenal Image Mounter’s (AIMs) Free Mode functionality in the past, I was unaware of its Professional Mode capabilities until this case. AIM allowed me to mount the server’s disk image in write-temporary mode (so changes to the operating system and applications could be made without altering the original evidence) and launch the virtual machine – with just a few button presses!

I finally had the server running in a virtual machine… but I was at a login screen and did not have a password. Not a problem – AIM’s Windows authentication bypass allowed me to get right into the server. In order to get the CRM application working, I also launched the Windows workstations into virtual machines using AIM’s isolated networking (only between virtual machines) option. At this point, the CRM clients on the workstations connected to the CRM on the server and my team was able to access the data we needed for our case.

I have since recommended AIM to the other members of my team, and I foresee I’ll be using the virtual machine launching and Windows authentication bypassing functionality a lot more often.”

Allan McNamara

Digital Forensic Analyst, National Trading Standards eCrime Team (UK)

You may find (like Allan did) that immediately after launching disk images from Windows servers and workstations on the same network into virtual machines, they start talking to each other normally… or, much less often in our experience, you may find that they do not. The focus of this Insights article is on providing you with a method to force servers (particularly, domain controllers) and workstations to talk to each other within the virtual machines you have launched with AIM.

Let’s revisit accessing protected content by launching a Windows domain controller and workstations attached to it into virtual machines with isolated networking. Remember, while bypassing Windows authentication (particularly with AIM, which can bypass all types of Windows authentication) provides digital forensics practitioners with great opportunities, there are certain things in Windows such as EFS-encrypted files and cached login credentials that require authentication to be cracked and/or physically present rather than bypassed. Or is there another option? You can launch disk images obtained from a domain controller and workstations attached to it into virtual machines, use the domain controller to reset user passwords, and then logon to the user accounts with the new passwords on their workstations to access protected content. You can see this workflow in action by visiting our previous Insights article on this topic: Accessing Protected Content using Windows Domain Controllers and Workstations.

So – let’s say you have launched a domain controller and workstations that were attached to it into virtual machines with isolated networking, but they are not talking to each other. In our experience it’s rare that this happens, but when it does we can force the domain controller and workstations to talk to each other. We will now demonstrate this process for you. The disk images we will use for the examples below are from DFIR Madness… more specifically, from The Case of the Stolen Szechuan Sauce challenge.

We will begin our demonstration by starting with the domain controller from The Case of the Stolen Szechuan Sauce challenge. While AIM provides you with a password to login as a local administrator on a domain controller, allowing you to use various GUI administrative tools, we will use an administrative command prompt right from the Windows logon screen instead.

First, we identify the IP addresses which were last used by both the domain controller and the workstation we want it to talk to (keep in mind that you may need to wait a bit for the DNS service to start running before you can run dnsmgmt successfully):

Second, we identify the domain controller’s primary network interface:

Third, we change the domain controller’s IP address on its primary network interface to what it was before the disk image was obtained:

Fourth, we restart the DNS service:

Fifth, we run ADUC to reset Morty Smith’s password:

Sixth, we launch the Windows 10 workstation into a virtual machine:

Seventh, we identify the workstation’s primary network interface and then change its IP address to what it was before the disk image was obtained:

Eighth, we change the workstation’s DNS to point at the domain controller:

Ninth, we ping the domain controller to make sure the two AIM-launched virtual machines can talk to each other:

Tenth, we logon with the password we set earlier for Morty Smith:

Eleventh, we check to make sure that Morty Smith has received Kerberos tickets as expected from the domain controller:

Twelfth, we start browsing around the workstation as Morty Smith… and seamlessly accessing any protected content we come across!

I hope you found this Insights article useful! Please let us know if there are more aspects of Windows server and workstation interaction within virtual machines that you would like addressed in future articles.