An Underrated Technique to Delete Volume Shadow Copies - DeviceIoControl

An Underrated Technique to Delete Volume Shadow Copies - DeviceIoControl

Picus Labs has updated the Picus Threat Library with a relatively new method used by attackers to delete Volume Shadow Copies.

To prevent the recovery of a corrupted system, adversaries delete built-in operating system data and turn off services designed to help recover, and this adversary behavior is listed as the T1490 Inhibit System Recovery technique in the MITRE ATT&CK framework under the Impact tactic [1].

One of the most used methods to implement this technique is deleting volume shadow copies; a typical ransomware behavior used to prevent the recovery of encrypted files from volume shadow copies.

Adversaries use various procedures to delete volume shadow copies. The well-known methods are:

1. wmic:  wmic.exe  is a command-line utility to access Windows Management Instrumentation (WMI), which is the infrastructure for management data and operations on Windows-based operating systems. You can write WMI scripts or applications to automate administrative tasks on remote computers. Ransomware threat actors like Nefilim use a simple WMIC command to delete shadow copies [2]:

wmic shadowcopy delete /nointeractive

Picus users can use the following atomic attack in the Picus Threat Library to emulate this method:

Picus ID

Threat Name

Action ID

Action Name

205796

Inhibit System Recovery by Deleting All Volume Shadow Copies with wmic

11269

Delete Shadow Copy using Windows Management Instrumentation (WMI)

This method is also a part of the following attack scenarios in the Picus Threat Library:

Picus ID

Threat Name

390945

Maze Ransomware Malware Scenario

321223

GandCrab Malware Attack Scenario

647501

Trickbot Banking Malware Attack Scenario

2. vssadmin (Volume Shadow Copy Service Admin): vssadmin.exe is a native Windows tool that can display current volume shadow copy backups and all installed shadow copy writers and providers. It is also capable of deleting volume shadow copies. This feature is abused by ransomware groups like Sodinokibi with the following command [3]:

vssadmin.exe Delete Shadows /All /Quiet

Picus users can use the following atomic attack in the Picus Threat Library to emulate this method:

Picus ID

Threat Name

Action ID

Action Name

573481

Inhibit System Recovery by Deleting All Volume Shadow Copies with Vssadmin

11268

Delete Shadow Copy using Vssadmin

This method is also a part of the following attack scenarios in the Picus Threat Library:

Picus ID

Threat Name

409979

Hermes Ransomware Attack Scenario

571986

Scarab Ransomware Attack Scenario

638708

CoronaVirus Ransomware Malware Scenario

3. PowerShell is also capable of deleting volume shadow copies via VMI. PowerShell’s Get-WmiObject cmdlet can access WMI access and runs WMI’s Win32_ShadowCopy class to delete volume shadow copies. For example, the NetWalker ransomware use the following PowerShell command to inhibit system recovery:

Get-WmiObject Win32_Shadowcopy | ForEach-Object {$_.Delete();}

Picus users can use the following atomic attack in the Picus Threat Library to emulate this method:

Action ID

Action Name

12160

Delete Shadow Copy using Powershell

This method is also a part of the following attack scenarios in the Picus Threat Library:

Picus ID

Threat Name

655212

Darkside Ransomware Scenario

636545

Netwalker Ransomware Malware Scenario

4. A relatively new method used by attackers to inhibit Volume Shadow Copies from being used for system recovery is resizing the maximum amount of storage space that can be used for shadow copy storage. Using this method, adversaries decrease the allocated storage for snapshots of Volume Shadow Copies; the minimum possible size is 320MB. If the existing snapshots exceed the size of the newly resized diff area, they are deleted by the system to free up space, so this feature can also be used to delete existing snapshots of volume shadow copies.

vssadmin can be used to resize shadow copy storage. For example, the Hakbit ransomware uses the following command to resize the allocated space for shadow copies as 401 MB:

vssadmin resize shadowstorage /for=c: /on=c: /maxsize=401MB

Volume Shadow Copy Service (VSS) relies on a device driver waiting for control codes. Another method to resize the shadow storage is directly accessing this driver by using the device IO control calls to the driver.  DeviceIoControl() function can be used for this method. The control call  that is used to resize the storage size is IOCTL_VOLSNAP_SET_MAX_DIFF_AREA_SIZE. The hex value of this control code is 0x53c028, which means the device type is 0x53, the function code is 0xa, the method is 0x0 METHOD_BUFFERED, and  the access is Read and Write.

Adversaries realized that this control call is capable of setting a maximum storage size for Volume Shadow Copy snapshots and started to use it in their malware. Picus Labs’ Red Team updated Picus Threat Library for that direct device access method to delete volume shadow copies.

Picus users can use the following atomic attack in the Picus Threat Library to emulate this method:

Picus ID

Threat Name

Action ID

Action Name

253727

Inhibit System Recovery by Deleting All Volume Shadow Copies with DeviceIoControl

12607

Delete Shadow Copy using DeviceIoControl

References

[1]  https://attack.mitre.org/techniques/T1490/

[2] https://www.picussecurity.com/resource/blog/how-to-beat-nefilim-ransomware-attacks

[3] https://www.picussecurity.com/resource/blog/a-brief-history-and-further-technical-analysis-of-sodinokibi-ransomware