A Password Reset Will Not Undo This: How Two Intrusions Turned a Fake Support Call Into Certificates for Privileged Accounts
Microsoft Threat Intelligence describes two intrusions where attackers went from a user-approved remote session to certificates for privileged accounts and even a domain controller, by abusing weak Active Directory Certificate Services settings. Here is the briefing and the layers that close each gap.
Here Is How Layered Defenses Close the Certificate Gap
Most businesses that run Windows networks have heard about fake help desk calls. Fewer have looked closely at a quieter piece of their infrastructure: the internal certificate authority. In two intrusions investigated by Microsoft, the remote session was only the start. What made the attacks dangerous was what came next, when the attackers used the company’s own certificate service to mint credentials for powerful accounts.
This briefing is based on Microsoft Threat Intelligence’s analysis of the two intrusions.
The shared opening
Both incidents started the same way. Attackers sent Microsoft Teams messages and placed calls posing as IT support, using tenant and display names designed to look familiar. They talked a user into opening Quick Assist or another remote support session and sharing the connection code. Once in, they dropped an archive into the Downloads folder, unpacked it into a folder named to look like a Windows update, and launched it with a portable Python, Java or Bun runtime. Then they surveyed the machine and the network, including Active Directory Certificate Services (AD CS). Microsoft stresses that no Teams vulnerability was involved; the attacks relied on persuasion and on weak certificate settings.
Case 1: a template that let anyone ask for anyone
The first network had a certificate template with the weakness known as ESC1. It let a low-privileged user request an authentication certificate while naming a different identity, and enrollment was broadly allowed. The attacker used it to get certificates for three highly privileged accounts. Microsoft’s automated response restricted those accounts, but one privileged account had been excluded from automated containment.
About 90 minutes later, a bigger wave of Teams phishing went to 16 users, compromised a second workstation and produced certificates for eight more privileged accounts. Within seconds of getting one of them, the attacker performed DCSync, copying account data from a domain controller. Automated response blocked more than 1,000 later file-access attempts, but the excluded account stayed usable. The attacker used it to reach a file server and copy data out to an external server with a renamed copy of the Rclone transfer tool.
Case 2: borrowing the domain controller’s identity
The second network did not have the ESC1 weakness, so the attacker used a technique called PetitPotam to make a domain controller authenticate to a machine the attacker controlled. The attacker relayed that authentication to the AD CS web enrollment page, a weakness known as ESC8, and received a certificate for the domain controller itself. That certificate was then used to obtain a Kerberos ticket as the domain controller. Security alerts fired, the customer isolated the workstation, and no further progress was observed.
Why a password reset is not enough
An issued authentication certificate works independently of the password that was first stolen. Resetting a user’s password or reimaging the first computer does not revoke the certificate, and revoking the certificate does not cancel Kerberos tickets already issued. Cleanup needs certificate-aware steps.
The layers that close each gap
- People and process: a firm rule that staff verify any unexpected support contact through a known internal channel before sharing a screen or starting a remote session.
- Collaboration settings: limit which outside organizations can message or call your staff in tools such as Microsoft Teams, and pay attention to impersonation warnings.
- Remote support control: allow only approved remote support tools and workflows, and alert when they unpack archives or launch scripts.
- Application control: block unapproved portable runtimes and scripts from running out of user folders, using a tool such as Windows App Control for Business or an equivalent.
- Certificate hygiene: review templates that allow authentication for requester-supplied names and broad enrollment; remove web enrollment endpoints you do not need; require HTTPS with Extended Protection for Authentication on the ones you keep; and turn off NTLM on enrollment services where you can. Microsoft’s KB5005413 guidance covers the relay protections.
- Auditing: turn on certificate services auditing so certificate requests and issuance are recorded, and keep those logs with your other security records.
- Response without blind spots: treat any exclusion from automated containment as a deliberate decision with a manual backup step, and include certificate revocation and ticket review in your incident playbook.
What this means for your company
If your business runs an on-premises Active Directory, there is a fair chance a certificate service was set up years ago and has not been reviewed since. That is worth a look, because a single permissive template can turn one fooled employee into domain-wide access. No single product fixes this; the protection comes from stacking several ordinary controls so that the phone call, the remote session, the runtime, the certificate request and the cleanup each have their own check.
Not sure how your certificate services are configured, or whether a fake support call could get that far? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
About The Author
