Resourced

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 4000 -Pn 192.168.219.175
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-30 21:34 +08
Nmap scan report for 192.168.219.175
Host is up (0.17s latency).
Not shown: 65515 filtered tcp ports (no-response)
PORT      STATE SERVICE
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
3389/tcp  open  ms-wbt-server
5985/tcp  open  wsman
9389/tcp  open  adws
49666/tcp open  unknown
49667/tcp open  unknown
49670/tcp open  unknown
49671/tcp open  unknown
49703/tcp open  unknown
49776/tcp open  unknown

This is an AD machine.

SMB Guest Creds -> Creds

enum4linux allowed for null credentials, and it listed a lot of users along with a password!

In the description of the v.ventz user, there was a password of HotelCalifornia194!. Using this, we can do password spraying to test each user.

Here's the username list:

However, none of the passwords worked with any user other than v.ventz. This user also did not appear to be within the Remote Management Group because we were unable to evil-winrm in.

SMB Shares -> Secrets Dumping

WIth our credentials, we were able to access some SMB shares, with one sticking out:

We can access this share via smbclient:

These directories had some rather interesting files:

We can download all of these files using some basic SMB commands:

Once downloaded, we can attempt to dump stuff from these files:

Loads of hashes available. Now the question is which user is part of the Remote Management Group?

Bloodhound -> Shell

We can use bloodhound-python to query the domain using the existing credentials we have.

We can then upload all of this information to bloodhound. Then, we find that l.livingstone is part of the Remote Management Group:

We can then evil-winrm in by passing the hash.

Then, we can grab the user flag.

Privilege Escalation

GenericAll -> DA Fail

When viewing the outbound privileges that this user has, we see that they have GenericAll permissions over the DC:

This means that the user has full control over the DC and we can basically do whatever we want. We can abuse this to get an administrator shell via RCBD:

LogoKerberos Resource-based Constrained Delegation: Computer Object Takeover | Red Team Noteswww.ired.team

Bloodhound also provides some commands to abuse this. Here are the commands I used:

Once we have run these, it should work and we can check klist to see that we have the administrator's ticket:

However, even with this ticket, it appears we still cannot access the administrator's desktop (and also we still don't have a shell...)

Proper DA Shell

This machine account fails to be useful to us because we aren't pivoting to another machine in the domain from this one. Instead, we can still use this machine account by simply requesting for the administrator ticket using impacket-getST on our Kali machine, which we can then use to get a shell as the administrator.

This might be possible with PsExec.exe on the domain itself, but I didn't test it out.

Then, we can import this ticket into KRB5CCNAME and use it to get a shell:

Rooted!

PreviousNickelNextShenzi

Last updated