In my last post I talked about how cross-cloud transfers create machine identities on both sides that often persist long after the job is done. The natural question is: so what? What's the actual risk?

Two of the highest-profile breaches in the last two years answer that question.

In October 2023, Okta's customer support system was breached. The root cause was a service account stored in the support system itself — one that had been granted permissions to view and update all customer support cases. Not some cases. All of them.

An attacker gained access to that service account's credentials after an employee inadvertently synced them to a personal Google profile on a work laptop. The credentials persisted in an unmonitored location. The account had far broader access than its function required. And the security team didn't know it was exposed until BeyondTrust and Cloudflare detected suspicious activity in their own environments — weeks later.

134 customers were affected. Session tokens were stolen. Five customer accounts were hijacked.

Then in January 2024, Microsoft disclosed that a Russian state-sponsored group — Midnight Blizzard — had accessed the email accounts of senior executives and cybersecurity team members.

The entry point? A legacy, non-production test tenant account that had no multi-factor authentication. That account had access to an OAuth application with elevated privileges in Microsoft's corporate environment. The application had been instantiated as a service principal with permissions broad enough to create new users and assign administrative roles.

The account was dormant. Likely forgotten. The attackers used it to grant themselves full access to corporate mailboxes.

Both of these breaches share the same pattern. A machine identity with more permissions than it needed. Credentials that persisted long after their original purpose was served. A security team that didn't know the account existed. And an attacker who found it before anyone else did.

Now consider the cross-cloud transfer scenario from my previous post.

Every ad-hoc transfer creates service accounts on both sides of a cloud boundary. Those accounts have read access to source data, write access to the destination, and cross-cloud networking permissions. Many are never revoked. Each one is a bridge between two environments that an attacker doesn't have to build — your team already built it for them.

If the Okta breach was caused by one over-provisioned service account in a single system, what's the risk profile of dozens of orphaned accounts spanning two cloud environments?

How many orphaned service accounts from past transfers are still active in your environment right now?