{
	"id": "ae6f5269-5a8c-41df-bb41-65dc842d7b98",
	"created_at": "2026-04-06T00:10:46.251013Z",
	"updated_at": "2026-04-10T03:20:41.406003Z",
	"deleted_at": null,
	"sha1_hash": "f6214374cef7ddf317aebbb84c3423fe8f3386a7",
	"title": "Threat Report: Illuminating Volume Shadow Deletion",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 650348,
	"plain_text": "Threat Report: Illuminating Volume Shadow Deletion\r\nBy Dana Behling\r\nPublished: 2022-09-20 · Archived: 2026-04-05 19:12:26 UTC\r\nExecutive Summary \r\nRansomware is one of the greatest threats to all industries. Threat actors have the ability to severely hinder, or\r\ndestroy, the operations of organizations that range from small non-profits to global corporations. While there are\r\nmany research studies on ransomware, this paper will describe specifically its method of destroying a form of\r\nWindows data backups called Volume Shadows. Specifically, this paper will describe a new method discovered in\r\nthe wild that can bypass many forms of detection and prevention. \r\nIntroduction \r\nThe trillion-dollar ransomware market continues to grow, evolve, and affect every industry around the world. The\r\nattackers’ goal is simple: prevent access to data using numerous methods to ensure that data is inaccessible until a\r\ndesired ransom is paid. While most ransomware detection techniques focus heavily on methods of data\r\nencryption, which normally follows a narrow set of techniques, the techniques that ransomware uses to prevent\r\nrestoration from backups and thwart system recovery are equally important and often receive less attention.\r\nSecurity practitioners continue to stress the importance of backups, and at the same time malicious actors are\r\ninventing new ways to inhibit system recovery. Some of the first tactics ever identified are still in use today.  \r\nAs part of a large-scale ransomware threat analysis, the VMware Threat Analysis Unit (TAU) identifies and\r\ncatalogs the various techniques that impact data recovery on compromised endpoints. One of the most well-known\r\nmethods is the deletion of Windows Volume Shadow Copies. The Volume Shadow Copy Solution (VSS) was\r\nintroduced with Windows Server® 2003 and on user systems with Windows XP.  It solved two critical needs. One,\r\nit allowed backup of data while it was in use, and two, it allowed the backup of data that was otherwise too large\r\nto backup all at once. This is possible because rather than make a one-time exact copy of the data, VSS monitors\r\nand records changes to data, and by tracking these changes, it can produce copies of files and system settings.\r\nKnown by users as the “Previous Versions” feature, this built in VSS quickly became and continues to be a part of\r\nindividual and corporate backup strategies. \r\nCommonly accepted as one of the first modern-day ransomware, CryptoLocker emerged in 2013 spreading\r\nthrough the Zeus Banking Trojan.  It encrypted files and requested amounts such as $100 and $300 from victims\r\nfor decryption.  In its very first iteration this ransomware did not delete volume shadow copies (VSCs), so a\r\ncommon recovery solution performed by victims was to remove the ransomware from the system and then restore\r\nit from a known-good VSC. The ransomware actors learned quickly and as expected, this loophole was closed in a\r\nmatter of months with new variants that deleted all VSCs. Since then, almost all ransomware deletes VSCs and\r\nuses other techniques to prohibit system recovery. \r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 1 of 17\n\nThree Categories of VSC Deletion Techniques \r\n1. Use of native Windows binaries (Living Off the Land binaries or LOLbins) \r\n2. Scripting which uses objects available in the language (WQL, PowerShell, VBS) \r\n3. COM object interactions  \r\nUse of living off the land binaries is by far both the simplest and most observed technique, closely followed by the\r\nuse of objects in scripting languages. These first two categories of techniques are easily observable because in\r\nmost cases, even if obfuscated, they must eventually be interpreted as text that their perspective interfaces or\r\ninterpreters can understand. Markedly different from the first two categories is the direct manipulation of COM\r\nobjects. Techniques that use COM to modify VSCs are far more sophisticated, which makes them both more\r\ndifficult to detect and more difficult to write.  On both fronts these techniques require a significantly deeper\r\nknowledge of Windows internals including a good understanding of COM.     \r\nThis paper provides an overview of techniques in all three of these categories that delete VSCs and reveals a new\r\nVSS COM object technique for deleting volume shadow copies that was recently discovered in ransomware in the\r\nwild. To understand the technique, it helps to have a high-level understanding of the VSS and COM. \r\nBasics of Volume Shadow Copies \r\nFour Components of Volume Shadow Copy Solution \r\nVolume Shadow Copy Service (VSS) – coordinates the actions of the other components listed here \r\nVSS Requestor – applications that request actions on one or more shadow copies; most commonly this is a\r\nbackup application \r\nVSS Writer – enumerates and tracks the state changes of data tagged for backup, including locations.\r\nNumerous VSS Writers are provided for enumerating data required by Windows features.1  \r\nVSS System Provider – commonly referred to as “providers”, these know about both copies of the data\r\nthe original and the backup and interact with hardware.  This is the only component that can also be\r\nimplemented in hardware. \r\nFigure 1: Architectural Diagram of Volume Shadow Copy Service (Microsoft, 2021) \r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 2 of 17\n\nOperational Flow of Volume Shadow Copy Service \r\nAn example volume shadow copy creation starts with a VSS Requester asking the VSS Coordinator for a list of all\r\nthe VSS Writers available.  Generally, each writer returned represents data associated with a specific Windows\r\nfeature. Some examples of VSS Writers include a Registry Writer, Task Scheduler Writer, and File Replication\r\nService Writer.  As requested by the VSS Coordinator, each of the available VSS Writers provides details about its\r\ndata, which the VSS Coordinator then sends to the VSS Requestor, who selects which data to backup.  The VSS\r\nthen notifies the appropriate VSS Writers to prepare their data for making a shadow copy.  After all preparations\r\nhave been completed by the VSS Writers the VSS Coordinator is notified, who then requests that the VSS Writers\r\nfreeze changes to their data.  Once the VSS Coordinator is notified that the VSS Writers’ data is frozen, the VSS\r\nSystem Providers is notified to make the Volume Shadow Copy.  On completion, the VSS Provider notifies the\r\nVSS Coordinator, who in turn notifies the VSS Writers that the freeze can be lifted. If everything goes smoothly,\r\nthe location of the volume shadow copy is then provided to the VSS Requestor. \r\nSystem Restore Points Versus Volume Shadow Copies \r\nRestore points are also an option of the Volume Shadow Copy Solution, and both Restore Points and Volume\r\nShadow Copies are native features built into Windows. While both are handled by the in-box Volume Shadow\r\nCopy Service, there is an important difference. System Restore points do not backup user data (i.e., anything is the\r\n“Users” folders).  As the word “System” in the name “System Restore” implies these backups record\r\nconfiguration changes to the operating system and its applications.  Volume Shadow Copies on the other hand\r\nbackup both system configurations and user data.  The difference between Volume Shadow Copies and System\r\nRestore Points illustrates how configurable the Volume Shadow Copy Solution can be. It all comes down to which\r\nof the VSS Writers are selected by the VSS Requestor.   \r\nVSC Management with Windows Utilities \r\nThe VSS is a native Windows service, so Microsoft provides convenience utilities for interacting and managing\r\nshadow copies.  While they do see regular use by network administrators the world over, it is hardly surprising to\r\nfind that these same utilities are also abused by ransomware to delete or deny access to VSCs.  Many ransomware\r\nuse more than one to make certain that VSCs are not available for data recovery.  The table below provides a list\r\nof some of the more common utilities.  \r\nTable 1: Windows Utilities for VSCs \r\nUtility  Description \r\nvssadmin.exe  Provides functionality to list, delete, and resize VSCs. \r\nwmic\r\nshadowcopy  \r\nThe shadowcopy command under the Windows Management Instrumentation Command\r\nline (WMIC) or wmic.exe allows for the creation, deletion and listing of VSCs. \r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 3 of 17\n\nwbadmin.exe \r\nCreates a one time or scheduled Volume Shadow Copy where changes are not tracked or\r\nsaved. Can create, list, delete VSCs. This command uses the keyword “catalog” to refer to\r\nVSCs.  \r\nbcdedit.exe \r\nThe BCD in bcdedit.exe is short for Boot Configuration Data. This utility has many\r\noptions, but ransomware primarily uses it to prevent automatic recovery from VSCs.  \r\nNative Windows Binaries for VSC Deletion \r\nIn ransomware, the most common method of deleting VSCs is to use tools resident on the system, otherwise\r\nknown as Living Off the Land binaries (LOLbins), and the most common of these by far is the LOLbin\r\nvssadmin.exe. The behavior and available options of vssadmin.exe may vary depending on the version of\r\nWindows or if running these commands on a server version, but in general it provides the ability to show details\r\nabout most VSS objects and resize or delete VSCs. \r\nFigure 2: Available vssadmin Commands \r\nExample usage that loops over each volume deleting the VSCs associated with each. \r\nvssadmin delete shadows /for=\u003cForVolumeSpec\u003e [/oldest | /all | /shadow=\u003cShadowID\u003e] [/quiet]\r\nCommand 1: vssadmin delete shadows \r\nAnother way to abuse the vssadmin command is to resize the volume shadow copy storage to anything smaller\r\nthan its currently used space.  This leaves malware authors with the choice of guessing the VSC used space,\r\nsimply picking a small value and hoping it deletes the VSCs, or adding functionality to determine the actual used\r\nspace.  One way to get the amount of space currently used by the VSC is to run the below command. \r\nvssadmin list shadowstorage\r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 4 of 17\n\nCommand 2: vssadmin list shadowstorage \r\nTo achieve a resize deletion the malware authors need to set the maxsize parameter to any value less than what is\r\ncurrently used. According to Microsoft, the minimum value allowed for allocation by the maxsize parameter is\r\n1MB2, so it follows that setting maxsize to 1MB should have the best chance of deleting the VSCs.  \r\nvssadmin resize shadowstorage /for=\u003cForVolumeSpec\u003e /on=\u003cForVolumeSpec\u003e /maxsize=1MB\r\nCommand 3: vssadmin resize shadowstorage \r\nVSSADMIN Used in DarkGate Ransomware \r\nThe DarkGate ransomware written in Delphi takes full advantage of those unfortunate enough to become infected\r\nby not only encrypting files and adds insult to injury by using the infected systems to mine cryptocurrency. If\r\nthat’s not enough, it also has the capability to download and execute additional payloads that can steal crypto\r\nwallets or gain complete control of the system. The below image is taken from DarkGate and shows the vssadmin\r\ncommand being passed to the command prompt to delete the volume shadow copies. \r\nFigure 3: Example of vssadmin in 10bfaeb0c00425c4749140d5c7d9f3d88537cf2f621ba7af5322b15cf205b896 \r\nVSSADMIN Resize ShadowStorage Used by Conti \r\nIn a 2020 version of the now notorious Conti ransomware, the vssadmin resize technique is used. The choice to set\r\nthe maxsize to 401MB is interesting for the value selected. Popular consensus at the time was that the number was\r\npicked by the author at random.  \r\nvssadmin Delete Shadows /all /quiet\r\nvssadmin resize shadowstorage /for=c: /on=c: /maxsize=401MB\r\nvssadmin resize shadowstorage /for=c: /on=c: /maxsize=unbounded\r\nvssadmin resize shadowstorage /for=d: /on=d: /maxsize=401MB\r\nvssadmin resize shadowstorage /for=d: /on=d: /maxsize=unbounded\r\nvssadmin resize shadowstorage /for=e: /on=e: /maxsize=401MB\r\nvssadmin resize shadowstorage /for=e: /on=e: /maxsize=unbounded\r\nvssadmin resize shadowstorage /for=f: /on=f: /maxsize=401MB\r\nvssadmin resize shadowstorage /for=f: /on=f: /maxsize=unbounded\r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 5 of 17\n\nvssadmin resize shadowstorage /for=g: /on=g: /maxsize=401MB\r\nvssadmin resize shadowstorage /for=g: /on=g: /maxsize=unbounded\r\nvssadmin resize shadowstorage /for=h: /on=h: /maxsize=401MB\r\nvssadmin resize shadowstorage /for=h: /on=h: /maxsize=unbounded\r\nFigure 4: Example of vssadmin in eae876886f19ba384f55778634a35a1d975414e83f22f6111e3e792f706301fe \r\nVSSADMIN \u0026 WMIC Used in MSILZilla (.NET Ransomware) \r\nMSILZilla ransomware was originally written in one of the Microsoft .NET languages (C#, F# or Visual Basic)\r\nand compiled into MicroSoft Intermediate Language (MSIL).   MSIL is a CPU-independent set of instructions\r\nthat can be efficiently converted to native code usually at runtime by the .NET just-in-time (JIT) compiler. \r\nAlthough an exhaustive study was not made on the topic, experience shows that there are numerous named MSIL\r\nransomware circulating. One recently in the news is Chaos, but the .NET ransomware legacy can be traced back to\r\nat least 2016. \r\nFigure 5: Example of vssadmin and wmic in\r\n390f6c71817dcf576d2b59878684ff46a78e2292fdd60df090b77730206a537a \r\nThe above screenshot not only shows hints of a Kaspersky masquerade, but the death blow to this system’s VSCs.\r\nThe ransomware sample is shown running the command, “vssadmin delete shadows /all /quiet \u0026\u0026 wmic\r\nshadowcopy delete”.  The first part of this two-part command that is separated by double-ampersands uses the\r\nWindows vssadmin utility to delete all shadow copies and suppresses any user feedback.  Then, the second part\r\nmakes doubly sure the VSCs are deleted by running “wmic shadowcopy delete”, which achieves the same\r\noutcome through different means. If this doesn’t seem quite right, it’s because it contains an error.  The double-ampersands should be replaced either with a single-ampersand or double-vertical bar.  The single ampersand will\r\nrun the wmic part of the command regardless of the outcome of the vssadmin command, and the double-vertical\r\nbar would run the wmic command only if the vssadmin part of the command fails.  While looking at methods of\r\nVSC deletion, it was common to see these two commands used together.  They were usually separated by a single\r\nampersand. \r\nWMIC SHADOWCOPY \r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 6 of 17\n\nWMIC is short for Windows Management Instrumentation Command Line. As the name suggests it is a command\r\nline utility that is part of the larger Windows Management Instrumentation (WMI) infrastructure.  WMI, and on a\r\nsmaller scale WMIC, provides tools for the automation and remote administration of distributed systems.  A\r\nrelatively small part of this is the management of volume shadow copies. As shown below, the wmic shadowcopy\r\ncommand provides a robust set of options for interacting with volume shadow copies. \r\nFigure 6: WMIC Shadowcopy Commands \r\nThe simple three-word command to delete all shadow copies with WMIC is shown here.  The default is to delete\r\nall shadow copies; the easiest way to delete a single VSC using WMIC is to type WMIC in an administrator\r\nprivileged command prompt, which will enable WMIC interactive mode. In this mode typing “shadowcopy\r\ndelete” will prompt the user about the deletion of individual VSCs.  Outside of interactive mode, there is no\r\nprompt, and all shadow copies are deleted. \r\nwmic SHADOWCOPY DELETE\r\nCommand 4: The wmic shadowcopy delete command \r\nWMIC SHADOWCOPY Delete Used in Wana Decrypt0r 2.0  \r\nThe confusingly named Wana Decrypt0r 2.0 also uses a very conservative approach; as shown, the command calls\r\nnot only vssadmin to delete shadows, but also wmic shadowcopy delete. Then, just to hamper recovery further,\r\nbcdedit is called to prevent automatic recovery from the VSCs that were presumably already deleted.  \r\nWana Decrypt0r 2.0 is an ancestor of WannaCry, which wormed its way around the world starting in 2017 using\r\nthe EternalBlue SMB exploit.  The large number of variants associated with this Wana Decrypt0r 2.0 can be\r\nattributed in part to a ransomware generator.  This program, Aron WanaCryptor 2.0 Generator v1.0, allows\r\nenterprising criminals to customize the WannaCry lock screen text, images, and colors.  For this reason, there are\r\nmany variants of this ransomware that are functionally identical, but given new names based on the text from the\r\nransom window. \r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 7 of 17\n\nFigure 7: Use of vssadmin and wmic shadowcopy in\r\nb9c5d4339809e0ad9a00d4d3dd26fdf44a32819a54abf846bb9b560d81391c25 \r\nWMIC SHADOWCOPY Used in Somhoveran  \r\nKnown for being distributed on Discord’s content delivery network under the guise of game related hacks or\r\ncheats, the Somhoveran ransomware arrives as a self-extracting archive, which runs a batch script to kick off a\r\n.NET (MSIL) file that ultimately locks the user out of their own desktop.  To add insult to injury a countdown\r\ntimer is displayed to pressure those affected to pay the ransom promptly. \r\nFigure 8: Use of vssadmin and wmic shadowcopy\r\nin31dfd40951e006b0a2f2fa439d4bbb37db01120478155d48b533453676e71073 \r\nScripting Objects Used for VSC Deletion \r\nInteracting with VSC using Windows utilities is without question the most straight forward method to delete\r\nshadow copies, but it is also very well-known, and detectable by security projects.  By using objects available in\r\nscripting languages like PowerShell, VBScript or Python, actors can achieve the same outcome, with minimal\r\nadditional effort, and gain some anonymity in the operating system.    \r\nPowerShell Script with WMI to Delete VSCs \r\nThe WMI command line utility isn’t the only way to use WMI to delete volume shadow copies.  From a\r\nransomware authors’ perspective, it could be beneficial to avoid the use of command line tools like wmic.exe, as\r\ncalls to this and similar can be easily monitored by security products.  To hide in the noise of corporate network\r\nenvironments ransomware can use cmdlets in PowerShell to delete VSCs.  As shown here, with just a simple for-loop, PowerShell can make quick work of all the VSCs. \r\nGet-WmiObject Win32_Shadowcopy | ForEach-Object{$_.Delete();} \r\nCommand 5: One Line PowerShell Script to Delete VSCs \r\nPowerShell Script with WMI Used in Anchor \r\nAnchor is publicly attributed to the Trickbot group whose toolkit started out primarily with banking trojans and\r\nlater branched into multiple ransomware tools. Like the other examples described, Anchor uses multiple methods\r\nto delete VSCs including a call to PowerShell that uses WMI to delete shadow copies. \r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 8 of 17\n\nFigure 9: PowerShell Script to Delete VSCs in\r\ne26b2ffb2ee711fc7b04d62911580560794ee4fa9b7fcfade65ee6ff2eed0274 \r\nPowerShell with WMI Used in BlackSun Ransomware  \r\nImplemented entirely in PowerShell, BlackSun is an all-in-one ransomware, which arrives with all its\r\nfunctionality and does not download or load additional payloads.  Part of the prepacked functionality deletes the\r\nshadow copies as shown here in the author named function, “DoCleanShadows”. \r\nFigure 10: PowerShell Scrip to Delete VSCs in\r\n8de8134635cfbbf3cda763208262ceb07633d65f394e0395abf0c543c4d7f76b \r\nVBScript and Python Use WMI to Delete Shadow Copies \r\nUnlike PowerShell VBScript doesn’t have a built-in object for interacting directly with VSCs.  The below\r\nexample script goes back to at least 2016, and while it still works, it has fallen out of favor in newer ransomware\r\nsamples, it was popular at the dawn of the modern ransomware age, when criminal groups began to adopt\r\nransomware as a business model.  In the below example, VBScript retrieves a handle to WMI and then uses that\r\nhandle to invoke the WQL3 request, “Select * From Win32_ShadowCopy”.  The For Each loop then deletes each\r\nVSC. A very similar script can be written in Python or other scripting languages where an interface to WMI is\r\nprovided. \r\nstrComputer = “.”\r\nSet objWMIService = GetObject(“winmgmts:\\\\” \u0026 strComputer \u0026 “\\root\\cimv2”)\r\nSet colItems = objWMIService.ExecQuery(“Select * From Win32_ShadowCopy”)\r\nFor Each objItem in colItems\r\nobjItem.Delete_\r\nNext\r\nCommand 6: VBScript for Volume Shadow Deletion \r\nComponent Object Model (COM) for VSC Deletion \r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 9 of 17\n\nInteracting with Windows COM objects is not new in malware.  As covered soon, without the layer of Windows\r\nPrivileges on the proverbial COM cake, COM allows direct access to the operating system’s underlying\r\ncomponent objects.  This low-level direct access combined with the difficulty of differentiating malicious\r\nbehavior from bona fide behavior make COM an attractive vector to achieve malicious goals. This includes COM\r\ntechniques for deleting VSCs. \r\nNew Technique: COM VSS Coordinator Used for VSC Deletion \r\nDuring the study of ongoing ransomware tactics and techniques, TAU uncovered a newer method of Volume\r\nShadow deletion in the wild. This never reported technique instantiates the Component Object Model (COM)\r\nVolume Shadow Copy Coordinator (VssCoordinator), a part of the Volume Shadow Copy Service (VSS) using its\r\nCLSIDs. Short for class identifier, a CLSID is a globally unique identifier for a COM Class Object.  This direct\r\naccess to the VSS Coordinator provides full access to VSCs. \r\nTable 2: CLSIDs Used in New COM VSC Deletion Technique \r\nCLSID  Value \r\nVSS COM Interface  DA9F41D4-1A5D-41D0-A614-6DFD78DF5D05 \r\nVSS Coordinator  E579AB5F-1CC4-44B4-BED9-DE0991FF0623 \r\nHigh Level Summary of the Component Object Model (COM) \r\nA complete understanding of COM goes beyond what is needed to understand this technique, but a high-level\r\nunderstanding is helpful.  Here are the basics.  COM goes back to the beginning of Windows, and there are entire\r\nbooks written about it. At the risk of oversimplification, it is provided by Windows as a way for one or more\r\nprocess’ objects to interact with any other COM process’ objects regardless of language, structure, or location\r\nthrough a specifically defined COM interface. These interfaces commonly facilitate communication between\r\napplications and the operating system. It can be helpful to think of it as object-to-object communication regardless\r\nof all else. \r\nWhile COM has a no-rules-anything-goes philosophy, Windows privileges inject order into this anarchist\r\nmethodology. The relevant thing about Windows privileges for this paper’s purpose is that they define which\r\napplications and COM objects can interact, and what operations are allowed. This new technique to delete VSCs\r\nrequires access to the VSS Coordinator COM Object, and that requires SeBackupPrivilege.  \r\nSeBackupPrivilege allows file content retrieval, even if the security descriptor on the file might not grant such\r\naccess. A caller with SeBackupPrivilege enabled obviates the need for any ACL-based security check. (Microsoft,\r\n2021) \r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 10 of 17\n\nFigure 11: Enables SeBackupPrivilege \r\nThe above code shows the sample retrieving the LUID or Local Unique Identifier struct for SeBackupPrivilege.  A\r\nnew TOKEN_PRIVILEGES structure is created with this LUID to grant itself the same privilege. Then the\r\ncreated structure is passed to AdjustTokenPrivileges to ensure SeBackupPrivilege, which allows access to the\r\nnecessary interface. \r\nThe ransomware now has access to the VSS Coordinator Object through the VSS COM Interface and complete\r\ncontrol over volume shadow copies, including the ability to delete them, but before we analyze the technique any\r\nfurther; let’s look at the ransomware sample that contained it. \r\nHello Ransomware Containing New COM Technique for Deleting VSCs \r\nThe new technique was discovered in a sample of Hello ransomware, which has been circulating since at least\r\nmid-2021.  The table provides a high-level overview of its execution flow.  \r\nTable 3: Summary of Hello Ransomware Files \r\nName  SHA256  Relationship \r\nxd.exe  ffebda7512c78ba73ffa40dd02b59fd22cfa8e1bf48cd86e7b2d54e19c061134 \r\nOrigin File\r\n(Hello\r\nRansomware) \r\ndi.dll  5cd61b2f5f3f2d8af51b3635ba85f708e58a0961e4496e1cc37fdce58b3c04fb \r\nDropped by xd.exe\r\n(Drops vs.exe) \r\nvs.exe  cff04aa0a317d6b7c498faccdfbe7353b2676ea97acb1bee1bda650f29a8e423 \r\nDropped by di.dll\r\n(Deletes VSCs) \r\nFigure 12: Hello Ransomware Icon \r\nThe primary parent of the EXE that contains the new VSC deletion technique is named xd.exe. Its icon is shown\r\nhere. The xd.exe loads an AES encrypted blob into memory and decrypts it in place.  This decoded in-memory\r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 11 of 17\n\ncontent initiates encryption of files and drops the dynamic link library (DLL) file di.dll, which it spawns in a new\r\nprocess. The di.dll file has two objectives.  One, it finds a process with SeDebugPrivilege, and two, it drops and\r\nruns vs.exe as a new process. Then vs.exe exercises the new VSC deletion technique. \r\nFigure\r\n13: Red Mask Desktop Image \r\nWhile di.dll and vs.exe are prepping for and deleting the VSCs, the parent file, xd.exe continues to encrypt files,\r\neach encrypted file’s extension is appended with “.hello”, and the desktop background is changed to a centered\r\nimage of a red mask.  \r\nNew COM VssCoordinator Technique for Deleting VSCs \r\nAs described, the ransomware is not particularly noteworthy, except in its method of volume shadow copy\r\ndeletion, so let’s take a closer look at that technique specifically. As illustrated in the decompiled code, a handle to\r\nthe COM interface associated with the Volume Shadow Copy Coordinator is retrieved with a call to\r\nCoCreateInstance. Using this interface, a list of VSCs is secured, and this list enables the deletion of all shadow\r\ncopies.  As of this writing this technique has no detections by security vendors, which is likely because this\r\nmethod of deleting volume shadow copies has legitimate uses in the backup and recovery lifecycle.  In fact, while\r\nresearching this technique several legitimate backup solutions were evaluated and dismissed as known-good\r\napplications. \r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 12 of 17\n\nFigure 14: New Technique for Deleting VSCs \r\nMITRE ATT\u0026CK Techniques \r\nThis table was built using v11.2 of the framework. \r\nTable 4: MITRE ATT\u0026CK Techniques for Hello Ransomware\r\nffebda7512c78ba73ffa40dd02b59fd22cfa8e1bf48cd86e7b2d54e19c061134 \r\nTactic  ID  Name \r\nDescription of this\r\nimplementation                   \r\nExecution\r\nTA0002 \r\nT1129  Shared Modules \r\nCalls CreateProcessW to execute decrypted\r\ncontent. \r\nT1106  Native API  Makes direct system calls. \r\nT1559.001  Component Object Model  Uses COM to delete VSCs. \r\nPrivilege\r\nEscalation \r\nTA0004 \r\nT1134 \r\nAccess Token\r\nManipulation \r\nEnsures SeBackupPrivilege \r\nDefense\r\nEvasion\r\nTA0005 \r\nT1027.002 \r\nObfuscated Files or\r\nInformation: Software\r\nPacking \r\nSoftware packing and dynamic resolution of\r\nwindows function addresses, which are then\r\ncalled from non-standard registers. \r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 13 of 17\n\nT1218.011 \r\nSystem Binary Proxy\r\nExecution: Rundll32 \r\nRuns dropped file using rundll32.exe. \r\nT1140 \r\nDeobfuscate/Decode Files\r\nor Information \r\nEmbedded files are decrypted and dropped to\r\nthe file system. \r\nT1070.004 \r\nIndicator Removal on\r\nHost: File Deletion \r\nDropped file is deleted. \r\nT1140 \r\nDeobfuscate/Decode File\r\nor Information \r\nDecrypts and runs embedded files. \r\nImpact\r\nTA0040 \r\nT1486 \r\nData Encrypted for\r\nImpact \r\nFiles are encrypted for financial gain. \r\nT1491.001  Defacement: Internal  Desktop image is changed. \r\nT1490  Inhibit System Recovery  Deletes Volume Shadow Copies \r\nYARA Rule \r\nThe nature of this technique dictates that this rule will return false positive results in some environments. By\r\nexcluding validly signed files, a partial mitigation is achieved, however as most are already aware not all\r\nlegitimate files are signed, and subsequently sometimes malicious files can have a valid signature.  With this\r\ncaveat in mind, the below rule is provided as a starting point for further customization to meet the needs of one’s\r\nsituation.  For example, if the organization has software for managing backups that interacts directly with the VSS\r\nCoordinator, it will likely need to exclude executable files associated with it. \r\nimport \"pe\"\r\n/*\r\n Detects COM technique for deleting volume shadow copies using the\r\n Volume Shadow Copy Coordinator.\r\n*/\r\nrule VSS_COM_Deletion_Technique_without_WMI\r\n{\r\n strings:\r\n $IID_IVssCoordinator = {D4 41 9F DA 5D 1A D0 41 A6 14 6D FD 78 DF 5D 05}\r\n $CLSID_CVssCoordinator = {5F AB 79 E5 C4 1C B4 44 BE D9 DE 09 91 FF 06 23}\r\n $SeBackupPrivilege = \"SeBackupPrivilege\" ascii wide fullword\r\n condition:\r\n uint32(uint32(0x3C)) == 0x00004550 and\r\n $IID_IVssCoordinator and\r\n $CLSID_CVssCoordinator and\r\n $SeBackupPrivilege and\r\n not for all i in (0..pe.number_of_signatures - 1):\r\n pe.signatures[i].valid_on(pe.timestamp)\r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 14 of 17\n\n)\r\n}\r\nCommand 7: YARA Rule to Detect COM VssCoordinator VSC Deletion \r\nOther COM VSC Deletion Techniques \r\nOf course, this new technique isn’t the first-time malicious actors tapped into COM to delete volume shadow\r\ncopies and interacting directly with the VSS Coordinator is not the only access to the VSCs. To illustrate this, two\r\nmore techniques are provided.  This should not be considered a complete anthology of COM techniques for\r\ndeleting VSC and is provided as an overview.  The vast capabilities of COM almost certainly ensure there are\r\nmore techniques both already in the wild and yet to be written.  \r\nCOM WMI Object for VSC Deletion in Five Hands Ransomware \r\nFive Hands ransomware uses a different COM interface for deleting volume shadow copies, but one that is\r\nfamiliar.  The highlighted portion of the below image shows the CLSID of the WMI interface.  Gaining access to\r\nthe COM WMI interface provides the author with an incredible amount of built-in functionality including the\r\nability to delete volume shadow copies. \r\nFive Hands is reported to be used by an espionage-for-hire criminal group.  While many ransomware samples gain\r\naccess by phishing, initial access for this ransomware is strongly tied to an unpatched vulnerability in an\r\nexternally facing VPN product.  It is both always too late and never too late to patch those vulnerable systems, but\r\nmostly too late once Five Hands finds a way into the network.  \r\nFigure 15: COM WMI Access in\r\n02a08b994265901a649f1bcf6772bc06df2eb51eb09906af9fd0f4a8103e9851 \r\nVSS Requestor \u0026 Writer COM Objects Used for VSC Deletion in Diavol \r\nDiavol ransomware shares code similarities with Trickbot malware and Conti ransomware, and it has been\r\nobserved as early as October 2021. Its name, Diavol, is the Bulgarian word for devil, however one might be able\r\nto escape this “diavol”. If the unfortunate situation occurs, that causes the network to fall victim to this\r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 15 of 17\n\nransomware, check out the free decryption tool provided by Emsisoft4.  The VSCs will likely be gone, but maybe\r\nsome data may still be recoverable. \r\nThrough the Microsoft Volume Shadow Copy Requestor/Writer Services API DLL (vssapi.dll) Microsoft offers\r\nanother method of interaction with VSCs that is in use by Diavol. Very similar to the new technique outlined that\r\nuses the VssCoordinator, authors of the Diavol ransomware use COM to request the VssBackupComponents\r\ninterface by calling the public function CreateVssBackupComponentsInternal, which is a COM interface used by\r\nVSS Requesters to poll the VSS Writers.  Diavol uses this interface to query the VSS Writers for a list of all the\r\ncompleted shadow copies.  Then it iteratively calls DeleteSnapshots on each VSC until all VSCs have been\r\ndeleted. \r\nFigure 16: COM VssBackupComponents Use in\r\ne0c0e663bf44c9820b049f73f2910843ede20fd3e6cd0c9a22cbd2a48e1a228a \r\nConclusion \r\nIt is worth asking, “Is there a way to recover a VSC once it’s deleted?” The short answer is, “no.” File recovery\r\nsoftware could offer some hope, but success would be unpredictable at best.  It is important to acknowledge and\r\nquantify the unique risk for every situation, do not consciously or unconsciously decide ransomware will not\r\naffect the network. This is unrealistic and akin to the biological equivalent of deciding; no one will never get sick. \r\nEven in the very best, most security aware network environments bad things happen.  Products from VMware\r\nCarbon Black can play a key role in the detection and prevention of malicious behavior, and if necessary, can\r\nassist in remediation before the effects are out-of-control.  \r\nThere are open source freely available counter techniques and tools available to hedge the adversary’s ability to\r\ndelete VSCs.  A notable mention is Raccine5, whose name is a portmanteau of Ransomware and Vaccine.  This\r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 16 of 17\n\ntool registers itself as a debugger with vssadmin and wmic, which allows it to monitor for deletion commands. \r\nWhen offending commands are recognized, it kills the associated processes. This offers a good amount of\r\nprotection against the most common category of VSC deletion techniques with two of the most common LOLbins,\r\nhowever no protection is offered for deletion through scripting language objects or COM objects.  It is essential to\r\nhave quality backups in the event of ransomware, and not depend solely on VSCs. As much as possible, backups\r\nshould be kept offline and completely inaccessible to ransomware. There is simply no substitute for high quality\r\noffline backups and skilled professionals who can orchestrate their restoration. \r\nAppendix: Helpful Tips \r\nIt might be useful to create a shadow copy on demand to experiment or reproduce the analysis here.  The below\r\nexample commands, run as administrator, in CMD or PowerShell will accomplish this. \r\nwmic shadowcopy call create Volume=’C:\\’ \r\nvssadmin list shadows \r\nSource: https://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nhttps://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blogs.vmware.com/security/2022/09/threat-report-illuminating-volume-shadow-deletion.html"
	],
	"report_names": [
		"threat-report-illuminating-volume-shadow-deletion.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434246,
	"ts_updated_at": 1775791241,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f6214374cef7ddf317aebbb84c3423fe8f3386a7.pdf",
		"text": "https://archive.orkl.eu/f6214374cef7ddf317aebbb84c3423fe8f3386a7.txt",
		"img": "https://archive.orkl.eu/f6214374cef7ddf317aebbb84c3423fe8f3386a7.jpg"
	}
}