Hello folks and welcome to the fourth mini paper in my series “from the darkened room”. This mini paper is looking at what actually goes into the reconnaissance part of a penetration test, and how the recon phase alone meant game over on a test. I am going to run through a job I worked on with a good friend and fellow tester very recently.
The job was reasonably a simple job. Perform a penetration test against the external IP addresses space and top-level domain. The only information given to us was the top-level domain. The .com name. We had 15 man days to do the job, which would prove to be more than enough time. This is the actual scope that was provided:
“Over a period of 15 man days, complete an external penetration test of REDACTED.com. All IP addresses, sub-domains and any connected domains that are clearly owned by REDACTED are considered within scope. No DOS attacks.”
This kind of scope is the sort of scope that is a tester’s dream. Everything is on the table and the only forbidden action is a denial of service attacks.
Where to start
The scope provided was a single .com top level domain. Of course the easy thing to do was run a lookup on the domain and get an IP address as a starting point. Using the Hurricane Electric (bgp.he.net) we could easily see the assigned network is a /22 CIDR. A /22. For those of you who do not know what a /22 address block is, it is a block of 1024 continuous IP addresses. Internally in the business the client has a very small IT team but that IT team know how to monitor OSSIM. And monitor it they did, closely for 15 days.
With a /22 in play, we deployed mass to quickly identify the available host. While that ran we used a number of DNS enumeration tools to identify every DNS host possible. Looking through the DNS records it was clearly apparent that the client used Office365. Knowing this means we have our phishing angle and pretty much every tester is going to have Office365 templates they can throw into GoPhish for a quick and dirty phishing expedition.
At the end of the DNS enumeration run we have 117 valid DNS entries. That might seem a lot of running these through eyewitness meant we had an easy visual way to review the entries quickly.
Portscanning 1024 addresses
Looking at the output from masscan, we had 455 active hosts. We suspected there were some more but we can review that if needed. With that number of hosts, we needed a fast way to iterate through them. Hello sniper. If you have never used sniper, it was written by xerosecurity and is a quick and easy way to run through a large number of tools for a large number of hosts. With more time on the clock I would have done this manually but with the number of hosts and the time in play we needed to be targeted.
Our version of sniper is a little different, it has been modified to include a number of really current exploits, including our BlueKeep RCE exploit. We do not usually run offensive scripts but we have used sniper for a long time now and have extensively customised it. So, as they say on TV, DONT DO THIS AT HOME!
Dont Do This At Home!!!!!
Off we go, with the first pass of sniper was a simple review of the hosts. It is an aggressive review, the only part disabled was DOS and DDOS.
We were actually making a brew when we heard “never gonna give you up”. Odd, this is almost the end of day 1. We cant have shell. Suffice to say that brew never got made. A single Windows 2008 server was present, running RDP. The perfect storm. we had a shell.
Shell to the AD server
The shell we had was for an admin user. Result we thought. Sadly for us the server was not joined to the domain. But how lazy can an admin be. We have the password hash. If they are running a 2008 server, have they enabled SMB signing? Probably not. Well the answer it turned out was no, they hadn’t. The AD server accepted the hash to authenticate. But then the user cant be a domain admin can they? No, of course not.
Admin Account to Domain Admin
Looking at the user names, we can see a few users have firstname.lastname.da. The .da must stand for domain admin. Bets on the admin using the same password? We ran the hash through our password cracking rig and the following day had the clear text. Logging into the AD server with the users domain admin user name, yes you guessed it, the password was the same.
At this point it was end game. We were three days into a fifteen day engagement with a domain admin account. We informed the client contact and stopped the test as we achieved the goal of the test. Thankfully the client asked us to continue with a series of health checks to use up the time.
In the end we had a cascasding failure.
Windows 2008 was not patched which gave us shell
An admin was still logged in (idle) on the server so we got the password hash from memory
SMB signing was not enabled so we re-used the hash to log into the ad server
The password was not strong, so we could crack the password over night
The admin shares their password between their windows account and their .ad account.
Five issues, chained together, resulted in us being able to simulate taking over the entire companies IT infrastructure in three days.
How about you?
When was the last time you let the testers take the gloves off? In a conversation with the clients CIO afterwards, he expressed dismay. They had been tested by every six months for a couple of years by top ranking testing firms who had never identified a Windows 2008 server. I asked him a very simple question:
Did you confine them to a particular scope?
We all know the answer to that question. So, if you are commissioning a penetration test and you really want to know where the chink in your armour is, don’t constrain the testers. Let them have an open scope.