\x01 intro

In my quest to continue honing my skill set, I am revisiting CyberSecLabs which I worked on a few years ago but dropped off for some reason. I enjoyed the platform and wanted to come back. Our first box to review is Secret - which is rated as a pretty straightforward box.

We start with SMB enumeration which reveals a cleartext password. Using a list of possible users, we find a user in the domain who is using the password. From there, autologon credentials were discovered in the registry which was valid for another user who had replication rights over the domain object because of an over-permissive nested group membership.

Without further ado - let's jump in!

\x02 Enumeration

As always, we start with a nmap scan to find open ports and services. This time around, I didn't do a full service and version scan and instead chose only to scan open ports and go from there.

We have quite a few ports open, including Kerberos, SMB, LDAP, and Windows Remote Management. Ports 53 and 88 points us in the direction that we're working on a domain controller.

Let's enumerate some ports and see what we're up against.

53/tcp    open  domain           syn-ack
88/tcp    open  kerberos-sec     syn-ack
135/tcp   open  msrpc            syn-ack
139/tcp   open  netbios-ssn      syn-ack
389/tcp   open  ldap             syn-ack
445/tcp   open  microsoft-ds     syn-ack
464/tcp   open  kpasswd5         syn-ack
593/tcp   open  http-rpc-epmap   syn-ack
636/tcp   open  ldapssl          syn-ack
3268/tcp  open  globalcatLDAP    syn-ack
3269/tcp  open  globalcatLDAPssl syn-ack
3389/tcp  open  ms-wbt-server    syn-ack
5985/tcp  open  wsman            syn-ack
9389/tcp  open  adws             syn-ack
49665/tcp open  unknown          syn-ack
49667/tcp open  unknown          syn-ack
49668/tcp open  unknown          syn-ack
49670/tcp open  unknown          syn-ack
49671/tcp open  unknown          syn-ack
49704/tcp open  unknown          syn-ack
49756/tcp open  unknown          syn-ack

RPC - 135

There are a few ports I always check first, and RPC is one of them. If anonymous connections are enabled, we can view users in the domain, query domain information, and more.

However, in this case, we aren't so fortunate. When binding using rpcclient, we get access denied. Bummer...it was worth a shot.

LDAP - 389

Given the fact we couldn't bind anonymously via rpcclient, the chances of anonymous access via LDAP are slim to none. However, it's essential to check everything and validate.

Using ldapsearch, we don't get anywhere quickly because valid credentials are needed to bind - figures.

SMB - 139/445

Another service I like to enumerate first is SMB. We have a few tools at our disposal to enumerate SMB - smbclient, smbmap, and crackmapexec. Just because, let's use all three.

SMB Enumeration via smbclient

Using smbclient, we connect anonymously and find an intriguing share called Office_Share

Connecting to the share reveals a few potential users and a Template directory

After enabling recursive listing, we find a file named Default_Password.txt in the Template directory.

After downloading the file, we get, you guessed it, a default password -

SMB Enumeration via smbmap

Running smbmap with recursive share listing, we see the same file - smbmap -H 172.31.1.4 -u "//" -R

SMB Enumeration via crackmapexec

Using crackmapexec to list shares and see that we have read access to the Office_Share share

Did we need to use three separate tools to enumerate SMB? No. Nevertheless, it's nice to have numerous ways of doing the same thing just in case a particular tool doesn't work for whatever reason.

\x03 Generating User List

Remember what we saw in the Office_Share share? A list of possible users. Let's take those names and put them in a new file called users.txt

Ben Dover
Joe Cakes
Kurby Curtis
Lee Frank

I used namemash to generate a word list of permutations of the names we found which should cover possible AD username schemas.

Finding Valid Users

We have a list of possible username formats, but we don't know which format is being used in the domain. I used kerbrute to go through the word list to find valid users in the domain.

Kerbrute was able to validate 4 usernames - nice!

Now that we have what appears to be a default password (remember, we found that via SMB enumeration) along with a list of valid users, I used crackmapexec to spray the password to see if any user was using that password.

We got a hit! Good ole' jcakes never changed his password from the default - shame on you, Joe. Good for us, bad for him.

\x04 Using Discovered Creds

Great, we have credentials, now what? Well, since we have credentials, are there any service accounts that we can kerberoast? What about potential ASREP roasting? We can use crackmapexec or Impacket to do these checks. In our case, there are no accounts to roast.

Again, I used two different tools for the same check just to show their use. You don't need to use both every time, but it's nice to know just in case one doesn't work.

What about WinRM?

If we recall, our nmap scan found port 5985 to be open which means the Windows Remote Management service is running. Let's confirm if we have access.

Using the winrm protocol in crackmapexec, we can see if jcakes can get a shell via Windows Remote Management. In this case, we can.

We're able to utilize WinRM because jcakes is in the BUILTIN\Remote Management Users group in AD.

\x05 Sniffing with BloodHound

Since we have valid credentials, let's use BloodHound.py to run the BloodHound ingestor to further our AD enumeration and likely attack vectors.

python3 /opt/BloodHound.py/bloodhound.py -c all -u jcakes -p 'Sxxxxxxxx!' -d secret.org --zip -ns 172.31.1.4

Once the zip file is uploaded to BloodHound, we begin to analyze what we have and find something interesting.

bdover is a member of the Service Accounts group which for some reason is a member of the Administrators group. Why? Who knows.

Due to this nested group membership, members of the Service Accounts group automatically have GenericWrite permissions over Domain Admins. This would allow us to modify the group membership of Domain Admins if we wish.

However, since bdover is technically in the administrator's group (nested groups), he has replication privileges over the secret.org domain object. We can simply do a DCSync attack to dump ntds.dit and own the entire domain.

We have an issue though...we don't have a way to go from jcakes to bdover - yet.

\x06 Evil to Get Initial Access

As jcakes can use WinRM, we utilize Evil-WinRM to get our initial shell on the box and get our user flag.

On the Box Enumeration

Once on the box, I did the usual low-hanging fruit enumeration such as running services, local ports, user group membership, etc., and came up short.

To make this easier on myself, I tried to load both PowerView via the upload feature in Evil-WinRM and using Invoke-WebRequest & IEX and hardly got any output other than errors and a DLL hijack path.

Okay, let's use another tool. It seems to be a theme of this post - numerous tools to do the same thing. This time, let's use WinPEAS. I use the upload feature in Evil-WinRM to get WinPEAS on the box.

After running and reviewing the output, we find an autologon password. Where might this work?

The password could have been discovered manually by running REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon" /v DefaultPassword.

\x07 Owning Domain

From the BloodHound dump, we have a pretty good idea of our attack path along with uncovering a new password. When we find a new credential, we need to go back to the start and see what we can access with it.

Since bdover is required for our attack path, let's check to see if the password we just found works for the account. This can be done using crackmapexec.

Since we see Pwn3d!, we know it's game over. We have credentials for bdover who has replication rights - the next step is an DCSync attack.

Using secretsdump, we can do an DCSync attack and dump ntds.dit

With the administrator hash, we can use Evil-WinRM again to get a privileged shell on the box -