# A detailed analysis of the STOP/Djvu Ransomware **[cybergeeks.tech/a-detailed-analysis-of-the-stop-djvu-ransomware/](https://cybergeeks.tech/a-detailed-analysis-of-the-stop-djvu-ransomware/)** Summary STOP/Djvu ransomware is not a very known ransomware like Conti, REvil or BlackMatter, however ESET ranked it on the 3rd place in the top ransomware families in Q2 2020 (https://www.welivesecurity.com/wpcontent/uploads/2020/07/ESET_Threat_Report_Q22020.pdf). This ransomware can run with one of the following parameters: “–Admin”, “–Task”, “–AutoStart”, “–ForNetRes”, and “– Service”. The process doesn’t target specific countries based on their country code, and also decrypts a list of files, file extensions and folders that will be skipped. Two persistence mechanisms are implemented: a Run registry key and a scheduled task created using COM objects. The malware computes the MD5 hash of the MAC address and performs a GET request to the C2 server based on it. The binary also acts as a downloader for 2 malicious files called build2.exe and build3.exe. The victim ID is decrypted using the XOR operator and then written to a file called PersonalID.txt. Both local drives and network shares are targeted by the malware, and the files are encrypted using the Salsa20 algorithm. The Salsa20 matrix used for encrypting files is based on a UUID generated using the UuidCreate API, which is encrypted using an embedded RSA public key (if the C2 server is unreachable) or a public key downloaded from the C2 server. The RSA implementation found in the executable is [taken from the OpenSSL project hosted at https://github.com/openssl/openssl.](https://github.com/openssl/openssl) **Analyst:** [@GeeksCyber](https://twitter.com/GeeksCyber) Technical analysis SHA256: 4380c45fd46d1a63cffe4d37cf33b0710330a766b7700af86020a936cdd09cbe The following PDB path can be found in the binary: “C:\xudihiguhe\jegovicatusoca\jijetogez\winucet\xusev\kucor.pdb”. There is a call to GlobalAlloc that allocates several bytes from the heap: Figure 1 The malware calls the LoadLibraryW function in order to load the “kernel32.dll” file into the address space of the process: ----- Figure 2 The GetProcAddress API is utilized to retrieve the address of the “VirtualProtect” function: Figure 3 The memory area allocated above is filled in by the malware, and the VirtualProtect routine is used to change its protection to 0x40 = PAGE_EXECUTE_READWRITE: Figure 4 There is also a lot of garbage code in the binary that is never executed, as shown in figure 5: ----- Figure 5 The process jumps at the beginning of the new shellcode, as highlighted below: ----- Figure 6 The binary retrieves the address of the following functions using GetProcAddress: “GlobalAlloc”, “GetLastError”, “Sleep”, “VirtualAlloc”, “CreateToolhelp32Snapshot”, “Module32First”, “CloseHandle”. CreateToolhelp32Snapshot is utilized to take a snapshot of the current process that includes all its modules (0x8 = TH32CS_SNAPMODULE): Figure 7 The ransomware extracts information about the first module of the process using the Module32First API: Figure 8 The malicious process allocates and populates a new memory area via a function call to VirtualAlloc (0x1000 = MEM_COMMIT and 0x40 = PAGE_EXECUTE_READWRITE): Figure 9 The process jumps at the beginning of the new shellcode, as highlighted below: ----- Figure 10 The malware calls the LoadLibraryA API to load the following DLLs into memory: user32.dll, kernel32.dll and ntdll.dll. It also retrieves the address of the following functions: “MessageBoxA”, “GetMessageExtraInfo”, “WinExec”, “CreateFileA”, “WriteFile”, “CloseHandle”, “CreateProcessA”, “GetThreadContext”, “VirtualAlloc”, “VirtualAllocEx”, “VirtualFree”, “ReadProcessMemory”, “WriteProcessMemory”, “SetThreadContext”, “ResumeThread”, “WaitForSingleObject”, “GetModuleFileNameA”, “GetCommandLineA”, “NtUnmapViewOfSection”, “NtWriteVirtualMemory”, “RegisterClassExA”, “CreateWindowExA”, “PostMessageA”, “GetMessageA”, “DefWindowProcA”, “GetFileAttributesA”, “GetStartupInfoA”, “VirtualProtectEx”, “ExitProcess”. From our perspective, the malware developers have implemented some actions that don’t influence the main execution flow as an anti-analysis mechanism. GetFileAttributesA is used to retrieve file system attributes for a non-existent file: Figure 11 The file registers a window class called “saodkfnosa9uin” using the RegisterClassExA routine: Figure 12 ----- The CreateWindowExA function is utilized to create a new window (0x200 = **WS_EX_CLIENTEDGE, 0xCF0000 = WS_OVERLAPPEDWINDOW, 0x80000000 =** **CW_USEDEFAULT):** Figure 13 The process allocates a new memory area via a function call to VirtualAlloc (0x1000 = **MEM_COMMIT and 0x4 = PAGE_READWRITE):** Figure 14 The ransomware extracts the content of the STARTUPINFO structure: Figure 15 The malware creates a copy of itself in a suspended state via a call to CreateProcessA (0x08000004 = CREATE_NO_WINDOW | CREATE_SUSPENDED): Figure 16 ----- GetThreadContext is used to retrieve the context of a specific thread: Figure 17 The malicious binary unmaps a view of a section from the address of the newly created process using ZwUnmapViewOfSection: Figure 18 The VirtualAllocEx routine is utilized to allocate new space in the newly created process (0x3000 = MEM_COMMIT | MEM_RESERVE and 0x40 = PAGE_EXECUTE_READWRITE): Figure 19 The ransomware writes data to the area allocated above using multiple calls to ZwWriteVirtualMemory, as displayed in figure 20: ----- Figure 20 The SetThreadContext function is used to set the context for the remote thread: Figure 21 The binary resumes the main thread of the suspended process using ResumeThread: ----- Figure 22 We’ve extracted the executable from memory, and we continue to analyze this file. The following PDB path has been found: “e:\doc\my work (c++)_git\encryption\release\encrypt_win_api.pdb”. The binary initializes the use of the WinINet functions by calling the InternetOpenW API (the user agent being “Microsoft Internet Explorer”): Figure 23 The malware performs a GET request to https[:]//api.2ip.ua/geo.json, which reveals details about the location of the IP address: Figure 24 InternetReadFile is used to read the response from the server, and an example of a JSON form is displayed below: Figure 25 ----- The country_code element is compared with RU (Russian language), BY (Belarusian language), “UA” (Ukrainian language), “AZ” (Azerbaijani language), “AM” (Armenian language), “TJ” (Tajik language), “KZ” (Kazakh language), “KG” (Kyrgyz language), “UZ” (Uzbek language) and “SY” (Syriac language): Figure 26 The systems that have one of the languages enumerated above will not be encrypted. The priority for the current process is set to high by calling the SetPriorityClass routine (0x80 = **HIGH_PRIORITY_CLASS):** Figure 27 The executable retrieves the command-line string for the process and then returns an array of pointers to the command-line arguments: Figure 28 It’s important to mention that the malware can run with one of the following parameters: “– Admin”, “–Task”, “–AutoStart”, “–ForNetRes”, and “–Service”. We’ll describe the execution flows with different parameters later on. All process IDs that correspond to the processes on the system are retrieved by calling the EnumProcesses API: Figure 29 Each process object is opened by the ransomware using OpenProcess (0x410 = **PROCESS_QUERY_INFORMATION | PROCESS_VM_READ):** Figure 30 ----- The malware extracts a handle for each module from a process that was successfully opened: Figure 31 The GetModuleBaseNameW function is used to retrieve the base name of a module that is compared with the name of the executable (in our case, “wininet_dump.exe”): Figure 32 The binary performs a lot of XOR operations (key = 0x80) in order to decrypt relevant strings. The next figure contains a buffer with the C2 server securebiz[.]org: Figure 33 The ransomware opens the Run registry key using RegOpenKeyExW (0x80000001 = **HKEY_CURRENT_USER and 0xF003F = KEY_ALL_ACCESS):** ----- Figure 34 The process is looking for a value called “SysHelper”, which doesn’t exist at this time: Figure 35 The UuidCreate function is used to generate a new UUID (16 random bytes): Figure 36 The process converts the UUID to a string using the UuidToStringW API: Figure 37 A new directory based on the UUID is created by the malware: Figure 38 The CopyFileW routine is utilized to copy the executable to a new file in the above directory: ----- Figure 39 The ransomware establishes persistence on the host by creating an entry called “SysHelper” under the Run registry key, which will run the executable with the “–AutoStart” parameter whenever the user logs on: Figure 40 The binary denies “Everyone” to delete the folder created above using the icacls command, as highlighted in figure 41: Figure 41 A second persistence mechanism consists of creating a scheduled task (using COM objects) that will run the ransomware every 5 minutes. The malicious file initializes the COM library on the current thread using the CoInitialize function: Figure 42 ----- We have observed that the implementation is similar to the one presented at [https://docs.microsoft.com/en-us/windows/win32/taskschd/time-trigger-example–c—,](https://docs.microsoft.com/en-us/windows/win32/taskschd/time-trigger-example--c---) however we’ll dig deeper and explain how the assembly code looks like. The CoInitializeSecurity routine is used to register and set the default security values for the process (0x6 = RPC_C_AUTHN_LEVEL_PKT_PRIVACY and 0x3 = **RPC_C_IMP_LEVEL_IMPERSONATE):** Figure 43 The process creates an object with the CLSID {0F87369F-A4E5-4CFC-BD3E73E6154572DD}, which implements the Schedule.Service class for operating the Windows Task Scheduler Service: Figure 44 You can notice if you follow the C++ implementation mentioned above that in a case of a function call such as p -> f(a,b), the assembly representation contains 3 parameters pushed on the stack (because the pointer p is pushed as well). An example of such a call is represented by the ITaskService::GetFolder method, which gets a folder of registered tasks: Figure 45 A task called “Time Trigger Task” is deleted using the ITaskFolder::DeleteTask method: Figure 46 ----- The ITaskService::NewTask function is utilized to create an empty task definition object: Figure 47 An example of a safe release when the pointer is no longer used is shown in figure 48: Figure 48 The binary retrieves the registration information of the task (the description, the author, and the date the task is registered) by calling the ITaskDefinition::get_RegistrationInfo method: Figure 49 IRegistrationInfo::put_Author is used to set the author of the task to “Author Name”: Figure 50 The ransomware retrieves the principal for the task (which provides the security credentials) by calling the ITaskDefinition::get_Principal function: Figure 51 The security logon type is set to 0x3 (TASK_LOGON_INTERACTIVE_TOKEN), which means that the task will be run only in an existing interactive session: Figure 52 ----- ITaskDefinition::get_Settings is utilized to retrieve the settings that describe how the Task Scheduler performs the task: Figure 53 The file sets a Boolean value to 0xFFFFFFFF (VARIANT_TRUE) that indicates the Task Scheduler can start the task at any time after its scheduled time has elapsed using the ITaskSettings::put_StartWhenAvailable method: Figure 54 The amount of time the Task Scheduler will wait for an idle condition to occur is set to 5 minutes via a function call to IIdleSettings::put_WaitTimeout: Figure 55 ITaskDefinition::get_Triggers is used to get a collection of triggers used to start the task: Figure 56 The executable creates a new trigger for the task using the ITriggerCollection::Create method (0x1 = TASK_TRIGGER_TIME): Figure 57 There is a QueryInterface call with a parameter set as CLSID {B45747E0-EBA7-4276-9F2985C5BB300006} – IID_ITimeTrigger: ----- Figure 58 The identifier for the trigger is set to “Trigger1” using the ITrigger::put_Id function: Figure 59 The ransomware sets the date and time when the trigger is deactivated by calling the ITrigger::put_EndBoundary method: Figure 60 The system time is extracted via a call to the _time64 function: Figure 61 The malware formats the system time into a human-readable form using strftime: Figure 62 The malicious binary sets the date and time when the trigger is activated by calling the ITrigger::put_StartBoundary method: Figure 63 IActionCollection::Create is utilized to create and add a new action to the collection (0x0 = **TASK_ACTION_EXEC):** ----- Figure 64 There is a QueryInterface call with a parameter set as CLSID {4c3d624d-fd6b-49a3-b9b709cb3cd3f047} – IID_IExecAction: Figure 65 The path of the executable is set to the copied file using the IExecAction::put_Path method: Figure 66 The “–Task” argument is added by calling the IExecAction::put_Arguments function: Figure 67 Finally, the malware uses the ITaskFolder::RegisterTaskDefinition method to create the task called “Time Trigger Task” (0x6 = TASK_CREATE_OR_UPDATE): Figure 68 Here is the newly created scheduled task in Windows Task Scheduler: ----- Figure 69 The ransomware launches itself with the following parameters “–Admin IsNotAutoStart IsNotTask” (IsNotAutoStart = malware didn’t run based on the Run registry key, IsNotTask = malware didn’t run based on the scheduled task): Figure 70 **“–Task“ parameter** We’ll only highlight different actions that are performed by the ransomware running with this parameter without mentioning the same actions as in the case of running with no parameters. GetAdaptersInfo is utilized to retrieve adapter information (including the MAC address) for the localhost: Figure 71 The malware calls the CryptAcquireContextW API in order to obtain a handle to a particular key container within a cryptographic service provider (0x1 = PROV_RSA_FULL and 0xF0000000 = CRYPT_VERIFYCONTEXT): ----- Figure 72 The binary creates a handle to a CSP hash object using the CryptCreateHash API (0x8003 = **CALG_MD5):** Figure 73 The ransomware hashes a buffer that contains the MAC address extracted above via a function call to CryptHashData: Figure 74 The MD5 hash value is extracted by calling the CryptGetHashParam routine (0x2 = **HP_HASHVAL):** Figure 75 A new thread is created by calling the CreateThread API: Figure 76 ----- **Thread activity – sub_16E690** The RegOpenKeyExW function is used to open the “Software\Microsoft\Windows\CurrentVersion” registry key (0x80000001 = **HKEY_CURRENT_USER and 0xF003F = KEY_ALL_ACCESS):** Figure 77 The process is looking for a value named “SysHelper”, which doesn’t exist at this time (this is different from the one in figure 34): Figure 78 The entry from above is created, and its value is set to 1 using the RegSetValueExW API: Figure 79 The executable tries to locate a file called “bowsakkdestx.txt” in the “C:\Users\ \AppData\Local” directory, which doesn’t exist on our machine: Figure 80 There is a function call to InternetOpenW similar to the one presented in figure 23 (with the same user agent). The binary performs a GET request to the C2 server securebiz[.]org with the parameter pid = MD5(MAC address): ----- Figure 81 The response from the server is read using the InternetReadFile function: Figure 82 The binary creates the file called “bowsakkdestx.txt” using fopen: Figure 83 The file is populated using a function call to fwrite (the C2 server was down during our analysis, so we emulated the network communications using FakeNet): Figure 84 An example of a real response can be seen at https://app.any.run/tasks/900f626a-2bf6-48b285f9-2328f2b2d0d2/ and contains 2 elements: “public_key” and “id”. The malware wants to extract the “public_key” value from the response: Figure 85 ----- Even though the C2 server was down, the binary comes with a hard-coded RSA public key. The file from above is deleted in any case: Figure 86 Using multiple XOR operations with 0x80, the ransomware decrypts the RSA public key in PKCS1 format, a victim ID, and a URL that leads to another malicious file at http[:]//securebiz[.]org/files/1/build3.exe: Figure 87 We continue to analyze the main thread. A mutex called “{1D6FC66E-D1F3-422C-8A53C0BBCF3D900D}” is created via a function call to CreateMutexA: ----- Figure 88 The malware decrypts the ransom note using the XOR operator: Figure 89 The following information is also decrypted (a list of files to be skipped, a list of extensions to be skipped, and a list of directories to be skipped): ntuser.dat, ntuser.dat.LOG1, ntuser.dat.LOG2, ntuser.pol .sys, .ini, .DLL, .dll, .blf, .bat, .lnk, .regtrans-ms C:\SystemID\, C:\Users\Default User\, C:\Users\Public\, C:\Users\All Users\, C:\Users\Default\, C:\Documents and Settings\, C:\ProgramData\, C:\Recovery\, C:\System Volume Information\, C:\Users\%username%\A”ppData\Roaming\, C:\Users\%username%\AppData\Local\, C:\Windows\, C:\PerfLogs\, C:\ProgramData\Microsoft\, C:\ProgramData\Package Cache\, C:\Users\Public\, C:\$Recycle.Bin\, C:\$WINDOWS.~BT\, C:\dell\, C:\Intel\, C:\MSOCache\, C:\Program Files\, C:\Program Files (x86)\, C:\Games\, C:\Windows.old\ D:\Users\%username%\AppData\Roaming\, D:\Users\%username%\AppData\Local\, D:\Windows\, D:\PerfLogs\, D:\ProgramData\Desktop\, D:\ProgramData\Microsoft\, D:\ProgramData\Package Cache\, D:\Users\Public\, D:\$Recycle.Bin\, D:\$WINDOWS.~BT\, D:\dell\, D:\Intel\, D:\MSOCache\, D:\Program Files\, D:\Program Files (x86)\, D:\Games\ E:\Users\%username%\AppData\Roaming\, E:\Users\%username%\AppData\Local\, E:\Windows\, E:\PerfLogs\, E:\ProgramData\Desktop\, E:\ProgramData\Microsoft\, E:\ProgramData\Package Cache\, E:\Users\Public\, E:\$Recycle.Bin\, E:\$WINDOWS.~BT\, E:\dell\, E:\Intel\, E:\MSOCache\, E:\Program Files\, E:\Program Files (x86)\, E:\Games\ F:\Users\%username%\AppData\Roaming\, F:\Users\%username%\AppData\Local\, F:\Windows\, F:\PerfLogs\, F:\ProgramData\Desktop\, F:\ProgramData\Microsoft\, F:\Users\Public\, F:\$Recycle.Bin\, F:\$WINDOWS.~BT\, F:\dell\, F:\Intel\ ----- The executable retrieves the user name associated with the current thread by calling the GetUserNameW API: Figure 90 The malicious process is looking for a file called “PersonalID.txt” that doesn’t exist at this time: Figure 91 CreateDirectoryW is utilized to create a directory called “C:\SystemID”: Figure 92 The ransomware creates the file “C:\SystemID\PersonalID.txt” and writes the victim ID to it: Figure 93 It’s very uncommon that the malware searches the system for a file called “I:\5d2860c89d774.jpg” (0xC0000000 = GENERIC_READ | GENERIC_WRITE, 0x1 = **FILE_SHARE_READ, 0x3 = OPEN_EXISTING and 0x80 = FILE_ATTRIBUTE_NORMAL):** Figure 94 ----- LoadCursorW is used to load the standard arrow resource from the executable (0x7F00 = **IDC_ARROW):** Figure 95 The binary registers a window class using the RegisterClassExW routine: Figure 96 CreateWindowExW is utilized to create a new window called “LPCWSTRszTitle” (0xCF0000 = WS_OVERLAPPEDWINDOW and 0x80000000 = CW_USEDEFAULT): Figure 97 The window created earlier is hided by calling the ShowWindow routine (0x0 = SW_HIDE): Figure 98 We need to analyze the window procedure defined in figure 96 (sub_16BAE0). The malware uses the ntdllDefWindowProcW API in order to call the default window procedure whenever a particular message needs to be processed (0x24 = **WM_GETMINMAXINFO, 0x81 = WM_NCCREATE, 0x83 = WM_NCCALCSIZE and 0x1 =** **WM_CREATE):** ----- Figure 99 GetLogicalDrives is used to retrieve a bitmask that represents the available disk drives: Figure 100 The ransomware forces the system not to display the critical-error message box and sending these errors to the calling process (0x1 = SEM_FAILCRITICALERRORS): Figure 101 The file extracts the type of the drives by calling the GetDriveTypeA API and compares it with 2 (DRIVE_REMOVABLE), 3 (DRIVE_FIXED), 4 (DRIVE_REMOTE) and 6 (DRIVE_RAMDISK): Figure 102 Two new threads are created using the CreateThread function: ----- Figure 103 Figure 104 The file retrieves a message from the message queue by calling the GetMessageW routine, translates virtual-key messages into character messages using TranslateMessage, and finally dispatches a message to a window procedure using DispatchMessageW: Figure 105 **Thread activity – sub_16FD80** The malware enumerates all resources on the network via a function call to WNetOpenEnumW (0x2 = RESOURCE_GLOBALNET): Figure 106 WNetEnumResourceW is utilized to further enumerate the network resources: ----- Figure 107 The message DBT_DEVICEREMOVECOMPLETE (“A device or piece of media has been removed”) is sent to the window created earlier, and its procedure will handle it: Figure 108 When the window procedure receives the message, it calls the GetComputerNameW API in order to get the NetBIOS name of the local machine: Figure 109 **Thread activity – sub_16F130** The ransomware creates the ransom note called “_readme.txt” in every directory that it encrypts: Figure 110 The ransom note is populated by calling the WriteFile function, as shown in figure 111: ----- Figure 111 An example of a ransom note is highlighted below: Figure 112 The files are enumerated using the FindFirstFileW and FindNextFileW APIs: Figure 113 The directories mentioned under figure 89 will not be encrypted. The file extension is extracted by calling the PathFindExtensionW routine: Figure 114 The files and file extensions mentioned under figure 89 will be skipped. The ransomware also avoids files that have the “.tisc” extension because this will be appended after the encryption is complete: ----- Figure 115 Each targeted file is opened using the CreateFileW routine: Figure 116 The file content is read by calling the ReadFile function: Figure 117 There is a function call to CryptAcquireContextW (as in figure 72) and another one to CryptCreateHash (as in figure 73). The malware hashes a buffer that contains the first 5 bytes from the targeted file and the RSA public key, as shown in figure 118: Figure 118 The MD5 hash value is extracted by calling the CryptGetHashParam routine (0x2 = HP_HASHVAL): ----- Figure 119 The binary creates a new UUID (16 random bytes) by calling the UuidCreate API (which internally uses CryptGenRandom): Figure 120 The process converts the UUID to a string using the UuidToStringA API: Figure 121 Based on the value generated above, the ransomware constructs the following Salsa20 matrix: Figure 122 A snippet of the Salsa20 algorithm implemented by the malware is presented below: ----- Figure 123 The process encrypts the file content using the Salsa20 algorithm, however the first 5 bytes from the targeted file are not encrypted. Based on the strings presented in figure 124 and our analysis of the RSA implementation, we believe that the malware developers have included [the OpenSSL code found at https://github.com/openssl/openssl (or similar code taken from](https://github.com/openssl/openssl) other projects): ----- Figure 124 The binary encrypts the UUID generated before using the RSA public key embedded in the file: Figure 125 The encrypted content is written to the file using WriteFile, as shown below: ----- Figure 126 The malicious binary writes the encrypted UUID using the same API: Figure 127 The offline ID is also added to the encrypted file: Figure 128 The value “{36A698B9-D67C-4E07-BE82-0EC5B14B4DF5}” is also added to the encrypted file: Figure 129 The encrypted file extension is changed to “.tisc” by the ransomware: ----- Figure 130 The encrypted file has the following structure that highlights different elements: Figure 131 **“–AutoStart“ parameter** The activity is similar to the case discussed above. **“–Admin IsNotAutoStart IsNotTask“ parameters** The binary establishes a connection to the service control manager by calling the OpenSCManagerW routine (0x1 = SC_MANAGER_CONNECT): Figure 132 A service called “MYSQL” is opened by the process via a function call to OpenServiceW (0x20 = SERVICE_STOP): ----- Figure 133 Whether the service would exist on a host, the ransomware would stop it using the ControlService API: Figure 134 The file decrypts another URL that will be used to download more malicious files, http[:]//znpst[.]top/dl/build2.exe: Figure 135 A new thread is created by calling the CreateThread function: Figure 136 **Thread activity – StartAddress (sub_16DBD0)** UuidCreate is utilized to generate a new UUID: ----- Figure 137 The UuidToStringA routine is used to convert the UUID to a string: Figure 138 The malicious process creates a new directory based on the UUID generated above: Figure 139 The binary performs a GET request to http[:]//znpst[.]top/dl/build2.exe using InternetOpenUrlA: Figure 140 According to the analysis from https://any.run/report/cd6bf2f554a9aa446cb36d28e374e1010268cbda8f55eb0043fbe6e2724 128be/152e55c2-5e8f-4fe2-a764-7876ba00f03e, the above executable is a malware called Ursnif (banking Trojan). The status code is extracted by calling the HttpQueryInfoW routine (0x20000013 = **HTTP_QUERY_FLAG_NUMBER | HTTP_QUERY_STATUS_CODE):** Figure 141 ----- A file called build2.exe is created in the new directory: Figure 142 The InternetReadFile routine is utilized to read the executable from the server, as displayed in figure 143: Figure 143 ShellExecuteA is used to run the newly created executable: Figure 144 Figure 145 The binary performs a GET request to http[:]//securebiz[.]org/files/1/build3.exe using InternetOpenUrlA: ----- Figure 146 According to multiple online resources, the above file is supposed to be an infamous infostealer called Vidar. The process of reading data from the server, creating the malicious file, etc. is the same as above and isn’t explained again. For completeness, we will also provide details about the other parameters that can be used, [as displayed at https://app.any.run/tasks/635cd7df-e4b7-4d1a-a937-e8d8599e6c72/.](https://app.any.run/tasks/635cd7df-e4b7-4d1a-a937-e8d8599e6c72/) **“–ForNetRes “jwvfPPgZoQyg6Q6he8weP7iDsH9FKc74ICjysAt2″** **r77yXePcnmrctJPWrZCcbJgUlAtOa1FC9Na710t1 IsNotAutoStart IsNotTask”** **parameters** The binary creates a mutex called “{FBB4BCC6-05C7-4ADD-B67B-A98A697323C1}” using the CreateMutexA API: Figure 147 According to online sources, the first parameter can be considered as a Key and the second one as a Personal ID. The malware performs a hashing operation (MD5) on the Key: Figure 148 The hash value is extracted using the CryptGetHashParam function (0x2 = HP_HASHVAL): Figure 149 The execution flow is similar to the one starting with figure 90 and will not be reiterated. ----- **–Service 4904 jwvfPPgZoQyg6Q6he8weP7iDsH9FKc74ICjysAt2** **r77yXePcnmrctJPWrZCcbJgUlAtOa1FC9Na710t1” parameters** The above value represents the parent process ID, which is converted from string to a long integer value: Figure 150 The ransomware opens the local process object using the OpenProcess routine (0x100000 = **SYNCHRONIZE):** Figure 151 After the parent process enters the signaled state, the file dispatches incoming sent messages, checks for posted messages, and then retrieves the messages: Figure 152 The malicious binary retrieves the exit code of the current process and then kills itself using TerminateProcess: Figure 153 Finally, we describe the case when the country code belongs to the following list: “RU”, “BY”, “UA”, “AZ”, “AM”, “TJ”, “KZ”, “KG”, “UZ” and “SY”. CreateMutexA is utilized to create a mutex called “{FBB4BCC6-05C7-4ADD-B67BA98A697323C1}”: ----- Figure 154 A batch file called “delself.bat” is created in the %TEMP% directory: Figure 155 The above file is populated using the WriteFile API, and its content is displayed below: Figure 156 Figure 157 After the batch file finishes its execution, the malicious file and the script are deleted: Figure 158 References [MSDN: https://docs.microsoft.com/en-us/windows/win32/api/,](https://docs.microsoft.com/en-us/windows/win32/api/) https://docs.microsoft.com/enus/windows/win32/taskschd/time-trigger-example–c— ----- Fakenet: [https://github.com/fireeye/flare-fakenet-ng](https://github.com/fireeye/flare-fakenet-ng) Any.run: [https://app.any.run/tasks/635cd7df-e4b7-4d1a-a937-e8d8599e6c72/](https://app.any.run/tasks/635cd7df-e4b7-4d1a-a937-e8d8599e6c72/) VirusTotal: https://www.virustotal.com/gui/file/4380c45fd46d1a63cffe4d37cf33b0710330a766b7700af86 020a936cdd09cbe MalwareBazaar: https://bazaar.abuse.ch/sample/4380c45fd46d1a63cffe4d37cf33b0710330a766b7700af8602 0a936cdd09cbe/ OpenSSL: [https://github.com/openssl/openssl](https://github.com/openssl/openssl) INDICATORS OF COMPROMISE C2 domains: securebiz[.]org znpst[.]top SHA256: 4380c45fd46d1a63cffe4d37cf33b0710330a766b7700af86020a936cdd09cbe Scheduled Task: “Time Trigger Task” Registry key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\SysHelper User-agent: “Microsoft Internet Explorer” PDB paths: “C:\xudihiguhe\jegovicatusoca\jijetogez\winucet\xusev\kucor.pdb” “e:\doc\my work (c++)_git\encryption\release\encrypt_win_api.pdb” URLs: http[:]//securebiz[.]org/fhsgtsspen6/get.php http[:]//securebiz.org/files/1/build3.exe http[:]//znpst.top/dl/build2.exe https[:]//api.2ip.ua/geo.json -----