If your endpoint privilege management (EPM) is compromised: freeze policy, find rogue admin rights and rebuild

Endpoint privilege management (EPM) decides which programs run with administrator rights on every managed workstation and server, so an attacker who controls it can grant themselves elevation across the fleet through policy that looks like normal administration. A single rule that elevates an attacker's binary, an approver account that says yes to every request, or a leaked offline elevation code can undo the removal of local admin rights that the platform was bought to deliver. This guide is a vendor-neutral response playbook for that scenario: how compromise shows up, triage, containment in priority order, finding and removing rogue rights on endpoints, rebuilding the platform, evidence and measurement. It is for endpoint, identity and incident response teams, and assumes the controls in Securing the endpoint privilege management (EPM) itself. For EPM design itself, see the Endpoint Privilege Management Guide.

Key takeaways

• Freeze policy publishing first. The fastest way an attacker reaches every endpoint is a policy change; stop new versions before you investigate old ones.
• Check endpoints, not just the console. Rights granted during the window may persist locally as group memberships, services or scheduled tasks after policy is reverted.
• Rotate local administrator passwords fleet-wide. If the EPM managed or could reveal them, assume every one was exposed.
• Invalidate offline elevation. Challenge-response or emergency codes work without the console; change their secrets or they keep working.
• Treat the agent's identity as a privileged NHI. Enrolment tokens and agent service credentials let an attacker register rogue endpoints or impersonate real ones.

What an EPM compromise looks like

ATT&CK's Software Deployment Tools technique (T1072) describes the core risk: enterprise-wide endpoint management software can give an adversary code execution on all connected systems. The Stryker device wipe through a hijacked management console admin shows the scale one console account can reach; an EPM console reaches the same endpoints with administrator rights.

Triggers and triage

Invoke this playbook for: a policy version published outside a change window or by an unexpected admin; new rules elevating unsigned files, files in user-writable paths, scripting hosts or broad wildcards; a jump in auto-approved elevations; approvals by one approver for one requester in quick succession; offline code use without a matching help desk ticket; new admins, roles, API keys or enrolment tokens; agents reporting stopped or uninstalled on many endpoints; or new members in local Administrators groups across endpoints.

1. Preserve evidence: export the EPM audit log, policy version history with full rule content, approval records, offline code issuance logs, JIT grants and agent health history, plus endpoint security logs, before changing anything.
2. Diff policy: compare every policy version published in the window with the last known-good version and list each added or changed rule, its target groups and the files it elevates.
3. Establish capability: which console role, approver, API key or agent credential was abused, and what it could change.
4. Find elevations actually used: elevation events in the window by user, endpoint, file hash and rule, especially for files not seen before.
5. Check local persistence: local group changes, new local accounts, services and scheduled tasks created by elevated processes in the window.

Containment in priority order

1. Freeze publishing: stop new policy versions and pending deployments; restrict console and API access to named responders on clean admin devices.
2. Revert policy: publish the last known-good policy version to all groups, and confirm endpoints report receiving it. Attacker rules removed in the console still apply on any endpoint that has not checked in.
3. Suspend approvers and JIT grants: remove attacker-created approvers, cancel open JIT admin grants, and move to manual approval by named staff.
4. Invalidate offline elevation: rotate the secrets behind challenge-response or emergency codes and revoke any issued codes the platform can revoke.
5. Rotate platform credentials: console admin passwords and MFA, API keys, directory and ITSM integration accounts, and agent enrolment tokens. See the Service Account Security Guide.
6. Isolate endpoints that ran attacker elevations: see How to Isolate a Compromised Endpoint.
7. Rotate local administrator passwords across the fleet: through a mechanism the attacker did not control, such as the operating system's own local administrator password solution. See the Local Administrator Password Solution (LAPS) Guide.

Before stopping or uninstalling agents, confirm what endpoints do without them in your configuration. Removing the agent should leave users as standard users; if your deployment restores local admin rights when the agent stops, an attacker who can stop agents gains elevation without any policy change.

Finding rogue rights on endpoints

Microsoft's guidance for event 4732 is to monitor changes to high-value groups such as the built-in local Administrators group and to review the subject account against an allowlist of who may change group membership. Run the same query fleet-wide from your SIEM or EDR, compare current local Administrators membership with the expected baseline, and remove anything unexplained.

Where identity fits

An EPM incident is mostly an identity incident on two levels. The human level is the console admins, policy authors and approvers whose accounts were abused. The machine level is less visible and often missed in recovery:

• Agent service identities: each agent authenticates to the server with a certificate, token or key issued at enrolment. If enrolment secrets were taken, the server cannot tell real endpoints from rogue ones until every agent is re-enrolled.
• Integration accounts: directory read accounts used to resolve users and groups, ITSM accounts that open approval tickets, and SIEM connectors. Each holds standing credentials that survive a console password change.
• Service and maintenance accounts on servers: where EPM rules elevate scripts or tools run by service accounts, an attacker rule can attach elevation to a non-human account that nobody watches interactively. Review every rule whose subject is a non-interactive account.
• Local administrator accounts: managed local admin passwords are shared-secret credentials on every endpoint; rotate them and confirm they are unique per device.

Give each of these an owner in your NHI inventory, rotate them as part of the incident, and record their new expiry. See the Tiered Administration Guide for keeping EPM administration in the right tier.

Choosing the response depth

A small organisation with a cloud-hosted EPM and a few hundred endpoints can usually revert policy, rotate everything and reimage the handful of endpoints that ran attacker elevations in a day or two. A large estate needs ring-based reversion with check-in tracking, and a separate push for servers, where an EPM policy may also control service and maintenance accounts. Expect help desk load: tighter elevation during response stops legitimate installs. Agree a break-glass route first; see the Break-Glass Account Guide.

Eradication and rebuild

• Close the entry point: the phished console admin, exposed management interface, stolen API key or compromised admin workstation.
• Restore policy from a verified export pre-dating the window (NIST CSF 2.0 RC.RP-03), then review every elevation rule against the rule types your design allows.
• Rebuild the server or tenant where needed: new hosts from clean images, new enrolment tokens and agent credentials, and re-enrolment of every endpoint so devices enrolled by the attacker do not carry over.
• Re-establish separation of duties: policy authors cannot approve their own changes, approvers cannot elevate for themselves, and console admins use privileged access workstations. See the Privileged Access Workstations Guide.
• Verify endpoint state by querying local group membership and agent policy version across the fleet before closing the incident.

Evidence and notification

• Preserve: EPM audit log, policy versions with rule content, approval and JIT records, offline code logs, agent health history, endpoint security and system logs for 4732, 4672, 4688, 4720 and 7045, and images of endpoints that ran attacker elevations.
• Internal stakeholders: server and application owners whose systems ran elevated attacker code must reassess their own credentials and data.
• Regulators and customers: EPM compromise is a means, not an outcome. Whether notification is required depends on what the attacker did with administrator rights on endpoints. See the Cyber Incident Reporting Requirements Map.
• Provider: for a hosted EPM, request tenant-scoped logs and the provider's own findings in writing.

Detection and measurement

For at least 90 days after recovery (an NHI Mgmt Group recommendation), alert on: policy publication outside change windows; new or broadened elevation rules; elevations of files not previously seen; offline code use without a ticket; approver and admin changes; agents stopping or uninstalling; and event 4732 for local Administrators from any subject not on the allowlist.

• Time from declaration to known-good policy confirmed on all endpoints.
• Endpoints whose local Administrators membership matches baseline, target 100%.
• Local administrator passwords rotated after the incident, as a percentage of the fleet.
• Policy changes with a second approver, target 100%.
• Agent coverage and health, endpoints reporting the current policy version.

Common failure patterns

• Reverting policy in the console and stopping there: endpoints that have not checked in still apply the attacker's rules, and local group changes persist regardless.
• Forgetting offline codes: emergency elevation keeps working on disconnected laptops long after the console is clean.
• Not rotating local admin passwords: if the EPM managed them, the attacker may already hold every one.
• Uninstalling agents as containment: in some configurations this hands rights back to users or removes elevation logging.
• Rebuilding without re-enrolment: rogue devices enrolled with stolen tokens remain trusted by the new server.
• Elevation rules by path: rules trusting user-writable locations let any file placed there run as administrator; prefer hash, publisher or certificate conditions.

Framework mapping

Practitioner checklist

• Keep a known-good export of EPM policy with full rule content, and diff every published version.
• Stream EPM audit and elevation events to a SIEM the endpoint team cannot change.
• Document how to rotate offline elevation secrets and how long existing codes stay valid.
• Baseline local Administrators membership per endpoint group and alert on drift.
• Rotate local administrator passwords with a mechanism independent of the EPM, or know how to switch to one.
• Know what endpoints do when the agent stops, and test it.
• Require a second approver for policy publication and approver changes.
• Exercise a fleet-wide policy reversion and measure check-in time.

Standards and references

• MITRE ATT&CK: Software Deployment Tools
• Microsoft Learn: 4732(S) A member was added to a security-enabled local group
• Microsoft Learn: Windows LAPS overview
• NCSC: Secure system administration
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Account Manipulation: Additional Local or Domain Groups

Related NHI Mgmt Group resources: Securing the endpoint privilege management (EPM) itself · Endpoint privilege management (EPM) health check · If your privileged access management (PAM) vault is compromised · If your EDR and XDR platform is compromised · Endpoint Privilege Management Guide