As reported by Dark Reading, forgotten service accounts in a Chilean organization's Microsoft 365 environment enabled data theft — demonstrating that even robust employee account controls cannot compensate for unmanaged, orphaned identities lurking in the background.
This incident underscores a structural blind spot in cloud identity governance that Shield53 has flagged repeatedly: service accounts are treated as infrastructure plumbing rather than privileged identities. They persist through employee turnover, reorganizations, and migrations. Nobody owns them. Nobody audits them. And when attackers find one with stale credentials, wide API permissions, or lingering admin roles, the entire tenant becomes exposed.
Why M365 Service Accounts Are Uniquely Dangerous
Microsoft 365's service account ecosystem is sprawling. Unlike traditional on-premises Active Directory where service accounts are at least visible in a single directory, M365 introduces multiple identity layers: Azure AD service principals, app registrations, Exchange Online mailbox service accounts, PowerShell automation identities, and third-party OAuth integrations. Each carries its own permission model, authentication flow, and audit surface.
The Chilean incident illustrates the core failure mode: an organization locks down user accounts with MFA, conditional access, and session policies — but a forgotten service account with mailbox access or Graph API permissions bypasses all of it. The attacker doesn't need to defeat modern authentication. They need a credential that was never rotated, never enrolled in MFA, and never reviewed because nobody remembers it exists.
Who Is Most Exposed
Mid-size and enterprise organizations that migrated to M365 rapidly during 2020-2022 are at highest risk. These migrations typically created service accounts for mailbox migrations, calendar sharing, third-party backup integrations, and reporting automation — many of which were never decommissioned. Public sector, financial services, and healthcare organizations tend to have the most sprawl due to complex compliance and integration requirements.
Specifically vulnerable configurations include:
Beyond the Headline: The Deeper Problem
Service account governance is an identity lifecycle failure, not a tooling gap. Organizations buy PAM solutions but never inventory what needs to be managed.
The Chilean breach isn't an anomaly — it's the predictable outcome of an industry-wide pattern. Security teams focus on human identity because humans complain, trigger HR processes, and show up in HRIS systems. Service accounts are invisible to HR, often invisible to ITSM workflows, and only partially visible to IAM tools. The gap between what exists in Azure AD and what's documented in any asset register is where attackers operate.
Worse, Microsoft's own tooling doesn't make this easy. The Entra ID admin center shows service principals and app registrations, but there's no single dashboard showing which accounts have stale credentials, which have never signed in, and which carry tenant-wide permissions simultaneously. Defenders must stitch together Graph API queries, sign-in logs, and permission audits manually.
Shield53 Recommendations
Immediate Actions (First 72 Hours)
- Inventory all service principals and app registrations — Export the full list via Graph API or PowerShell. Flag any with credentials older than 90 days or no sign-in activity in 60 days.
- Audit Graph API permissions — Review every app registration and service principal for tenant-wide
Mail.Read,Files.Read.All, orDirectory.Read.All. These are attacker gold. - Remove unused credentials — Delete client secrets and certificates for service principals that haven't authenticated in 30+ days. You can regenerate if needed.
- Enable sign-in logs for service accounts — Configure diagnostic settings in Entra ID to send all sign-in activity to a Log Analytics workspace for monitoring.
Strategic Actions (30-60 Days)
- Implement quarterly service account reviews — Owner attribution, permission justification, credential rotation schedule. No account persists without a named owner.
- Apply least-privilege remediation — Replace tenant-wide Graph permissions with application-specific scopes or use resource-specific consent where possible.
- Transition to workload identities and managed certificates — Where possible, move automation to managed identities or certificate-based authentication with automated rotation via Azure Key Vault.
- Deploy conditional access for service accounts — While not all policies apply, location-based restrictions and risk-based access can limit blast radius for legacy accounts that can't be eliminated.
- Create a disposal process — Every new service account must have a documented expiration or review date at creation time. No exceptions.
The lesson from Chile is uncomfortable but necessary: you cannot secure what you forgot you had. Identity hygiene isn't about the accounts you can see — it's about finding the ones you can't.
