Spirals: from web shell to encryption in under a day

Symantec’s Threat Hunter Team documented a new ransomware family called Spirals, used against an IT services company in South Asia. The number that stands out: from breach to full network encryption took under 24 hours.

That timeline matters more than the malware itself. The Rust-based payload is solid but not revolutionary. What is revolutionary — or rather, steadily refined over years — is the operational tempo. Not long ago the median dwell time before an attacker struck was measured in weeks. Here the entire cycle closed within a single day, which directly shapes how defence must work.

Below we reconstruct the sequence step by step and, more importantly, identify the specific moments where it could have been stopped.

Timeline: the day that ended in encryption

16 June, 22:21 — entry

The attack begins with the compromise of an internet-facing IIS web server and the upload of an ASP.NET web shell. The hour isn’t accidental: late evening is a standard choice because it reduces the chance anyone notices an anomaly in real time.

A web shell is a small file placed in a directory served by the web server, giving the attacker command execution through ordinary HTTP requests. Its appeal is that it requires installing nothing — it runs in the context of the existing, trusted server process.

Within minutes — three independent tunnels

Immediately after gaining access, the attackers deploy three separate tunnelling tools, including Chisel masquerading as chrome.exe and a Cloudflare tunnel client. A token impersonation tool follows, likely used for privilege escalation.

That redundancy is a deliberate operational decision. Three independent communication channels mean cutting one doesn’t end the operation. If a defender spots and blocks one tunnel, two remain — and the attacker learns they’ve been detected.

Note the tool selection. Chisel is legitimate, open-source tunnelling software. The Cloudflare client is a component of a widely used service. Both blend into normal traffic and aren’t classic malware, so signature-based detection struggles. Naming the binary chrome.exe adds a layer of camouflage, betting nobody checks where the browser is being launched from.

23:33 — lateral movement via WMI

Just over an hour after entry the attackers pivot to WMI-based lateral movement, reaching more than a dozen machines within minutes. They use compromised domain administrator credentials.

This is the pivotal moment of the whole operation and deserves emphasis: from a web shell on a web server to domain administrator credentials took about an hour. The report doesn’t specify how those credentials were obtained, but the typical routes are well known: extraction from process memory after privilege escalation, an over-privileged service account, or credentials stored in application configuration.

WMI (Windows Management Instrumentation) is a built-in Windows management mechanism. Using it for lateral movement is a living off the land technique — the attacker brings no tooling, using what the system offers natively and administrators use daily. So “WMI was used” isn’t an alert in itself; the alert is who, from where, and to how many machines.

17 June — mass deployment via PsExec

The next day the operation shifts to scaling. PsExec becomes the primary vector: a single compromised host pushes an identical base64-encoded PowerShell payload to further targets across the network — every few seconds, for roughly 30 minutes.

From a detection standpoint that pattern is practically shouting. One machine opening administrative connections to dozens of others, at even multi-second intervals, with an identical payload, is behaviour with no counterpart in normal operations. If any moment of this operation was going to be caught automatically, this was it.

The finale — encryption

The Spirals payload is full-featured ransomware written in Rust, with capabilities spanning defence evasion, encryption, lateral movement, process termination, obfuscation and privilege escalation. Before encrypting, the operation disables security services and disrupts backups — a standard element of modern campaigns, aimed squarely at the victim’s ability to recover without paying.

Symantec notes the payload appears entirely new or purpose-built for this single attack, and the actor behind it remains unidentified.

Why Rust, and why it matters

The language choice isn’t accidental and fits a clear trend of recent years.

Harder analysis. Binaries compiled from Rust are tougher for reverse engineers than C equivalents. Aggressive optimisation, interwoven error-handling machinery and code generation patterns mean reconstructing logic takes longer — and an analyst’s time is a real cost on the defensive side.

Weaker signature coverage. Detection tooling has decades of experience with malware written in C and C++. Newer languages mean a smaller base of rules and heuristics.

Easy cross-platform builds. The same code compiles for Windows and Linux with modest effort, simplifying attacks on mixed environments.

Performance. Encrypting large volumes is computationally intensive; a language without VM overhead simply does it faster, shortening the window for response.

The practical takeaway: file-signature detection will keep losing effectiveness. Since payloads are sometimes written for a single campaign and compiled in a language with weaker coverage, defence must rest on behaviour: who executes processes remotely, who modifies files en masse, who disables security services.

Where it could have been stopped

This is the most important part of the analysis. The attack had several clear points where automated response would have halted it before encryption.

Moment	Signal	Possible response
22:21	New `.aspx` file in an IIS directory	Alert on changes in served directories; block writes
minutes later	Web server spawning child processes	Alert — `w3wp.exe` shouldn’t launch a shell
minutes later	New binaries in temp directories; `chrome.exe` outside its standard path	Application control (allowlisting); alert on unusual location
minutes later	Persistent outbound connections to tunnelling services	Egress control; domain allowlist
23:33	Remote execution via WMI to a dozen-plus hosts in minutes	Threshold alert; automatic isolation of the source host
17 June	PsExec pushing an identical payload every few seconds	High-priority alert; immediate isolation
before encryption	Stopping security services, deleting backups	Tamper protection; immutable backups

Note that none of these signals requires detecting the ransomware itself. All concern earlier stages — the moments when damage is still reversible. That’s exactly why detection engineering aimed at techniques rather than samples is more effective today than another scanner.

Practical conclusions

Internet-facing servers remain entry point number one

It all began with an IIS server reachable from the internet. The fundamentals don’t change: short patch cycles, a minimal number of exposed services, a WAF in front of web applications and — most importantly — monitoring served directories for new executable files. A web shell has to land somewhere; detecting a write in an application directory is a simple, effective rule.

An hour from web shell to domain admin is an identity problem

If an attacker moves from a web server to domain administrator credentials in an hour, those credentials were within reach. Remediation directions:

no domain administrator logins on ordinary servers (a tiering model),
separate administrative accounts for workstations, servers and the domain,
in-memory credential protection (Credential Guard and equivalents),
least-privilege service accounts instead of “administrator just in case”,
monitoring privileged account use from unusual hosts.

We cover this in more depth in Active Directory security and NTLM relay attacks.

Segmentation buys the time you most lack

In a flat network, lateral movement via WMI and PsExec is trivial. Segmentation doesn’t prevent a breach but slows its spread — and in an operation compressed into 24 hours, every delay materially increases the chance of responding. Practically: restrict administrative traffic (SMB, WMI, RPC) between workstations and servers to designated management hosts (segmentation testing).

Backups must survive the attacker, not just a failure

The operation deliberately disrupted backups before encrypting. A backup reachable from the same domain, using the same credentials, is useless in that scenario. Minimum requirements: immutable or offline copies, outside the production domain, with regularly tested full-environment restores (3-2-1 strategy).

Detection has to work at night

The attack started at 22:21 and the critical lateral movement phase came at 23:33. A “SOC during office hours” model doesn’t apply. If a 24/7 team is out of reach, the alternative is automated response: isolating a host when hard conditions are met, without waiting for a human decision. Better to disconnect one machine unnecessarily than to rebuild an entire network — we discuss the trade-offs in security monitoring for SMEs.

Three numbers worth knowing for your own network

Analysing someone else’s incident only pays off when it turns into questions about your own environment. For this scenario, three specific figures matter.

Time from a file write in a web directory to an alert. The web shell is the first artefact of the whole operation. Without file integrity monitoring on served directories that figure is effectively “never”. If you have it, check whether the alert actually reaches someone at 22:21, or merely joins a queue for morning review.

Time from an ordinary account to domain administrator. This is the one number that genuinely describes your internal network’s resilience. In this attack it was about an hour. You can’t establish it any way other than by testing — which is why internal penetration tests starting from “the attacker has a foothold” are more valuable than external scanning.

Time to restore critical services from backup. Not “do we have backups”, but how many hours it takes to restore operations assuming the domain is compromised and any backup reachable via domain accounts is useless. If nobody knows that number, the continuity plan exists only on paper.

Measure these three once, write them down, and treat them as a baseline. Improving any of them translates directly into the impact of a real incident — unlike most metrics reported by security tooling.

Frequently asked questions (FAQ)

Is 24 hours the new standard? It’s a clear direction. A few years ago attackers spent weeks in a network conducting reconnaissance. Today many operations are heavily automated and close the cycle within a day or faster. When planning response, assume you have hours, not days — and with automation-assisted operations, less.

We’re a small company — does an attack on an IT firm apply to us? Yes, for two reasons. First, the technique is universal and cheap. Second, IT service providers are targeted because of their access to clients — compromising one partner can open doors to many companies, which we cover in third-party risk.

Would antivirus have caught Spirals? The payload appears purpose-built for one campaign, so signatures couldn’t have known it at the time. What was detectable was behaviour: the web shell, the tunnels, remote execution via WMI and PsExec, stopping security services. Defence resting solely on signatures arrives late in this scenario.

Where do we start on a limited budget? With four things offering the best effort-to-benefit ratio: monitoring file writes in web server directories, alerting on application server child processes, restricting administrative traffic between workstations, and a tested offline backup. Those detect or block most steps of this operation.

How do we check whether our network would withstand this? A controlled internal test starting from the assumption “the attacker has a web shell on a web server” reveals the real path to domain administrator and how long it takes to walk it. Get in touch if you’d like that verified.

Summary

Spirals is interesting not because it’s written in Rust — though that complicates analysis. It’s interesting because it shows how far time has been compressed: a web shell at 22:21, domain administrator credentials and lateral movement by 23:33, mass deployment the next day, encryption before the day was out.

The conclusions are mundane and actionable. The attacker entered through an exposed server, escalated to domain administrator in an hour, moved using native Windows tooling and destroyed backups before encrypting. Every one of those steps leaves a signal detectable without knowing the specific malware. The question isn’t “do we have antivirus” but “at 23:33, will anyone — or anything — respond”. If you want to know what that answer looks like in your organisation — let’s test it together.

Sources and further reading: Symantec Threat Hunter Team, Help Net Security, CISA — StopRansomware, MITRE ATT&CK.