In this post, I would like to talk about a very interesting situation that I encountered years ago in an insider threat simulation project.
Target: International Bank
Access Point: Internal
Test Profile: Guest
Before Test:
The customer said that they had penetration testing services from different consulting companies a few times and fixed all vulnerabilities; they just want to be sure they have enough cybersecurity maturity. Also, they added that there will be no exception, no test account and the MITM based attack vectors are out-of-scope.
Day 1:
I discovered that the target organization has successfully implemented a network access control solution and whenever I plug the ethernet cable into my computer (even with cloned MAC address), the cable was turning off for a while and generating a log about the incident. That’s how the IT team was able to detect me.
I started to analyze the personal computers in the organization and realized that almost all of them had fully encrypted disks. But some computers didn’t have that, I tried to plug in a USB drive with Kali Live and boot it but the secure boot feature was enabled. It was not possible to reach storage disks or disable the secure boot feature.
Let’s talk about that,
If the secure boot feature was disabled:
It would be possible to boot the Kali on the target computer via a USB drive and mount the target drive. Then, I could get the SAM File via “chntpw“.
After that, it was going to be possible to dump the password hashes, modify the SAM file to create new users with admin authority or changing the passwords of existing users.
If the storage disk was accessible:
It would be possible to mount it on a different computer and I could get the SAM file as well.
Then, I got an idea. I decided to install Windows on a USB drive and tried to boot it on the target computer. And it did work! The secure boot feature only was checking if the operating system is Windows or not.
With the Windows operating system that I booted on the target computer, I was able to get the SAM file from the storage disk of the target computer.
I dumped the hashes, changed the password and authority of an existing user. After that, I removed the USB drive and restarted the computer. I was able to log in to the computer via administrator authority.
As a next step, I plugged in a wireless USB Wi-Fi adapter, enabled the hotspot feature and accessed the internal network via connecting the wireless access point with my test computer.
I started to try the username and hash combination that I got from the SAM file on all computers in the internal network. I detected the active computers via simple port scan (only on 445 ports).
After I realized that I was able to log in to some computers, I started crackmapexec to dump clear-text passwords and hashes.
In my first scan I only got a few passwords, they belonged to users without any specific privilege. I wrote a script to run crackmapexec regularly to get passwords from LSA memory.
Meanwhile, I decided to run BloodHound and check trusts, privileges on the AD architecture. Disabling EDR solutions took a lot of time because there were a few group policy and similar mechanisms that installs EDR solutions continuously. When I was finally ready to get some data for BloodHound on Windows, just realized that the crackmapexec script had new results. I realized that one of them was domain admin!
Why?
When a user made a connection to a computer, it is possible to find the user’s clear-text password on the memory (in some specific conditions). Probably, one of the domain admins logged into the target computer to check some things or a scheduled job started on a different computer and created a connection to the target computer with domain admin authority to handle daily/weekly jobs. That’s why I didn’t get this password on my first try but I got that from LSA memory after a while.
In just one day, I was able to get the Domain Controller. It shows that the security policies should be implemented throughout the organization without exception. (See: Zero Trust)