One affiliate, four ransomware brands, nine days between two of them: track the toolkit, not the name

Nine days between brands

On 11 February 2026 a ransomware affiliate that Microsoft tracks as Storm-2570 made its last observed Qilin deployment. On 20 February it made its first observed DragonForce deployment. That is a gap of nine days, and it is our arithmetic from the deployment timeline Microsoft Threat Intelligence published on 24 September in Beyond the ransomware: Tracking Storm-2570's consistent tradecraft across deployments.

The same timeline shows two overlaps, one early and one late. BERT and Qilin ran side by side from 8 May to 19 June 2025, 42 days. From 20 February to 29 April 2026 DragonForce ran continuously while Anubis appeared in three short windows inside it. Across the 393 days the chart covers, from 2 April 2025 to 30 April 2026, one affiliate put four different ransomware brands on victims' machines, and the post describes the tools that came before each payload as "largely uniform".

Here is what those nine days do not establish. They do not say the affiliate stopped working with Qilin for any particular reason, that anything happened between the two dates, or that Microsoft saw every deployment. The timeline is what Microsoft observed in its own investigations. It ends on 30 April 2026, 147 days before the post was published, and the post does not say what the affiliate has done since. It gives no count of intrusions and no count of victims.

What the timeline does show is enough for a defender. If you had been tracking this threat by the name on the ransom note, you would have watched BERT disappear, then Qilin disappear, and you would have been looking at two new names within ten weeks of the second. If you had been tracking the tools that arrived before the note, you would have been looking at the same list throughout.

What Microsoft put on the record

Microsoft describes Storm-2570 as a ransomware affiliate it has tracked since April 2025, operating across four ransomware as a service ecosystems: Qilin, DragonForce, Anubis and BERT. In the ransomware as a service model the brand owner supplies the encryptor and the leak site, and affiliates do the breaking in. Storm-2570 is one of the people doing the breaking in, and it has worked for at least four brand owners.

Victims were in six places: the United States, Canada, the United Kingdom, Spain, the Netherlands and Puerto Rico. The post lists 14 sectors, from healthcare and public health and education to government, financial services, energy, critical manufacturing and transportation. It does not say which sectors were hit in which country.

Microsoft's Storm-2570 post: what it states and what it leaves out. Source: Microsoft Threat Intelligence, 24 September 2026

Question	Stated	Not stated
When tracking began	April 2025; timeline starts 2 April 2025	Anything before that date
Ransomware brands	Four: Qilin, DragonForce, Anubis, BERT	Revenue share or why it switched
Countries	Six, including the United Kingdom	Victims per country
Sectors	14 named sectors	Which sectors in the UK
How it gets in	"Remains unconfirmed" in the text	Any initial access vector
Remote access tools	Six RMM tools, plus ngrok and Cloudflared tunnels	Whether they were the first foothold
Exfiltration	s5cmd to S3 buckets, and Rclone	Volumes, destinations, providers
Latest activity	Timeline ends 30 April 2026	Anything from May to September 2026
Other vendors' names	None given	Whether others track the same cluster

One inconsistency is worth a defender's attention. The body text says the method of initial access "remains unconfirmed". The attack chain diagram in the same post, Microsoft's Figure 2, labels its first stage "Initial foothold gained through RMM tools". Those are different claims. The text is the more careful one, and this briefing follows it: the RMM tools are the affiliate's way of staying in and working, and the post does not establish that they are how it gets in.

The brand is a friendly name

A ransomware brand is the label the victim sees. It is on the ransom note, on the leak site, in the insurer's claim form, in the incident report, in the regulator's notification and in the press coverage. That makes it the label every statistic is filed under. It is also the one thing in this intrusion chain that the affiliate changes freely.

Microsoft's own framing makes the point: tracking and responding to ransomware by payload alone "can obscure the affiliates carrying out intrusions". An organisation that briefs its board on "Qilin" and hardens against "Qilin" is preparing for the last five minutes of an attack that, in Storm-2570's case, started with an agent install, a credential dump and a data copy that all look the same whichever brand is paid at the end.

The comfort of a brand name is that it sounds like a control. It suggests a known adversary, a signature set, a playbook. For this affiliate it is none of those. If your threat intelligence feed tells you Qilin activity is down, the affiliate that used to deploy Qilin may simply be deploying DragonForce, and your detection logic for what happens before encryption should not care either way.

None of this means the payload does not matter. The encryptor determines what recovery looks like and whether a decryptor exists. But for detection and prevention, which is where a defender can still change the outcome, the payload is the least useful thing to track, because it arrives last and changes most.

The persistence layer is software you may already run

Microsoft lists six remote monitoring and management tools across Storm-2570's intrusions: Atera, MeshAgent, ScreenConnect, Splashtop, Remotely_Agent and NinjaRMM. The post calls them "commercially available RMM platforms". These are products IT teams and managed service providers install on purpose, sign contracts for and whitelist in their endpoint tools. That is why they are useful to an intruder.

The post describes how they were used together. Atera was used to install agents and run commands, and to download and install Splashtop, which Microsoft reads as the interactive remote control delivered through Atera. ScreenConnect ran commands and account and domain reconnaissance. Remotely_Agent was installed as a persistent service. MeshAgent is singled out as one of the most frequently observed tools, used with MeshCentral as "an operational bridge" between early hands-on activity and later account changes, credential access, security tampering and ransomware deployment.

Two details matter for detection. First, the affiliate renamed MeshAgent binaries or services with the victim organisation's own name, in the pattern meshagent64-[organization name].exe, likely to look legitimate. Second, it paired the RMM tools with tunnels. In one intrusion it created a persistent Cloudflare Tunnel service running under LocalSystem, giving an encrypted outbound channel that does not need an inbound firewall opening. It also used ngrok to expose RDP on TCP 3389.

What an allow-list of approved RMM tools does about this. It does a lot, and less than people assume.

It helps because Storm-2570 rotated through several products and often ran more than one in the same intrusion. If your organisation has decided that exactly one remote management product is approved, then an Atera agent, a Splashtop Streamer and a Remotely service appearing on the same server is a signal on its own, whatever the ransomware later turns out to be. Microsoft's own mitigation advice points the same way: if an unapproved RMM installation is found, reset the passwords of the accounts used to install it, and investigate further if a System-level account was used.

It does not help in three cases. If the affiliate uses the product you have approved, an allow-list by product name passes it. If the tool is renamed, as MeshAgent was here, a list keyed on file names can be walked past, so the list has to be keyed on what cannot be renamed cheaply: the code signer, the file hash, the service's installation path, and the destination the agent talks to. And an allow-list says nothing about who is using an approved tool, which is why Microsoft also advises enforcing MFA on approved RMM systems.

The honest summary is that an RMM allow-list is a detection control with a good signal to noise ratio, not a prevention control, unless it is enforced by application control that blocks unapproved installers from running at all.

The rest of the chain, at defender level

After remote access, the post describes a conventional human-operated sequence. Discovery used NetScan, SoftPerfect Network Scanner Portable and Nmap. Credential theft used Mimikatz, LaZagne and pypykatz, and the Windows ntdsutil tool to create an Install From Media copy of the Active Directory database, which gives an attacker the NTDS.dit file and registry hives for offline hash extraction. Microsoft notes that this implies high-privilege access to a domain controller.

Defence evasion followed privileged access: real-time monitoring switched off, a Defender exclusion added for C:\PerfLogs, and registry changes affecting DisableAntiSpyware, DisableRealtimeMonitoring and the WinDefend service. Lateral movement used PsExec, often with a host list file, together with Impacket, NetExec over SMB, admin shares and an RDP batch script that enables Remote Desktop and opens TCP 3389 in the firewall. PsExec was also used to push renamed MeshAgent binaries to newly compromised machines.

Exfiltration is the part most worth building a specific alert for. Microsoft says the affiliate most commonly relied on s5cmd, a command-line tool for Amazon S3 and compatible storage, staged alongside a credentials file holding access keys, and used it to copy documents, spreadsheets, databases, mail files and archives to attacker-controlled buckets, filtered by file extension. Rclone was the other tool. Both are legitimate data movement utilities. The data leaves before the encryptor runs, which is what makes double extortion work, and it is also the defender's last good chance to notice.

Microsoft is candid that none of this is new: the post says Storm-2570's techniques "are not novel". That is the point rather than a weakness. The value of the post is not a new technique; it is the evidence that the same list of ordinary tools sits under four different brands, which tells a defender where the stable detection surface is.

Method and interest

Microsoft sells the products it recommends. The mitigation list centres on Defender features: tamper protection, attack surface reduction rules, automatic attack disruption in Defender XDR, and threat analytics reports that need a Defender licence. The hunting queries are written for Defender and Sentinel tables. The post also includes a section promoting Security Copilot agents. That is normal for vendor threat research and it does not make the findings wrong; it means the controls should be read as categories rather than as a shopping list.

Separate the method from the product. Tamper protection exists because an attacker with local admin rights can otherwise switch off endpoint protection, and every serious endpoint product has an equivalent. Blocking process creation from PsExec and WMI, blocking credential theft from LSASS, and flagging renamed copies of system tools are behaviours to ask of whatever endpoint and detection stack you run. The attribution of these intrusions to one affiliate is Microsoft's assessment from its own investigations, and the post does not map Storm-2570 to any name another vendor uses. We found no other vendor's name for this cluster in the public coverage we checked, all of which repeats Microsoft's post. Treat the clustering as one well-resourced vendor's view, not an industry consensus.

What the post does not establish

Claims a reader might draw from the Storm-2570 post, and whether the post supports them. Source: Microsoft Threat Intelligence, 24 September 2026

Claim	Established?	Why
UK organisations were hit	Yes	UK is one of six countries named
How many UK victims	No	No victim or intrusion counts given
Which UK sectors	No	Sectors are listed for all countries together
RMM tools were the way in	No	Text says initial access is unconfirmed
Activity continues now	No	Timeline ends 30 April 2026
Other vendors agree on the cluster	No	No cross-vendor names given
Defender tampering in BERT cases	No	Named only for Qilin, DragonForce, Anubis
Same tooling across brands	Yes, per Microsoft	Microsoft's assessment across its own cases

For a UK reader the useful fact is narrow. A named affiliate with a documented toolkit has hit UK organisations. The post does not say whether UK victims were in the NHS or retail or local government, and nothing in it supports a UK-specific risk level. What it does support is a UK organisation checking its own estate for the tools listed, because those checks cost little and do not depend on the missing numbers.

What to do, in the order worth doing it

// Starting point for Microsoft Defender advanced hunting. Adjust to your estate; not tested against it.
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("s5cmd.exe", "rclone.exe", "cloudflared.exe", "ngrok.exe")
    or ProcessCommandLine has_any ("s5cmd", "rclone", "cloudflared", "ngrok")
    or (FileName =~ "ntdsutil.exe" and ProcessCommandLine has "ifm")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc

The question that exposes the gap

Ask your own team one question. If Storm-2570 installed a MeshAgent renamed after your organisation on one of your servers tonight, then added Splashtop through Atera the next morning, which alert would fire, and who would see it before anyone knew which ransomware brand was coming?

If the honest answer is that the first alert would be the ransom note, then the brand name on it will not matter much.

Key facts