Threat Advisory: SwiftSlicer Wiper STRT-TA03

Splunk is committed to using inclusive and unbiased language. This blog post might contain terminology that we no longer use. For more information on our updated terminology and our stance on biased language, please visit our blog post. We appreciate your understanding as we work towards making our community more inclusive for everyone.

The ongoing geo-political crisis in Eastern Europe continues to be the scenario of deployment of a variety of payloads linked to information stealing and data/network destruction. The deployment of these payloads has been associated or contingent with Military actions as Microsoft and ESET have observed in some of their publications. These campaigns have targeted critical infrastructure affecting civilian populations in addition to  military targets.

There was an increase in attacks over the winter season, bringing some new payloads consistent with the objective of stealing information and destroying targeted data and network altogether. That is the case of SwiftSlicer wiper, a new payload discovered by ESET and found in a recent January 2023 campaign. This payload was deployed via Microsoft Active Directory, Group Policy Object (GPO). 

Microsoft Active Directory GPOs are mechanisms to manage and deploy artifacts within joined computers. GPOs are commonly used as system administrators' primary tools of deploying configuration changes, software upgrades, security settings, and security policies. Actors abuse these features by deploying malicious payload via GPO and then forcing execution at the client level. The traits of this malicious payload include:

• Written in Golang programming language (versatile to run cross-platforms)
• Recursive encryption and deletion of host files
• Targeting NTDS (AD Database & Replication) objects to render entire AD network destroyed
• Deletion of all local system backups and snapshots (via shadowcopy)
• Forces reboot

The Splunk Threat Research Team (STRT) has developed an analytic story focused on this new destructive payload. The analysis, detections, and mitigation measures are all outlined below. 

Analysis

SwiftSlicer starts its code by retrieving the system directory file path or CSIDL_SYSTEM and the root drive to locate the first two targeted folders which are the CSIDL_SYSTEM\drivers and C:\Windows\NTDS to start the wipe process.

Figure 1.1 shows the entry point code of SwiftSlicer where its initializes the systemdirectory, root drive and the CSIDL_SYSTEM\drivers folder path for its destructive payload .

Figure 1.2 shows the initialization of the C:\Windows\NTDS where it will enumerate files to wipe.

Before it wipes all the files, it gets its process token information and adjusts its token privileges. Figure 2 shows its “enableDisableProcessPrivilege function” that can enable or disable its process token privileges.

^{Figure 3}

As part of its destructive payload, it will delete the “shadowcopy”, also known as the Volume Snapshot Service (VSS), in the targeted machine to delete all the backup copies or snapshots of computer files or volumes. Figure 3 shows the code used to set up the command “wmic delete shadowcopy” to delete the VSS files.

^{Figure 4}

Then it will execute  “main_wipe function” to corrupt or wipe all the files, even executable that makes the targeted host inoperable.This malicious wiper overwrites the files with a random generated string to make it unrecoverable. Figure 4 shows the code snippet of SwiftSlicer malware that opens the file it wants to overwrite and executes the main_wipe function to wipe it.

Figure 5 is the code snippet of main_wipe function that generates a random string buffer that will be used to overwrite files in the targeted host.

^{Figure 5}

Lastly, it will force reboot of the compromised host using ExitWindowsEx Windows API. The code implementation of the force reboot instruction can be seen in Figure 6.

^{Figure 6}

As an example of our testing, Figure 7.1 shows us a short procmon event captured during the execution of SwiftSlicer wiper malware that catches the File Write Event while it overwrites the afunix.sys in the compromised host with random generated strings.

^{Figure 7.1}

Figure 7.2 shows what the corrupted file looks like after the infection. We can see how the afunix.sys driver was overwritten by a random generated string with 4096 bytes per each block.

^{Figure 7.2}

Detections

Windows Data Destruction Recursive Exec Files Deletion

This analytic identifies a suspicious process recursively deleting files in a compromised host. It can also catch a possible recursive file overwrite on multiple files using Sysmon Event 23. Sysmon treats the modified or overwritten file as a deleted one as soon as it was overwritten.

`sysmon` EventCode=23  TargetFilename IN ("*.exe", "*.sys", "*.dll") 
  | bin _time span=2m  
  | stats values(TargetFilename) as deleted_files min(_time) as firstTime max(_time) as lastTime count by Computer user EventCode Image ProcessID 
  | where count >=500 
  | `security_content_ctime(firstTime)` 
  | `security_content_ctime(lastTime)`

^{Figure 8} 

Mitigation

This payload targets Microsoft Operating Systems. The following links share specific mitigation strategies for these types of attacks:

• Splunk Ransomware Detection Content
• Splunk Content Pack for Windows Dashboards and Reports 
• Ransomware as a service: Understanding the cybercrime gig economy and how to protect yourself (Microsoft)
• CISA. How can I protect against ransomware? 

Why Should You Care?

The use of these payloads quickly gets implemented, replicated or adapted to other payloads and techniques reused by other groups. In some instances, collateral damage from these campaigns may affect organizations or third party networks outside or neutral to this conflict. It is important to prepare in case your organization is exposed to these threats. 

Please visit research.splunk.com for more information. 

Learn More

You can find the latest content and security analytic stories on GitHub and in Splunkbase. Splunk Security Essentials also has all these detections available via push update. 

For a full list of security content, check out the release notes on Splunk Docs.

Feedback

Any feedback or requests? Feel free to put in an issue on GitHub and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions if you need an invitation to our Splunk user groups on Slack.

Contributors

We would like to thank Teoderick Contreras and Rod Soto for authoring this post and the entire Splunk Threat Research Team (Michael Haag, Mauricio Velazco, Lou Stella, Bhavin Patel, Eric McGinnis, and Patrick Bareiss) for their contribution to this release.