by Jason Downey

The Vendor Requirement

The final entry in The Aftermath blog series. At this point, I had successfully social engineered credentials, bypassed multifactor authentication, and established command and control within my client’s environment. In this last entry, we’ll discuss how I leveraged a vendor requirement to escalate to Domain Admin.

What Had Happened Was…

Active Directory Certificate Services (AD CS, not ADCS, by the way) has been one of my favorite things to exploit over the past year. Since the folks at SpecterOps released their research on AD CS, it has led to more Domain Admin escalations than any other method in my arsenal. This environment became yet another notch on my belt.

Using Certify, I identified a certificate template that allowed the requesting user to supply its own Enrollee Name—meaning I could specify any username I wanted to receive a valid certificate for. If I wanted to be Batman, I could request a certificate as Batman. I just wanted to be Domain Admin—so that’s exactly what I did.

This misconfigured template instantly granted me Domain Admin privileges. Any attacker with network access and knowledge of this flaw could have done the same.

The Disclosure…

When I informed the client that I had escalated to Domain Admin, they were flabbergasted. They didn’t even know what that certificate template was for. After some digging, they realized it was required by a third-party vendor’s product. The vendor’s installation guide had instructed them to configure it this way, and they had simply trusted that it was safe.

After further discussion, it became clear that the vendor had no real understanding of AD CS security—they just knew they needed to use it. Their requirement for allowing users to supply their own Enrollee Name wasn’t even necessary.

The Impact…

Trusting a vendor to provide a secure solution had left the entire organization open to complete compromise. AD CS misconfigurations are far too easy to accidentally set up—and even easier to exploit once discovered.

Thanks for following along with this series. Hopefully, you’ve learned something that can help better secure your own environment against some of the attacks we have the most success with.


About Jason Downey, Security Consultant

Jason Downey has over ten years of professional experience in IT and information security ranging in a variety of roles in network security roles with additional experience in systems administration. Jason has spoken in front of various audiences ranging from youth initiatives to major security conferences, while creating informational content on SiegeCasts and forward-facing marketing channels. Jason excels at a variety of penetration testing tactics and is well known for his vishing and social engineering expertise.

Certifications:
CRTO, GPEN, GCIH, CCNA R&S, CCNA Security, CEH, CHFI

Authentication vs. Authorization in Web App Penetration Testing

By Red Siege | June 4, 2025

by Douglas Berdeaux Introduction Authentication and Authorization in web application penetration testing are so closely related, that it’s easy to confuse the two. This article aims to outline each process, […]

Learn More

Authentication vs. Authorization in Web App Penetration Testing

The Aftermath Part 3: The Simple Stuff

By Red Siege | June 2, 2025

by Jason Downey The Simple Stuff So far in The Aftermath Blog Series, I had social engineered credentials, bypassed MFA, and gained access to a VDI environment. In this entry, […]

Learn More

The Aftermath Part 3: The Simple Stuff

The Aftermath Part 2: The Condition

By Red Siege | June 2, 2025

by Jason Downey The Condition In the first entry of The Aftermath Blog Series, I was able to social engineer a set of domain credentials. In this entry, we’ll discuss […]

Learn More

The Aftermath Part 2: The Condition

Find Out What’s Next

Stay in the loop with our upcoming events.