Qilin Ransomware: Inside a Rust Encryptor and Its Affiliate Ecosystem

Qilin ransomware combines file encryption with an affiliate operation that manages victims, ransom negotiations, and stolen-data publication. Different intrusion teams deploy its payloads, so identifying Qilin does not automatically identify the attacker or the method used to enter a network.

This analysis examines a Rust-based Windows encryptor and the wider Qilin affiliate ecosystem. It covers the sample’s configuration, file selection, encryption behavior, and indicators that can support investigation.

The sample’s most important findings go beyond its encryption algorithms. Its file-size-based gaps, incomplete-write handling, and rename behavior mean that modified files may not carry the expected extension. These details matter when assessing damage and planning recovery.

Key Findings

• Qilin is deployed by multiple intrusion teams. The ransomware family does not identify a single affiliate or initial-access method.
• The analyzed sample uses partial file encryption. Its gaps depend on the original file size, rather than a fixed 5 MiB interval.
• A nominal 10 MiB range can transform 11 MiB. An inclusive loop boundary allows another operation when file data remains.
• File names can understate the damage. Changed files may retain their original names if renaming fails.
• A reported success does not guarantee complete recovery metadata. The footer write can return a success status without writing all 512 bytes.

What Is Qilin Ransomware?

Qilin, also known as Agenda, is a ransomware family offered through a ransomware-as-a-service model. The core operation supplies ransomware and extortion infrastructure, while affiliates conduct intrusions and deploy the payload.

The family has included Go-based and Rust implementations, with variants targeting Windows, Linux, and VMware ESXi environments. The technical analysis below focuses on one Rust-based Windows sample.

The core operation and its history

MITRE tracks the Qilin RaaS operators as Water Galura, G1050, with GOLD FEATHER listed as an associated name. The core handles payload generation, ransom negotiation and stolen-data publication for affiliates recruited on Russian cybercrime forums. It also operates a Telegram news channel. This division places the ransomware service behind multiple intrusion teams, rather than making every Qilin deployment the work of one affiliate. MITRE’s operator record identifies the core as active since at least 2022.

The chronology separates changes in the service from later incidents:

• July to September 2022: Agenda launches and adopts the Qilin name.
• October to December 2023: Affiliate recruitment excludes CIS targets as an advertised operating policy; a Linux variant targeting ESXi is identified in December. These milestones are documented in the HC3 profile.
• June 2024: The Synnovis attack begins on 3 June, and NHS England records file publication on 20 June. Service restoration follows by December. NHS England
• August 2024 reporting: A Qilin intrusion includes theft of Chrome-stored credentials, compromised VPN access without MFA and an 18-day dwell period before ransomware execution. HC3’s August bulletin, published 13 September
• 2025: Qilin appears in further affiliate deployments, driver-assisted defense tampering and a publicly advertised legal-advisory offering.
• 2026: National incident reporting, a newer pre-encryption EDR Killer chain and continued leak-post activity show an operation that remains active. Each observation has its own date and measurement scope.

How the Affiliate Panel Works

EcuCERT’s July 2024 alert describes six areas in the Qilin affiliate panel:

The embedded configuration in the Windows binary provides the technical counterpart to this customization model: the note, extension, exclusion lists, shutdown targets and range schedule are data, not universal constants across every Qilin deployment.

Threat Actors That Have Deployed Qilin

Different threat actors have deployed Qilin or Agenda ransomware. These deployment relationships should not be treated as proof that the actors belong to the same organization or develop the ransomware themselves.

Keep the four actor entries, with these concise opening sentences:

Pistachio Tempest. Microsoft’s August 2022 Cyber Signals report records DEV-0237 experimenting with Agenda in June 2022. Its Pistachio Tempest profile describes a financially motivated cluster using brokered access and several ransomware payloads. ANSSI’s FIN12 assessment connects the FIN12, DEV-0237 and Pistachio naming. This is deployment-cluster context, not identification of Qilin’s developers.

Octo Tempest / Scattered Spider. The Microsoft Digital Defense Report 2024 identifies Octo Tempest as Scattered Spider and records Qilin and RansomHub additions to its payload set in the second quarter of 2024. Microsoft’s 2025 report describes continued Qilin-related activity, including hybrid and ESXi environments.

Moonstone Sleet. Microsoft’s human-operated ransomware overview records Qilin deployment in March 2025. Its actor-naming reference identifies Moonstone Sleet as a North Korean activity cluster. The state affiliation belongs to that deployer; it does not establish state ownership of the Qilin service.

Storm-2570. Microsoft’s September 2026 investigation tracks this affiliate from April 2025 across Qilin, DragonForce, Anubis and BERT. Repeated activity includes MeshAgent and other RMM access, ngrok or Cloudflare tunnels, network discovery, NTDS credential theft, PsExec/Impacket/NetExec lateral movement, Defender tampering, and s5cmd or Rclone transfers to cloud storage. For defenders, those recurring pre-encryption behaviors can connect intrusions even when the final ransomware changes.

Extortion and Negotiation Tactics

A publicly archived February 2025 conversation records two distinct proof offers: copies of selected stolen files and test decryption of selected encrypted files. On 12 February, the speaker labeled Qilin offered a 10% discount to USD 63,000. The next day, it refused a separate purchase of decryption or confidentiality. On 19 February it extended the deadline by 24 hours; on 20 February the stated demand fell to USD 60,000. A publication threat followed on 26 February.

These are recorded statements in one negotiation, not verified payment, deletion or recovery outcomes, and not a family-wide price schedule. The sequence illustrates how technical proof, bundled promises and deadline pressure work together.

The extortion service also expanded its advertised support. A December 2025 EcuCERT alert records a June announcement of Call Lawyer, an affiliate-facing legal-advisory feature intended to increase negotiating pressure. The significant development is the offer itself: regulatory and disclosure risk becomes another lever alongside decryption and confidentiality. It should not be treated as reliable legal advice or as assurance that payment resolves a victim’s obligations.

Qilin Attack Methods and Business Impact

Qilin is a payload used in different intrusion chains, rather than a reliable identifier of one initial-access method. CERT Polska’s 2025 report recorded 13 Qilin incidents and suspected compromised VPN credentials in nearly half. CERT.at connected confirmed Austrian ZipLine recruitment-chain incidents with subsequent Qilin activity.

Italian government-republished incident reporting describes perimeter compromise, supplier access, remote management, exfiltration and pressure on ESXi and backup infrastructure. Its Ivanti EPMM examples involve mobile-device management, not VPN vulnerabilities. These intrusion routes belong to the broader campaign context; the Windows encryptor’s own behavior is detailed below.

Credential Theft and Security Interference

The HC3 August 2024 bulletin records browser-credential theft during a Qilin intrusion following VPN compromise without MFA. That extends the response problem beyond restoring encrypted files: browser and remote-access identities can remain exposed after storage recovery.

An EcuCERT alert dated 8 May 2025 describes a different chain. A legitimate upd.exe loads avupdate.dll, which stages web.dat. EDRSandblast and the vulnerable TPwSav.sys driver support tampering with security callbacks and monitoring before the ransomware phase. The same campaign context includes stolen SSL-VPN credentials and lateral movement through RDP, PsExec and WMIC.

A later alert dated 15 April 2026 describes Foxit PDF Reader loading msimg32.dll and an encrypted EDR Killer component. Its driver chain uses rwdrv.sys, a renamed ThrottleStop driver, and hlpdrv.sys to support security-process termination and integrity tampering before Qilin deployment. These components are campaign-layer tools; this Windows encryptor implements its own process and service interference through ordinary Windows APIs.

Remote administration creates another deployment surface. The December 2025 alert records MeshAgent/MeshCentral access, WinSCP transfer of mmh_linux_x86-64 and a Splashtop SRManager.exe execution path in a June 2025 incident. Those artifacts make remote-management and transfer logs important alongside the final payload. In two earlier, unnamed cases, the same alert records a 2023 Asian company’s SMB/RDP/WMI movement and approximately 30 GB transferred to MEGA, and a 2024 U.S. company’s default-credential/RDP access with FTP exfiltration. These publicly documented but unnamed organizations widen the case history without inventing victim identities. EcuCERT’s December case summary

Virtualization and Backup Infrastructure

Later Qilin deployments extend disruption into virtualization management. MITRE’s Qilin record documents discovery of ESXi hosts, datacenters and vCenter clusters, enabling SSH on ESXi, and disabling vCenter High Availability and Distributed Resource Scheduler. It also records platform detection for FreeBSD, VMkernel, Nutanix AHV and standard Linux. These family-level procedures put hypervisor credentials, management-plane logs and recovery controls in scope alongside endpoints. They are distinct from the capabilities of this Windows encryptor.

What the Activity Figures Measure

The FBI IC3 2025 Annual Report places Qilin second among ransomware variants reported to IC3. That ranking describes U.S. complaint reporting.

ANSSI’s 2025 threat overview attributes 21% of ransomware types in its incident population to Qilin. CERT Polska supplies a separate national case series rather than the same denominator. Neither metric should be presented as a worldwide market share or added to leak-site post counts.

ANSSI also records more than 700 Qilin-claimed victims during 2025, including 185 in October. Those are public claims, separate from the agency’s 21% incident statistic. The difference matters: a leak post is an extortion event, not a forensic confirmation of a unique compromise. ANSSI’s annual overview

On 29 September 2026, RansomLook’s Qilin archive displayed 2,293 all-time posts, 76 in the preceding 30 days and 16 in the preceding seven days. These are archive post counts, not independently confirmed victims. The archive and the national case series measure different things and are not added together.

The historical sector distribution is similarly bounded. HC3’s 7 June 2024 leak-site snapshot assigned 21% of posted organizations to manufacturing, 15% to legal, 14% to finance, 9% to construction, 8% to technology and 7% to healthcare. Its separate healthcare review identified at least 15 incidents since October 2022, spanning several types of care provider. Those are dated disclosure and sector observations, not a current global victim census. HC3 threat profile

Yanfeng: the manufacturing claim

Qilin’s November 2023 claim against automotive supplier Yanfeng appears in CERT-EU’s monthly brief. It places a major automotive supplier in the public extortion record. The recorded claim is the attribution fact used here; it is not extended into a claim that every Yanfeng location or downstream manufacturer suffered the same compromise.

Synnovis: consequences beyond encrypted files

The Synnovis pathology-service incident began on 3 June 2024. NHS England’s incident FAQ records publication of files on 20 June, identifies confirmed patient-related data from an administrative working drive and describes service restoration by December. A later Greater London Authority report attributes the attack to Qilin.

A UK Parliament statement records more than 11,000 delayed outpatient and elective appointments, a patient death to which the disruption contributed, and an estimated £32.7 million financial impact on Synnovis. These victim-side facts illustrate the operational stakes; they do not identify the executable used in that incident.

Asahi: a public claim and a prolonged business outage

Asahi’s attack began on 29 September 2025. The company confirmed encrypted files at approximately 7 a.m. JST and disconnected its network at approximately 11 a.m. Its investigation placed unauthorized entry through network equipment roughly ten days before the disruption. The affected systems were those managed in Japan; the company confirmed encryption of servers and employee PCs and theft of some PC-held information. These findings come from Asahi’s shareholder investigation summary, completed as of 18 February 2026.

Qilin publicly claimed the attack on 7 October 2025, as recorded in Reuters’ contemporaneous report. The family claim and the company’s confirmed impact are kept distinct. The outage extended beyond the encryption event: Asahi’s investigation summary records restoration of digital order and shipment operations in early December 2025 and full logistics recovery in February 2026. Its 27 July 2026 financial-control notice records a material weakness following the attack and delayed financial reporting. The case illustrates how one intrusion can continue affecting logistics and corporate reporting months after containment.

Inside the Qilin Windows Encryptor

Sample identity and startup

Property	Value
SHA-256	37546b811e369547c8bd631fa4399730d3bdaff635e744d83632b74f44f56cf6
SHA-1	a85d9d2a3913011cd282abc7d9711b2346c23899
MD5	14dec91fdcaab96f51382a43adb84016
Size	1,642,496 bytes
Format	PE32, x86 Windows executable
Extension	.gBBQsRxAcQ
Ransom note	README-RECOVER-gBBQsRxAcQ.txt

The PE entry passes through MinGW startup before invoking the ransomware’s Rust main routine. TLS callbacks handle runtime setup and teardown. CPU feature checks select optimized cryptography; they do not gate encryption on an environment check.

The main routine parses configuration and command-line inputs before interference and traversal. Its --password check requires a nonempty value, which becomes part of the ransom note. It does not authenticate against an embedded secret.

Parser-name registrations establish paths and ips as targeting inputs alongside password. The range-selector fields n, p, fast, skip and step are read from the embedded configuration.

Embedded Configuration and File Exclusions

The embedded JSON supplies the public RSA key, note text, company identifier, encryption schedule and control lists. It also contains an empty private_rsa_pem field; the public key is the one used to wrap recovery metadata.

Raw control list	Entries	Unique values	Implemented selection
Directories	30	25	Lowercased basename, exact equality
Files	26	16	Lowercased filename, exact equality
File patterns	50	50	Dot-prefixed suffix comparison
Processes	1,028	1,028	Regular expressions with a (?i) prefix
Windows services	460	458	Conditional (?i) regex or transformed exact-name matching

Those counts describe the embedded lists, not the final working filters. Configuration processing adds company_id to the pattern list and constructs the exact note name from README-RECOVER-, gBBQsRxAcQ and .txt before adding it to the file list. The working file list becomes 27 entries with 17 unique values. The pattern list becomes 51 entries with 50 unique values, because the company identifier already appears in the raw list.

Those additions protect the note and ordinarily prevent files already carrying the ransomware’s extension from being processed again. The effective filters therefore differ from the raw JSON lists.

The ransom note brands the incident as Qilin, says files were encrypted, warns against modifying files or relying on third-party recovery, claims data theft and publication pressure, and directs the recipient to a Tor negotiation and credential workflow. Those are statements made by the note, not proof of exfiltration, publication, payment or deletion.

The delay and recovery-inhibition sequence

Before the 45-second delay, the program launches a separate thread for process and service interference. That thread handles processes first, then services. The main thread continues without waiting for it, so interference can overlap the delay and need not finish before encryption begins.

The main thread then sleeps for 45,000 milliseconds before attempting shadow-copy deletion.

The helper launches cmd.exe /C vssadmin.exe delete shadows /all /quiet, creating a recognizable child-process event. Whether shadow copies are deleted still depends on privileges and host conditions.

On WOW64, the launcher attempts to disable filesystem redirection around that command, but its revert call uses a zero-valued local address rather than the value saved by the disable call. That violates Microsoft’s disable-and-revert contract. The effect on shadow-copy deletion depends on the host and command outcome; it does not mean every attempt fails.

The sequence gives defenders a concrete correlation opportunity: an unusual executable, a short pre-encryption interval, destructive shadow-copy administration, process or service interference, and high-rate file activity. The command alone also occurs in legitimate administration, so its parent and surrounding events matter.

Process termination and service disabling

The separate interference thread handles processes before services, though either operation can fail or be delayed by the host.

The process path makes one EnumProcesses call with a fixed 16 KiB buffer, enough for at most 4,096 process IDs. It does not retry when that buffer fills. Microsoft notes that a full returned buffer cannot distinguish a complete list from a truncated one. For each PID, the implementation tries to resolve the base-module name; failures leave that process out of the matching vector.

Configured processes are normally selected through case-insensitive regular expressions. If a regex fails to compile, the program logs a warning and falls back to exact comparison of transformed names; it does not simply skip that target. A match requests PROCESS_TERMINATE and calls TerminateProcess with exit code 1. Failed name lookups or termination attempts can leave configured processes running.

Service inventory uses two EnumServicesStatusW calls: the first sizes the buffer and the second collects service and display names. The control list includes expressions such as svc$ and (.*?)sql(.*?). Service selection uses either case-insensitive regex or transformed exact-name matching. A regex error triggers a retry with exact-name matching rather than discarding the list. File exclusions use a different mechanism.

For selected services, the program opens the service-control manager and service, recursively handles active dependents, requests stop and polls state. Its tight poll continues until the elapsed whole-second count exceeds 40; it contains no Sleep inside that loop.

Whether stopping succeeds, fails or times out, the control path can still attempt to set the service start type to SERVICE_DISABLED.

A separate flaw complicates runtime reliability: GetLastError is tested immediately after handle-returning SCM calls instead of only after detecting an invalid handle. A stale thread error can reject an otherwise valid handle. Service-control attempts therefore do not establish that every configured target was successfully disabled.

Storage discovery and traversal

When explicit paths or hosts are supplied, the encryptor follows those targets; host expansion uses NetShareEnum. Without either input, it discovers local roots and recursively enumerates Windows network resources.

Two discovery details constrain coverage:

• The ordinary GetLogicalDrives loop tests A through Y but exits before checking Z. If that helper fails, a fallback tries C through Z. Explicit and network targets are separate, so Z is not universally excluded.
• The host-share helper makes a single level-0 NetShareEnum call and rejects every nonzero result, including ERROR_MORE_DATA. It does not resume pagination, so it can abandon a host whose share results exceed the supplied buffer.

Windows network-resource enumeration descends into containers and adds connectable remote names as traversal roots. Reach depends on available network providers, connectivity and the process’s access rights; the encryptor cannot automatically reach every share.

File selection, links and ransom notes

Directory filtering lowercases the basename and compares it against exact blacklist values. File filtering lowercases the filename, applies exact-file exclusions and then checks suffixes formed from . plus each effective bare pattern. These are not wildcard or regex comparisons. The resulting working lists include the exact note name and ransomware extension added during parsing.

The walker checks the Windows name-surrogate flag, not every reparse point indiscriminately. With its default settings, it does not descend into non-root directory name-surrogate links but does follow a root link. File-link entries can still be queued; because their ordinary open path does not set FILE_FLAG_OPEN_REPARSE_POINT, Windows opens the target.

Each accepted traversed directory receives an attempted write of README-RECOVER-gBBQsRxAcQ.txt before eligible files enter the work queue. Note placement and traversal can therefore provide evidence even where a subsequent file operation fails.

The worker pool has at least eleven threads and grows to one fewer than the reported processor count on larger hosts. Traversal and per-file encryption share that pool. SRW-lock coordination and work stealing distribute queued work, with SwitchToThread used during contention.

How This Qilin Sample Encrypts Files

ChaCha20 Encryption and File I/O

The encryptor uses standard 20-round ChaCha20. Its state constants decode to expand 32-byte k, and the round function uses the 16/12/8/7 rotation schedule. It reads selected file regions into a 1 MiB buffer, XORs them with the keystream and writes them back in place.

File I/O uses NtReadFile and NtWriteFile exports loaded from ntdll, not inline system calls. Pending operations wait on the file handle, and completed operations use the I/O status block’s byte count. If export resolution fails, the wrappers return STATUS_NOT_IMPLEMENTED rather than falling back to Win32 read/write calls. Microsoft defines that NTSTATUS value.

One cipher state is initialized per file. Keystream consumption continues across transformed chunks; plaintext gaps do not consume it. A later encrypted range continues that stream rather than restarting at counter zero or deriving its stream position from the file offset.

The cipher checks its remaining 32-bit block-counter budget. An oversized request panics instead of silently wrapping the counter. Because writes occur in place, earlier ranges could already be changed before such a failure prevents metadata and rename from completing.

Randomness and key material

The per-file 32-byte key and 12-byte nonce come from a ChaCha-based thread-local CSPRNG. Its bootstrap path is seeded with 32 bytes from Windows BCryptGenRandom; initial failure panics. A later reseed helper can retain the existing generator state when the OS request fails. Retaining an already seeded generator does not establish zero, repeated or predictable keys.

The embedded wrapping key is RSA-4096 with exponent 65,537. Its SubjectPublicKeyInfo SHA-256 is 498012a0ceac56bb69ff1410c50c74e39d1296287c23e9f1385da3fc5b4e51ad, a useful exact-build correlation pivot.

The selected range schedule

The embedded n=10 and p=5, with the other range fields set to zero, select a 10 MiB nominal range and a gap derived from the original file size. The program divides the size by 100, discards the remainder, then multiplies by five. If that result has any nonzero bits below 1 MiB, it bitwise-ORs the result with 1 MiB. Each later segment begins 10 MiB plus that derived gap after the previous segment start.

This is not ordinary rounding. At 20 MiB, the five-percent value is 1,048,575 bytes; the bitwise adjustment makes the gap 2,097,151 bytes. At 30 MiB, the raw gap is 1,572,860 bytes and already has the 1 MiB bit set, so it stays unchanged.

Why a 10 MiB Range Can Transform 11 MiB

After each successful nonzero write, the loop advances its logical cursor by 1 MiB. It repeats when that cursor is below or equal to the nominal end, allowing an extra 1 MiB operation at a continuing range boundary. The next segment still starts from the nominal range plus the derived gap, not from the cursor after that extra operation.

For a 30 MiB file, NtReadFile and NtWriteFile operate at offsets 0 through 10 MiB in 1 MiB steps, then resume at 12,058,620 and 24,117,240 bytes. The 512-byte metadata write begins at the original EOF, 31,457,280. Bytes in the intervening gaps remain unchanged. The same formula gives these file-size-dependent boundaries:

Original size	Derived gap	Next segment start(s)	Untouched span after first segment
20 MiB	2,097,151 B	12,582,911 B	[11,534,336, 12,582,911)
30 MiB	1,572,860 B	12,058,620 B; 24,117,240 B	[11,534,336, 12,058,620)
40 MiB	2,097,150 B	12,582,910 B; 25,165,820 B; 37,748,730 B	[11,534,336, 12,582,910)

The 20 MiB file’s first untouched span is wider than the 30 MiB file’s because of the bitwise adjustment. That non-monotonic result rules out a fixed repeating stride. A zero-byte read ends the segment; filesystem faults, short writes and remote providers can alter the ordinary successful-I/O path.

RSA-Wrapped Recovery Metadata

After the selected ranges, the implementation constructs a 60-byte record:

ChaCha20 key       32 bytes
ChaCha20 nonce     12 bytes
Constructed range  8 bytes, little-endian
Derived gap        8 bytes, little-endian

RSA-4096 OAEP using SHA-256/MGF1 produces a 512-byte ciphertext. Under normal full-write I/O, that ciphertext is appended at offset N, the original size.

The resulting normal layout is mixed transformed/plaintext original data followed by the 512-byte RSA ciphertext. The wrapped schedule fields are not a byte-by-byte map of transformed content, so the inclusive extra block must still be accounted for. There is no fixed trailer magic, so size growth alone is not a definitive test.

The footer path checks whether the write reported success but does not verify that it wrote all 512 bytes. A success-status short or zero write can therefore be treated as complete. The N+512 layout describes ordinary full writes, not every file counted as successful.

Why Modified Files May Keep Their Original Names

After core encryption reports success, the program increments its encrypted-file counter before attempting to rename the file. It discards rename errors, and the timing-success message can still appear. A counted file therefore need not have the build-specific suffix.

This creates several distinct forensic states:

• A file can contain transformed ranges and a complete footer but retain its original name after rename failure.
• An in-place operation can fail after earlier writes, leaving changed content without a final footer or suffix.
• A success-status nonzero short body write is not compared with the requested count, while the logical cursor still advances one MiB.
• A success-status short or zero footer write can reach rename despite incomplete recovery metadata.
• An empty eligible file can receive a 512-byte footer and the build-specific suffix under ordinary successful writes.

These paths explain why suffix counts, internal counters and the population of modified files need not agree. A responder should preserve representative unsuffixed and partially modified files rather than discarding them as unaffected.

Qilin Ransomware Indicators of Compromise

Indicator	Use
37546b811e369547c8bd631fa4399730d3bdaff635e744d83632b74f44f56cf6	Exact executable match
.gBBQsRxAcQ	Attempted build-specific suffix after core result tag 13; that status does not guarantee a complete footer or successful rename
README-RECOVER-*.txt	ransome note
README-RECOVER-*	Broader note-name hunting, requiring context
ru3q4ftbaqmpobhamqlnseorxywhhmqwhzx4pv4sqaacqz4m2ptleiid[.]onion	Embedded negotiation portal, not binary C2; do not visit
498012a0ceac56bb69ff1410c50c74e39d1296287c23e9f1385da3fc5b4e51ad	Embedded public-key correlation

Ransom Note

-- Qilin

Your network/system was encrypted.
Encrypted files have new extension.

-- Compromising and sensitive data

We have downloaded compromising and sensitive data from you system/network
If you refuse to communicate with us and we do not come to an agreementyour data will be published.
Data includes:
    - Employees personal dataCVsDLSSN.
    - Complete network map including credentials for local and remote services.
    - Financial information including clients databillsbudgetsannual reportsbank statements.
    - Complete datagrams/schemas/drawings for manufacturing in solidworks format
    - And more...

-- Warning

1) If you modify files - our decrypt software won't able to recover data
2) If you use third party software - you can damage/modify files (see item 1)
3) You need cipher key / our decrypt software to restore you files.
4) The police or authorities will not be able to help you get the cipher key. We encourage you to consider your decisions.

-- Recovery

1) Download tor browser: https://www.torproject.org/download/
2) Go to domain
3) Enter credentials


-- Credentials

Extension: gBBQsRxAcQ
Domain: ru3q4ftbaqmpobhamqlnseorxywhhmqwhzx4pv4sqaacqz4m2ptleiid[.]onion
login: 
password: 

YARA Detection Rule

The rule combines a PE header check with a threshold of implementation-specific strings, avoiding reliance on one generic crypto or Windows API name.

rule Qilin_Rust_Windows
{
    meta:
        description = "Qilin Rust Windows Encryptor and Decryptor Yara Rule"
        author      = "Dark Atlas; @ELJoOker"
        date        = "2026-09-30"

    strings:
        $s0 = "[FATAL] provide password with `--password` before start!" ascii
        $s1 = "[NOTIFICATION] 45 seconds before encrypt" ascii
        $s2 = "Traversal end's. Waiting encryption threads!" ascii
        $s3 = "/usr/src/myapp/file_encryption/src/lib.rs" ascii
        $s4 = "/usr/src/myapp/rsa/src/oaep.rs" ascii
        $s5 = "vssadmin.exe delete shadows /all /quiet" ascii
        $s6 = "struct EncryptorEmbedConfiguration with 14 elements" ascii
        $s7 = "public_rsa_pem" ascii
        $s8 = "[FATAL] Cannot parse public key" ascii

        $v0 = "encryptor/src/config/embedded_config.rs" ascii
        $v1 = "-----END CIPHERTEXT BLOCK-----" ascii
        $v2 = "[INFO|AUTO] Waiting for all encryption jobs to complete." ascii
        $v3 = "[INFO] Checking password validity" ascii
        $v4 = "[FATAL] Auto mode should not be passed directly during encryption!" ascii

        $d0 = "decryptor/src/config/embedded_config.rs" ascii
        $d1 = "[INFO|DEC] Waiting for all decryption jobs to complete." ascii
        $d2 = "[FATAL] Cannot parse private key" ascii
        $d3 = "[DEBUG|DEC] File was encrypted with ChaCha20." ascii
        $d4 = "[DEBUG|DEC] File was encrypted with AES-CTR." ascii
        $d5 = "Qilin" fullword ascii

    condition:
        uint16(0) == 0x5A4D and
        uint32(uint32(0x3c)) == 0x00004550 and
        (
            6 of ($s*) or
            (
                $s0 and $s8 and
                $v0 and
                2 of ($v1, $v2, $v3, $v4)
            ) or
            (
                $d0 and $d5 and
                3 of ($d1, $d2, $d3, $d4)
            )
        )
}

Incident Response Takeaways

The sample’s behavior supports five practical investigation priorities:

1. Check content as well as filenames. Modified files may retain their original names.
2. Inspect recovery metadata carefully. An attempted footer write does not guarantee a complete 512-byte record.
3. Review service configuration. A service may be disabled even when a stop request fails.
4. Correlate host activity. Examine shadow-copy administration alongside process interference, ransom-note creation, and rapid file changes.
5. Investigate the intrusion separately from encryption. Stolen credentials, remote-management access, and data theft may require action beyond file recovery

Conclusion

Qilin ransomware combines a customizable affiliate service with payloads deployed by different intrusion teams. Understanding the ecosystem helps explain the wider attack, while sample analysis establishes what a specific executable does.

In this Rust-based Windows sample, encryption boundaries, generated exclusions, discovery limits, and incomplete-write handling all affect the evidence left behind. A new extension or success counter cannot reliably describe the full population of modified files.

Effective investigation requires checking file contents, recovery metadata, service changes, and the access used before encryption. Those findings provide a stronger basis for assessing damage and planning recovery.