Pentesting Restrictive Environments – Part 1

The Scenario

On a recent engagement, the client was focused on testing the controls that were in place within the environment. The client wanted a penetration test conducted as a malicious employee using a heavily restricted, domain joined Windows host. The other caveat is that the client would be actively looking for me and works under a 3 strike system. I want to be clear that the client was not physically looking for me but that they were attempting to find me by alerts generated through malicious activity. For example, if I trigger the antivirus. If the client finds me 3 times, the engagement is over. Each time I am found I will be forced to move to a new location and use a clean Windows operating system (per their incident response policy).

It should also be noted that the Group Policy (GPO) applied to these systems is very strict. Some of the restrictions that I can recall are:

  1. Mass storage
  2. Command Prompt
  3. PowerShell (or Powershell ISE)
  4. Access to the C: drive
  5. Registry
  6. Task scheduler
  7. Computer Management
  8. Services
  9. Network configuration settings
  10. Any other common administrative tools

The PC could not be booted by USB without enabling it in the BIOs (which was password protected) and the client specifically requested that we do not take apart any hardware. Since the drive was unencrypted, an attacker could theoretically use a drive reader to extract the SAM file and try to crack the built in Administrator account (or pass the hash if the account is shared).

The client does not allow their employees to bring in external devices, therefore I would not be able to plug an external device into the network. With 802.1x controls in place- any attempt to plug in an external device would be met with 1 strike.

Instead of thinking of this as a network penetration test, I thought of this as a controls test. A successful engagement would mean I circumvented the controls. There wasn’t going to be any way to easily do that with all the restrictions so I devised a plan. Here’s a picture of the solution:

                      Figure 1: Portable Backpack LAN aka PacLan

 

After some thinking, I decided it was reasonable to assume that a wireless dongle would be authorized. Ideally this meant I would go into the environment, plug the dongle into the desktop I was testing from and connect to my portable backpack network. I will be referring to this setup as PacLan.

To turn the PacLan into a reality, I began ordering some things.

 

What you will need

  1. Low Profile Edimax Wi-Fi USB x 2
  2. ODROID-C2
  3. Don’t forget the ODROID-C2 case like I did
  4. ZyXEL Wireless Travel Router
  5. Crave PowerPack 50,000 mAh battery
  6. Memory Card Reader/Writer
  7. MicroSD Card

 

In the next blog we will be putting all these pieces together!