Midnight Blizzard-Linked Server Was Still Serving Malware Weeks After Exposure, ReversingLabs Finds
ReversingLabs found a staging server in a campaign Microsoft ties to a Midnight Blizzard sub-cluster still serving a PowerShell stager on Oct 5, more than two months after disclosure. The campaign hijacks hotel Wi-Fi captive portals. Here is how to check your devices.
Publishing a threat report does not switch off the attacker's servers. ReversingLabs has shown that plainly with a staging server tied to a Midnight Blizzard-linked campaign: on October 5, 2026, more than two months after Microsoft first described the operation, the server was still handing out malware to anyone who requested the right paths.
The finding comes from a new ReversingLabs (RL) analysis by Igor Lasic, the company's SVP of Engineering. RL started from just two file hashes that Anthropic published in its September 2026 threat intelligence report and worked outward through its own historical telemetry. Those two files led to the staging server at 213.145.86[.]112, five more builds of the same PowerShell stager, two lure files built to launch it, and links between the campaign's phishing domains and its servers.
The attribution comes with careful wording. Microsoft tracks the operation as CaptiveCrunch and attributes it to Storm-2945, which it assesses is "an operational sub-cluster of Midnight Blizzard," the Russia-based group the US and UK governments attribute to Russia's Foreign Intelligence Service (SVR). Anthropic describes its GTG-20006 operator as Russian-speaking, with attribution "consistent with public reporting linking the actor to Midnight Blizzard." RL says its own file analysis neither confirms nor contradicts either vendor's attribution, so it calls the cluster "Midnight Blizzard-linked," and adds that no file it found should be called "Midnight Blizzard malware" on its authority.
Microsoft's July 31 report explains how victims get hit. Since early May 2026, Storm-2945 has manipulated DNS and HTTP traffic on hospitality networks served by captive portals, the sign-in pages travelers see on hotel Wi-Fi. Microsoft says the group redirects users to phishing sites that imitate Microsoft 365, abuses the device code sign-in flow in Microsoft Entra ID, and serves malware dressed up as browser or operating system updates, often through ClickFix pages that talk the user into running it themselves. Microsoft cites ReliaQuest as finding the activity at conference centers and other shared venues as well as hotels, aimed at the accounts of corporate travelers. In an October 5 update, Microsoft said the campaign resumed on September 29, now including a Rust variant of its backdoor.
The two seed files are a PowerShell stager Microsoft calls ChocoShell and a Go backdoor it calls CornFlake. According to Microsoft, ChocoShell steals browser cookies, saved passwords, Microsoft 365 single sign-on tokens and Wi-Fi credentials, beacons to /t/pixel.gif?m= on the staging server, and sends stolen data to /t/event. CornFlake is a full remote access trojan that installs itself as svchost32.exe, registers a Windows service named "svchost32" with the display name "Cloud Sync Service," and adds Run keys and scheduled tasks for backup persistence. RL independently saw the backdoor read Edge, Chrome and Firefox profile data and the Microsoft Teams cache.
RL had both files in its telemetry weeks before anyone published, first seeing the backdoor on July 6 and the stager on July 10. Its platform classified them as malicious on August 1, the day after Microsoft's report, and RL is upfront that this verdict was not independent of Microsoft. A YARA hunt on the stager's beacon labels, stage2_entry and stage2_ctx_, turned up five rebuilt stagers with different hashes but an identical 35-item capability profile, arriving between July 9 and August 3. RL says that pattern is consistent with Anthropic's account of the operator using Claude to rebuild implants after they were detected, though its data cannot show what produced them.
Two of RL's finds show why antivirus scores alone missed this. The lure files are 60-byte Windows Internet Shortcut (.url) files that contain nothing but a link to a stager path on the server, so none of 37 antivirus engines flagged them. The servers fared little better: when RL checked in late September, 13 of the 14 servers Anthropic listed were flagged by 0 to 5 of roughly 49 reputation sources, and the staging server itself by 6 of 50. On October 5, the stager download path /s, a shortcut's /s?r=7ed4bb1d link and a fake JavaScript bundle path all answered HTTP 200 and each delivered a file RL classifies as malicious. RL notes this is a dated snapshot, not proof the server is still up today. Several phishing domains also still answered, while the Outlook Web Access lookalike owa-ms365[.]com returned 403. Coverage from GBHackers matches RL's account.
Are you affected? These checks come from the indicators in the ReversingLabs and Microsoft reports. The malware targets Windows, so run the PowerShell checks on laptops, especially those of staff who travel. A hit means investigate, not proof of compromise.
- Look for the CornFlake service. Microsoft gives the name svchost32 and the display name "Cloud Sync Service":
Get-Service -Name svchost32 -ErrorAction SilentlyContinue |
Format-List Name, DisplayName, Status
Get-CimInstance Win32_Service |
Where-Object DisplayName -eq 'Cloud Sync Service'- Look for the backdoor binary. Microsoft gives the path as
%APPDATA%\svchost32\svchost32.exe, and RL observed%LOCALAPPDATA%\Microsoft\svchost32\svchost32.exe, so check both:
Test-Path "$env:APPDATA\svchost32\svchost32.exe"
Test-Path "$env:LOCALAPPDATA\Microsoft\svchost32\svchost32.exe"- Check Run keys and scheduled tasks for anything launching svchost32.exe:
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' |
Format-List
Get-ScheduledTask |
Where-Object {{ $_.Actions.Execute -match 'svchost32' }}- Compare file hashes against the two published samples:
Get-FileHash -Algorithm SHA256 <suspect-file>
# ChocoShell stager:
# be99857449d2856dd5a84e21c8a3d5e0e01456adb44062ddec5a6b4970d8d42c
# CornFlake backdoor:
# 918fa52ae45ed60ba7cc8bdc99c3cbe9ab92e0375ec31fc05d0d4513be11c593- Look for small
.urlshortcuts pointing at the staging server in Downloads and on the desktop:
Get-ChildItem "$env:USERPROFILE\Downloads", "$env:USERPROFILE\Desktop" `
-Filter *.url -ErrorAction SilentlyContinue |
Select-String -Pattern '213\.145\.86\.112'- Search proxy, firewall and DNS logs for the network indicators in the table, plus requests to
/t/pixel.gif?m=,/t/eventand/cdn/chunks/on the staging server. - Review Microsoft Entra ID sign-ins for device code authentication, and block the device code flow with Conditional Access where your business allows it. Both RL and Microsoft recommend this.
- Treat any captive portal or Wi-Fi sign-in page that offers a browser update, system update, certificate or tool, or asks you to paste and run a command, as hostile. Microsoft advises against downloading anything presented through captive portals and recommends checking for updates through the operating system itself.
| Indicator (defanged) | Role, per source |
|---|---|
| 213.145.86[.]112 | Staging server, ChocoShell C2 (RL, Microsoft) |
| 107.189.26[.]194 | ChocoShell C2, DNS resolver (Microsoft) |
| 31.57.243[.]154 | Phishing host for owa-ms365 (RL, Microsoft) |
| 104.145.210[.]184 | Device code phishing server (RL) |
| 38.146.28[.]75, 104.194.159[.]150 | AitM infrastructure (Microsoft) |
| 38.146.28[.]132 | DNS resolver (Microsoft) |
| 154.29.75[.]245, 149.3.170[.]186 | Infrastructure seen Sep 29 to Oct 1 (Microsoft) |
| ms365-live[.]com, ms365-device[.]com | Device code phishing redirects (Microsoft) |
| owa-ms365[.]com, m365-owa[.]com | AitM phishing (Microsoft) |
| cdn-gstat[.]com, sslcdnhost[.]com | Redirects seen Sep 30 (Microsoft) |
| network-privacy[.]com | Redirect seen Oct 1 (Microsoft) |
| wa-meeting[.]com, chamber-ua[.]org | Lookalike domains (RL) |
RL also lists 192.142.52[.]31 as a hunting lead, not a confirmed indicator. It assesses with moderate confidence that the backdoor uses this address and advises validating it before blocking. RL's broader lesson for defenders is to query every new vendor report's indicators against historical logs the day it lands, and not to assume that disclosure took the infrastructure offline.