Writing
Anatomy of an Identity Incident

Your Vendor's Subcontractor Is Your Attack Surface

Anatomy of an Identity Incident — Okta and Sitel, January 2022. The breach happened on a support subcontractor's laptop. The blast radius was every customer tenant that laptop could reach.

Michael AbramovichApril 5, 20226 min read

Forensic write-ups of public identity breaches, strictly at the identity layer. No vendor is the villain — the point is the structural class of failure, not the logo on it.

The 60-second version

In January 2022, an attacker spent five days with remote-desktop access to a laptop belonging to a support engineer at Sitel — a subcontractor that supplies contract staff for Okta's customer support organization. The engineer was not an Okta employee, and the laptop was not Okta's. But the support tooling that engineer could reach was able to take identity actions inside customer tenants: the sort of help-desk operations, like assisting with password and factor resets, that support exists to perform.

The technical intrusion was small and was caught relatively quickly — Okta's monitoring flagged a new MFA factor being added to the Sitel account and froze it within hours. The part worth studying is everything that happened after: the compromise sat on a subcontractor's machine, the forensic investigation belonged to that subcontractor, and the affected customers did not hear about it for roughly two months. The breach was at the subcontractor. The incident belonged to everyone downstream.

The identity timeline

Only identity-relevant events.

  • Jan 16–21, 2022 — A forensic review later establishes a five-day window in which an attacker had access to the Sitel environment, including remote-desktop control of a support engineer's workstation.
  • Jan 20, 2022, 23:18 UTC — Okta's security monitoring fires an alert: a new MFA factor has been added to the Sitel employee's Okta account from a new location.
  • Jan 20, 2022, 23:46 UTC — Okta investigates and escalates the alert to a security incident.
  • Jan 21, 2022, 00:28 UTC — The account is frozen. The active intrusion, as far as Okta's own environment is concerned, is contained.
  • Late January–February — The investigation now lives at the subcontractor. A third-party forensic firm examines the Sitel environment; its report is dated March 10, 2022 and goes to Sitel.
  • Mid-March — A summary of that report makes its way to Okta. The customers whose tenants were reachable during the window still do not know.
  • March 22, 2022 — The attacker publishes screenshots of internal systems. Only now does the incident become public, and only now do downstream customers learn they were in scope.
  • Impact — Okta states that up to 366 customers — about 2.5% of its base — had tenants that were potentially reachable during the window, while concluding the number where any action was actually taken was far smaller.

Read it as an identity story: the intrusion was contained in hours, but the incident — who was exposed, who needed to rotate what, who had to be told — took two months to reach the people it actually affected.

The pivot point

The pivot here is not the RDP session. Attackers get onto laptops every day. The pivot is the fact that a contractor's laptop, two organizations removed from the customer, sat upstream of identity actions inside customer tenants.

Trace the chain of trust. A customer trusts their identity provider. The provider extends some of its support operations to a subcontractor. The subcontractor hands a support console to a contract engineer. That console can perform identity-affecting actions — the help-desk class of operations — on the customer's users. Every link in that chain is normal and individually defensible. But stack them up and you get this: the security of a customer's identity now depends on the endpoint hygiene of a person they have never heard of, employed by a company they never signed a contract with, doing legitimate work on a console three trust-hops away.

That is the moment the blast radius left everyone's control. Not when the laptop was compromised — when the architecture decided that a subcontractor's workstation would be upstream of customer identity, with no one owning the security of the span between them.

What would have caught it

Naming controls, not products.

Scoping support access to the minimum, and proving it. The most important question after this incident is not "was the laptop secure" but "what could that console actually do to a tenant?" Support tooling that can touch customer identity needs hard, audited limits — and customers need a way to see those limits, not take them on faith.

Tenant-side visibility into vendor and support actions. A customer should be able to see when their identity provider's support function acts inside their tenant — factor resets, impersonation, admin reads — as first-class, alertable events. If the only people who can see support actions are the support organization, the customer is blind to their own blast radius.

Independent detection that doesn't depend on the subcontractor. Okta's own monitoring did fire — that part worked. The gap was downstream: customers had no independent signal. Tenant-level anomaly detection on privileged identity changes gives the customer a tripwire that does not route through anyone else's incident process.

Contractual and technical containment of subprocessors. "Who are our providers' providers, and what can they reach?" is an identity question, not just a procurement one. The subprocessor boundary is exactly where ownership evaporates, so it needs to be drawn explicitly, with access scoped and logged across it.

A notification path that matches the speed of the risk. Two months is not a detection failure; it is an ownership failure. When an incident spans vendor, subprocessor, and customer, somebody has to own end-to-end notification, or it falls into the gap — as it did here.

The last mile

This incident is the cleanest example I know of the last mile having more than two ends.

We usually talk about the gap between a vendor and a customer. Here there were at least three parties — the identity provider, its support subcontractor, and the customer — and the failure lived in the seams between all of them. The provider owned its own environment and, to its credit, detected and froze the intrusion there quickly. The subcontractor owned the compromised endpoint and the forensic investigation. The customer owned the consequences. No one owned the span end-to-end: the stretch from "a contractor's laptop is compromised" to "every affected customer has rotated credentials and knows they were exposed."

That stretch is the last mile, and it is structurally ownerless in any multi-party support arrangement. The provider's responsibility tapered off at the edge of its environment. The subcontractor's responsibility was to its direct client, the provider — not to the provider's customers, whom it had no relationship with. The customer had the responsibility but none of the visibility or tooling: they could not see the subcontractor's console, could not drive the subcontractor's forensics, and could not learn the scope until it was published by the attacker.

The lesson is not "don't use subcontractors." Every provider at scale does. The lesson is that each hop in a support chain adds a span of last mile that someone must explicitly own — with scoped access, customer-visible logging, and a notification path that matches the risk — or the span will be owned by no one, and discovered by the attacker's screenshots.

For defenders

Five things you can check this week.

  1. Inventory who can touch your identity from outside. List every vendor, and every vendor's subprocessor, whose support functions can perform identity actions in your tenant. If you can't produce that list, that's finding number one.
  2. Turn on (and alert on) vendor/support actions in your tenant. Factor resets, admin impersonation, and privileged reads initiated by support should be visible to you and page someone.
  3. Ask your IdP what its support tooling can do — in writing. "What can a support engineer, or their subcontractor, do to my users?" is a fair question with a specific answer. Get it.
  4. Build detection you own. Tenant-level anomaly detection on privileged identity changes that does not route through any vendor's incident process.
  5. Pin down notification SLAs across the chain. Make "you tell us within N hours, even if the breach is at your subprocessor" a contractual term, not a hope.

Built from public reporting and the parties' own disclosures; sources below.

Sources

#okta #lapsus #third-party #subprocessor #last-mile