7MS #353: Tales of Internal Pentest Pwnage - Part 1
Buckle up! This is one of my favorite episodes.
Today I'm kicking off a two-part series that walks you through a narrative of a recent internal pentest I worked on. I was able to get to Domain Admin status and see the "crown jewels" data, so I thought this would be a fun and informative narrative to share. Below are some highlights of topics/tools/techniques discussed:
Building a pentest dropbox
The timing is perfect - my pal Paul (from Project7) and Dan (from PlexTrac) have a two-part Webinar series on building your own $500 DIY Pentest Lab, but the skills learned in the Webinars translate perfectly into making a pentest dropbox. Head to our webinars page for more info.
Securing a pentest dropbox
What I did with my Intel NUC pentest dropbox is build a few VMs as follows:
Win 10 pro management box with Bitlocker drive encryption and Splashtop (not a sponsor) which I like because it offers 2FA and an additional per-machine password/PIN. I think I spent $100/year for it.
Kali attack box with an encrypted drive (Kali makes this easy by offering you this option when you first install the OS).
Scoping/approaching a pentest
From what I can gather, there are (at least) two popular schools of thought as it relates to approaching a pentest:
From the perimeter - where you do a lot of OSINT, phish key users, gain initial access, and then find a path to privilege from there.
Assume compromise - assume that eventually someone will click a phishing link and give bad guys a foothold on the network, so you have the pentester bring in a Kali box, plug it into the network, and the test begins from that point.
For one of the tests I worked on, here were some successes and challenges I had along the way:
Even with low-level AD creds, I recommend running Bloodhound/Sharphound against AD to get a map of your target domain, and definitely look at the shortest paths to domain admin to find some high value targets.
Responder no worky
From the subnet my pentest box was placed in, the client had the necessary mitigations to not allow me to abuse LLMNR/Netbios/WPAD. That was good!
.SCF files are my friend
This article was awesome in giving me an idea to stick .scf files on the few shares I could write to. These .scf files have a parameter in them that look for an icon file, and so what you can do is change this parameter to point to
\\your.kali.attacking.box\icon.ico and when people browse the root share where your .scf file lives, they'll send you a hash you can capture with Responder! This allowed me to capture/crack my first set of creds.
Finding points of privilege
With my new credentials, I used CrackMapExec to see where my account had local admin access. From those machines, I used CME to dump the local user database, and found that the local Administrator account had the same hash. I then passed that hash to several servers in the servers subnet and found it worked!
Turn on wdigest
Knowing I had local admin privs on some servers, I used CME's
--wdigest enable flag so that future logons to the server would store creds in plain text.
Later, I came back and used CME again to download procdump and execute it against lsass. Then I ran mimikatz offline against these dumps and found cleartext domain admin creds!
I thought I'd won the pentest, all that was left to do is RDP into the "crown jewels" server and...NOPE! Creds no worky! WTH is up with that?
Tune in next time for the exciting conclusion!