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.
Peter has been in the Information Security world since 1999 and in IT in general since 1996. His work history contains a unique blended balance between the development of exceptional technical capabilities and business knowledge. Peter is a proud father of twins and enjoys GT endurance racing on the weekends.
Last week saw SB Tech Breached by the hacking group Maze. It seems that every week the group are announcing more victims. GameOn asked our CEO Peter Bassill, to give us some insight into the attack. The GameOn article is here.
In our “How to securely” series we asked our followers what tools they would like a simple guide on to help them stay secure online. There seemed to be a lot of confusion as to what a VPN is and why you should or should not use one. So we asked Peter to help.
WhatsApp is among the fastest-growing instant messengers out there, and almost a social network in its own way. But if you are using it, there are some steps you should take to protect your security and privacy.
The UK’s highest court ruled that Morrisons can not be liable for a criminal act of a person seeking to harm their business. On April 1st, 2020, a panel of five justices unanimously ruled that Morrisons was not “vicariously liable”.
With the current pandemic situation, we all need to be taking remote working considerations. While adjusting the work paradym, it is vital to keep a mind’s eye on the security and safety of the businesses information assets
In this guide we are looking at how to go about securing zoom. Since the onset of the global pandemic, we have seen surge in “zoom bombing”. This is where people with malicious intent look for in-progress zoom meetings to join and cause trouble.
On March 27th, Hiscox Insurance Company Inc. filed a complaint against law firm Warden Grier for concealing a data breach that occurred back in 2016.
Chubb Cyber Ransomware Attack? Really? Well yes. It seem that, according the operations of Maze Ransomware, there really was a Chubb Cyber Ransomware Attack.
In a surprising announcement Fortune 500 technology giant General Electric (GE), an organisation that should have this all sown up, disclosed that personally identifiable information of current and former employees, as well as beneficiaries, was exposed in a security incident experienced by one of GE’s service providers. Shock, Horror, Information Security in the supply chain yet again.
NutriBullet has become the latest Magecart victim with skimmer code planted within their domain in order to steal customer financial data. RiskIQ published their research on Wednesday of this week, and it make very good reading.