Correction, 31 October 2026: The initial version used 2023–24 evidence and missed relevant 2025–26 primary reporting. This version replaces that incomplete assessment with the updated joint advisory, Microsoft and IBM investigations, and October incident-response reporting. Historical indicators are separated from current operational evidence.
Assessment at a glance
Identity: Rhysida is a ransomware-as-a-service ecosystem. Its service operators, affiliates and suppliers of access or signed malware are different analytical objects. Assessment: investigate the access chain and retained credentials as well as encryption. Confidence: high in the source-specific findings below; lower in generalisations across affiliates. Research checked: 31 October 2026. Reporting dates and the dates of underlying activity are kept separate.
Cisco Talos's report published on 29 October names Rhysida among ransomware operations encountered during Q3 2026. This establishes recent incident-response visibility; it does not assign every technique in Talos's aggregate findings to Rhysida. Talos Q3 findings
Naming: the service and its operators
Microsoft's naming reference associates Vanilla Tempest, previously DEV-0832, with VICE SPIDER / Vice Society. Those names describe an operator cluster. They are not blanket aliases for the entire Rhysida ransomware service. A Rhysida detection identifies malware activity; further evidence is needed to identify the intrusion team. Microsoft naming reference
Microsoft's 19 May 2026 investigation documents Vanilla Tempest using Fox Tempest's malware-signing service from June 2025. Fraudulently signed Teams installers were distributed through advertisements and fake download pages. Execution installed Oyster, also known as Broomstick, providing persistent remote access and follow-on payload delivery. Some observed attacks culminated in Rhysida. Fox Tempest supplies signing services; it is not an alternative name for Vanilla Tempest or Rhysida. Microsoft technical investigation
Attribution therefore depends on whether local evidence supports a particular chain. Shared certificates, loaders or backdoors can reveal a supplier relationship without demonstrating common command, ownership or victim selection. Preserve the vendor namespace and scope of each asserted relationship.
The missed April 2025 advisory update
The joint FBI/CISA/MS-ISAC advisory AA23-319A was updated on 30 April 2025, using investigations as recent as December 2024. The earlier profile missed this revision. It adds Gootloader as an observed initial-access mechanism, discusses AZCopy and Azure Storage Explorer, and removes outdated indicators and techniques. The update changes both investigation priorities and the weight that historical indicators deserve.
The advisory reports deployment against education, healthcare, manufacturing, information technology and government organisations since May 2023. This describes the agencies' visibility, not a complete victim census or evidence that other sectors are safe. Its service-and-affiliate model also means an intrusion can involve several commercial relationships before encryption.
Initial access and expansion
The revised advisory retains compromised VPN credentials and exposed remote services as access paths, particularly where MFA was not enabled by default. It adds cases involving Gootloader. Establish which path is supported locally: stolen remote-access credentials and a user executing a malicious download require different evidence collection, even if the same encryptor appears later.
The agencies describe RDP, PowerShell, PsExec and native discovery commands. Enumeration includes identities, network configuration, domain membership, administrative groups and trust relationships. These tools have legitimate uses. Investigate unexpected sequences: a new remote source, an unusual account, discovery on a machine that does not normally administer the domain, and execution across further hosts. Tool names alone do not establish attribution.
Credential access includes NTDS dumping with tools such as secretsdump and ntdsutil. Directory-database access compromises a trust boundary, not merely one password. The advisory recommends domain-wide password resets and two krbtgt resets when NTDS.dit compromise is indicated. Recovery needs a controlled identity-restoration plan that accounts for service dependencies; uncoordinated resets during an active intrusion can complicate containment.
Data movement and security impairment
The April revision identifies AZCopy and Azure Storage Explorer in the observed toolset. An installed copy of these legitimate utilities does not prove theft. Investigate the launching account, executable provenance, destination ownership, transfer volume and business purpose. A legitimate storage provider can host a destination controlled by an attacker.
The advisory documents event-log clearing with wevtutil and malicious administration blended into ordinary activity. Central log copies matter: preserve remote-access, identity, endpoint, DNS and cloud-storage records before retention limits or containment changes erase the sequence. A missing local log is an investigative finding, not proof that no intrusion occurred.
Encryption and extortion
The agencies describe 4096-bit RSA with ChaCha20, a .rhysida extension and a PDF ransom note directing victims to a negotiation portal. They also describe staging and remote execution with batch scripts and PsExec. These observations organise an investigation; they are not an invariant playbook for every affiliate or later binary.
Double extortion creates separate recovery questions: restoring operations and establishing what information was taken. Successful restoration does not answer the second. Conversely, a criminal claim is not independent verification of data contents, volume or provenance. Keep technical findings separate from negotiation claims.
What 2026 research adds about persistence
IBM X-Force's 12 June 2026 investigation associates Vanilla Tempest chains with Endico, Tomb, Broomstick and Supper. In a reconstructed late-2025 fake-Teams chain, a scheduled task named AlphaSecurity maintained Broomstick access; Vidar and Supper followed. IBM also identifies code relationships among Supper, NodeSnake and InterlockRAT. This supports shared-development or supplier hypotheses, not a conclusion that Rhysida and Interlock are one operator. IBM X-Force investigation
TIR assessment: containment must cover more than the encryptor. A loader, scheduled task, backdoor, stolen browser session or valid remote-access identity can outlast file restoration. Investigate the process that delivered ransomware and every access mechanism it depended on. A trusted-looking signer is evidence of provenance, not a guarantee of safety. Correlate the download origin and execution chain with the approved enterprise deployment process.
Useful hunting questions include whether the installer came through the software catalogue, whether it created unexpected tasks or child processes, and whether new outbound destinations appeared afterwards. Check whether the same credentials were used elsewhere before or after isolation. These questions derive from observed chains; they are not universal Rhysida signatures.
Dwell time: measure access separately from encryption
The reviewed evidence does not establish a representative Rhysida dwell-time statistic for 2026. Individual malware-stage intervals do not measure the duration of access to an organisation. A new report can also describe substantially older activity.
TIR assessment: record four clocks separately: earliest evidenced access, first malicious execution, first confirmed data access or transfer, and encryption or disruption. Record uncertainty when telemetry begins after the likely compromise. A short backdoor-to-encryption interval can coexist with a much older stolen credential or access-broker foothold.
Persistence is an evidence question too. Recurring tasks, remote-access installations, unauthorised identities and backdoors require different eviction measures. Current reporting gives specific reasons to investigate software-delivery and signing trust alongside the established requirement to remove backdoors and recover credentials.
Detection and recovery priorities
- Reconstruct entry. Preserve downloads, browser and proxy history, remote-access authentication and device telemetry. Identify the account and host responsible for the first evidenced access.
- Find retained execution. Review new or changed tasks, services, remote-management installations and unexpected software-delivery paths. Validate ownership before removing legitimate administrative tools.
- Scope identity exposure. Investigate directory-database access and browser or session theft. Revoke sessions and rotate affected credentials from trusted systems, including identities usable outside the encrypted network.
- Investigate transfers. Review unusual AZCopy or Storage Explorer use and outbound storage destinations with account, process and timing context. Distinguish authorised transfers from exfiltration.
- Restore trust before reconnecting. Verify images, access policies, management identities and recovery infrastructure. Restoring files while retaining adversary access leaves a route to recurrence.
These are TIR response priorities informed by the evidence. They supplement the updated advisory's recommendations on phishing-resistant MFA, patching, segmentation, logging and recoverable offline or immutable backups. Apply them through the organisation's incident command and recovery plan.
Indicators and related coverage
The April 2025 advisory explicitly removed outdated indicators from its first edition. This profile therefore does not recycle the 2023 IP list as a current blocklist. Use the dated government advisory and Microsoft investigation for source-specific indicators, validating relevance and time bounds before operational use. A historical match can support retrospective scoping; absence of a match cannot clear a system.
Read the Qilin profile for a separate affiliate ecosystem, and trusted remote access, persistence and SolarWinds lessons for abused administrative trust. Similar exposure does not establish common attribution or an identical breach mechanism.
Version history
Version 2 — 31 October 2026: Corrects the missing 2025–26 evidence; adds the revised advisory, operator/supplier distinctions, signed-installer and backdoor analysis, and October activity context. Removes the obsolete indicator list from current guidance. Version 1 remains an explicitly superseded historical record.