{
	"id": "d98780b7-645c-402a-9407-d3d774739376",
	"created_at": "2026-04-06T00:09:37.88074Z",
	"updated_at": "2026-04-10T13:11:52.701616Z",
	"deleted_at": null,
	"sha1_hash": "ea2f082e3c0d8851ba4db71c60a9b776ac0bfa54",
	"title": "A step-by-step analysis of a new version of Darkside Ransomware (v. 2.1.2.3) – CYBER GEEKS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 16387719,
	"plain_text": "A step-by-step analysis of a new version of Darkside Ransomware (v.\r\n2.1.2.3) – CYBER GEEKS\r\nPublished: 2021-06-14 · Archived: 2026-04-05 21:31:07 UTC\r\nSummary\r\nDarkside ransomware is the malware family responsible for the Colonial Pipeline attack on May 7 2021 as described\r\nat https://www.zdnet.com/article/darkside-the-ransomware-group-responsible-for-colonial-pipeline-cyberattack-explained/. The binary contains an encrypted configuration that will be decrypted using a custom algorithm, which\r\nreveals a 22-byte buffer that describes different actions performed by the malware. These actions include: checking the\r\nsystem language and avoiding to encrypt Russian language machines, deleting Shadow copies, wiping Recycle Bin,\r\nignore specific files, directories and file extensions, killing specific processes, deleting specific services, etc. The\r\nransomware can perform privilege escalation using the CMSTPLUA COM interface and achieves persistence by\r\ninstalling itself as a service. The files are encrypted using the custom Salsa20 implementation, with the Salsa20 matrix\r\nbeing encrypted by the public RSA key hard-coded in the binary. Darkside uses multithreading with I/O completion\r\nports to communicate between the main thread and the worker threads responsible for file encryptions. It’s important\r\nto mention that the process generates a random Salsa20 matrix using the RDRAND and RDSEED instructions, as\r\nopposed to earlier versions that use the RtlRandomEx function.\r\nAnalyst: @GeeksCyber\r\nTechnical analysis\r\nSHA256: 0A0C225F0E5EE941A79F2B7701F1285E4975A2859EB4D025D96D9E366E81ABB9\r\nThe malware comes with an encrypted configuration that is decrypted using a custom algorithm:\r\nFigure 1\r\nThe custom decryption algorithm consists of 4 subtraction operations by 0x10101010 each time and then some\r\naddition operations, as shown below:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 1 of 52\n\nFigure 2\r\nFor each DLL to be loaded, there is a hash function that is applied to the DLL name, and the 4-byte result is compared\r\nto hardcoded values:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 2 of 52\n\nFigure 3\r\nFor example, the following value corresponds to kernel32.dll:\r\nFigure 4\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 3 of 52\n\nThe following DLLs are expected to be loaded: ntdll, kernel32, advapi32, user32, gdi32, ole32, oleaut32, shell32,\r\nshlwapi, wininet, netapi32, wtsapi32, activeds, userenv, mpr, rstrtmgr. The process retrieves the address of multiple\r\nexport functions based on similar hash values computed using the same algorithm:\r\nFigure 5\r\nThe decrypted configuration is presented below and is composed of the RSA-1024 exponent (0x010001 = 65537),\r\n0x80-byte RSA-1024 modulus, victim UID, 22 configurations bytes (will be detailed further on) and the aPLib-compressed configuration:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 4 of 52\n\nFigure 6\r\nThe binary uses an aPLib-decompression algorithm to decrypt different strings. The following list represents the\r\ndirectories to avoid in the encryption process:\r\nFigure 7\r\nThe following files will be ignored by the ransomware:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 5 of 52\n\nFigure 8\r\nIf the file’s extension belongs to the following list, then the file will not be encrypted by the process:\r\nFigure 9\r\nThe binary intends to delete folders that contain the word “backup” in their name:\r\nFigure 10\r\nA feature not used by the malware would use the following strings decompressed as the other ones (our guess is that\r\nthe actor would try to kill the SQL-related processes in order to encrypt databases):\r\nFigure 11\r\nThe following processes will not be terminated by the file:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 6 of 52\n\nFigure 12\r\nIf a process name contains any of the following strings, it will be killed by the binary:\r\nFigure 13\r\nThere is also a list of services to be stopped and deleted, as shown in the figure below:\r\nFigure 14\r\nThe list of C2 servers is also obtained using the same algorithm:\r\nFigure 15\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 7 of 52\n\nThe process reveals a message that will be utilized to set a custom wallpaper that contains important instructions for\r\nthe victim:\r\nFigure 16\r\nThe content of the ransom note is also written in the process memory, as shown in figure 17:\r\nFigure 17\r\nThe following table describes the actions that the malware takes depending on the configuration decrypted above:\r\nOffset Enabled Description\r\n0x00 Yes FAST encryption mode\r\n0x01 Yes Unknown (not used)\r\n0x02 No Attempt to log on as a user on the machine\r\n0x03 Yes\r\nEncrypt DRIVE_REMOVABLE, DRIVE_FIXED and DRIVE_REMOTE\r\ntype of drives\r\n0x04 Yes Retrieve the domain controllers and probably an attempt to spread further\r\n0x05 Yes Check system language and avoid the Russian language\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 8 of 52\n\n0x06 Yes Delete volume shadow copies\r\n0x07 Yes Delete files and folders from Recycle Bin\r\n0x08 No Self deletion\r\n0x09 Yes Ignore specific directories\r\n0x0a Yes Ignore specific files\r\n0x0b Yes Ignore specific file extensions\r\n0x0c Yes Wipe “backup” directories\r\n0x0d Yes Unknown (not used)\r\n0x0e Yes Kill specific processes\r\n0x0f Yes Stop and delete specific services\r\n0x10 Yes Set Desktop wallpaper\r\n0x11 Yes Drop ransom note\r\n0x12 Yes Change icon of new encrypted files\r\n0x13 Yes Create a mutex\r\n0x14 Yes Unknown (not used)\r\n0x15 Yes Communication with the C2 servers\r\nThe malware uses the NtQueryInstallUILanguage and NtQueryDefaultUILanguage APIs to determine the language of\r\nthe system and compares the result with 0x419 (Russian language identifier). If there is a match between these two\r\nvalues, then the malware exits:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 9 of 52\n\nFigure 18\r\nThere is a call to the RegCreateKeyExW function, which is supposed to create (or open if it already exists) the\r\n“Software\\Microsoft\\Cryptography” registry key, as follows:\r\nFigure 19\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 10 of 52\n\nThe malware extracts the “MachineGuid” value from the above registry key, as presented in the next figure:\r\nFigure 20\r\nFigure 21\r\nA custom hashing algorithm that generates 8 lowercase hexadecimal characters is implemented by the process (the\r\n“MachineGuid” value is the input, and the algorithm applies 8 times):\r\nFigure 22\r\nFigure 23\r\nThe value computed above (let’s call it RansomPseudoValue) will be used in the following constructions:\r\nService name: \u003cRansomPseudoValue\u003e\r\nService display name: \u003cRansomPseudoValue\u003e\r\nRansom note: README\u003cRansomPseudoValue\u003e.TXT\r\nWallpaper: %PROGRAMDATA%\\\u003cRansomPseudoValue\u003e.BMP\r\nEach encrypted file will have the following name: \u003cOriginal filename\u003e\u003cRansomPseudoValue\u003e\r\nIcon file: %PROGRAMDATA%\\\u003cRansomPseudoValue\u003e.ico\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 11 of 52\n\nRegistry key created: HKCR\\\u003cRansomPseudoValue\u003e\\DefaultIcon=%PROGRAMDATA%\\\r\n\u003cRansomPseudoValue\u003e.ico\r\nThe binary uses the SHTestTokenMembership API to verify if the user belongs to the Administrators groups (0x220 =\r\n544 in decimal):\r\nFigure 24\r\nWe’ll split the analysis into 3 different parts depending on the user’s privileges: low level privileges, administrative\r\nprivileges, and SYSTEM privileges.\r\nLow Level privileges\r\nThe malware attempts a UAC bypass that uses the CMSTPLUA COM interface as described at\r\nhttps://gist.github.com/api0cradle/d4aaef39db0d845627d819b2b6b30512. It utilizes ZwOpenProcessToken to open the\r\naccess token associated with the process (0x8 = TOKEN_QUERY – required to query an access token):\r\nFigure 25\r\nThe NtQueryInformationToken function is used to get the group accounts associated with the token (0x2 =\r\nTokenGroups) and it checks if the administrators group can be found in the TOKEN_GROUPS structure:\r\nFigure 26\r\nThere is a call to the CoInitialize routine in order to initialize the COM library on the current thread, as highlighted in\r\nfigure 27:\r\nFigure 27\r\nAs presented so far, the binary uses a lot of lower level APIs (from ntdll). It allocates a new memory area using the\r\nZwAllocateVirtualMemory API (0x3000 = MEM_COMMIT | MEM_RESERVE and 0x4 =\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 12 of 52\n\nPAGE_READWRITE):\r\nFigure 28\r\nWe have encountered a call to an undocumented API function called LdrEnumerateLoadedModules:\r\nFigure 29\r\nThe file executes CoGetObject with the object name as Elevation:Administrator!new:{3E5FC7F9-9A51-4367-\r\n9063-A120244FBEC7}, as highlighted below:\r\nFigure 30\r\nBasically, it will relaunch the malware with SYSTEM privileges:\r\nFigure 31\r\nFigure 32\r\nAdministrative privileges\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 13 of 52\n\nAs in the first case, the binary uses ZwOpenProcessToken to open the access token associated with the process (0x8 =\r\nTOKEN_QUERY – required to query an access token):\r\nFigure 33\r\nThe NtQueryInformationToken API is utilized to retrieve the token’s user account (0x1 = TokenUser):\r\nFigure 34\r\nThe malicious process uses LookupAccountSidW to obtain the name of the account associated with the SID provided\r\nas the input, as shown in figure 35:\r\nFigure 35\r\nThere are 3 different comparison operations that compare the domain name (the name of the computer in our case)\r\nwith “NT AUTHORITY”, “AUTORITE NT” and “NT-AUTORITAT” (basically, it tries to determine if the user\r\naccount is SYSTEM or not):\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 14 of 52\n\nFigure 36\r\nThe OpenSCManagerW routine is utilized to establish a connection to the service control manager:\r\nFigure 37\r\nThe process tries to open a service called \u003cRansomPseudoValue\u003e (which doesn’t exist at this time):\r\nFigure 38\r\nBecause the service doesn’t exist, it will be created by the malware for persistence purposes, as shown in the following\r\npictures:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 15 of 52\n\nFigure 39\r\nFigure 40\r\nThe newly created service is started, and the binary launches itself as a service:\r\nFigure 41\r\nSYSTEM privileges\r\nThe malicious binary can run with no arguments, one, two, or three arguments (these cases will be described later on).\r\nAs we can see below, it uses CommandLineToArgvW to obtain pointers to the command line arguments (argv[0] is the\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 16 of 52\n\nexecutable name) + the number of arguments:\r\nFigure 42\r\nThe WTSQueryUserToken API is utilized to obtain the primary access token of the logged-on user specified by\r\nsession 1:\r\nFigure 43\r\nOpenWindowStationW is used to open the “Winsta0” windows station (the interactive window station), 0x40000 –\r\nWRITE_DAC – modify the DACL in the security descriptor for the object:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 17 of 52\n\nFigure 44\r\nThe DACL (discretionary access control list) of the “Winsta0” windows station is modified by calling the\r\nNtSetSecurityObject routine with the 0x4 = DACL_SECURITY_INFORMATION parameter:\r\nFigure 45\r\nThere is a call to OpenDesktopW that is utilized to open the “Default” desktop object with the argument 0x40081 =\r\nWRITE_DAC | DESKTOP_WRITEOBJECTS | DESKTOP_READOBJECTS, as follows:\r\nFigure 46\r\nThe DACL of the “Default” desktop object is modified by calling the NtSetSecurityObject function with the 0x4 =\r\nDACL_SECURITY_INFORMATION parameter:\r\nFigure 47\r\nThe malware creates a mutex called “Global\\4787658f1cc4202b8a15e05dd0323fde” (this value has been computed\r\nbefore this operation and represents a custom “hash” value of the malware), which makes sure that there is only one\r\ninstance of the ransomware running at a time (if the mutex already exists, then the malware quits):\r\nFigure 48\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 18 of 52\n\nFigure 49\r\nThe ransomware forces the system not to enter sleep mode and not to turn off the display while the process is running,\r\none of the parameters being 0x80000001 = ES_CONTINUOUS | ES_SYSTEM_REQUIRED:\r\nFigure 50\r\nThe file changes the privilege to SE_PRIVILEGE_ENABLED in order to enable the token’s privileges (note the\r\nTOKEN_PRIVILEGES structure) by a function call to ZwAdjustPrivilegesToken:\r\nFigure 51\r\nThe CreateThread API is used to create a new thread, as described in the next figure:\r\nFigure 52\r\nA list of valid drives on the system is extracted using the GetLogicalDriveStringsW routine:\r\nFigure 53\r\nThe ransomware is looking for DRIVE_REMOVABLE (0x2) and DRIVE_FIXED (0x3) drives, as highlighted in\r\nfigure 54:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 19 of 52\n\nFigure 54\r\nAll files and directories from Recycle Bin are deleted by the process. It starts to enumerate via a FindFirstFileExW\r\nAPI call:\r\nFigure 55\r\nAs presented below, the files are deleted using the DeleteFileW function, and the directories are removed using the\r\nRemoveDirectoryW routine:\r\nFigure 56\r\nThe binary uses COM objects and WMI commands to delete volume shadow copies. It calls the CoCreateInstance\r\nfunction to create a single object of the class IWbemLocator with the CLSID {dc12a687-737f-11cf-884d-https://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 20 of 52\n\n00aa004b2e24} (Ref. https://forum.powerbasic.com/forum/user-to-user-discussions/source-code/25222-wmi-wrapper-functions):\r\nFigure 57\r\nThere is also a new IWbemContext interface with the CLSID {44aca674-e8fc-11d0-a07c-00c04fb68820} (Ref.\r\nhttps://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-wmi/3485541f-6950-4e6d-98cb-1ed4bb143441)\r\ncreated via a CoCreateInstance function call:\r\nFigure 58\r\nUsing the IWbemLocator object, the process calls the ConnectServer API to connect to the local “ROOT\\CIMV2”\r\nnamespace and retrieves a pointer to a IWbemServices object, as follows:\r\nFigure 59\r\nThere is a call to CoSetProxyBlanket performed by the ransomware, as described in the next figure (0xA =\r\nRPC_C_AUTHN_WINNT – NTLMSSP, 0x3 = RPC_C_AUTHN_LEVEL_CALL and 0x3 =\r\nRPC_C_IMP_LEVEL_IMPERSONATE):\r\nFigure 60\r\nThe process executes the following SQL query “SELECT * FROM Win32_ShadowCopy” to obtain an enumerator of\r\nall shadow copies, and then it deletes each of the shadow copy objects via the DeleteInstance method:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 21 of 52\n\nFigure 61\r\nA list of all services and their status is retrieved by calling the EnumServicesStatusExW function (0x30 =\r\nSERVICE_WIN32, 0x3 = SERVICE_STATE_ALL):\r\nFigure 62\r\nEach service name is compared to the list that was decrypted at the beginning of the analysis:\r\nFigure 63\r\nThe malware opens the targeted services by calling the OpenServiceW routine (0x10020 = DELETE |\r\nSERVICE_STOP):\r\nFigure 64\r\nEvery targeted service is stopped and deleted using ControlService and DeleteService, as displayed in figure 65:\r\nFigure 65\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 22 of 52\n\nThe NtQuerySystemInformation API returns an array of SYSTEM_PROCESS_INFORMATION structures (one for\r\neach process running on the system, 0x5 = SystemProcessInformation):\r\nFigure 66\r\nEach process name is compared to the list that was decrypted in the beginning, as displayed below:\r\nFigure 67\r\nFor every targeted process, the binary opens the process and terminates it and all of its threads:\r\nFigure 68\r\nThe binary creates an ico file called \u003cRansomPseudoValue\u003e.ico, as displayed below:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 23 of 52\n\nFigure 69\r\nA new registry key called \u003cRansomPseudoValue\u003e is created using the RegCreateKeyExW function, as shown in figure\r\n70:\r\nFigure 70\r\nThe DefaultIcon subkey is created, and it specifies the path for the newly created ico file:\r\nFigure 71\r\nThe malware calls the SHChangeNotify routine to notify the shell to update its icon cache (0x08000000 =\r\nSHCNE_ASSOCCHANGED, 0x1000 = SHCNF_FLUSH):\r\nFigure 72\r\nA new file called %PROGRAMDATA%\\\u003cRansomPseudoValue\u003e.BMP is created using the CreateFileW function:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 24 of 52\n\nFigure 73\r\nMoving forward, there is a registry key opened by calling the RegCreateKeyExW API, as shown in the next picture:\r\nFigure 74\r\nThe “WallPaper” value inside the registry key is changed to the location of the newly created BMP file:\r\nFigure 75\r\nAfter all of these activities, the Desktop has been changed to the following image:\r\nFigure 76\r\nThread activity – sub_4095AB\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 25 of 52\n\nThe thread starts by decrypting the following information:\r\nFigure 77\r\nThe version of the Darkside ransomware is also decrypted and represents the latest version analyzed in the wild\r\n(2.1.2.3):\r\nFigure 78\r\nAnother JSON structure is decrypted by the binary and will be used to collect data about the local machine:\r\nFigure 79\r\nOne more time, the process checks the type of the drives and is looking for DRIVE_REMOVABLE (0x2),\r\nDRIVE_FIXED (0x3) and DRIVE_REMOTE (0x4):\r\nFigure 80\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 26 of 52\n\nThe GetDiskFreeSpaceExW function is used to retrieve information about the targeted drives, such as the total amount\r\nof space and the total amount of free space:\r\nFigure 81\r\nNtDuplicateToken is utilized to duplicate an existing token and to obtain a handle to a new access token (0xC =\r\nTOKEN_DUPLICATE | TOKEN_IMPERSONATE | TOKEN_QUERY and 0x2 = TokenImpersonation):\r\nFigure 82\r\nThe thread’s impersonation token is changed via a call to the ZwSetInformationThread routine, as shown in figure 83\r\n(0x5 = ThreadImpersonationToken):\r\nFigure 83\r\nThe ransomware retrieves the username associated with the current thread, as well as the NetBIOS name of the local\r\nmachine:\r\nFigure 84\r\nFigure 85\r\nThe current language of the machine is retrieved from the “LocaleName” value, as presented below:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 27 of 52\n\nFigure 86\r\nNetGetJoinInformation is used to get the join status information for the local computer:\r\nFigure 87\r\nThe product name of Windows can be extracted by querying the “ProductName” value and the Windows product ID\r\ncan be extracted by querying the “ProductId” value, as shown in the following pictures:\r\nFigure 88\r\nFigure 89\r\nThe malware constructs the following JSON, which contains data to be exfiltrated to the C2 server:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 28 of 52\n\nFigure 90\r\nThe final data looks like in the following JSON form:\r\nFigure 91\r\nThe data from above is encrypted by a custom encryption algorithm:\r\nFigure 92\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 29 of 52\n\nFigure 93\r\nThe result of the encryption operation is base64-encoded, as shown below:\r\nFigure 94\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 30 of 52\n\nFigure 95\r\nThe following function is used to generate 2 random 4-byte values that will be utilized in the network\r\ncommunications. It uses instructions such as RDRAND and RDSEED to generate random numbers (if these are\r\nsupported), but we’ll provide a deeper understanding of it when we discuss file encryption (it’s also used to generate\r\nthe Salsa20 matrix):\r\nFigure 96\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 31 of 52\n\nThe parameters of the network request have the following structure:\r\nrandom_number1=base64(encryptionresult)\u0026random_number2=victim_uid:\r\nFigure 97\r\nThe InternetOpenW function is called using a user agent decrypted by the malware as a parameter:\r\nFigure 98\r\nInternetConnectW is utilized to connect to one of the C2 servers (baroquetees[.]com) on port 443:\r\nFigure 99\r\nThe process creates an HTTP request handle using the HttpOpenRequestW routine, as shown in figure 100:\r\nFigure 100\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 32 of 52\n\nThere is also a call to the InternetSetOptionW API that is used to set the security flags for the handle (0x1f =\r\nINTERNET_OPTION_SECURITY_FLAGS):\r\nFigure 101\r\nThe binary sends the POST request to the C2 server using HttpSendRequestW:\r\nFigure 102\r\nFigure 103\r\nThe status code returned by the server is retrieved using the HttpQueryInfoW API (0x13 =\r\nHTTP_QUERY_STATUS_CODE):\r\nFigure 104\r\nInterestingly, the ransomware doesn’t expect a 200 status code but a 500 (Internal Server Error). If the status code isn’t\r\n500, then the process repeats the steps described so far using the second C2 server, rumahsia[.]com:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 33 of 52\n\nFigure 105\r\nFigure 106\r\nThis last idea concludes our analysis of this thread. We continue to analyze the main thread.\r\nThe binary enumerates the volumes available on the machine and uses the CreateFileW routine to open them:\r\nFigure 107\r\nDeviceIoControl is utilized to get information about the type, size, and nature of a disk partition (0x70048 =\r\nIOCTL_DISK_GET_PARTITION_INFO_EX):\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 34 of 52\n\nFigure 108\r\nA new thread is created by the file using CreateThread:\r\nFigure 109\r\nThread activity – sub_407558\r\nThe only action the thread does is using the GetLogicalDriveStringsW API to retrieve the valid drives on the local\r\nmachine:\r\nFigure 110\r\nIf a volume doesn’t have a drive letter associated with it, then the ransomware does that using the\r\nSetVolumeMountPointW API, as highlighted in the following picture:\r\nFigure 111\r\nThe malicious process targets the following types of drives – DRIVE_REMOVABLE (0x2), DRIVE_FIXED (0x3)\r\nand DRIVE_REMOTE (0x4):\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 35 of 52\n\nFigure 112\r\nThe CreateFileMappingW function is used to create a named file mapping object (name “Local\\\\job0-\u003cProcess Id\u003e”\r\nmeans the object is created in the session namespace):\r\nFigure 113\r\nThe binary maps a view of the file mapping into the address space of the process by calling the MapViewOfFile\r\nroutine (0xf001f = FILE_MAP_ALL_ACCESS):\r\nFigure 114\r\nA named event object called “Local\\\\job0-\u003cProcess Id\u003e-Event” is created by the binary:\r\nFigure 115\r\nThe ransomware launches itself with 3 parameters, and the new process will execute the encryption operations:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 36 of 52\n\nFigure 116\r\nOpenMutexW is utilized to open a named mutex called “Global\\\\T-job0-\u003cProcess Id\u003e” (which doesn’t exist at this\r\ntime) – 0x100000 = SYNCHRONIZE:\r\nFigure 117\r\nThe event object created earlier is opened by calling the OpenEventW API (0x1f0003 = EVENT_ALL_ACCESS), as\r\ndisplayed in figure 118:\r\nFigure 118\r\nThe file creates an I/O completion port that isn’t associated with a file handle, which will be used by the main thread\r\nto send data that will be encrypted to worker threads:\r\nFigure 119\r\nTwo different threads that will take care of the files’ encryption are created using the CreateThread routine:\r\nFigure 120\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 37 of 52\n\nThe ransom note README\u003cRansomPseudoValue\u003e.TXT is created and populated in every directory the malware\r\nencrypts:\r\nFigure 121\r\nThe process doesn’t encrypt some certain files, as displayed in the next figure:\r\nFigure 122\r\nA list of file extensions decrypted at the beginning of the execution is also excluded from the encryption process:\r\nFigure 123\r\nEvery targeted file is opened and read using the CreateFileW and ReadFile functions:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 38 of 52\n\nFigure 124\r\nFigure 125\r\nThe file extension is changed to also include \u003cRansomPseudoValue\u003e, as shown below:\r\nFigure 126\r\nThere is a second function call to CreateIoCompletionPort that associates the existing I/O completion port with the\r\nFileHandle parameter:\r\nFigure 127\r\nThe RSA public exponent and the RSA modulus will be used in the encryption process of the Salsa20 matrix, as we’ll\r\ndescribe later on:\r\nFigure 128\r\nThe ransomware checks to see if the RDRAND and RDSEED instructions are supported by the processor. If that’s the\r\ncase, it will use one of them to generate 56 random bytes, and 8 NULL bytes are added to the resulting buffer (Salsa20\r\nmatrix -\u003e custom Salsa20 implementation). If none of these are supported, the malware uses the rdtsc instruction to\r\ngenerate deterministic timestamps that will provide a 64-byte Salsa20 matrix:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 39 of 52\n\nFigure 129\r\nFigure 130\r\nThe thread poses a custom implementation of the RSA-1024 algorithm (it doesn’t rely on Windows APIs). Basically,\r\nthe data d will produce a ciphertext = (d^exponent)%modulus. The raw modulus calculation is performed using\r\naddition and subtraction and part of the implementation is presented in the following figures:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 40 of 52\n\nFigure 131\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 41 of 52\n\nFigure 132\r\nThe Salsa20 matrix is encrypted using the custom RSA implementation, as shown in figure 133:\r\nFigure 133\r\nThere is a custom “hash” function applied to the above encryption result, which produces a 16-byte output:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 42 of 52\n\nFigure 134\r\nThe file content that will be encrypted is appended to the buffer that will be sent to the worker threads:\r\nFigure 135\r\nThe Salsa20 matrix is also added to the buffer, and it will be utilized by the worker threads to encrypt the files:\r\nFigure 136\r\nThread activity – sub_405E7C (File encryption)\r\nThe file content is encrypted using a custom Salsa20 implementation and the ciphertext overwrites the plaintext in the\r\nbuffer:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 43 of 52\n\nFigure 137\r\nA snippet of the custom implementation is presented below:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 44 of 52\n\nFigure 138\r\nThe encrypted content is written to the initial file, followed by the encrypted Salsa20 matrix and the hash value, as\r\ndisplayed in the following figures:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 45 of 52\n\nFigure 139\r\nFigure 140\r\nThis last idea concludes our analysis of this thread. We continue to analyze the main thread.\r\nIf the current directory contains “backup”, then the malware deletes it:\r\nFigure 141\r\nThe main thread sends the buffer described above (which includes file content to be encrypted etc.) to the worker\r\nthreads by calling the PostQueuedCompletionStatus routine:\r\nFigure 142\r\nWe’ve also identified a function that we believe it’s used to propagate the malware to domain controllers (we didn’t\r\nhave one in our environment). It calls functions such as DsGetDcNameW, DsGetDcOpenW and DsGetDcNextW:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 46 of 52\n\nFigure 143\r\nDarkside enumerates all network shares using the NetShareEnum API and encrypts each one of them by the main\r\nencryption routine described so far:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 47 of 52\n\nFigure 144\r\nThread activity – sub_4096A4\r\nThe following JSON is decrypted by the thread:\r\nFigure 145\r\nThe file opens the following registry key by calling RegCreateKeyExW:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 48 of 52\n\nFigure 146\r\nThe Product ID is retrieved again by calling the RegQueryValueExW function:\r\nFigure 147\r\nThe machine GUID is extracted from the registry and represents a unique identifier for the machine:\r\nFigure 148\r\nFigure 149\r\nAfter the encryption finishes, the malware sends encryption statistics to the C2 server, such as: victim ID, uid, number\r\nof encrypted files, size of encrypted files, number of skipped files and elapsed time. The final JSON structure looks\r\nlike the following:\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 49 of 52\n\nFigure 150\r\nAs already described so far regarding the C2 communication, the buffer is encrypted with a custom algorithm and\r\nbase64-encoded. The request sent to the C2 server is presented in the next picture:\r\nFigure 151\r\nIf the self deletion feature would be enabled, Darkside would delete itself using ShellExecuteW:\r\nFigure 152\r\nFigure 153\r\nAs we specified at the beginning of the analysis, the binary can run with different parameters:\r\n1 parameter: filename – only this file will be encrypted\r\n2 parameters: “-path” directory – only this directory will be encrypted\r\n3 parameters: “-work” worker0 job0-\u003cProcess Id\u003e – this is spawned by the initial process, already described\r\nA particular case is handled by the ransomware differently when it deals with a shortcut file (.lnk file). Basically, the\r\nbinary wants to extract the full path to the file from this link. It calls the CoCreateInstance API with the CLSID of\r\n{000214F9-0000-0000-C000-000000000046} (IShellLinkW interface):\r\nFigure 154\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 50 of 52\n\nUnfortunately, Scylla didn’t help us here and it couldn’t provide us the methods. We’ve found that the next 2 function\r\ncalls are used to extract the path of the file/directory:\r\nFigure 155\r\nFigure 156\r\nThe file extracted above is encrypted as usual:\r\nFigure 157\r\nReferences\r\nMSDN: https://docs.microsoft.com/en-us/windows/win32/api/\r\nFakenet: https://github.com/fireeye/flare-fakenet-ng\r\nAny.run: https://any.run/report/0a0c225f0e5ee941a79f2b7701f1285e4975a2859eb4d025d96d9e366e81abb9/e7a712f5-\r\n961a-45b4-a7e5-a0f7196113a5\r\nVirusTotal:\r\nhttps://www.virustotal.com/gui/file/0a0c225f0e5ee941a79f2b7701f1285e4975a2859eb4d025d96d9e366e81abb9/detection\r\nAnalysis of Darkside Ransomware v1.8.6.2:\r\nhttps://chuongdong.com/reverse%20engineering/2021/05/06/DarksideRansomware/\r\nFireeye report: https://www.fireeye.com/blog/threat-research/2021/05/shining-a-light-on-darkside-ransomware-operations.html\r\nhttps://gist.github.com/api0cradle/d4aaef39db0d845627d819b2b6b30512\r\nhttps://forum.powerbasic.com/forum/user-to-user-discussions/source-code/25222-wmi-wrapper-functions\r\nhttps://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-wmi/3485541f-6950-4e6d-98cb-1ed4bb143441\r\nINDICATORS OF COMPROMISE\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 51 of 52\n\nC2 domains: baroquetees[.]com, rumahsia[.]com\r\nSHA256: 0A0C225F0E5EE941A79F2B7701F1285E4975A2859EB4D025D96D9E366E81ABB9\r\nCreated files: README\u003cRansomPseudoValue\u003e.TXT, %PROGRAMDATA%\\\u003cRansomPseudoValue\u003e.BMP,\r\n%PROGRAMDATA%\\\u003cRansomPseudoValue\u003e.ico\r\nService Name: \u003cRansomPseudoValue\u003e, Service display name: \u003cRansomPseudoValue\u003e\r\nRegistry key: HKCR\\\u003cRansomPseudoValue\u003e\\DefaultIcon=%PROGRAMDATA%\\\u003cRansomPseudoValue\u003e.ico\r\nUser-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:79.0) Gecko/20100101 Firefox/80.0 (prone to False\r\nPositives)\r\nSource: https://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nhttps://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/\r\nPage 52 of 52\n\n https://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/ \nFigure 93  \nThe result of the encryption operation is base64-encoded, as shown below:\nFigure 94  \n  Page 30 of 52",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://cybergeeks.tech/a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware/"
	],
	"report_names": [
		"a-step-by-step-analysis-of-a-new-version-of-darkside-ransomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775434177,
	"ts_updated_at": 1775826712,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ea2f082e3c0d8851ba4db71c60a9b776ac0bfa54.pdf",
		"text": "https://archive.orkl.eu/ea2f082e3c0d8851ba4db71c60a9b776ac0bfa54.txt",
		"img": "https://archive.orkl.eu/ea2f082e3c0d8851ba4db71c60a9b776ac0bfa54.jpg"
	}
}