How not to set password policy

How not to set password policy

TLDR; Weak Passwords = Domain Admin
Estimated Read Time: ~5-10min

This post is about how I ended up with Domain Admin access while doing a recent blackbox penetration test. This post contains abstracts from actual test so most of the confidential info is removed.

It is commonly observed that despite of enforced password policies by SysAdmins, employees tend to use easy passwords. But in some cases, lazy admins don’t even bother about a setting up properly configured password policies. In this post, we will abuse this issue and try to exploit it. We will assume that the client who assigned us the project is EvilCorp (www.ecorp.com).

Let’s start with OSINT. Since the screenshots might disclose more info about the client, I will just write up the methods used to gather info about this assessment. Below is the list of sources and tools which I’ve used for this assessment;

  • Google dorks (intext:”@ecorp.com”)
  • TheHarvester (theharvester -d ecorp.com -l 1000 -b 500)
  • LinkedIn Searches (People: ecorp)
  • Sub-domain Information Gathering ( https://pentest-tools.com/information-gathering/find-subdomains-of-domain )

I’ve used few more during the assessment but only mentioned the relevant tools here.

After we’re done with OSINT, we found dozen of subdomains for the parent domain, but for this assessment we will focus on mail.ecorp.com. We also have a list of around 200 emails of the client. Abstract of 20 emails from the generated list (using common names).

Now let’s create a list of passwords to be used with these emails for bruteforce. I will use python for this purpose.

This will result in a list of following passwords

The list contains 125 password variations for each email, which turns out to be 200*125 = 25000 requests to the server. If the latency to the target client server is low and high bandwidth is available, it shouldn’t take more than ~10min. In my case, it took around 20min to finish of the list of ~1500 emails. (You also need to keep in mind whether the target app is having captcha, behind a firewall, or some other protection)

So now we have list of email and required variations of password which can be used for our bruteforce. But we still need to figure out what and where to send this data, how to parse it etc. Time to have a look at the target mail app

Let’s try to login using any credentials to intercept the request in BurpSuite so that we can use it in our script.

We need to check what kind of response the webserver sends incase of valid and invalid login. In our, the post varilable destination contains a url which the logged in user will be redirected to incase of valid credentials. Let’s put all of this together and finish out working script.

Start the script and wait for it to finish. After the script was finished, I was left with 4 working credentials. Umm, that’s quite low and after the enumeration process (checking the emails etc), I haven’t found anything useful but this

Turned out that Outlook Web App (OWA) provides access to GAL (Global Address List) which works as a directory to find other users inside the domain. This not only provides access to email address but also gives a little overview of the person like Name, Email, Description, Mobile Number, Work hierarchy etc. So I wrote another script to fetch all this info (a single request to web server can give you a max of 200 results, so you need to make a while loop and keep fetching until a duplicate record exists) and ended up with around ~1500 more email ids (can’t share the script since i use a single file to make all of it and that got overwritten in the process or writing some other script 🙁 ). I added these emails to the email list and started the bruteforce script once again, and after several hours, it turned out to be whooping ~350 possible logins. After doing further enumeration of webmail, I came around another credentials for the subdomain connect.ecorp.com.

Using the credentials I was able to login to this portal and after finding/installing up the dependencies, I was presented with this

The provided options are quite self explanatory, we can only use these limited set of applications. To overcome this, you can simply use Explorer and enter cmd.exe in address bar to popup a cmd prompt or use Internet Explorer to download cmd.exe from WINDIR and than run it.

Now as you can imagine, we can simply do many things here. I can try to elevate using metasploit, empire etc but I ended up writing another powershell script for local users present on this system with some more password pattern of commonly used passwords worldwide.

You need to modify the above script to work in a loop, the provided code is to validate the provided user/pwd combination.

I got two local accounts which was part of local Users group by using the above script :(. I used the first account to write cmd.exe at path “C:\Program Files(x86)\P.exe” to abuse Unquoted path issue to elevate to local system Administrator, from here onwards I could’ve used tools to gather cached credentials (Sorry I cannot provide much screenshots here since they contain critical information about the client infra). But the other local account name sounded familiar and it turned out to be in the final user list which I gathered earlier. About time I used the domain username and password and switched to this user’s context to fire up another cmd.exe process and this user turned out to be a part of group “Domain Admins”. A little bit of more info gathering and finally

——END——

One Reply to “How not to set password policy”

  1. It’s in great details. Absolutely struck by how these amazing screenshots were plied up. More interestingly, it’s absolute funny how policies in such companies are in place with the CSO being a total mess.

    Not sure why CSO & CISO’s are even paid up! Excellent read tho.

Leave a Reply

Your email address will not be published. Required fields are marked *