Threat Update: AwfulShred Script Wiper

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 Splunk Threat Research Team (STRT) continues to analyze and produce content related to the ongoing geopolitical conflict in eastern Europe where new variances of destructive payloads are being released, targeting government and civilian infrastructure. The sole purpose of these destructive payloads is to decimate infrastructure; there is no ransom or alternative presented, and they need to be addressed as soon as they are detected. These new payload variants, like AwfulShred which targets Linux, speak of an adversary with an inventory of weapons that cater to diverse infrastructures in order to cause widespread or total damage. 

Indicators by other industry organizations present a scenario where these types of payloads may be used against NATO partners and indirectly related organizations or states involved in this conflict. This scenario is to be expected as these destructive payloads are released in the field and the geopolitical conflict escalates. According to some industry publications, these payloads are being spearheaded by a specific RU related government entity. 

Below are some of the STRT findings on this  Linux targeted destructive payload AwfulShred. 

Analysis

Bash Version and Linux Release Checking

This Linux shell script wiper checks bash script version, Linux kernel name and release version before further execution. Based on the reviewed sample, the bash version AwfulShred needs to continue its code is base version 3. 

Using the “uname -s” and “uname –kernel-release”  to retrieve the kernel name and the Linux kernel release version. Figure 1 shows its code, how it checks if the kernel name is “Linux” and the kernel release version must be greater than or equal to 2.6.27.

^{Figure 1}

Shred Files

In each mounted disk, Awfulshred enumerates and wipes each found file using the shred utility. Figure 2 shows the code screenshot of how it executes shred with specific parameters to wipe files.

^{Figure 2}

Service Stop

AwfulShred will also try to stop and delete unit configuration files related to apache, http and ssh services.

Figure 3 shows the functions of AwfulShred wiper that execute “systemctl stop” and “systemctl disable”  to stop and disable all the targeted services in the compromised host. It also calls another function to delete “.service” configuration files related to apache, http and ssh services.

^{Figure 3}

Delete Critical Folders

Figure 4 shows the code block of AwfulShred that deletes files and directories in /boot, /home and /var/log folder. The “rm -rf <folder path> –no-preserve-root” command can wipe all the file systems in the targeted folder, especially the critical /boot folder that makes the compromised host in-operable after the reboot.

^{Figure 4}

Clear History and Caches

As part of its destructive payload, AwfulShred clears the history of the compromised host by executing “history -c”  and disables the usage of history executing “set +o history” and by setting environment variables HISTSIZE, HISTFILESIZE to 0 . Figure 5 shows the code function that turns off the swapping of paging devices using the “swapoff” command and clearing the cache using /proc/sys/vm/drop_cache kernel system request..

^{Figure 5}

Magic System Request Key for Reboot

Lastly, after all the wiping and payloads of this malicious script, AwfulShred reboots the compromised host using the system request kernel object. Figure 6 shows the 2 lines of code that enable all the functions of sysrq (“echo 1> /proc/sys/kernel/sysrq”) and reboot (“echo b > /proc/sysrq-trigger”) the compromised host that makes it inoperable after the restart.

^{Figure 6}

Detections 

The Splunk Threat Research Team has curated relevant detections and tagged them to the AwfulShred Analytic Story to help security analysts detect adversaries leveraging the AwfulShred malware. 

For this release, we used and considered relevant data endpoint telemetry sources such as:

• Process Execution & Command Line Logging in Linux (Sysmon Linux)

Below is the list of new analytics to detect AwfulShred TTP’s.

Linux Data Destruction Command

This analytic identifies a Unix shell command that can wipe root folders of a Linux host. This commandline is being abused by Awfulshred malware that wipes or corrupts files in a targeted Linux host. The shell command uses the rm command with force recursive deletion even in the root folder.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes 
 where Processes.process_name = "rm"  AND Processes.process IN ("* -rf*", "* -fr*") AND Processes.process = "* --no-preserve-root" 
 by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.process Processes.process_id
 Processes.parent_process_id Processes.process_guid 
 | `drop_dm_object_name(Processes)` 
 | `security_content_ctime(firstTime)` 

Linux Hardware Addition SwapOff

This analytic looks for process execution to disable the swapping of paging devices. This technique was seen in AwfulShred malware that disables the swapping of the specified devices and files. 

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes 
  where Processes.process_name = "swapoff"  
  by Processes.dest Processes.user Processes.parent_process_name
Processes.process_name Processes.process Processes.process_id 
  Processes.parent_process_id Processes.process_guid 
 | `drop_dm_object_name(Processes)` 
 | `security_content_ctime(firstTime)`

Linux Impair Defenses Process Kill

This analytic looks for PKILL process execution for possible termination of process. This technique is being used by several threat actors, adversaries and red teams to terminate processes in a targeted Linux machine. 

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes 
  where Processes.process_name IN ( "pgrep", "pkill") Processes.process = "*pkill *"
  by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.process Processes.process_id 
 Processes.parent_process_id Processes.process_guid 
 | `drop_dm_object_name(Processes)` 
 | `security_content_ctime(firstTime)`

Linux Indicator Removal Clear Cache

This analytic looks for processes that clear or free page cache in Linux system hosts. This technique was seen in AwfulShred malware wiper that tries to clear the cache using kernel system request drop_caches while wiping all files in the targeted host.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes 
  where Processes.process_name IN ("dash", "sudo", "bash")  AND Processes.process  IN("* echo 3 > *", "* echo 2 > *","* echo 1 > *") AND Processes.process = "*/proc/sys/vm/drop_caches"
  by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.process Processes.process_id 
  Processes.parent_process_id Processes.process_guid 
  | `drop_dm_object_name(Processes)` 
  | `security_content_ctime(firstTime)`

Linux Indicator Removal Service File Deletion

This analytic looks for suspicious Linux processes that delete service unit configuration files. This technique has been observed in several payloads that delete service configuration files to corrupt operating system services or security products as part of its defense evasion. 

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes 
  where Processes.process_name = "rm"  AND Processes.process = "*rm *"  AND Processes.process = "*.service"
  by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.process Processes.process_id 
  Processes.parent_process_id Processes.process_guid 
  | `drop_dm_object_name(Processes)` 
  | `security_content_ctime(firstTime)`

Linux System Reboot Via System Request Key

This analytic looks for possible execution of SysReq hack to reboot the Linux system host.

This technique was seen in AwfulShred malware wiper to reboot the compromised host by using the Linux magic sysrq key. This kernel configuration can trigger reboot by piping out 'b' to /proc/sysrq-trigger after enabling all the functions of sysrq. 

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes 
  where Processes.process_name IN ("dash", "sudo", "bash")  Processes.process =  "* echo b > *" Processes.process = "*/proc/sysrq-trigger"
  by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.process Processes.process_id 
  Processes.parent_process_id Processes.process_guid 
  | `drop_dm_object_name(Processes)` 
  | `security_content_ctime(firstTime)`

Linux Unix Shell Enable All SysRq Functions

This analytic looks for possible execution of SysReq hack to enable all functions of kernel system requests of the Linux system host. This technique was seen in AwfulShred malware wiper rebooting the compromised host by using the Linux magic sysrq key. 

This kernel configuration can be triggered by piping out bitmask '1' to /proc/sys/kernel/sysrq.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes 
  where Processes.process_name IN ("dash", "sudo", "bash")  Processes.process =  "* echo 1 > *" Processes.process = "*/proc/sys/kernel/sysrq"
  by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.process Processes.process_id 
  Processes.parent_process_id Processes.process_guid 
  | `drop_dm_object_name(Processes)` 
  | `security_content_ctime(firstTime)`

This AwfulShred analytic story introduces 13 detections across MITRE ATT&CK techniques.

To see the full list of analytics created, check out the analytic story here.

Why Should You Care?

As outlined in this threat update, the development and evolution of these types of destructive payloads becomes new ammunition to criminals that will implement these new techniques in their exploit techniques or frameworks. Once these types of techniques are revealed, they can be defended against. However, this also indicates that would-be criminals are likely developing new exploits incorporating such techniques. 

It is important to be prepared against these threats and be ready to react in the event of an attack. Please visit research.splunk.com and the CISA Shields UP! page for more guidance.

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.