Palo Alto Networks Unit 42 has identified a series of phishing emails containing updated versions of the previously discussed CMSTAR malware family targeting various government entities in the country of Belarus.
In this latest campaign, we observed a total of 20 unique emails between June and August of this year that included two new variants of the CMSTAR Downloader. We also discovered two previously unknown payloads. These payloads contained backdoors that we have named BYEBY and PYLOT respectively.
Figure 1 Diagram of the attack sequence
Between June and August of this year, we observed a total of 20 unique emails being sent to the following email addresses:
|email@example.com[.]by||Press Service of the Ministry of Defense of the Republic of Belarus|
|firstname.lastname@example.org[.]by||Baranovichi Operational Management of the Armed Forces|
|email@example.com[.]by||Ministry of Defense of the Republic of Belarus|
|firstname.lastname@example.org[.]by||Ministry of Defense of the Republic of Belarus|
|email@example.com[.]by||Unknown. Likely used by Ministry of Defense of the Republic of Belarus|
|firstname.lastname@example.org[.]by||Minsk Operational Administration of the Armed Forces|
|email@example.com[.]by||Unknown. Likely used by Ministry of Defense of the Republic of Belarus|
|firstname.lastname@example.org[.]by||Unknown. Likely used by Ministry of Defense of the Republic of Belarus|
|email@example.com[.]by||State Border Committee of the Republic of Belarus|
|firstname.lastname@example.org[.]by||International Security and Arms Control Department, Ministry of Foreign Affairs|
|ablameiko@mia[.]by||Unknown. Likely used by the Ministry of Internal Affairs of the Republic of Belarus|
These emails contained a series of subject lines, primarily revolving around the topic of Запад-2017 (‘West-2017’), also known in English as Zapad 2017. Zapad 2017 was a series of joint military exercises conducted by the Armed Forces of the Russian Federation and the Republic of Belarus, held from September 14th to 20th in 2017.
The full list of subject lines is as follows:
- Fwd:Подготовка к Запад-2017 [Translation: Fwd:Preparing for the West-2017]
- выпуск воспитанников [Translation: graduation]
- К Запад-2017 [Translation: To West-2017]
- Запад-2017 [Translation: West-2017]
An example of some of the previously mentioned emails may be seen below.
Figure 2 Phishing email sent to Belarus government (1/2)
Figure 3 Phishing email sent to Belarus government (2/2)
We observed that the attachments used in these emails contained a mixture of file types. RTF documents, Microsoft Word documents, and a RAR archive. The RAR archive contained a series of images, a decoy document, and a Microsoft Windows executable within it. The executable has a .scr file extension, and is designed to look like a Windows folder, as seen below:
Figure 4 Payload disguising itself as a Microsoft Windows folder
The rough translation of the folder and file names above are ‘Preparations for large-scale West-2017 exercises in this format are being held for the first time.’ Within the actual folder, there are a series of JPG images, as well as a decoy document with a title that is translated to ‘Thousands of Russian and Belarusian military are involved in the training of the rear services.’
Figure 5 Embedded images and decoy document within RAR
The decoy document contains the following content:
Figure 6 Decoy document within RAR
The other RTF and Word documents used additional decoy documents, which can be seen below.
Figure 7 Decoy document with translation (1/2)
Figure 8 Decoy document with translation (2/2)
While we observed different techniques being used for delivery, all attachments executed a variant of the CMSTAR malware family. We observed minor changes between variants, which we discuss in the CMSTAR Variations and Payloads section of the blog post.
The Word documents, which we track as Werow, employ malicious macros for their delivery. More information about these macros may be found in the Appendix of the blog post. Additionally, we have included a script that extracts these embedded payloads that can also be found in the Appendix.
The RTF documents made use of CVE-2015-1641. This vulnerability, patched in 2015, allows attackers to execute malicious code when these specially crafted documents are opened within vulnerable instances of Microsoft Word. The payload for these samples is embedded within them and obfuscated using a 4-byte XOR key of 0xCAFEBABE. We have included a script that can be used to extract the underlying payload of these RTFs statically that can be found in the Appendix.
The SCR file mentioned previously drops a CMSTAR DLL and runs it via an external call to rundll32.exe.
CMSTAR Variations and Payloads
In total, we observed three variations of CMSTAR in these recent attacks against Belarusian targets. The biggest change observed between them looks to be minor modifications made to the string obfuscation routine. A very simple modification to the digit used in subtraction was modified between the variants, as shown below:
Figure 9 String obfuscation modifications between CMSTAR variants
The older variation, named CMSTAR.A, was discussed in a previous blog post entitled, “Digital Quartermaster Scenario Demonstrated in Attacks Against the Mongolian Government.”
The CMSTAR.B variant was witnessed using both a different mutex from CMSTAR.A, as well as a slightly modified string obfuscation routine. The mutexes used by CMSTAR ensure that only one instance of the malware runs at a time. The CMSTAR.C variant used the same mutex as CMSTAR.B, however, again used another slightly modified string obfuscation routine. We found all CMSTAR variants using the same obfuscation routine when I payload was downloaded from a remote server. We have included a tool to extract mutex and C2 information from all three CMSTAR variants, as well as a tool to decode the downloaded payload: both may be found in the Scripts section.
An example of CMSTAR downloading its payload may be found below:
Figure 10 Example HTTP download by CMSTAR
When expanding the research to identify additional CMSTAR.B and CMSTAR.C variants, we identified a total of 31 samples. Of these 31 samples, we found two unique payloads served from three of the C2 URLS—One of which was downloaded from a sample found in the phishing attacks previously described. Both payloads contained previously unknown malware families. We have named the payload found in the email campaign PYLOT, and the malware downloaded from the additional CMSTAR samples BYEBY.
Both malware families acted as backdoors, allowing the attackers to execute commands on the victim machine, as well as a series of other functions. More information about these individual malware families may be found in the appendix.
During the course of this research, we identified a phishing campaign consisting of 20 unique emails targeting the government of Belarus. The ploys used in these email and decoy documents revolved around a joint strategic military exercise of the Armed Forces of the Russian Federation and the Republic of Belarus, which took place between September 14th and September 20th of this year. While looking at the emails in question, we observed two new variants of the CMSTAR malware family. Between the samples identified and others we found while expanding our research scope, we identified two previously unknown malware families.
Palo Alto customers are protected from this threat in the following ways:
- Tags have been created in AutoFocus to track CMSTAR, BYEBY, and PYLOT
- All observed samples are identified as malicious in WildFire
- Domains observed to act as C2s have been flagged as malicious
- Traps 4.1 identifies and blocks the CVE-2015-1641 exploit used in these documents
- Traps 4.1 blocks the macros used in the malicious Word documents
A special thanks to Tom Lancaster for his assistance on this research.
Werow Macro Analysis
The attacker used the same macro dropper all of the observed Microsoft Word documents we analyzed for this campaign. It begins by building the following path strings:
The ‘d.doc’ path will be used to store a copy of the Word document, while the ‘WinCred.acl’ will contain the dropped payload, which is expected to be a DLL.
Figure 11 Macro used to drop CMSTAR
Werow uses rudimentary obfuscation to hide and re-assemble the following strings:
- rundll32 %APPDATA%\Microsof\Office\WinCred.acl ,WinCred
These strings will be used at the end of the macro’s execution to ensure persistence via the Run registry key.
The malware proceeds to read an included overlay within the original Word document from a given offset. This data is decoded using and XOR operation, as well as an addition operation. It can be represented in Python as follows:
def decrypt_xor(data, key, key_offset):
output = ""
seed = ord(key)
for d in data:
ord_d = ord(d)
if ord_d != 0 and ord_d != seed:
nvalue = ord_d ^ seed
seed = (seed + key_offset) % 0x100
output += chr(nvalue)
output += d
Once this overlay is decoded, it is written to the ‘WinCred.acl’ file and loaded with the ‘WinCred’ export. A script has been provided in the Scripts section that, in conjunction with oletools, can statically extract the embedded DLL payload from these documents.
RTF Shellcode Analysis
The RTF documents delivered in this attack campaign appear to be created by the same builder. All of the RTF files attempt to exploit CVE-2015-1641 to execute shellcode on the targeted system. Please reference https://technet.microsoft.com/en-us/library/security/ms15-033.aspx for more information.
The shellcode executed after successful exploitation begins by resolving the API functions it requires by enumerating the API functions within loaded modules in the current process. It then builds the following list of values:
The shellcode then enumerates the API functions, subjects them to a ROR7 hashing routine and XORs the resulting hash with 0x10ADBEEF. It uses the result of this arithmetic to compare with the list of values above to find the API functions it requires to carry out its functionality.
After resolving the API functions, the shellcode then begins searching for the embedded payload and decoy within the initial RTF file. It does so by searching the RTF file for three delimiters, specifically 0xBABABABABABA, 0xBBBBBBBB and 0xBCBCBCBC, which the shellcode uses to find the encrypted payload and decoy. The shellcode then decrypts the payload by XOR’ing four bytes at at time with the key 0xCAFEBABE, and decrypts the decoy by XOR’ing four bytes at a time using the key 0xBAADF00D. Here is a visual representation of the delimiters and embedded files:
After decrypting the payload, it saves the file to the following location:
The shellcode then creates the following registry key to automatically run the payload each time the system starts:
Software\Microsoft\Windows\CurrentVersion\Run : Microsoft
The shellcode saves the following command to this autorun key, which will execute the OutL12.pip payload, specifically calling its ‘WinCred’ exported function:
The shellcode will then overwrite the original delivery document with the decrypted decoy contents and open the new document.
This malware family was named via a combination of the DLLs original name of ‘pilot.dll’, along with the fact it downloads files with a Python (.py) file extension.
PYLOT begins by being loaded as a DLL with the ServiceMain export. It proceeds to create the following two folders within the %TEMP% path:
PYLOT continues to load and decode an embedded resource file. This file contains configuration information that is used by the malware throughout its execution. The following script, written in Python, may be used to decode this embedded resource object:
file = sys.argv
fh = open(file, 'rb')
fdata = list(fh.read())
fdata_len = len(fdata)
c = fdata_len-1
output = ""
while c > 1:
fdata[c] = chr( ord(fdata[c]) ^ ord(fdata[c-2]) )
c -= 1
fdata = ''.join(fdata)
Looking at the decoded data, we see the following:
Figure 12 Decoded embedded configuration information
The malware continues to collect the following information from the victim computer:
- Computer name
- IP addresses present on the machine
- MAC addresses
- Microsoft Windows version information
- Windows code page identifier information
This information is used to generate a unique hash for the victim machine. PYLOT then begins entering its C2 handler routine, where it will use HTTP for communication with the remote host.
Data sent to the remote C2 server is encrypted using RC4 with the previously shown key of ‘BBidRotnqQpHfpRTi8cR.’ It is then further obfuscated by base64-encoding this encrypted string. An example of this HTTP request containing this data can be seen below.
Figure 13 HTTP request made by PYLOT to remote server
The decrypted data sent in the request above is as follows. Note that all of this custom data format has not been fully identified, however, we’re able to see various strings, including the embedded configuration string of ‘fGAka0001’, as well as the victim hash of ‘100048048.’
Figure 14 Decrypted data sent by PYLOT to remote server
The base64-encoded string at the end of the data contains the collected victim machine information from earlier, separated by a ‘|’ delimiter.
The remote C2 server responds using the same data format. An example response can be seen below.
Figure 15 Response from remote C2 server
The decoded data at the end of the response contains various URIs to be used by the malware to receive commands, as well as other information that has yet to be fully researched.
A number of commands have been identified within PYLOT, including the following:
• Download batch script
• Run batch script
• Delete file
• Rename file
• Execute file
• Download file
• Upload file
BYEBY was named based on a string within the malware itself. Most strings found within this malware are concatenated to 6 characters. One such example was an instance where a debug string contained ‘BYE BY’, which was likely a concatenated form of the phrase ‘BYE BYE’.
This malware is loaded as a DLL, with an export name of ServiceMain. When the malware is initially loaded, it begins by checking to see if it is running within either of the following paths:
If it finds itself not running in either location, it will immediately exit. This is likely a technique used to bypass various sandboxing systems. Should it find itself running as svchost.exe, it will write the current timestamp and a value of ‘V09SS010’ (Base64 Decoded: ‘WORKMN’) to a file named ‘vmunisvc.cab’ within the user’s local %TEMP% folder. This file acts as a lot file and is written to frequently throughout the malware’s execution.
When the malware runs within the context of svchost.exe, it bypasses the installation routines and immediately enters the C2 handler.
When BYEBY is run within the context of rundll32.exe, it expects itself to be running for the first time. As such, it will register itself as a service with a name of ‘VideoSrv.’ After this service is created, BYEBY proceeds to enter it’s C2 handler function in a new thread.
BYEBY uses TLS for network communication, connecting to the following host on port 443:
After the initial connection is established, BYEBY will collect the following system information and upload it to the remote C2:
- IP Address
- Embedded String of ‘WinVideo’
- Major Windows Version
- Minor Windows Version
- Embedded String of ‘6.1.7603.16000’
The malware is configured to accept a number of commands. These appear to be Base64-encoded strings that, when decoded, provide their true meaning. Only the beginning of the commands are checked. The Base64-decoded strings have been included for the benefit of the reader.
- aGVsbG8h [Decoded: hello!]
- R09PREJZ [Decoded: GOODBY]
- TElTVCBE [Decoded: LIST D]
- U1RBUlRD [Decoded: STARTC]
- Q09NTUFO [Decoded: COMMAN]
- VFJBTlNG [Decoded: TRANSF]
- RVhFQ1VU [Decoded: EXECUT]
A mapping of commands and their descriptions has been provided:
|aGVsbG8h||Authenticate with the remote C2 server.|
|R09PREJZ||Close socket connection with remote server.|
|TElTVCBE||List drives on the victim machine.|
|U1RBUlRD||Start an interactive shell on the victim machine.|
|Q09NTUFO||Execute a command in the interactive shell|
|VFJBTlNG||Upload or download files to the victim machine.|
|RVhFQ1VU||Execute command in a new process.|
We created multiple scripts during the course of our research. We are sharing them here to assist other researchers or defenders that encounter this malware.
extract_cmstar_doc.py – Script to extract the embedded CMSTAR payload from Word documents.
extract_cmstar_rtf.py– Script to extract the embedded CMSTAR payload from RTFs.
extract_cmstar_strings.py – Script to identify possible mutex and C2 strings from CMSTAR variants.
decode_cmstar_payload.py – Script to decode a payload downloaded by CMSTAR.
Indicators of Compromise
CMSTAR Variants Identified in Phishing Campaign
CMSTAR Download Locations in Phishing Campaign
CMSTAR.B Download Locations
CMSTAR.C Download Locations