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/wp-content/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.

Analyst: @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:

The malware calls the LoadLibraryW function in order to load the “kernel32.dll” file into the address space of the process:

The GetProcAddress API is utilized to retrieve the address of the “VirtualProtect” function:

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:

There is also a lot of garbage code in the binary that is never executed, as shown in figure 5:

The process jumps at the beginning of the new shellcode, as highlighted below:

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):

The ransomware extracts information about the first module of the process using the Module32First API:

The malicious process allocates and populates a new memory area via a function call to VirtualAlloc (0x1000 = MEM_COMMIT and 0x40 = PAGE_EXECUTE_READWRITE):

The process jumps at the beginning of the new shellcode, as highlighted below:

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:

The file registers a window class called “saodkfnosa9uin” using the RegisterClassExA routine:

The CreateWindowExA function is utilized to create a new window (0x200 = WS_EX_CLIENTEDGE, 0xCF0000 = WS_OVERLAPPEDWINDOW, 0x80000000 = CW_USEDEFAULT):

The process allocates a new memory area via a function call to VirtualAlloc (0x1000 = MEM_COMMIT and 0x4 = PAGE_READWRITE):

The ransomware extracts the content of the STARTUPINFO structure:

The malware creates a copy of itself in a suspended state via a call to CreateProcessA (0x08000004 = CREATE_NO_WINDOW | CREATE_SUSPENDED):

GetThreadContext is used to retrieve the context of a specific thread:

The malicious binary unmaps a view of a section from the address of the newly created process using ZwUnmapViewOfSection:

The VirtualAllocEx routine is utilized to allocate new space in the newly created process (0x3000 = MEM_COMMIT | MEM_RESERVE and 0x40 = PAGE_EXECUTE_READWRITE):

The ransomware writes data to the area allocated above using multiple calls to ZwWriteVirtualMemory, as displayed in figure 20:

The SetThreadContext function is used to set the context for the remote thread:

The binary resumes the main thread of the suspended process using ResumeThread:

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”):

The malware performs a GET request to https[:]//api.2ip.ua/geo.json, which reveals details about the location of the IP address:

InternetReadFile is used to read the response from the server, and an example of a JSON form is displayed below:

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):

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):

The executable retrieves the command-line string for the process and then returns an array of pointers to the command-line arguments:

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:

Each process object is opened by the ransomware using OpenProcess (0x410 = PROCESS_QUERY_INFORMATION | PROCESS_VM_READ):

The malware extracts a handle for each module from a process that was successfully opened:

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”):

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:

The ransomware opens the Run registry key using RegOpenKeyExW (0x80000001 = HKEY_CURRENT_USER and 0xF003F = KEY_ALL_ACCESS):

The process is looking for a value called “SysHelper”, which doesn’t exist at this time:

The UuidCreate function is used to generate a new UUID (16 random bytes):

The process converts the UUID to a string using the UuidToStringW API:

A new directory based on the UUID is created by the malware:

The CopyFileW routine is utilized to copy the executable to a new file in the above directory:

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:

The binary denies “Everyone” to delete the folder created above using the icacls command, as highlighted in 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:

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—, 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):

The process creates an object with the CLSID {0F87369F-A4E5-4CFC-BD3E-73E6154572DD}, which implements the Schedule.Service class for operating the Windows Task Scheduler Service:

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:

A task called “Time Trigger Task” is deleted using the ITaskFolder::DeleteTask method:

The ITaskService::NewTask function is utilized to create an empty task definition object:

An example of a safe release when the pointer is no longer used is shown in 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:

IRegistrationInfo::put_Author is used to set the author of the task to “Author Name”:

The ransomware retrieves the principal for the task (which provides the security credentials) by calling the ITaskDefinition::get_Principal function:

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:

ITaskDefinition::get_Settings is utilized to retrieve the settings that describe how the Task Scheduler performs the task:

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:

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:

ITaskDefinition::get_Triggers is used to get a collection of triggers used to start the task:

The executable creates a new trigger for the task using the ITriggerCollection::Create method (0x1 = TASK_TRIGGER_TIME):

There is a QueryInterface call with a parameter set as CLSID {B45747E0-EBA7-4276-9F29-85C5BB300006} – IID_ITimeTrigger:

The identifier for the trigger is set to “Trigger1” using the ITrigger::put_Id function:

The ransomware sets the date and time when the trigger is deactivated by calling the ITrigger::put_EndBoundary method:

The system time is extracted via a call to the _time64 function:

The malware formats the system time into a human-readable form using strftime:

The malicious binary sets the date and time when the trigger is activated by calling the ITrigger::put_StartBoundary method:

IActionCollection::Create is utilized to create and add a new action to the collection (0x0 = TASK_ACTION_EXEC):

There is a QueryInterface call with a parameter set as CLSID {4c3d624d-fd6b-49a3-b9b7-09cb3cd3f047} – IID_IExecAction:

The path of the executable is set to the copied file using the IExecAction::put_Path method:

The “–Task” argument is added by calling the IExecAction::put_Arguments function:

Finally, the malware uses the ITaskFolder::RegisterTaskDefinition method to create the task called “Time Trigger Task” (0x6 = TASK_CREATE_OR_UPDATE):

Here is the newly created scheduled task in Windows Task Scheduler:

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):

“–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:

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):

The binary creates a handle to a CSP hash object using the CryptCreateHash API (0x8003 = CALG_MD5):

The ransomware hashes a buffer that contains the MAC address extracted above via a function call to CryptHashData:

The MD5 hash value is extracted by calling the CryptGetHashParam routine (0x2 = HP_HASHVAL):

A new thread is created by calling the CreateThread API:

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):

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):

The entry from above is created, and its value is set to 1 using the RegSetValueExW API:

The executable tries to locate a file called “bowsakkdestx.txt” in the “C:\Users\<User>\AppData\Local” directory, which doesn’t exist on our machine:

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):

The response from the server is read using the InternetReadFile function:

The binary creates the file called “bowsakkdestx.txt” using fopen:

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):

An example of a real response can be seen at https://app.any.run/tasks/900f626a-2bf6-48b2-85f9-2328f2b2d0d2/ and contains 2 elements: “public_key” and “id”. The malware wants to extract the “public_key” value from the response:

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:

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:

We continue to analyze the main thread. A mutex called “{1D6FC66E-D1F3-422C-8A53-C0BBCF3D900D}” is created via a function call to CreateMutexA:

The malware decrypts the ransom note using the XOR operator:

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:

The malicious process is looking for a file called “PersonalID.txt” that doesn’t exist at this time:

CreateDirectoryW is utilized to create a directory called “C:\SystemID”:

The ransomware creates the file “C:\SystemID\PersonalID.txt” and writes the victim ID to it:

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):

LoadCursorW is used to load the standard arrow resource from the executable (0x7F00 = IDC_ARROW):

The binary registers a window class using the RegisterClassExW routine:

CreateWindowExW is utilized to create a new window called “LPCWSTRszTitle” (0xCF0000 = WS_OVERLAPPEDWINDOW and 0x80000000 = CW_USEDEFAULT):

The window created earlier is hided by calling the ShowWindow routine (0x0 = SW_HIDE):

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):

GetLogicalDrives is used to retrieve a bitmask that represents the available disk drives:

The ransomware forces the system not to display the critical-error message box and sending these errors to the calling process (0x1 = SEM_FAILCRITICALERRORS):

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):

Two new threads are created using the CreateThread function:

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:

Thread activity – sub_16FD80

The malware enumerates all resources on the network via a function call to WNetOpenEnumW (0x2 = RESOURCE_GLOBALNET):

WNetEnumResourceW is utilized to further enumerate the network resources:

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:

When the window procedure receives the message, it calls the GetComputerNameW API in order to get the NetBIOS name of the local machine:

Thread activity – sub_16F130

The ransomware creates the ransom note called “_readme.txt” in every directory that it encrypts:

The ransom note is populated by calling the WriteFile function, as shown in figure 111:

An example of a ransom note is highlighted below:

The files are enumerated using the FindFirstFileW and FindNextFileW APIs:

The directories mentioned under figure 89 will not be encrypted. The file extension is extracted by calling the PathFindExtensionW routine:

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:

Each targeted file is opened using the CreateFileW routine:

The file content is read by calling the ReadFile function:

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:

The MD5 hash value is extracted by calling the CryptGetHashParam routine (0x2 = HP_HASHVAL):

The binary creates a new UUID (16 random bytes) by calling the UuidCreate API (which internally uses CryptGenRandom):

The process converts the UUID to a string using the UuidToStringA API:

Based on the value generated above, the ransomware constructs the following Salsa20 matrix:

A snippet of the Salsa20 algorithm implemented by the malware is presented below:

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 other projects):

The binary encrypts the UUID generated before using the RSA public key embedded in the file:

The encrypted content is written to the file using WriteFile, as shown below:

The malicious binary writes the encrypted UUID using the same API:

The offline ID is also added to the encrypted file:

The value “{36A698B9-D67C-4E07-BE82-0EC5B14B4DF5}” is also added to the encrypted file:

The encrypted file extension is changed to “.tisc” by the ransomware:

The encrypted file has the following structure that highlights different elements:

“–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):

A service called “MYSQL” is opened by the process via a function call to OpenServiceW (0x20 = SERVICE_STOP):

Whether the service would exist on a host, the ransomware would stop it using the ControlService API:

The file decrypts another URL that will be used to download more malicious files, http[:]//znpst[.]top/dl/build2.exe:

A new thread is created by calling the CreateThread function:

Thread activity – StartAddress (sub_16DBD0)

UuidCreate is utilized to generate a new UUID:

The UuidToStringA routine is used to convert the UUID to a string:

The malicious process creates a new directory based on the UUID generated above:

The binary performs a GET request to http[:]//znpst[.]top/dl/build2.exe using InternetOpenUrlA:

According to the analysis from https://any.run/report/cd6bf2f554a9aa446cb36d28e374e1010268cbda8f55eb0043fbe6e2724128be/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):

A file called “build2.exe” is created in the new directory:

The InternetReadFile routine is utilized to read the executable from the server, as displayed in figure 143:

ShellExecuteA is used to run the newly created executable:

The binary performs a GET request to http[:]//securebiz[.]org/files/1/build3.exe using InternetOpenUrlA:

According to multiple online resources, the above file is supposed to be an infamous info-stealer 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/.

“–ForNetRes “jwvfPPgZoQyg6Q6he8weP7iDsH9FKc74ICjysAt2″ r77yXePcnmrctJPWrZCcbJgUlAtOa1FC9Na710t1 IsNotAutoStart IsNotTask” parameters

The binary creates a mutex called “{FBB4BCC6-05C7-4ADD-B67B-A98A697323C1}” using the CreateMutexA API:

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:

The hash value is extracted using the CryptGetHashParam function (0x2 = HP_HASHVAL):

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:

The ransomware opens the local process object using the OpenProcess routine (0x100000 = SYNCHRONIZE):

After the parent process enters the signaled state, the file dispatches incoming sent messages, checks for posted messages, and then retrieves the messages:

The malicious binary retrieves the exit code of the current process and then kills itself using TerminateProcess:

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-B67B-A98A697323C1}”:

A batch file called “delself.bat” is created in the %TEMP% directory:

The above file is populated using the WriteFile API, and its content is displayed below:

After the batch file finishes its execution, the malicious file and the script are deleted:

References

MSDN: https://docs.microsoft.com/en-us/windows/win32/api/, https://docs.microsoft.com/en-us/windows/win32/taskschd/time-trigger-example–c—

Fakenet: https://github.com/fireeye/flare-fakenet-ng

Any.run: https://app.any.run/tasks/635cd7df-e4b7-4d1a-a937-e8d8599e6c72/

VirusTotal: https://www.virustotal.com/gui/file/4380c45fd46d1a63cffe4d37cf33b0710330a766b7700af86020a936cdd09cbe

MalwareBazaar: https://bazaar.abuse.ch/sample/4380c45fd46d1a63cffe4d37cf33b0710330a766b7700af86020a936cdd09cbe/

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