{ "id": "e65e2862-b907-410a-9649-98b8a89ae991", "created_at": "2026-04-06T00:07:08.059736Z", "updated_at": "2026-04-10T03:37:33.417899Z", "deleted_at": null, "sha1_hash": "1124300149ea5da862c0785fb52080456bbee3fd", "title": "Midnight Blizzard attack on Microsoft corporate environment: a detailed analysis, detections and recommendations", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 77303, "plain_text": "Midnight Blizzard attack on Microsoft corporate environment: a\r\ndetailed analysis, detections and recommendations\r\nBy Lior Sonntag\r\nPublished: 2024-02-08 · Archived: 2026-04-05 21:16:37 UTC\r\nOn January 25th, Microsoft disclosed a security breach by a Russian cyber group identified as Midnight Blizzard\r\n(among other names), that targeted email accounts from November 2023 to January 2024. The actors initially\r\ngained access by compromising a legacy, non-production test tenant account that did not have MFA (Multi Factor\r\nAuthentication) enabled, and subsequently moved laterally to the main Microsoft corporate production tenant.\r\nThey secured elevated privileges within Microsoft's own Exchange Online tenant, resulting in unrestricted access\r\nto their corporate mailboxes. \r\nIn this blog, we’ll provide a detailed analysis of the whole attack chain. We’ll discuss what we think might have\r\nhappened while focusing mainly on the OAuth attack techniques used in this campaign, as there are still\r\nsignificant pieces missing from the report (which obscures a full understanding of all the details). In addition,\r\nwe’ll also provide some detections/threat-hunting queries related to potential risks posed by OAuth applications\r\nand provide some general recommendations and best-practices that any organization might implement to reduce\r\nthe risk of being compromised by malicious OAuth applications and brute-force/password-spray attacks. \r\nAttack analysis\r\nMicrosoft’s report states that after the adversary gained initial access to the legacy test tenant account by\r\ncompromising an Entra ID user through a password-spray technique, it compromised a legacy test OAuth\r\napplication that had elevated access to the Microsoft corporate environment.\r\nBased on this, we can confidently claim that the initial compromised Entra ID account had the privilege to create\r\nnew secrets/certificates for OAuth applications in the test tenant, subsequently allowing the adversary to\r\nauthenticate as the test app and execute actions on behalf of it. \r\nThe statement “legacy test OAuth application that had elevated access to the Microsoft corporate environment”\r\nindicates that the test application has been previously granted consent by a highly privileged Entra ID user in the\r\ncorporate tenant — allowing it high privileges in the corporate environment. To understand what privileges were\r\npreviously granted by a legitimate admin, we'll take note of the following statement: “They created a new user\r\naccount to grant consent in the Microsoft corporate environment.” In other words, either the MS Graph app\r\npermission of Directory.ReadWrite.All or User.ReadWrite.All was previously granted consent to the\r\ncorporate tenant, since these are the only MS Graph permissions that allow creation of new Entra ID users. For the\r\ndemonstration’s purpose, let’s assume that the Directory.ReadWrite.All permission was granted consent.  \r\nThe report later states that the adversary used the Office 365 Exchange Online app permission of\r\nfull_access_as_app to access corporate mailboxes. Since it requires admin consent, we can conclude that the\r\nnewly created user in the corporate environment was assigned admin privileges. Thus, we can infer that the MS\r\nhttps://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices\r\nPage 1 of 5\n\nGraph app permission of RoleManagement.ReadWrite.Directory was also previously granted access to the\r\ncorporate environment (prior to the incident). \r\n From the Microsoft corporate tenant, the service principal representing the legacy test OAuth application (in the\r\ntest tenant) would look like this, indicating that the MS Graph permissions of Directory.ReadWrite.All and\r\nRoleManagement.ReadWrite.Directory have been granted consent on behalf of the entire tenant: \r\nThe attacker then abused the previously granted MS Graph elevated permissions in the corporate environment,\r\nusing the credentials of the OAuth test application to create a new Entra ID user with admin privileges. This was\r\ndone in three steps.\r\nStep 1: First, the attacker requests an access token that provides access to the corporate tenant with the previously\r\ngranted privileges:\r\nStep 2: With this token, the attacker uses the Directory.ReadWrite.All permission to create a new user in the\r\ncorporate tenant: \r\nStep 3: Then the attacker utilizes the RoleManagement.ReadWrite.Directory permission to assign the user the\r\nGlobal Administrator role: \r\nFurthermore, the report states that the adversary also created additional OAuth applications, although it doesn’t\r\nindicate whether they were created by the initial compromised user or the test app (we’ll assume the test app\r\ncreated them). It also doesn't specify whether they were created in the test tenant or the prod tenant. Considering\r\nthat this nation-state APT group is known for its sophisticated operations and the ability to stay under the radar\r\nand evade detection, we'll assume that they would not choose to create apps in the prod tenant, since Microsoft\r\nalmost certainly rigidly monitors their production environments. \r\nThis means that the test app also had the elevated MS Graph app permission of Application.ReadWrite.All .\r\nThe report also states that the threat actor used the legacy test OAuth app to grant their new malicious apps the\r\nelevated Office 365 Exchange Online permission of full_access_as_app , meaning that the test app also had the\r\nhighly privileged MS Graph permission of AppRoleAssignment.ReadWrite.All . \r\nOverall, the legacy test OAuth application in the test tenant might have had the following MS Graph permissions: \r\nDirectory.ReadWrite.All : MS Graph permission that was previously granted in the Microsoft corporate\r\ntenant – allowing the adversaries to create a new user in the corporate tenant.\r\nRoleManagement.ReadWrite.Directory : MS Graph permission that was previously granted in the\r\nMicrosoft corporate tenant – allowing the adversaries to assign any directory roles to their new user.\r\nApplication.ReadWrite.All : MS Graph permission that allows the OAuth app to create new OAuth\r\napplications. This permission allowed the attacker to create the new malicious OAuth application.\r\nAppRoleAssignment.ReadWrite.All : MS Graph permission that allows the OAuth app to assign new\r\npermissions for existing applications. This permission allowed the attacker to assign the\r\nfull_access_as_app permission to their malicious application. \r\nhttps://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices\r\nPage 2 of 5\n\nThe procedure for creating a new, potentially malicious OAuth application and assigning it the Office 365\r\nExchange Online permission full_access_as_app via the legacy test OAuth app might proceed as follows: \r\nCreating a new multi-tenant OAuth application:\r\nAssigning the new application the Office 365 Exchange Online permission of full_access_as_app : \r\nAfterward, the new malicious-mail-access OAuth application is created in the test tenant and might look like\r\nthis: \r\nThe adversaries would then need to create their new malicious OAuth application credentials (probably using the\r\nsame user account that was initially compromised via the password-spray attack), and then initiate an illicit-consent attack where they would consent to the Office 365 Exchange Online permission of full_access_as_app\r\nusing their new admin user in the Microsoft corporate tenant, subsequently allowing unrestricted access to any\r\nmailbox associated with users in the corporate tenant. This procedure for this operation could be as follows: \r\nThe adversaries sign in to their malicious multi-tenant app using their new admin user in the Microsoft corporate\r\ntenant.\r\nThen, they utilize the user’s administrative privileges to grant consent to their malicious app, which aims to obtain\r\nfull access to all corporate mailboxes.\r\nFinally, upon obtaining consent, the attackers would only need to request an access token with the credentials of\r\ntheir malicious-mail-access OAuth application (a name we’ve chosen for the purpose of this demonstration) to\r\ngain access to any mailbox within the corporate tenant: \r\nDetecting similar activity in your environment \r\nFollowing are some detection/hunting queries related to anomalous activity associated with Entra ID OAuth\r\napplications, using Entra ID (AAD) Audit Logs in Azure Log analytics. \r\n1. Detect assignments of high privileged permissions to OAuth applications: \r\nThis query will detect the assignment of application permissions of the type noted in this blog. If you’re interested\r\nin covering additional MS Graph permissions, refer to the official Microsoft documentation.\r\n2. Detect assignments of high privileged directory roles to Entra ID users, specifically the Global Administrator,\r\nPrivileged Role Administrator, Application Administrator, and Cloud Application Administrator built-in roles that\r\ncan grant tenant-wide admin consent for OAuth applications: \r\n3. Detect secrets/certificates generated for multiple OAuth applications by a specific principal in a short period of\r\ntime: \r\nBe sure to define the time frame and the threshold according to your requirements. \r\n4. Detect whenever a new third-party application has been consented in your tenant: \r\nhttps://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices\r\nPage 3 of 5\n\nBe sure to monitor new service principals being added to your tenant as a result of consenting to a third-party\r\nOAuth application. If you find any new suspicious service principal, investigate their consented permissions and\r\ndetermine whether this is a legitimate application accessing your organization’s data. \r\nRecommendations and best practices \r\nEnforce MFA in your Entra ID tenant \r\nThis kind of attack could have been prevented if strict security controls were in place, such as having MFA on\r\neach Entra ID user in the tenant. \r\nBe sure to enforce MFA authentication registration policy in your tenant by following these steps.   \r\nEnable Smart Lockout \r\nAzure AD Smart Lockout defends against brute force or password-spray attacks by locking out attackers while\r\nensuring that legitimate users can access their accounts. It differentiates between likely legitimate sign-ins and\r\nattacker attempts, setting thresholds and durations for account lockouts to balance security and accessibility. To\r\nenforce it in your tenant, follow these steps. \r\nPrevent illicit application consent attacks \r\nBy default, all users can grant consent to applications that don’t require administrative review. To reduce the risk\r\nof malicious applications trying to trick users into granting them access to your organization’s data, we highly\r\nrecommend restricting users from consenting to unverified third-party applications. To configure user consent\r\nsettings, follow these steps and be sure to select the second option (Allow user consent for apps from verified\r\npublishers): \r\nHow can Wiz help detect and prevent this kind of attack chain? \r\nWiz offers a comprehensive solution to detect and prevent similar attacks.\r\nDetection \r\nWiz customers can use Wiz CDR (Cloud Detection and Response) to detect emerging cloud threats in real-time,\r\nsuch as the following scenarios: \r\n1. Detect a successful brute-force attack on a specific Entra ID user account. \r\n2. Detect multiple valid Entra ID user accounts failing to authenticate from the same IP address (usually\r\nassociated with password-spray attacks). \r\n3. Detect creation of new credentials to multiple OAuth applications by a specific Entra ID principal in a\r\nshort period of time. \r\n4. Detect potential illicit admin consent to a third-party application that requests high privileged permissions.\r\nhttps://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices\r\nPage 4 of 5\n\nPrevention \r\nWiz customers can use Wiz to assess the risk in their environment and detect relevant toxic and risky\r\ncombinations, similar to the ones exploited in the above-described attack: \r\n1. Discover whether you have highly privileged third-party service principals in your tenant that were\r\npreviously granted consent. \r\n2. Keep track of all the highly privileged Entra ID users that don’t have MFA enabled. \r\nStay informed\r\nThe Midnight Blizzard attack involved a sophisticated, multi-layered approach. It serves as a stark reminder of the\r\nimportance of robust security measures for organizations doing business in the cloud. Wiz customers can use the\r\nWiz CDR for relevant threat detection information and built-in Controls to identify related risks in their\r\nenvironments. For any questions or help with patching or mitigating vulnerabilities, please don't hesitate to contact\r\nus at threat.hunters@wiz.io.  \r\nWe would like to thank Matt Graeber and Justin Schoenfeld from Red Canary for reaching out and bringing to our\r\nattention that the final attack step requires the Office365 Outlook scope specification to retrieve the relevant app\r\nrole token.\r\nSource: https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices\r\nhttps://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices" ], "report_names": [ "midnight-blizzard-microsoft-breach-analysis-and-best-practices" ], "threat_actors": [ { "id": "a241a1ca-2bc9-450b-a07b-aae747ee2710", "created_at": "2024-06-19T02:03:08.150052Z", "updated_at": "2026-04-10T02:00:03.737173Z", "deleted_at": null, "main_name": "IRON RITUAL", "aliases": [ "APT29", "Blue Dev 5 ", "BlueBravo ", "Cloaked Ursa ", "CozyLarch ", "Dark Halo ", "Midnight Blizzard ", "NOBELIUM ", "StellarParticle ", "UNC2452 " ], "source_name": "Secureworks:IRON RITUAL", "tools": [ "Brute Ratel C4", "Cobalt Strike", "EnvyScout", "GoldFinder", "GoldMax", "NativeZone", "RAINDROP", "SUNBURST", "Sibot", "TEARDROP", "VaporRage" ], "source_id": "Secureworks", "reports": null }, { "id": "70872c3a-e788-4b55-a7d6-b2df52001ad0", "created_at": "2023-01-06T13:46:39.18401Z", "updated_at": "2026-04-10T02:00:03.239111Z", "deleted_at": null, "main_name": "UNC2452", "aliases": [ "DarkHalo", "StellarParticle", "NOBELIUM", "Solar Phoenix", "Midnight Blizzard" ], "source_name": "MISPGALAXY:UNC2452", "tools": [ "SNOWYAMBER", "HALFRIG", "QUARTERRIG" ], "source_id": "MISPGALAXY", "reports": null }, { "id": "20d3a08a-3b97-4b2f-90b8-92a89089a57a", "created_at": "2022-10-25T15:50:23.548494Z", "updated_at": "2026-04-10T02:00:05.292748Z", "deleted_at": null, "main_name": "APT29", "aliases": [ "APT29", "IRON RITUAL", "IRON HEMLOCK", "NobleBaron", "Dark Halo", "NOBELIUM", "UNC2452", "YTTRIUM", "The Dukes", "Cozy Bear", "CozyDuke", "SolarStorm", "Blue Kitsune", "UNC3524", "Midnight Blizzard" ], "source_name": "MITRE:APT29", "tools": [ "PinchDuke", "ROADTools", "WellMail", "CozyCar", "Mimikatz", "Tasklist", "OnionDuke", "FatDuke", "POSHSPY", "EnvyScout", "SoreFang", "GeminiDuke", "reGeorg", "GoldMax", "FoggyWeb", "SDelete", "PolyglotDuke", "AADInternals", "MiniDuke", "SeaDuke", "Sibot", "RegDuke", "CloudDuke", "GoldFinder", "AdFind", "PsExec", "NativeZone", "Systeminfo", "ipconfig", "Impacket", "Cobalt Strike", "PowerDuke", "QUIETEXIT", "HAMMERTOSS", "BoomBox", "CosmicDuke", "WellMess", "VaporRage", "LiteDuke" ], "source_id": "MITRE", "reports": null }, { "id": "f27790ff-4ee0-40a5-9c84-2b523a9d3270", "created_at": "2022-10-25T16:07:23.341684Z", "updated_at": "2026-04-10T02:00:04.549917Z", "deleted_at": null, "main_name": "APT 29", "aliases": [ "APT 29", "ATK 7", "Blue Dev 5", "BlueBravo", "Cloaked Ursa", "CloudLook", "Cozy Bear", "Dark Halo", "Earth Koshchei", "G0016", "Grizzly Steppe", "Group 100", "ITG11", "Iron Hemlock", "Iron Ritual", "Midnight Blizzard", "Minidionis", "Nobelium", "NobleBaron", "Operation Ghost", "Operation Office monkeys", "Operation StellarParticle", "SilverFish", "Solar Phoenix", "SolarStorm", "StellarParticle", "TEMP.Monkeys", "The Dukes", "UNC2452", "UNC3524", "Yttrium" ], "source_name": "ETDA:APT 29", "tools": [ "7-Zip", "ATI-Agent", "AdFind", "Agentemis", "AtNow", "BEATDROP", "BotgenStudios", "CEELOADER", "Cloud Duke", "CloudDuke", "CloudLook", "Cobalt Strike", "CobaltStrike", "CosmicDuke", "Cozer", "CozyBear", "CozyCar", "CozyDuke", "Danfuan", "EnvyScout", "EuroAPT", "FatDuke", "FoggyWeb", "GeminiDuke", "Geppei", "GoldFinder", "GoldMax", "GraphDrop", "GraphicalNeutrino", "GraphicalProton", "HAMMERTOSS", "HammerDuke", "LOLBAS", "LOLBins", "LiteDuke", "Living off the Land", "MagicWeb", "Mimikatz", "MiniDionis", "MiniDuke", "NemesisGemina", "NetDuke", "OnionDuke", "POSHSPY", "PinchDuke", "PolyglotDuke", "PowerDuke", "QUIETEXIT", "ROOTSAW", "RegDuke", "Rubeus", "SNOWYAMBER", "SPICYBEAT", "SUNSHUTTLE", "SeaDaddy", "SeaDask", "SeaDesk", "SeaDuke", "Sharp-SMBExec", "SharpView", "Sibot", "Solorigate", "SoreFang", "TinyBaron", "WINELOADER", "WellMail", "WellMess", "cobeacon", "elf.wellmess", "reGeorg", "tDiscoverer" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434028, "ts_updated_at": 1775792253, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/1124300149ea5da862c0785fb52080456bbee3fd.pdf", "text": "https://archive.orkl.eu/1124300149ea5da862c0785fb52080456bbee3fd.txt", "img": "https://archive.orkl.eu/1124300149ea5da862c0785fb52080456bbee3fd.jpg" } }