A wider campaign hiding in plain sight
A Russian state-backed group has been tied to a recent run of WiFi gateway compromises that looked, at first glance, like a hotel problem. That early framing was too neat. The activity appears to have started around May, and the scope was broader than the first public write-up suggested.
Hotels and conference centers were in the mix, sure. But they were not the whole story. Other organizations were hit too, which changes the picture quite a bit. Once you stop thinking about this as a one-off hotel WiFi mess, it starts to look more like a campaign built around shared network choke points, the kind that many people use without thinking twice. One compromised gateway can touch a lot of traffic very quickly. That is handy for the attacker, less so for everyone else.
The basic trick here is simple enough to describe and unpleasantly effective in practice: if an attacker can influence traffic at the network edge, they can steer victims before the victim even realizes anything is off. That can mean pushing people toward credential theft, or toward a malware download, or toward both in the same session if the operator feels ambitious. Public WiFi is an obvious target because it gives the attacker a pool of transient users and a lot of trust to abuse. But the larger lesson reaches beyond lobby networks and business travel. Any shared access point, guest network, or gateway that sits between users and the internet can become a convenient sorting machine for victims.
A compromised gateway lets attackers work at scale without needing to break into each person one by one.
That is the part worth keeping in mind. These attacks do not depend on someone being careless in the usual, everyday sense. A user can connect normally, open a browser, and still get routed into a hostile page or a malicious download path if the network itself has been bent out of shape. That makes the campaign different from the usual spammy phishing operation that lives and dies on a single email subject line. Here, the network does some of the heavy lifting.
It also means the blast radius can stretch well beyond a single industry. The phrase hotel WiFi attacks makes the incident sound narrow, almost quaint, but the underlying technique is more general. If a group can control what people see on a shared network, it can tailor the next step to the target in front of it. One user gets pushed toward a login page. Another gets nudged toward a file download. Another may never notice anything except a weird detour in the browser. That flexibility is what makes gateway compromise such a comfortable fit for both credential harvesting and malware delivery.
So the right way to think about this wave is not “bad WiFi at hotels.” It is a broader abuse of network infrastructure, with hotels and conference centers just being the most visible places where it showed up. The shape of the campaign matters because it turns ordinary connectivity into a distribution channel. That is a tidy little nightmare for defenders, and a fairly awkward surprise for anyone who assumed the lobby network was just a place to check email and complain about the coffee.
How the traffic hijack worked
Once the attackers had a foothold in the gateway, the rest of the operation was less about brute force and more about quietly steering people where they were already headed. DNS traffic was altered on the compromised networks so that normal requests for Microsoft-related login services could be diverted to attacker-controlled destinations. In practice, that meant a victim trying to sign in, renew a session, or clear a prompt could be pushed to a fake Microsoft-branded page without anything obvious breaking on their end. The browser still opened. The page still looked plausible enough at a glance. That little bit of friction-free deception did most of the work.
The phishing branch was the cleaner of the two paths. Users were sent to pages that mimicked Microsoft sign-in screens and were prodded to enter credentials or other authentication material. The malware branch was messier in a way that sometimes makes it more effective. Instead of a simple form, victims were sent toward download pages, where the attacker wanted them to pull down a file or follow a sequence of manual steps. That is where the operation starts to feel less like old-school phishing and more like a trap built from browser prompts, fake urgency, and just enough social engineering to get someone to click one more time.
A lot of those pages borrowed the style that security teams now lump together as ClickFix malware. The script is familiar by now: copy this text, paste it into a run dialog, save this file, or execute this command to “fix” the issue. The page frames the victim as the person solving a problem, which is a neat trick because people are often more willing to trust instructions when they think they are repairing a login hiccup. There is no dramatic exploit chain on the screen, just a tidy set of steps that asks the user to do the dangerous part themselves. That keeps the attackers’ hands clean and, annoyingly, makes the whole thing look almost mundane.
The sharpest part of the attack was not the fake page itself. It was the way the network redirect nudged victims into treating the malicious page as routine troubleshooting.
Two payloads showed up in this branch: CornFlake RAT and CocoShell. CornFlake RAT is the more obviously malicious of the pair, since remote access tooling is hard to dress up as anything else once it lands. CocoShell was a PowerShell-based infostealer, which makes the whole thing feel a bit more low-rent on paper and a lot more effective in practice. PowerShell has a habit of being wherever attackers need it to be, and this case was no exception. Once launched, both payloads were seen reaching out to a command-and-control panel called FruitStone, a name that had not been seen in this context before. That shared backend matters. It suggests the phishing flow and the malware flow were not separate experiments bolted onto the same campaign, but coordinated parts of one operation.
The traffic manipulation itself was the glue. DNS hijacking let the attackers decide where a victim’s browser went, which meant they did not need to win every step with malware from the start. They could start with redirection, then branch the victim into either credential theft or payload delivery depending on what was most useful at the moment. For the attacker, that kind of flexibility is gold. For everyone else, it is the sort of thing that turns a normal captive portal or login prompt into a problem you only notice after the browser has already been led off leash.
The same general pattern has shown up in earlier hospitality-sector abuse too, including past work on hotel WiFi abuse and traveler-targeting campaigns documented in older hospitality threat writeups and historical hotel attack reports. Even the practical travel advice from CISA’s guidance for staying safe on the road still maps neatly onto this kind of attack: assume the network can be weird, verify the page before you trust it, and don’t treat every login prompt as if it were handed down from a benevolent cloud deity.
Seen together, the DNS changes, the fake Microsoft pages, the ClickFix-style instructions, and the two payloads tell a pretty clear story. This was not just about getting someone to type a password into a fake form. It was about using the network itself to shape what the victim saw, then using that moment of confusion to push either a login theft flow or a malware install flow. Storm-2945’s operators appear to have spent most of their effort on making the handoff feel ordinary, which is often the part people remember too late.
Credential theft, MFA bypass, and the Russian cluster behind it
Once the redirect landed, the real prize wasn’t just a page view. The phishing branch was built to pull device codes and OAuth codes tied to Microsoft Entra accounts, which is a much neater trick than smashing at a password prompt until something gives. If the victim enters the right code at the wrong time, the attacker can sometimes turn that short-lived approval into access that looks annoyingly legitimate. MFA still helps, of course, but this is the sort of setup that tries to slip around the usual guardrails by borrowing the victim’s own sign-in flow.
MFA blocks a lot of clumsy attacks. It gets much less comfortable when the attacker asks the user to unlock the door for them.
The end goal here was plain enough: get into the Microsoft account, then get into the mailbox. That matters because email is rarely just email. It often carries reset links, internal chatter, cloud service notices, and enough context to make later impersonation easier. In a Microsoft environment, a stolen Entra sign-in can open the door to more than one service, which is why these code-theft campaigns keep showing up. They don’t need to win every time. They only need one distracted user who thinks they’re signing in to WiFi, a portal, or some half-plausible corporate prompt.
Microsoft attributed the activity to Storm-2945, which it described as a smaller subgroup inside the Midnight Blizzard cluster. That naming can look like alphabet soup at first glance, but there’s a useful thread underneath it. Midnight Blizzard is Microsoft’s label for a set of Russian threat actors that it has long connected to APT29, also known as Cozy Bear. That cluster is widely linked to Russia’s SVR foreign intelligence service. In other words, this isn’t being treated as random cybercrime with a borrowed accent. It sits in a well-known intelligence ecosystem that has been active for years and has a habit of choosing patient, credential-focused operations over noisy break-ins.
The Storm-2945 label also matters because it narrows the campaign’s identity. Microsoft wasn’t just saying, “some Russian actor did this.” It was separating this operation from other Russian groups that use different infrastructure, different tradecraft, and different objectives. That distinction becomes clearer when you compare it with FrostArmada. FrostArmada relied on compromised MikroTik and TP-Link routers, and Microsoft tied that activity to APT28, a group also known as Fancy Bear or Forest Blizzard. That actor is generally tracked separately from Midnight Blizzard. The overlap is national origin, not operational signature. Different crews, different playbooks, different messes to clean up.
That split is easy to miss if you only skim the headlines. Both campaigns involve compromised network gear and traffic redirection, so they can blur together in a hurry. Still, the attribution points land in different buckets. Midnight Blizzard, APT29, Cozy Bear, and the SVR connection point toward one family of Russian activity. APT28, Fancy Bear, and Forest Blizzard point toward another. Mixing them up would be a bit like confusing a locksmith with a pickpocket because both wear gloves. Same city, different line of work.
Microsoft also said the group appeared to use AI in parts of the operation, though it did not provide technical detail. That leaves room for a lot of interpretation. The most cautious reading is that AI may have helped with some support task, maybe content generation, language polishing, or operational prep. It doesn’t automatically mean the campaign was run by robots in trench coats. Threat actors love experimenting with tools that save time, and AI now sits in that pile alongside old favorites like templates, scripts, and whatever spreadsheet someone keeps on a desktop called “final_final_v7.”
What stands out here is the blend of old-school social engineering and modern account abuse. The attackers were not just trying to lure people into typing a password into a fake box. They were aiming at the sign-in artifacts that actually matter in Microsoft’s identity stack. That makes the campaign less about one phony page and more about access theft at the protocol level, which is a far less comforting phrase to read before your second coffee.
What defenders should watch for next
The cleanest way to think about this activity is simple: if a gateway can steer traffic, it can also steer people. That means defenders responsible for guest WiFi, branch offices, managed apartments, conference venues, or any shared network should watch the network layer and the identity layer at the same time. Focusing on only one side leaves a blind spot big enough for an attacker to drive a fake Microsoft login page through.
Start with DNS. A WiFi gateway compromise often shows up as DNS changes that don’t fit the normal pattern for that site. Maybe the resolver was swapped without approval. Maybe new records appeared for common Microsoft domains. Maybe lookups began landing on unusual infrastructure after a clean sign-in. Those are the kinds of changes that look boring in a log until they’re not. Captive portals deserve the same treatment. If a login page suddenly looks like Microsoft, asks for credentials after a WiFi join, or appears right after a redirect chain that wasn’t there yesterday, treat it as suspicious until proven otherwise. A hotel lobby page asking for a Microsoft sign-in can be legitimate in a narrow set of cases, but most of the time it deserves a very skeptical stare.
When a public network starts behaving like an identity broker, something has already gone wrong.
Unexpected downloads should also sit near the top of the watch list. Redirects from WiFi infrastructure that send users to executable files, script prompts, or odd “verification” pages are not normal guest-network behavior. The same goes for pages that ask users to copy text, save a file, or run a command to “complete access.” That pattern often shows up when an attacker is trying to move from simple phishing into malware delivery or social engineering around a payload. In cyber threat intelligence terms, those redirect chains are worth preserving in full. Don’t just log the destination. Keep the source, the timing, the user agent, and the DNS path that got the victim there. Otherwise the trail gets muddy fast.
On the identity side, defenders should watch for Entra device codes, OAuth grants, and mailbox access that appear after a suspicious sign-in event. Device-code abuse can be easy to miss if the sign-in itself looks ordinary. A user may have authenticated cleanly, then granted access in a second step that never felt suspicious to them. OAuth code theft can be even messier, because the consent flow may look like a standard app approval unless someone checks what was approved, when, and from which network. If a mailbox suddenly shows new forwarding rules, unusual IMAP or webmail access, or odd consent grants from a fresh IP range, that deserves immediate review. MFA didn’t fail because it was weak. It failed because the attacker worked around it.
Response planning should assume the blast radius is larger than one room or one building. A gateway-level compromise can affect every visitor who hits that network segment, not just one unlucky laptop on one unlucky floor. That’s why hotel and conference networks aren’t the only problem. Shared WiFi in co-working sites, retail branches, clinics, transit hubs, and temporary event spaces can all become convenient staging points for the same sort of abuse. If a single captive portal or resolver serves hundreds of users, one bad change can create hundreds of opportunities.
The practical takeaway is dull in the best possible way: treat public WiFi infrastructure like a high-value target. Watch the DNS, inspect the portal, review the redirects, and correlate those events with identity logs before the attacker gets a second chance. A guest network may feel like an amenity. To an intruder, it can be a shortcut into a lot of accounts.
