I don’t think any of the three needed a clever attacker at the front door. In each case, a credential was issued for a piece of work and then left alone long after the work had finished.
Getting the groundwork in first
It is a relatively simple task to create a playbook. However, a playbook relies upon an inventory. In many organizations, this inventory consists of a service account list generated from Active Directory where half of the description fields have been left blank. Each time you identify a high-privilege non-human identity, document the team responsible for that identity, and provide a brief explanation (one or two sentences) describing what will fail should you remove that identity. Many people do not include the explanation as to why something would fail if removed, since obtaining this information requires contacting the application team for clarification; this contact would otherwise be initiated by your analyst at 3:00 AM while the attacker remains active within your network.
Next, sort those identities by blast radius. I wouldn’t put a read-only reporting token on the same response path as a cloud admin service principal, and I doubt your auditors would either. For the top tier, settle in advance who’s allowed to authorise an immediate revoke even if it knocks something over, and put that role in the playbook by name. Executives must own that call. If you leave it with whoever’s on shift, you’ll get a polite wait for permission while the token stays live. For SOCI-regulated entities, there’s an extra edge to this, because the 12-hour window for reporting a significant cyber incident to ASD can be running while that conversation drags on.
