By Asheer Malhotra.

• Cisco Talos has observed a malware campaign that utilizes malicious Microsoft Office documents (maldocs) to spread a remote access trojan (RAT) we're calling "ObliqueRAT."
  
• These maldocs use malicious macros to deliver the second stage RAT payload.
• This campaign appears to target organizations in Southeast Asia.
• Network based detection, although important, should be combined with endpoint protections to combat this threat and provide multiple layers of security.

What's New?

Cisco Talos has recently discovered a new campaign distributing a malicious remote access trojan (RAT) family we're calling "ObliqueRAT." Cisco Talos also discovered a link between ObliqueRAT and another campaign from December 2019 distributing CrimsonRAT sharing similar maldocs and macros. CrimsonRAT has been known to target diplomatic and government organizations in Southeast Asia.

How did it work?

This RAT is dropped to a victim's endpoint using malicious Microsoft Office Documents (maldocs). The maldocs aim to achieve persistence for the second-stage implant that contains a variety of RAT capabilities, which we're calling "ObliqueRAT." In this post, we illustrate the core technical capabilities of the maldocs and the RAT components including:

• The maldocs based infection chain
• A variant distributed using a dropper EXE.
• Detailed capabilities and command codes of the RAT implant (2nd stage payload).
• Communication mechanisms used.

So what?

This malware is an example of how a simple, yet effective RAT, is used to implement a wide variety of malicious capabilities. Key capabilities of ObliqueRAT include:

• Ability to execute arbitrary commands on an infected endpoint.
• Ability to exfiltrate files.
• Ability to drop additional files.
• Ability to terminate process on the infected endpoint etc.

Analysis of a recently discovered preliminary variant of ObliqueRAT in this post presents insights into the evolution of this threat. Analyses of the key similarities and differences between the two campaigns of ObliqueRAT and CrimsonRAT show us the changes in tactics and techniques of the attackers used to continue attacks while trying to bypass detections. This campaign also shows us that while network-based detection is important, it can be complemented with system behavior analysis and endpoint protections for additional layers of security.

Analysis of Maldocs

Initial Infection Vector

This threat arrives on the endpoint in the form of malicious Microsoft Word documents. The malicious documents (maldocs) prompt the end-user for a password to view the contents of the maldocs. The malicious VB script in the maldocs is activated once the user enters the correct password for the document.

The maldocs have been known to have seemingly benign file names in the wild such as:

• Company-Terms.doc
• DOT_JD_GM.doc

[DOT_JD_GM may possibly stand for "Department Of Telecommunications_Job Description_General Manager"]

These file names indicate that the maldocs may be targeted towards specific individuals as part of a targeted distribution campaign. The initial infection vector of this threat is most likely email based with the body of the malicious email containing the password required to open the maldocs.

Malicious VBA Analysis

Once opened, the maldoc activates a malicious VBA script that performs the following malicious activities:

1. Extracts the contents of a form/textbox.


2. This content consists of an MS Windows binary embedded as a character representation of the binary's bytes delimited using a specific character (e.g. "O" used as a delimiter).


Delimited Malicious MZ embedded in maldoc highlighted.



3. The malicious binary is extracted from the maldoc by the VBA script and dropped on the endpoint to the location:
   C:\Users\Public\sgrmbrokr.doc
   


4. The file is consequently renamed to an exe : C:\Users\Public\sgrmbrokr.exe


5. The malicious VBScript then creates a shortcut in the currently logged in user's Start-Up directory to achieve persistence across reboots for the malicious executable (MZ) written to the file system in previous steps. The shortcut created is:
   %userprofile%\\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\saver.url
   


6. Once the shortcut is created the VBScript stops execution without executing the actual second-stage payload (ObliqueRAT).

Second-stage payload analysis: ObliqueRAT

The second-stage binary (ObliqueRAT) contains the following features:

• RAT capabilities (detailed below).
• Ability to communicate with the command and control server (C2) to obtain command codes and send back executed command outputs.

Mutex Creation

The RAT ensures that only one instance of its process is running on the infected endpoint at any given time by creating and checking for a mutex named "Oblique". If the named mutex already exists on the endpoint then the RAT will stop executing until the next login of the infected user account.

Gather initial system fingerprint

Once the malware has created the named mutex, it attempts to gather an initial fingerprint of the system to identify the system. This information is then sent to the operating C2 to fingerprint the system to decide which commands to send next.

Sysinfo gathered by the RAT:

• Computer Name.
• Current User Account Name.
• Windows operating system (OS) version in the form of a textual representation:

• XP
• XP SP2
• Vista
• 7
• 8
• 8.1
• 10

• OS bitness i.e.

• 64 bits
• 32 bits

• Directory & File Check: A unique feature of the RAT is that it looks for the presence of a specific directory and all files residing inside it. The directory path (folderpath) is hardcoded in the RAT: C:\ProgramData\System\Dump.
  If this directory is present on the infected system then the RAT sends the keyword "Yes" to its C2 and "No" otherwise.

• Another hard coded value from the implant "5.2" is sent to the C2. (May indicate version number of the implant)

The sysinfo gathered by the implant is then put together as a single string with the character ">" used as a delimiter.

Format used:

(_variable_ = used for depicting a variable value)

_ComputerName_>_UserName_>Windows _version-string_>_implant-name-on-disk_>_OS-bitness_>_Dump_dir_files_exist_>_hardcoded_implant_version_number_>

E.g.

DESKTOP-SCOTTPC>jon>Windows 10>sgrmbrokr>64 bits>Yes>5.2>

Although the implant gathers the system information initially, it only sends this information out if it receives a specific command code from the C2. The implant also performs anti-infection checks before it fully activates itself on the endpoint.

Anti-Infection Checks

Another interesting feature in the implant is that after it gathers the preliminary system information for fingerprinting, it performs a series of checks against the user and computer name it has obtained to identify an endpoint or user account it must avoid its execution on/for. If any of the values from its blacklist match the current user/computer name, it simply stops its execution.

The usernames blacklisted by the implant are:

• John
• Test
• Johsnson
• Artifact
• Vince
• Serena
• Lisa
• JOHNSON
• VINCE
• SERENA

A similar check is done for the computer name as well. The list of computer name values blacklisted by the implant are:

• JOHN
• TEST

The anti-infection checks may have been implemented to:

• Avoid successful execution of the implant on a Sandbox based detection system (Anti-Analysis Technique) OR
• Prevent execution of the implant in the attackers' test environment.

RAT command codes and functionalities

The implant then connects to its C2 server using hardcoded values of its IP Address and Port Number.


On connection, the implant receives a command code from the C2 that corresponds to the capability the implant is supposed to execute next on the endpoint. Also, everytime the implant receives a command from the C2 it sends back an acknowledgement message to the C2 indicating that it has received the command code.

The acknowledgment sent to the C2 is always the keyword "ack".


The command codes, supporting command data (both sent by the C2) and capability description are detailed below.


This command code is used to find files and record file sizes in KB for files specified by a specific folder or file path. The data gathered by the implant is in format:

(_variable_ = used for depicting a variable value)
_filepath_<_size_in_KB_;_filepath_<_size_in_KB_;

E.g.
pony.txt<4;bigpony.txt<100;


Send the already gathered system information (sysinfo) described previously to the C2 server for fingerprinting the infected host.



This command is aimed to trigger the implant to discover the category of various drives on the endpoint. The drives to be checked for are listed as hardcoded drive letters in the implant:

• A:
• B:
• C:
• D:
• E:
• F:
• G:
• H:
• I:
• J:
• K:
• L:

The drive types for the drives checked on the system are represented textually by the implant using the following keywords:

• Unknown
• Removable Drive
• Hard Drive
• Network Drive
• CD Drive
• RAM Disk

The data sent out for this command is in format:

(_variable_ = used for depicting a variable value)
_drive-letter_>_Drive-type_|_drive-letter_>_Drive-type_|

E.g.
C:>Hard Drive|D:>CD Drive|



Receive a target filename and ZIP filename from the C2server. Create a new ZIP file with the name provided in the %temp% directory and add the target file to it. Once done, send the contents of the ZIP file to the C2 server.

The ZIP file is subsequently deleted from the endpoint after exfiltration.

The implant also records the target filename that has been exfiltrated (in ZIP form) from the endpoint to a log file called: %temp%\lgb



Variant of command code "4." The difference here is that the implant doesn't require a different ZIP file name from the C2 it simply uses the name of the target filename and creates a ZIP file.

E.g. if the target file name is "abc.txt" then the ZIP file name is "abc.txt.zip"


Accept a folder path from the C2 server, recursively find all files residing in the folders and ZIP them up into a ZIP file with the same name as the folder path specified by the C2. (The ZIP file is created in the operating directory of the implant). This ZIP file is then exfiltrated by the implant to the C2 and subsequently deleted.


Variant of command code ="5". The difference here is that implant accepts only a foldername and recursively calculates the file sizes and builds the list of filepaths and filesizes in the same format:

_filepath_<_filesize_;_filepath_<_filesize_;_filepath_<_filesize_;


Execute given command line on the endpoint with a high priority (The output of the command executed on the endpoint is not sent back to the C2 though).



This command is used by the implant to write a file sent by the C2 to the infected endpoint. To achieve this functionality the implant recvs the following info from the C2 server:

• Path of the file to be written to on disk.
• Size of the file to be being sent by the C2.
• Contents of the file to be written to disk.

Backup the contents of the lgb log file to another file. The backup is done

From = %temp%\lgb
To = %temp\lgb2

The implant reads the lgb log file character by character and writes it to the lgb2 file. On encountering a newline character, the newline is replaced by "*\n" instead.

Once the backup is done the implant will remove the "lgb" log file and then rename the lgb2 file back to "lgb" (Convoluted backup mechanism used here).


Rename a file to a new name provided by the C2.



This command is used to gather the list of running processes on the system, record this information to a log file and exfiltrate the contents of the log file. Once the log file has been sent to the C2 it is removed from the endpoint.

Log filepath used = C:\ProgramData\a.txt

Log file format =

Running Processes
<process_image_name>
<process_image_name>
<process_image_name>
.
.
.



Stop execution of implant on the endpoint without removing persistence from Star-tUp folder.


Restart the socket connection to the C2.


Find all processes by the name specified by the C2 and terminate them.



This command code is used to trigger a recursive search sweep of one or more directories specified by the C2 server. This sweep is done to verify the presence of files specified by a filename. The data specified by the C2 is:

• Folder path(s) to find files in.
• File name(s) to find.
• File extension(s) to find files.

Any files matching the specified criteria are logged into the file C:\ProgramData\auto.txt

Format:

_folderpath_>_filename1_,_filename2_,_filenameN_<_file-extn1_,_file-extn2_,_file-extnN_

E.g.

If the command data sent by the C2 is:
c:\dummy>pony.txt,blah.exe<txt,exe

Then if these files exist, the log file ("auto.txt") will contain:
c:\dummy\pony.txt
c:\dummy\blah.exe

The log file (auto.txt) is then read and the contents are sent to the C2 followed by its deletion.


This command is used to delete (remove) a file specified by the C2 server from the endpoint.

RAT(Implant's) Communication Mechanisms

ObliqueRAT utilizes the ws2_32.dll library to communicate with its C2. This library is used to implement the core socket libraries supported by MS Windows.

Keywords used by the RAT during communication are:

• "ack\0" = Acknowledgment of the command code received as well as an indicator of successful command execution.
• "nak\0" = Indicates failure to execute functionality without providing reason for failure to the C2.

Variant #0 - ObliqueRAT

Cisco Talos also discovered another variation of the ObliqueRAT attack distributed via a malicious dropper. The malicious dropper contains 2 EXEs embedded in it that will be dropped to disk during execution to complete the infection chain. The initial distribution vector of this dropper is currently unknown.

Variant #0 Artifacts:

Dropper EXE:

• 4a25e48b8cf515f4cdd6711a69ccc875429dcc32007adb133fb25d63e53e2ac6

ObliqueRAT Variant #0 EXE:

• 9da1a55b88bda3810ccd482051dc7e0088e8539ef8da5ddd29c583f593244e1c

Persistence Component EXE:

• ad17ada0171b9e619000902e62b26b949afb01b974a65258e4a7ecd59c248dba

Variant #0 Dropper Analysis

The dropper consists of one EXE with another two additional EXEs embedded in it. During execution the dropper will perform the following activities:

If specific file markers exist in the dropper's binary file on disk: (Markers used= "***")

1. If the markers exist then read the data between the markers (there will be 2 such markers for 2 embedded EXEs) and write it to files on disk:
   C:\Users\Public\Video\hrss.exe
   C:\Users\Public\Video\lphsi.exe
2. Execute these files using the ShellExecute API.

If the markers do not exist then it will package its components into a new copy of itself:

1. Look for files named "a.exe" and "b.exe" in the current working directory and read their contents into memory.
2. Rename itself (the dropper) to "fin.exe".
3. Append to itself (fin.exe) the magic markers specified ("***") and the contents of "a.exe" and "b.exe" thereby completing the packing process.

ObliqueRAT component Functionalities (lphsi.exe)

The ObliqueRAT sample dropped by the dropper has the same capabilities as the ObliqueRAT sample discussed above. There is a slight variation though (discussed in the comparison section below).

Persistence Module (hrss.exe)

The 2nd EXE (hrss.exe) executed by the dropper is used only to establish persistence for the ObliqueRAT sample (lphsi.exe). This is done by creating a shortcut in the currently logged in user's Start-Up directory to execute ObliqueRAT whenever the user logs into the infected endpoint.

Shortcut created: %userprofile%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\script.lnk

Variant #0 Comparison

Variant #0 (9da1a55b88bda3810ccd482051dc7e0088e8539ef8da5ddd29c583f593244e1c) discovered by Cisco Talos looks like a preliminary version of the ObliqueRAT attack detailed in this post (37c7500ed49671fe78bd88afa583bfb59f33d3ee135a577908d633b4e9aa4035).

This is because of the following factors:

1. Variant #0 has an earlier compile time of 04/11/2019 12:12:04 UTC while the ObliqueRAT implant detailed in this post has a later compile time of 27/11/2019 08:40:10 UTC.
2. Although the hardcoded version number of both the implants is "5.2", variant #0 contains an additional feature where, if the implant fails to connect to the C2 server it will display any of two Message Boxes consisting of:
   Title = scokerr
   Text = sockerror
   
   and
   
   Title = grace
   Text = grace
   
   

This indicates that variant #0 may be a test copy of ObliqueRAT that was released into the wild by the attackers without scrubbing the Message Boxes used for debugging the C2 connection functionality (Thus identified as "Variant #0").

Related campaigns: CrimsonRAT vs. ObliqueRAT

The malicious VBA Scripts in the maldocs discovered by Talos semantically resemble a previously observed maldoc distribution campaign (from 2019) delivering another .NET based RAT family popularly known as CrimsonRAT. CrimsonRAT has been known to target organizations in Southeast Asia.

An example of a maldoc (from December 2019) observed distributing the CrimsonRAT malware is:

• 965b90d435c1676fa78cdce1eee2ec70e3194c0e4f0d993bc36bfd9f77697969

The CrimsonRAT sample dropped by the maldoc is:

• 98894973a86aa01c4f7496ae339dc73b5e6da2f1dbcd5fe1215f70ea7b889b85

Similarities Between the Two Campaigns

This CrimsonRAT maldoc although not password protected (as in the case of the maldocs containing ObliqueRAT) contains the following similarities w.r.t the ObliqueRAT maldocs:

• Similar VB variable naming conventions for filenames, folder names, ZIP file names:
  E.g.
  
  The ObliqueRAT VBScripts use variables named:
  file_Salan_name, fldr_Salan_name, zip_Salan_file
  
  while the CrimsonRAT VBScripts use variables named:
  file_Allbh_name, fldr_Allbh_name, zip_Allbh_file
  
  
• Similar decoding technique for the next stage payload:
  Both sets of VBScripts extract the embedded next stage payload from a form (textbox) where the bytes of the next stage payload are character representations (of decimal numbers) delimited by a specific character.
  

Differences Between the Two Campaigns

• The CrimsonRAT maldocs drop the next stage payload to a ZIP file (E.g. %allusersprofile%\intaRD\thnaviwa.zip) on the filesystem.
  However the ObliqueRAT maldocs drop the RAT payload directly to a file named:
  C:\Users\Public\sgrmbrokr.exe
  

• As mentioned above, the CrimsonRAT maldocs drop a malicious ZIP file on the disk first and then extract the EXE within the archive file. This malicious EXE (.NET based CrimsonRAT) is then executed on the infected endpoint.
  The ObliqueRAT maldocs however simply drop the malicious EXE (ObliqueRAT EXE) directly on the filesystem, create a shortcut in the infected user's StartUp folder. The EXE is not executed and the malware relies on the user to re-login for the ObliqueRAT infection to trigger.
  

Conclusion

This campaign shows a threat actor conducting a targeted distribution of maldocs similar to those utilized in the distribution of CrimsonRAT. However, what stands out here is that the actor is now distributing a new family of RATS. Although it isn't technically sophisticated, ObliqueRAT consists of a plethora of capabilities that can be used to carry out various malicious activities on the infected endpoint. The fact that the maldocs are password protected (and that the ObliqueRAT implant consists of probable anti-analysis techniques) indicates the attackers' intent to hide the malicious activities of the infection from an analyst. This campaign started in January 2020 and is still ongoing. This campaign also shows us that while network-based detection is important, it must be complemented with system behavior analysis and endpoint protections.

Coverage

Ways our customers can detect and block this threat are listed below.



Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware detailed in this post. Below is a screenshot showing how AMP can protect customers from this threat. Try AMP for free here.

Cisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.

Email Security can block malicious emails sent by threat actors as part of their campaign.

Network Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), and Meraki MX can detect malicious activity associated with this threat.

Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.

Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.

Additional protections with context to your specific environment and threat data are available from the Firepower Management Center.

Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

AMP Detections

AMP detects the ObliqueRAT implants as follows:

Indicators Of Compromise (IOCs)

The following IOCs are related to this threat:

ObliqueRAT

Maldocs

• 057da080ae0983585ae21195bee60d82664355a7fd78c25f21791b165c250212
• dfad2a80dac91e7703266197ebbf5d67ef77467ab341dd491ad25d92d8118cac

Dropper (for Variant #0)

• 4a25e48b8cf515f4cdd6711a69ccc875429dcc32007adb133fb25d63e53e2ac6

2nd Stage Malicious EXEs

• ObliqueRAT - 37c7500ed49671fe78bd88afa583bfb59f33d3ee135a577908d633b4e9aa4035
• Variant #0 - 9da1a55b88bda3810ccd482051dc7e0088e8539ef8da5ddd29c583f593244e1c

Persistence Component

• ad17ada0171b9e619000902e62b26b949afb01b974a65258e4a7ecd59c248dba

Mutexes Created by 2nd Stage EXEs:

• "Oblique"

C2 IP Addresses and URLs:

• 185[dot]117.73.222:3344

CrimsonRAT

Maldocs

• 965b90d435c1676fa78cdce1eee2ec70e3194c0e4f0d993bc36bfd9f77697969

Next Stage Malicious ZIPs & EXEs

• 3671b7ed9f67098d2a534673ed9ff46e90c03269c0bdd9b6f39ae462915ecdcb [ZIP]
• 2911a3da2299817533ca27a0d44c8234fdf9ecd0a285358041da245581673d6f [ZIP]
• 98894973a86aa01c4f7496ae339dc73b5e6da2f1dbcd5fe1215f70ea7b889b85 [exe]
• e436be68cdbdb7ea20e5640ad5fa5eca1da71edb9943c3bde446b4c75dacfbd0 [exe]

Newsletter compiled by Jon Munshaw.


Welcome to this week’s Threat Source newsletter — the perfect place to get caught up on all things Talos from the past week.

We’ve got more ways than ever for you to get Talos content. We continue to grow our YouTube page with the second entry in the “Stories from the Field” series, this time with Matt Aubert discussing when to get lawyers involved in an incident.

Our podcast family also continues to grow, with new episodes this week of Talos Takes and Beers with Talos.

On the old-fashioned write-up end of things, we have the latest on our research into adversaries’ use of living-off-the-land binaries (also known as “LoLBins”). Recently, we’ve seen a wave of attacks utilizing the Microsoft Build Engine to conduct post-infection activities.

And, as always, we have the latest Threat Roundup where we go through the top threats we saw — and blocked — over the past week. 

Upcoming public engagements

Cyber Security Week in Review

Title: Snake/Ekans malware adds new functionality to go after ICS
Description: The Snake ransomware (otherwise known as “Ekans”) has added new capabilities aimed at going after industrial industries. Ekans first emerged in December, but now has a relationship with the MEGACORTEX ransomware that could allow it to spread quickly on ICS systems and even force some services to revert to manual operations. The malware’s code now includes direct references to HMI processes and historian clients that are commonly linked to ICS.
Snort SIDs: 53106, 53107

Title: Carrotbat malware, Syscon backdoor team up to target federal government
Description: An American federal agency was targeted in late January with a series of phishing emails utilizing a variant of the Carrotbat malware and the Syscon backdoor. Attackers used six unique email attachments in the campaign, all relating to the ongoing strained relationship between the U.S. and North Korea. Security researchers say these attackers are still active, despite the majority of their activity taking place over the summer.
Snort SIDs: 53129 – 53145

Most prevalent malware files this week

Jared Rittle and Carl Hurd of Cisco Talos discovered these vulnerabilities. Blog by Jon Munshaw.

The Moxa AWK-3131A networking device contains several different vulnerabilities that an attacker could exploit to carry out malicious activities in an industrial environment. The AWK-3131A is a wireless networking device that is meant to be used in large-scale, industrial cases to provide
communication across the environment in which it's deployed. This device contains several bugs that could lead to numerous malicious activities, including remote code execution and privilege escalation.

In accordance with our coordinated disclosure policy, Cisco Talos worked with Moxa to ensure that these issues are resolved and that an update is available for affected customers.

Vulnerability details

Moxa AWK-3131A iw_console privilege escalation vulnerability (TALOS-2019-0925/CVE-2019-5136)

An exploitable privilege escalation vulnerability exists in the iw_console functionality of the Moxa AWK-3131A, firmware version 1.13. A specially crafted menu selection string can cause an escape from the restricted console, resulting in system access as the root user. An attacker can send commands while authenticated as a low privilege user to trigger this vulnerability.

Read the complete vulnerability advisory here for additional information.

Moxa AWK-3131A ServiceAgent use of hard-coded cryptographic key (TALOS-2019-0926/CVE-2019-5137)

The usage of hard-coded cryptographic keys within the ServiceAgent binary allows for the decryption of captured traffic across the network from or to the Moxa AWK-3131A, firmware version 1.13.

Read the complete vulnerability advisory here for additional information.

Moxa AWK-3131A encrypted diagnostic script command injection vulnerability (TALOS-2019-0927/CVE-2019-5138)

An exploitable command injection vulnerability exists in encrypted diagnostic script functionality of the Moxa AWK-3131A, firmware version 1.13. A specially crafted diagnostic script file can cause arbitrary busybox commands to be executed, resulting in remote control over the device. An attacker can send diagnostic while authenticated as a low-privilege user to trigger this vulnerability.

Read the complete vulnerability advisory here for additional information.

Moxa AWK-3131A multiple iw_* utilities use of hard-coded credentials vulnerability (TALOS-2019-0928/CVE-2019-5139)

An exploitable use of hard-coded credentials vulnerability exists in multiple iw_* utilities of the Moxa AWK-3131A, firmware version 1.13. The device operating system contains an undocumented encryption password, allowing for the creation of custom diagnostic scripts.

Read the complete vulnerability advisory here for additional information.

Moxa AWK-3131A iw_webs DecryptScriptFile file name command injection vulnerability (TALOS-2019-0929/CVE-2019-5140)

An exploitable command injection vulnerability exists in the iw_webs functionality of the Moxa AWK-3131A, firmware version 1.13. A specially crafted diagnostic script file name can cause user input to be reflected in a subsequent iw_system call, resulting in remote control over the device. An attacker can send commands while authenticated as a low-privilege user to trigger this vulnerability.

Read the complete vulnerability advisory here for additional information.

Moxa AWK-3131A iw_webs iw_serverip parameter command injection vulnerability (TALOS-2019-0930/CVE-2019-5141)

An exploitable command injection vulnerability exists in the iw_webs functionality of the Moxa AWK-3131A, firmware version 1.13. A specially crafted iw_serverip parameter can cause user input to be reflected in a subsequent iw_system call, resulting in remote control over the device. An attacker can send commands while authenticated as a low-privilege user to trigger this vulnerability.

Read the complete vulnerability advisory here for additional information.

Moxa AWK-3131A WAP hostname command injection vulnerability (TALOS-2019-0931/CVE-2019-5142)

An exploitable command injection vulnerability exists in the hostname functionality of the Moxa AWK-3131A firmware, version 1.13. A specially crafted entry to network configuration information can cause the execution of arbitrary system commands, resulting in full control of the device. An attacker can send various authenticated requests to trigger this vulnerability.

Read the complete vulnerability advisory here for additional information.

Moxa AWK-3131A iw_console conio_writestr remote code execution vulnerability (TALOS-2019-0932/CVE-2019-5143)

An exploitable format string vulnerability exists in the iw_console conio_writestr functionality of the Moxa AWK-3131A firmware version 1.13. A specially crafted time server entry can cause an overflow of the time server buffer, resulting in remote code execution. An attacker can send commands while authenticated as a low-privilege user to trigger this vulnerability.

Read the complete vulnerability advisory here for additional information.

Moxa AWK-3131A ServiceAgent denial-of-service vulnerability (TALOS-2019-0938/CVE-2019-5148)

An exploitable denial-of-service vulnerability exists in ServiceAgent functionality of the Moxa AWK-3131A, firmware version 1.13. A specially crafted packet can cause an integer underflow, triggering a large memcpy that will access unmapped or out-of-bounds memory. An attacker can send this packet while unauthenticated to trigger this vulnerability.

Read the complete vulnerability advisory here for additional information.

Moxa AWK-3131A iw_webs user configuration remote code execution vulnerability (TALOS-2019-0944/CVE-2019-5153)

An exploitable remote code execution vulnerability exists in the iw_webs configuration-parsing functionality of the Moxa AWK-3131A, firmware version 1.13. A specially crafted username entry can cause an overflow of an error message buffer, resulting in remote code execution. An attacker can send commands while authenticated as a low-privilege user to trigger this vulnerability.

Read the complete vulnerability advisory here for additional information.

Moxa AWK-3131A iw_webs account settings improper access control vulnerability (TALOS-2019-0955/CVE-2019-5162)

An exploitable improper access control vulnerability exists in the iw_webs account settings functionality of the Moxa AWK-3131A, firmware version 1.13. A specially crafted username entry can cause the overwrite of an existing user account password, resulting in remote shell access to the device as that user. An attacker can send commands while authenticated as a low-privilege user to trigger this vulnerability.

Read the complete vulnerability advisory here for additional information.

Moxa AWK-3131A iw_webs hostname authentication bypass vulnerability (TALOS-2019-0960/CVE-2019-5165)

An exploitable authentication bypass vulnerability exists in the hostname processing of the Moxa AWK-3131A firmware version 1.13. A specially configured device hostname can cause the device to interpret select remote traffic as local traffic, resulting in a bypass of web authentication. An attacker can send authenticated SNMP requests to trigger this vulnerability.

Read the complete vulnerability advisory here for additional information.

Versions tested

Talos tested and confirmed that these vulnerabilities affect the Moxa AWK-3131A, running firmware version 1.13.

Coverage

The following SNORTⓇ rules will detect exploitation attempts. Note that additional rules may be released at a future date and current rules are subject to change pending additional vulnerability information. For the most current rule information, please refer to your Firepower Management Center or Snort.org.

Snort Rules: 52010 - 52018, 52024, 52025, 52086, 52241

This signature can be found in many packer signature databases available online, and is responsible for many false positives (e.g. 7z.exe, a commonly used tool, is flagged as being packed by Armadillo).

This imprecision has many consequences on malware related systems and studies:

• Sample ingestion pipelines often rely on static data, which is not reliable if a sample is packed.
• Machine learning based classifiers need to be trained with a solid source of ground truth. Polluted datasets negatively affect the reliability and performance of these approaches.
• A wrong classification of packed vs. not packed malware can affect studies that analyze trends in malware.

Researchers have sporadically mentioned the existence of low-entropy packers, but it was still unclear if this phenomenon is relevant or negligible. We conducted a systematic study over a curated dataset of 50,000 low-entropy malicious PE files belonging to multiple families, obtained from the VirusTotal public feed, observed between 2013 and 2019. Then, we leveraged a dynamic analysis system based on the PANDA binary instrumentation framework in order to provide ground truth about the presence of a packer and the scheme used to keep entropy low: byte padding, encoding, transposition, monoalphabetic and polyalphabetic substitution.

For further details about these schemes, our dynamic analysis component, and how we designed and conducted these experiments, you can refer to the full paper. Our results show that over 30 percent of these low-entropy files adopt some type of run-time packing. Similarly, we obtained a dataset belonging to APT samples obtained from numerous reports and whitepapers, conducted a similar experiment and observed that up to 15 percent of these low-entropy files were packed. These numbers confirm that the phenomenon is not negligible and must not be ignored in future studies.

In a second test, we evaluated the detection rates of commonly used tools such as PEiD, DIE, and Manalyze. All the tools had difficulties to recognize low-entropy packers as packed, and some of them showed false positive detections of common off-the-shelf packers due to weak heuristics or signatures.

Finally, we conducted an experiment to evaluate several machine-learning based classification approaches to distinguish between packed and not packed files. For this, we collected all the features used to date in different academic publications. In all cases, these classifiers showed an important performance degradation when trained and evaluated on a dataset with low-entropy packers: even the best classifier was able to detect only 70 percent of the packed samples in our dataset.

For more on our research, the authors of this research paper will be presenting their work at NDSS on February 26th, 2020. You can also download the full research paper here...

Recorded Feb. 19, 2020

Craig made an oopsie. Pardon his echo-chamber reverb. We had no idea until he sent in his audio for mixing. This is a shorter episode focusing on software licencing and features, as well as vulnerability disclosure. Join us to talk about vendors' abilities to disable feature sets and owning versus using products. We further chat about vulnerabilities and how a vendor with no security advisories is often seen as a “more secure” option, when in fact, that can mean the exact opposite.

Newsletter compiled by Jon Munshaw.

Welcome to this week’s Threat Source newsletter — the perfect place to get caught up on all things Talos from the past week.

We know we’ve kept you waiting for a while, but the new Snort Resources page is finally here. We’ve got new and improved documentation, but our most exciting feature is the new Snort 101 video series. In these short tutorials, you’ll learn everything you need to know about configuring Snort 2 and 3, and even dives a little bit into rule writing. Head over to the Snort blog for more.

If you’re hanging out at RSA, what better way to escape the crowds for a few minutes than slinking off to listen to the new Beers with Talos episode. It’s shorter than usual, but we’ve still got plenty of talk of vulnerability research and software licenses.

And, as always, we have the latest Threat Roundup where we go through the top threats we saw — and blocked — over the past week.

Upcoming public engagements

Cyber Security Week in Review

Title: ObliqueRAT spreads via malicious documents
Description: Cisco Talos has observed a malware campaign that utilizes malicious Microsoft Office documents (maldocs) to spread a remote access trojan (RAT) we're calling "ObliqueRAT." These maldocs use malicious macros to deliver the second-stage RAT payload. Network-based detection, although important, should be combined with endpoint protections to combat this threat and provide multiple layers of security. According to Talos researchers, ObliqueRAT has connections to the adversaries behind the CrimsonRAT discovered last year.
Snort SIDs: 53152 - 53163

Title: Multiple vulnerabilities in Cisco Data Center Network Manager 
Description: Cisco Data Center Network Manager contains a privilege escalation vulnerability and a cross-site request forgery vulnerability. Cisco disclosed the high-severity vulnerabilities late last week. In the casea of the privilege escalation vulnerability, an attacker could exploit the Network Manager in a way that would allow them to interact with the API with administrator-level privileges. A successful exploit could allow the attacker to interact with the API with administrative privileges.
References: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200219-dcnm-priv-esc

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200219-dcnm-csrf
Snort SIDs: 53171 - 53176

Most prevalent malware files this week

The Cisco Talos Incident Response "Stories from the Field" video series returns with another entry from Matt Aubert.

This time, Matt discusses ransomware infections he's seen in real-time, and shares what defenders can learn from others' mistakes and recovery.

Is it ever smart to pay attackers' request extortion payment? Which ransomware families should organizations be most worried about? Matt covers all of this in just six minutes.

You can watch the full video above or over on our YouTube page here. You can get all of the Stories from the Field videos in one place on our playlist, too.

By Warren Mercer, Paul Rascagneres and Vitor Ventura.

Executive summary

• Security researchers detected and exposed the Bisonal malware over the past 10 years. But the Tonto team, the threat actor behind it, didn't stop.
• The victimology didn't change over time, either. Japanese, South Korean and Russian organizations were the prime targets for this threat actor.
• The malware evolved to lower its detection ratio and improve the initial vector success rate.

What's new?

Bisonal is a remote access trojan (RAT) that's part of the Tonto Team arsenal. The peculiarity of the RAT is that it's been in use for more than 10 years — this is an uncommon and long period for malware. Over the years, it has evolved and adapted mechanisms to avoid detection while keeping the core of its RAT the same. We identified specific functions here for more than six years.

How did it work?

Bisonal used multiple lure documents to entice their victims to open and then be infected with Bisonal malware. This group has continued its operations for over a decade and they continue to evolve their malware to avoid detection. Bisonal primarily used spear phishing to obtain a foothold within their victims' networks. Their campaigns had very specific targets which would suggest their end game was more around operational intelligence gathering and espionage.

So what?

This is an extremely experienced group likely to keep their activities even after exposure, even if we identified mistakes and bad copy/paste, they are doing this job for more than 10 years. We think that exposing this malware, explaining the behavior and the campaigns where Bisonal was used is important to protect the potential future targets. The targets to this point are located in the public and private sectors with a focus on Russia, Japan and South Korea. We recommend the entities located in this area to prepare for this malware and actor and implement detections based on the technical details provided in this article.

Victimology and campaigns

From our analysis and the intelligence shared by the community throughout the last decade of activities of Bisonal, we can conclude that the actor behind this malware is specifically targeted at the South East Asian region, namely Japan and Korea with another significant focus on Russian-speaking victims.


We identified a couple of decoy documents pointing to the victims. During the Heartbeat campaign documented in 2012 by Trend Micro, dating back to 2009, the attacker used Hangul Word Processor (HWP) decoy documents. This file format is mainly used in South Korea. The report mentioned political parties, media outfits, a national policy research institute, a military branch of South Korean armed forces, a small business sector organization and branches of the South Korean government. Later in 2018, Unit 42 released a Bisonal paper where we can see a spear-phishing campaign in Russian and a decoy document alleged to be from Rostec, a Russian state-owned holding conglomerate headquartered in Moscow.

Finally, in 2018, Ahnlab released a paper about "Operation Bitter Biscuit" where Bisonal was used against Korean and Japanese entities. India is also mentioned, but it was by another malware named "Bioazih" by Ahnlab. In this paper, the editor mentions targets such as manufacturers, defense industry and government.

Additionally, we can provide additional decoy documents. For example, a Korean document used in September 2014 where the title was "Contact member and counselor of the Agriculture, Forestry, Livestock, Food and Marine Fisheries Committee:"

Or a Russian document about the CIPR Digital conference used in April 2018. This is an application document that has been used to provide a decoy to the Bisonal malware. This conference has some high-ranking government and business attendees.

In 2019, a Russian RTF document — судалгаа.doc (research.doc) — was used with an exploit to drop the winhelp.wll file, which contains Bisonal.

Last year, we also identified multiple Korean decoy documents using similar RTF exploits to deliver Bisonal, namely ☆2020년도 예산안 운영위 서면질의 답변서_발간(1).doc (State Council Candidate (Minister of Justice Chumiae) Personnel Hearing Execution Plan (1) .doc) and 국무위원후보자(법무부장관 추미애) 인사청문회 실시계획서(1).doc (Written Inquiry from the 2020 Budget Operation Committee (Published) (1) .doc) which are both alleged government documents.

Based on our research and the released paper mentioned above, the Bisonal malware is part of the Tonto Team arsenal. Tonto Team was mentioned in the media in 2017 as one of the actors who targeted South Korea, when the country announced it would deploy a Terminal High-Altitude Air Defense (THAAD) in response to North Korean missile tests. At this time, researchers connected the Tonto Team to China.

10 years of evolution

Introduction

The first variant of Bisonal publicly released went by the name of "HeartBeat." At the end of 2019, the actor changed their TTP and started using the Microsoft Office extension (.wll) to execute the Bisonal payload. Based on this recent change, we decided to dive into the 10 years of evolution of Bisonal. To do so, we analysed more than 50 different samples and focused on the changes that appear during the years of usage.

2010: the birth

The oldest version of Bisonal we identified was compiled on Dec. 24, 2010. This version is the simplest we identified. The attacker created a Windows library (.dll) designed as a Windows service (ServiceMain() entry point). When executed, the malware uses the Windows API to communicate with the Service Control Manager (SCM) and finally execute a thread. This thread contains the code of the malware.

The C2 server of this first Bisonal variant is young03[.]myfw[.]us (port 8888). We can notice the usage of a dynamic DNS service. This is a Bisonal pattern. Even the newest version we identified used this kind of service. The domain name was not obfuscated:

The IP address is a rollback if the first C2 server is down. In this campaign, the rollback was not used as it is configured to localhost. The communication to the C2 server is performed by using raw sockets:

The first action of the malware is to send the hostname of the infected system and the "kris0315" string. The sent data is not encrypted or obfuscated. We assume the string is an identifier:

The malware supports only three commands:

• Command execution: The execution is performed by the ShellExecuteW() API
• Listing the running processes
• Cleaning the malware: The malware first removes the registry key of the service and removes the library. As the library is currently running, the deletion cannot be performed immediately. The developer decided to use MoveFileEx() API with the MOVE_DELAY_UNTIL_REBOOT to remove the file at the reboot.

The malware contains the Bisonal string. It is interesting to notice the string is not used but is still visible:

The sample was used in the HeartBeat campaign mentioned above.

Sha256: ba0bcf05aaefa17fbf99b1b2fa924edbd761a20329c59fb73adbaae2a68d2307
C2 server: young03[.]myfw[.]us

2011: obfuscation my darling & more espionage capabilities

2011 March: commect()

We identified a sample from March 18, 2011. The sample is really similar to the variant from 2010. We can notice that the developers wanted to hide some API usage. They use the LoadLibrary() API followed by GetProcAdress(). But they obfuscated the function name strings by splitting it in two. Here is an example:

Once the two strings are concatenated and with the little-endian, the string becomes "commect." After the malware replaces the "m" by "n:"

They use this trick for a couple of other API such as CreateThread(), CreatePipe(), PeekNamedPipe(), CreateProcessA(), CreateToolhelp32Snapshot(), ReadFile(), WriteFile() and, finally, the string "cmd.exe."

The attacker also implemented a new order: execution of a command by using named pipe to get the output of the executed command. The attackers execute cmd.exe, followed by the command to be executed. An interesting point is the adding of a charset on each executed command:

This charset is designed to cover languages that use Cyrillic script such as Russian, Bulgarian and Serbian. This hardcoded string could be an indicator concerning the targets of this malware.

sha256 : bb61cc261508d36d97d589d8eb48aaba10f5707d223ab5d5e34d98947c2f72af
C2 server: kissyou01[.]myfw[.]us

2011 September: The big changes

The developer decided to remove the MFC library and put almost all the code in a unique function. The number of functions is divided by three. Here is the main thread graph flow:

Additionally, the string such as the domain names of the URLs is encoded by using the XOR algorithm (0x1f for example). The network communication is also obfuscated with a XOR (0x28).

On the version, the attacker supports the proxy server. It was a limitation of the previous variants. If the target would have a proxy, the malware would not be able to communicate outside. The attacker retrieves the proxy configuration in the registry:

The network communication is divided in two parts. The first part uses the Microsoft Windows Wininet library. The purpose is to send reconnaissance information to the attackers. The data is sent to the server via InternetOpenA() and InternetOpenURLA(). The C2 server of the analysed sample is hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp. The malware sent to the operator the following information: the campaign ID (named Flag by the developer), the hostname of the compromised system, the IP address, the OS version, the proxy server of the system and if the system is running on VMware. To get this information, the attacker the VMXh-Magic-Value (0x0a). The second part of the communication is dedicated to the orders and the exfiltration. This part is similar to the previous samples: raw sockets usage.

The features of the malware are the same as previously with new capabilities such as file creation and removal.

The author removed the malware cleaning feature and implements two others features: the developer adds PostThreadMessageW() to send message inside the thread and in the previous version the developer used TerminalProcess() API to stop the process executed via the named pipes, in the version the developer append the "exit\r\b" string to the executed command in order to exit properly:

Another interesting change is the fact they don't use CHCP command anymore to force the charset but use code page. You can see in the screenshot 0x4E3 (1251 - Cyrillic Russian) and 0x362 (866 - DOS Cyrillic Russian):

Sha256: 43606116e03672d5c2bca7d072caa573d3fc2463795427d6f5abfa25403bd280
C2 for the orders: dnsdns1[.]PassAs[.]us
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp

2011 October: oops where is my cleaning function?

In October 2011, the attacker re-implements the cleaning function.

In this implementation, the developer first uses the Windows service management API in order to remove the service (instead of removing directly the registry key as he did previously) and, finally, remove the file with the same API as previously (MoveFileExA()).

Sha256:43459f5117bee7b49f2cee7ce934471e01fb2aa2856f230943460e14e19183a6
C2 for the orders: jennifer998[.]lookin[.]at
C2 for rollback: 196[.]44[.]49[.]154
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp

2011 December: Not a service anymore

The new variant from December 2011 is not a service anymore but a simple library (.dll). The library is executed via a launcher (conime.exe) and the persistence mechanism is not a service anymore but a registry key (CurrentVersion\\Run\\task).

The malware is lighter than the previous version but includes more espionage features such as file exfiltration, file listing, driver listing, process-killing, file removing. The other features are the same as previously.

It is interesting to note that the obfuscated reconnaissance is still hard-coded in the binary but it is not used anymore. The code used for the reconnaissance was removed but the developer forgot the IP variable.

Sha256: 915ad316cfd48755a9e429dd5aacbee266aca9c454e9cf9507c81b30cc4222e5
C2 for the orders: v3net[.]rr[.]nu
C2 for rollback: faceto[.]UglyAs[.]com
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/mh/o.asp

Hardcoded identifiers

In this version, we identify hard coded identifiers. We assume these IDs are campaign or target ID. Here is a list of IDs:

• 1031
• jp0201
• jp-serv
• mhi
• m1213
• classnk
• 95mhi
• nscsvc

In the next version, a campaign ID will be also used. The ID we believe is in reference to Japan targets. We believe these targets to sit within both the public and private sectors and they are specifically targeted to further enhance the attacker's capabilities through espionage.

2012: File format year

February: Let's hide my code in an almost legit library

In February 2012, the developer tried to hide the malicious code in the middle of a legit library. The malicious library was named msacm32.dll and contains the same exports as a legit library from Microsoft Windows named msacm.dll. Here is the export of the malicious library with the same name than the real one:

As previously the hard-coded C2 for reconnaissance variable is here. Without being used.

Sha256: 6f8bbea18965b21dc8b9163a5d5205e2c5e84d6a4f8629b06abe73b11a809cca
C2 for the orders: since[.]qpoe[.]com
C2 for rollback: applejp[.]myfw[.]us
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp

2012 May & December: l miss services

In May and December 2012, the developers modified the .dll to come back to a Windows service.

As previously described, the hardcoded C2 for reconnaissance variable is here. Without being used.

Sha256: b75c986cf63e0b5c201da228675da4eff53c701746853dfba6747bd287bdbb1d
C2 for the orders: since[.]qpoe[.]com
C2 for rollback: 69[.]197[.]149[.]98
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp

Sha256: 979d4e6665ddd4c515f916ad9e9efd9eca7550290507848c52cf824dfbd72a7e
C2 for the orders: usababa[.]myfw[.]us
C2 for rollback: indbaba[.]myfw[.]us
C2 URL for reconnaissance: hxxp://indbabababa[.]dns94[.]com/o.asp

2012 October: Standalone PE

In October 2012, the attackers used an .exe. The attacker chose a standalone PE.

As previously the hard coded C2 for reconnaissance variable is here. without being used.

Sha256: 6f4a1b423c3936969717b1cfb25437ae8d779c095f158e3fded94aba6b6171ad
C2 for the orders: mycount[.]MrsLove[.]com
C2 for rollback: mycount[.]MrsLove[.]com
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp

2013: RIP

We did not identify any Bisonal samples used in 2013. The first explanation could be that it was used so much that it stays under our radar. The second explanation could be a publication from Trend Micro on January 3, 2013. In the publication, the editor described a campaign where Bisonal was used. Maybe the actor decided to stop using Bisonal?

2014: The rebirth

Packer

For the first time, the Bisonal developers decided to use a packer: MPRESS. The Bisonal string also disappears from the binary however the workflow of the malware stays the same and some features are copy/pasted from the previous Bisonal variant.

Obfuscation

The domain and the port number are obfuscated but it is not a simple XOR anymore. The developers implemented its own byte manipulation algorithm. The developer also implemented an obfuscation concerning OS detection. The OS version string is not stored as a string anymore but as bytes:

It is interesting to note that a few samples from 2014 do not use the obfuscation described above.

Malware core

The developer rewrote a large part of the code however the workflow is the same as previously and some features are copy/paste. The binary is compiled with the MFC framework.

The biggest change is the network communication with the C2 server. The malware does not use a raw socket anymore but all the communications are performed with WinInet. The malware performs connection to the C2 server by using InternetOpenA() with an hardcoded User-Agent: "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322". Note the missing parenthesis at the end of the User-Agent. This typo will be there till today.

This variant has exactly the same features as the previous variant: file listing, OS version getting, process killing, drive listing, execution via ShellExecuteW(), execution via named pipe, cleaning, file removal, file downloading.

Here is an example of code similarities on the execution via named pipe function. On the left a sample from Bisonal 2014 and on the right Bisonal 2011. The code is not exactly the same but the workflow and some constants are similar.

Hard-coded Identifiers & URL pattern

In this new version, we identify three hard-coded identifiers:

• Campaign ID: an ID put in the exfiltrated data with the hostname and the OS version. We assume this ID is used to identify the campaign and the target by the operator;
• Malware ID: used to generate the first "word" of the URL. We assume this ID is used to identify the malware version (from a network protocol point of view);
• Third ID: used to generate the end "word" of the URL. It generally looks like a file name.

The URL pattern is the following: hxxp://C2_domain:PORT/MalwareIDVictimIPThirdID

SHA256: c6baef8fe63e673f1bd509a0f695c3b5b02ff7cfe897900e7167ebab66f304ca
C2 URL: hxxp://www[.]hosting[.]tempors[.]com:443/av9d0.0.0.0akspbv.txt

2016: More packers

In 2016, the developer implemented a new way of packing Bisonal. An initial static analysis immediately shows an executable with very little information. IDA Pro only shows five functions and almost no imports.


Looking at the few functions available it becomes clear the packer uses several anti-analysis tricks. In the unpacking stage, the malware has a lot of useless jumps and calls which makes the code tracking in the debugger harder.

After the unpacking is done the malware continued to use several anti-analysis measures. There are almost no direct calls to functions. It is common during the unpacking process to find useless code, like sequences of one instruction followed by a jump or increments in register values almost immediately followed by decrements. The initial unpacking is based on the manipulation of the return addresses pushed in the stack and the ordering of the data within the .text section. A second stage will allocate memory and unpack code into it, which finally will unpack code into a section that is originally empty called .textbss. This is where the core of the malware will be.

All API calls are made through a dispatcher function. Which is not called directly either, before this function is called it goes through a series of jumps and the stack is filled with encoded offset values.

The call of the jump table entry:

Push parameter for dispatch function into the stack:

Push all general-purpose registers into the stack:

Before calling the actual dispatch function, all registers are saved to the stack, by doing this the offset value is no longer on the top of the stack so the malware needs to put it back on the top of the stack.

At this time and just before the argument in the stack we also have the return address, inside the core of the malware. The dispatcher function will push the desired API function address into the stack. Afterward, it will do the same for the general-purpose registers.

After calling the dispatcher function the malware will first restore the generic purpose registers from the stack, thus leaving the API function address at the top of the stack. Logically, after the ret instruction is executed the code will jump into the API function.

This mechanism allows the malware to execute API functions without ever using the Call instruction, making it difficult to perform the analysis. The other side effect is that even after the code is unpacked if the analyst tries to dump it and analyze it statically, it will be hard for the disassembler to understand the code.

The dispatcher function has other tricks up its sleeve. Every time it is called it will use the anti-debug GetTickCount() to check if it is being debugged. If there is a discrepancy in the timing it will terminate the process. The termination can be as simple as a call to ExitProcess(), or it will first resume a thread that will display a message to the user. So that it ensures the thread has a chance to run, it will return the API call sleep() no matter what was originally requested. Once sleep() is executed, the error message thread will have a chance to be executed and will terminate the process.

From the functionality point of view, there aren't many differences between the 2014 versions. Always using three hard-coded identifiers mentioned previously but with different values.

SHA256: 15d5c84db1fc7e13c03ff1c103f652fbced5d1831c4d98aad8694c08817044cc
C2 URL: hxxp://emsit[.]serveirc[.]com/ks8d0.0.0.0akspbu.txt

2018: I miss you

During 2018, the attackers used a mix of samples using the MFC framework or the Visual C libraries. The registry key used for the persistence is now named "mismyou".

In September 2018, the developer made a mistake. Normally on this variant of Bisonal the domain names are encoded. However, the developer forgot to obfuscate the strings and put them in clear text into the variables but the deobfuscation function is still executed:



The mistake has for effect to destroy the domain and generate garbage strings. The malware will try to perfect connection to this bad domain (hxxp://硟满v鐿緲赥e ?r雀溝1kdi簽:70/ks8d0.0.0.0akspbu.txt). You can see here a screenshot of the debugger trying to perform a connect on it:

SHA256: 92be1bc11d7403a5e9ad029ef48de36bcff9c6a069eb44b88b12f1efc773c504
C2: kted56erhg[.]dynssl[.]com

SHA256: d83fbe8a15d318b64b4e7713a32912f8cbc7efbfae84449916a0cbc5682a7516
C2 fail: hxxp://硟满v鐿緲赥e ?r雀溝1kdi簽:70/ks8d0.0.0.0akspbu.txt

2019 - Office Extension and a new packer

Packer

Static analysis of this executable shows only two functions, but a regular number of imports. This time the packer shares some of the characteristics from the advanced one used in 2016.

There is a lot of useless code, including jumps and bswap operations. Upon detecting a debugger attached to it, the malware will display the message below and terminate the execution.

This message translates to "The debugger was found to be running in your operating system. This turns it off before running the program again!".

This packer also hides the calls to API functions. This time instead of using a dispatcher function, the malware pushes the arguments into the stack as usual but will then perform a call to a jump table built during the unpacking, in the .text section memory region.

Even though a call is made, these are not functions, in fact, most of the code in this jump table is useless except for the last instruction of each entry. Each entry finishes with a jmp instruction into the respective API function. Effectively the malware doesn't do any call to API functions, it always performs a jump. The return address is loaded into the stack when the malware does a call to the jump table. The end result is the same has in the packer from 2016, but with a simpler mechanism.

The majority of the code was moved into a packed area. The malware configuration (such as C2 server and the User-Agent) is outside that area. The packer uses a thread-local storage (TLS) callback to unpack some of the code. At this stage, it uses in-place unpacking avoiding memory allocations. One of the anti-analysis features included in this packer is the lack of calls to API functions. In the early stages of execution, the malware loads the libraries and retrieves the addresses from functions it needs.

Feature-wise, there is no change when compared with the 2016 version, in fact when compared the C2 beaconing functions even share some of the offsets.

Office Extension

In 2019, the actor behind Bisonal used a new way to deploy the machine on the target's systems. They sent a malicious RTF document to the targets with an exploit targeting the CVE-2018-0798 (Microsoft's Equation Editor vulnerability). The purpose of the shellcode was not to execute the malware (as it is usual) but simply to drop it in the %APPDATA%\microsoft\word\startup\ repository with the .wll extension.

The libraries in this directory with this specific extension will be loaded as a Microsoft Office extension. So next time the user opens an Office application, the malware will be loaded and executed. The purpose of the malware is to deploy Bisonal on the infected system ($tmp$\tmplogon.exe) and to create a Run registry key in order to execute Bisonal at the next reboot of the system.

We think the purpose of this multistage execution is an anti sandbox technique. If you look at the report after executing the malicious document, you only see one action: the .wll file creation. The user also needs to open an Office application and finally a reboot is needed in order to execute the real payload: Bisonal.

Bigger is better

We identified a version of Bisonal using Office extension with a really specific behavior during the installation of the malicious payload. The dropper appends 80MB of binary data at the end of the Bisonal binary:

The binary value is "56MM" is ASCII characters. If we look at the malware, we can see the appended data:

We are not sure of the purpose of the creation of a huge binary. It could be an anti-analysis technique. Some tools limit the size of the analyzed files. For example, by using the VirusTotal standard API, we cannot upload files bigger than 32MB. We also identified sandboxes that cannot handle big files correctly. Remember, size matters.

Malware code

The developer partially refactored the code. The variant from 2019 keeps exactly the same features. The two main changes are the obfuscation and the network protocol to communicate to the C2 server.

The developers used two different obfuscation algorithms: one for the C2 encoding and one for the data. The C2 encoding is a simple XOR (as in 2012):

The C2 encoding communication is also different. As the data are now sent with the GET method, the data must be in ASCII. That's they add base64 encoding in order to get supported characters in the HTTP query.

For the first time, the developer switched from POST requests to GET requests:

The exfiltrated data is appended to the URL. Here is the pattern: hxxp://C2_domain/MalwareIDVictimIPThirdIDExfiltratedDataBase64

SHA256:37d1bd82527d50df3246f12b931c69c2b9e978b593a64e89d16bfe0eb54645b0
C2 URL:hxxp://www[.]amanser951[.]otzo[.]com/uiho0.0.0.0edrftg.txt

Bisonal timelines summary

Conclusion

The actor behind Bisonal is clearly motivated and has an interest in Russian, Korean and Japanese victims. The development of Bisonal has been active for more than a decade. We have observed the code evolving with the different publications but also with the evolution of Microsoft Windows.

However, specific functions are still used today, many years after the original implementation of the Bional malware. Even if Bisonal could be considered as simple with less than 30 functions, it has spent its life targeting sensitive entities in both the public and private sectors. Some campaigns were even mentioned on mainstream media against military entities within the mentioned regions.

During the decade of activities, we also can see mistakes and rollbacks from the attackers. For example, in one campaign they put the domain name of the C2 server in plaintext in the malware which had the function to generate a non-ASCII string for the C2 servers once decoded. In this condition, the malware cannot work on the compromised system. Even after so many years of activities, the attackers make mistakes.

We don't see any reason why this actor will stop in the near future. With this investigation and the analysis of this decade of activity, we hope to force this actor to innovate by providing a better understanding of his arsenal and more specifically how Bisonal works.

Coverage

Ways our customers can detect and block this threat are listed below.


Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors. Exploit Prevention present within AMP is designed to protect customers from unknown attacks such as this automatically.

Cisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.

Email Security can block malicious emails sent by threat actors as part of their campaign.

Network Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), Cisco ISR, and Meraki MX can detect malicious activity associated with this threat.

AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.

Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.

Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

IOCs

SHA256:

0cf9d9e01184d22d54a3f9b6ef6c290105eaa32c7063355ca477d94b130976af
7dc58ff4389301a6eccc37098682742b96e5171d908acdeb62aeaa787496c80a
0ff88a6cd7dcd27f14ebb7b2c97727b81e1aa701280d1164685c52c234e4a9df
8252f2cdedf16f404d43c81d005ea8ebb10594477f738e40efacf9013e1470d2
915ad316cfd48755a9e429dd5aacbee266aca9c454e9cf9507c81b30cc4222e5
1128d10347dd602ecd3228faa389add11415bf6936e2328101311264547afa75
92be1bc11d7403a5e9ad029ef48de36bcff9c6a069eb44b88b12f1efc773c504
15d5c84db1fc7e13c03ff1c103f652fbced5d1831c4d98aad8694c08817044cc
9638e7bb963ac881bd81071d305dea91b040536c55b7ee79b526b8afcfad6972
1e66579b856cd331518d67c351bcb2b102399d8ade53370797228b289e905dc1
979d4e6665ddd4c515f916ad9e9efd9eca7550290507848c52cf824dfbd72a7e
22b3a86f91d2eb5a8a1e1cdc044bcf6aca898663071be5233bac00c0f0d3c001
9c86c2dd001c47b933c6b5f43c8f87a6d0c01c066e3520e651fab51d19355d3c
2c1e0facf563bb2054d9a883144ef9bad77ba75cdb46cc80843821c363c0a9dc
a4a5c60a392d236b76907f58597e83ba9c9d4cfc6a4502ef3e0e149b8710a0c6
359835c4a9dbe2d95e483464659744409e877cb6f5d791daa33fd601a01376fc
b1da7e1963dc09c325ba3ea2442a54afea02929ec26477a1b120ae44368082f8
37d1bd82527d50df3246f12b931c69c2b9e978b593a64e89d16bfe0eb54645b0
b75c986cf63e0b5c201da228675da4eff53c701746853dfba6747bd287bdbb1d
43459f5117bee7b49f2cee7ce934471e01fb2aa2856f230943460e14e19183a6
b85e4168972b28758984f919aef2ce0fde271ee1f0863510e521a2920fcc658e
43606116e03672d5c2bca7d072caa573d3fc2463795427d6f5abfa25403bd280
bd1a9b148580dad430683639b747d1c49932db5d8f6eb2d90e2583af976810dc
436fc9530015c2d2b952a16d2a3dfa202d1cb1c577b580811b9b48355855591b
c5496dc3fa96b657ab4467c551877bbced56fd07c00c7ccb199c1794235bf710
444e864a3bb2abb1edccab4a5cd45bc0039f2a48e01615b2719da65a40a5140e
c6baef8fe63e673f1bd509a0f695c3b5b02ff7cfe897900e7167ebab66f304ca
cdba1a69d75f3e2256dccc16255aef07ded41c257b2cc95ccb801a0063445926
5caada5737b0a6c8c8f8a27bfcd0fb2221af68a4856278c3919b37279daa7409
d19b85891dd0f83808b70fbe68a56a64e828611dfe53d04a6c1c211f1352b5b5
6676934d7f214cb256407400357c1f7ead69a523b3017f6a5bc30d06a11a8305
d7692a71b85c869ee11647b80ea6d42b2e4303233c525a8fa7e6bec3599e2c8b
67e286c7308dda5cd8fe4a1340f354927e5791ce6ef0ef02c93a4e063e11c4ad
d83fbe8a15d318b64b4e7713a32912f8cbc7efbfae84449916a0cbc5682a7516
6c714653a8fa54eef1de2f0148e5e8cf514907f6f523bf09c8ee126bebcdbdcc
dd88b31275b7079899d945fc6de2dceaf7e8fc143ef24be5bb336585ddf6af1e
6cc4707942f9323347c95066a43b30f874f1b1c783960cf8ed9ecf5914f85ba7
eb7681c653ef1942103cd3272fd124eaf73e79bb830be978535c18b73c87b985
6ef4df8460ba57b836f52a9a73e2d739a3f2aa832bec6b663af53b55dc74a63d
effd31b11bdc6486082967c2d8e53d979e59a88ba28e68a1c94f5a064a8a966d
6f4a1b423c3936969717b1cfb25437ae8d779c095f158e3fded94aba6b6171ad
6f8bbea18965b21dc8b9163a5d5205e2c5e84d6a4f8629b06abe73b11a809cca
f3a30e5f8bfd0f936597bcef7cb43df11ec566467001dff9365771900e90acb1
77a36530555eada268238050996839bd34670e8bfda477c30d9dd66574625f59
f9302b7ecc32b891edeaf61353dc5e976832b7104ec0d36f1641f1f40cf6fe12
799d858ff77c29684fc1522804ed45c24171484d9618211c817df01424bc981a
23d263b6f55ac81f64c3c3cf628dd169d745e0f2b264581305f2f46efc879587
72f6a54d0d09a16e6fde9800aa845cd1866001538afb2c8f61f3606f5e13f35a
4bad5898373eb644662a8c1d5d5c674e2558908e34bb2fd915f3350b0f28752b

C2 servers:

0906[.]toh[.]info
dnsdns1[.]PassAs[.]us
euiro8966[.]organiccrap[.]com
jennifer998[.]lookin[.]at
kfsinfo[.]ByInter[.]net
kted56erhg[.]dynssl[.]com
mycount[.]MrsLove[.]com
since[.]qpoe[.]com
usababa[.]myfw[.]us
v3net[.]rr[.]nu
www[.]amanser951[.]otzo[.]com
www[.]amanser951.otzo[.]com
137[.]170[.]185[.]211
196[.]44[.]49[.]154
21kmg[.]my-homeip[.]net
61[.]90[.]202[.]197
61[.]90[.]202[.]198
69[.]197[.]149[.]98
agent[.]my-homeip[.]net
applejp[.]myfw[.]us
dnsdns1[.]PassAs[.]us
emsit[.]serveirc[.]com
etude[.]servemp3[.]com
euiro8966[.]organiccrap[.]com
faceto[.]UglyAs[.]com
games[.]my-homeip[.]com
hansun[.]serveblog[.]net
hxxp://硟满v鐿緲赥e ?r雀溝1kdi簽:70/ks8d0.0.0.0akspbu.txt
indbaba[.]myfw[.]us
kazama[.]myfw[.]us
kreng[.]bounceme[.]net
kted56erhg[.]dynssl[.]com
mycount[.]MrsLove[.]com
navego[.]serveblog[.]net
shinkhek[.]myfw[.]us
wew[.]mymom[.]info
www[.]hosting[.]tempors[.]com
www[.]nayana[.]adultdns[.]net
www[.]dds.walshdavis[.]com