Beyond the User: The 40:1 Non-Human Identity Nightmare
Saw the webinar promo on THN regarding the 68% cloud breach stat attributed to compromised service accounts. Honestly, it tracks perfectly with what we're seeing in the wild. The days of worrying solely about user phishing are effectively over; the real danger is the 'zombie' credentials left behind.
The 40-to-1 ratio of non-human to human identities is terrifying when you actually try to inventory them. Most orgs have rigorous HR offboarding for users, but who owns the lifecycle for a container's service account or a legacy OAuth grant? When a project ends or a developer leaves, those API tokens often persist indefinitely.
We started querying for stale service principals recently and found accounts with GlobalAdmin roles that hadn't authenticated in over a year. Here is a basic KQL query we use in Sentinel to identify these ghosts:
AADServicePrincipalSignInLogs
| where ResultType == 0
| summarize LastLogin = max(TimeGenerated) by AppId, ServicePrincipalName
| where LastLogin < ago(180d)
| project AppId, ServicePrincipalName, LastLogin
| order by LastLogin asc
Enforcing rotation is a political nightmare, but leaving them is a security risk. How are you guys handling non-human identity lifecycle? Are you relying on CSP native tools or building custom automation to revoke orphaned keys?
This is a massive blind spot for a lot of SOC teams. We've started correlating sign-in logs with ticketing system data. If a service principal hasn't been used in 90 days and there's no active change request tied to it, we trigger an automated disable script. The false positives were high at first, but it forced dev teams to actually document their automation.
On the AWS side, IAM Access Analyzer is your best friend here. It helps identify external access and unused roles. Also, don't forget about Kubernetes service accounts. We found a forgotten K8s SA that had permission to mount the host's root filesystem. It's not just cloud provider IAM; it's the orchestration layer too.
I rarely need to exploit a zero-day during cloud engagements. I just run a basic git secrets scan or look for .env files in repos. Devs accidentally commit keys, forget to rotate them, and suddenly I have persistent access to their S3 buckets. The hygiene around non-human identities is practically non-existent in most startups.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access