Most of the Teams calls lasted two to two and a half minutes.
That is what Sophos observed across a voice phishing campaign it tracks as STAC4749, which targeted dozens of North American organizations between February and June 2026. Ninety seconds on the short end, twenty-plus on the long end. In one intrusion, fewer than seventeen hours passed between initial access and ransomware deployment.
The chain is simple enough to explain at a shift briefing. An external Teams account with a plausible name, on a domain that looks like IT infrastructure, calls someone and presents as helpdesk. The goal is a remote session. Sophos says the operators started with Microsoft Quick Assist and fell back to a cloud tool called RemSupp when Quick Assist was blocked or unavailable, then shifted toward preferring RemSupp in April, likely because it was less often blocklisted. Once the session is live, PowerShell retrieves malicious payloads, a loader or backdoor depending on the month, and the operator works laterally.
At least three of these compromises led to Chaos ransomware deployment.
Two things up front. Sophos's public report does not name a public safety answering point or any municipality as a STAC4749 victim, and as of July 31, 2026, I have not found a public report that does. And this is one practitioner reading published research, not guidance. Every center's environment is different enough that what follows is meant to be read as questions worth asking, not steps worth taking.
Why it caught my attention
The Public Safety Threat Alliance and MS-ISAC published their analysis of 2024 incidents in June 2025. One figure in it is the reason I read the Sophos report twice: 83 percent of the CAD attacks they observed either began on municipal or police networks, or were indirectly affected by attacks on those networks.
Most CAD attacks in that data did not begin inside the CAD environment. They began on, or arrived through, the connected enterprise network next to it. PSTA identified credential abuse, vulnerability exploitation, and exploitation of remote services as the most likely initial access techniques affecting mission-critical systems.
The case from that report I keep returning to started with a phishing email against a city mayor's personal Gmail account in August 2024. It pivoted into the city's enterprise IT and ended with ransomware across the municipal environment and the county CAD system. Officers and dispatchers ran the response on paper and walkie-talkies.
That is a long way from a dispatch console, and it still arrived there. So a campaign engineered to reach ordinary enterprise workstations at ordinary organizations is worth a read in this sector, even with no public safety victim named.
Reading the government exception carefully
Cisco Talos documented Chaos's advertisement on a Russian-language criminal forum, in which the group said it would not collaborate with affiliates targeting hospitals or government entities.
That is genuinely in the reporting, and it would be easy to stop reading there. A couple of things gave me pause.
Nothing in the published research explains when that restriction is applied, how consistently, or by whom across an operation that may involve separate operators and affiliates. There is no mechanism a defender can verify from the outside.
The category is also less tidy at the edges of this sector than it looks. Joint powers authorities, regional dispatch authorities, nonprofit 911 boards, contracted PSAP operators, and the vendor hosting your CAD data may not all be recognized as government during triage.
Talos also assesses with moderate confidence that Chaos is either a rebrand of BlackSuit, formerly Royal, or is operated by some of its former members. In June 2024, BlackSuit published a major city police department's stolen data after a ransom went unpaid: crime scene photos, evidence, records, officer information. That does not prove the current operation has broken its own rule, and I am not going to claim it does. It is context worth having.
What it looks like from a dispatch floor
Microsoft's guidance is straightforward: only allow a remote connection from someone claiming to be IT support if you initiated the interaction. That is sound advice and it is the right default.
It also sits differently in a 911 center than in most workplaces, and everything below this line is my own observation rather than a finding in the research.
At many centers, legitimate vendor contact still arrives as a surprise to the dispatcher or supervisor who receives it. The CAD vendor pushing a patch, the logging recorder vendor pulling a diagnostic, the NG911 provider troubleshooting an ESInet issue. Plenty of centers have thought carefully about this and approve every session in advance through IT. Even then, the person at the console is not always the person who approved it, which means the floor can encounter a contact that is entirely legitimate and still unexpected from where they are sitting.
The centers I have seen handle that well lean on something dispatch already does constantly, which is calling back on a number they hold rather than one they were given. That is not a new control so much as an existing habit pointed at a different kind of contact.
The other half of it is not technical at all. Where anyone on the floor can raise a concern at any hour without having to justify it first, that tends to surface odd things early. Dispatchers develop a good instinct for when something is off, and a center where calling the on-call tech at 0330 over a bad feeling is normal gets more use out of that instinct than one where it isn't.
Where the obvious answers get complicated
This is the part I find more useful than any list of fixes, because the straightforward answers all have edges.
An approved-vendor list answers a different question than it looks like it answers. It establishes that a vendor is legitimate. It does not by itself establish that the person on the call is that vendor. The technique described in these reports does not need to defeat a list, only to sound like something already on it. A callback to a number the center holds narrows that gap considerably, though it cannot address a compromise inside the vendor's own environment.
Blocking a tool tends to move the activity rather than end it. Sophos observed these operators shift toward RemSupp and assessed they likely did so because it was less likely to be blocklisted. Application control clearly still matters, and Sophos recommends it. It just is not the whole answer on its own.
Failover and recovery are solving different problems. A redundant CAD node is designed to protect against hardware or site failure. Ransomware is a different failure mode. If the same access reaches both nodes, or the same credentials work on both, the redundancy may not produce a clean place to fall back to. Depending on architecture, replication can also carry unwanted changes along with legitimate ones.
For context on why that matters here: Chaos advertises encryptors for Windows, ESXi, Linux, and NAS. The Windows version Talos analyzed supports local and network encryption modes, enumerates private subnets, connects to discovered systems over SMB, and deletes volume shadow copies. Talos also observed domain trust enumeration and activity it assessed as a likely attempt to steal privileged credentials.
PSTA documented 18 cyberattacks affecting CAD systems in 2024, with average downtime of 15 days. In cases where defenders proactively disabled systems, downtime was limited to seven days. The report does not establish that the shutdown alone caused the difference, and I would not read it that way. It does suggest that knowing in advance who can make that call, and what the floor does next, is worth working out on a calm day.
Questions worth asking
I want to be careful here, because the settings involved have real operational purposes and a change made without understanding the environment can disrupt something a center depends on. In a lot of departments the person reading this is also the person who would have to make the change, and may not have a dedicated IT group behind them. So these are conversations to have with whoever supports your systems, not steps to take this afternoon.
Does anyone know how your Microsoft 365 tenant is currently configured for external contact? Microsoft documents the default for federation with other managed organizations as "allow all external domains," and it is worth knowing where yours sits and why.
Is Quick Assist in use at your center, and if not, does your IT support have a view on whether it should remain available? It ships preinstalled on current Windows 11 builds.
If a support request arrived at the console unexpectedly, what would the person receiving it do next, and would they feel comfortable pausing to check?
If CAD had to come down, does anyone know how long the floor could run manually, and has that ever been tried on a scheduled day rather than a bad one?
None of those require a budget cycle. Most of them are a conversation.
