The connector that sees every password: Okta AD agent compromise
In delegated auth, the user's plaintext password passes through the Okta AD agent. Own that host and you intercept credentials in flight and tamper with the results.
The Okta AD agent is a small connector on an on-prem host that bridges your cloud identity provider to Active Directory. In delegated authentication, the user’s plaintext password passes through it, which makes that host Tier-0.
How the attack works
An attacker compromises the agent host and injects a process that attaches to the agent service. As users sign in, delegated authentication forwards their passwords through the agent to AD for validation, and the attacker captures them in transit. They go further, tampering with the agent so selected sign-ins are validated even with wrong credentials, then re-registering the agent so the tampered connector persists through a host rebuild. This maps to T1556, Modify Authentication Process, and T1557, Adversary-in-the-Middle.
Why it works
The agent is a credential choke point bridging two Tier-0 systems, and delegated auth puts plaintext on that host by design. Resetting one user’s password is almost meaningless while the agent keeps intercepting everyone else and tampering with results.
How to fix it
Treat the agent host as Tier-0. Isolate it, revoke and rotate the agent registration and rotate its AD service account, and fail delegated auth closed until a clean agent is stood up. An outbound block does not stop on-host capture. The root-cause fix is to remove plaintext from the path entirely by moving sensitive sign-ins to phishing-resistant passwordless, then tier-isolate and harden the connector hosts and monitor agent registrations. Treat captured credentials as compromised across cloud and on-prem.
Practice it
We built this as a GraphLattice Range scenario so responders learn why the agent host, not one user, is the thing to contain.