Spirals Ransomware

The intrusion opened with an internet-facing IIS web server, exploited or otherwise compromised, that received an ASP.NET web shell. Current public reporting does not name the specific vulnerability or configuration weakness involved, so defenders should treat "internet-facing IIS" broadly rather than waiting on a CVE to hunt for this pattern. The first observed malicious activity was timestamped June 16, 2026 at 22:21 local time, when a cluster of tunneling and reverse-proxy tools appeared on the initially compromised host.

What sets Spirals apart is what happened in the minutes right after that upload. Within roughly ten minutes, the operator had deployed four separate tunneling and remote-access tools, each staged in a location consistent with access through the web server itself:

• A tunneling utility named tunn.exe appeared first under a public web production directory (...\public\tunn.exe), then a second copy was placed inside the Windows Tasks folder (...\Windows\tasks\tunn.exe), a staging location chosen to blend in with legitimate scheduled-task binaries
• A reverse SOCKS proxy, revsocks.exe, was dropped and executed in the same two locations shortly afterward
• The Chisel tunneling tool was renamed chrome.exe and placed in the Windows Tasks folder, disguised as a browser process
• A Cloudflare Tunnel client (cloudflared-windows-amd64.exe) was deployed to a web production project directory, adding a fourth, independent encrypted outbound channel

Establishing four redundant covert channels before doing anything else on the host is not exploratory behavior. It is the signature of an operator working from a checklist, prioritizing persistent access over stealth from the very first minutes of the intrusion. Around the same time, a token-impersonation tool named tokens.exe was executed from a separate web project directory, likely to acquire elevated privileges on the host.

For defenders, the practical takeaway is that a single web shell detection on an IIS server should be treated as a network-wide incident within the hour, not a ticket to close after removing one file. By the time a web shell is found, redundant remote access may already be in place.

The operator ran commands directly through the IIS worker process (w3wp.exe), spawning cmd.exe and powershell.exe as children. Over roughly three hours, they bypassed User Account Control, enabled Remote Desktop Protocol, created a persistent local account, and dumped the SAM registry hive for local password hashes. By 23:07, roughly ninety minutes after the initial breach, telemetry showed ransomware precursor activity, including attempts to disable security tools and download additional tooling. The tokens.exe token-impersonation utility deployed in Stage 1 is assessed as a likely privilege-escalation aid, though the specific mechanism it uses is not detailed in current public reporting.

Credential harvesting extended beyond the SAM hive. LSASS process memory was also dumped, reportedly using rundll32.exe to invoke the MiniDump export of comsvcs.dll, a living-off-the-land technique that avoids introducing a dedicated credential-dumping binary and blends into normal DLL export activity unless process-argument telemetry is examined closely.

What runs on the endpoint here is deliberately unremarkable at the binary level. There is no custom loader and no packed dropper at this stage. The tells are behavioral: an IIS worker process spawning a shell, a UAC bypass immediately followed by RDP configuration changes, and a credential-dumping command line using a legitimate system DLL for a purpose it was not designed for.

The attempt to disable security software at 23:07 on the first night, roughly ninety minutes after the initial breach, shows evasion was treated as a prerequisite for the rest of the operation, not a late-stage cleanup step.

Evasion here relies on disguise rather than packing, consistently matching legitimate names and locations (T1036.005) throughout the intrusion. The ransomware executable itself was named bitsadmin.exe, borrowing the identity of a legitimate Windows Background Intelligent Transfer Service utility that many allowlists and analysts overlook by name alone. One of the tunneling tools ran under the process name chrome.exe. In one instance, a Spirals sample was dropped directly into the user's Temp directory as vbr2116.exe by a process presenting as svchost.exe, a further layer of masquerading consistent with the operator's broader pattern of impersonating legitimate Windows components. The mass-deployment PowerShell payload pushed through PsExec was base64-encoded, a simple but effective way to defeat naive string-based command-line scanning.

The final evasion layer is the tunneling infrastructure itself. Chisel, revsocks, and Cloudflare Tunnel all wrap command-and-control traffic inside protocols, HTTPS and WebSocket-style tunnels, that firewalls and proxies are configured to allow by default. None of these tools require a novel exploit; each is a publicly available utility repurposed for covert access.

A file name alone is not malicious evidence. The presence of a file called bitsadmin.exe outside %SystemRoot%\System32, a svchost.exe process that does not match the legitimate binary's install path or signature, or a file matching one of the hashes in the IOC section, is the actual indicator, not the process name in isolation.

At 23:33 on the first night, the operator pivoted to WMI-based lateral movement, reaching more than a dozen machines within minutes using multiple abused accounts, including accounts assessed as likely or built-in domain administrator accounts. The cadence and command structure of this activity is consistent with automated, scripted lateral movement rather than manual targeting, and points toward a target list built from prior Active Directory and network-share enumeration.

The following day, June 17, the operator switched to PsExec as the primary mass-deployment mechanism, running remote sessions of this general form against each target hostname in turn:

psexec.exe -accepteula -d -s \\<target> powershell -nop -w 1 -enc <base64-payload>

Starting around 14:12, a single compromised host pushed this identical base64-encoded PowerShell payload to network targets, more than one new host every few seconds, for roughly thirty minutes; PsExec sessions were reported delivering the decoded payload beginning around 14:44. Targets reportedly included domain controllers, file servers, application servers, virtual machines, and workstations, a spread consistent with a target list compiled in advance rather than discovered live.

The decoded payload performed two actions in sequence on each host. First, it disabled Windows Defender's real-time monitoring and removed its threat definitions:

C:\progra~1\window~1\MpCmdRun.exe -RemoveDefinitions -All -DisableRealtimeMonitoring $true -Set-MpPreference -DisableIOAVProtection $true

Second, it enumerated and forcibly stopped any running service whose name, display name, or description matched a broad list of roughly 23 backup, database, and virtualization products, including Exchange, Hyper-V, VMware, Veeam, Acronis, Veritas, Commvault, SQL Server, Oracle, MySQL, PostgreSQL, Intuit, SAP, and Lotus Domino:

$p=@("*excha*","*hyper*","*vmms*","*vmcompute*","*virtual*","*veeam*",
"*backup*","*acronis*","*veritas*","*commvault*","*SQL Server*",
"*oracle*","*mysql*","*postgre*","*intuit*","*sage*","*sap*","*domino*");
$p|%{$pt=$_;Get-WmiObject Win32_Service|?{($_.Name -like $pt)-or
($_.DisplayName -like $pt)-or($_.Description -like $pt)}|
?{$_.State -eq 'Running'}|%{Stop-Service -Name $_.Name -Force -EA 0}}

Stopping these services releases the file locks those applications hold, clearing the way for the encryptor to reach files that would otherwise be in use, and it simultaneously degrades the victim's ability to recover from backup. The ransomware payload (bitsadmin.exe) was then placed across multiple locations to maximize coverage: %SystemRoot%\bitsadmin.exe, %USERPROFILE%\desktop\bitsadmin.exe, the SYSVOL domain scripts share (...\sysvol_dfsr\domain\scripts\bitsadmin.exe), and a network share hosted directly on a domain controller. Placement inside SYSVOL and on a domain-controller share is significant: both locations replicate or are reachable across the entire domain, giving the payload a path to machines that PsExec never directly targeted.

Once services were cleared, the Rust-based encryptor ran across reachable hosts, generating a unique AES-128 key per file and wrapping each key with an attacker-controlled ECDH P-256 public key. Files larger than 5MB are encrypted in jittered chunks rather than in full, a common optimization that trades completeness of encryption for speed across a large file set.