Getting to the (Actual) Goal

While certainly not a new topic, there has been plenty of discussion recently around the goals of pen testing. Many believe that getting DA is the be-all and end-all of an engagement. Others think it might be a valid finding, but falls short of meeting the actual goal.

Periodic reminder: Gaining DA and taking a screenshot is the Active Directory equivalent of <script>alert(“XSS!”);</script>

It implies the _potential_ impact to those in the know, but does _nothing_ to demonstrate impact to less technical folk

— Jeff McJunkin (@jeffmcjunkin) May 11, 2018

I can’t believe pentesters/red teamers still focus on getting Domain Admin. DA is in most cases a waste of access. It’s inefficient. If you’re modeling “sophisticated” (whatever that means) adversaries, abuse the path of least privilege, usually the path of least noise.

— Tim MalcomVetter (@malcomvetter) April 10, 2018

Getting DA is great, you get to do the “it’s raining shells” happy dance all over the place. But it’s often completely unnecessary. Yes, if you have the keys to the kingdom, you can do a lot of damage. What kind of damage can you do if you can only eek out just a little landing pad on the network?

Recently, I had the chance to test this on a few engagements. The first engagement was an internal network pen test. Thanks to some default creds, I was able to land an unprivileged shell on a linux box. I took a cursory look to see if there were any easy avenues to elevate privileges, but quickly abandoned that route in favor of seeing what access I already had could yield. A quick search for world-readable files resulted in unprotected Chef configuration files and backup files which contained dozens of credentials, including some mysql database creds.

This customer was concerned about the ability to access customer data. Using the mysql database creds, I was able to access three databases which contained over 1.1 million tables, including one database with over 800,000 tables. Tables, not rows! These tables contained customer usernames and passwords, account information, and assorted PCI-related data among a host of other data.

On the second engagement, I was performing an assumed breach test and was provided access to a workstation on the customer network. This customer had some very effective security controls. Over the course of several days, I was unable to elevate privileges on my workstation or move laterally to any other hosts. I finally managed to establish a Cobalt Strike beacon, but that was detected within minutes!

I shifted from privilege escalation and lateral movement to understanding what resources were available with my current level of access. I started to enumerate file shares and came across a file share on what appeared to be an application server. With some more research, I discovered this particular server appeared to be responsible for receiving and processing .x937 image cash letter files – scanned images of checks transferred between banks to send and receive payments. I was able to confirm with the customer that these files should not have been accessible.

Scanned check image from .x937 file (Example from x937 software vendor site)

Clearly, without any elevation of privilege, I was able to achieve the customers’ goals of identifying if sensitive information was accessible. In both cases, a breach or a malicious insider could have caused significant harm to these organizations if this data had been stolen or tampered with.

Getting DA is great for the ego, but helping customers reach their goals and secure their organizations is good for the ego as well, and in the end, everyone involved is better for the effort.