{
	"id": "01b5a7f4-f7ec-47c8-9a86-cd974da94ad1",
	"created_at": "2026-04-06T00:14:32.45509Z",
	"updated_at": "2026-04-10T13:12:51.017169Z",
	"deleted_at": null,
	"sha1_hash": "89f10051ab65bffedd1fbc2860e4dd70503f1225",
	"title": "Diavol Ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2040840,
	"plain_text": "Diavol Ransomware\r\nBy Chuong Dong\r\nPublished: 2021-12-17 · Archived: 2026-04-05 14:53:59 UTC\r\nReverse Engineering  · 17 Dec 2021\r\nContents\r\nDiavol Ransomware\r\nContents\r\nOverview\r\nIOCS\r\nRansom Note\r\nStatic Code Analysis\r\nAnti-Analysis: Launching Functions with Shellcode\r\nCommand-line Arguments\r\nBot ID Generation\r\nHard-coded Configuration\r\nBot Registration\r\nConfiguration Overriding\r\nStopping Services\r\nTerminating Processes\r\nRSA Initialization\r\nFinding Drives To Encrypt\r\nScanning Target Network Shares Through SMB\r\nScanning Network Shares In ARP Table Through SMB\r\nEncryption: Target File Enumeration\r\nEncryption: Remote File Enumeration Through SMB\r\nEncryption: System Drives Enumeration\r\nEncryption: File Encryption\r\nShadow Copies Deletion\r\nChanging Desktop Image\r\nSelf Deletion\r\nLogging\r\nReferences\r\nOverview\r\nThis is my analysis for the DIAVOL Ransomware.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 1 of 44\n\nDIAVOL is a relatively new ransomware that uses a unique method with shellcode to launch its core functions\r\nand RSA to encrypt files.\r\nThe malware contains a hard-coded configuration that stores informations such as files to encrypt and RSA public\r\nkey, but it can also requests these informations from the threat actor’s remote server.\r\nUnlike most major ransomware, this new malware’s encryption scheme is relatively slow due to its recursive\r\nmethod for file traversal.\r\nFigure 1: DIAVOL Post-Infection.\r\nIOCS\r\nHuge shout-out to Curated Intelligence for providing this sample.\r\nThe analyzed sample is a 64-bit Windows executable.\r\nMD5: f4928b5365a0bd6db2e9d654a77308d7\r\nSHA256: ee13d59ae3601c948bd10560188447e6faaeef5336dcd605b52ee558ff2a8588\r\nSample: MalwareBazaar\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 2 of 44\n\nFigure 2: VirusTotal Result.\r\nRansom Note\r\nThe content of the default ransom note is stored in plaintext in DIAVOL’s configuration. The malware can also\r\nrequest a ransom note from its remote server and override the default with that.\r\nDIAVOL’s ransom note filename is README-FOR-DECRYPT.txt.\r\nFigure 3: DIAVOL’s Ransom Note.\r\nStatic Code Analysis\r\nAnti-Analysis: Launching Functions with Shellcode\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 3 of 44\n\nFor anti-analysis, DIAVOL loads shellcode containing its core functions into memory and executes it\r\ndynamically, which makes static analysis a bit harder.\r\nFirst, the malware calls VirtualAlloc to allocate two memory buffers to later load these shellcodes in.\r\nFigure 4: Allocating Shellcode Buffers.\r\nWhen DIAVOL wants to execute a certain functionality, it calls a function to load the shellcode into memory and\r\nexecutes a call instruction to transfer control to the shellcode.\r\nFigure 5: Loading \u0026 Executing Shellcode.\r\nFirst, to load shellcode into memory, DIAVOL extracts the bitmap image corresponds to the given resource name\r\nby calling LoadBitmapW, CreateCompatibleDC, SelectObject, and GetObjectW.\r\nNext, it calls GetDIBits to retrieve the bits of the bitmap image and copies them into the shellcode buffer as a\r\nDIB.\r\nFigure 6: Loading Shellcode into memory.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 4 of 44\n\nUnlike normal shellcode, DIAVOL’s don’t manually walk the PEB to resolve its imports dynamically. The\r\nmalware loads a “JPEG” with the same name in the resource section, extracts a list of imported functions with\r\ntheir corresponding DLL, and manually calls LoadLibraryA and GetProcAddress to resolve it for the shellcode.\r\nThe resolved API addresses are stored at the end of the buffer, so the shellcode can make calls to those APIs using\r\ntheir exact offsets, which makes the loaded payload position-independent.\r\nFigure 7: Resolving API Addresses For Shellcode.\r\nBelow is the bitmap and the imported API list extracted from Resource Hacker.\r\nFigure 8: DIAVOL Resource Section.\r\nBecause each shellcode should be position-independent, we can simply load it into IDA for static analysis after\r\nextraction. However, the API addresses won’t make sense when IDA loads the shellcode because they are relative\r\nto where the DLLs are in the malware’s memory.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 5 of 44\n\nFigure 9: Loading Shellcode Into IDA.\r\nTo fix this, we just need to rename the API addresses in the order that they appear in the corresponding JPEG\r\nresource. After renaming, the shellcode should be decompiled correctly, and we can begin our static analysis on it.\r\nFigure 10: Fixing Shellcode’s API Calls In IDA.\r\nCommand-line Arguments\r\nDIAVOL can run with or without command-line arguments.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 6 of 44\n\nBelow is the list of arguments that can be supplied by the operator.\r\nArgument Description\r\n-p \u003ctarget\u003e Path to a file containing files/directories to be encrypt specifically\r\n-h \u003ctarget\u003e Path to a file containing remote files/directories to enumerate with SMB\r\n-m local Encrypting local files and directories\r\n-m net Encrypting network shares\r\n-m scan Scanning and encrypting network shares through SMB\r\n-m all Encrypting local and network drives without scanning through SMB\r\n-log \u003clog_filename\u003e Enable logging to the specified log file\r\n-s \u003cIP_address\u003e Remote server’s IP address to register bot\r\n-perc \u003cpercent\u003e Percent of data to be encrypted in a file (default: 10%)\r\nBot ID Generation\r\nThe first functionality DIAVOL executes is generating the bot ID through loading and executing the shellcode\r\nfrom the resource GENBOTID.\r\nPrior to launching the shellcode, DIAVOL calls time64 to retrieve the current timestamp on the system and uses it\r\nas the seed for srand to initialize the pseudo-random number generator.\r\nNext, it generates the following structure and passes it to the shellcode. The bot_ID field is later used to register\r\nthe victim to the threat actor’s remote server, and the victim_ID is the victim ID that is written to the ransom note.\r\nThe RSA_CRYPT_BUFF is a buffer that is later used to encrypt files.\r\nstruct DIAVOL_GENBOTID_STRUCT\r\n{\r\n char* bot_ID;\r\n wchar_t* victim_ID;\r\n BYTE* RSA_CRYPT_BUFF;\r\n int (__stdcall *rand)();\r\n};\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 7 of 44\n\nFigure 11: Initialize Structure For GENBOTID.\r\nTo generate the victim ID, the shellcode creates a unique GUID using CoCreateGuid and uses it as a random\r\nnumber to index into the string “0123456789ABCDEF” to generate a random 32-character string.\r\nFigure 12, 13: Generating Random 32-character Victim ID.\r\nTo generate the bot ID, the malware first calls GetComputerNameA and GetUserNameA to retrieve the\r\ncomputer name and user name. It also calls RtlGetVersion to retrieve the version of the victim’s computer and\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 8 of 44\n\nuses it to index into the string “0123456789ABCDEF” to generate an 8-character string.\r\nThen, the bot ID is built in the following string format.\r\n** + + \"_W\" + \u003c8_character_string_from_OS_version\u003e + \".\"**\r\nFigure 14, 15: Generating Bot ID.\r\nFinally, to populate the RSA_CRYPT_BUFF field, the malware calls the rand function to generate a random\r\n1024-byte buffer.\r\nFigure 16: Generating RSA CRYPT Buffer.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 9 of 44\n\nHard-coded Configuration\r\nThe configuration of DIAVOL is stored in plaintext in memory. To extract it, the malware allocates the following\r\nstructure using LocalAlloc and populates it using the hard-coded values from memory.\r\nstruct DIAVOL_CONFIG\r\n{\r\n _QWORD server_IP_addr; // remote server to register bot\r\n wchar_t* group_ID; // bot group ID\r\n wchar_t* Base64_RSA_key; // Base64-encoded RSA key\r\n wchar_t* process_kill_list; // processes to kill\r\n wchar_t* service_stop_list; // services to stop\r\n wchar_t* file_ignore_list; // filenames to avoid encrypting\r\n wchar_t* file_include_list; // filenames to include encrypting\r\n wchar_t* file_wipe_list; // filenames to delete\r\n wchar_t* target_file_list; // target files to encrypt first (overriden by \"-p\" command-line)\r\n wchar_t* ransom_note; // ransom note in reverse\r\n _QWORD findfiles_complete_flag; // is set to true when the first FINDFILES iteration is done\r\n};\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 10 of 44\n\nFigure 17, 18: Populate Configuration.\r\nBelow are the hard-coded values for the configuration.\r\n{\r\n server_IP_addr: \"127.0.0.1\",\r\n group_ID = \"c1aaee\",\r\n Base64_RSA_Key = \"BgIAAACkAABSU0ExAAQAAAEAAQCxVuiQzWxjl9dwh2F77Jxqt/PIrJoczV2RKluW\r\nM+xv0gSAZrL8DncWw9hif+zsvJq6PcqC0NugL3raLFbaUCUT8KAGgrOkIPmnrQpz\r\n5Ts2pQ0mZ80UlkRpw10CMHgdqChBqsnNkB9XF/CFYo4rndjQG+ZO22WX+EtQr6V8\r\nMYOE1A==\",\r\n process_kill_list = [\"iexplore.exe\", \"msedge.exe\", \"chrome.exe\", \"opera.exe\", \"firefox.exe\", \"savfmsesp.exe\",\r\n service_stop_list = [\"DefWatch\", \"ccEvtMgr\", \"ccSetMgr\", \"SavRoam\", \"dbsrv12\", \"sqlservr\", \"sqlagent\", \"Intuit\r\n file_ignore_list = [\"*.exe\", \"*.sys\", \"*.dll\", \"*.lock64\", \"*readme_for_decrypt.txt\", \"*locker.txt\", \"*unlocke\r\n file_include_list = [\"*\"],\r\n file_wipe_list = [],\r\n target_file_list = [],\r\n ransom_note = \"\\n\\r!NPV revo roT esu ot yrT .krowten etaroproc ro yrtnuoc ruoy ni kcolb eb yam resworB roT\\n\\r\r\n}\r\nBot Registration\r\nTo register the victim as a bot, DIAVOL first builds the content of the POST request to later be sent to the register\r\nremote server.\r\nThis is done through combining the bot ID generated in Bot ID Generation and the hard-coded group ID in the\r\nconfiguration in the following format.\r\ncid=\u003cbot_ID\u003e\u0026group=\u003cgroup_ID\u003e\u0026ip_local1=111.111.111.111\u0026ip_local2=222.222.222.222\u0026ip_external=2.16.7.12\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 11 of 44\n\nFigure 19: Building Register Request.\r\nNext, the malware allocates memory for the following structure before loading and executing the shellcode from\r\nresource REGISTER.\r\nstruct DIAVOL_REGISTER_STRUCT\r\n{\r\n char* agent; // \"Agent\"\r\n char* C2_IP_addr; // C2 IP address from configuration or command-line \"-s\"\r\n char* request_type; // \"POST\"\r\n char* domain_dir; // \"/BnpOnspQwtjCA/register\"\r\n char* content_type; // \"Content-Type: application/x-www-form-urlencoded; charset=UTF-8\"\r\n __int64 content_type_len; // length of content type\r\n char* payload_content; // register request\r\n __int64 payload_content_len; // length of register request\r\n};\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 12 of 44\n\nFigure 20: Building Register Structure \u0026 Register Bot.\r\nTo send the POST request, the shellcode InternetOpenA to initializes the application’s use of the WinINet\r\nfunctions, InternetConnectA to connect to the C2 server, HttpOpenRequestA to open a POST request at the\r\nspecified domain directory, and HttpSendRequestA to send the crafted POST request.\r\nFinally, the malware calls HttpQueryInfoA to query and return the server’s response.\r\nFigure 21: Sending POST Request To Register Bot.\r\nConfiguration Overriding\r\nBeside using the command line parameters, DIAVOL can also request different values from its remote server to\r\noverride the configuration fields unlike most major ransomware.\r\nFirst, the malware checks to make sure the victim has been properly registered as a bot to the main register server\r\nby checking if the server’s response code is 200.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 13 of 44\n\nFigure 22: Checking Register Response Code.\r\nNext, it loads and executes the shellcode from the resource FROMNET to request different configuration values.\r\nFor the calls to the shellcode, the malware allocates the following structure before passing it in as a parameter.\r\nstruct DIAVOL_FROMNET_STRUCT\r\n{\r\n char* agent; // \"Agent\"\r\n char* C2_IP_addr; // \"173.232.146.118\" (Hard-coded)\r\n char* request_type; // \"GET\"\r\n char* domain_dir; // \"/Bnyar8RsK04ug/\u003cbot_ID\u003e/\u003cgroup_ID\u003e/\u003cfield_name\u003e\r\n char* content_type; // \"Content-Type: application/x-www-form-urlencoded; charset=UTF-8\"\r\n __int64 content_type_len; // the length of the content type\r\n};\r\nFor the domain directory of the server’s address, the field name depends on the configuration field the malware is\r\nrequesting. Once registration is done, DIAVOL requests for the following field names:\r\nkey: Base64-encoded RSA key\r\nservices: service stop list\r\npriority: target files to encrypt first\r\nignore: filenames to avoid encrypting\r\next: filenames to include encrypting\r\nwipe: filenames to delete\r\nlanding: Ransom note\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 14 of 44\n\nFigure 23: Populating FROMNET Structure.\r\nThe shellcode calls InternetConnectA to connect to the C2 server, HttpOpenRequestA to open a GET request,\r\nand HttpSendRequestA to send the request. Next, it then calls InternetReadFile to read the server’s response for\r\nthe requested field and return that.\r\nFigure 24: Sending GET Request For Config Field.\r\nNext, because the lists in the configuration contains environment variables, DIAVOL resolves them by calling\r\nGetEnvironmentVariableW and converts them to lowercase using CharLowerBuffW.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 15 of 44\n\nFigure 25: Parsing Configuration Lists.\r\nFinally, the ransom note in the configuration is reversed and the string “%cid_bot%” is replaced with the\r\ngenerated victim ID.\r\nFigure 26: Building Final Ransom Note.\r\nStopping Services\r\nDIAVOL loads and executes the shellcode from the resource SERVPROC to stop the services specified in the\r\nconfiguration.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 16 of 44\n\nFigure 27: Loading \u0026 Executing SERVPROC.\r\nGiven a list of services to stop, the shellcode iterates through the list and stops them through the service control\r\nmanager.\r\nIt first calls OpenSCManagerW to retrieve a service control manager handle with all access, OpenServiceW to\r\nretrieve a handle to the target service, and ControlService to send a control stop code to stop it.\r\nFigure 28: Stopping Target Services.\r\nTerminating Processes\r\nDIAVOL loads and executes the shellcode from the resource KILLPR to terminate the processes specified in the\r\nconfiguration.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 17 of 44\n\nFigure 29: Loading \u0026 Executing KILLPR.\r\nThe shellcode first calls CreateToolhelp32Snapshot to take a snapshot of all processes in the system. Using the\r\nsnapshot, it iterates through each process using Process32FirstW and Process32NextW. For each process, its\r\nexecutable name is compared against every name in the configuration’s process list to be terminated.\r\nFigure 30, 31: Terminating Target Processes.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 18 of 44\n\nRSA Initialization\r\nPrior to file encryption, DIAVOL sets up the cryptography buffers that are later used to encrypt files.\r\nFirst, it allocates memory for the following structure before loading and executing the shellcode from resource\r\nRSAINIT.\r\nstruct DIAVOL_RSAINIT_STRUCT\r\n{\r\n HCRYPTPROV hCryptProv; // Handle to cryptographic service provider\r\n BYTE* Base64_RSA_key; // Base64-encoded RSA key\r\n char* container_str; // \"MicrosoftCryptoGuard\"\r\n char* provider_str; // \"Microsoft Enhanced Cryptographic Provider v1.0\"\r\n BYTE* RSA_CRYPT_BUFF;\r\n BYTE* RSA_FOOTER;\r\n};\r\nFigure 32: Loading \u0026 Executing RSAINIT.\r\nThe shellcode’s job is to populate RSA_FOOTER field to later be used during file encryption.\r\nFirst, it calls CryptStringToBinaryW to Base64-decode the RSA public key and CryptAcquireContextW to\r\nretrieve a handle to the corresponding cryptographic service provider.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 19 of 44\n\nFigure 33: Decode RSA Key \u0026 Retrieve CSP Handle.\r\nNext, the malware calls CryptImportKey to import the RSA public key and retrieve the key handle. It calls\r\nVirtualAlloc to allocate a memory buffer and divides the RSA_CRYPT_BUFF buffer into 117-byte blocks. For\r\neach block, DIAVOL appends it into the allocated buffer and calls CryptEncrypt to encrypt it using the RSA key\r\nhandle.\r\nFigure 34: Importing RSA Public Key \u0026 Encrypting RSA_CRYPT_BUFF.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 20 of 44\n\nFinally, the 2304-byte encoded buffer will be copied into the RSA_FOOTER buffer. How this and the\r\nRSA_CRYPT_BUFF buffer are used will later be discussed during file encryption.\r\nFigure 35: Writing Encrypted Content Into RSA_FOOTER.\r\nFinding Drives To Encrypt\r\nDIAVOL loads and executes the shellcode from the resource ENMDSKS to enumerate and find all drives in the\r\nsystem when the encryption mode from the command line is local, net, scan, or all.\r\nThe shellcode receives the list of files to avoid encrypting and a buffer to contain the name of drives found during\r\nenumeration as parameters.\r\nFigure 36: Loading \u0026 Executing ENMDSKS.\r\nThe shellcode first calls GetLogicalDriveStringsW to retrieve a list of all the drives in the system. For each\r\ndrive, its name is converted into lowercase and passed into GetDriveTypeW as a parameter to retrieve its type.\r\nThe drive only gets processed if its type is DRIVE_REMOTE or DRIVE_FIXED and its name is not in the list\r\nof files to avoid.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 21 of 44\n\nFigure 37: Enumerating Drives.\r\nIf the drive is valid to be encrypted, its name is appended to the buffer of drives from the shellcode’s parameter.\r\nFigure 38: Populating Target Drives List.\r\nIf the drive is a remote drive, the malware calls WNetGetConnectionW to retrieve the name of the network\r\nresource associated with it.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 22 of 44\n\nFigure 39: Finding Network Resource From Drive Name.\r\nFinally, using the name of the network resource, the malware calls gethostbyname to retrieve a hostent structure\r\nthat contains the IP address of the remote host.\r\nFinally, DIAVOL adds that IP address to the list of files to avoid encrypting.\r\nFigure 40: Adding Network Resource IP Address To Avoid Enumerating Twice.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 23 of 44\n\nDIAVOL has two different shellcode for scanning network shares using SMB in the SMBFAST and SMB\r\nresources.\r\nThe SMBFAST shellcode is used to scan for network shares from the target host list given by the “-h” command-line parameter.\r\nPrior to launching this shellcode, DIAVOL allocates memory for this following structure to contain information\r\nabout network hosts to enumerate for shares.\r\nstruct DIAVOL_SMB_STRUCT\r\n{\r\n FARPROC GetProcAddress;\r\n FARPROC memset;\r\n wchar_t *TARGET_NETWORK_SHARE_LIST; // Target network host names to enumerate for shares (from \"-h\" command-li\r\n DWORD *remote_host_IP_list; // Buffer to receive IP address of network hosts\r\n __int64 curr_network_share_name[16]; // Buffer to contain currently-processed share name\r\n _WORD DNS_server_name[260]; // Buffer to receive DNS or NetBIOS name of the remote server\r\n MIB_IPNETTABLE *IpNetTable;\r\n MIB_IFROW pIfRow;\r\n __int64 unk[2];\r\n};\r\nThe malware also allocates memory for this structure to receive the name of all scanned network resources. Both\r\nstructures are then passed to the shellcode as parameters.\r\nstruct DIAVOL_SMB_LIST\r\n{\r\n __int64 length;\r\n char *SMB_net_share_list;\r\n};\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 24 of 44\n\nFigure 41: Loading \u0026 Executing SMBFAST.\r\nSince the SMBFAST shellcode only scans for host names in the given target list, it enumerates through the list\r\nand writes each network share name into the curr_network_share_name field to be processed.\r\nFirst, the malware calls gethostbyname to retrieve a hostent structure for the current share name. Using the\r\nstructure, it extracts the host’s list of IP addresses and appends it to the remote_host_IP_list field.\r\nFigure 42: SMBFAST: Retrieve Target Host IP Addresses.\r\nNext, for each IP address retrieve from the host, the malware writes it to the DIAVOL_SMB_STRUCT-\r\n\u003eDNS_server_name buffer. This is then passed as a parameter to a NetShareEnum call to retrieve information\r\nabout each shared resource on the server with that IP address.\r\nFigure 43: SMBFAST: Retrieve Share Resource Info From IP Address.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 25 of 44\n\nNext, for each resource on the server, DIAVOL adds it to the DIAVOL_SMB_LIST-\u003eSMB_net_share_list\r\nbuffer in the following format.\r\n\u003cServer_IP_Address\u003e//\u003cResource_Name\u003e//\r\nThe resource name is extracted from the shi1_netname from the SHARE_INFO_1 structure that comes from the\r\nprevious NetShareEnum call.\r\nFigure 44, 45: SMBFAST: Adding Share Resource’s Full Path To Output List.\r\nThe final list is later used to encrypt these shared resources.\r\nThe SMB shellcode is used to scan for network shares from the hosts extracted from the Address Resolution\r\nProtocol (ARP) table.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 26 of 44\n\nPrior to launching this shellcode, DIAVOL allocates memory for the DIAVOL_SMB_STRUCT structure and the\r\nDIAVOL_SMB_LIST structure similar to the SMBFAST shellcode.\r\nFigure 46: Loading \u0026 Executing SMB.\r\nFirst, the shellcode calls GetIpNetTable to retrieve the IPv4-to-physical address mapping table on the victim’s\r\nmachine.\r\nUsing that table, the malware extracts the list of MIB_IPNETROW structures containing entries for IP addresses\r\nin the ARP table. For each MIB_IPNETROW structure, DIAVOL calls GetIfEntry to retrieve information for\r\nthe specified interface on the local computer.\r\nFigure 47: SMB: Retrieving Information For IP Addresses In ARP Table.\r\nNext, the malware iterates through the DIAVOL_SMB_STRUCT-\u003eremote_host_IP_list buffer to check if any\r\ngiven IP address from the “-h” command-line parameter is in the ARP table.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 27 of 44\n\nFigure 48: SMB: Looking Up Target IP Addresses In ARP Table.\r\nFor each target IP address that is also in the ARP table, the malware writes it to the DIAVOL_SMB_STRUCT-\r\n\u003eDNS_server_name buffer. This is then passed as a parameter to a NetShareEnum call to retrieve information\r\nabout each shared resource on the server with that IP address.\r\nFigure 49: SMB: Retrieve Share Resource Info From IP Address.\r\nThe rest of the code is similar to the SMBFAST shellcode. For each resource on the server, DIAVOL adds it to\r\nthe DIAVOL_SMB_LIST-\u003eSMB_net_share_list buffer in the following format.\r\n\u003cServer_IP_Address\u003e//\u003cResource_Name\u003e//\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 28 of 44\n\nEncryption: Target File Enumeration\r\nDIAVOL’s file encryption is divided into three parts. The first part is enumerating and encrypting all files from\r\nthe target list in the malware’s configuration.\r\nUp to this point, the files and directories in the list can come from the hard-coded values in memory or from the\r\ncommand-line parameter “-p”.\r\nFirst, it allocates memory for the following structure before loading and executing the shellcode from resource\r\nFINDFILES.\r\nstruct DIAVOL_FINDFILES_STRUCT\r\n{\r\n char* target_file; // The name of the file/directory to be encrypted\r\n DIAVOL_CONFIG *diavol_config; // Malware configuration\r\n FARPROC encrypt_file; // Function to encrypt file\r\n};\r\nFor the target_file field, the malware iterates through the target file list and launches the FINDFILES shellcode\r\nto encrypt each one.\r\nFigure 50: Loading \u0026 Executing FINDFILES.\r\nThe FINDFILES shellcode first converts the target filename to lowercase and checks to make sure the filename\r\ndoes not match with anything in the configuration’s file to ignore list or the target file list (to avoid enumerating a\r\ndirectory twice).\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 29 of 44\n\nBecause the names in the list can contain wildcard characters (‘*‘ for matching zero or more characters and ’?’ for\r\nmatching one character), the shellcode contains some additional code to check for that against the target filename.\r\nFigure 51: Checking To Avoid Encrypting File.\r\nNext, DIAVOL calls FindFirstFileW to begin its enumeration on the target file. For each file it finds, the\r\nmalware checks and avoids files whose name are ”.” or ”..” to infinite recursion during enumeration.\r\nFigure 52: Starting Enumeration.\r\nIf the currently processed file is a directory, the malware similarly converts it into lowercase and checks to make\r\nsure the filename is not in the file to ignore list or the target file list.\r\nIf the found directory is valid to be enumerated, the malware updates the target_file field to the directory’s name\r\nand recursively calls the FINDFILES shellcode function again.\r\nIf it is not valid, DIAVOL calls FindNextFileW to move on to find another file.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 30 of 44\n\nFigure 53: Recursive Traversal On Found Directories.\r\nIf the currently processed file is a directory, the malware also converts it into lowercase and checks to make sure\r\nthe filename is not in the file to ignore list or the target file list.\r\nIf the filename is in the configuration’s file to wipe list, the malware calls DeleteFileW to delete it.\r\nFigure 54: Deleting File.\r\nNext, if the filename’s format matches with anything in the configuration’s file to include list, the malware calls\r\nLocalAlloc to allocate memory and write the filename in there. Finally, it passes the allocated buffer to the\r\nDIAVOL_FINDFILES_STRUCT-\u003eencrypt_file function to encrypt it.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 31 of 44\n\nFigure 55: Sending File To Be Encrypted.\r\nOnce the enumeration is done for the original target file, the malware calls FindClose to close the file search\r\nhandle and pass the target file’s name to the DIAVOL_FINDFILES_STRUCT-\u003eencrypt_file function to encrypt\r\nit.\r\nFigure 56: Closing Search Handle \u0026 Encrypting Target File.\r\nThe encrypt_file function will be analyzed in a later section. This function can either take in a directory name or a\r\nfilename as the parameter.\r\nEncryption: Remote File Enumeration Through SMB\r\nAfter scanning the network for network share resources through the SMBFAST and SMB shellcodes, the malware\r\nspawns threads to enumerate the resources in those lists.\r\nPrior to each thread_encrypt call, the malware updates the target_file field to contain each resource list from the\r\ntwo shellcodes.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 32 of 44\n\nFigure 57: Setting Up Network Resource Enumeration.\r\nThe thread_encrypt function calls CreateThread to create a suspended thread launching an inner function with\r\nthe FINDFILES structure passed in as parameter.\r\nDIAVOL also passes the thread handle to a global handle array to later launch it.\r\nFigure 58: Launching Suspended Thread To Enumerate Share Resource.\r\nFor each resource in the list, the thread executes the FINDFILES to enumerate it.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 33 of 44\n\nFigure 59: Thread To Launch FINDFILES Shellcode To Enumerate Resource.\r\nFinally, to launch all these threads to begin the remote file enumeration, the malware iterates through the global\r\nhandle array and calls ResumeThread on each thread handle.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 34 of 44\n\nFigure 60: Resuming Suspended Threads To Begin Enumeration.\r\nEncryption: System Drives Enumeration\r\nThe final part of the enumeration is on the local and network drives retrieved from the ENMDSKS shellcode in\r\nthe previous section.\r\nThe list of drives to encrypt is passed to the target_file field in the FINDFILES structure, and the malware\r\nlaunches the FINDFILES shellcode to enumerate and encrypt each drive.\r\nFigure 61: Enumerating \u0026 Encrypting Network + Local Drives.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 35 of 44\n\nEncryption: File Encryption\r\nThe encrypt_file used in the FINDFILES shellcode takes in the name of a directory/file to encrypt.\r\nFirst, it sets up the following structure.\r\nstruct DIAVOL_ENCDEFILES_TRUCT\r\n{\r\n HANDLE RSA_hKey; // RSA Public Key Handle\r\n wchar_t *file_name; // filename to encrypt\r\n __int64 MAX_FILE_CRYPT_PERCENT; // From the \"-perc\" command-line parameter\r\n FARPROC calculate_percent; // function to calculate percent (a / b * c where b is 100)\r\n BYTE *RSA_CRYPT_BUFF;\r\n BYTE *RSA_FOOTER;\r\n FARPROC log_to_file; // logging function\r\n};\r\nFigure 62: Populating ENCDEFILES Structure.\r\nIf the name from the parameter is a directory, DIAVOL calls SetCurrentDirectoryW to change the current\r\ndirectory for the malware’s process to the directory’s name.\r\nIt then calls CreateFileW to create the ransom note file and WriteFile to write the ransom note in there.\r\nFigure 63: Dropping Ransom Note.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 36 of 44\n\nEarlier, before setting up the FINDFILES shellcode, the malware also loads the ENCDEFILE shellcode into\r\nanother buffer in memory.\r\nWhen the name from the parameter is of a file, the malware launches the ENCDEFILE shellcode to encrypt it.\r\nFigure 64: Launching ENCDEFILE Shellcode To Encrypt File.\r\nTo encrypt the file, the shellcode first calls CreateFileW to retrieve a handle for the target file.\r\nIt then calls GetFileSizeEx to retrieve the size of the file and calculates the maximum size to encrypt the file. This\r\nis done by calculating the MAX_FILE_CRYPT_PERCENT percent from the total file size.\r\nNext, the file is encrypted in 2048-byte blocks each, and the malware allocates a 2048-byte buffer using\r\nVirtualAlloc to host this data. For each block, DIAVOL calls ReadFile to read data into the allocated buffer and\r\nencrypts it using the RSA_CRYPT_BUFF buffer.\r\nIt then calls SetFilePointerEx to set the file pointer to the beginning of the newly encrypted block and calls\r\nWriteFile to write the encrypted block back in.\r\nAfter the encryption is finished, DIAVOL calls SetFilePointerEx to set the file pointer to the end of the file. It\r\nthen calls WriteFile to write to the end the RSA_FOOTER buffer, the max file size to encrypt, and the negation\r\nof every byte of that size.\r\nUsing this file footer, the threat actor’s decryptor can retrieve the RSA_FOOTER buffer and decrypt it into the\r\nRSA_CRYPT_BUFF buffer using their RSA private key to decrypt the file.\r\nFigure 66: Writing File Footer.\r\nFinally, DIAVOL calls VirtualAlloc to allocate a buffer to store the encrypted filename. It writes the original\r\nfilename in this buffer and appends it with the extension “.lock64” before calling MoveFileW to change the\r\nfilename.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 37 of 44\n\nFigure 67: Setting Encrypted File Extension.\r\nShadow Copies Deletion\r\nTo delete all shadow copies on the system, DIAVOL loads and executes the shellcode from the VSSMOD\r\nresource.\r\nFigure 68: Loading \u0026 Executing VSSMOD.\r\nFirst, the shellcode resolves these two stackstrings:\r\n“CompSpec”\r\n“/c vssadmin Delete Shadows /All /Quiet » NULL”\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 38 of 44\n\nFigure 69, 70: Resolving Stackstrings.\r\nNext, it calls GetEnvironmentVariableW on the “CompSpec” string to retrieve a full path to the command-line\r\ninterpreter.\r\nWith that, it calls ShellExecuteW to execute the command “vssadmin Delete Shadows /All /Quiet » NULL” to\r\ndelete all shadow copies on the system.\r\nFigure 71: Deleting Shadow Copies.\r\nChanging Desktop Image\r\nTo change the desktop image, DIAVOL loads and executes the shellcode from the CHNGDESK resource.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 39 of 44\n\nFigure 72: Loading \u0026 Executing CHNGDESK.\r\nThe shellcode first resolves the following stackstrings:\r\n”.\\encr.bmp”\r\n“Control Panel\\Desktop”\r\n“Wallpaper”\r\n“WallpaperOld”\r\nNext, it calls RegOpenKeyExW to retrieve the registry key using the sub key “Control Panel\\Desktop”. With\r\nthe registry key, the malware calls RegQueryValueExW to query the path to the current wallpaper image and\r\nRegSetValueExW to set that path as the value of “WallpaperOld”.\r\nFigure 73: Setting WallpaperOld Registry Value.\r\nTo build the bitmap path to drop on the system, the malware calls GetDesktopWindow and\r\nSHGetSpecialFolderPathW to retrieve the path to the special folder containing image files common to all users.\r\nIt then appends “encr.bmp” to that path.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 40 of 44\n\nFigure 74: Building Bitmap Path.\r\nTo build the bitmap from scratch, DIAVOL calls CreateCompatibleDC, GetDesktopWindow, and\r\nCreateDIBSection to create a bitmap as big as the current desktop window size. It also calls GetStockObject to\r\nset the bitmap’s background to black and SetTextColor to set the text color to white.\r\nFigure 75: Creating Background Bitmap.\r\nNext, it resolves the following stackstrings:\r\n“All your files are encrypted!”\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 41 of 44\n\n“For more information see README-FOR-DECRYPT.txt”\r\nThe malware then calls DrawTextW to write these two strings into the bitmap, CreateFileW to create the bitmap\r\nfile in the special folder, and WriteFile to write the generated bitmap into the file.\r\nFigure 76: Writing Bitmap Data To File.\r\nFinally, it calls SystemParametersInfoW to set wallpaper to the newly created bitmap file.\r\nFigure 77: Setting Wallpaper To Generated Bitmap.\r\nSelf Deletion\r\nAfter finishing file encryption and changing the wallpaper, the malware deletes its own executable.\r\nFirst, it calls GetModuleFileNameW to retrieve its own executable path. Then it builds the following string using\r\nthat.\r\n\"/c del \u003cmalware_executable_path\u003e \u003e\u003e NULL\"\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 42 of 44\n\nFigure 78: Building CMD Parameter.\r\nNext, it calls GetEnvironmentVariableW on the “CompSpec” string to retrieve a full path to the command-line\r\ninterpreter.\r\nWith that, it calls ShellExecuteW to execute the parameter above to delete its own executable.\r\nFigure 79: Deleting Its Own Executable.\r\nLogging\r\nThroughout its execution, DIAVOL logs all of its operations when logging is enabled through command-line.\r\nIn the logging function, the malware receives a string as a parameter. It calls GetLocalTime to retrieve the current\r\nsystem time when the logging occurs and write that to the log file buffer.\r\nThe malware then appends the input string parameter to the log file buffer and calls WriteFile to write to the log\r\nfile.\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 43 of 44\n\nFigure 80: Logging Functionality.\r\nReferences\r\nhttps://www.fortinet.com/blog/threat-research/diavol-new-ransomware-used-by-wizard-spider\r\nhttps://securityintelligence.com/posts/analysis-of-diavol-ransomware-link-trickbot-gang/\r\nyashechka, don’t be too distanced ;) Just wanna say hi on XSS\r\nSource: https://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nhttps://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/\r\nPage 44 of 44",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://chuongdong.com/reverse%20engineering/2021/12/17/DiavolRansomware/"
	],
	"report_names": [
		"DiavolRansomware"
	],
	"threat_actors": [
		{
			"id": "2864e40a-f233-4618-ac61-b03760a41cbb",
			"created_at": "2023-12-01T02:02:34.272108Z",
			"updated_at": "2026-04-10T02:00:04.97558Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "ETDA:WildCard",
			"tools": [
				"RustDown",
				"SysJoker"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "f6f91e1c-9202-4497-bf22-9cd5ef477600",
			"created_at": "2023-01-06T13:46:38.86765Z",
			"updated_at": "2026-04-10T02:00:03.12735Z",
			"deleted_at": null,
			"main_name": "WIZARD SPIDER",
			"aliases": [
				"TEMP.MixMaster",
				"GOLD BLACKBURN",
				"DEV-0193",
				"UNC2053",
				"Pistachio Tempest",
				"DEV-0237",
				"Storm-0230",
				"FIN12",
				"Periwinkle Tempest",
				"Storm-0193",
				"Trickbot LLC"
			],
			"source_name": "MISPGALAXY:WIZARD SPIDER",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "bc119938-a79c-4e5f-9d4d-dc96835dfe2e",
			"created_at": "2024-06-04T02:03:07.799286Z",
			"updated_at": "2026-04-10T02:00:03.606456Z",
			"deleted_at": null,
			"main_name": "GOLD BLACKBURN",
			"aliases": [
				"ITG23 ",
				"Periwinkle Tempest ",
				"Wizard Spider "
			],
			"source_name": "Secureworks:GOLD BLACKBURN",
			"tools": [
				"BazarLoader",
				"Buer Loader",
				"Bumblebee",
				"Dyre",
				"Team9",
				"TrickBot"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "63061658-5810-4f01-9620-7eada7e9ae2e",
			"created_at": "2022-10-25T15:50:23.752974Z",
			"updated_at": "2026-04-10T02:00:05.244531Z",
			"deleted_at": null,
			"main_name": "Wizard Spider",
			"aliases": [
				"Wizard Spider",
				"UNC1878",
				"TEMP.MixMaster",
				"Grim Spider",
				"FIN12",
				"GOLD BLACKBURN",
				"ITG23",
				"Periwinkle Tempest",
				"DEV-0193"
			],
			"source_name": "MITRE:Wizard Spider",
			"tools": [
				"TrickBot",
				"AdFind",
				"BITSAdmin",
				"Bazar",
				"LaZagne",
				"Nltest",
				"GrimAgent",
				"Dyre",
				"Ryuk",
				"Conti",
				"Emotet",
				"Rubeus",
				"Mimikatz",
				"Diavol",
				"PsExec",
				"Cobalt Strike"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "256a6a2d-e8a2-4497-b399-628a7fad4b3e",
			"created_at": "2023-11-30T02:00:07.299845Z",
			"updated_at": "2026-04-10T02:00:03.484788Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "MISPGALAXY:WildCard",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "e6a21528-2999-4e2e-aaf4-8b6af14e17f3",
			"created_at": "2022-10-25T16:07:24.422115Z",
			"updated_at": "2026-04-10T02:00:04.983298Z",
			"deleted_at": null,
			"main_name": "Wizard Spider",
			"aliases": [
				"DEV-0193",
				"G0102",
				"Gold Blackburn",
				"Gold Ulrick",
				"Grim Spider",
				"ITG23",
				"Operation BazaFlix",
				"Periwinkle Tempest",
				"Storm-0230",
				"TEMP.MixMaster",
				"Wizard Spider"
			],
			"source_name": "ETDA:Wizard Spider",
			"tools": [
				"AdFind",
				"Agentemis",
				"Anchor_DNS",
				"BEERBOT",
				"BazarBackdoor",
				"BazarCall",
				"BazarLoader",
				"Cobalt Strike",
				"CobaltStrike",
				"Conti",
				"Diavol",
				"Dyranges",
				"Dyre",
				"Dyreza",
				"Dyzap",
				"Gophe",
				"Invoke-SMBAutoBrute",
				"KEGTAP",
				"LaZagne",
				"LightBot",
				"PowerSploit",
				"PowerTrick",
				"PsExec",
				"Ryuk",
				"SessionGopher",
				"TSPY_TRICKLOAD",
				"Team9Backdoor",
				"The Trick",
				"TheTrick",
				"Totbrick",
				"TrickBot",
				"TrickLoader",
				"TrickMo",
				"Upatre",
				"bazaloader",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434472,
	"ts_updated_at": 1775826771,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/89f10051ab65bffedd1fbc2860e4dd70503f1225.pdf",
		"text": "https://archive.orkl.eu/89f10051ab65bffedd1fbc2860e4dd70503f1225.txt",
		"img": "https://archive.orkl.eu/89f10051ab65bffedd1fbc2860e4dd70503f1225.jpg"
	}
}