Table of Contents
Executive Summary
This sample was recently pulled from VirusTotal while looking for samples that involved cryptography. The sample gains persistance and replicates itself onto other executables that it finds to further infect the system. The ultimate goal and purpose of the malware is unknown, but the damage and behavior it exhibits has been reverse engineered.
There has been no evidence of communication to C2 IPs found, however, this malware behaves and operates very similar to ransomware and could be a template for how a ransomware sample would be built. Additionally, I have not seen clear evidence of how this sample is delivered to victims and only that sample submissions seem to be coming out of France.
Initial binary
- Copies itself to Windows system and temp directories
- Creates persistence via registry Run keys
- Creates a mutex
- Searches for executable files within user directory to infect them with itself
- Executables are modified to encrypt the original content and prefix the binary with the malware
- The modified files use RC4 for encryption and the key is saved at the end of the modified file and located via hex 0xA535443 = “CTS”
- Continually monitors for removable drives to further infect
- Continually scans for new executables to infect
Infected binaries
- The infected binary decrypts the original file bytes and saves it back to disk in the temp directory with a random name
- The file saved to the temp directory is the same hash of the file pre-infected
- The new file in temp is executed
- The infected binary once again establishes persistence by:
- Copying itself to the Windows system directory (overwriting any existing CTS.exe file if it exists)
- Updates the registry Run key
MITRE Attack Matrix
Indicators of Compromise
| Name | Value |
|---|---|
| Hash (MD5): CTS.EXE | 8e3ecc68ad8bb0db61b5de65d8381eff |
| Hash (SHA-1): CTS.EXE | f6a89e29036c200f5f595b95e75df7ec05a64990 |
| Hash (SHA-256): CTS.EXE | 20c8baddda18909c2cd6eb78ac904fe9ac1a1e96db37698b157b12f745ce1ff8 |
| File Size: CTS.EXE | 88.50 KB (90624 bytes) |
| File | %windir%\CTS.EXE |
| File | %temp%\<random-alpha-numeric-name>.exe |
| Registry | => %windir%\CTS.EXE |
| Mutex | Global\3pc6RWOgectGTFqCowxjeGy3XIGPtLwNrsr2zDctYD4hAU5pj4GW7rm8gHrHyTB6 |
Threat intel insights
- There is not enough information to attribute this to a specific group
- Yara rules may find samples with similar code that could potentially lead to attribution to the malware author
Technical Analysis
Persistance
When the initial payload gets executed on the victim machine a self replication and persistance flow takes place.
During this process the malware will copy itself to the Windows system directory or temp directory depending on its permissions. The malware will then update the Windows Run key to start execution on login to persist through reboots.
Monitor logical drives
The malware will start a new thread to run an indefinite loop that checks for local and remote drives attached to the victim machine to further infect. This is a loop that that runs every half second.
When decompiling this in IDA Pro we can see the loop that occurs in the thread. It is searching for drives that indicate they are of the type DRIVE_REMOVABLE or DRIVE_REMOTE and upon finding these it will fork off a thread from the malware start address.
Main thread infection loop
The malware moves on to perform an infection loop. The malware will identify the path to the current users’ profile directory to start the executable file search loop from.
This infection loop will continue to run indefinitely.
The malware checks to see if the file is an executable and moves to the next file if it is not.
When opening the executable file it will perform several checks to see if it has been infected or not. The malware will be checking for the value 0xA535443 that translates to CTS. It appears to use this as a separator or locator for data once it has re-written the binary in order to know how to find data.
The are a number of locations the CTS bytes are found within the infected file, however, the key ones to highlight are show in the layout of the newly infected file.
The re-written file will now:
- Start with the malware (and the sections and sizes will only include the malware portion of the file with the rest of the bytes going beyond the defined length of the sections that are in the PE headers
- Next will be the original file that is RC4 encrypted
- Finally, at the very end we’ll be able to locate the RC4 key that was used to perform the encryption. When the infected file runs, it will use this key to perform the decryption as we’ll see later
Infected file execution
The same malware code that is in the initial binary is also in the infected ones. The execution path splits off for the infected files during the persistance routines. The malware performs an initial check for the CTS bytes and based on this check it is either going to continue on with the initial payload or it is going to move into the infected path.
The file that is going to be written to the temp directory is the original file that is RC4 encrypted. Earlier I mentioned that is was at the end of the infected binary and we can confirm that here where we can see the malware use the CTS bytes to locate the RC4 key that will be used to decrypt this file.
In the below screenshot you can see where the the offset of ebx+8 is used to find the key after the CTS bytes. You can see the key bytes both in x64dbg as well as confirmed at the end of the infected file that I have opened with a hex editor.
NOTE: At this point, theoretically, we would have enough information to write a tool to clean the infection and re-write all system binaries back to their original state to remove the infection (if we really needed to do this).
The custom RC4 crypto routine is called to decrypt the original file bytes and write it into the new temp executable file. For additional details on the RC4 encryption/decryption routine seen here and how to identify this in malware you can refer to my previous post on this topic at:
https://www.travismathison.com/posts/RC4-Crypto-Usage-In-Malware/
The malware will construct a random alpha-numeric file name using the CryptGenRandom function and an alpha-numeric static string.
The temp path for the user profile is fetched and the full file path is constructed for writing.
In the final steps of the infected file it will start the process from the temp directory. This will launch the original binary but from within the temp directory and not the original location. Further, it will attempt to establish persistence via the original method.
And finally, when you launch an infected file you can see that is appears to execute and run but it is now running out of the temp directory and not the original location.
Conclusion
We have unpacked the behavior of the malware of which has the capability to establish persistance, scan the filesystem (and connected drives) for executables and take them over by copying itself into the file and encrypting the original one. Finally it can re-write the original file back to the temp directory and run it.
What is the purpose of this malware? This is a good question and I don’t have an answer to it. This would certainly wreak havoc on a system and cause it to need to be restored/re-imaged similar to a ransomware attack. That said, there is no ransom demanded and, as shown above, we have learned how we can decrypt the files programmatically if we had to do a manual recovery.
The next steps would be to write Yara rules on the key bytes related to this sample and perform threat hunting for other samples that appear to be using the same codebase that contain more information that could be used for attribution. Maybe we’ll get lucky?