Test tenants are production when their apps can reach production
Midnight Blizzard reached Microsoft’s executive mailboxes through a test tenant account and an old OAuth app. Whether any non-production identity is a production risk turns on three properties: who can log in to it, what it can reach, and who would notice it acting.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On January 19, 2024, Microsoft disclosed in an SEC filing that a Russian state actor it tracks as Midnight Blizzard had accessed a small percentage of its corporate email accounts. They included members of senior leadership and staff in cybersecurity and legal. On January 25 it published more detail. The actor had used a password spray to compromise a legacy, non-production test tenant account that lacked multifactor authentication. It then used a legacy test OAuth application with elevated access to Microsoft’s corporate environment to create further applications and grant them access to Exchange Online mailboxes. On January 24, Hewlett Packard Enterprise disclosed in its own filing that the same actor had accessed its cloud-based email environment, in activity it said began in May 2023.
Most organizations classify identities by the environment they live in. Production accounts get strong authentication, monitoring and access reviews. Test and development accounts get less, on the reasoning that they hold no real data. Microsoft’s account of the intrusion shows why that classification fails. The test account held nothing of value. What mattered was what it could reach. A better test asks three questions of any identity, whatever its label: who can log in to it, what it can reach, and who would notice it acting. The answers are independent. An identity can be hard to log in to but have vast reach, or easy to reach but closely watched. Risk sits where all three answers are bad, as they were here.
Who can log in: exposure
The first foothold came from a password spray, the oldest identity attack there is. The attacker tries a few common passwords across many accounts, slowly, often from residential proxy addresses so that the traffic looks ordinary. It works only against accounts that accept a password alone from the internet.
In a large Microsoft 365 or Entra ID estate, those accounts cluster in predictable places. Test tenants are created for a pilot and never get the conditional access policies of the main tenant. Tenants inherited through acquisitions keep their old settings. Inside the main tenant, accounts are excluded from MFA because a script or a legacy device could not cope. Each exclusion made sense when it was granted. Few were ever revisited.
The controls are concrete. Keep a register of every tenant the organization owns, with an owner and a baseline. Apply the same sign-in policy baseline to test tenants as to production, or block interactive sign-in to them from outside corporate networks. Treat every MFA exclusion as a dated exception, approved like a firewall rule and reviewed on the same cycle.
Measuring this is straightforward. Count the accounts, in every tenant, that can complete an interactive sign-in from the internet with a password alone. The target is zero, with a short, named list of approved exceptions. Report that number to the CISO monthly, broken down by tenant. The figure tends to surprise. Teams that manage the main tenant well often have no view of the others, because test tenants are created by developers and project teams outside the identity team’s change process. Bringing tenant creation itself under a request and approval workflow stops the problem from regrowing.
What it can reach: privilege across boundaries
The decisive step was the OAuth application. A legacy test app had been granted elevated access to Microsoft’s corporate tenant. That single grant turned a compromised test account into a route into production. Using it, the actor created new applications and gave them a role that allowed access to mailboxes across Exchange Online. No user had to approve anything during the attack. The permission was already in place.
Application identities are easy to overlook because they do not behave like users. They authenticate with secrets or certificates, not passwords. They do not trigger MFA prompts. Many hold tenant-wide application permissions, which work without any user being signed in. A multitenant app registered in one tenant and consented in another creates a trust path that neither tenant’s user review will show.
The inventory that matters is therefore one of permissions. For every app registration and service principal, the organization needs to know what permissions it holds, in which tenants, who consented and when, who owns it, and when it last did anything. In practice, the highest-risk entries are a small set: apps with permission to read all mail, write to the directory, or grant roles to other apps. Those deserve the scrutiny given to domain administrators. Health systems and agencies face a long tail of such apps, from EHR and case management integrations to mail-processing and analytics connectors. The aim is to know, scope and own them, not to remove them.
Who would notice: detection on non-human activity
The third property is visibility. The actor’s actions were unusual for the identities involved. A dormant test application suddenly created new applications. A newly created account granted consent. New applications were assigned a powerful mailbox role. Each of those actions produced audit records. The question for any security team is whether anyone was looking at them.
Most detection content was built around users: impossible travel, unusual sign-in locations, risky sign-ins. Non-human identities need their own rules. A useful starting set flags new credentials added to an existing app and new high-privilege permissions granted to any app. It also flags role assignments to service principals and any activity from an app dormant for months. These events are rare in a well-run tenant, so the alert volume is manageable.
There is a trade-off. Tight monitoring of app activity generates work for identity and security teams who already struggle with user alerts. The answer is to tier: watch the small set of highly privileged apps continuously, and review the long tail in a quarterly attestation by app owners.
Applied together, the three questions give a simple rule. A test identity that cannot be reached from the internet, holds no cross-boundary privilege, and is monitored can stay lightly governed. One that fails any of the three needs production treatment, whatever its tenant is called.
With hindsight
The story widened. In March 2024 Microsoft said the actor had used information from the stolen emails to try to access, and in some cases access, source code repositories and internal systems. In April 2024, CISA issued Emergency Directive 24-02, requiring federal civilian agencies to analyze email they had exchanged with Microsoft that may have been exfiltrated, and to reset affected credentials. Microsoft expanded its Secure Future Initiative in May 2024 and has since reported work to remove unused applications and tenants. The disclosure side also moved. In May 2024 the SEC’s Division of Corporation Finance said companies should use Item 8.01, not Item 1.05, of Form 8-K for cyber incidents not yet judged material. Organizations should work through their own disclosure approach with counsel. Nothing in the later disclosures changed the technical picture: no novel exploit was needed, only an exposed test account and an over-privileged app.