A few months back I finished the AD-RTS course material from CyberWarfare Labs — four modules covering core Active Directory internals, Certificate Services abuse, Exchange Server exploitation, and ESXi-to-AD integration attacks. The course itself is dense, but the real test is the 30-day flag-based challenge lab that comes after it: a live, self-contained telecom environment called telecore.ad, built around a fictional company, TELECOM INC., with a Domain Controller, a SQL Server, a PKI/ADCS server, an Exchange server, an IIS-hosted internal web application, and an ESXi hypervisor sitting inside the same domain.

The exam is split into two independent adversary paths. Path 1 assumes zero credentials and zero prior access — you start with nothing but an IP range. Path 2 assumes you already have a low-privilege authenticated foothold on a public-facing web server and have to escalate from there. Both paths converge on the same underlying domain, but the entry vectors, the misconfigurations abused, and the final objectives are completely different. This write-up walks through the full methodology for both paths, exactly as I approached them, without listing the specific flag values captured along the way — the point here is the how, not the what.

Target: TELECOM INC. internal AD forest (telecore.ad) Stack: Windows Server 2022 Domain Controller, MS SQL Server (SQLEXPRESS), ADCS Certificate Authority, Exchange Server, IIS 10 / ASP.NET Web Forms, VMware ESXi with AD-joined authentication Assessment Type: Adversary emulation — unauthenticated black-box (Path 1) and authenticated foothold escalation (Path 2) Tools: nmap, dig, ldapsearch, Impacket suite (GetNPUsers, mssqlclient, wmiexec, secretsdump), hashcat, John the Ripper, GodPotato, certipy-ad, rpcclient, smbclient, pyVmomi, ysoserial.net, exchangelib, netexec

Path 1: Unauthenticated Adversary

The brief for Path 1 is deliberately minimal: you are handed a /24 and told to behave like a telecom-motivated APT starting from zero. No credentials, no internal knowledge, nothing but network reachability into the range.

Mapping the DNS Infrastructure

Every internal Windows environment leans on DNS to keep itself glued together, and that dependency is usually the first crack an attacker can pry open. A UDP sweep across port 53 on the target range revealed multiple name servers, one of which turned out to be a secondary, less-hardened DNS instance sitting outside the domain controller itself. Once I pointed my resolver configuration at that secondary server, a full PTR sweep across the subnet mapped every reverse DNS record in the environment — instantly revealing the hostnames and roles of every server in play: the domain controller, the SQL server, the certificate authority, the Exchange server, and the hypervisor, all before a single authenticated packet had been sent.

The real opening, though, came from testing whether that secondary DNS server would honor a zone transfer request. It did — both in the reverse zone and in the forward zone for telecore.ad. AXFR being enabled on an internet- or perimeter-adjacent DNS server is a classic, almost nostalgic misconfiguration, but it remains devastatingly effective: a single dig command handed over the complete internal namespace, service records, and IP-to-hostname mapping for the entire forest, again with zero authentication.

With the domain controller identified from the zone transfer, the next step was straightforward LDAP enumeration over anonymous bind — pulling the domain’s functional level, then walking the directory for every object under objectClass=user and objectClass=computer. This produces two things that matter enormously for what comes next: a clean list of real domain user accounts (filtered out from the noise of Exchange system mailboxes and health-check accounts that always clutter a mailbox-enabled AD), and a map of which machines in the domain hold interesting roles.

From Kerberos Pre-Auth to a Foothold on SQL

With a legitimate username list in hand, the obvious next move was to test for accounts with Kerberos pre-authentication disabled — the classic ASREPRoasting misconfiguration. Impacket’s GetNPUsers module does this cleanly: it walks the username list and, for any account with the UF_DONT_REQUIRE_PREAUTH flag set, returns a crackable AS-REP hash without ever needing to know the account’s password up front. One of the service-oriented accounts in the environment had exactly this misconfiguration, and the resulting hash fell quickly to a dictionary attack.

Cracked credentials in hand, the next question was where they were actually valid. Cross-referencing against the computer objects pulled during LDAP enumeration pointed straight at the SQL Server. Authenticating to it with Impacket’s MSSQL client confirmed the account held sysadmin-equivalent rights on the instance — enough to re-enable the xp_cmdshell extended stored procedure, which is disabled by default on modern SQL Server but, once flipped back on, gives arbitrary OS command execution in the context of the SQL service account.

From Service Account to SYSTEM

Command execution as the SQL service account is useful, but it’s not the finish line — the account only had ordinary service-level privileges. A privilege check revealed SeImpersonatePrivilege was enabled, which is the precondition for the entire family of “Potato” privilege escalation exploits. On a fully patched, modern Windows Server build, most of the older Potato variants (RoguePotato, JuicyPotato, PrintSpoofer) have been closed off, but GodPotato remains effective against current builds because it abuses a lower-level RPC/DCOM marshaling primitive rather than a specific, patchable service misconfiguration.

Dropping GodPotato onto the SQL box through the xp_cmdshell channel and triggering it against a reverse shell payload elevated the session cleanly from a low-privilege service account to NT AUTHORITY\SYSTEM.

With SYSTEM on the SQL server, the natural move was a credential harvest from LSASS. Rather than dropping a third-party dumping tool that’s likely to trip EDR, I used the built-in comsvcs.dll MiniDump export via rundll32 — a living-off-the-land technique that doesn’t touch disk with anything outside of what Windows already ships. The resulting dump was compressed, exfiltrated back to the attacking host over a simple HTTP upload listener, and parsed offline with pypykatz, which yielded NTLM hashes and Kerberos material for every account that had ever authenticated interactively or as a service on that box — including a domain account with a considerably more interesting set of permissions than the one I’d started with.

Abusing ADCS: ESC1 to Domain Admin

The newly recovered account turned out to have enrollment rights on a certificate template published by the internal PKI, and enumerating that CA with certipy-ad flagged the template as vulnerable to the ESC1 misconfiguration: the template allows the requester to supply an arbitrary Subject Alternative Name while also permitting client authentication, meaning any authenticated user with enroll rights can request a certificate asserting an identity that isn’t their own — including Domain Admin.

Before actually requesting the certificate, it’s worth noting the certifried mitigation Microsoft shipped in response to CVE-2022–26923: modern domain controllers now cross-check the SID embedded in the certificate’s security extension against the SAN identity, so simply putting an administrator’s UPN in the SAN field is no longer sufficient on its own — you also need the correct objectSid for that account, retrievable over RPC with a simple SID lookup against the domain controller. With both the UPN and the correct SID supplied in the certificate request, the CA issued a certificate that authenticated as the Domain Administrator, and that certificate could then be exchanged for the account’s NT hash directly — no interactive logon, no password reset, just a straightforward abuse of a legitimate PKI enrollment workflow.

From there it was a matter of cracking the recovered hash offline and confirming Domain Admin access against the domain controller directly, which also surfaced an interesting security group in the domain that doesn’t exist in a stock AD install: an ESX Admins group, hinting strongly at the next phase of the assessment.

Pivoting into the Hypervisor

ESXi hosts joined to Active Directory for centralized authentication are common in mixed enterprise environments, and telecore.ad had exactly this setup: the hypervisor trusted domain credentials, and membership in that ESX Admins group translated directly into root-equivalent access on the host. With the cracked Domain Admin credential, I authenticated to the ESXi host and used the pyVmomi SDK — VMware’s official Python bindings for the vSphere API — to programmatically enumerate every guest VM running on the hypervisor: power state, guest OS, VMware Tools status, and, critically, the free-text annotation/notes field attached to each VM object.

Notes fields on virtual machines are a surprisingly common dumping ground for exactly the kind of information that should never live there — and this environment was no exception. One particular guest VM had its local credentials sitting in plaintext in its own annotation field, visible to anyone with sufficient ESXi permissions to query VM metadata.

With ESXi root privileges and VMware Tools confirmed present on the target guest, the final move didn’t require touching the guest’s network interface at all. VMware Tools exposes a guest operations API that lets an ESXi-privileged operator execute arbitrary processes directly inside a running guest VM, authenticated with the guest’s own local credentials, entirely out-of-band from the guest’s actual network stack. I used this to launch a reverse shell process inside the guest, landing an interactive session on what the environment had positioned as its most sensitive internal system — completing the unauthenticated attack path from a bare IP range down to code execution on a hardened internal Linux host, entirely through Active Directory, certificate services, and hypervisor misconfigurations chained together.

Path 2: Authenticated Adversary

Path 2 starts from a completely different assumption: you already have low-privilege, unauthenticated-but-network-reachable access to a single public-facing IIS web application, and the objective is privilege escalation and lateral movement from that single entry point through to sensitive business data.

Breaking the ASP.NET ViewState

The target application was a fairly standard ASP.NET Web Forms site — the kind of legacy internal tooling that telecom operators tend to keep running long past its expected lifespan. Web Forms pages carry a hidden __VIEWSTATE field that encodes serialized page state, cryptographically signed (and optionally encrypted) using a machine key configured in the application’s web.config. If that machine key is ever exposed, the ViewState mechanism — designed purely for tamper protection — becomes a fully general .NET deserialization gadget, because the framework will happily deserialize and execute anything correctly signed with the right key.

The application exposed a reporting feature that read files from the local filesystem based on a URL parameter, with essentially no path validation. That’s a textbook local file inclusion primitive, and the highest-value target for it was obvious: the application’s own web.config, which — as is unfortunately common — held its ViewState validation key and algorithm directly in cleartext, alongside a setting that explicitly relaxed the URL-to-filesystem mapping to make path traversal easier rather than harder.

With the validation key, the algorithm, and the ViewState generator value scraped from the page’s own markup, I had everything ysoserial.net needs to forge a malicious ViewState blob. The TextFormattingRunProperties gadget chain — which abuses a WPF-related deserialization path to spawn an arbitrary process — turned that forged, correctly-signed ViewState payload into direct remote code execution the moment it was replayed against the application’s own postback endpoint. No credentials, no authentication bypass in the traditional sense — just a trust boundary (the machine key) that had leaked into a place it was never supposed to be reachable from.

Registry Credentials and DPAPI

Command execution through the ViewState gadget landed in the context of the IIS application pool identity — not a domain account, but still a foothold worth building on. A search through predictable locations on the host surfaced a custom internal application with its own registry key under HKLM\SOFTWARE, storing a domain service account’s username in cleartext alongside a Base64-encoded, DPAPI-protected password blob.

Storing secrets in a machine-scoped registry hive that any local process can read is already a mistake, but the developer had additionally used DPAPI’s LocalMachine protection scope rather than CurrentUser — meaning any process running on that specific machine, regardless of which user account it’s running as, can decrypt the blob using nothing but the machine’s own DPAPI master key. A short PowerShell snippet using the standard System.Security.Cryptography.ProtectedData class was enough to unwrap it and recover a plaintext domain credential for a genuinely useful service account.

A Second Path Through ADCS

That newly recovered service account turned out to have its own enrollment rights on a different certificate template in the same PKI — again vulnerable to the same ESC1 misconfiguration pattern seen in Path 1, just via a different template and a different starting account. The exploitation mechanics were identical: enumerate the vulnerable template, retrieve the target’s SID over RPC, forge a certificate request asserting the Domain Administrator’s identity, authenticate with the issued certificate, and recover the corresponding NT hash — landing Domain Admin from an entirely different starting point than Path 1, but through the same underlying PKI weakness. It’s a good illustration of why a single vulnerable certificate template rarely stays contained to one attack path; if more than one principal can enroll against it, it’s effectively a shared skeleton key for the domain.

From there, authenticating directly to the domain controller as Domain Admin opened up the full SMB share tree, and a look through the Windows Task Scheduler’s on-disk task definitions turned up something unusual: a scheduled task configured to run a PowerShell script under the Administrator’s own context, seemingly for routine mailbox maintenance. Pulling that script down and reading through it revealed hardcoded Exchange service credentials — again stored in plaintext, this time inside a script whose entire purpose was mailbox automation.

Exchange Impersonation and Mailbox Enumeration

The credentials recovered from that scheduled task belonged to an operations-focused service account, and a quick programmatic check against the Exchange server confirmed it had been granted the ApplicationImpersonation management role — an Exchange RBAC role that, by design, allows a single service account to act on behalf of any mailbox in the organization without needing that mailbox’s own credentials. It’s an entirely legitimate feature meant for backup, migration, and integration tooling, but when the account holding it also has weak or exposed credentials, it collapses into a universal mailbox-reading primitive.

Using the Exchange Web Services API with that account’s impersonation rights pointed at the Administrator’s own mailbox, I was able to enumerate the Inbox, Sent Items, and Drafts folders directly — no need to ever touch the Administrator’s actual password. Reading through the recovered correspondence surfaced exactly the kind of operational detail that internal email threads tend to accumulate over time: database credentials shared between a DBA and an operations contact for a production SQL instance, network infrastructure access details passed along in a router-maintenance thread, and references to an internal marketing campaign server mentioned in passing in an unrelated message chain. None of this was the result of a single exploit — it was simply what falls out of an inbox that’s been collecting operational chatter for months, once you have legitimate-looking read access to it.

That last stretch of Path 2 is worth reflecting on separately, because it’s a different category of finding than everything before it. Getting to Domain Admin via ADCS ESC1 is a hard technical exploit with a clean root cause and a clean fix — restrict enrollment rights, disable enrollee-supplied subject, or require manager approval on the template. Reading sensitive operational secrets out of an executive’s inbox because a service account with impersonation rights had weak credentials is a softer, more human failure mode — and honestly the one that’s hardest to fully close, because impersonation itself is a legitimate and necessary Exchange feature. The fix there isn’t technical elimination, it’s credential hygiene and RBAC scoping: impersonation rights should be scoped to the specific mailboxes a given integration actually needs, not granted organization-wide by default, and any account holding that role deserves the same protection posture as a Domain Admin account, because functionally it often is one.

Closing Thoughts

Looking back at both paths together, the pattern that stands out most isn’t any single vulnerability class — it’s how often the misconfigurations were individually mundane and collectively devastating. A DNS server that shouldn’t allow zone transfers. An account that shouldn’t skip Kerberos pre-auth. A certificate template that shouldn’t let requesters pick their own identity. A registry key that shouldn’t hold a password, even an encrypted one, at machine scope. A scheduled task script that shouldn’t hardcode credentials. None of these individually would make a headline vulnerability disclosure. Chained together, in the right order, they took an anonymous position on a /24 all the way to Domain Admin and hypervisor-level code execution, twice, through two completely different entry points.

That’s really the entire thesis of AD-RTS as a certification, and it’s the same lesson every serious AD engagement eventually teaches: defenders tend to think in terms of individual controls, and attackers think in terms of paths. The environments that hold up aren’t the ones with zero misconfigurations — that bar doesn’t exist in any real enterprise — they’re the ones where no single chain of small mistakes reaches all the way to the crown jewels.

If you’re working through AD-RTS yourself, my honest advice is to resist the urge to jump straight to the tooling. Every phase of this exam rewards understanding why a technique works before running it — ASREPRoasting only makes sense once you understand what Kerberos pre-authentication is actually protecting against, and ESC1 only clicks once you understand what a certificate template’s enrollment permissions and SAN policy are actually meant to enforce. The course material front-loads that theory for a reason.

If you found this useful, feel free to connect on LinkedIn or check out my tools on GitHub.