Phobos Ransomware

17 minute read

Executive summary

This report provides a comprehensive analysis of a Phobos ransomware sample, detailing its infection and encryption mechanisms, as well as its anti-detection and persistence strategies. Upon execution, Phobos initiates a series of obfuscation tactics, including anti-sandbox delays, and achieves persistence through registry modifications and file replication in startup directories. It employs cryptographic measures by generating unique AES keys and encrypting them with RSA, allowing for both thorough and efficient file encryption across local and network resources. The malware’s multi-threaded architecture enables rapid distribution and concurrent encryption over shared network drives, increasing the impact on large networked environments. Further, Phobos ensures it operates as a single instance through mutex creation and selectively terminates processes that could interfere with encryption, such as backup and database services. With effective post-encryption routines, Phobos generates a ransom note, completes system resource cleanup, and securely exits, leaving the system in an encrypted state with limited recovery options outside of the ransom payment. This report’s findings enhance understanding of Phobos ransomware’s robust technical design, facilitating better detection and mitigation strategies.

Basic Analysis

Static Phase

Sample information:

Attribute	Value
File name	Sample
File size	72.0 KB
File type	PE32 executable (GUI) Intel 80386, for MS Windows
MD5	9A6EF5689148A33F5F7FDF0A65706EA3
SHA1	770030699B2FA7B9E5F122EBED3E0F0FCB9C06E2
SHA256	D2404D41F96F5E12D518D61197FD38598FBBC6F46444CF84D95CD975A666B205
Packer / compiler info	Microsoft Visual C++
Compile time	2019-05-14 03:57:04

Only resource found is manifest file:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

This manifest make sure that:

The application will run with the user’s current privileges (it will not try to elevate privileges).
The application will not have special access to UI accessibility functions.
It avoids triggering User Account Control (UAC) prompts when launched, as it does not request administrator rights.

Looking at strings found nothing interesting only some imports and junk stings seems to be encrypted. The thing took my eye in this information gathering is that KANAL told me that the program uses heavy cryptography:

CRC32 :: 0000D190 :: 0040EB90
	Referenced at 00404CDE
CryptDecrypt [Import] :: 0000A004 :: 0040B004
	Referenced at 00404028
CryptEncrypt [Import] :: 0000A00C :: 0040B00C
	Referenced at 00403FE9
CryptGenRandom [Import] :: 0000A014 :: 0040B014
	Referenced at 00404073
	Referenced at 0040422D

This means that might be ransomware or only some obfuscation, but I tend to be more in ransomware thoughts. Also, high entropy is a good indicator for packing, but this does not seem like packed file.

Behavioral Analysis

To start my behavioral analysis, I followed my own approach:

Take a registry snapshot using Regshot before running the file.
Open another machine to create virtual network (using inetsim) and monitor network traffic (using wireshark).
For processes and file system activities, I use procmon and process explorer.

Key observations from this phase is that:

The file took too long time to execute which mostly means that it uses some anti-sandboxing technique (likely sleep function)
It achieve persistence through copying itself into startup folder as well as registry Runkey

The program starts a new instance of itself under the parent process which take responsibility for all activities.

It’s ransomware using .acute extension renames all files with some id followed by the email to reach out i.e.[ challenge.zip.id[762A8F99-1096].[lockhelp@qq.com].acute]

From that information and a little search, it is Phobos Ransomware.

As I get this, I tried some more behaviour analysis on special crafted files to guess more about the encryption process and different behaviors between large and small files also the same file in different runs. To do that I made two binaries of 0x00 only 10kb, 1gb. After encryption found many interesting things:

This block is repeated at the end of all encrypted files which possibly the decryption key encrypted in the file also followed by the ransomware signature “LOCK96”.

The same file with same content (10kb file) among different tuns had different encrypted bytes.

The large file is being only encrypted from the end of the file and the rest of the file remains as it is.

Advance Analysis

Main function

At the start, there is only one function call which must be the main function.

The function starts with some Prologue, Stack Setup and Variable Initialization. After that there is call for three important functions:

mem_xor: takes three arguments the last is (size of config) and performs xor for memory values with this size, that could be just preprocessing for this data or checksum to make sure that’s the write data before loading it into memory.
load_sus_data_to_memory: this perform just some memory allocation and memory copying (just load some data to memory).

Those two functions could be just considered as preparation for the data, and nothing is valuable except the xor key gen algorithm.

String Decryption

The third call -which is most valuable is string_decryption which takes two arguments (0,0x1F)

Diving into this function, you can see some memory setting and value transfer which is just preparation for the most important two calls (crypt_intialize, crypt_decrypt_call).

The crypt_initialize function analyzed here leverages the Microsoft CryptoAPI to establish a cryptographic context and configure key parameters using a combination of CryptAcquireContextW, CryptImportKey, and CryptSetKeyParam. Based on the function’s parameters and values observed in memory, we conclude the that: Cryptographic Algorithm: RSA or AES

The call to CryptAcquireContextW specifies a provider type of 0x18 (PROV_RSA_AES), which indicates that this context can support both RSA and AES algorithms. Given that RSA and AES are distinct in usage (asymmetric versus symmetric cryptography), further details in the pbData structure and key length help to narrow down the likely algorithm.

Key and Parameter Settings via CryptSetKeyParam

CryptSetKeyParam is called dwParam set to 1, which corresponds to KP_MODE in CryptoAPI. This parameter is used to set the cipher mode for symmetric algorithms, especially relevant if AES is in use. However, pbData points to zeroes, suggesting that no specific mode was set in this function.
When pbData is zeroed or unspecified, CryptoAPI typically defaults to ECB (Electronic Codebook) mode if a symmetric algorithm like AES is in use. This mode does not require an initialization vector (IV) and operates with the simplest form of block encryption.
If the key material is indeed RSA, as suggested by the structured blob format, then KP_MODE would not apply directly to RSA encryption or signing. Instead, it may be included as a placeholder or default parameter setting within the function’s symmetric context setup.

After that initialization, the crypt_decrypt_call just call CryptDecrypt API which will just do the dirty staff and obtain our precious strings along the code execution:

%systemdrive%\\
Software\Microsoft\Windows\CurrentVersion\Explorer\ User Shell Folders
Global\\1096<<ID>><<ELVL>>
Software\Microsoft\Windows\CurrentVersion\Run
%localappdata%
<<Startup>>		<<Common Startup>>	runas
info.hta;info.txt;boot.ini;bootfont.bin;ntldr;ntdetect.com;io.sys
msftesql.exe;sqlagent. exe;sqlbrowser.exe;sqlservr. exe;sqlwriter.exe;oracle.exe;ocssd.exe;dbsnmp.exe;synctime.exe;agntsvc.exe;mydesktopqos.exe;isqlplussvc.exe;xfssvccon.exe;mydesktopservice.exe;ocautoupds.exe;agntsvc.exe;agntsvc.exe;agntsvc.exe;encsvc.exe;firefoxconfig.exe;tbirdconfig.exe;ocomm.exe;mysqld.exe;mysqld-nt.exe;mysqld-opt.exe;dbeng50.exe;sqbcoreservice.exe;excel.exe;infopath.exe;msaccess.exe;mspub.exe;onenote.exe;outlook.exe;powerpnt.exe;steam.exe;thebat.exe;thebat64.exe;thunderbird.exe;visio.exe;winword.exe;wordpad.exe
kernel32.dll;Wow64DisableWow64FsRedirection;Wow64RevertWow64FsRedirection

After that, the possible AES key used to encrypt files on the victim’s machine is being randomly generated by setting the seed to number of milliseconds that have elapsed since the system was started, which of course will be random each run then call _srand which is the start of key generation.

Next part is just system information collection as well as process information collection.

The next stage is Mutex creation.

The mutex name follows “Global\\1096<<ID»<<ELVL»” format. open mutex name: Global\1096762A8F9901 , Global\1096762A8F9900

At this point, the first thread is created which only performs some mutex checks, decrypt some configurations and open modules.

Next part of execution is one of the most important parts, which is achieving persistence.

Achieving Persistence

This function achieves persistence through three ways:

Create a copy of the file at %localappdata%

Create another copy at common startup.
Add itself to “Software\Microsoft\Windows\CurrentVersion\Run” registry key.

Free Files Handles

This thread is concerned with closing as many processes as possible to be able to encrypt all files of the system as some processes may interfere with encryption process. That is achieved through “check_runnig_procs_terminate_unwanted” function which act as following:

Call CreateToolhelp32Snapshot to take a snapshot specified processes (which is all running in my case).
Then use Process32FirstW to retrieves information about the first process encountered in a system snapshot.
Then opens this process, checks if it need to be terminated and finally terminate this process.
Get the next process and loop again till finish all processes.

Network Management

The network_things_thread function is designed to facilitate the enumeration, processing, and management of network resources within a specified scope, such as network shares or mapped drives. Operating in a multithreaded environment, the function allows for efficient, concurrent handling of network resource data, particularly when handling extensive network infrastructures which will be used to attack network shares. Purpose: network_things_thread initiates a thread to enumerate network resources and perform specified operations on each detected resource. This function is designed for environments where recursive network resource exploration is necessary, making it useful for tasks such as logging network shares, verifying network paths, or managing resource-specific data encryption. Operation:

Enumeration Initialization: Using the Windows API, the function opens an enumeration session based on the specified scope and resource parameters. If successful, it allocates memory buffers to temporarily hold resource information.
Resource Processing: For each network resource found, the function checks if the resource type or usage matches specific criteria (e.g., network shares or connected drives). If eligible, it performs further operations, such as comparing resource names, formatting paths, and preparing data for cryptographic processing.
Thread Creation for Encryption and Processing: When specific resources are identified (e.g., those not already processed), the function retrieves volume information and generates an encryption key based on network resource data. A separate thread is created to handle each resource’s cryptographic and network data generation, allowing for efficient, parallel processing.
Memory Management and Cleanup: After processing the network resources, the function closes the enumeration handle and releases allocated memory, ensuring no resource leaks in the multithreaded environment.

Workflow Summary:

Enumerate network resources based on specified scope.
Recursively process nested resources and check resource paths.
Generate cryptographic keys or network data and spawn threads to handle each resource.
Release resources and clean up memory allocations after enumeration.

This function’s multithreaded approach enables rapid network resource processing while maintaining control over memory allocation and thread lifecycle. This design ensures effective resource management and cryptographic processing across a wide network structure. From debugging found that htonl show the following IP [118].[42].[143].[153]

File Encryption

Now the most interesting part of the ransomware, File encryption. Phobos uses the WindowsCrypto API for encryption of files. There are several parallel threads to deploy encryption on each accessible disk or a network share.

As you see there is two threads for file encryption with slightly different functionality, but the core is just file encryption.

Operation

First, the thread decrypt some strings using the previously discussed function. Then, call function to create another thread which will do the same until reaching thread creation with thread_for_crypto.
This thread contain many important details but the most important one (in my opinion) is encryption_routin function call which will be looped.

The encryption_routin function is responsible for encrypting files based on certain conditions, such as the file’s size. It leverages Windows API calls to manage file access, attributes, and size checks before determining which encryption routine to apply. So, let us break it down in details:
- File Access and Initialization: The function begins by setting up the stack and preparing local variables. It opens the specified file using CreateFileW with read permissions (0x80000000). If it fails to open the file, the function exits.
- File Size Check: Using GetFileSizeEx, it retrieves the file size and checks if the operation succeeded. If unsuccessful, it closes the handle and exits.
- File Attributes Management: The function then retrieves the file’s attributes with GetFileAttributesW. If the file is read-only, it temporarily clears the read-only attribute using SetFileAttributesW to enable writing during encryption.
- Choosing the Encryption Method: Based on the file size, the function decides which encryption routine to apply: Large files trigger Encryption_for_large_files (above 180000 bytes long)Small files use Encryption_for_small_files.

Attribute Restoration and Cleanup: After encryption, if the read-only attribute was initially set, it is restored using SetFileAttributesW. Finally, the function closes any open file handles and returns to clean up the stack and restore the initial state.

Small File Encryption

The function is concerned with files below 180000 bytes long.it operate in many stages as following:

File Setup: It calculates file path details and sizes, then prepares to create a new encrypted file if the specified file does not already exist.
File Handling: Opens the input file for reading and creates a new output file for writing. Uses SetFilePointerEx to check the file size and ensure it is non-zero.
Encryption and Writing: Initializes the encryption key (crypt_intialize). Although the AES key is common to all the files that are encrypted in a single round, yet, each file is encrypted with a different initialization vector. The initialization vector is 16 bytes long, generated just before the file is open, and then passed to the encrypting function:

Reads data from the input file in chunks, aligns each chunk to a 16-byte boundary if needed, and encrypts it. Writes each encrypted chunk to the output file, verifying successful write operations. After the file is being encrypted successfully, the meta data is added such as original file name, IV Encrypted AES Key and file marker “LOCK96”

Cleanup: If encryption is completed successfully, the original file is deleted; otherwise, the output file is removed if incomplete. Closes all file handles and destroys the encryption key before returning the success status.

Large File Encryption

Phobos uses a different algorithm to encrypt big files (above 0x180000 bytes long). The algorithm explained above was used for encrypting files of typical size (in such case the full file was encrypted, from the beginning to the end). In the case of big files, the main algorithm is similar, however only some parts of the content are selected for encryption. Let us be more detailed about the operation:

Path and Size Calculation: Determines file paths, calculates necessary memory sizes, and prepares buffer areas for encryption and writing.
File Preparation:

Moves the existing file to a new filename and opens it for read-write access. Loads the file’s contents into memory and performs initial memory manipulation (mem_xor).

Encryption Initialization: Sets up encryption keys (crypt_intialize) and encrypts the content in place. Copies critical header and file information into specific buffer areas for encrypted data integrity.
Write Encrypted Data: Moves the file pointer to the end, then writes the encrypted buffer to the file. Finalizes the file with SetEndOfFile and invokes additional file modification functions to ensure integrity.
Cleanup and Reversion: If encryption completes successfully, the original file is replaced with the new encrypted file.
AES Key Protection

The AES key is encrypted just after being created. Its encrypted form is later appended at the end of the attacked file (in the aforementioned block of 128 bytes). Let us take a closer look at the function responsible for encrypting the AES key.

Something interesting here is that format_ip_and_gen_ecn_rand_key is always called before the creation of crypto thread so let us give it a deep look:

we can see that first several variables are decrypted, in the same way as the before mentioned strings. It turns out that the decrypted block of 128 bytes is a public RSA key of the attacker. This buffer is then verified with the help of a checksum (mem_xor). The checksum of the RSA key is compared with the hardcoded one. In case if both matches, the size that will be used for AES key generation is set to 32. Otherwise, it is set to 4. Then, a buffer of random bytes is generated for the AES key. After being generated, the AES key is protected with the help of the hardcoded public key. This time the authors decided to not use Windows Crypto API, but an external library (this piece of information has been generated with the help of chat GPT).

Post Infection Activities

After all threads are done (thanks to WaitForSingleObject) it make to calls to one to create the ransom note and the other to open it using same technique used to open new instance (ShellExecuteExW) then close program.

Conclusion

This in-depth analysis confirms that the analyzed sample is a variant of Phobos ransomware, demonstrating complex capabilities aimed at effective encryption and evasion. Utilizing the Windows Crypto API, the malware employs AES for file encryption, with unique initialization vectors per file and a randomly generated AES key. This AES key is subsequently encrypted with a hardcoded RSA public key, indicating asymmetric cryptography integration to prevent unauthorized decryption.

The malware achieves persistence through multiple avenues, including copying itself into the startup folder and modifying the Run registry key. Additionally, it creates a mutex to ensure single-instance execution and avoid interference from competing processes. The behavioral analysis further indicates anti-sandboxing techniques, specifically through sleep functions, to delay execution and thwart automated detection tools.

Phobos ransomware operates across both local and networked resources. It enumerates network shares and mapped drives using Windows API functions and initiates concurrent threads for encryption, ensuring rapid, distributed encryption over networked environments. The ransomware adopts an optimized encryption strategy by encrypting only sections of large files, conserving resources while still rendering the files unusable.

Further inspection of its internal structure reveals that Phobos utilizes a series of cryptographic context initializations and key settings tailored for AES encryption in ECB mode, although symmetric and asymmetric configurations are both supported within the execution flow. Post-encryption, the ransomware appends a unique signature to each encrypted file, alongside essential metadata, such as the encrypted AES key and ransomware marker “LOCK96,” ensuring data integrity and providing information essential to the ransom demand.

In summary, the Phobos ransomware sample exhibits advanced cryptographic design, evasion techniques, and multi-threaded file encryption across networked environments, demonstrating a high level of sophistication intended to maximize impact and hinder remediation.

IOCs

[id[].[email].acute] file extension
Mutex named “Global\\1096<<ID>><<ELVL>>” format
Software\Microsoft\Windows\CurrentVersion\Run persistence value
%localappdata% or common startup existence 

TTPs

Category	Techniques
Discovery	Query Registry [T1012]
	System Network Configuration Discovery [T1016]
	System Information Discovery [T1082]
	Process Discovery [T1057]
	Software Discovery [T1518]
	File and Directory Discovery [T1083]
Persistence	Registry Run Keys / Startup Folder [T1547.001]
Execution	Shared Modules [T1129]

Cyber Assassin