Page 62 – Unit 42

Threat Actors Target Government of Belarus Using CMSTAR Trojan

Posted on September 28, 2017November 1, 2018 by Josh Grunzweig

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.

We first reported on CMSTAR in spear phishing attacks in spring of 2015 and later in 2016.

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

Phishing Emails

Between June and August of this year, we observed a total of 20 unique emails being sent to the following email addresses:

Email Address	Description
press@mod.mil[.]by	Press Service of the Ministry of Defense of the Republic of Belarus
baranovichi_eu@mod.mil[.]by	Baranovichi Operational Management of the Armed Forces
modmail@mod.mil[.]by	Ministry of Defense of the Republic of Belarus
admin@mod.mil[.]by	Ministry of Defense of the Republic of Belarus
itsc@mod.mil[.]by	Unknown. Likely used by Ministry of Defense of the Republic of Belarus
mineuvs@mod.mil[.]by	Minsk Operational Administration of the Armed Forces
inform@mod.mil[.]by	Unknown. Likely used by Ministry of Defense of the Republic of Belarus
uporov_milcoop@mod.mil[.]by	Unknown. Likely used by Ministry of Defense of the Republic of Belarus
video@gpk.gov[.]by	State Border Committee of the Republic of Belarus
armscontrol@mfa.gov[.]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)

Decoy Documents

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.

Conclusion

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 14^th and September 20^th 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.

Appendix

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:

%APPDATA%\d.doc
%APPDATA%\Microsoft\Office\WinCred.acl

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:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\WinCred
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)
    else:
      output += d
  return output

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)

else:

output += d

return output

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.

ROR7	ROR7^0x10ADBEEF	API Func
1a22f51	110f91be	WinExec
741f8dc4	64b2332b	WriteFile
94e43293	84498c7c	CreateFileA
daa7fe52	ca0a40bd	UnmapViewOfFile
dbacbe43	cb0100ac	SetFilePointer
ec496a9e	fce4d471	GetEnvironmentVariableA
ff0d6657	efa0d8b8	CloseHandle

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:

%APPDATA%\Microsoft\Office\OutL12.pip

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:

rundll32.exe
"%APPDATA\Roaming\Microsoft\Office\OutL12.pip",WinCred

The shellcode will then overwrite the original delivery document with the decrypted decoy contents and open the new document.

PYLOT Analysis

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:

KB287640
KB887209

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:

import sys
import hexdump

file = sys.argv[1]
fh = open(file, 'rb')
fdata = list(fh.read())
fh.close()

fdata_len = len(fdata)
c = fdata_len-1

output = ""
while c &gt; 1:
	fdata[c] = chr( ord(fdata[c]) ^ ord(fdata[c-2]) )
	c -= 1

fdata = ''.join(fdata)
hexdump.hexdump(fdata)

import sys

import hexdump

file = sys.argv[1]

fh = open(file, 'rb')

fdata = list(fh.read())

fh.close()

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)

hexdump.hexdump(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.

/duakzu/furs.py|/ugvrf/pvoi.py|/tydfw/pld.py|/bpnij/syau.py|/plugin/plugin.py|eycHhHKVQUnuAwtNchvYjScGYMtVMzMqYmxBmCEwieQpKgsokpvrxknPQRvnkOHDywCImVZxHxRdvlePjgnbPXsyTzreBEckVVFbuUHHcvLPGmqxHUNWondMIntBiVVO|CgpQxWOeTAbOLpOCdWtesymHSqjeSUYPQFBeUnbhXElorlcjqldwEMVucaDwJRhuzZjprKkZEPvLEWUbkEQxFUqzqIRQwyuTaBmOZSOpfJRByRvyTHjSVdVeihtkbcnG|GqPfDIAHOik/

/duakzu/furs.py|/ugvrf/pvoi.py|/tydfw/pld.py|/bpnij/syau.py|/plugin/plugin.py|eycHhHKVQUnuAwtNchvYjScGYMtVMzMqYmxBmCEwieQpKgsokpvrxknPQRvnkOHDywCImVZxHxRdvlePjgnbPXsyTzreBEckVVFbuUHHcvLPGmqxHUNWondMIntBiVVO|CgpQxWOeTAbOLpOCdWtesymHSqjeSUYPQFBeUnbhXElorlcjqldwEMVucaDwJRhuzZjprKkZEPvLEWUbkEQxFUqzqIRQwyuTaBmOZSOpfJRByRvyTHjSVdVeihtkbcnG|GqPfDIAHOik/

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 Analysis

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:

[SYSTEM32]\svchost.exe
[SYSTEM32]\rundll32.exe

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:

oeiowidfla22[.]com

After the initial connection is established, BYEBY will collect the following system information and upload it to the remote C2:

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

Command	Description
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.

Scripts

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

65d5ef9aa617e7060779bc217a42372e99d59dc88f8ea2f3b9f45aacf3ba7209

2a0169c72c84e6d3fa49af701fd46ee7aaf1d1d9e107798d93a6ca8df5d25957

4da6ce5921b0dfff9045ada7e775c1755e6ea44eab55da7ccc362f2a70ce26a6

2008ec82cec0b62bdb4d2cea64ff5a159a4327a058dfd867f877536389a72fb6

cecd72851c265f885ff02c60cbc3e6cbf1a40b298274761f623dfa44782a01f8

d8c0f8ecdeceba83396c98370f8f458ea7f7a935aabbcc3d41b80d4e85746357

2c8267192b196bf8a92c8b72d52096e46e307fa4d4dafdc030d3e0f5b4145e9e

2debf12b1cb1291cbd096b24897856948734fa62fd61a1f24d379b4224bda212

79b30634075896084135b9891c42fca8a59db1c0c731e445940671efab9a0b61

b0065fc16ae785834908f024fb3ddd4d9d62b29675859a8e737e3b949e85327a

16697c95db5add6c1c23b2591b9d8eec5ed96074d057b9411f0b57a54af298d5

6843d183b41b6b22976fc8d85e448dcc4d2e0bd2c159e6d966bfd4afa1cd9221

3c3efa89d1dd39e1112558af38ba656e048be842a3bedb7933cdd4210025f791

b2bebb381bc3722304ab1a21a21e082583bf6b88b84e7f65c4fdda48971c20a2

09890dc8898b99647cdc1cceb97e764b6a88d55b5a520c8d0ea3bfd8f75ed83b

fd22973451b88a4d10d9f485baef7f5e7a6f2cb9ce0826953571bd8f5d866c2a

CMSTAR Download Locations in Phishing Campaign

http://45.77.60[.]138/YXza9HkKWzqtXlt.dat
http://45.77.60[.]138/mePVDjnAZsYCw5j.dat
http://45.77.60[.]138/UScHrzGWbXb01gv.dat
http://45.76.80[.]32/tYD7jzfVNZqMfye.dat
http://45.77.60[.]138/liW0ecpxEWCfIgU.dat
http://45.77.60[.]138/ezD19AweVIj5NaH.dat
http://45.77.60[.]138/jVJlw3wp379neaJ.dat
http://108.61.175[.]110/tlhXVFeBvT64LC9.dat
http://45.77.60[.]138/HJDBvnJ7wc4S5qZ.dat
http://45.77.60[.]138/JUmoT4Pbw6U2xcj.dat
http://108.61.175[.]110/oiUfxZfej29MAbF.dat
http://45.77.60[.]138/cw1PlY308OpfVeZ.dat
http://45.77.60[.]138/VFdSKlgCAZD7mmp.dat
http://45.77.60[.]138/c2KoCT5OHcVwGi7.dat
http://45.77.60[.]138/3kK24dXFYRgM6Ac.dat
http://45.77.60[.]138/WsEeRyHEhLO1kUm.dat

PYLOT SHA256

7e2c9e4acd05bc8ca45263b196e80e919ff60890a872bdc0576735a566369c46

PYLOT C2

wait.waisttoomuchmind[.]com

BYEBY SHA256

383a2d8f421ad2f243cbc142e9715c78f867a114b037626c2097cb3e070f67d6

BYEBY C2

oeiowidfla22[.]com

CMSTAR.B SHA256

8609360b43498e296e14237d318c96c58dce3e91b7a1c608cd146496703a7fac

f0f2215457200bb3003eecb277bf7e3888d16edcf132d88203b27966407c7dc3

aecf53a3a52662b441703e56555d06c9d3c61bddf4d3b23d9da02abbe390c609

960a17797738dc0bc5623c74b6f8a5d74375f6d18d20ba18775f26a43898bae6

e37c045418259ecdc07874b85e7b688ba53f5a7dc989db19d7e8c440300bd574

75ea6e8dfaf56fb35f35cb043bd77aef9e2c7d46f3e2a0454dff0952a09c134f

a65e01412610e5ed8fde12cb78e6265a18ef78d2fd3c8c14ed8a3d1cef17c91d

7170b104367530ae837daed466035a8be719fdb17423fc01da9c0ded74ca6ad1

13acddf9b7c2daafd815cbfa75fbb778a7074a6f90277e858040275ae61a252b

625ed818a25c63d8b2c264d0f5bd96ba5ad1c702702d8ffaa4e0e93e5f411fac

a56cd758608034c90e81e4d4f1fe383982247d6aeffd74a1dd98d84e9b56afdf

a4b969b93f7882ed2d15fd10970c4720961e42f3ae3fced501c0a1ffa3896ff5

e833bbb79ca8ea1dbeb408520b97fb5a1b691d5a5f9c4f9deabecb3787b47f73

8e9136d6dc7419469c959241bc8745af7ba51c7b02a12d04fec0bc4d3f7dcdf0

CMSTAR.B Download Locations

http://108.61.175[.]110/tlhXVFeBvT64LC9.dat
http://104.238.188[.]211/gl7xljvn3fqGt3u.dat
http://45.77.60[.]138/c2KoCT5OHcVwGi7.dat
http://108.61.175[.]110/gkMmqVvZ7gGGxpY.dat
http://108.61.175[.]110/z_gaDZyeZXvScQ6.dat
http://108.61.175[.]110/bDtzGVtqgiJU9PI.dat
http://45.77.60[.]138/liW0ecpxEWCfIgU.dat
http://45.77.60[.]138/JUmoT4Pbw6U2xcj.dat
http://108.61.175[.]110/oiUfxZfej29MAbF.dat
http://108.61.103[.]123/jvZfZ0gdTWtr46y.dat
http://108.61.103[.]123/06JcD5jz5dSHVAy.dat
http://108.61.103[.]123/nj3dsMMpyQQDBF3.dat
http://108.61.103[.]123/fHZvWtBGlFvs2Nr.dat
http://45.77.60[.]138/w57E8dktKb9UQyV.dat

CMSTAR.C SHA256

85e06a2beaa4469f13ca58d5d09fec672d3d8962a7adad3c3cb74f3f9ef1fed4

b8ef93227b59e6c8d3a1494b4860d15be819fae17b57fd56bfff9a51b7972ff0

9e6fdbbc2371ac8bc6db3b878475ed0b0af8950d50a4652df688e778beb87397

4e38e627ae21f1a85aa963ca990a66cf75789b450605fdca2f31ee6f0f8ab8f2

f4ff0ca7f2ea2a011a2a4615d9b488b7806ff5dd61577a9e3a9860f2980e7fc0

8de3fa2614b1767cfd12936c5adf4423ef25ea60800fa170752266e0ca063274

38197abde967326568e101b65203c2efa75500e5f3c084b6dd08fd1ba1430726

726df91a395827d11dc433854b3f19b3e28eac4feff329e0bdad93890b03af84

5703565ec64d72eb693b9fafcba5951e937c8ee38829948e9518b7d226f81c10

d0544a3e6d1b34b8b4e976c7fc62d4500f28f617e2f549d9a3e590b71b1f9cc5

2a8e5551b9905e907da7268aba50fcbc526cfd0549ff2e352f9f4d1d71bf32a7

d7cd6f367a84f6d5cf5ffb3c2537dd3f48297bd45a8f5a4c50190f683b7c9e90

8f7294072a470b886791a7a32eedf0f0505aaecec154626c6334d986957086e4

6419255d017b217fe984d3439694eb96806d06c7ea41a422298650969028c08c

CMSTAR.C Download Locations

http://45.77.58[.]49/54xfapkezW64xDE.dat
http://45.77.58[.]49/54xfapkezW64xDE.dat
http://45.77.62[.]181/naIXl13kqeV7Y2j.dat
http://45.77.58[.]160/9EkCWYA3OtDbz1l.dat
http://45.77.58[.]160/8h5NPYB5fAn301E.dat
http://45.77.58[.]160/9EkCWYA3OtDbz1l.dat
http://45.77.60[.]138/3kK24dXFYRgM6Ac.dat
http://45.77.60[.]138/ezD19AweVIj5NaH.dat
http://45.77.60[.]138/VFdSKlgCAZD7mmp.dat
http://45.77.60[.]138/HJDBvnJ7wc4S5qZ.dat
http://45.77.60[.]138/jVJlw3wp379neaJ.dat
http://45.77.60[.]138/YXza9HkKWzqtXlt.dat
http://45.77.60[.]138/UScHrzGWbXb01gv.dat
http://45.77.60[.]138/WsEeRyHEhLO1kUm.dat

Striking Oil: A Closer Look at Adversary Infrastructure

Posted on September 26, 2017October 15, 2018 by Robert Falcone

While expanding our research into the TwoFace webshell from this past July, we were able to uncover several IP addresses that logged in and directly interfaced with the shell we discovered and wrote about. Investigating deeper into these potential adversary IPs revealed a much larger infrastructure used to execute the attacks. We found the infrastructure was segregated into different functions for specific malicious objectives. We found some sites that were set up as credential harvesters (likely used in phishing attacks), a compromised system that was used to interact with a TwoFace webshell to hide the actor’s location, and finally systems that interact with TwoFace webshell-compromised systems to provide command and control direction of those compromised systems.

In addition to uncovering the attack infrastructure for this adversary, we were able to determine a significant link between the operators of the set of attacks involving TwoFace and another attack campaign we have published on in detail: OilRig.

Spoofing Sites and Credential Harvesters

We observed the IP address 137.74.131[.]208 interacting with the TwoFace webshell as described in our previous blog. Our investigation of the passive DNS entries for this IP revealed a potential link to a credential harvesting campaign carried out by the threat group behind the TwoFace webshell attacks. Looking into passive DNS entries for the IP gave us the following domain resolutions:

owa-insss-org-ill-owa-authen[.]ml
webmaiil-tau-ac-il[.]ml
mail-macroadvisorypartners[.]ml
webmail-tidhar-co-il[.]ml
my-mailcoil[.]ml
logn-micrsftonine-con[.]ml
so-cc-hujii-ac-il[.]ml

These domain names, on initial inspection, appear to be emulating legitimate webmail login portals, indicating that these are likely to be credential harvesters. We confirmed this as seen below:

Figure 1a. Example of a credential harvester

Figure 1 b. Example of a credential harvester

Our further examination revealed that these credential harvesters were crafted to be exact replicas of the legitimate sites they were purporting to be. This is a common tactic deployed by adversaries leveraging credential harvesters to increase the chance that a user will input their credentials and decrease suspicion of nefarious activity.

Breaking down the intended targeting for these credential harvesters reveals interesting target grouping.

owa-insss-org-ill-owa-authen[.]ml is likely intended to mimic the INSSS or the Institute of National Security Studies, a thinktank for Israel’s national security agenda.
webmaiil-tau-ac-il[.]ml is likely intended to mimic Tel Aviv University, the largest university in Israel.
mail-macroadvisorypartners[.]ml is likely intended to mimic Macro Advisory Partners, a prominent strategic consulting firm that has published insights into the Israel region.
webmail-tidhar-co-il[.]ml is likely intended to mimic the Tidhar Group, an Israeli based real estate and property management company.
my-mailcoil[.]ml is likely intended to mimic Bezeq International’s webmail application. Bezeq International is an Israeli based telecommunications company providing consumer and enterprise services.
so-cc-hujii-ac-il[.]ml is likely intended to mimic the Hebrew University of Jerusalem which is the second oldest university in Israel.

Each of these organizations appear to be either Israeli based or have strong Israeli connections and interests. Credential harvesters in general are not uncommon, but it is significant to have a grouping of region and company specific harvesters. This grouping leads us to believe that this adversary is likely to have had a specific mission to accomplish, which involved breaching specific organizations. This is in contrast to more generic credential harvesting by targeting common applications such as Gmail or Facebook.

The relationship between the credential harvesters hosted on 137.74.131[.]208 and the interaction with TwoFace is still unclear at this time. We do know the operator of TwoFace had access to both TwoFace and these spoofing sites. And it is highly unlikely that it is a coincidence that these specifically designed spoofing sites were on the same infrastructure as TwoFace when both target the same geopolitical region.

Additional Webshells

By analyzing additional TwoFace samples, as well as the traffic seen associated with TwoFace, we were able to find additional webshells used by this threat group. The additional webshells show that this threat group does not solely rely on TwoFace when deploying a webshell on a compromised web server.

RunningBee

A second IP of high interest seen interacting with the TwoFace webshell was 192.155.x.x, which is owned by SoftLayer. This IP resolves to a domain owned by the Ministry of Oil of a nation-state in the Middle East. The use of this IP is interesting as there are only two possibilities as to why this specific IP would be directly interfacing with the TwoFace shell: either it is the adversary themselves, or it has been compromised and is being used as part of the adversary infrastructure.

Based upon additional telemetry found in AutoFocus, we believe it is highly likely that this IP was indeed compromised and added to the adversary infrastructure. The telemetry revealed that this IP was not only used to interact directly with the TwoFace shell discussed in our previous blog, but also used to upload post-exploitation tools to another shell hosted on a Middle Eastern educational institution. We have named this second webshell “RunningBee”.

RunningBee is a webshell that requires an actor to enter a password before running commands or uploading files to the webserver much like TwoFace. However, the shell itself is different from a UI and code perspective. The samples of RunningBee that we identified requires the password “NeshaNesha12” for interaction. This is notable because this same password was mentioned in Cylance’s Operation Cleaver report as a password for webshells used by one of the members of that operation.

Figure 2 RunningBee webshell

Investigating RunningBee activity revealed that the 192.155.x.x IP uploaded at least four additional tools to that compromised system with RunningBee on it, as seen in Table 1. Please reference the 'Post-exploitation Tools SHA256' section at the end of this blog for full hashes of the tools mentioned throughout in this blog.

Date Uploaded	SHA256	Filenames	Tool
10/06/2016, 02/19/2017	3b08535b4add194...	PsExec.exe, kb-11.exe	PsExec
02/19/2017	28a0db561ff5a52...	kb.exe	Mimikatz
02/19/2017	450ebd66ba67bb4...	Local.exe	Local.Exe of Microsoft Windows NT Resource Kit
02/19/2017	5b7eb534a852c18...	kbs.exe	Mimikatz

Table 1 Post-exploitation tools found on RunningBee

The uploaded files were common examples of tools often found during the post-exploitation phase.

Psexec – a lightweight application part of the SysInternals package designed to execute processes on other systems and allow for interactive console access
Mimikatz – an open source tool designed to extract and use credential information from Windows systems
local.exe – a command line tool part of the NT Resource Kit to view members of local groups on remote servers or domains

Our analysis showed the specific hashes of these tools were placed on multiple other sites also containing TwoFace related webshells, leading us to believe that they are related to one specific adversary.

Based on the post-exploitation tools uploaded to RunningBee and common IP addresses interacting with the shells, we found four other related webshells hosted on webservers belonging to organizations in the Middle East. The tools listed in Table 2 include the same tools that were uploaded to RunningBee such as PsExec, Mimikatz and Local.exe. In addition to these tools, we also discovered the existence of the remote connection tool known as PuTTY Link (plink) and a custom Microsoft IIS (Internet Information Services) web server backdoor that we track as RGDoor. We believe the threat actors may have used plink to connect to additional systems on the compromised network after obtaining legitimate credentials using a tool such as mimikatz. RGDoor is an HTTP module that the threat actors are likely loading into the IIS web server to maintain an additional, backup access point should the compromised organization detect and remediate the installed webshell (e.g. TwoFace, RunningBee) from the server.

SHA256	Filename	Tool	Shells	IP addresses uploading
744e0ce108598aa...	S64.exe		1	138.201.209.162
bb9b4e088eb9910...	z64.exe		1	89.163.206.0
28a0db561ff5a52...	mom64.exe	Mimikatz	2	137.74.131.208
6e623311768f1c4...	s64.exe		3, 4	51.254.50.153, 212.16.80.102, 37.59.229.231, 91.121.237.227
3b08535b4add194...	ps.exe	PsExec	3, 4	51.254.50.153
6ae32cd3b5a8a1d...	pl.exe	PuTTY Link	3, 4	51.254.50.153, 91.121.237.227, 37.59.229.231, 176.9.164.252
450ebd66ba67bb4...	Local.exe	Local.Exe of Microsoft Windows NT Resource Kit	3	91.121.237.227
d3b03c0da854102...	O6.exe	Mimikatz	1	92.222.209.48, 94.23.172.49
5ead94f12c30743...	O64.exe	Mimikatz	1	92.222.209.51
caf5f9791ab3049...	i64.exe		1	138.201.209.182, 5.39.59.97, 91.121.237.224
497e6965120a7ca...	HTTPParser.dll	RGDoor	1	5.39.59.97

Table 2 Post-exploitation tools and associated IPs

Figure 3 Visualization of relationships of webshell and tools

LittleFace

As we reported in our TwoFace blog, the TwoFace shell was unique in that it was actually two webshells, where after initial authentication to a loader webshell, a secondary webshell with additional functionality was unpacked and made accessible to the operator. After gathering additional TwoFace loader shells, we noticed that some of these TwoFace loaders contained an embedded shell that differed from the TwoFace payload we originally found and published in our previous blog. This different shell, which we call LittleFace, contains much less functionality and is relatively simple compared to its TwoFace payload counterpart. LittleFace also differs from the previous TwoFace payloads as once it is saved to the system, it no longer requires authentication.

The LittleFace shell does not display a web-based user interface like most webshells. Instead, it is a webshell that allows the threat actor to pass commands to Windows command prompt by issuing HTTP POST requests with the desired command within the “c” field of the posted data, as seen in the following code block that is the command handler on the webshell. The webshell will receive the commands embedded in the HTTP POST requests and hand them off to another function (“r” function in the following code block) for processing.

void Page_Load(object sender, EventArgs e)
{
    try
    {
        string cmd = Request["c"];
        r(cmd);
    }
    catch (Exception)
    {
    }
}

void Page_Load(object sender, EventArgs e)

{

try

{

string cmd = Request["c"];

r(cmd);

}

catch (Exception)

{

}

The LittleFace shell will execute the command (‘r’ function seen in code block above) by creating a “cmd.exe” process and writing the desired command to the process’ standard input. The result of the command is provided back to the actor directly within the HTTP response to the POST request.

OilRig Link

While examining each of the tools that were found on the compromised sites, one specific sample of Mimikatz showed evidence of a potential relationship with the OilRig campaign.

As detailed in our April 2017 blog "OilRig Actors Provide a Glimpse into Development and Testing Efforts", we were able to track an entity that appeared to be testing and iterating through different variations and versions of tools associated with the OilRig campaign. This same entity was found submitting a specific sample of Mimikatz a day after testing multiple Helminth samples. We observed actors uploading this specific sample of Mimikatz to the TwoFace webshell hosted at the Saudi education institution mentioned earlier in this blog, leading us to believe that there is a likely relationship between the OilRig campaign and the TwoFace campaign. The extent of this relationship is unknown at this time. While we cannot be absolutely certain that this is the same adversary in both attacks, we are able to ascertain that this specific entity does have access to OilRig tools and also has access to a very specific sample of Mimikatz only found in this attack infrastructure.

Expanding on the possible relationship between TwoFace and OilRig, examining the tactical overlap of both attacks may also provide additional data points to link them. Specifically, significant targeting overlap exists with both attacks, with multiple organizations in multiple nation states throughout the Middle East region being targeted either as a final target or added as part of the attack infrastructure. One possible scenario of how TwoFace and OilRig are used in conjunction could be where the adversary uses the ClaySlide documents to deliver Helminth, which is then used as an initial landing point or beachhead into the target’s network. From there, the adversary may use the initial ingress point and its corresponding permissions to install the TwoFace webshell on accessible systems. Additional post-exploitation tools such as the ones we discovered may then have been uploaded to the now compromised systems via the TwoFace file upload function.

Conclusion

As we have continued our research into operations in the Middle East, we are beginning to uncover more and more overlaps between the various adversary groups and campaigns outlined by us and others in the public domain. In this incident, we were able to follow a trail starting from a single webshell to a bevy of compromised sites, credential harvesters, post-exploitation tools, and even an operational overlap with what we originally thought was an unrelated attack campaign. The Middle East region has proven to be a hotbed of threat activity in recent times, with continued acceleration of pacing as well as development in the tactics and techniques used. There is no indication that this type of threat activity will cease, but with continued discovery of the adversary’s playbooks, implementation of strong security policies, and effective deployment of technology, we can make it far less worthwhile for the adversary to execute their attacks.

Post-exploitation Tools SHA256 Hashes

28a0db561ff5a525bc2696cf98d96f443f528afe63c5097c5e0ccad071fcb8c2
744e0ce108598aaa8994f211e00769ac8a3f05324d3f07f7705277b9af7a7497
caf5f9791ab3049811e16971b4673ec6d4baf35ffaadd7486ea4c5e318d10696
6ae32cd3b5a8a1dbb5464372ded370f31802fd1f5031795b43d662c64fc5b301
3b08535b4add194f5661e1131c8e81af373ca322cf669674cf1272095e5cab95
450ebd66ba67bb46bf18d122823ff07ef4a7b11afe63b6f269aec9236a1790cd
5b7eb534a852c187eee7eb729056082eec7a028819191fc2bc3ba4d1127fbd12
6e623311768f1c419b3f755248a3b3d4bf80d26606a74ed4cfd25547a67734c7
497e6965120a7ca6644da9b8291c65901e78d302139d221fcf0a3ec6c5cf9de3
d3b03c0da854102802c21c0fa8736910ea039bbe93a140c09689fc802435ea31
5ead94f12c307438e6475e49f02bedaee0cd09ce6cebb7939f9a2830f913212c
bb9b4e088eb99100156f56bbd35a21ff7e96981ffe78ca9132781e9b3f064f44

Credential Harvesting Domains

owa-insss-org-ill-owa-authen[.]ml
webmaiil-tau-ac-il[.]ml
mail-macroadvisorypartners[.]ml
webmail-tidhar-co-il[.]ml
my-mailcoil[.]ml
logn-micrsftonine-con[.]ml
so-cc-hujii-ac-il[.]ml

Analyzing the Various Layers of AgentTesla’s Packing

Posted on September 25, 2017 by Jeff White

AgentTesla is a fairly popular key logger built using the Microsoft .NET Framework and has shown a substantial rise in usage over the past few months.

It offers all of the standard features of a keylogger but goes beyond the typical confines of this type of software. One particular feature of interest is the custom packer it uses to hide the primary AgentTesla binary. Packers allow for a binary to essentially be wrapped in another binary to mask the original one from detection.

There are a number of excellent blogs out there covering AgentTesla’s functionality and it’s various obfuscations, but having I recently unpacked a sample and wanted to focus on this particular function and provide some helpful tools to aide in unpacking it.

For this analysis, I’ll be using a PE32 version AgentTesla file seen in the wild on August 29^th with hash “ca29bd44fc1c4ec031eadf89fb2894bbe646bc0cafb6242a7631f7404ef7d15c”. You’ll find AgentTesla delivered commonly via phishing documents that usually contain VBA macros to download and run a file – like the one in question.

As it’s a commercial product, you’ll find a lot of variety in the initial carrier files that deliver the AgentTesla binary; however, at some point you’ll find yourself with a PE.

Thus, begins the journey…

I suppose the first layer of obfuscation really begins with the file itself, called “one.jpeg.png.exe” and an icon of a JPG trying to create an illusion of legitimacy.

This is a common technique to fool people and they’ve taken it one step further by opening an image when you execute the binary.

The first executable is a .NET application, which is no surprise since AgentTesla is very well known for being a .NET key logger. To analyze .NET applications, I prefer to use the application dnSpy and, once loading up this sample, we can see there is only one namespace of interest with a handful of functions and a byte array.

The Japanese kanji stands out at first glance but I believe this is less about language and more about being a form of obfuscation – I’ll explain why shortly.

Looking at the Main() function shows a pattern of multiple calls to two other functions.

Take for example the below string.

ゆ.く(ゆ.るこ(New Byte() { 129, 148, 157, 176, 144, 129, 163, 219 })),

1	ゆ.く(ゆ.るこ(New Byte() { 129, 148, 157, 176, 144, 129, 163, 219 })),

The namespace is “ゆ” and the functions are “く” and “るこ”, with the latter taking a byte array as input and then the resulting output of that function being passed to the former.

Starting with the first function, there are two XOR operations that occur with what looks like two values from the passed in byte array and then a static XOR key.

Looking at this function deeper, it uses the last value in the byte array as one of the 3 XOR keys, then adjusts the array in size and begins the decoding loop. Starting at the first byte, it will take this number as the second XOR key and increment it each iteration. The final XOR key is pulled from the GetBytes call on the long string of kanji.

Before going any further though, can you spot the issue with the function above? It works and successfully decodes the byte array but there is a flaw in codes logic that threw me for a loop when trying to implement the code in Python.

If you manually XOR those values together (129 [first byte] ^ 214 [last byte] ^ 12375 [first kanji]), the resulting output isn’t what gets returned within the debugger. In fact, it’s not even close which left me scratching my head for a while.

129^214^12375 = 12288 (0x3000)

1	129^214^12375 = 12288 (0x3000)

Instead, what we end up with is 104 (0x68). It’s clearly wrong though and I assumed I was missing something in what appeared to be a relatively straight forward, par for the course, decoding function. If I XOR the know good result with the two values from the byte array, I end up with 63 (0x3F), otherwise known as “?”.

What’s happening is that the GetBytes call is set to use the default system encoding, which in my case is Windows-1252, so the bytes fall outside of the acceptable range and all return as 63 (0x3F), regardless of where the index pointer is in the array. Given this, the only two values I ever need to worry about are within the array itself and I can ignore most of this code.

Below is a small Python script which will decode the strings passed into it.

def decode(a):
	xorkey = a[-1]
	a = a[0:-1]
	b = [0] * len(a)
	num = 0
	counter = 0
	maxlength = len(b) - 1
	while counter <= maxlength:
		b[len(b) - 1 - counter] = chr(a[counter] ^ xorkey ^ 0x3f)
		counter += 1
	return "".join(b)

>>> a = [129,148,157,176,144,129,163,219]
>>> decode(a)
'GetType'

def decode(a):

xorkey = a[-1]

a = a[0:-1]

b = [0] * len(a)

num = 0

counter = 0

maxlength = len(b) - 1

while counter <= maxlength:

b[len(b) - 1 - counter] = chr(a[counter] ^ xorkey ^ 0x3f)

counter += 1

return "".join(b)

>>> a = [129,148,157,176,144,129,163,219]

>>> decode(a)

'GetType'

As the string successfully decodes with using XOR key 0x3F, it implies it was also encoded with this value initially, so the default code page used by the author when encoding it was also most likely Windows-1252.

The reason I believe the kanji is more for obfuscation than anything else is because of this and what the XOR key displays, which is nothing but a jumble of random characters without any coherent message.

This randomness in function and variable names is similar to the techniques they use in later payloads but now with a different character set.

For the second function, “く” it simply returns a string from the byte array of the previous function.

Going back to the previously mentioned byte array, it’s quite large and only has one reference inside this code, highlighted below.

After the byte array is passed to the decoding function, the output is used as input into a new function, “うむれぐ”, that is responsible for decompressing the data.

Once decompressed, the new data is returned in a byte array.

At this point I copied out the list of integers for the byte array and ran it through the decoding Python function and decompressed the it with the zlib library into the next payload.

fh = open("output", "w")
fh.write(zlib.decompress(decode(a), -15))
fh.close()

fh = open("output", "w")

fh.write(zlib.decompress(decode(a), -15))

fh.close()

Looking at the new file shows that it is a DLL named “rp.dll”.

This was also a .NET file and we can load it into dnSpy for further analysis; however, before doing that I’ll go over the final part of the first packer.

Dim objectValue As Object = RuntimeHelpers.GetObjectValue(NewLateBinding.LateGet(Nothing,CType(NewLateBinding.LateGet(Nothing, “System.Type”,“GetType”, “System.Reflection.Assembly”, Nothing, Nothing, Nothing), Type), “Load”, BINARY_ARRAY, Nothing, Nothing, Nothing))

Dim objectValue2 As Object = RuntimeHelpers.GetObjectValue(NewLateBinding.LateGet(RuntimeHelpers.GetObjectValue(objectValue), Nothing, "GetType", "とむ暮.とむ暮", Nothing, Nothing, Nothing))

NewLateBinding.LateGet(Nothing, CType(NewLateBinding.LateGet(Nothing, Type.[GetType]("System.Type", "GetType", "System.Activator", Nothing, Nothing, Nothing), Type), "CreateInstance", New Object() { RuntimeHelpers.GetObjectValue(objectValue2) }, Nothing, Nothing, Nothing)

Dim objectValue As Object = RuntimeHelpers.GetObjectValue(NewLateBinding.LateGet(Nothing,CType(NewLateBinding.LateGet(Nothing, “System.Type”,“GetType”, “System.Reflection.Assembly”, Nothing, Nothing, Nothing), Type), “Load”, BINARY_ARRAY, Nothing, Nothing, Nothing))

Dim objectValue2 As Object = RuntimeHelpers.GetObjectValue(NewLateBinding.LateGet(RuntimeHelpers.GetObjectValue(objectValue), Nothing, "GetType", "とむ暮.とむ暮", Nothing, Nothing, Nothing))

NewLateBinding.LateGet(Nothing, CType(NewLateBinding.LateGet(Nothing, Type.[GetType]("System.Type", "GetType", "System.Activator", Nothing, Nothing, Nothing), Type), "CreateInstance", New Object() { RuntimeHelpers.GetObjectValue(objectValue2) }, Nothing, Nothing, Nothing)

I’ve cleaned up the encoded strings so you can see what it’s doing but effectively, it takes the DLL assembly, loads it, and calls the main function, “とむ暮.とむ暮”, within it.

This DLL uses the same byte array string obfuscation as the initial executable.

In the above image, you can see it begins by checking whether the file “\\Products\\WinDecode.exe” exists and then will create the “\\Products\\” directory if it does not. After that it will enumerate processes to kill, delete files, establish itself in the registry for persistence and other characteristics typical of this malware.

But, eventually during the execution, you’ll end up at the next part of the unpacking code.

Dim obj2 As Object = とむ暮.れなつ(Me.まこうに(Me.こなき(Me.れな())))
Dim うひ硯る As うひ硯る = New うひ硯る()
Return うひ硯る.う("Nothing", String.Empty, CType(obj2, Byte()), True)

Dim obj2 As Object = とむ暮.れなつ(Me.まこうに(Me.こなき(Me.れな())))

Dim うひ硯る As うひ硯る = New うひ硯る()

Return うひ硯る.う("Nothing", String.Empty, CType(obj2, Byte()), True)

The first line calls multiple functions - starting on the far right is “れな”. This function can be seen below and creates an object from a PNG file in the resources section of the DLL.

Picture Time

The PNG itself doesn’t visually show anything of note but static.

The next function “こなき” is a bit more interesting.

This loads the image as a bitmap and then it will read the pixels in a certain order to build an array from the values for Red, Green, and Blue that get returned.

For example, if you look at the bottom left of the image (0,192), you will see a dark green with the hex value 0x1AE2C.

The first entries in the array would be 0x2C (Blue), 0xAE (Green), 0x1 (Red)

To unpack this, I once again re-wrote the code in Python and used the Python Imaging Library (PIL) to extract the bytes. This particular image is 192x192 pixels and 24bits per pixel (3 bytes – RGB) and it iterates over each pixel from left to right, bottom to top, for the array of data.

from PIL import Image
im = Image.open("/Users/pickleRICK/19.png")

def imparse(a):
	width, height = im.size
	counter = 0
	b = [0] * (width * height * 3)
	for y in range(height - 1, -1, -1):
		for x in range(0,width):
			pixel = im.getpixel((x,y))
			b[counter * 3 + 2] = pixel[0] # R
			b[counter * 3 + 1] = pixel[1] # G
			b[counter * 3 + 0] = pixel[2] # B
			counter += 1
	while b[-1] == 0:
		del b[-1]
	return b

from PIL import Image

im = Image.open("/Users/pickleRICK/19.png")

def imparse(a):

width, height = im.size

counter = 0

b = [0] * (width * height * 3)

for y in range(height - 1, -1, -1):

for x in range(0,width):

pixel = im.getpixel((x,y))

b[counter * 3 + 2] = pixel[0] # R

b[counter * 3 + 1] = pixel[1] # G

b[counter * 3 + 0] = pixel[2] # B

counter += 1

while b[-1] == 0:

del b[-1]

return b

After it returns, the byte array gets passed to the now familiar decode function and then the deflate function.

&gt;&gt;&gt; dec = imparse(im)
&gt;&gt;&gt; dec
[44, 174, 1, 0, 237, 11, 8, 125, 109, 41, 15, …

&gt;&gt;&gt; dec = decode(dec)
&gt;&gt;&gt; dec
'\xec\xbd\tx\x1c\xc5\x95\x00\xdcs\xf59#\xa9\xa6G …

&gt;&gt;&gt; dec = zlib.decompress(dec,-15)
&gt;&gt;&gt; dec
'MZ\x90\x00\x03\x00\x00\x00\x04\x00\x00\x00\xff\xff\x00 …

>>> dec = imparse(im)

>>> dec

[44, 174, 1, 0, 237, 11, 8, 125, 109, 41, 15, …

>>> dec = decode(dec)

>>> dec

'\xec\xbd\tx\x1c\xc5\x95\x00\xdcs\xf59#\xa9\xa6G …

>>> dec = zlib.decompress(dec,-15)

>>> dec

'MZ\x90\x00\x03\x00\x00\x00\x04\x00\x00\x00\xff\xff\x00 …

As you can see, we have the MZ header and the next binary.

Within the DLL are additional functions which handle executing the new payload and I’ve gone ahead and decoded some of the native API’s they use to show how they carry out activity.

The final payload

Arrival of the last binary – another .NET application called “RII9DKFR5LC4Y669MLOA2C50SFLPHZBN61CZ160Z.exe”. If you read any of the posts mentioned earlier on the analysis of AgentTesla, then this will look familiar.

Function and variable names are encoded with Unicode values in the range of 0x200B-0x200E. Strings are decrypted by, in this sample, function “KMBHFDXSELJYYLVK\u3002”.

This function uses a hardcoded password and salt to derive a key from the SHA1 hashing algorithm as implemented by Microsoft (modified PBKDF1). Afterwards, it uses the key and hardcoded IV to decrypt the string with AES-CBC.

A quick Google for that IV shows hundreds of results for it, with most revolving around an encryption example that was used as the base for this function – it even copies the examples variable names.

What I found interesting here is that none of these values ever change sample to sample. Even going back to the samples in the write-ups on AgentTesla from over 6 months ago, I was able to decrypt their base64 strings listed in the blog. This confirms the same values are in use and likely hard coded into the builder for AgentTesla.

Given that everything is static then, it’s fairly trivial to extract all of the base64 encoded strings, decrypt them, and look for interesting IoC’s.

from Crypto.Cipher import AES
def stringdecrypt(a):
	string = base64.b64decode(a)
	iv = "@1B2c3D4e5F6g7H8"
	key = "\x34\x88\x6D\x5B\x09\x7A\x94\x19\x78\xD0\xE3\x8b\x1b\x5c\xa3\x29\x60\x74\x6a\x5e\x5d\x64\x87\x11\xb1\x2c\x67\xaa\x5b\x3a\x8e\xbf" #to 6a/5e for first iteration
	cleartext = AES.new(key[0:32], AES.MODE_CBC, iv).decrypt(string)
	return cleartext

fh = open("extractedb64")
content = fh.readlines()
fh.close()
for i in content:
	try:
		dec = stringdecrypt(i)
		print "%s | %s" % (i.strip(),dec.strip())
	except:
		pass

from Crypto.Cipher import AES

def stringdecrypt(a):

string = base64.b64decode(a)

iv = "@1B2c3D4e5F6g7H8"

key = "\x34\x88\x6D\x5B\x09\x7A\x94\x19\x78\xD0\xE3\x8b\x1b\x5c\xa3\x29\x60\x74\x6a\x5e\x5d\x64\x87\x11\xb1\x2c\x67\xaa\x5b\x3a\x8e\xbf" #to 6a/5e for first iteration

cleartext = AES.new(key[0:32], AES.MODE_CBC, iv).decrypt(string)

return cleartext

fh = open("extractedb64")

content = fh.readlines()

fh.close()

for i in content:

try:

dec = stringdecrypt(i)

print "%s | %s" % (i.strip(),dec.strip())

except:

pass

What we end up with is a long list of values like the below.

cWUeT8dJU4KfzxUEgGflzQ== | temp
y9/s0/2Soj9dWZ7YCF9viw== | \des_date.txt
hQ1zQ5Cg31OSE+BZ2Os36w== | 2017-08-25
cWUeT8dJU4KfzxUEgGflzQ== | temp
y9/s0/2Soj9dWZ7YCF9viw== | \des_date.txt
1IhffSZWWBl13XPDs8n3myYCTMqLedaSKEkL/imL258= | dd.MM.yyyy HH:mm:ss
cWUeT8dJU4KfzxUEgGflzQ== | temp
aXsej6rp5uxy+3ym08w3iA== | ApplicationData
haLsi+cj0yodiuWmM+o4Wg== | appdata
AnV66gJ6ewY8YTWIByRSMA== | Temp
cWUeT8dJU4KfzxUEgGflzQ== | temp
zYMGsY8aSA781gMxSStsC9UAfia6hLdLRxgBeS3NtD0= | \Java\JavaUpdtr.exe
cWUeT8dJU4KfzxUEgGflzQ== | temp
y9/s0/2Soj9dWZ7YCF9viw== | \des_date.txt
Akq+/Qobe3bW+jdjmv5oI6h1rNqdq+rlANdh6Ef29KelgAp0y6gsCspLDS+k+xmNC9TpnFhgwZyL///RhoSWxQ== | Software\Microsoft\Windows NT\CurrentVersion\Windows
aZG83zDiQxysOvFJFc8qmg== | Load
8mFIzTz8+GxS3SBdy62qeA== | JavaUpdtr
IMqa7/uMjEFhAZrJPRn9Gw== | False
qQj4VB+mzRT8iDf7llcE6Q== | xyz
hyNN5z+7qAsS695lDXLuHg== | True
…
82ZGUDSQrPCv8v1Hf+HpRA== | &lt;/span&gt;
BJsW0oB1ieLYwE8A0Yu6OlLBTcrh0varR+ibOkyOCrk= | mylogbox4h@gmail.com
2qbrW8tf2IZoaPGZlcaKWw== | /log.tmp
v4EpbnhZTubu6HTjEZ8Gdw== | [SavedLog (
I/tDnJPWEB6yySAivkY/576ixyY2gOP+bLVbbaRIV8A= | yyyy_MM_dd_HH_mm_ss
2qbrW8tf2IZoaPGZlcaKWw== | /log.tmp
Q9Yhy5Uive3G6Gspdid9EQ== | Saved_Log_From_
eCqe8oqjGUIRwUWqnBrrpA== | /
q542gy/+wDIUJhH3OGKnNg== | -
3TzIyOOSC+3lcpPaeTxO6g== | _
4T5LGk6qEvqUS2xRJLUlww== | .html