Low-code, long memory: when an Okta Workflows flow becomes the attacker
An attacker builds an Okta Workflows flow that provisions accounts, steals tokens, and resets MFA on a schedule. It keeps acting long after the attacker's admin session is gone.
Okta Workflows is a low-code automation engine that runs inside your identity provider, and the identity provider is Tier-0. An attacker who builds a flow there has built a principal that outlives them.
How the attack works
With Okta admin access, the attacker creates a flow that blends in with legitimate provisioning automation and stores its own Okta API connection, a long-lived token, so it can call the API without a logged-in admin. On a schedule and on a trigger, the flow provisions a hidden account with admin-adjacent group membership, resets a target’s MFA factors, and posts a freshly minted API token to an external endpoint. When the attacker’s interactive admin session is revoked, the flow keeps running. This maps to T1098, Account Manipulation, and T1648, Serverless Execution.
Why it works
The automation is its own principal. It acts through a stored connection, not the attacker’s session, so resetting the human admin’s password does nothing. Okta stamps these actions with a flow-run transaction in the System Log, which is also how you tell the robot from a human.
How to fix it
Disable the rogue flow so scheduled and triggered runs stop, then revoke the API token its connection holds so even a duplicated flow has no credential. Resetting the admin or suspending touched users is not containment. For the class, scope who may author Workflows and create connections, inventory existing flows and stored tokens, and alert on flow create and modify events. Treat Workflows authorship as a Tier-0 privilege.
Practice it
We built this as a GraphLattice Range scenario so responders learn to kill the automation principal, not just the human session.