← All field notes
awsstep functionseventbridgepersistence

The backdoor that runs on a schedule, with no server

Cloud persistence does not need a host. An attacker can wire EventBridge to a Step Functions state machine that runs as a role and recreates access on a schedule, in the control plane where no endpoint scan looks. Here is the pattern, and how to remove it.

Attack flow
1Compromise an AWS identity
2Create a state machine + EventBridge rule
3Rule fires on a schedule
4State machine runs as its role
5Recreates access / exfiltrates
Seen in the wildCloud access brokersOpportunistic

You deleted the backdoor user, and an hour later it was back. Nothing re-created it by hand.

What it is

An attacker with AWS access plants persistence using serverless orchestration instead of a host. They create a Step Functions state machine that assumes a privileged role, then an EventBridge rule (scheduled, or triggered on an event) that fires it without them present. The state machine recreates an access key, re-grants a role, or exfiltrates on a cadence. This is T1053 (scheduled task/job) and T1648 (serverless execution) with T1098 (account manipulation).

Why it works

It lives in the control plane, so there is no instance to inspect, and it runs on a schedule with the attacker long gone. Delete the recreated user and the next execution simply mints it again.

How to detect it

In CloudTrail, look for a new EventBridge rule targeting a new state machine whose execution role performs identity actions (CreateAccessKey, role assignments) outside any change window.

The fix that holds

Remove the whole chain: the rule and its targets, the state machine, and the role it assumes. Then least-privilege who can create orchestration and which roles they can pass (iam:PassRole conditions), and alert on new rules or state machines that perform identity actions.

Practice it

We built a serverless-persistence scenario in GraphLattice Range so teams learn to evict control-plane persistence, not reboot for it.