1. Executive summary
Dark Reading reported on 24 September 2026 that an unnamed organisation in Chile lost data from its Microsoft 365 environment after attackers used forgotten service accounts rather than employee credentials. The item as supplied is a headline and a single-sentence summary: no victim is named, and no timeline, initial access vector, tooling or indicator is given. No CVSS score, severity rating or CISA KEV entry was resolved for this item, so no vulnerability-level severity can be stated and none is implied here. The exposure for EMEA financial services clients is not a specific exploit but a control gap: non-human identities in M365 are routinely excluded from MFA, credential rotation and sign-in monitoring, so they survive the account lockdowns that follow a human-account compromise. Treat this as a prompt to audit service principals and app registrations, not as an incident affecting clients.
2. Regulatory framing
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| DORA Art. 17: ICT-related incident management process | The reported intrusion path is a non-human (service) account, a class of ICT incident that incident-management processes and detection coverage commonly omit. | Confirm that service-account and workload-identity compromise sits inside the scope of the incident management process, with a named owner, detection source and escalation path, before an incident occurs rather than during one. |
No reporting obligation is engaged by this item. DORA Art. 19 and NIS2 Art. 23 are not triggered: the reported incident is at an unnamed organisation in Chile, no EMEA entity or client is identified, and the source gives no detail sufficient to classify an incident. UK NIS 2018 duties are likewise not engaged on the facts available.
3. Technical analysis & attack chain
The source does not support an attack chain. It states that an organisation in Chile had data taken from its M365 environment and that forgotten or lost service accounts were the means, and it stops there. There is no named victim, no date or duration, no initial access vector, no exploited component or CVE, no payload, no persistence mechanism, no command-and-control, no exfiltration method and no observed impact beyond the loss of data. Nothing in the item indicates ransomware, and nothing indicates extortion. No actor is named, so there is no attribution to assess, confirmed or otherwise.
What the headline establishes is narrow but worth stating precisely: the accounts that were used were service accounts, meaning non-human identities rather than employee logins, and they were described as forgotten or lost, meaning they were still present and still usable in the tenant after their business purpose had ended. That is the whole of the sourced claim.
The following is general context about why that class of identity recurs in M365 intrusions, not a description of this incident. Service principals and app registrations authenticate without a human, so they are frequently left outside conditional access policies, outside MFA enforcement and outside password-rotation cycles. Credentials are often long-lived client secrets stored in scripts, pipelines or configuration files. Application permissions granted to a service principal are tenant-wide by default and are not constrained by the mailbox or site-level scoping that limits a user account. An identity of this kind that nobody owns is difficult to notice when it is abused, because there is no user who will report an unfamiliar sign-in. None of this is confirmed for the Chile incident; it is the reason the reported pattern is worth acting on.
Confidence: single-sourced. The entire item rests on one Dark Reading report, and the report as supplied contains no technical detail to corroborate. Any expansion of this advisory will depend on the full article or a vendor write-up.
4. Mitigation & containment
These steps address the control gap the item describes. They are not derived from a vendor fix, because the source names no product flaw and no patch.
P1, within 24 hours
- Inventory every service principal and app registration in the tenant and identify those with credentials attached. In Microsoft Graph PowerShell,
Get-MgServicePrincipalandGet-MgApplicationenumerate them; the credential objects on each carry the key or secret identifier and expiry. - Disable or delete service principals and app registrations with no sign-in activity in the last 90 days. Where the tenant's licensing exposes service principal sign-in activity, use it as the evidence base rather than assuming an application is in use because it exists.
- Revoke credentials on any service principal that has no identifiable owner. An unowned credential is the condition the source describes.
- Check for the standard post-compromise M365 artefacts in parallel: new or modified inbox forwarding rules, mailbox delegation, added application permissions, and changed SharePoint or OneDrive sharing settings.
P2, within 72 hours
- Apply conditional access to workload identities so that service principal authentication is constrained by location or network where the tenant's licensing supports it. Where it does not, compensate with alerting on service principal sign-ins from unexpected addresses.
- Replace client secrets with certificate credentials or workload identity federation. Secrets are the credential type most likely to sit unrotated in a script.
- Set short credential lifetimes on anything that must keep a secret, and alert on the addition of a new credential to an existing app registration. That event is a common persistence step and is rarely expected outside a change window.
P3, within 7 days
- Review the application permissions held by each service principal and remove tenant-wide scopes that the application does not need. Mail read, file read and write, and directory read and write scopes are the ones that turn a forgotten identity into a data theft path.
- Add service principal sign-in anomalies to SOC use cases, including first-seen IP address, first-seen user agent, and authentication from a country where the organisation has no presence.
- Bring non-human identities into the ownership register and the joiner, mover, leaver process, so that a service account is decommissioned when the system it served is decommissioned.
5. Indicators of compromise
No indicators of compromise available in the source material. The source describes no observable behaviours either, so no behavioural indicator table is provided.
6. Detection
Insufficient indicators to author detection rules.
7. Sources
- Dark Reading, "Ghost Service Accounts Enable M365 Data Theft in Chile", https://www.darkreading.com/cyberattacks-data-breaches/ghost-service-accounts-m365-data-theft-chile, published 2026-09-24.
8. Adverse Trace position
We cannot assign a severity to this item. No CVSS score, severity rating or CISA KEV state was resolved, the source names no victim and no actor, and the report as supplied is a headline with a one-sentence summary. The client-impact assessment is therefore about the control gap rather than the incident: any EMEA financial services client running M365 with service principals or app registrations that lack an owner, an expiry date or sign-in monitoring carries the same exposure the source describes, and that exposure is not reduced by the MFA and password hygiene applied to employee accounts. We will attempt to obtain the full Dark Reading report and any vendor write-up that follows it, and will reissue this advisory with a technical section and detection content if the mechanism, tooling or indicators become available. Clients who want the P1 inventory run against their own tenant can request it through their usual Adverse Trace contact.
Published via PulseTrace — Adverse Trace threat intelligence.