TwoFace Webshell: Persistent Access Point for Lateral Movement

While investigating a recent security incident, Unit 42 found a webshell that we believe was used by the threat actor to remotely access the network of a targeted Middle Eastern organization. The construction of the webshell was interesting by itself, as it was actually two separate webshells: an initial webshell that was responsible for saving and loading the second fully functional webshell. It is this second webshell that enabled the threat actor to run a variety of commands on the compromised server. Due to these two layers, we use the name TwoFace to track this webshell.

During our analysis, we extracted the commands executed by the TwoFace webshell from the server logs on the compromised server. Our analysis shows that the commands issued by the threat actor date back to June 2016; this suggests that the actor had access to this shell for almost an entire year. The commands issued show the actor was interested in gathering credentials from the compromised server using the Mimikatz tool. We also saw the attacker using the TwoFace webshell to move laterally through the network by copying itself and other webshells to other servers.

Actor Activities using TwoFace

The web server logs on the system we examined that was compromised with the TwoFace shell gave us a glimpse into the commands the actor executed through their malware. These commands also enabled us to create a profile of the actor, specifically their intentions and the tools and techniques used to carry out their operation.

Our analysis determined that five different IP addresses from four countries issued commands on the TwoFace shell, as seen in Table 1. As it is possible these originating IP address may themselves have been targeted and compromised, we have redacted the full IP addresses to hide the identities. The first command in the logs was issued on June 18, 2016, which was a simple “whoami” command to get the username on the server. This single command was the only one by this specific IP address which appears to be in Iran, and suggests that the actor may have initially compromised the server around this time and performed a quick check to see if the shell was loaded successfully.

IP address Country Number of Commands Date of Activity Days Since Initial Command
46.38.x.x Iran 1 2016-06-18 0
178.32.x.x France 6 2016-09-28 103
137.74.x.x France 16 2017-03-03 259
192.155.x.x USA 61 2017-04-24 311
46.4.x.x Germany 10 2017-05-03 320

Table 1 IP Addresses seen issuing TwoFace Commands

Three months after this single, initial command the next set of commands were sent. This time on September 28, 2016 a series of twelve commands were sent from an IP address apparently in France. These commands provide additional insight into the actor’s intentions. It is not certain why a time gap exists in issuing commands to the TwoFace webshell, although it is highly plausible this may simply be a visibility gap or even anti-detection measure taken by the actor. Rather than speculating on this gap and subsequent time gaps between interactions, we will focus on the commands actor issued that provide insight into this actor’s tactics, techniques, and procedures (TTPs).

The first command issued from this second IP address attempts to run a variant of the Mimikatz post-exploitation tool (m64.exe), specifically the Sekurlsa module that gathers the passwords of accounts currently logged into the system and saves the results locally to a text file. The actor then issues a command that uses the “type” command to read the contents of the text file containing the passwords, followed by a command that uses “del” to delete the text file.

c:\windows\temp\m64.exe privilege::debug sekurlsa::logonpasswords exit > c:\windows\temp\01.txt

Just over five months later on March 3, 2017, a third IP address, a different one apparently in France, issued a series of 16 commands to the TwoFace webshell. The first command of interest is as follows:

net group "Exchange Trusted Subsystem" /domain

According to MSDN, the “Exchange Trusted Subsystem” group is defined as follows:

The “Exchange Trusted Subsystem” is a highly privileged universal security group (USG) that has read/write access to every Exchange-related object in the Exchange organization. It’s also a member of the Administrators local security group and the Exchange Windows Permissions USG, which enables Exchange to create and manage Active Directory objects.

Using hostnames obtained from the previous command, the actor issues several commands to determine if they have access to Microsoft Exchange related folders. The actor then issued several commands that attempt to copy a different webshell onto these additional systems, which resembles the following:

copy c:\windows\temp\Exchange.aspx "\\[hostname]\d$\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews\"

This clearly shows the threat actor attempting to use the TwoFace webshell to pivot to other servers on the network. The “Exchange.aspx” file copied over to the other systems appears to be a different webshell from TwoFace. We analyzed this additional webshell and have named it IntrudingDivisor, which we will describe in detail later in this blog.

On April 24, 2017, a fourth IP address, this one apparently in the United States, issued 61 commands to the TwoFace webshell. Like the previous set of commands issued in March 2017 from France, this IP address issued the command to obtain objects in the Exchange Trusted Subsystem group, and it appears the actor copied over yet another webshell named “global.aspx” and set the file’s attributes to be hidden using the following command:

attrib h "\\[hostname]\d$\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews\global.aspx"

The actor then issued commands that suggests the use of the Mimikatz tool, but this time Mimikatz was named “mom64.exe” instead of “m64.exe”. The following two commands show the actor killing the process and using the “type” command to read the contents of a text file “01.txt,” which was also used in the password gathering activity observed on the day of the initial compromise on Jun 2016, ten months earlier:

taskkill /f /im mom64.exe
type c:\windows\temp\01.txt

Nine days later on May 3, 2017 the next commands came from a fifth IP address apparently in Germany. This time the threat actors issued 10 commands to the TwoFace webshell: fewer than nine days before but still more than during the other sessions.

The actor first issues a command to ping the IP address “4.2.2.4”, which is the legitimate DNS resolver operated by Level 3. The actor then checks the “Domain Admins” group to determine the accounts with domain administrator privileges using the following command:

net group "Domain admins" /domain

After this command, the actor runs a variant of the Mimikatz tool to gather locally logged in passwords, this time using a filename of “MicrosoftUpdate.exe” for the executable and “mic.txt” to store the results, as seen in the following command:

c:\windows\temp\MicrosoftUpdate.exe p::d s::l q > c:\windows\temp\mic.txt

These commands show the threat actors rely heavily on the TwoFace webshell to interact with compromised servers, but it also appears that other webshells are used in addition to TwoFace, such as IntrudingDivisor. The commands also show the threat actor’s reliance on the Mimikatz tool to steal passwords from systems, which they will then use to attempt to move laterally amongst other servers by copying over webshells. Lastly, the timestamps of the commands suggest that the threat actor had maintained persistent access that they used intermittently to the compromised network using the TwoFace shell since at least June 2016.

TwoFace Loader Shell

Both components of the TwoFace shell, which we will refer to as the loader and payload components were written in C# and meant to run on a webserver that supports ASP.NET. The author of the initial loader webshell included legitimate and expected content that will be displayed if a visitor accesses the shell in a browser. The inclusion of expected content suggests that the actors wished to use the TwoFace webshell for extended periods while remaining hidden.

The code in the loader webshell includes obfuscated variable names and the embedded payload is encoded and encrypted. To interact with the loader webshell, the threat actor uses HTTP POST requests to the compromised server. As its name suggests, the loader component is mainly responsible for saving and loading the payload component on the same server, allowing the actor to interact with the payload component that has far more functionality than the loader. However, the loader is also capable of the following functionality:

  • Save the TwoFace payload to a specified file on the server
  • Delete the TwoFace payload saved on the server
  • Write data to a specified file on the server
  • Delete the entire folder on the server used to store the TwoFace payload

The TwoFace loader parses the HTTP POST requests issued by the actor and references data at specific locations, more specifically at certain indexes within the posted data (C# “Request.Forms”) that the shell will use to determine the functionality the actor wishes to execute. While we did not have logs of HTTP requests for the loader shell, we were able to determine some of the indexes that the webshell will specifically access within the data. Table 2 shows the known indexes within the HTTP POST data that TwoFace references.

Request.Forms Index Description
0 If set to a specific value (for example, "931201"), it creates a set of "pre" html tags with a string of numbers for reasons unknown.
5 Data to write to a file on the server
8 String name for the TwoFace webshell filename
9 Contains base64 data provided by the actor to specify the command to run, as well as the decryption key in the event the actor wishes to load the webshell

Table 2 Indexes within Request.Forms that the TwoFace loader relies on

As you can see in the descriptions in Table 2, none of these locations contain the command that the actor wishes to execute. Instead, the actor must provide data in index 9 that was constructed to not only contain the command the actor wants to execute, but also contains the key to decrypt the TwoFace payload component that is embedded within the loader. The data in index 9 will contain data at specific offsets, seen in Table 3 that the loader component will use to determine the command and the location of command specific data within the posted data (C# “Request.Forms”).

Offset Value Description
0 Varied The entirety of the data is used as a key to decrypt the TwoFace payload component
25 8 Specifies the argument in the HTTP POST request that contains the string of the filename for the TwoFace webshell file
26 1000 Minimum length required to write data to a specified file
44 31 Contains the number of arguments needed to perform a file deletion operation?
45 5 Specifies the argument within the POST request that contains the data to write to a file on the server
57 36 Contains the number of arguments within the POST request to run a command to write data to a file on the server
61 13 Contains the number of arguments within the POST request to run a command to install the TwoFace payload webshell
63 14 Contains the number of arguments needed to perform a folder deletion operation?

Table 3 Offets of actor provided data used by the TwoFace loader

Saving the TwoFace Payload

The main purpose of the loader shell is to install a secondary webshell on demand. The secondary webshell, which we call the payload, is embedded within the loader in encrypted form and contains additional functionality that we will discuss in further detail. When the threat actor wants to interact with the remote server, they provide data that the loader will use to modify a decryption key embedded within the loader that will be in turn used to decrypt the embedded TwoFace payload. The decryption algorithm (below) is very simple, as it relies on basic arithmetic operations, specifically addition and subtraction to decrypt the embedded payload.

The pseudocode above provides the logic used by the TwoFace loader to decrypt the ciphertext of the payload, which is

  1. Iterate through the key, modifying each byte by adding a value from the actor’s provided data
  2. Iterate through TwoFace payload ciphertext and subtracting each byte using a value from the modified key

We were able to determine the data that the threat actor would have to provide to successfully decrypt the embedded TwoFace payload, which is as follows:

\x15@^\xbbs\xfa\xae\x876\x03`\xffs\x89\xb9 \x9a\xcb\x02\xec\x8e\xc3\x92\x7f\xd6b\xa8\x1ag\xb8\xff\x82\x08\xd0ALB\xd8\x0c)\x91\x82\xc4\x85\xb2\xa7\xe6\xea\x8e\x92\xf9u\x96\xc1\xef\xfd\xe9.!\x047\xc8#y

As you can surmise from the above characters, this does not appear to be a human generated string. We believe this is a machine generated string used for this input data, which gives a bit of insight into the actors behind this webshell, as they would have to use a tool to interact with to automate the use of these webshells, or at a minimum they would need to keep track of these machine generated user input strings to be able to interact with their webshells manually.

TwoFace Payload Shell

The TwoFace payload shell requires a password that is sent within HTTP POST data or within the HTTP Cookie, specifically with a field with a name “pwd”. The “pwd” field is used for authentication as a password, which the payload will generate the SHA1 hash and compare it with a hash that is hardcoded within the payload. We extracted the SHA1 hashes used for authentication from the known TwoFace shells, as seen in Table 4 and were able to find the associated password string for three of them. One of the passwords, “RamdanAlKarim12” contains a phrase that means “Ramadan the generous” in Arabic (رمضان الكريم). Another known password is “FreeMe!”, while the last known password contains what may be an acronym of a middle eastern energy organization followed by “pass”. It is possible that the actor chose this acronym based on the targeted organization, but we cannot confirm this.

Sample SHA256 Embedded SHA1 Password
8f0419493d… a2c9afd6adac242827adb00d76c20c491b2d2247
0a77e28e6d… 6a0e681586988388d4a0690b6fb686715d92d069
54c8bfa0be… 5e1c37bf3bd8a7567d46db63ed9b0aeed53e57fe
818ac924fd… 37ada887553cf48715cc19131b8e661ac43718e9
fd47825d75… 9789b5c0c13fb58c423bce5577873d413d9494be
79c9a2a2b5… c56bc0d331a825fdea01c5437877d5e9e1cda2c4
e33096ab3… 9f4e10484f4ceac34878d4f621a1ad8e580fd02a
c116f078a0… 57dd9721f9837ebd24dea55a90a2a9e3e6ad6f1e

Table 4 Authentication hashes and matching password strings used for TwoFace webshells

Much like the authentication password, a threat actor can issue commands to the TwoFace payload using either data sent within the HTTP Cookie or HTTP POST data itself. If using an HTTP Cookie to issue commands, the payload will split the cookie data using the delimiter “#=#” and will treat the first value as the command and the second value the data to pass to the command. We enumerated the command handler, which can be seen in Table 5 that accepts a variety of commands to interact with the compromised server.

Command Arg Field Description
Execute application or command pro Executable to run command line commands
cmd Runs a supplied command using “cmd.exe” or another executable supplied by the user via the “pro” field within the HTTP POST data.
Upload a file to the server upl Field name within the HTTP POST files that contains the file contents to save to the server
sav Path to save file to
vir Boolean to save a file to a virtual path rather than a physical path
nen Specified name of file to upload, otherwise the script uses the filename of the uploaded file from the HTTP POST request
Upload data to a file in the %TEMP% folder upb Base64 encoded data that is decoded and saved to a file
upd Filename in the %TEMP% folder to save ‘upb’ data to
Delete a file in %TEMP% folder del Filename in the %TEMP% folder to delete
Download a file from the server don Path to file to download from the server
View or set MAC timestamps of a file hid 1 = View the ‘tfil’ MAC times

2 = Set ‘tfil’ file MAC times to match the file specified in the ‘ttar’ field

3 = Set ‘tfil’ file MAC times to times specified in the ‘ttim’ field

tfil Filename to get or set MAC times
ttar Filename to get MAC times, most likely a legitimate filename used to make uploaded files look as if they are legitimate
ttim Specific timestamp to set file MAC times to

Table 5 Commands available within the TwoFace payload webshell

While the commands within Table 5 are available within TwoFace, the threat actor does not have to manually issue these requests within HTTP POST data, as the actor can interact with the webshell using a web form within the browser. We set up an IIS server to test the TwoFace webshell, which displays the user-interface seen in Figure 1.

twoface_1

Figure 1 TwoFace payload webshell before authentication

At first, the text box in the row labeled “Login” has a red background, which means the user has not successfully provided the password required to issue commands to the webshell. After entering the correct password in the login box, the box changes from a red to green background, as seen in Figure 2. The actor can now interact with the compromised server using the webshell, which runs the commands described in Table 5. In most cases, the output or results of commands are displayed immediately below the webshell. For instance, in Figure 2 we issued the “whoami” command that used the Windows command-prompt to display the name of the current user account below the webshell.

twoface_2

Figure 2 Issuing a command on TwoFace webshell after successfully authenticating

TwoFace++ Loader

We discovered another version of the TwoFace loader shell that was structurally similar to the TwoFace loader shell discussed in this blog, as this version of TwoFace also contains an embedded payload shell in encrypted form. To use the embedded payload shell, the actor must provide a password that the loader shell will not only use for authentication, but also as a key to decrypt the payload.

The actor will provide the password in the HTTP POST data, specifically as a base64 encoded string within a field labeled “p”. The TwoFace++ loader will decode this password and concatenate a static salt value and compute the SHA1 hash of this string. The loader then base64 encodes the SHA1 hash and compares it with a hardcoded base64 encoded string of a SHA1 hash needed for successful authentication. We know of the SHA1 hashes 19be2493b7cc2d43e8bf245b6faf2c747be6bae5 and 26749c6b5308bb668eb954f4120607c2a9d620be used for authentication, however, we have been unable to determine the passwords that would result in these hashes.

The TwoFace++ loader will use the actor provided password as a decryption key to decrypt the embedded payload shell. The loader will use the first 24 bytes of the actor’s password as a key, which it will use the 3DES symmetric cipher to decrypt the payload shell. The embedded payload is 8624 bytes, which we believe is another webshell based on the previous version of the TwoFace loader, however, we have been unable to decrypt the payload to confirm.

IntrudingDivisor Webshell

Our analysis of the commands issued to the TwoFace webshell resulted in the discovery of another webshell that we call IntrudingDivisor. Like TwoFace, the IntrudingDivisor webshell requires the threat actor to authenticate before issuing commands. To authenticate, the actor must provide two pieces of information, first an integer that is divisible by 5473 and a string whose MD5 hash is “9A26A0E7B88940DAA84FC4D5E6C61AD0”. Upon successful authentication, the webshell has a command handler that uses integers within the request to determine the command to execute, specifically integers divisible by the following:

Divisor Command
6571 Write provided data to a specified file
9273 Execute a command or change the modified and access times of a file
3471 Read a specified file

Table 6 Commands available within the IntrudingDivisor webshell

The webshell logs the IP, user-agent, and timestamp of all requests to a file named "KB45253-ENU.exe”, but we have seen another IntrudingDivisor sample logging requests to “KB76862-ENU.exe” as well. We believe the threat actor will use the IntrudingDivisor in a similar manner to TwoFace, specifically to gain access to additional servers during lateral movement and to gather user credentials.

Conclusion

The TwoFace webshell has an effective two-layer approach that makes it difficult to detect. Coupled with the multiple layers and inclusion of legitimate website content that displays correctly in the browser, the threat actors are able to enjoy long periods of persistent access to a network without detection as evidenced by their demonstrated ability to access and manipulate a compromised system for nearly a year. Based on the commands issued to TwoFace, the threat actors used this webshell to deliver variants of the Mimikatz tool to gather the passwords of logged on accounts. The actor also used TwoFace to move laterally by copying webshells to other remote systems on the network.

TwoFace Loader SHA256

ed684062f43d34834c4a87fdb68f4536568caf16c34a0ea451e6f25cf1532d51
f4da5cb72246434decb8cf676758da410f6ddc20196dfd484f513aa3b6bc4ac5
9a361019f6fbd4a246b96545868dcb7908c611934c41166b9aa93519504ac813
d0ffd613b1b285b15e2d6c038b0bd4951eb40eb802617cf6eb4f56cda4b023e3

TwoFace++ Loader SHA256

bca01f14fb3cb4cfbe7f240156feebc55abac73a6c96b9f75da2f9df580101ef
8d178b9730e09e35c071526bfb91ce72f876797ebc4e81f0bc05e7bb8ad1734e

TwoFace Payload SHA256

8f0419493da5ba201429503e53c9ccb8f8170ab73141bdc6ae6b9771512ad84b
0a77e28e6d0d7bd057167ca8a63da867397f1619a38d5c713027ebb22b784d4f
54c8bfa0be1d1419bf0770d49e937b284b52df212df19551576f73653a7d061f
818ac924fd8f7bc1b6062a8ef456226a47c4c59d2f9e38eda89fff463253942f
fd47825d75e3da3e43dc84f425178d6e834a900d6b2fd850ee1083dbb1e5b113
79c9a2a2b596f8270b32f30f3e03882b00b87102e65de00a325b64d30051da4e
e33096ab328949af19c290809819034d196445b8ed0406206e7418ec96f66b68
c116f078a0b9ea25c5fdb2e72914c3446c46f22d9f2b37c582600162ed711b69

IntrudingDivisor Shell SHA256

e342d6bf07de1257e82f4ea19e9f08c9e11a43d9ad576cd799782f6e968914b8
49f43f2caaea89bd3bb137f4228e543783ef265abbdc84e3743d93a7d30b0a7e

Mimikatz SHA256

f17272d146f4d46dda5dc2791836bfa783bdc09ca062f33447e4f3a26f26f4e0

OilRig Uses ISMDoor Variant; Possibly Linked to Greenbug Threat Group

Unit 42 has discovered activity involving threat actors responsible for the OilRig campaign with a potential link to a threat group known as GreenBug. Symantec first reported on this group back in January 2017, detailing their operations and using a custom information stealing Trojan called ISMDoor.

In July 2017, we observed an attack on a Middle Eastern technology organization that was also targeted by the OilRig campaign in August 2016. Initial inspection of this attack suggested this was again the OilRig campaign using their existing toolset, but further examination revealed not only new variants of the delivery document we named Clayslide, but also a different payload embedded inside it. In the past, we had primarily associated the OilRig campaign with using the Clayslide documents to deliver as a payload a Trojan we named Helminth; in this instance, the payload was instead a variant of the ISMDoor Trojan with significant modifications which we are now tracking as ISMAgent.

The Attack

On July 16, 2017, actors associated with the OilRig campaign sent emails to five different individuals within the targeted organization. All of the emails sent had the same subject, attachment filename, and attached Excel file (SHA256: 3eb14b6705179590f0476d3d3cbd71665e7c1935ecac3df7b876edc9bd7641b6).

We identified the Excel file attached to the delivery email as a variant of the Clayslide delivery documents used by the OilRig campaign. A closer look revealed that although it was similar to previous Clayslide documents, it was also quite different in several aspects. Like the previous samples, it displays a worksheet titled “Incompatible” containing a banner that shows a fake compatibility warning message (Figure 1). The message is an attempt to trick the user into clicking the “Enable Content” button, which would run a malicious macro embedded within the Excel file

OilRig_1

Figure 1 Incompatible message attempting to trick the victim into enabling macros

The macro within the delivery document will unhide and display a new worksheet that contains a fake invoice for Citrix products, as seen in Figure 2. This fake invoice acts as a decoy document to minimize the user’s suspicions that any malicious activity occurred.

OilRig_2

Figure 2 Decoy document opened to minimize suspicions of compromise

While the macro displays the decoy invoice spreadsheet, it silently runs malicious code in the background to install its payload. The malicious code starts by concatenating several base64 encoded strings into a single variable. As you can see in the following code snippet, the variable name “Paltofp1” suggests that the author of this code may want our attention:

The macro then writes the concatenated base64 encoded data to the file %PUBLIC%\Libraries\B642.txt. It then reads in the “B642.txt” file and decodes the data, which it will save to the file %PUBLIC%\Libraries\servicereset.exe (SHA256: 52366b9ab2eb1d77ca6719a40f4779eb302dca97a832bd447abf10512dc51ed9). The servicereset.exe file is the payload of this attack, which is a variant of ISMDoor that we track as ISMAgent.

The script then creates a file named %PUBLIC%\Libraries\OfficeServicesStatus.vbs which contains a VBScript that will execute the “servicereset.exe” file using the command line. Lastly, as a persistence mechanism, a scheduled task named “OfficeServicesStatus” will be created, set to run every three minutes, as seen in Figure 3.

OilRig_3

Figure 3 Scheduled task created by the macro within the delivery document

An Iterative Task

While hunting for other samples similar to the one observed in the attack against the technology organization, we discovered yet another variant of Clayslide (SHA256: 5ac939a5426db8614165bd8b6a02d3e8d9f167379c6ed28025bf3b37f1aea902). This sample was dated June 2017, a month older than the newest version containing ISMAgent. Based upon timestamping and similarities with both the original Clayslide documents as well as the newest ISMAgent loaded ones, we believe this June 2016 sample to be an iterative version of Clayslide.

The June 2017 sample of Clayslide contained the same OfficeServicesStatus.vbs file found in the ISMAgent Clayslide document, but instead of having the payload embedded in the macro as segregated base64 strings that would be concatenated, this variant obtained its payload from multiple cells within the “Incompatible” worksheet. This technique was observed in previous Clayslide documents to access the script variant of the Helminth Trojan in earlier OilRig attacks.

Also, the June 2017 sample contained artifacts observed in previous Clayslide documents as documented in a blog post we published in April. Specifically, we found this comment:

along with the following common function names within the macro code:

Although structurally the document was more similar to the originally discovered Clayslide documents, this June 2017 sample was designed to load ISMAgent instead of Helminth. We do not have targeting details for this sample, although the decoy document contained a similar theme to the newest Clayslide document, displaying vendor related information (Figure 4).

OilRig_4

Figure 4 Decoy document

A table displaying the differences in each variant of Clayslide is below:

Original Clayslide June Clayslide Newest Clayslide
Helminth X
ISMAgent X X
OfficeServicesStatus X X
Base64 in multiple cells X X
Source code comment X X

Table 1 Comparison of Clayslide versions

The payload (SHA256: 52366b9ab2eb1d77ca6719a40f4779eb302dca97a832bd447abf10512dc51ed9) delivered in the June 2016 attack is a variant of the recent ISMDoor versions that use DNS tunneling for its C2 communications. On May 1, 2017, Arbor Networks published research on ISMDoor using DNS tunneling to communicate with its C2 server, which is nearly identical to the DNS tunneling the payload of this attack carries out. Due to considerable differences and evidence of potentially different authors between the previous ISMDoor samples and this newly discovered variant, we are tracking this new variant as ISMAgent.

On-demand Configuration

The ISMAgent tool comes with a default configuration that specifies the C2 domain and the number of minutes between further attempts to execute the tool. However, an actor can use command line arguments to create a new ISMAgent sample that is configured with a specified C2 domain and a specified number of minutes to automatically execute the Trojan. The following command line arguments are supported:

Argument Description
-c Configures a second domain to use for C2 communications
-m Configures the number of minutes that a scheduled task should execute the payload

Table 2 Command line options available in ISMAgent for configuration

If the Trojan is executed with these arguments, the Trojan will read its own file data in, and search for two strings of characters within the data that it will overwrite with the configured settings. The Trojan searches for a string of "^" characters that it will overwrite with the C2 domain provided via the "-c" argument, and it searches for the string "%%%%" that it will replace with the number of minutes provided via the "-m" argument. The "%%%%" string exists within the following larger string, that the Trojan uses as a command to execute in order to create a scheduled task named "TimeUpdate" to execute the payload after the specified number of minutes passes:

Command and Control

The Trojan is able to use two mechanisms to communicate with its C2 server: HTTP requests and DNS tunneling. The DNS tunneling protocol found in this payload is remarkably similar to recent ISMDoor samples, as documented in Arbor Networks’ research. Similar message handling is found in both ISMAgent and ISMDoor, in addition to the existence of strings in both samples, such the hardcoded IPv6 values. The similarities may allow for backward compatibility between ISMAgent and ISMDoor C2 infrastructure. In the payloads themselves, a number of differences exist, enough that in essence they appear to be different tools.

Regardless of the communications method used, the Trojan will parse the received data from the C2 server for a GUID field that the Trojan will use as a unique identifier, as well as commands the Trojan should run on the compromised system:

HTTP C2 Communications

ISMAgent prioritizes HTTP as its mechanism to communicate with the C2 server, but if it is unable to reach the C2 server it will switch to the DNS tunneling mechanism. To carry out its HTTP C2 communications, the Trojan prepends "www." to the configured C2 domain and issues a DNS query to resolve this domain. The Trojan will use the resolved IP address as the host in the HTTP beacon request.

For instance, the sample used in this attack was configured to use ntpupdateserver[.]com for its C2 server. The HTTP C2 process would attempt to resolve the domain “www.ntpupdateserver[.]com”, which resolved to 142.54.179[.]90, so the Trojan would use the string “http:/w” as the basis of the C2 URL.  The initial beacon sent from the Trojan to the C2 server using a URL structured in the following way:

The C2 server will respond to this request with a command string using the previously mentioned format. During the attack on the technology organization, we observed the C2 server issuing the following command:

If the C2 server provides a command to execute on the system, the Trojan executes it using cmd.exe and writes the output to %TEMP%\runlog[random number].tmp. The Trojan will read this runlog file and send it to the C2 server via an HTTP POST request to a URL structured as follows:

The HTTP POST request contains an anomalous boundary value of “myboundary” and hardcoded filename value of “a.a”, as seen below, which may be used to generate detection signatures for this behavior:

While we did not observe the C2 server attempting to run additional commands via ISMAgent, we were able to analyze the Trojan itself to determine the functionality of its available commands. If the command string contains a URL to download a file to the system, the Trojan will simply use the URLDownloadToFileA function to download and save the file to the target system in the %TEMP% folder. If the C2 server provides a path to a file it wishes to upload from the system, the Trojan will open the file, read its contents, and then upload its contents via an HTTP POST to the following URL:

DNS Tunneling for C2

ISMAgent uses its DNS tunneling technique for C2 as a backup to its HTTP capability. This mechanism supports the same command message structure and even handles the commands in the same manner. The Trojan sends data to the C2 server via DNS queries by encoding data and using the encoded string as a subdomain of an actor owned domain. The C2 server can send data to the Trojan by resolving the DNS queries to IPv6 addresses that the Trojan treats as hexadecimal data.

To carry out its DNS C2 communications, the Trojan will issue DNS queries to the C2 domain to obtain the AAAA records associated with the domain. The Trojan starts this process by creating a unique GUID and appending it to the string "n.n.c." to create a subdomain to query in the following format:

To respond to this beacon, the C2 domain's name server will respond to this query with a hardcoded IPv6 value of a67d:0db8:a2a1:7334:7654:4325:0370:2aa3. This value acts as an acknowledgement of the beacon. The Trojan will then base64 encode the HTTP C2 URL it was using and will send this data to the C2 by constructing and issuing the following DNS query:

The Trojan splits up the base64 encoded data across several DNS queries, which we believe the C2 domain's name server pieces together using the supplied sequence numbers. The name server will respond to each of these DNS queries with another hardcoded IPv6 value of a67d:0db8:85a3:4325:7654:8a2a:0370:7334 to notify the Trojan that it has received the data. After all of the data is successfully sent via DNS requests, the Trojan will send a final DNS query that has the following structure to notify the C2 server that it has completed its data transfer:

After notifying the C2 server that the data transfer has completed, the Trojan may issue additional DNS queries to notify it is ready to receive data back from the C2 server using the following domain name structure:

The DNS server will then respond to these DNS queries with additional IPv6 addresses that the Trojan will treat as hexadecimal data as described by Arbor Networks.

Infrastructure

The ISMAgent payload embedded inside the newest variant of Clayslide used the C2 domain ntpupdateserver[.]com. The primary second-level domain has no IP resolution, instead relying on www.ntpupdateserver[.]com for resolution then two specific subdomains of ns1.ntupdateserver[.]com and ns2.ntpupdateserver[.]com as the actual DNS C2 handler. The ISMAgent payload embedded inside the June version used a completely different C2 domain at Microsoft-publisher[.]com, but used the exact same domain name structure. Lastly, we were able to identify a third sample of ISMAgent leveraging another unique C2 domain, adobeproduct[.]com.

ismagent1

Figure 5 Primary C2 domains for ISMAgent

Pivoting from the WHOIS registrant email address of paul.mcalister[at]mail.com revealed four additional highly suspect domains:

Pivoting on the WHOIS phone number we found two additional domains. These are registered with the same Registrar, have the same WHOIS address, but the registrant name “bolips Angelio” and email address bolips[at]outlook.com.

Thematically, these domains follow the pattern of ISMAgent and OilRig C2 domain names, abusing typo-squatting techniques in attempts to appear as legitimate domains. Each of these additional domains had the same structure as the three ISMAgent C2 domains, with no IP resolution on the primary second-level domain containing the www, ns1, and ns2 subdomains. Based off the same registrant email address and domain name structure, it is highly probable these other domains are also part of the ISMAgent infrastructure as C2 servers.

Lastly, we identified another ISMAgent sample using the C2 domain of adobeproduct[.]com, which again fits thematically and was also found to have the www, ns1, and ns2 subdomains attached to it.

These findings are diagrammed below:

ismagent

Figure 6 ISMAgent C2 Infrastructure

ISMAgent vs. ISMDoor

On the surface, the ISMAgent payload appears similar to the ISMDoor payload, sharing functionality such as a specific DNS tunneling protocol. However, closer analysis shows there are enough differences between the two payloads that justifies tracking ISMAgent as its own tool with its own name.

First, all known ISMDoor payloads using DNS tunneling were created for 64-bit architectures, while all known ISMAgent are x86 only. The most recent ISMDoor payloads using DNS tunneling have abandoned HTTP as a C2 communications method compared to earlier ISMDoor samples, whereas ISMAgent uses HTTP as the primary method and DNS tunneling as a secondary method to communicate with its C2 server.

Also, while the DNS tunneling protocol is the same, the messages within the transmitted encoded data differs dramatically. After the initial "n.n.c." beacon, ISMAgent sends the HTTP C2 URL as the data via the DNS tunneling protocol to send a beacon to its C2. During our analysis, we observed the sample used in this attack sending the following data immediately after the initial beacon:

Comparatively, ISMDoor sends a much more involved series of messages to the C2 server in order to get a command. The following is a sequence of messages sent from the ISMDoor Trojan to its C2 server via the DNS tunneling protocol, the last message ("M:GAC?") resulting in a command for the Trojan to run:

Lastly, the commands available within ISMAgent and ISMDoor are very different. As mentioned previously, ISMAgent has a far more limited, but flexible command set, allowing an adversary to upload and download files, in addition to command execution via command prompt. The most recent version of ISMDoor (v 10.0.192 SHA256: aa52dcaf6df43c6aa872fe0f73725f61e082d32c33fc976741d4eca17679533d) on the other hand, has a more comprehensive yet more rigid command set:

From Helminth to ISMAgent

During our data collection process, we discovered a Clayslide delivery document (SHA256: ca8cec08b4c74cf68c71a39176bfc8ee1ae4372f98f75c892706b2648b1e7530) from September 2016 containing a payload that appeared to be the Helminth script variant as found in other Clayslide documents, but upon further examination was wholly different. The macro within this Clayslide documents obtains a PowerShell script from a cell in the “Incompatible” worksheet, much like previous samples. The macro then saves a VBScript to %PUBLIC%\Libraries\LicenseCheck.vbs to run this PowerShell script every 3 minutes.

Like the Helminth script variants, this PowerShell script is a malicious payload that uses both HTTP requests and DNS tunneling to interact with its C2 server. However, the HTTP requests and the protocol employed to perform DNS tunneling differs dramatically from Helminth scripts installed by all other known Clayslide samples. The HTTP requests and DNS tunneling protocol found in this PowerShell script are instead identical to ISMAgent.

The C2 domain used for this script was mslicensecheck[.]com, which had previously been reported by LogRhythm in their OilRig whitepaper. Interestingly, it was the only domain associated with OilRig that did not have an IP resolution at its second-level, much like the ISMAgent samples.

The “doIt” function within the PowerShell script, seen in Figure 7, is responsible for initiating the C2 communications, as well as parsing the data provided by the C2 server to run the appropriate commands. This function uses the strings “/action2/”, “/response/” and “/upload/” within the C2 URLs when using HTTP to communicate with the C2 server. This behavior and these strings were also observed in the ISMAgent C2 behavior. The “doIt” function also shows that the C2 server will respond with data structured the same way as ISMAgent, using “#” as a delimiter and various offsets such as offset 0 used in subsequent requests with the C2, offset 2 specifying a URL to download a file from, offset 3 specifying a command to execute using command-prompt, and offset 4 specifying a path to a file to upload to the C2 server.

Figure 7 The 'doIt' function within the PowerShell script handles C2 interaction and functionality

The commonalities between this PowerShell script and ISMAgent do not stop there. The HTTP requests to the C2 server use the exact same URL structure. For instance, the payload generates a URL using the following line of code, which results in a base64 encoded string that contains [hostname/username]:

Also, as seen in the code above, the PowerShell script makes sure the base64 encoded data used is safe to use in an HTTP URL, by replacing the characters “=”, “/” and “+” characters with hexadecimal equivalent. The ISMAgent payloads also performed the exact same replacement, as seen in the portion of code in Figure 8.
OilRig_7
Figure 8 Code within ISMAgent payload that overlaps character replacement HTTP communications functionality within PowerShell script

The DNS tunneling protocol within the PowerShell script is the same as the ISMAgent payload, which can be visualized by the following beacon sent from the PowerShell script:

To facilitate the DNS tunneling functionality, the PowerShell script replaces the “=”, “/” and “+” characters within the base64 data sent to the C2 server within the subdomains of DNS queries. However, DNS queries cannot include the “%” character, so it uses the following line of code to replace them with “-“, “-s-“ and “-p-“ instead:

This functionality is again replicated within the ISMAgent payload for its DNS tunneling functionality, as shown in Figure 9.
OilRig_8
Figure 9 Code within ISMAgent payload that overlaps character replacement within DNS tunneling functionality within PowerShell script

Conclusion

The OilRig campaign has repeatedly demonstrated a willingness and desire to be iterative in their toolset, while maintaining some level of similarities over time. In this scenario, we were able to directly observe this type of behavior, while also implement a tool thought to be previously unrelated to OilRig. With the inclusion of ISMAgent within the OilRig toolset, we are beginning to see stronger relationships between the various documented groups operating in the Middle East. This region has proven to be a hot bed of espionage motivated activity over the last couple of years, and there appear to be no signs of this changing. As our research continues, our goal will be to generate even better understandings of the true extent of the various operations in this region and the relationships between them.

Palo Alto Networks customers are protected and may learn more via the following:

  • Samples are classified as malicious by WildFire and Traps prevents their execution
  • Domains and IPs have been classified as malicious and IPS signatures generated
  • AutoFocus users may learn more via the ISMAgent and Clayslide tags

Indicators of Compromise

Clayslide delivering ISMAgent

3eb14b6705179590f0476d3d3cbd71665e7c1935ecac3df7b876edc9bd7641b6
5ac939a5426db8614165bd8b6a02d3e8d9f167379c6ed28025bf3b37f1aea902

ISMAgent payloads
bbfc05177e5e29b3c8c4ef0148969d07e6239140da5bff57473c32409e76c070
52366b9ab2eb1d77ca6719a40f4779eb302dca97a832bd447abf10512dc51ed9
af4d8604d0cd09b8dc01dbafc33c6d240d356cad366f9917192a2725e0121a0d

ISMAgent C2
Adobeproduct[.]com
ntpupdateserver[.]com
microsoft-publisher[.]com

Related infrastructure

Miedafire[.]com
tatavpnservices[.]com
chrome-dns[.]com
fireeyeupdate[.]com
cache-service[.]net
level3-resolvers[.]net
Mslicensecheck[.]com

 

“Tick” Group Continues Attacks

The “Tick” group has conducted cyber espionage attacks against organizations in the Republic of Korea and Japan for several years. The group focuses on companies that have intellectual property or sensitive information like those in the Defense and High-Tech industries. The group is known to use custom malware called Daserf, but also employs multiple commodity and custom tools, exploit vulnerabilities, and use social engineering techniques.

Regarding the command and control (C2) infrastructure, Tick previously used domains registered through privacy protection services to keep their anonymity, but have moved to compromised websites in recent attacks. With multiple tools and anonymous infrastructure, they are running longstanding and persistent attack campaigns. We have observed that the adversary has repeatedly attacked a high-profile target in Japan using multiple malware families for the last three years.

Tick Tools

Symantec was first to publicly report on Tick, followed by LAC in 2016. These reports discussed the group’s malware, Daserf (a.k.a Muirim or Nioupale) and some additional downloader programs. Though Daserf wasn't a popular attack tool at the time of publishing the two reports, it dates back to at least 2011. Using AutoFocus, we were able to identify the link among Daserf and two other threats, 9002 and Invader. These threats shared infrastructure between July 2012 and April 2013.

Tick_1

Figure 1 Sharing C2 servers among threats

Invader (a.k.a Kickesgo) is a backdoor that injects its main code into a legitimate process, such as explorer.exe, and has following functions:

  • Logs keystrokes and mouse movement
  • Captures screenshots
  • Opens cmd.exe shell
  • Enumerates processes
  • Executes programs
  • Removes itself
  • Enumerates all opening TCP and UDP ports

9002 is the infamous RAT frequently seen in targeted attacks reported by various security vendors, including Palo Alto Networks. Interestingly, the C2 servers linking 9002 to Daserf were described in the report of an Adobe Flash Zero-day attack from FireEye in 2013. These domains were registered through the privacy protection services in 2008 and 2011.

  • krjregh.sacreeflame[.]com
  • lywja.healthsvsolu[.]com

Though we don't know the targets of these malware samples at the time of writing this article, we suspect the same group is behind these threats for a number of reasons. The samples of Daserf that shared infrastructure were submitted to VirusTotal only from Japan multiple times in 2013. As noted in a later section, another Invader sample shared different C2 servers with Daserf. Symantec reported that Tick exploited additional Adobe Flash and Microsoft Office vulnerabilities. SecureWorks said the adversary group is abusing a previously undisclosed vulnerability in Japanese Software Asset Management system on endpoints. Therefore, Tick or their digital quartermaster is capable of deploying new and unique exploits.

Minzen and Nameless Backdoor

In July 2016, we identified a compromised website in Japan that was hosting a Daserf variant. The web server was also a C2 server for another threat, Minzen (a.k.a, XXMM, Wali, or ShadowWali). The threat often uses compromised web servers in Japan and the Republic of Korea.

As Kaspersky and Cybereason recently posted, Minzen is a modular malware that has both 32-bit and 64-bit components in its resource section or configuration data in its body. One of the Minzen samples (SHA256: 9374040a9e2f47f7037edaac19f21ff1ef6a999ff98c306504f89a37196074a2) found in the Republic of Korea in December 2016 installs simple backdoor module as a final payload on a compromised computer. It opens a TCP port and receives commands from a remote attacker. According to the debug path in the body, the author of the tool called it "NamelessHdoor," and its internal version is identified as “V1.5.”

Tick_2

Figure 2 Debug path left in the backdoor module in Minzen

The payload is based on "Nameless Backdoor" which has been publicly available for more than ten years. The oldest code we could identify was hosted on a famous Chinese source code sharing site since 2005. The author of the NamelessHdoor appears to have created additional versions of the Nameless Backdoor by removing unnecessary functions, and added open-source DLL injection code from ReflectiveDLLLoader.

Tick_3

Figure 3 Nameless Backdoor posted on Chinese Source File Sharing Site

There is minimal public information regarding the Nameless Backdoor, except for the interesting report from Cyphort in 2015. The researcher of the company analyzed multiple threats, including Invader, Nioupale(Daserf) and Hdoor found in an attack against an Asian financial institution. We examined the sample described in the report as Hdoor and found it's a previous version of the NamelessHdoor we discovered in the Minzen sample, but without support for DLL injection.

Tick_5

Figure 4 Strings in NamelessHdoor sample found in 2015

Shared Infrastructure and Cipher Code with Custom Gh0st

Other interesting samples in the report are dllhost.exe and Shell64.dll. We don't have the same files but found possible variants close to their description in the article. These include the following:

  • Executable files that connect to the same remote server, blog.softfix.co[.]kr:80, download a DLL file and execute the 'lowmain' export function.
  • DLL files have 'lowmain' and 'main' exports.

It turned out that the DLL files we found are a custom variant of Gh0st RAT, and the EXE files download the RAT. Since the source code is publicly available, Gh0st RAT has been used by multiple actors for years.

The domain, softfix.co[.]kr was registered in 2014. One of subdomains, news.softfix.co[.]kr was the C2 server of Daserf (SHA256: 9c7a34390e92d4551c26a3feb5b181757b3309995acd1f92e0f63f888aa89423). Another subdomain, bbs.softfix.co[.]kr was hosted on same IP address as bbs.gokickes[.]com, which was reported as the C2 server of Invader by Cyphort. We also identified www.gokickes[.]com was the C2 of another Invader variant (SHA256: 57e1d3122e6dc88d9eb2989f081de88a0e6864e767281d509ff58834928895fb).

In addition to the infrastructure, the attacker also shared code. The Gh0st downloaders employ simple substitution ciphers for hiding strings.

Tick_5

Figure 5 Decryption code in Gh0st Downloader

The cipher converts one character to another based on a substitution table, which can be seen below. As an example, the character 'K' in plain text is changed to '5' in cipher text, 'h' is converted to 'j' and so on. The string 'connect' was encoded to 'zF((0za' using this table.

Text characters
plain text KhL9V1ds5Z"QnfNC&Fb8xGr-()<>[]{}|+THce;0%7Oiz#W DE6qS?aw./BJlk,yUPjgI^@$*tumYA'p2RoX=v_:M43
cipher text 5j2Cnx^@$*(){}|+mX k3DK'LGchHNPgZ,z0T8_sRU7)<>"[lBpdfI#%bu;yt-YeoW?4vAMQVa.6qJi:=wFO9&/1ESr

Table 1 Substitution Table used in Gh0st Downloader

The following Python script can decipher the encoded string.

The exact same table for simple substitution cipher is used in a variant of Daserf (SHA256: 01d681c51ad0c7c3d4b320973c61c28a353624ac665fd390553b364d17911f46). We also found a very similar table in other Tick tools. Since the strings are unique to these threats, we believe a developer linked to the group built these tools. Because of the shared domains and code, we believe the incident reported by Cyphort have ties to Tick. The following tables were identified for their associated malware samples:

Minzen (SHA256:26727d139b593486237b975e7bdf93a8148c52d5fb48d5fe540a634a16a6ba82):

Datper (SHA256: 7d70d659c421b50604ce3e0a1bf423ab7e54b9df361360933bac3bb852a31849):

Spearphishing Email with Patched File Encryption Program

We also identified another malware family, HomamDownloader, sharing some servers with Daserf. An overview of the connections among these threats is discussed in below.

Tick_6

Figure 6 Links among threats and servers

HomamDownloader is a small downloader program with minimal interesting characteristics from a technical point of view. HomamDownloader was discovered to be delivered by Tick via a spearphishing email. The adversary crafted credible email and attachment after understanding the targets and their behavior.

The email below was sent from a personal email account with a subject line of “New Year Wishes on January 1st”. The message asked the recipient to rename the attachment extension from “._X_” to “.exe” and opening it with the password specified in the email to view the Happy New Year eCard in the correct and polite language.

Tick_7

Figure 7 Spearphishing Email with HomamDownloader

The image above is translated to the following in English:

Dear XXXX,

Heartfelt Greetings for the New Year.
Thank you very much for your support over the past year.
I will greatly appreciate your further guidance and encouragement.

Would you please change the file extension of the attachment from "._X_" to ".exe" and open it?
Password is "nengajyo".

For those who are not familiar with Japanese companies, the email must look suspicious, especially given that the executable file attachment has the incorrect file extension. However, this may look legitimate in some cases. Many Japanese companies introduced a file encryption system for secure data exchange over email. The system encrypts documents with a user-specified password and often creates a self-extracting (SFX) file for ease of decrypting the file to recipients. When sending the SFX file with a password by email, senders usually rename the file extension from .exe to something else to avoid blocking or detecting the attachment by an email gateway or security product. The adversary may know Japanese enterprise users exchange these emails in such a way and crafts the spearphishing email in the same manner.

In addition to the social engineering email technique, the attacker also employs a trick to the attachment. The actor embedded malicious code to a resource section of the legitimate SFX file created by a file encryption tool, and modified the entry point of the program for jumping to the malicious code soon after the SFX program starts. The malicious code drops HomamDownloader, then jumps back to the regular flow in the CODE section, which in turn asks the user the password and decrypts the file. Therefore, once a user executes the attachment and sees the password dialog on SFX, the downloader dropped by the malicious code starts working even if the user chooses the Cancel on the password window. Should the user become aware of the infection later, it may be difficult to find the cause due to the fact that the original embedded file contained within the SFX is benign.

Tick_9

Figure 8 Execution flow of Patched SFX file

Conclusion

Tick was spotted last year, but they are actively and silently attacking various organizations in South Korea and Japan for a number of years. While some of the group’s tools, tactics, and procedures (TTPs) have been covered within this article, it is likely there is much that still remains uncovered.

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

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

Indicator of compromise

SHA256

Daserf

  • 04080fbab754dbf0c7529f8bbe661afef9c2cba74e3797428538ed5c243d705a
  • f8458a0711653071bf59a3153293771a6fb5d1de9af7ea814de58f473cba9d06
  • e8edde4519763bb6669ba99e33b4803a7655805b8c3475b49af0a49913577e51
  • 21111136d523970e27833dd2db15d7c50803d8f6f4f377d4d9602ba9fbd355cd
  • 9c7a34390e92d4551c26a3feb5b181757b3309995acd1f92e0f63f888aa89423

Invader

  • 0df20ccd074b722d5fe1358b329c7bdebcd7e3902a1ca4ca8d5a98cc5ce4c287
  • e9574627349aeb7dd7f5b9f9c5ede7faa06511d7fdf98804526ca1b2e7ce127e
  • 57e1d3122e6dc88d9eb2989f081de88a0e6864e767281d509ff58834928895fb

9002

  • 933d66b43b3ce9a572ee3127b255b4baf69d6fdd7cb24da609b52ee277baa76e
  • 2bec20540d200758a223a7e8f7b2f98cd4949e106c1907d3f194216208c5b2fe
  • 055fe8002de293401852310ae76cb730c570f2037c3c832a52a79b70e2cb7831

Minzen

  • 797d9c00022eaa2f86ddc9374f60d7ad92128ca07204b3e2fe791c08da9ce2b1
  • 9374040a9e2f47f7037edaac19f21ff1ef6a999ff98c306504f89a37196074a2
  • 26727d139b593486237b975e7bdf93a8148c52d5fb48d5fe540a634a16a6ba82

NamelessHdoor

  • dfc8a6da93481e9dab767c8b42e2ffbcd08fb813123c91b723a6e6d70196636f

Gh0stRAt Downloader

  • ce47e7827da145823a6f2b755975d1d2f5eda045b4c542c9b9d05544f3a9b974
  • e34f4a9c598ad3bb243cb39969fb9509427ff9c08e63e8811ad26b72af046f0c

Custom Gh0st

  • 8e5a0a5f733f62712b840e7f5051a2bd68508ea207e582a190c8947a06e26f40

Datper

  • 7d70d659c421b50604ce3e0a1bf423ab7e54b9df361360933bac3bb852a31849

HomamDownloader

  • a624d2cd6dee3b6150df3ca61ee0f992e2d6b08b3107f5b00f8bf8bcfe07ebe7

C2
lywjrea.gmarketshop[.]net
krjregh.sacreeflame[.]com
psfir.sacreeflame[.]com
lywja.healthsvsolu[.]com
phot.healthsvsolu[.]com
blog.softfix.co[.]kr
news.softfix.co[.]kr
www.gokickes[.]com
log.gokickes[.]com
sansei.jpn[.]com

Malspam Targeting Brazil Continues to Evolve

For years now, criminals behind banking Trojans, remote access tools (RATs) and other types of malware have targeted Microsoft Windows hosts in Brazil through malicious spam (malspam). Antivirus often detects the associated malware as "Banload," a family of Trojans that downloads other malware. We've identified 9,215 samples tagged "Banload" in AutoFocus since December 2013. Of these Banload samples, we've seen 2,132 samples during the first six months of 2017.Malspam_1

Figure 1: Banload samples we've seen during the first six months of 2017.

The infection process has become increasingly complex. We've previously documented examples of Brazilian malspam from 2015 and 2016 that reveal a multi-stage infection process. As of 2017, this trend continues, and these criminals often abuse legitimate services like Google and Dropbox. We have notified both Google and Dropbox of the attacks we found so they can take appropriate action.

This blog post reviews a Brazilian malspam example from late June 2017.

Stages of the malware infection

This category of Brazilian malspam uses a multi-stage infection process. The initial stages start from a link in the email. This link is from a URL shortner that leads through a series redirects to a cloud storage URL. The cloud storage URL returns a malicious zip archive.

Follow-up stages require the victim to open the zip archive and double-click on its content. In this case, the malicious zip archive contained a Windows shortcut (.lnk) file that downloaded script to download a malware binary and infect the computer with it.

Malspam_2

Figure 2: Multi-stage infection process from the June 2017 example of Brazilian malspam.

The email

This message claims to be the 3rd and final notification for payment of IPTU (Brazilian Property, Territorial, and Urban Tax) from City Hall, but email headers show the message came from an Italian IP address at 212.237.35.135. The attackers used a spoofed sender address: specifically, they used the recipient's email address as the sender's address. Criminals behind this campaign abused Google's URL Shortener service and used it for a link in the message.

Malspam_3

Figure 3: Example from a wave of malspam in late June 2017.

After clicking on the URL from the message, we saw a series of redirects that led to a Dropbox URL. The Dropbox URL provided a zip archive to the potential victim. The zip archive contained a shortcut file for Microsoft Windows (an LNK file). Double-clicking on that shortcut generated more traffic and infected the Windows host in our lab environment.

Malspam_4

Figure 4: Traffic from an infected Windows host indicates abuse of legitimate services.

Malspam_5

Figure 5: Clicking the link led to a zip archive.

The malware

The shortcut uses an exploitation technique dubbed "Squiblydoo" designed to bypass application allowlisting by utilizing tools built into the Windows operating system. If the malicious script was run with only the user's account permissions, it would not work. However, this technique uses signed Microsoft binaries that are installed with the operating system. Squiblydoo allows a user with normal privileges to download and execute a script with elevated privileges from a remote server. In this case, the LNK file used regsvr32.exe to execute scriptlet files retrieved from a Dropbox URL.

Malspam_6

Figure 6: Malicious shortcut (LNK) file extracted from the downloaded zip archive.

Malspam_7

Figure 7: Scriptlet returned from URL generated by the LNK file.

Malspam_8

Figure 8: Script returned from URL generated by the previous scriptlet file

This Squiblydoo technique was used to download another zip archive that contained two files: a legitimate Windows executable and a malicious DLL file. These two files were extracted and stored on the infected Windows host in a randomly-named directory under the user's AppData/Local/Roaming folder as shown in the image below.

Malspam_9

Figure 9: Follow-up malware downloaded as zip, extracted and saved under user's AppData/Roaming directory.

The executable is a component of G-Buster Browser Defense, originally developed by GAS Tecnologia. Diebold acquired GAS Tecnologia in 2012, and the most recent version of this software is called Diagnóstico Warsaw (Warsaw Diagnostics). In recent years, this system has been used by several Brazilian financial institutions to prevent bank fraud by ensuring correct identification between the user's computer, bank, and bank account. The G-Buster executable component is not malicious, although this particular version is no longer in use. Originally named GbpSv.exe, this is a signed executable will generally not show as malware by most anti-virus programs.

Malspam_10

Figure 10: Windows registry entry for GbpSv.exe made persistent on the infected Windows host.

This G-Buster executable GbpSv.exe is designed to load a DLL file named fltLib.dll. The DLL file is the truly malicious component of the two items from the infected host. The technique of loading malicious DLL using a legitimate executable, is known as side-loading.  Side-loading is an increasingly common technique used by criminals to sneak malicious content past Anti-Virus vendors by hiding it in DLL files. The DLL file appears to be botnet malware, and it likely has an information stealing component common to other malware seen in this type of Brazilian malspam.

Post-infection traffic

Post-infection traffic consisted of a single HTTP POST request that returned information on other infected hosts. We saw data on more than 400 infected Windows computers in text returned from this HTTP request.  Most of the infected hosts were located in Brazil, but a handful were from other locations like Argentina, Czech Republic, or Russia.

Malspam_11

Figure 11: Post-infection traffic from an infected Windows host.

Conclusion

Google and Dropbox were notified of the malicious URLs from this infection traffic, and we have ensured Palo Alto Networks customers are protected against this traffic. A similar infection with matching characteristics was later noted in July 2017, and we expect this trend will continue.

Users located in Brazil or people who use Brazilian online banking services should be aware of this threat and take necessary precautions, such as not clicking links in suspicious emails. We will continue to investigate this activity for applicable indicators to inform the community and further enhance our threat prevention platform.

Indicators of Compromise

Traffic after clicking on the email link that downloaded the malicious zip archive:

  • HTTPS via port 443 – goo[.]gl - GET /htm4qG
  • HTTPS via port 443 - googleapis[.]com - GET /pid/2via.html
  • HTTP via port 80 - gov.br.impostocontribuinte[.]com - GET /Contribuinte/Iptu/
  • HTTPS via port 443 - dropbox[.]com - GET /s/ss6op2vxi3ggnhe/Notificacao%28Iptu-.-2017%29.zip?dl=1

Traffic that occurred after double-clicking on malicious LNK file:

  • HTTPS via port 443 - dropbox[.]com - GET /s/pqgwxrkcbqaonsy/sdar7hsy_2_.sct?dl=1
  • HTTPS via port 443 - dropbox[.]com - GET /s/vgq25no8a5zbb9b/gw4c9sql_1_.sct?dl=1
  • HTTP via port 80 - 192.252.1[.]11 - GET /https/dv/ipv3.zip

Post-infection traffic from the infected Windows host:

  • HTTP via port 80 - 192.252.2[.]161 - POST /ipv3/index.php

Associated file hashes:

SHA256 hash: b42994352613e6bf63599dac0e2d4ddaf2b868842d5f04749f437f8335a63309

  • File name: Notificacao(Iptu-.-2017).zip
  • File description: Downloaded zip archive after clicking link from the malspam

SHA256 hash: a4cf9811c55d0e4f2f8c783d1458ab3a5d69244287030a0a8154e89ed6ae02b0

  • File name: Notificacao(Iptu-.-2017).lnk
  • File description: Extracted Windows shortcut (LNK) file from the zip archive

SHA256 hash: e7374e5ec576d95155c3b35d799656aba33315edbc9cdc7f0a04ed201135843a

  • File name: sdar7hsy_2_.sct
  • File description: Scriptlet (SCT) file returned after double-clicking the LNK file

SHA256 hash: ed491c8d0b4ea30a3a4d78c2ee713d72b7ff4b1f90e04a86a775852953ade892

  • File name: gw4c9sql_1_.sct
  • File description: Another SCT file called from the first scriptlet

SHA256 hash: 94cf47c57413753ecc8c648384b475e96f13f8caca648b9240486340e1d91aa0

  • File name: ipv3.zip
  • File description: Follow-up malware downloaded by the above SCT file

SHA256 hash: 71eb0797db8de8ff5a9fe84b5568cd728b4b089537e4e1b5fd55b42de8b3fa07

  • File name: bxmmyDLr.exe
  • File description: G-Buster executable (GbpSv.exe) made persistent on the infected host

SHA256 hash: faf0892be515437f9dfc86040e130533722b6149d65000969ebb334253cf4b89

  • File name: fltLib.dll
  • File description: Malicious DLL loaded by G-Buster executable.

LabyREnth CTF 2017 Final Week: Beat the Maze!

The LabyREnth Capture the Flag (CTF) challenge ends in less than a week!

It’s the final hours of the LabyREnth challenge, do you have what it takes to defeat the goblin king? You’ll have until 4:00 p.m. Pacific Time on July 23, 2017 to complete the challenge.  Do you have the creativity and talent to make it to the finish line?

Though the cash prizes have been claimed, you can still find glory in completing challenges, getting your name in the hallowed halls, and receiving coins and other participation prizes. The CTF is open worldwide, including Palo Alto Networks partners.  Please refer to the official rules by typing 'overview' into the terminal for more on eligibility.

We’ll announce the winners right after the challenge closes, so keep an eye on our blog, watch the @unit42_intel Twitter handle and #LabyREnth hashtag for updates and hints!

Can you escape the LabyREnth?

EMEA Bi-Monthly Threat Reports: Turkey, Saudi Arabia & United Arab Emirates

Introduction

As part of a new series of regular threat report updates to the public covering different sets of countries from around the EMEA (Europe Middle East and Africa) region, this blog covers the emerging and Middle East region focusing on Turkey, Saudi Arabia & United Arab Emirates for April and May, and leads on from my previous blog about the United Kingdom, Germany and France. This new series will dig deeper into current trends, the threats affecting each country, and provide useful tips for mitigating these threats via our AutoFocus Threat Intelligence Service.

In my previous blogs, I introduced the EMEA region at a high-level– a large group of countries each with mixed languages, cultures, and cybersecurity maturity levels. Each also has different industry sectors and different economic profiles, which in turn creates a very diverse environment potentially ripe for cyberattacks.

Headlines

  • Jaff ransomware very prevalent in all three countries using PDF files with embedded weaponized Microsoft Word documents.
  • Spora ransomware uptick, delivered over web-browsing application, in Saudi Arabia.
  • Remote Access Trojans (RATs) especially popular in attacks against Saudi Arabia.

Trends

By Country

According to AutoFocus, Turkey accounted for over three quarters of the total malware samples and the malicious sessions of the three countries I’m examining in April, with almost 2,000 unique malware samples in over 27,000 malicious sessions. The United Arab Emirates accounted for a slightly higher number of samples than Saudi Arabia but both countries had lower volumes – under half of Turkey’s. The same cannot be said when comparing malicious session volume as the United Arab Emirates received almost four times the amount Saudi Arabia did.

Figure 1 below shows the general trends of malicious sessions for each country and highlighting the weekends where volume generally decreases as we tend to see less malspam inbound to organizations and less outbound malicious session volume using application traffic such as web-browsing.

EMEA_1

Figure 1: Daily malware sessions by country

The same malicious session volume data is represented in Figure 2 below in terms of the top 10 most affected industries in all three countries.

Given Turkey’s proportion of the total malicious volume, as mentioned earlier, it’s little surprise to see the country representing highly in many sectors in Figure 2, however other countries did show much higher volume in certain sectors, such as Healthcare in Saudi Arabia, with 96% of the volume, mostly due to the most prevalent of which include Jaff and Cerber. In addition, data stealing Trojans featured highly as well, including strains such as Ursnif, GipStealer, Pony, Lokibot and PredatorPain.

Similarly, the Government sector in the United Arab Emirates saw higher volumes of malware than other countries, receiving many of the same malware families as in the Healthcare sector in Saudi Arabia, mostly due to the large-scale malspam campaigns used for delivery. Conversely, Remote Access Trojans (RATs) featured highly only in the Government sector including such strains as ZyklonHTTP and LuminosityLink.

EMEA_2

Figure 2: Daily malware sessions by Industry

Top Malware

The following charts in Figure 3 below show the top malware by way of the highest number of unique samples seen targeting each of the three countries.

The charts clearly show overlap between the countries and the malware observed in the region. PdfDocmDropper, for example was the number one malware in terms of prevalence accounting for almost half of the samples in both Saudi Arabia and the United Arab Emirates. This malware is closely linked to Jaff ransomware and was also highly prevalent in Turkey only to be beaten by RanserKD.

EMEA_3EMEA_4

EMEA_5

Figure 3: Top Malware by Country

EMEA_6EMEA_7

A switch occurred in April whereby variants of Jaff ransomware that were previously delivered using weaponised Microsoft Word documents changed to using PDF files that contained said Word documents, embedded within the PDF. When opened, most applications rendering the PDF content will prompt the user to open the embedded file with leading text to encourage this behavior, as shown in Figure 4. If the embedded Word document is opened, the Microsoft Word will take over, and produce a more traditional view, together with social engineering content, to encourage the recipient to enable the VBA macro content, as shown in Figure 4.

EMEA_8 EMEA_9

Figure 4: (left) PDF Document Dropper containing embedded Word document (right)

The fact that there is an additional step (opening the embedded Word document from within the PDF) in the infection chain in many ways may lead to fewer infections simply because would-be victims get another chance to question if this is suspicious behavior, however, we believe belief is that PDFs are being used here because as weaponized Word documents are so ubiquotous that security policies are being applied to limit their delivery into enterprise organizations.

Typically these PDF droppers arrive via email with filenames such as “Scan_920684.pdf” and “123-229928252-reg-invoice.pdf” where numbers can differ. Similar subject lines for the emails are used, including “Scan Data” and “Copy of your 123-reg invoice ( 123-595747586 )”.

EMEA_10

RanserKD ransomware was seen during this period affecting both Turkey, where it was the most prevalent malware, and Saudi Arabia but in a much smaller scale and only affecting the Consumer and Packaged Goods sector. Figure 5 below shows the different industries affected in Turkey.

EMEA_11

Figure 5: Industries in Turkey affected by RanserKD

Some examples of session informaiton from the attacks seen in Turkey include filenames like “771040.doc” and email subjects as follows (with their English translation):

  • Odeme yapmanizi rica ediyoruz (we ask you to drink);
  • Istediginiz bilgi burada (The information you want here);
  • Lutfen onerimize bakin (Look at our tips)

RanserKD, a family of file-encrypting ransomware that has been with us since the start of the 2017 in ever-increasing volume, is quite novel making use of legitimate webservices, such as Imgur and Dropbox, as part of its communication schema. Weaponized Word documents typically look like the example shown in Figure 6 below, often including leading text and techniques to encourage recipients to click on links.

EMEA_12

Figure 6: RanserKD weaponized document example

During execution of a RanserKD weaponized Word document in our Wildfire sandbox numerous malicious behaviors are exhibited, including the malicious VBA code launching, in the context of the Word application process, a new command shell process in turn to execute a PowerShell command. Figure 7 below shows this activity as reported through AutoFocus.

EMEA_13

Figure 7: Wildfire sandbox analysis for RanserKD initial infection behavior

The command appears quite convoluted but essentially it attempts to download the ransomware payload from a list of URLs, saving the file in the user’s %TEMP% folder using a random number for the filename, and executing said payload.

Grey box 1

Top Applications

Figure 8 plots the malicious sessions seen in the three countries by their respective applications, where said application is common to all countries. The most common method for malware delivery was email, especially when combining SMTP, POP3, IMAP, and other webmail applications together. This trend matches malware delivery activity globally. Based off these metrics we can deduce that social engineering via specially crafted phishing emails is still a heavily used attack method.

The SMTP volume breakdown between the three countries indicates that Saudi Arabia received the most malicious sessions, which is interesting considering that the total of all application session volume in Saudi Arabia was almost five times less than Turkey’s and that Saudi Arabia received fewer unique samples over those more plentiful SMTP sessions. Aside from Jaff ransomware the most prevalent malware over SMTP in Saudi Arabia was Pony – a downloader with plugins for credential harvesting.

EMEA_15

Figure 8: Malware sessions by application by Country

EMEA_16Pony is a popular downloader program that can download additional malware onto the infected system. It is also equipped with a number of plugins that may be used to steal stored credentials for various applications such as FTP clients, web browsers, email clients, and other software. Pony is also commonly known as Fareit.

This commodity Trojan is common and often seen in high volumes throughout the world. Although this sparkline indicates what appears to be a slight decline EMEA_17in this period as compared to three to four months prior, the session volume still averages well over two thousand per day. For the three countries examined, the industries most targeted were Higher Education, Consumer Packaged Goods, Wholesale and Government.

EMEA_18

 

Loki Bot is a commodity malware sold on underground sites and is designed to steal private data from infected machines, and then submit that info to a command and control host via a HTTP POST. This private data includes stored passwords, login credential information from web browsers, and a variety of cryptocurrency wallets. Globally, LokiBot is trending upwards EMEA_19to hundreds if not thousands of sessions per day. Often the SMTP session emails have double file extensions, such as ‘.pdf.exe’ as well as ‘.gz’ extension purporting to be gzip compressed files.
EMEA_20

Spora was mentioned in the last threat report blog as being especially prevalent in France. In this report Spora is the most prevalent malware seen over the web-browsing application with more than one quarter of all such samples. Most of the volume seen was in Saudi Arabia, which had over three times the volume compared to the United Arab Emirates; Turkey saw no Spora activity during this period.

As described in the last blog the growth of Spora globally since early this year had been quite high and we can see this trend EMEA_21 continues further into 2017.

Many of the web-browsing sessions containing Spora ransomware use filenames such as “Chrome font.exe” that purport to be font files or other updates related to the Google Chrome web browser. The target industry in both countries is Securities and Investment Services.

Threats

Country Specific

We can see further differences between the three countries, as Figure 9 below highlights. Despite the vast majority of malware families being common across all three countries and globally, there are some malware families only in observed in one country. The following section describes each of these country-specific threats and shows their global trends for the last six months in the form of sparkline charts highlighting each malware’s peak and trend over the extended period.

EMEA_22

Figure 9: Unique malware families, by Country

EMEA_23

Nymaim is family of ransomware that includes components to download other malware and lock PCs. This malware is frequently distributed by Exploit Kits and malspam messages. In this case, the sessions in Turkey were sent over SMTP and the handful of samples seen during this period were present in several thousand sessions around the world as part of a large campaign. Email subject lines referenced “invoices” and “unpaid items” and many were in Polish, with some sender addresses including Polish domain names.

AutoFocus shows that globally, over the extended period of the last six months, the volume of Nymaim ransomware is trending EMEA_24 down but with some fairly significant activity reaching several thousand sessions per day from time to time.
EMEA_25

KasperAgent is a downloader malware family used in targeted attacks deployed to gain a foothold into target organizations. It supports a basic set of commands including the ability to capture keystrokes, screenshots, exfiltrate basic system and user information, and steal passwords from common web browsers.

The malware seen in Turkey targeted companies in the Media and Entertainment sector, as described in this Unit 42 and ClearSky collaborative blog, by sending emails with executable attachments having .scr extensions. Subject lines for such emails included text such as: مراسلة بين قيادة حركة حماس وقوي الامن الداخلي بغزة اعلان حرك , which translates to “Correspondence between the leadership of Hamas and the Internal Security Forces in Gaza”. Hamas is the de facto governing authority of the Gaza Strip since its takeover of that area in 2007; the Internal Security Forces are the national police and security force of Lebanon.

Session volume for this malware is quite low in total but has recently shown several larger spikes EMEA_26 after a period of little activity.
EMEA_27

ImminentMonitor (aka MorphineRAT), targeting Consumer Packaged Goods sector in Saudi Arabia via SMTP, is a popular Microsoft .NET Framework RAT with extensive functionality containing multiple plugins from crypto-currency miners to keylogging.

The SMTP sessions appear to be from spoofed accounts with most sessions originating from the U.S. with the sender email address coming from Gmail and yahoo addresses. Subject lines and attachment filenames include “Police Invitation Letter” or contain “Invoice”, “Proforma”, “Swift” or “Payment” references. The emails have the ImminentMonitor RAT malware attached as executable files having .EXE file extensions.

Higher volumes of this RAT were seen some months ago, however, very recently there’s been an uptick EMEA_28of several hundred sessions per day.
EMEA_29 QuasarRAT is a Remote Access Trojan that can collect a victim’s personal information and send it to a malicious actor. It can also imitate a legitimate website to lure you into revealing your personal information.

The samples tagged in AutoFocus affecting Saudi Arabia were also seen in conjunction with the OfficePackager AutoFocus tag as the executable malware was delivered as an embedded object within a Word document. The malicious behavior section below describes this delivery method in more detail. Example subject lines from the malicious emails included “AIR FREIGHT SHIPPING” and targeted the Consumer Packaged Goods sector.

Session volume globally for the last six months has been pretty low however since the peak of almost 500 sessions in one day back in February, there have been some other quite large spikes of activity EMEA_30 as well.

EMEA_31

DownloadSponsor bundles unwanted applications into the install process without user consent. Installed applications can include PriceSparrow capable of updating web browser home pages and installing other adware related files for monetization purposes. In the United Arab Emirates, this malware was installed by an instance of the Remote Access Trojan RemcosRAT. Globally, DownloadSponsor was extremely prevalent EMEA_32 about six months ago but now we see a much lower, albeit consistent, volume of hundreds of sessions per day.

EMEA_33During this period, other RemcosRAT sessions in the United Arab Emirates – those not installing DownloadSponsor – targeted Government, and Securities and Investment Services sectors with emails having subject lines such as “NEW ORDER.” and “TT Payment USD64,365.90”. These originated from the United States and Turkey respectively. File attachments were executed files with .EXE extensions.

Expanding the search for RemcosRAT to the other two countries only Turkey saw the malware with similar session information as per the United Arab Emirates, however, in two cases the attached files were .doc Word documents containing exploits – RTF-ASLR-Bypass and RTF-OLE-Exploit. The RAT payload installed after the exploits have successfully run also exhibits a behavior tagged in AutoFocus as PingSleep that was not seen in the aforementioned RemcosRAT variants in this report. More details can be seen in the malicious behaviors section below.

RemcosRAT emerged in underground forums in late July 2016. The RAT is written in C++ and provides full access to a compromised system including: downloading files, uploading files, listing drives and files, executing commands, stealing data, and logging keystrokes. Globally the malware peaked earlier this year but a slight uptick EMEA_34 has been witnessed again recently.

EMEA_35Grenham is a virus written in Delphi that infects other files found on the victim system having a .exe extension. The virus replaces the original filename with a copy of itself and renames said original as “g<filename>.<extension>” or “v<filename>.<extension> where <filename> is the name of the original file and <extension> the matching original extension. This process is highlighted in the three pictures below in Figure 10. The virus also creates a system Mutex "Paint" to ensure multiple instances of the malware. The malware is distributed over email using .exe or .bat files and purporting to be invoice or purchase order related. Globally the volume is fairly consistent EMEA_36 averaging around one hundred sessions each day.

EMEA_37EMEA_38EMEA_39

Figure 10: Grenam virus infection effects. Left: original, middle: copies of malware using original filenames, right: original files renamed.

Malicious Behaviors

As mentioned in my last blog on EMEA threat trends, malicious behaviors can be a powerful way of discovering new threats or suspicious applications. The reason being because many malicious behaviors are common across multiple malware families irrespective of the type of threat be they ransomware or information stealing Trojans. These commonalities could include the same persistence mechanisms, evasion, or communication techniques, and so forth. In this next section, we will investigate some of the most prevalent behaviors that were on the rise in the three studied countries as well as globally over the last six months.

EMEA_40 Seen in conjunction with Pony sessions in all three countries, QuasarRAT in Saudi Arabia and AgentTesla – a small .NET based keylogger readily available to actors to log keystrokes and the victim’s clipboard to send back to the command and control (C2) channel – in the United Arab Emirates.

OfficePackager or “OLE Packager” is a feature introduced in Windows 3.1 and is still present in every version of Microsoft Office, on every Windows OS. It allows you to embed any file into Office documents. It is also very dangerous, not only because there is no way to disable it, but also because attackers can use it to spoof the file extension and icon type of the embedded object, and essentially force someone to make a bad trust decision about the content.

Malware authors often use this technique to embed executables or other malicious code into Office documents and use techniques, such as misleading descriptions and iconography to mask the intention and type of the embedded file, to trick users into executing the payload. Figure 11 below shows the container Word document containing what appears to be another embedded Word document but upon opening the embedded file, the Security Warning dialog reveals the actual situation – an executable file, in this case named “DHL SHIPMENT DETAILS.exe” is trying to execute.

EMEA_41

Figure 11: OfficePackager in action: an embedded executable file resembles a Word document.

Over the past six months the trend has been fairly consistent with hundreds or low-thousands daily globally, EMEA_42however the sparkline does not show this consistency due to the huge volumes seen from time to time with the peak value at tens of thousands of malicious sessions containing malware using this behavior seen in a single day.

EMEA_43Malware authors learned long ago that performing a ping, often against the localhost IP address of 127.0.0.1, takes approximately one second to accomplish. As such, malware authors will often execute a series of pings as an alternative to calling a sleep function, or in situations where no such function exists. This behavior is quite common with several thousand malicious EMEA_44sessions seen per day containing malware exhibiting this “sleep” technique. During the peak of such activity over the past six months, that volume increased to close to forty thousand sessions per day.

PingSleep has been seen in conjunction with various malware families over time but during this period, and in these three countries, it was more commonly seen with Cerber ransomware, Loda Trojan that is capable of spying on its victim, and NanoCoreRAT.

The following three behaviors are commonly seen together when malware is delivered using weaponised Word documents to launch system commands, including PowerShell, which themselves are often obfuscated to evade signature based detection techniques. During this period, the three behaviors were used in by the aforementioned Nymaim ransomware targeting Turkey.
EMEA_45 EMEA_46

Has consistently high volume globally, averaging over twenty thousand sessions per day over the last month, and peaking at over one hundred and seventy five thousand sessions in a single day. This behavior represents Malicious Word documents that use VBA macros to launch PowerShell to perform malicious activities, including downloading payloads from the internet. This technique was most prevalent in the three countries in the context of RanserKD and Cerber ransomware, AgentTesla information stealer and to deploy the Pony downloader.

EMEA_47EMEA_48

Identifies samples that invoke “cmd.exe /C” commands to execute a specific Windows Shell command of which common examples include to launch built-in Windows programs such as PowerShell and ping. Despite a general decline over recent months this behavior still exists in various malware families that account for several thousand sessions per day. In the three countries of this report, said families include Spora ransomware, PredatorPain and LokiBot information stealers, Pony and more.

EMEA_49EMEA_50

This technique has declined of late to tens or hundreds of sessions compared to hundreds of thousands per day earlier this year, perhaps due to improved detection techniques counteracting the obfuscation technique, which basically involves using the caret (‘^’) character to evade basic detection by breaking up a command-line string. This AutoFocus tag identifies this technique in the context of the string "powershell", for example: “p^o^w^e^r^s^h^e^l^l”, “p^o^w^e^r^s^h^e^ll”, “p^o^w^e^r^s^h^el^l” and so on. During April and May, this behavior was only seen together with Nymaim ransomware family targeting Turkey.

AutoFocus: Search based on Behaviors

There are two methods for searching in AutoFocus for malicious Behaviors. One is by searching using the tag artifact, like the ones described above and the other method is to use the Observed Behavior artifact.

1. AutoFocus can be used to search for Behaviors malicious (or benign) in applications running in your environment to provide context around them. Pivoting searches in AutoFocus based on Behaviors alone may uncover suspicious files that malware family tagging and searching do not cover.

For example, importing the following AutoFocus query, or running it over the API, will uncover dozens of malware or adware families using the common malicious behavior of ImageFileExecutionOptionsPersistence discussed above.

{"operator":"all","children":[{"field":"sample.malware","operator":"is","value":1},{"field":"sample.tag","operator":"is in the list","value":["Unit42.ImageFileExecutionOptionsPersistence"]}]}

EMEA_51

2. Another artifact that can be used in search is “Observed Behavior”. This is a list of abstracted Behaviors based on a series of Behavioral events and include examples such as applications that set Image File Execution Option entries to load themselves, documents that contain macros, applications that access Alternate Data Streams, and many others.

{"operator":"all","children":[{"field":"sample.malware","operator":"is","value":1},{"field":"sample.tasks.behavior_type","operator":"is","value":"execution_option"}]}

EMEA_52

These queries can also be exported for use with the AutoFocus API. An easy way to access the API is to use our AutoFocus Lenz script available from GitHub. A command like the following can be run that requests a dns_scrape function, limited to 5 results and running a query using the exported JSON query from one the examples above (alternatively this could be for a hash or list of hashes.

python af_lenz.py -r dns_scrape -l 5 -i query -q '{"operator":"all","children":[{"field":"sample.malware","operator":"is","value":1},{"field":"sample.tasks.behavior_type","operator":"is","value":"execution_option"}]}'

The results from this particular query are a few domain names but for brevity:

[+] dns [+]

wiziancko.top

Conclusion

EMEA is a socially and economically diverse region with many interesting assets whether they be citizen data, financial information, or natural resources and, as such, is a target for cyber criminals the world over.

It’s probably no surprise to see ransomware as a prevalent malware crossing all borders into all countries as this malware is mostly victim-agnostic. Any data on any computer in any country is a viable target. We saw a slight change in TTPs (Tools Techniques and Procedures) with one ransomware family, Jaff, which made use of weaponized Word documents embedded inside PDF droppers (AutoFocus tag: PdfDocmDropper) perhaps to bypass increased security measures around the traditional Word document containers.

As per the last report, Spora ransomware accounted for some of the ransomware prevalence, and was delivered over web-browsing application, which differs from the traditional malspam email campaigns.

Clearly Remote Access Trojans and information-stealing malware are prevalent in these countries and their emerging markets.

Cyber Hygiene

The threat landscape is vast and can be complex but you can minimize your risk of infection and enhance the overall health of your network by following some basic cyber hygiene habits:

Patch systems and applications wherever (and as soon as feasibly) possible. Alternatively, focus on other security solutions and methods, such as exploit prevention technology to protect those unpatchable systems and applications from attack, or to help manage patching cycles to suit your requirements. Prioritize patching based on known exploits or in-the-wild-attacks. Segment those unpatched/unpatchable devices in the network with additional access controls based on users or application communication to minimize the risk of exploitation. Perform regular vulnerability scans of systems and review changes to spot new devices or changes in active vulnerabilities.

Segment networks to contain attacks by limiting attacker’s ability to move laterally and to provide additional security for certain areas of the network. This technique can be applied to external-facing networks as well to minimize the exposure to the internet and limit the capability of network worms, such as the recent Wanacrypt0r ransomware attacks.

Change the file association for JavaScript to be opened using Notepad (or something else benign) rather than the Windows Scripting Host or other shell capable of executing malcode. This can be done per PC or enterprise-wide using Group Policy. This will prevent many JavaScript-based threats from running in the context of weaponized documents.

Educate users and employees of the security risks faced by your organization and perform regular training and reminders about these, and how they can help the effort. Provide a platform for users to learn about the risks and to report incidents to security-related staff. Create a culture whereby such reporting is important and valued. Monitor effectiveness of training for the purposes of gap analysis and creating dialogue between security teams and users.

Ensure timely, accurate and verified backups of critical data to provide a feasible option to recover should a malware attack render a system or its data inoperable or inaccessible.

SpyDealer: Android Trojan Spying on More Than 40 Apps

With the prevalence of Google Android smartphones and the popularity of feature-rich apps, more and more people rely on smartphones to store and handle kinds of personal and business information which attracts adversaries who want to steal that information. Recently, Palo Alto Networks researchers discovered an advanced Android malware we’ve named “SpyDealer” which exfiltrates private data from more than 40 apps and steals sensitive messages from communication apps by abusing the Android accessibility service feature. SpyDealer uses exploits from a commercial rooting app to gain root privilege, which enables the subsequent data theft.

SpyDealer has many capabilities, including:

  • Exfiltrate private data from more than 40 popular apps including: WeChat, Facebook, WhatsApp, Skype, Line, Viber, QQ, Tango, Telegram, Sina Weibo, Tencent Weibo, Android Native Browser, Firefox Browser, Oupeng Brower, QQ Mail, NetEase Mail, Taobao, and Baidu Net Disk
  • Abuses the Android Accessibility Service feature to steal sensitive messages from popular communication and social apps such as WeChat, Skype, Viber, QQ
  • Takes advantage of the commercial rooting app “Baidu Easy Root” to gain root privilege and maintain persistence on the compromised device
  • Harvests an exhaustive list of personal information including phone number, IMEI, IMSI, SMS, MMS, contacts, accounts, phone call history, location, and connected Wi-Fi information
  • Automatically answer incoming phone calls from a specific number
  • Remote control of the device via UDP, TCP and SMS channels
  • Spy on the compromised user by:
    • Recording the phone call and the surrounding audio & video.
    • Taking photos via both the front and rear camera
    • Monitoring the compromised device’s location
    • Taking screenshots

There are multiple factors that mitigate the risk of this threat to most users.

  • As far as we know, SpyDealer has not been distributed through the Google Play store
  • We do not know exactly how devices are initially infected with SpyDealer, but have seen evidence to suggest Chinese users becoming infected through compromised wireless networks.
  • We have reported information on this threat to Google, and they have created protections through Google Play Protect.
  • SpyDealer is only completely effective against Android devices running versions between 2.2 and 4.4, as the rooting tool it uses only supports those versions. This represents approximately 25% of active Android devices worldwide. On devices running later versions of Android, it can still steal significant amounts of information, but it cannot take actions that require higher privileges.

As of June 2017, we have captured 1046 samples of SpyDealer. Our analysis shows that SpyDealer is currently under active development. There are three versions of this malware currently in the wild, 1.9.1, 1.9.2 and 1.9.3. Starting from 1.9.3, content of configuration files and almost all constant strings in the code are encrypted or encoded. An accessibility service was also introduced in 1.9.3 to steal targeted apps’ messages. According to our dataset, most of these samples use the app name “GoogleService” or “GoogleUpdate”. The most recent sample we have observed was created in May, 2017 while the oldest sample dates back to October, 2015, indicating this malware family has been active for over a year and a half. We also observed evidence of infected users discussing the malware in October 2015 and February 2016 as shown in Figure 1.

Spydealer_1

 

Figure 1 Real infection instances in the wild

Detailed Technical Analysis

Service Launching and Configuration

After installed on an Android device, SpyDealer shows no application icon. However, it registers two broadcast receivers to listen for events related to the device booting up and network connection status. Whenever any of these events are broadcasted, the key service component AaTService starts. At the first launch, it retrieves configuration information from the local asset file named readme.txt. The first line of this file indicates the IP address of a remote C2 server, the second line configures what actions the malware can take on mobile networks, and the third line specifies what actions are allowed under a Wi-Fi network. The configuration settings can also be remotely updated by various C2 channels. One example of the readme.txt is given in Figure 2. The full list of the IP addresses for the remote C2 servers is available in Appendix B. A partial listing of the configurable actions is depicted in Table 1.

Spydealer_2

Figure 2 Content of the readme.txt

Table 1 Partial Listing of Configurable Actions

Number Action Number Action
1 Get call history 9 Send recorded audio files
2 Get SMS messages 10 Capture screenshot
3 Record audio 11 List files under a given directory
4 Get GSM location 12 Get GPS location
5 Get contacts 20 Intercept incoming SMS messages
7 Get information and network traffic of installed apps 21 Do not intercept incoming SMS messages
8 Get device specific information 82 Get current running apps

 

Rooting and Persistence

SpyDealer uses two different rooting procedures to gain root (superuser) privilege. Samples of version 1.9.1 and 1.9.2 reuse the root exploits used by commercial rooting app “Baidu Easy Root”. Rooting applications like this one are created for users who want to gain low-level access to their phone which wouldn’t be possible without removing some security protections. This is not the first time that Android malware has stolen root exploits from existing commercial rooting tools. Previously in 2015, we saw the Rootnik Android Trojan abuse the “Root Assistant” tool to gain root access.

SpyDealer 1.9.1 and 1.9.2 gain root privilege by abusing “Baidu Easy Root” as detailed below:

  1. Drops a customized su file named sux from assets to the app’s own data directory.
  2. Checks if the infected device is already rooted or not. If the root privilege is available, there is no need to escalate to root privilege.
  3. Checks the existence of the file /data/data/<package_name>/broot/raw.zip which contains all the rooting exploits. If there is no such file, the malware will download it from http[:]//yangxiu2014.0323.utnvg[.]com/apk/raw.zip. The file integrity is then inspected by comparing the MD5 value of the downloaded file and the pre-calculated one from http[:]//yangxiu2014.0323.utnvg[.]com/apk/md5.txt.
  4. Unzips the downloaded file to the app’s data directory and attempt to gain root privilege by systematically executing the exploits one by one.
  5. Installs busybox and remounts system partition as read-write by running a sequence of shell commands with superuser permission.

The downloaded file “raw.zip” contains the exploits from “Baidu Easy Root” version 2.8.3, which is depicted in Figure 4.

Table 2 gives a full list of the exploits stolen by SpyDealer. For example, 022d251cf509c2f0 is an executable binary file observed in the “raw.zip”, and the original file in “Baidu Easy Root” is actually in gzip format. It’s interesting that we can recover its original file name which is fb_mem_root.

Spydealer_3

Figure 4 Files in the downloaded raw.zip and Baidu Easy Root v2.8.3

File Name Original File Name SHA256
022d251cf509c2f0 fb_mem_root d54ab418ba35f7623c45e3ba7fe341be9955f332524a251a886fbe34b1d11af4
23c6b143cd0d6c15 camera_config_exp 7e238f8f1f61dd81f1bebc59717b86769adeca6615f0460fc282d7a0ced1f10d
297e4ba234a39ee6 put_user_opt_exp 3367c0dd8ead724da0c8cd05e8f15a3664ec418bdcdaa2b3721fbc5f7b060f86
460dbcebd7f09800 hw_hisi_exp 7ceb9ec2d02a29bcece226f9e29c9e161594dcb8e40dc853325ac087863d144d
4f2d1af460417f6a boomsh 1b7a7fb6546c28e62506f458ccaff513743f568793a9fe639c2c54c3bcdec07a
54a9d3d68cb16d5a omap_dsp_exp 977dcfc06889d3a4a30d4f2a97a29df812a3cb18fcced894fa2293cbf9f2fb37
5fb437fbf964d7e7 mtk_isp_exp 51b970eef664819f28d5c3ad5c29ecff089d21b6164c6be495956b5002f43c14
621f1ca29529a0ab mtk_fdvt_exp 0ad1a250341839e3d9c5567f79b56aab501ab9e06375f401a74fbfeadd6bd40b
63e31e6275526979 mtk_isp_exp2 22a45ceb1ba9fbf377f89530baf85542d34294cefd3530ca563d148a58ae2f8d
65d21f6fc35ec9f1 camera_root 04e331353b028c87e2804df20bdbea845fb03323d3c7ce9003807ff91925b49b
75ea92243ef5ba08 s3c_video_exp 5fb0de184fc0c95add07727cad833c23888e08229631354571d859d27c4b7b5b
7e1d4da7f8e209fb put_user_exp 0413e5743ef4e3c56bdb22c73c7436544219c2d8bea6f51c1aa24adab7262524
802df67ba2cf7d1b mvl_galcore_exp 8ba1ffc6fe8ce44bb778136dd2c27ccb62a951009769363811ca818a1ee14308
8f28646170a23ff2 exynos_abuse f52a96db49cd8acd6257237bff7b89f1cba755f9fb828ceb12a79a467d2b8405
97145f9a7d58647f s3c_fb_root c9676968ba0b891fbed8db0de8c9dbabb4265e5b7d95705c69c7b925d21f98b3
b19d38ccddca2eff mtk_m4u_exp c464e477daa5f2b8247764497c2f18c8d920bef7bea612f76b25e1477d5436a3
c78eedf55997bf88 futex_cheat_exp 950452471531c89488e28f8e8126d02741efed119c5f1224167fe38a1bf41980
e366af54946d116f mtk_vdec_exp b113ed4edec1cb99fbddca292eb247a773c84f68282cdd09f120ebadcc5c7a60
e45b79e67137d261 dev_mmap_exp e142db432bd6371a6c6eda27143ebbef3efd54f8fbe0ea986fd87d0f8c731681
f2c51886c67482bc common_root_shell fc2b9690b926f4878c717c5a2f986bad0b58f78b7f9b5b4173c4735adb6b00c7
f546e283a9229234 am_jpegdec_exp bcb4c0c6166a9d34a327e157cb12ca4df33d16e98b54ede25b71ed4f7bb7ae5d

SpyDealer 1.9.1, 1.9.2, and 1.9.3 also gain root privilege thought another method that doesn’t use “Baidu Easy Root” as detailed below:

  1. Drop files including sux, getroot, logo.png and busybox_g1 from assets to the app’s own data directory.
  2. Copy files sux, logo.png and busybox_g1 that are dropped in the above step to /data/data/ <package_name>/app_bin
  3. Generate shell script /data/data/<package_name>/app_bin/toor.sh with the content depicted in Figure 5.
  4. Execute png and toor.sh to gain root privilege, and these two files are deleted at the end.

Spydealer_4

Figure 5 Content of toor.sh

Readers should note that this second rooting method only targets Android versions from 4.0 to 4.3 (included). However, the exploits used in this attack remains unknown to us as none of logo.png, getroot or busybox_g1 exists in the app’s assets.

After gaining root privilege, SpyDealer takes steps to maintain persistence on the compromised device. It first drops a native executable file powermanager to its own data directory (Figure 6.) Once executed, powermanager creates a backup the app’s APK file to /system/bin/update_1.apk. Whenever the app is uninstalled (Figure 7,) the running powermanager will copy the APK file from /system/bin/update_1.apk to /system/app/Update.apk, resulting in the Trojan running as a system app (Figure 8.) After reinstallation, the core SpyDealer service (AaTService) is launched to perform malicious behaviors.

Spydealer_5

Figure 6 Drop and executes powermanager

Spydealer_6

Figure 7 Monitor the data directory and reinstall itself once got uninstalled

Spydealer_7

Figure 8 The malware copies itself to /system/bin/update_1.apk and reinstalls it to /system/app if uninstalled

Command & Control

SpyDealer is capable of receiving commands from remote servers via a number of different channels by either actively initiating connections to C2 servers or passively receiving instructions from C2 servers. These channels include via SMS, UDP and TCP connections. This section details how the malware utilizes each of these channels to communicate with the remote C2 servers.

SMS

SpyDealer registers a broadcast receiver with a higher priority than the default messaging app to listen for the commands via incoming SMS messages. The commands received through SMS are first decoded for further parsing and processing. Each SMS command contains a command index and arguments split by a newline. The command index ranges from 1 to 5 and each command is detailed in Table 3.

Table 3 SMS command list

Command Index Description
1 Get geographical location via GSM cell information.
2 Collect the contacts on the device and send back via SMS.
3 Gather SMS messages which are created later than a given date in the inbox, outbox and draft box, and then send back via SMS.
4 Exfiltrate call histories that are later than a given date through SMS. The collected information contains call duration, phone number and date time.
5 Set the auto reply phone number. The malware will automatically answer the incoming phone call when the number is the same as the set one.

To get the geographical location based on the GSM cell information, SpyDealer takes advantage of the interface of Baidu map service (Figure 9.) It first collects the GSM cell identity, area code and network operator and then posts the encoded data to the Baidu map service to retrieve the geographical location. With this tactic, a compromised device’s location is exposed to the attacker even there is no GPS available.

Spydealer_8

Figure 9 Utilize the interface of Baidu map service to get geographical location

Besides the commands listed above, SpyDealer can also set the remote server’s IP address under the following two conditions:

  • The length of the command index received in the SMS (Table 3) is larger than 4, then the command index is actually the remote server’s IP address
  • The incoming SMS message body starts with the string “L112 ” which is followed by the remote server’s IP address

If SpyDealer receives a command index of 1 or 2, it will not reply when it received an SMS command. However, if it receives a command index of 3, 4, or 5, SpyDealer will acknowledge that a command was received by sending back a specially formatted SMS response. For example, when received the command 5, it will automatically reply a message in the format “msg:repcall|<phone number>”.

All incoming SMS messages that contain commands will be aborted, which means the user will not be aware of these messages. However, other types of SMS messages will also be blocked if the malware is set to do so or the incoming number is in the blocking list.

TCP Server

SpyDealer creates a TCP server on the compromised device listening at port 39568 and waits for incoming commands. The command format and description are listed below in Table 4.

Table 4 Commands via TCP channel

Command Format Description
imei Send back the device IMEI
mobileinfor Send back device information including IMEI, IMSI and phone number
gettype\t1 Send back contacts information including contact name and phone number
gettype\t\t1 Send back SMS messages in inbox, outbox and draft box
gettype\t\t\t1 Send back call histories including phone call duration, type and date
listdir\t<directory> Send back the information of files under a given directory. The information contains file path, file size and last modified time.
Over Close the socket connection

The response data is formatted in the following pattern in bytes:

{0x35, 0x31, 0x64, 0x11, 0x09, <length of data>, 0x09, <data>}

However, there is no authentication mechanism implemented before accepting the incoming commands, which means anyone can connect to a compromised device and control it as long as one knows the target device’s IP address.

UDP/TCP Client

Aside from the TCP server that passively waits for the commands, SpyDealer can also actively connect to the remote server with the configured IP address to ask for commands through UDP or TCP. At first launch, the remote server’s IP address is retrieved from the local asset readme.txt, and the use of UDP or TCP protocols is determined based on another local asset named socket. The list contains around 90 different IP/domains that SpyDealer may use as remote servers. The full list of IP/domains can be found in Appendix B.

The command data received by the client is encrypted by the server using Tiny Encryption Algorithm (TEA) Once the client receives a command, the malware decrypts the data (Figure 10).  and then parses and processes the command. Through the UDP/TCP client channel, the attacker can fully control the compromised device with more than 45 different commands varying from private data collection, surveillance, and remote code execution.

Spydealer_9

Figure 10 TEA algorithm used to decrypt incoming command

Each command starts with the command followed by a newline character and the base64 encoded arguments. Table 5 details a full list of commands available through this channel. One interesting command is named SendMsg. Previously, Android malware could fake an incoming SMS message by exploit the Smishing vulnerability, which was patched in Android 4.2. To achieve this effect in newer Android versions, SpyDealer first inserts an SMS message into the inbox and then posts a notification indicating an SMS message has arrived. To our knowledge, this is the first malware family that fakes an incoming SMS message in this way.

Command Format Command Arguments Description
list\n\<cmd_id>\n<max_count>

\n<directory>

cmd_id: the command index;

max_count: max number of files to collect;

directory: target directory

List at most max_count files under the directory and send back the file name, file size and last modified time
searchdir\n<file_suffix>\t<time_range>

\t<size_range>

file_suffix: suffixes split by “,”,

time_range: start time and end

time split by “-”,

size_range: smallest and largest

file size split by “-”

Search files under external storage and send back the information of files that match the given suffixes, last modified time and file size
subloadfile\n\<file_path>\n

<cmd_id>\n<offset>\n<length>

file_path: the target file path;

cmd_id: command index;

offset: starting point of the file to read;

length: total number of bytes to be sent

Send back a limited content of specified file starting at a given offset
setsctm\n<time> time: number of seconds Set the screen taken interval time. A screenshot is taken every time seconds
getsctm Query the screen taken interval time
setmd5filter\n<file_md5> file_md5: MD5 hash value Set the MD5 filter which will be used to search for a file with the same MD5 value
getmd5filter Query the set MD5 filter
filemd5\n<file_path> file_path: the target file path Collect the file information of the given file_path including MD5, file name, file size and last modified time
loadfile\n<file_dir_path> file_dir_path: the target file or directory path Store the file or directory path that is ready to be uploaded
FinishDFile\n<file_dir_path> file_dir_path: the target file or directory path Store the file or directory path that is already uploaded
sysinfo Collect the compromised device information including phone number, Wi-Fi MAC address, network operator, screen display metrics, camera information, etc.
gsmlocation Get the geographical location based on the cell information
getpackets Collect the installed apps’ information including app name, package name, network packets received and transmitted by an app
queryremoteip Query the remote server’s IP address set previously
contact Get the contact name, phone number and thumbnail images
historycall Send back the phone call history including the phone number, contact name, date and phone call duration
getsms Retrieve all the SMS messages in the inbox, outbox and draft box as well as the MMS messages
set3gtrans\n<type>\n<config> type: indicates the type of configuration, Wi-Fi configuration is set if the value is wifi, otherwise set the 3G configuration

config: the configuration content

Set the configuration under Wi-Fi or 3G network and this configuration controls what actions the malware can do
gettransinfo Query the configuration set that indicates what kind of actions are enabled
SetGpstm\n<time> time: number of seconds Set the GPS location obtaining interval time
QueryGpstm Query the interval time to obtain GPS location
setremoteip\n<ip> ip: IP address of the remote server Set the remote C2 server’s IP address
FileConfig\n<file_name>\n<action_type>

\n<config_content>

file_name: a file is created under the app’s own data directory with the file_name

action_type: if the value is “set”, then the config content will be stored

config_content: configuration content that will be stored

Store the config_content into the file created under the app’s own data directory with the file name file_name
setautophone\n<phone_num> phone_num: phone number Set the phone number and the malware automatically answers the incoming phone call if the number is the same to the set one
getautophone Get the phone number set by the command setautophone
setabroadsms\n<phone_nums> phone_nums: phone numbers are split by the new line character Set the SMS message blocking list. The malware blocks the incoming SMS messages if the phone number is among the blocking list
getabroadsms Get a list of the blocking phone number list set by the command setabroadsms
setsocketmode\n<socket_type>   Set the communication protocol. The default one is UDP. If the socket_type is “t”, then the protocol is changed to TCP
SetBackIp\n<ip> ip: IP address Set the IP address of the backup C2 server
uninstall Uninstall the malware itself
ExecCmd\n<command> command: shell command string Execute the command with root privilege
getevnaudiostate Check the audio recording state which can be enabled or not
SendMsg\n<action_type>\n<phone_num>

\n<content>\n<date_time>

action_type: type of actions

phone_num: phone number

content: message body

date_time: date time string

If the value of action_type is “local”, the malware will insert a fake SMS message with the phone_num as source address and content as message body, and an incoming SMS message notification is posted. Otherwise, an SMS message with the content will be sent to phone_num
 
GetSControl\n Get some configurations such as if need to consume battery, test the network connection, etc.
ReGetApp\n<file_names> file_names: file names split by comma Delete .db files specified by the file_names one by one. The .db files are under /data/data/<package_name>/files/app/out
GetApp\n<package_names> package_names: app package names split by comma Upload app’s data files except libs. The target apps are determined by the argument package_names
StartRoot Try to execute exploits to gain root privilege
camvideo\n<camera_type>\n<duration> camera_type: front or rear camera

duration: duration time for each video to be recorded

Set the configuration for video recording. Use rear camera if camera_type is “back”, otherwise, the front camera is used to record a video. The duration argument specifies the duration of the video.
campic\n<camera_type> camera_type: front or rear camera Determine to use which camera to take a picture. The rear camera is used if camera_type is “back”.
GetPhoneNum\n<phone_num> phone_num: phone number Send the GSM location of the compromised device along with the remote server’s IP to the given phone number via SMS
DeleteFile\n<file_path> file_path: an absolute path of a file or folder Delete a file or folder under the malware’s own data directory.
SControl\n<cmd_type>

\n<cmd_argumetns>

cmd_type: numbers that indicate what type of commands should be executed

cmd_arguments: command arguments

Execute kinds of commands, for example, delete files, get Wi-Fi connection information, consumes battery, etc. All commands are detailed later in Table 6


Table 5 Commands through UDP/TCP Client

For the command type SControl, there are some sub commands determined by the cmd_type field, which is an integer number ranging from 0 to 10. All the sub-commands are detailed in Table 6.

Sub Command Type Command Arguments Description
0 Execute rm commands including “rm -r /system/app/”, “rm -r /data/app/”, “rm -r /system/bin/”, “rm -r /system/xbin/” with root privilege
1 app package names split by comma Remove apps’ data directory by executing the command “rm –r /data/data/<package name>” with root privilege
2 a string ends with “start” Continuously consumes the compromised device’s resource by doing floating multiplication and division
3 file suffixes split by comma Delete all the files on the external storage that match the given file suffixes
4 Enable the airplane mode on a device with the Android version < 18
5 a string ends with “start Test the network connection by sending a HTTP request to “http://www.163.com/”
6 file path Delete a file specified by the given file path. A file may be not removable because of the permission. With this in mind, SpyDealer first tries to delete the file via Java API File.delete, and then executes the “rm” command with root privilege
8 Collect the current connected Wi-Fi information as well as the history ones. The information contains BSSID, SSID, MAC address, network id, key management and password
9 a string ends with “start Continuously drain the compromised device’s power by doing floating division
10 Get the compromised device’s system information including IMEI, IMSI, Wi-Fi MAC address, phone number, etc.
99 src_file_path/n/dst_file_path Copy a file from src_file_path to destination dst_file_path

Table 6 Detail of SControl sub commands

The data sent back to the remote server is encrypted using TEA algorithm. Because UDP is a sessionless protocol by design, there is no guarantee that all transmitted packets will be received by the destination without any loss. To mitigate this risk, SpyDealer creates an effective session layer on top of UDP. SpyDealer divides the original data into multiple groups and each group has no more than 1000 bytes data. These groups are sent one by one and every transition is repeated three times. In order to restore the data at the server side, an additional identification code is added at the beginning of each grouped data. Hence, the format of the final group data is shown below:

MulPacket\n<IMEI>\n<UUID>\n<#TotalGroups >\n<CurrentGroupId>\n<Data>

  • IMEI: IMEI of the compromised device
  • UUID: This field consists of two parts. The first part is an integer starting from 0 and increases one by one for each transition. After reaching 10,000,000, it will be reset to 0. The second part is the current time in milliseconds
  • #TotalGroups: Total number of groups
  • CurrentGroupId: The index of the current group and it starts from 1
  • Data: The payload data

Private Data Collection

As discussed in section Command & Control, we have seen this malware employ many mechanisms to collect private data. Additionally, with root privilege, SpyDealer also tries to gather data from more than 40 common apps falling in different categories including social, communication, browser, mobile mail client, etc. The targeted apps are listed in Table 7.

ID Package Name App Name
1 com.facebook.katana Facebook
2 com.tencent.mm WeChat
3 com.whatsapp WhatsApp
4 com.skype.raider/com.skype.rover Skype
5 jp.naver.line.android Line
6 com.viber.voip Viber
7 com.tencent.mobileqq QQ
8 org.telegram.messenger Telegram
9 com.alibaba.mobileim Ali WangXin
10 kik.android Kik
11 com.icq.mobile.client icq video calls & chat
12 com.keechat.client KeeChat Messenger
13 com.oovoo ooVoo Video Call, Text & Voice
14 com.instanza.cocovoice Coco
15 com.bbm BBM
16 com.gtomato.talkbox TalkBox Voice Messenger
17 com.rebelvox.voxer Voxer Walkie Talkie Messenger
18 com.immomo.momo MOMO
19 com.zing.zalo Zalo
20 com.loudtalks Zello PTT Walkie Talkie
21 com.duowan.mobile 手机YY
22 im.yixin 易信
23 cn.com.fetion 飞信
24 com.sgiggle.production Tango
25 com.renren.mobile.android 人人
26 net.iaround 遇见
27 com.sina.weibo Sina Weibo
28 com.tencent.WBlog Tencent Weibo
29 org.mozilla.firefox Firefox Browser
30 com.oupeng.browser Oupeng Browser
31 com.android.browser Android Native Browser
32 com.baidu.browser.apps Baidu Browser
33 com.tencent.mtt Tencent QQ Browser
34 com.lenovo.browser Lenovo Browser
35 com.qihoo.browser Qihoo Browser
36 com.taobao.taobao Taobao
37 com.netease.mobimail NetEase Mail
38 com.tencent.androidqqmail Tencent QQ Mail
39 com.corp21cn.mail189 189 Mail
40 cn.cj.pe 139 Mail
41 com.baidu.netdisk Baidu Net Disk
42 com.l Smart Shopping List - Listonic
43 com.dewmobile.kuaiya Zapya
44 com.funcity.taxi.passenger Kuaidi Taxi

Table 7 The full list of the targeted apps

To gather sensitive data from above apps, SpyDealer first drops an executable binary named dealapp from local assets to the app’s own data directory and then copies it to /system/bin/dealapp with superuser privilege. The /system/bin/dealapp is then launched to gather kinds of data from target apps. The data to be collected is not only limited to database files, but also includes some configuration and other specific files. Table 8 listed some target apps and various directories, databases and files which the malware tries to access.

Table 8 Files which SpyDealer tries to access

App Name Files Accessed
Facebook /data/data/com.facebook.katana/databases/contacts_db2
WeChat /data/data/com.tencent.mm/MicroMsg/***/EnMicroMsg.db
WhatsApp /data/data/com.whatsapp/shared_prefs/RegisterPhone.xml

/data/data/com.whatsapp/shared_prefs/registration.RegisterPhone.xml

Skype /data/data/com.skype.raider/files/<account_name>/main.db
Line /data/data/jp.naver.line.android/databases/e2ee

/data/data/jp.naver.line.android/databases/naver_line

Viber /data/data/com.viber.voip/files/preferences/reg_viber_phone_num

/data/data/com.viber.voip/files/preferences/display_name

/data/data/com.viber.voip/databases/viber_messages

QQ /data/data/com.tencent.mobileqq/databases/*.db
Telegram /data/data/org.telegram.messenger/files/cache4.db

/data/data/org.telegram.messenger/shared_prefs/userconfing.xml

Kik /data/data/kik.android/shared_prefs/KikPreferences.xml

/data/data/kik.android/databases/kikCoreDatabase.db

icq video calls & chat /data/data/com.icq.mobile.client/databases/agent-dao
KeeChat Messenger /data/data/com.keechat.client/app_Parse/currentUser

/data/data/com.keechat.client/databases

ooVoo Video Call, Text & Voice /data/data/com.oovoo/databases/Core.db
BBM /data/data/com.bbm/files/bbmcore/ads.db

/data/data/com.bbm/files/bbmcore/files/

TalkBox Voice Messenger /data/data/com.gtomato.talkbox/shared_prefs/TalkBoxData.xml

/data/data/com.gtomato.talkbox/databases/*_conversations.db

Voxer Walkie Talkie Messenger /data/data/com.rebelvox.voxer/databases/rv.db
Zello PTT Walkie Talkie /data/data/com.loudtalks/shared_prefs/preferences.xml
Tango /data/data/com.sgiggle.production/files/userinfo.xml.db

/data/data/com.sgiggle.production/files/profilecache.db

/data/data/com.sgiggle.production/files/tc.db

FireFox Browser /data/data/org.mozilla.firefox/files/mozilla/browser.db

/data/data/org.mozilla.firefox/files/mozilla/cookies.sqlite

/data/data/org.mozilla.firefox/files/mozilla/signons.sqlite

Oupeng Browser /data/data/com.oupeng.browser/databases/bookmark.db

/data/data/com.oupeng.browser/databases/webviewCookiesChromium.db

/data/data/com.oupeng.browser/databases/webview.db

Android Native Browser /data/data/com.android.browser/databases/webviewCookiesChromium.db
Baidu Browser /data/data/com.baidu.browser.apps/databases/webviewCookiesChromium.db

/data/data/com.baidu.browser.apps/databases/flyflowdownload.db

Tencent QQ Browser /data/data/com.tencent.mtt/databases/webviewCookiesChromium.db

/data/data/com.tencent.mtt/databases/default_user.db

/data/data/com.tencent.mtt/databases/webview_x5.db

Lenovo Browser /data/data/com.lenovo.browser/databases/lebrowser.db

/data/data/com.lenovo.browser/databases/xldownloads.db

Qihoo Browser /data/data/com.qihoo.browser/databases/browser.db

/data/data/com.qihoo.browser/databases/downloads.db

/data/data/com.qihoo.browser/databases/webviewCookiesChromium.db

/data/data/com.qihoo.browser/databases/webview.db

NetEase Mail /data/data/com.netease.mobimail/databases/mmail
Tencent QQ Mail /data/data/com.tencent.androidqqmail/databases/AccountInfo

/data/data/com.tencent.androidqqmail/databases/QMMailDB

189 Mail /data/data/com.corp21cn.mail189/databases/preferences_storage
Baidu Net Disk /data/data/com.baidu.netdisk/databases/account.db
Zapya /data/data/com.dewmobile.kuaiya/databases/im_user.db

/data/data/com.dewmobile.kuaiya/databases/transfer20.db

The dealapp binary can also be updated from the remote server as shown in Figure 11.

Spydealer_10

Figure 11 dealapp update procedure

Accessibility Service Abuse

An increasing number of apps encrypt data before storing it into databases, especially for some popular communication and social apps. App developers do this to protect user data from malicious attacks like this one. To avoid this obstacle, starting in version 1.9.3, SpyDealer implemented an extra accessibility service to steal plain messages by directly extracting texts from the screen. Figure 12 depicts the accessibility service configuration in which the package names of targeted apps are declared.

Spydealer_13

Figure 12 Configuration of the accessibility service

Normally enabling the accessibility service requires the user’s interaction to manually go through the device’s settings. However, with root privilege, SpyDealer can silently enable the accessibility service without a user’s participation. The command used to enable the accessibility service is depicted in Figure 13.

Spydealer_14

Figure 13 Enable accessibility service silently via executing command with root privilege

With the accessibility service enabled, SpyDealer primarily listens for TYPE_NOTIFICATION _STATE_CHANGED and CONTENT_CHANGE_TYPE_SUBTREE events. A notification is posted when a message comes and this triggers the TYPE_NOTIFICATION_STATE _CHANGED event. Usually, a user will click the notification to view the message, which brings the detail view to the front. This behavior further fires the CONTENT_CHANGE_ TYPE_SUBTREE event. Once the CONTENT_CHANGE_ TYPE_SUBTREE event arrives, the malware starts to travel through the current screen to extract plain text messages. Although the number of messages is limited by the dimensions of the device’s screen, continuously monitoring the screen can help to extract the complete messages. After gathering the messages, SpyDealer sends them to the remote server (Figure 14) along with other information including IMEI, IMSI, package name and app name.

Spydealer_15

Figure 14 Send extracted data with other information to the remote server

Surveillance

SpyDealer is capable of surveilling a compromised victim through multiple means including recording phone call and surrounding audio, recording video, taking photos, capturing screenshots, and monitoring geographical locations. It takes these actions based on commands it receives from the command and control channels described above.

Record Phone Call and Surrounding Audio

SpyDealer registers a PhoneStateListener to monitor the phone call status. Once there is an active phone call, the audio recording procedure is triggered. The recorded audio data is finally compressed in zip format and stored to

/sdcard/.tmp/audio/<current_time_in_yyyyMMddHHmmss>_<phone_call_num><phone_call_ date>.zip

A message in the format “audio\n<IMSI>\n<IMEI>\n<zip_file_path>” will be sent to the remote server after audio is successfully recorded.

In addition to recording phone calls, SpyDealer is also capable of recording surrounding, ambient audio. It can be configured to record audio at a specific time range. The recorded audio file is stored to the following path in zip format

/sdcard/.tmp/environmentaudioaudio/<current_time_in_yyyyMMddHHmmss>.zip

Audio files recorded more than seven days ago are automatically deleted from the directory /sdcard/.tmp/environmentaudioaudio.

Record Video

SpyDealer checks to see if the camera is available to record a video every three seconds. In the Android system, a preview surface is required to take a video, which means the user is aware of the video recording event. To avoid this, SpyDealer intentionally sets a very tiny preview surface which, in this case, is 3.0dip * 3.0dip in dimensions. Each video is recorded for 10 seconds and is finally stored to

/data/data/<package_name>/files/cameravideo/<current_time_in_yyyyMMddHHmmss>.zip

If a network connection is available, SpyDealer sends a message in the format “cameravideo\n<IMSI>\n<IMEI> \n<zip_file_path>” to the remote server.

Spydealer_16

Figure 15 A tiny surface view is defined for recording video silently

Take Photos

Similar to recording video without a user’s awareness, this malware creates another tiny preview surface which is 0.100000024dip * 0.100000024dip in dimensions before taking a photo. Using the front or rear camera depends on the configuration which the attacker can set remotely. The taken photo is stored to

/data/data/<package_name>/files/camerapic/camera_<current_time_in_millseconds >.jpg

A message indicating a photo is taken is then sent to the remote server and the message is in the format “camerapic\n<IMSI>\n<IMEI>\n<picture_path>”.

Monitor Geographic Location

SpyDealer dynamically registers a broadcast receiver listening for screen’s status. Whenever the screen is turned off, it tries to get the geographical location via GPS. At the same time, a location listener is registered to track the device’s location. This location listener is notified with the updated location every 10 seconds or whenever 100 meters of movement occurs between location updates. If a network connection is available, the location data will be sent to the remote server in the format

LGPS\n<IMEI>\n<IMSI>\n<longitude>\n<latitude>\n<current_time_in_yyyy-MM-dd hh:mm:ss>

However, the location data is saved locally if there is no network connection and will be uploaded later when the connection is restored.

There is an icon indicating the usage of GPS on the status bar when the GPS is active. To avoid a user’s suspect, SpyDealer stops tracking the device’s location once the device’s screen is turned on.

Other Functionalities

Besides many powerful capabilities described above, SpyDealer is also capable of automatically answering an incoming phone call and dynamically loading plugins downloaded from the remote server.

If the incoming phone call is from a specific number, which can be remotely configured, this malware will simulate an earphone plugged event to automatically answer the phone call, which is detailed in Figure 16. With this functionality, SpyDealer can let the victim miss phone calls without their awareness.

Spydealer_17

Figure 16 Implementations of automatically answer an incoming phone call

Conclusion

SpyDealer makes use of the commercial rooting app “Baidu Easy Root” to gain root privilege and maintain persistence on the compromised device. It employs a wide array of mechanisms to steal private information. At the same time, it accesses and exfiltrates sensitive data from more than 40 different popular apps with root privilege. With accessibility service, this malware is also capable of extracting plain text messages from target apps at real time. To remotely control the victim device, the malware implements three different C2 channels and support more than 50 commands.

Customers of Palo Alto Networks are protected by our WildFire, URL filtering services, Traps for AndroidWildFire is able to automatically classify SpyDealer samples as malicious and AutoFocus users can track this malware using the SpyDealer tag. Traps for Android protects Android devices, it automatically intercepts malicious apps installed on the device by leveraging WildFire and protect the device from SpyDealer apps by blocking the app and notifying the user.

Acknowledgements

We would like to thank Claud Xiao and Ryan Olson from Palo Alto Networks for their assistance during the analysis.

Appendix A - IOCs

Samples of SpyDealer

ea472586b6f958fb79051aee5b7b7134dc37818b72ab97d1d542a9f94fdc63f7

9973133dcdaeea5a7d519359ba2272db5de9e9bb5759d169e0454632c3d91401

ec3b506c7fc80717d9ae19ca46ad2599d8d8d4880d6b980da03f054bbcf00cbd

e9a0b8b780999a64838c492b70032a076d052eb321c99d68ab1d230bd91d0100

4e4a31c89613704bcace4798335e6150b7492c753c95a6683531c2cb7d78b3a2

c39a2962c2734f6350cd45a399c58f203cd1b97aa12bec166a27c0fffc850280

13aa7fdf838a7c0bb79a805db25c99d75ccf4088b65c4e1f3741d3c467376faf

77c196544a2a778c63579f1a205ffd631b1999d69043679ab60b13cedc13db0e

d991e1ef7c8a502079d71e2d779b3ae8f081e2af9d1e2709f08b72a7de2a519e

1a941833df8434c7e96ca3cda4465f3cdbb6bd239e6bfd939eb603948b975cd7

b913bdb396d87c1f71073cdfef901697b512bd409c59447bcde1ddab07e5b7e6

e4604fc23d2c89707748e42c8ae8631b8e1db235ec3c9b2488dae4963de46b1a

8001e0258b13cd6971ef1d227cfc9c2f51036f1faf400cff7042fb099d1d11ab

 

The downloaded raw.zip which contains exploits stolen from “Baidu Easy Root”

 

cfd0a4f266a51c45ff7b33e5854bc62a49cfc769e62e1d73dd06ff92a7088f51

Appendix B - IP/Domain List of C2 Servers

IP Country IP Country IP Country
219.150.214.117 China 110.167.201.44 China 192.160.2.78 United States
222.208.85.119 China 116.52.154.114 China 124.117.219.254 China
124.117.237.46 China 116.53.130.192 China 203.156.200.214 China
61.186.137.213 China 218.10.2.237 China 220.171.99.118 China
222.82.238.70 China 222.82.253.110 China 121.26.229.201 China
202.103.207.227 China 218.65.18.193 China 222.82.228.134 China
219.146.144.162 China 222.86.225.194 China 121.12.154.233 China
124.117.249.126 China 117.40.226.57 China 124.117.246.78 China
202.97.135.68 China 222.82.250.62 China 124.117.254.194 China
59.48.105.14 China 61.166.10.147 China 120.68.194.138 China
59.33.110.101 China 124.117.238.62 China 47.88.100.148 United States
218.10.191.6 China 202.103.202.227 China 60.223.252.190 China
120.76.118.153 China 49.116.41.219 China 222.87.144.137 China
124.119.15.6 China 210.26.168.71 China 222.82.252.18 China
222.82.236.226 China 192.160.2.76 United States 218.84.75.243 China
125.46.78.60 China 222.82.229.66 China 120.76.118.53 China
120.68.46.150 China 218.58.124.146 China 222.172.200.200 China
58.242.244.70 China 218.84.35.39 China 124.117.249.170 China
124.117.232.114 China 222.82.252.138 China 124.117.212.218 China
221.212.235.46 China 222.82.230.202 China 118.122.180.173 China
124.235.96.235 China 120.77.177.167 China 222.88.154.148 China
60.30.134.99 China 222.82.230.146 China 120.68.203.46 China
222.82.250.122 China 124.117.218.218 China 220.167.224.171 China
60.164.210.48 China 222.82.210.250 China 222.88.118.104 China
218.31.175.32 China 27.191.191.2 China 124.117.249.26 China
124.117.217.194 China softupdate.eicp.net China 221.235.152.85 China
220.171.24.178 China 60.28.53.174 China 124.117.218.18 China
222.80.52.5 China 113.12.190.254 China 222.208.163.112 China
125.39.138.47 China 124.117.232.198 China 59.46.177.140 China
124.117.236.194 China

 

VIDEO: Tips, Tricks, and Clues to Escape the LabyREnth CTF

We’re halfway through Unit 42’s LabyREnth Capture the Flag (CTF) competition, and things are getting interesting. Malware reverse engineers and threat experts across the world are testing their technical skills in binaries, threat intelligence, programming, and more. Armor has been acquired, tears have been shed, cows have been spotted... Plus, puppies!

Have you escaped the LabyREnth yet?

We know many of you are still in the LabyREnth building security skills and solving challenges. Because we don’t want to leave you trapped in the maze, the LabyREnth creators put together a video and several writeups with some of their best tips, tricks, and clues for solving their security challenges. Check them out below.

All monetary prizes have been claimed, but you can still win electronics and challenge coins, so we encourage you to keep going. As always, good luck escaping the LabyREnth!

Documents 1 Challenge Hints

By: Jeff White

For this challenge, we’re given an RTF file called “find_bbz_challenge_file.rtf” and upon opening it we’re immediately greeted with a prompt to Enable Macros.

LabyREnth_Tips_1

Running it we see a message to double click an object with the Firefox icon to “Find BBZ”.

LabyREnth_Tips_2

Finally, double clicking this Firefox icon takes us to an image of David Bowie in a new document that is opened.

LabyREnth_Tips_3

The first thing I like to do when analyzing Word documents like this is to dig into the Macro source and try to understand what’s happening under the hood. I’ll focus on the “Document_Open()” function and follow the logic and debug the code.

Opening up the Visual Basic Editor we see the function under “ThisDocument” and it immediately does a check for the value of variable “wfozoV”; if it does not equal “bbz” then it launches a function “dLMNiMbhMkYVvgR”.

LabyREnth_Tips_4

Looking at this function shows some variables being set to the returned result of a call to “jlETByoSKP” with an array of integers and another integer.

LabyREnth_Tips_5

This second function appears to be a decoding routine and has familiar operations such as XOR and MOD.

Also of note is the MsgBox function right below the first variable that gets set. Typically, in CTF’s, a MsgBox is used to display the key or other pertinent messages so this is a good place to pause the debugger and see what’s happening.

LabyREnth_Tips_6

In the Locals window, you can see the decoded message. Given this, you should be able to decode the rest of the messages and take down the first level Documents challenge!

Binaries 1 Challenge Hints

By: Tyler Halfpop

We are given the following 3 files for this challenge.  Two of the files come up as data using the file command and look like they might be compressed or encrypted in a hex editor.  One of the files is a PE executable.  This is where you might want to start your analysis.

If you check the strings for MyFirstMalware.exe you will find the correct location to place the other two files in your virtual machine.

If you open MyFirstMalware.exe in a disassembler like IDA and find the main method pictured below you can see that a few of the calls are dynamically resolved.

LabyREnth_Tips_7

Figure 1 main method

The simplest method to determine what these calls are is to use a debugger and step through the program to see what is being called.  Most of the APIs in this challenge are resolved dynamically like this.  This is a common technique that malware authors use to try to make their code more difficult to analyze.

You will need to do something about the sleep call or you will be waiting for a long time.  The simplest method is just to change the parameter pushed to sleep to 1 and then nop out (0x90) the remaining bytes.

LabyREnth_Tips_8

Figure 2 Renamed functions and patched sleep call

Next you will encounter a few anti-analysis techniques that will set variables used for the file decryption.  You need to pass the checks correctly in order to get the correct file to decrypt and the correct password.  After the checks a string is built with the name of an executable, followed by a function that handles the file decryption.

LabyREnth_Tips_9

Figure 2 Disassembly Anti-Checks and Main Flow

After you are able to pass the checks correctly and decrypt the correct file it is injected into another process.  You will need to dump this executable in order to analyze it.  Set a breakpoint on WriteProcessMemory when you find it and then dump the memory pointed to by the third argument on the stack.

LabyREnth_Tips_10

Figure 3 WriteProcessMemory breakpoint showing MZ header

You can then start analyzing the dumped binary, which employs similar tricks.   You should be able to apply the same strategies used on the first binary to find the key.

Threat 2 Challenge Hints

By: Jeff White

If you played the CTF last year you’ll immediately be familiar with this challenge. We’re given a folder of 50+ malicious files and are tasked with creating a YARA rule to find a common, specific, function across the set. This is a common practice when analyzing threats and it allows you to find related samples which can then expand your overall knowledge of a given family.

The directions.txt file that comes with the samples gives us more insight into what’s required. Specifically, our rule will need to match the following syntax and will need to include 308 wildcard’s for a total of 298 byte matching hex-rule.

Typically, what I do in these scenarios is start with the smallest file possible as it must contain the function we’re interested in and will have less noise, then I’ll choose a larger file that will have more noise but should make finding similarities easier. For this example, I’ll use the below samples if you want to follow along.

Small (94KB) - 7f63e65ab460ff8ad607ede5bedb9573263015ba81824c3896f5416969353dba
Large (394KB) - c99b32b4bd6744311cdb357c8fa2210de6b79873f104a8f6268c2e60c606d330

There are a few methods to approach this problem and the most basic is a simple visual comparison inside a disassembler like IDA. You can compare the basic blocks and graph overview one-by-one to see if anything visually matches.

LabyREnth_Tips_11

Based on the image above, you can see neither of these functions match. At this point you can go down the list until something stands out but this can be extremely time consuming and prone to simple mistakes.

Another method for comparison is to use a tool like BinDiff and take advantage of its built-in “Similarity” scoring system to see if any basic blocks match.

LabyREnth_Tips_12

You can sort the results by Similarity and Confidence to focus in on blocks that appear to be shared between samples. This helps reduce the noise reduce the overall amount of time required.

If you open one of the high Similarity/Confidence blocks up, you’ll see a visual comparison similar to what we saw in IDA.

LabyREnth_Tips_13

In the above image, you can see two functions that are an exact match. If this was the correct size and what we’re after, we can grab the underlying hex bytes which make up the instructions and values. Looking at the hex in IDA we can build a rule based on this data.

LabyREnth_Tips_14

Where the MOV instruction is highlighted as “8B 54 24 08”. Our resulting YARA rule, for this one instruction, would then look like the below.

Rinse and repeat for the entire function until you have the rule. Keep in mind that the function size is 298 bytes so it’s fairly large.

The wildcards come into play when you consider things like offsets or values used by the instructions. In our above example, “MOV EDX, [esp+arg_4]” exists in one sample but what if in another sample it’s arg_B? In that case, the instruction could be the same but we need to account for this delta with a wildcard in YARA so that it still matches between the two.

Below is the same rule but with a wildcard that specifies ANY value here, assuming the rest match, will result in a match.

With 308 wildcards, you can bet the function you’re looking for is going to have a lot of different values!

Mobile 3 Challenge Hints

By: Tyler Halfpop

This challenge is an iOS app that was written in Swift.  If you look at the strings you might notice that there are what looks like some base64 encoded strings.

LabyREnth_Tips_15

The strings are base64 encoded and xor encoded with different keys.  We can use the Swift interpreter and these functions below to decode the strings.  After we decode the strings we can see what looks like a device name, some GPS coordinates, a device type, a decimal, a good job message, and a failure message.  You need to make sure you have the correct values for the environment checks in order to decrypt the key properly.

LabyREnth_Tips_16

If we look at the cross references for the example decoded good job message displayed above.  We can see that the function that references the string is called from a memory warning.  We can also see some functions related to AES encryption and crc32 algorithm.

LabyREnth_Tips_17

Programming 3 Challenge Hints

By: Richard Wartell

For the third challenge of the programming track, we’re given an IP address and port, as well as a hint that states: “The transition from first person to third person is real hard, especially when the game's a cheater...”. This hint refers to the first challenge from the programming track, which is a third person maze. This challenge is a first person maze in ascii art that you must solve in order to progress. When we connect to the challenge we see this:

LabyREnth_Tips_18

The challenge appears to take 4 possible moves: w for move forward, a for turn left, d for turn right, and s for move backwards. Now if we start moving through the maze a little bit, we start to realize that this game cheats. After walking for a while, we keep running into a wall.

LabyREnth_Tips_19

Disconnecting from the challenge and reconnecting allows us to start over, however this keeps happening. After walking for a while, we keep ending up at a dead end like the one below, as if the challenge is creating new walls as you play.

LabyREnth_Tips_20

The challenge here is to figure out how the game cheats, as it must be predictable in order to be solvable, and then get to the end of the maze where the key awaits.

Threat Brief: Petya Ransomware

Situation Summary

This Unit 42 blog provides an update on the threat situation surrounding attacks using the Petya Ransomware which are impacting organizations in Ukraine, Russia and to a lesser extent around the world.

On June 27th, 2017 we became aware of a new variant of the Petya malware which is spreading through multiple lateral movement techniques. One technique includes  the ETERNALBLUE exploit tool. This is the same exploit the WanaCrypt0r/WannaCry malware exploited to spread globally in May, 2017. At least 50 organizations have reported impacts from the malware, including government and critical infrastructure operators. Most impacted organizations are located in Ukraine, but global organizations with offices in Ukraine have seen the malware spread within their network across national borders.

Palo Alto Networks is documenting our prevention capabilities with regard to this threat in the Palo Alto Networks Protections for Petya Ransomware blog post. Windows users should take the following general steps to protect themselves:

  • Apply security updates in MS17-010
  • Block inbound connections on TCP Port 445
  • Create and maintain good back-ups so that if an infection occurs, you can restore your data.

This is a developing situation, we will update this blog as new information becomes available. AutoFocus users view samples using the Petya tag.

Attack Overview

Petya is a ransomware family that works by modifying the Window’s system’s Master Boot Record (MBR), causing the system to crash. When the user reboots their PC, the modified MBR prevents Windows from loading and displays a fake “chkdisk” screen which indicates the computer's hard drive is being repaired, but the malware is actually encrypting the user's files.  When this process completes, the malware displays an ASCII Ransom note demanding payment from the victim (Figure 1).

petya_1

Figure 1: Latest Petya Ransom note displayed on a compromised system.

The latest version of the Petya ransomware is spreading over Windows SMB and is reportedly using the ETERNALBLUE exploit tool, which exploits CVE-2017-0144 and was originally released by the Shadow Brokers group in April 2017.

After the system is compromised the victim is asked to send US $300 in Bitcoin to a specific Bitcoin address and then send an e-mail with the victim’s bitcoin wallet ID to wowsmith123456@posteo[.]net to retrieve their individual decryption key.  Posteo (a free e-mail provider) has already shut down this e-mail address, and as such victims should not even attempt to pay the ransom. As of 13:00 UTC on June 28thth, approximately 4 Bitcoin have been transferred to the attacker's wallet.

Unit 42 is unaware of ANY successful recovery after paying the ransom. Additionally, ongoing research by the industry is showing that specific actions this malware takes makes it technically infeasible, if not impossible, for recovery to occur.

This means that even though this malware is functionally ransomware, for threat assessment purposes, it should be functionally considered a “wiper”.

Attack Lifecycle

We are aware of the following information about how the Petya attack lifecycle works.

Delivery/Exploitation

We have not yet confirmed the initial infection vector for this new Petya variant. Previous variants were spread through e-mail, but we have not identified this latest sample carried in any e-mail related attacks.

While we have not been able to directly confirm the source, we have seen evidence that a Ukrainian software application called MEDoc was used by attackers to deliver the Petya DLL. The software is heavily used in Ukraine it appears the company’s systems may have been compromised and used to issue a malicious update to systems running the program on the morning of Jun 27th. This infection vector helps explain the high concentration of infections in Ukraine.

Installation

This variant of Petya is spread as a DLL file, which must be executed by another process before it takes action on the system. Once executed, it overwrites the Master Boot Record and creates a scheduled task to reboot the system. Once the system reboots, the malware displays a fake “chkdisk” scan which tricks the victim into believing the program is repairing their hard drive. In reality, the malware is encrypting the NTFS Master File Table in the background. Once the fake chkdisk completes, the malware displays a ransom note which demands a payment of $300 in bitcoin.

Command and Control

Petya contains no Command and Control mechanisms that we know of. After a host is infected, there is no communication from the malware back to the attacker.

Lateral Movement

Petya uses three mechanisms to spread to additional hosts.

  • Petya scans the local /24 to discover enumerate ADMIN$ shares on other systems, then copies itself to those hosts and executes the malware using PSEXEC. This is only possible if the infected user has the rights to write files and execute them on system hosting the share.
  • Petya uses the Windows Management Instrumentation Command-line (WMIC) tool to connect to hosts on the local subnet and attempts to execute itself remotely on those hosts. It can use Mimikatz to extract credentials from the infected system and use them to execute itself on the targeted host.
  • Petya finally attempts to use the ETERNALBLUE exploit tool against hosts on the local subnet. This will only be successful if the targeted host does not have the MS17-010 patches deployed.

Conclusion

Ransomware attacks are very common, but they are rarely coupled with an exploit that allows the malware to spread as a network worm. The WannaCry attacks in May, 2017 demonstrated that many Windows systems had not been patched for this vulnerability. The spread of Petya using this vulnerability indicates that many organizations may still be vulnerable, despite the attention WannaCry received.

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

Version Summary

June 27, 2017:

  • Initial Publication

June 27, 2017 – 1:08 PM PT

  • Updated Delivery/Exploitation section to include speculation about delivery through a compromised Ukrainian Tax software package.
  • Updated Lateral Movement section to describe additional mechanisms used to spread Petya.

June 28, 2017 – 8:40 AM PT

  • Updated summary to note the expansion beyond Ukraine and Europe
  • Added more detail to malware encryption process.
  • Updated Infection mechanism to specify the MEDoc software update delivery vector.

June 29, 2017 - 5:00 PM PT

  • Added more detail around recovery and “wiper” characteristics.

Paranoid PlugX

The PlugX malware has a long and extensive history of being used in intrusions as part of targeted attacks. PlugX is still popular today and its longevity is remarkable. The malware itself is well documented, with multiple excellent papers covering most aspects of its functionality. Some of the best write-ups on the malware are cited below:

Given this wealth of information in the public domain, PlugX receives a lot of attention from security vendors who put efforts into providing detection mechanisms for it. Despite this, it remains a tool of choice for many attackers today, meaning that if attackers are to be successful in using the malware, they must innovate in the delivery and installation of the malware if they are to successfully infect their targets.

This article discusses a group of PlugX samples which we believe are all used by the same attacker(s), and the measures they have taken to attempt to bypass security mechanisms. The targets of these attacks appear to primarily be companies in the video games industry, although other targets may exist outside of our telemetry.

Specifically, we discovered a series of samples using interesting techniques with respect to:

  • Resolution of an initial C2 address
  • Combining PlugX with open source tools to initially load the malware
  • Avoiding detection on disk

Palo Alto Networks defends our customers against the samples discussed in this blog in the following ways:

  • Wildfire identifies all files mentioned in this article as Malicious.
  • Traps 4.0 can be configured to protect the processes that are cited as being abused in this blog from loading malicious code.

Palo Alto Networks' AutoFocus customers can track samples related to this blog via the tag:

Related IOCs are provided in Appendix A of this blog.

An RTF, an MSI file, a .NET Wrapper and two stages of Shellcode walk into a bar...

Our journey begins with an RTF file named "New Salary Structure 2017.doc”, which exploits CVE-2017-0199.  The mechanics of this exploit are already well covered, and as such do not require further discussion here. The document reaches out to download its initial payload from the following URL:

hxxp://172.104.65[.]97/Office.rtf

This is a downloader script which attempts to download and execute two payloads, the code is shown below:

The first payload is a Windows Installer (MSI) file, and dynamic analysis of this file piqued out interest.   We could see the malware was PlugX from its actions, yet the C2 address was a pastebin.com URL. Looking at the Pastebin post we expected to immediately identify a block of text which would later decode to a C2 address, but glancing at the returned content we were unable to immediately identify the C2.

The second file is a PowerShell script which appears to be based on a Rapid7 Ruby Exploitation script that loads arbitrary shellcode. In this case, the shellcode is a copy of PlugX and is the same shellcode contained in the MSI file that we will dissect below.

.NET Wrapper

The main payload is delivered in a Microsoft .NET Framework file within previously mentioned MSI file. When executed, the .NET Framework wrapper will first check if VMware tools is running in background, this is done via a simple process check, searching for any process named “vmtoolsd.” Provided there are no matching processes running, the malware continues execution, creating a registry entry with the name ‘MSASCuiLTasks’ in HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce for persistence. This registry key causes the malware to run again each time the system reboots. Next, it will copy the first stage shellcode in memory and create a new thread with the shellcode running in it, the code responsible for this execution is shown in Figure 1. The shellcode is not encrypted but is obfuscated.

paranoid_1

Figure 1 - The main code from the .NET wrapper, with the Shellcode array being created and executed in a new thread.

The first shellcode decrypts a further shellcode block. This second shellcode block in turn, will unpack the main PlugX DLL in memory using RtlDecompressBuffer. As is typical for PlugX, the header of the final DLL is missing its magic DOS and NT image headers, which are replaced with XV instead of MZ and PE as shown in Figure 2.

paranoid_2

Figure 2 – The decoded DLL payload using the wrong header, XV instead of MZ/PE.

Finally, the second shellcode block will resolve the imports and relocations and jump to the entry point of the DLL.

Encrypted Configuration in shellcode

The configuration information for the malware, including the C2 information are encrypted in the first shellcode blob and are passed as an argument to the DllMain function of the main PlugX DLL. This DLL itself also contains a default configuration to connect to the localhost on port 12345. This means  if you extract the DLL manually and execute it then it will connect to localhost:12345 rather than the real C2 server, which was passed as an initial argument to the DLL by the first shellcode.

Decrypting the Configuration

As previously mentioned, the real configuration data is stored in the first stage shellcode but it is not stored in cleartext, but encrypted and compressed. The configuration data is encrypted with the same algorithm described previously by JPCert but using a different XOR value. The versions discussed in the JPCert blog post used 20140918, 353 while the versions we examined use XOR values of 20141118, 8389. The same decryption routine is also used for any other string obfuscation or file encryption as required by this sample of PlugX. After decrypting the strings, they must be further decompressed using LZNT1. For that we can use a Python script, included in Appendix B – Python Scripts.

After decrypting and decompressing the strings, we can trivially identify aspects of the PlugX configuration. For example, we can see it will inject itself to one these three processes:

  • %ProgramFiles(x86)%\Sophos\AutoUpdate\ALUpdate.exe
  • %ProgramFiles(x86)%\Common Files\Java\Java Update\jusched.exe
  • %ProgramFiles(x86)%\Common Files\Adobe\ARM\1.0\armsvc.exe

The attempt to inject itself into a process belonging to antivirus product suite is particularly bold.

In addition to this, the malware queries four PasteBin links to extract the C2 addresses from these links:

  • https://pastebin[.]com/eSsjmhBG
  • https://pastebin[.]com/PSxQd6qw
  • https://pastebin[.]com/CzjM9qwi
  • https://pastebin[.]com/xHDSxxMD

A full list of the extracted strings from the configuration is given in Appendix D – Extracted PlugX Strings.

Extracting C2

PlugX has a feature to extract encrypted C2 configurations from a given URL. In this case, the attackers were creative in hiding the string in a seemingly legitimate block of text. An example of the content retrieved from Pastebin is given below:

At first glanced we missed it, but the paste uses the same technique discussed in this Airbus post. It parses the "RSA key" looking for magic values "DZKS" and "DZJS". It then reads and decrypts the content between these values to yield an IP address as shown below:

A Python script to decode strings encrypted with this technique is given in Appendix B – Python Scripts.

An overview of the whole execution flow for this sample is given in Figure 3.

paranoid_3

Figure 3 - An overview of the execution flow for this sample.

In all, the attackers have chained together many disparate pieces of code both custom and open source, all in order to load PlugX. Given the number of components, this would have taken a reasonable amount of time and indicates their dedication to evading detection whilst continuing to use the same malware.

Pivoting to other PlugX samples

Based on our findings above, we identified other examples of interesting PlugX samples. These other examples were identified based on similar samples that were sent to the targeted organizations, infrastructure used by the attackers, as well as unique delivery mechanisms for samples.

Paranoid PlugX

One related series of PlugX samples we examined appeared to be particularly “paranoid” about being detected on disk and so taking specific anti-forensics steps to defeat being detected on the disk. One example of these samples is given below:

SHA256:6500636c29eba70efd3eb3be1d094dfda4ec6cca52ace23d50e98e6b63308fdb

The file is a self-extracting RAR, which is a common delivery mechanism for PlugX particularly when the eventual payload will be sideloaded by a legitimate executable. In that respect this case is no different, as the eventual payload executed by a legitimate signed Microsoft binary which loads the DLL “BlackBox.dll”. However, in order to kick off the execution of the malware the attacker uses a batch script which executes the malware, but the batch script does more than simply initiate execution of the malware. After running the malware, the batch script goes on to cleans up all signs of its existence on the system, this includes:

  • Deletion of all initial files created during installation, as well as all associated files required on disk during initial execution.
  • Deletion of all registry keys associated with the extraction of the SFX RAR
  • Deletion of the User Assist Key entries related to applications that have been recently executed
  • Deletion of all registry keys relating to services that have recently run

Clearly the attacker using this PlugX is paranoid about it being detected on disk, both in the registry and the file system. To top this off the script runs most of the deletion commands more than once.

The result is that there should be no evidence that the malware was ever executed on the disk, making it harder for forensics teams to identify how the malware got there, and meaning that memory or network based detection would be required to identify the intrusion. The full contents of the batch script are given in Appendix C – a.bat.

The power of open source & PlugX

In the first half of 2017, we saw attackers begin to improve upon this “Paranoid” version of PlugX – it wasn’t enough to be in memory-only after getting infecting the system, the attackers also wanted to bypass application allowlisting techniques in use by network defenders. To this end, they began incorporating open source techniques, in particular those that have been assembled in a list authored by the GitHub user SubTee. For example, the following sample loads the malware as shellcode within a .NET Framework project using msbuild.exe, effectively bypassing application allowlisting techniques:

SHA256: 822b313315138a69fc3e3f270f427c02c4215088c214dfaf8ecb460a5418c5f3

This sample approximately follows the GIST published here, but has additional code which appears to be custom to our attacker which acts as a helper to load the shellcode. The shellcode is, as in our first example, another PlugX payload.

In another case the attackers use another code snippet borrowed from the SubTee GitHub project, this time filling in a fully templated .NET application allowlist bypass file:

SHA256: 3e9136f95fa55852993cd15b82fe6ec54f78f34584f7689b512a46f0a22907f2:

This time the attacker didn't have to write any of their own code, instead they were simply able to paste their shellcode directly into a template, in order to launch PlugX as a child process of a trusted application.

Conclusions & Mitigations

While PlugX has been well understood by the security community for years, attackers continue to use the malware. Some possible reasons for this continued use include:

  • The operators of the malware are familiar and comfortable with the existing malware, meaning they are reluctant to change.
  • Though competent at packaging PlugX in different ways, the attackers would struggle to write a fully featured malware like PlugX.
  • The effort required to rebuild a malware as complex as PlugX is not worth the effort when they can bypass defenses without doing so.

In all likelihood, a combination of these three factors is behind the continued prevalence of the malware. Many PlugX attackers continue to use relatively mundane techniques to load the malware, making it easy for defenders to identify and prevent execution of the malware, but others continue to apply new and interesting techniques to evade detection.

In particular, this set of attackers have made good use of open source tools to package the malware, and show some skill in writing their own wrapper applications to execute payloads. Many in the security industry would be quick to recommend application whitelisting as one of the most effective way to reduce the success rate of attacks, however by applying publicly available techniques it is possible to bypass these controls.

For organizations relying on Application Whitelisting, SubTee’s blog makes a series of recommendations which help prevent these bypass techniques. In addition to these mitigations, the Traps 4.0 can be configured to protect the .NET processes which can be abused in this manner.

 

Appendix A - Related IoCs

Directly related:

45.248.84[.]7
172.104.65[.]97

SHA256 Comments
5909c1dcfb3270b2b057513561b2ab1613687a0af0072c51244ff005b113888b PlugX
6804be0689bbfbb180bb384ebc316f50cb87e65553d0c3597d6e9b6b6dd8dd3f PlugX
8ea275eee557037ab6626d15c0107bdcf20b45a8307a0dc3baa85d49acc94331 PlugX
e6020eb997715c4f627b6e6a16947861bce310aa31fcf58448a5beba11626d36 PlugX
4554aa6c2fdd58dfddebdb786c5d23cd6277025ab0355ffb5d8967c3976e8659 PlugX
3817388a983d5ee1604a8eec621b5eb251cb8bdeab9c8591fe5e8c90cd99ed49 CVE-2017-0199
45513f942b217def56a1eac82a4b5edca65ebdd5e36c7a8751bf0350d5ebea39 CVE-2017-0199
64d7d4846c5dd00a7271fe8a83aebe4317d06abad84d44ffd6f42b1004704bd5 PlugX
07d94726a1ae764fa5322531f29fe80f0246dd40b4d052c98f269987a3ee4515 PowerShell PlugX
4622f8357846f7a0bea3ce453bb068b443e21359203dfa2f74301c7a79a408c2 Downloader for PS PlugX ++ MSI PlugX
49baf12f50fec772fdfe56c49005efb306b72a312a7dbdad98066029a191bfaf CVE-2017-0199

 

https://pastebin[.]com/eSsjmhBG
https://pastebin[.]com/PSxQd6qw
https://pastebin[.]com/CzjM9qwi
https://pastebin[.]com/xHDSxxMD

Inferred relation via similar targeting

SHA256 Family
6e5864faf4312bf3787e79e432c1acacf2a699ecb5b797cac56e62ed0a8e965c Idicaf
6b455714664a65e2a4af61b11d141467f4554e215e3ebd02e8f3876d8aa31954 Idicaf
df58962a3a065f1587f543a501d0e3f0ca05ebac51fc35d4bb4669d8eac9d8c1 Idicaf
52fee36c647ca799e21cd75db1f425ccf632b28c27e67b8578ff6dd30ca62af7 Idicaf
90e45c7b3798433199d6d917a4847a409dbdc101b210d9798f8c78ee43abf6d8 Idicaf
5ff788efd079eb2987b03d98e0c8211ac97ae6479274bade36a170b5a396f72b Idicaf
535abe8cd436d6b635c5687db0ae8d47c7c3679e4f5e2b4d629276b41fca0578 Idicaf
ef85896426a0a558ab17346a67f108045d142a2d2a21f7702bfb8be50542726d Idicaf
d41e2bbc8ea10dd7543d5f4cb02983e2b1ad5d47cc3ce5fa95189501c019fdac Idicaf
208bd18054134909e2ad680c0096477c48a58e8754a9439002e6523f71e66d47 PlugX
3e9136f95fa55852993cd15b82fe6ec54f78f34584f7689b512a46f0a22907f2 PlugX
5deab61f83e9afe13a79930eda1bdcb6c867042a1ce0e5c44e4209a60ab3327d PlugX
6500636c29eba70efd3eb3be1d094dfda4ec6cca52ace23d50e98e6b63308fdb PlugX
8e07c7636be935e0a6184db8a85fd8b607e6c48bb07d34d0138432f7c697bc99 PlugX

 

Domains:

kbklxpb.imshop.in
serupdate.wicp.net
msfcnsoft.com
micros0ff.com
msfcnsoft.com
microsoff.net
msffncsi.com
A781195.gicp.net
upgradsource.com
B781195.vicp.net
kbklxp.eicp.net

 

Appendix B – Python Scripts

LZNT1 decrypt script, only works with Windows.

Decoding the PlugX configuration:

Decoding the C2 addresses from Pastebin:

 

Appendix C – a.bat

 

Appendix D – PlugX Extracted strings

The New and Improved macOS Backdoor from OceanLotus

Introduction

Recently, we discovered a new version of the OceanLotus backdoor in our WildFire cloud analysis platform which may be one of the more advanced backdoors we have seen on macOS to date. This iteration is targeted towards victims in Vietnam and still maintains extremely low AV detection almost a year after it was first discovered. Despite having been in the wild for an extended period of time, the operation appears to still be active. During our analysis, we were able communicate directly with the command and control server as recently as early June 2017.

While there seem to be similarities to an OceanLotus sample discovered in May 2015, a variety of improvements have been made since then. Some of the improvements include the use of a decoy document, elimination of the use of command line utilities, a robust string encoding mechanism, custom binary protocol traffic with encryption, and a modularized backdoor.

 

Infection Vector

The new OceanLotus backdoor is distributed in a zip file. While we don’t have direct evidence for the initial infection vector we presume it’s most likely via an email attachment. Once the user has extracted the zip file, they see a directory containing a file with a Microsoft Word document icon. The file is actually an application bundle, which contains executable code. (see Figure 1).  Once the user double clicks on the purported Word document, the Trojan executes and then launches Word to display a decoy document.

The malware uses the decoy document to help mask the execution of the malware. This technique is a common one for Windows-based malware, but rare on macOS. In order to achieve this layer of obfuscation, the malware author had to trick the operating system into believing the folder is an application bundle despite the .docx extension. Traditionally, macOS malware have emulated legitimate application installers such as Adobe Flash, which was how the previous version of OceanLotus was packaged.

oceanlotus1

Figure 1. Context menu and file listing

 

Once the application bundle is launched, it opens a hidden file in the bundle’s Resources folder named .CFUserEncoding which is a password-protected Word document (see Figure 2). It also copies this file to the executable path and essentially replaces the application bundle after persistence has been set up. This would lead the victim to believe that nothing was amiss, as they thought they were opening a Word document and a Word document opened. In this case, the Word file has the name “Noi dung chi tiet.docx”, which is Vietnamese for “Details.”

oceanlotus2

Figure 2. Decoy document prompts for a password to open the file

Persistence

Compared to the previous version of this backdoor, the persistence mechanism for this remained largely the same. This version creates a Launch Agent  that runs when the victim host starts up, where as in the previous version execution was upon when a user logs in. It also copies itself to a different location and filename based on the UID of the user who ran the application.

For a user other than root, it takes the MD5 hash of the structure returned by getpwuid() and breaks the hash down into segments <first 8 chars of hash>-<next 16 chars of hash>-<last 8 chars of hash>. This segmented MD5 hash is prepended with “0000-“ then used as a directory in ~/Library/OpenSSL/ to store the executable file (see Figure 3). If the user is root, the executable is stored in the system wide library directory at /Library/TimeMachine/bin/mtmfs.

It is interesting to note that the executable and plist locations look like legitimate applications.

UID plist Location Executable Location
0 /Library/LaunchDaemons/com.apple.mtmfsd.plist /Library/TimeMachine/bin/mtmfs
> 0 ~/Library/LaunchAgents/com.apple.openssl.plist ~/Library/OpenSSL/0000-<segmented MD5 hash>/servicessl

Figure 3. plist and executable names and locations based on UID

 

Once the malware has set up persistence, it deletes the application bundle from the executable path leaving the decoy document in its place and launches itself as a service from the new location.

No Command Line Utilities

One of the first things we noticed about this backdoor is the lack of suspicious strings which often times provides context as to what the malware might do on a victim host. In most macOS malware, calls to the system() or exec() functions  to run additional scripts are in place. In this case, these were not present nor were there command line utility strings that may easily convey the malicious intention of the application. This shows a deep level of understanding of the macOS platform by the author of this backdoor compared to other threat actors that will commonly copy and paste scripts from the Internet.

The lack of these strings may also double as an anti-analysis technique to make the malware seem less suspicious, especially to basic static analysis.

String Decoding

Since there appear to be no obvious suspicious strings in plaintext, we move onto the possibility of use of encoded, or obfuscated strings.

The string decode routine for this backdoor is an upgrade from previous versions in which strings were XOR encoded with the word “Variable” as a key. The string decode routine now consists of a combination of bit shifting and XOR operations with a variable key that depends on the length of the string that was encoded. If the computation for the variable XOR key turns out to be 0, the default XOR key of 0x1B is used. Figure 4 shows a Python implementation of the decode function.

oceanlotus4

Figure 4.  Python implementation of the malware’s string decode function

 

After decoding the strings (see Figure 5), we can glean that the malware sets up persistence, surveys the victim’s computer, and sends this information back to a server. At this point, it is still not obvious that this malware contains backdoor functionality.

oceanlotus5

Figure 5. List of decoded strings

Custom Binary Protocol and Encrypted Traffic

The threat actors responsible for this malware appear to have spent some amount of effort to develop their own custom communication protocol. They did not simply use an off-the-shelf web server for their command and control server, as is commonly done. Instead, they created their own command and control mechanism.

The backdoor uses a custom binary protocol on TCP port 443, a well-known port that is unlikely to be blocked by traditional firewalls due to its use in HTTPS connections. The packet seen in Figure 6 is encoded with a combination of bit shifting (see Figure 7) and XOR with a key of 0x1B before it is sent. The bits are always rotated to the left 3 times before doing the XOR operation. This is an improvement from the previous version where the packet was only XOR encoded with a key of 0x1B.

oceanlotus6

Figure 6. Initial packet sent by the client to the server

 

oceanlotus7

Figure 7. Bit shifting function used in the encode/decode routine for network packets

 

After decoding the packet, we can see a breakdown of different fields. Figure 8 shows the initial packet sent by the client to the server. It is relatively empty aside from the “magic” bytes, length of data and type of communication.

oceanlotus8

Figure 8. Initial packet sent by the client to the server (decoded)

 

Depending on the command response sent from the server, a packet may be bigger than 0x52 bytes. Data beyond 0x52 bytes is zlib compressed then encrypted with AES in CBC mode with a null initialization vector (IV) and a key sent from the server that is padded to 32 bytes.

We captured live traffic from the server, and observed that the encryption keys sent from the server are ephemeral. This means that each new session with the server is given a different key used to encrypt data sent back and forth within that session. This is a marked improvement compared to the previous version, where only XOR encoding with a one-byte key was used for encryption.

After decoding the packet it receives from the server, the backdoor validates certain fields like the “magic” bytes and makes sure the length of the data being received is not over a certain amount. Throughout the program execution, it also checks and handles any errors that may have been generated.

Command and Control Communications

The command and control server communication sequence is as follows:

  1. The client initiates a session with the server by sending a packet with 0x2170272 in the command field.
  2. The server then responds with an ephemeral encryption key and a command.
  3. The client checks if the received packet from the server is valid.
  4. The client executes the command sent by the server and responds with a zlib compressed and AES encrypted blob of the result then sends this back to the server.

Unlike the previous versions of OceanLotus where the commands can be easily gathered from its strings, the author has obfuscated the functions with constant values. We decoded the following available commands as seen in Figure 9.

Command Command Description
0x2170272 Initialize
0x5CCA727 ???
0x2E25992 receive file from server
0x2CD9070 get info on a file / directory
0x12B3629 delete file / directory
0x138E3E6 ???
0x25D5082 execute function from a dynamic library
0x25360EA send file to server
0x17B1CC4 ???
0x18320E0 send victim and computer information together with the backdoor’s watermark
0x1B25503 execute a function from a dynamic library
0x1532E65 execute a function from a dynamic library

Figure 9. List of commands available

Command 0x2170272

When the backdoor is launched, a file is created in /Library/Preferences/.files or ~/Library/Preferences/.files depending on the victim’s user ID. This file (see Figure 10) contains a timestamp and the victim’s name concatenated with the machine’s serial number which is then hashed twice with MD5. This is then copied to a buffer that is 0x110 bytes long and AES encrypted in CBC mode with a null IV and a key of “pth”. It is then saved into the file.


Timestamp + MD5(MD5(<victim’s name + machine serial number>))


After this file is created, the client sends its first packet to the server with 0x2170272 in the command field. The server acknowledges and responds with the same command and the client verifies that the file has been created.

 

\xa7\xf1\xd9*\x82\xc8\xd8\xfe4137674062B3226FE630C24F7DE1021E\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00

 

Figure 10. Decrypted contents of ~/Library/Preferences/.files

 

Command 0x18320E0

The server then sends this command with an ephemeral key shortly after it sends the 0x2170272 command. The client gathers all the data seen in Figure 11, encrypts it with the key provided by the server and sends it back. One thing to note is the Base64 string that is sent in this packet. This string is static in the binary and does not change, which may be indicative of a marker for campaign or version identification.

 

\x00\x00\x004137674062B3226FE630C24F7DE1021E\xe9\x0f\x00\x00\x00Mac OS X 10.X.X\xb6\x03\x00\x00

\x00username\t\x00\x00\x00localhost\x18\x00\x00\x00Ze0pXcpfbqbS4wD0eS/LVQ==\xb6\xbc\x1cY\x00\x00\x00\x00M\x00\x00\x00/Users/username/Library/OpenSSL/0000-ABCDEF01-23456789ABCDEF01-23456789/

servicessl\x8b\xbc\x1cY\x00\x00\x00\x00\x17\x00\x00\x00en0 : AA:BB:CC:DD:EE:FF[\x00\x00\x00lo0 : fe80::1\nlo0 : 127.0.0.1\nlo0 : ::1\nen0 : fe80::aaaa:bbbb:cccc:111\nen0 : 192.168.1.254

\x05\x01\x00\x00f\x00\x00\x00Model ID:iMac8,1\nCPU:Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz\nMemory:4.00\nSerial No:XXXXXXXXXXX\x00\x00\x00\x00

 

Figure 11. Decrypted contents of a packet sent by the client to the server

 

Not highlighted in Figure 11 but also included in this packet is the kernel boot time which may be used by the C2 server to help determine if the backdoor is being run in a sandbox environment.

 

Commands 0x25D5082, 0x1B25503, 0x1532E65

These commands load a dynamic library using dlopen() and obtains a function pointer to execute within that shared library using dlsym(). Unfortunately, we do not know which dynamic libraries or functions are used for each command since these are server supplied and we were not able to capture any communication that used these commands.

However, we can postulate that since the parameters to the functions have the same number of arguments with the first being a fairly large constant similar to the command constants, (see Figure 12) and the backdoor has a function for receiving files, it is possible that these functions correspond to a shared library that the server uploads to the victim host. This means that additional functionality can be added to this backdoor by loading modules directly from the C2 server.

oceanlotus12

Figure 12. Snippets showing loaded function pointers and their parameters

 

Conclusion

Most macOS malware in the wild today are not very complex, but threat actors have been quickly improving their tradecraft. The increased level of sophistication and complexity may be indicative of increased targeting of macOS hosts looking to the future. With this OceanLotus attack in combination with recent macOS versions of the Sofacy group’s toolset, we have now observed multiple espionage motivated threat actors targeting macOS. It is imperative that the same types of strong security practices and policies organizations use to defend Windows devices are applied universally to include macOS devices as well.

Apple has already updated the macOS protection systems to address this variant of OceanLotus.

Palo Alto Networks customers are protected and may learn more via the following:

  • Samples are classified as malicious by WildFire
  • Domains and IPs have been classified as malicious and IPS signatures generated
  • AutoFocus users may learn more via the OceanLotus tag

Indicators of Compromise

Hashes

b33370167853330704945684c50ce0af6eb27838e1e3f88ea457d2c88a223d8b  Noi dung chi tiet.zip

b3cf3e3b52b4b899cd0814fc75698ea24f08ce18642665adcd3555a068b5c16d  Info.plist

07154b7a45937f2f5a2cda5b701504b179d0304fc653edb2d0672f54796c35f7  Noi dung chi tiet

82502191c9484b04d685374f9879a0066069c49b8acae7a04b01d38d07e8eca0  PkgInfo

f0c1b360c0b24b5450a79138650e6ee254afae6ce8f6c68da7d1f32f91582680  .CFUserEncoding

e84b5c5152d8edf1e814cc4b4975bfe4dc0063ef90294cc96b383f523042f783  info.icns

 

C2 Server

call[.]raidstore[.]org

technology[.]macosevents[.]com

press[.]infomapress[.]com

24h[.]centralstatus[.]net

93.115.38.178

 

Dropped Files

UID == 0 UID > 0
/Library/LaunchDaemons/com.apple.mtmfsd.plist ~/Library/LaunchAgents/com.apple.openssl.plist
/Library/TimeMachine/bin/mtmfs ~/Library/OpenSSL/0000-<segmented MD5 hash>/servicessl
/Library/Preferences/.files ~/Library/Preferences/.files

 

Decline in Rig Exploit Kit

Starting in April 2017, we saw a significant decrease in Rig exploit kit (EK) activity after two major campaigns, EITest and pseudo-Darkleech, stopped using EKs. Figure 1 shows the hits for the Rig EK from December 2016 through May 2017, highlighting this trend.

This blog reviews recent developments in the EITest and pseudo-Darkleech campaigns that have contributed to the current drop in Rig EK. We also explore other causes for the overall decline of EK activity as others have noted in recent reports. Finally, due to the anemic nature of today's EK scene, we review some methods criminals are focusing on for malware distribution.

decline-in-rig_1

Figure 1: Hits for Rig EK from December 2016 through May 2017.

Two Major Campaigns Stop Using Rig EK

At the very end of March 2017, researchers stopped seeing indicators of the pseudo-Darkleech campaign. Pseudo-Darkleech was a long-running campaign that switched to Rig EK in September 2016. Since September 2016, pseudo-Darkleech accounted for a significant amount of Rig EK seen on a daily basis. When pseudo-Darkleech disappeared, Rig EK activity dropped approximately 50 percent from previous months.

Three to four weeks later, another long-running campaign cut back on its use of Rig EK. Near the end of April 2017, the EITest campaign began pushing tech support scams. Previously, EITest had also generated a great deal of Rig EK traffic, but as the criminals behind this activity began focusing on other techniques, Rig EK levels dropped another 50 percent in May 2017. As we enter June, EITest is primarily pushing tech support scams, and it does not appear to be utilizing EKs at this time.

Figure 2 shows the hits for Rig EK from March 1, 2017 through May 31, 2017 in more detail. Note on the chart when pseudo-Darkleech disappears and EITest shifts focus and their impact on Rig EK traffic.

Although researchers still find Rig from other campaigns like RoughTed or Seamless, recent levels are their lowest since we began tracking this EK.

decline-in-rig_2

Figure 2: Rig EK hits from March 1st through May 31st, 2017.

Not the Threat They Once Were

Rig is not the only EK suffering in today's threat landscape. All EKs have been affected. So why aren’t EKs as active as they once were?

One contributing factor is that the target surface for EKs is getting smaller.

EKs typically use browser-based exploits targeting Microsoft Windows systems. They are primarily focused on Internet Explorer, Microsoft Edge, and Adobe Flash Player. EKs are largely ineffective against more popular browsers like Chrome, a product that has gone through four major version updates this year alone.

Users (potential victims) are moving to other browsers, and this has greatly reduced the number of possible targets for current EKs. As shown below in Figure 3, as of May 2017, only 19 percent of the desktop browser market was taken by Microsoft Edge and Internet Explorer 11 combined.

decline-in-rig_3

Figure 3: Desktop browser market share in May 2017 from NetMarketShare.com.

With a declining target base, EKs are not aging gracefully. In previous years, we saw a variety of EKs used by various campaigns. But by the end of 2015, notable EKs like Sweet Orange and Fiesta had disappeared. As 2016 progressed, other prominent EKs like Nuclear and Angler also shut down. The graveyard of expired EKs has several dozen names by now.

This lack of diversity has impacted EK development. According to Proofpoint, more than a year has passed since any major EK has featured a zero-day exploit, making EKs far less effective compared to previous years.

Furthermore, the security community has been much more active against EKs. Recent efforts by Cisco Talos in 2016 and RSA Research in 2017 have seen researchers coordinating with hosting providers to take down servers used in domain shadowing schemes favored by EKs. The resulting setbacks have not been permanent, but they have significantly impacted operations for criminals using EKs.

Ultimately, a declining browser target base, lack of new exploits, and recent efforts by the community to fight domain shadowing have all contributed to an overall decline in EK activity.

What Are Criminals Turning To?

As EKs become more ineffective, criminals are focusing on other methods like malicious spam attacks, or social engineering schemes like HoeflerText notifications  like shown in Figure 4. Whether through spam or a browser popup, criminals trick potential victims into double-clicking a file that infects their computers.

decline-in-rig_4

Figure 4: A fake HoeflerText notification in Google Chrome that leads to malware.

In some cases, URLs will redirect to an EK one day and then on following days will often redirect to a fake installer for something like Adobe Flash Player like shown in Figure 5. These social engineering schemes are becoming more common, and researchers often run across them as they search for EKs.

decline-in-rig_5

Figure 5: Fake Flash installer distributing the same malware Rig EK did the day prior.

In some cases, criminals have turned away from malware entirely, and are focusing on apparently more lucrative activity. For example, the EITest campaign has switched to pushing tech support scams. At first, this seemed to be location-based, targeting the US and UK. However, as we go into June 2017, this type of activity is all we have found from the EITest campaign in recent days.

Figure 6 below shows a page viewed on June 7th, 2017 from a website compromised by the EITest campaign. The highlighted portion is a URL that redirects to a tech support scam website shown in Figure 7 that states your computer has been infected.

decline-in-rig_6

Figure 6: Injected script in page from a site compromised by the EITest campaign.

decline-in-rig_7

Figure 7: The tech support scam site.

This particular campaign also has audio continually reinforcing the same information. You cannot simply click okay or close the browser. The windows will immediately reappear. In order to close the browser and stop the audio, you must use the task manager to kill the browser process.

These tech support scams have been so successful that they are now a constant feature of our threat landscape. The EITest campaign has been pushing them for more than a month now.

Conclusion

Although EK activity levels are down, we still see indicators of Rig and Magnitude on a near-daily basis. But EKs are a relatively minor factor in today's threat landscape compared to social engineering schemes and malspam. Users who follow best security practices are much less likely to be affected by the EK threat.

However, this situation could change as new exploits appear and updated techniques are used in malware distribution. It always pays to be prepared. Threat detection, preventions, and protection solutions like Palo Alto Networks next-generation security platform are a key part of any prevention strategy.

LabyREnth CTF 2017 Launch Day: The Challenge Starts Now!

labyrenth_launch-image_2

The LabyREnth Capture the Flag (CTF) challenge is LIVE!

The goblins are at the gate and in this final hour it’s time for your many hours studying the blade, mastering the blockchain, and cultivating inner strength to be put to use. You’ll have until 4:00 p.m. pacific time on July 23, 2017 to test your mettle against the seemingly endless hordes of more than 25 security challenges.  Will you answer the call?

Whether you are an experienced researcher looking to win renown or a student just getting started, these challenges are built to surprise and show you something new. And if you’re among the first to complete the tracks, you could win a chunk of the $32,000 in cash prizes we’re offering this year. The CTF is open worldwide, including Palo Alto Networks partners.  Please refer to the official rules at LabyREnth by typing “rules" in the terminal.

These challenges bring together amazing learning opportunities for all levels across the security industry, all with serious prizes. Our goal is to drive threat intelligence education by sharing challenges based on the daily life of our engineers, helping improve skills and developing the next generation of analysts. By creating an avenue to build security skills, we’re making an effort to improve and strengthen the security community and our collective ability to defend against attackers.

Watch the @unit42_intel Twitter handle and #LabyREnth hashtag for updates and winners.

Can you escape the LabyREnth?

 

EMEA Bi-Monthly Threat Reports: United Kingdom, Germany & France

Intro

In December 2016 I posted the first of a two-part blog series, the second of which posted in April this year, to start a series of regular threat report updates to the public covering different sets of countries from around the EMEA (Europe Middle East and Africa) region. This blog is the first of a new series of bi-monthly threat reports that will focus only on one set of countries where before the series focused on two sets covering six or more countries. This new series will dig deeper into current trends, the threats affecting each country, and provide useful tips for mitigating these threats via our AutoFocus Threat Intelligence Service.

In my previous blogs, I introduced the EMEA region at a high-level– a large group of countries each with mixed languages, cultures, and cyber security maturity levels. Each also with different industry sectors and different economic profiles, which in turn creates a very diverse environment potentially ripe for cyberattacks.

The countries in this blog includes the United Kingdom, Germany, and France for the month of February.

Headlines

  • France, Germany, and United Kingdom: Cerber ransomware remains prevalent and replaced Locky as the #1 volume-wise.
  • France, Germany, and United Kingdom: Increase in malware that attempts to interact with digital currencies.
  • France and United Kingdom:  Uptick in Spora ransomware delivered over web-browsing application.

Trends

February by Country

We saw almost 120,000 total malicious sessions in AutoFocus in the three countries. Of these sessions, the United Kingdom received just over 70%; France just over 20% and Germany just under 10% of the volume. Despite the low session volume, Germany received the highest number of raw samples with nearly 50% of the total at 3,970 unique samples from the near 8,500 total. The United Kingdom received almost the same number of samples as Germany while France saw the lowest amount at just over 3,000 (35%).

The total session volume is some 50,000 less than the same three countries in December 2016 but the sample count in February was much higher with over 2,000 more samples compared to the previous time period.

Almost 50% of the aggregate samples and just over one third of the session volume in Germany can be attributed to the legacy – now some 13 years old – worm, MyDoom.

Figure 1 below shows the general trends of malicious sessions throughout the month of February for each country and highlighting the weekends where volume generally decreases. During the weekends, we tend to see less malspam inbound to organisations as people are not there to receive it and for the same reason, less outbound malicious session volume such as web-browsing. The United Kingdom’s most affected industry in terms of volume of malware sessions was Higher Education while both Germany and France’s most affected industry vertical was High Tech.

emea_1

Figure 1: Daily malware sessions by Country, February 2017

The proportion of malware sessions we observed in these countries could be due to a variety of reasons, such as different malware families in active operations, the number of existing compromised hosts, or even how the Palo Alto Networks® security platform is deployed.

February’s Top Malware

The following charts show the top malware by way of the highest number of unique samples seen targeting each of the three countries.

The charts clearly show overlap between the countries and the malware observed in the region. Pony, for example accounted for almost half of the malware in the United Kingdom and almost three-quarters of the top malware in France. MyDoom, on the other hand, dominated the German charts. Beyond MyDoom, Germany also saw a higher number of malware families that were present in the other countries as well. These included two ransomware families, Nymaim and RanserKD.

emea_3

emea_2

 

 

 

 

 

 

 

 

 

 

 

 

emea_4

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 2: Top Malware by Country, February 2017

February by application

Figure 3 plots the three countries in terms of malware volume delivered via different applications. The most common method for malware delivery were email protocols with SMTP, POP3, and IMAP being the highest combined volume of malware sessions by far. This is in-line for malware delivery activity globally. Based off these metrics, we can deduce that social engineering via specially crafted phishing emails is still a heavily used attack method.

The SMTP volume breakdown between the three countries indicates the UK received the most malicious sessions by far. The malware in the bulk of these SMTP sessions consisted of Pony and Cerber.

emea_5

Figure 3: Malware sessions by application by Country, February 2017

emea_6

Pony is a popular downloader program that can download additional malware onto the infected system. It is also equipped with a number of plugins that may be used to steal stored credentials for various applications such as FTP clients, web browsers, email clients, and other software. Pony is also commonly known as Fareit.

This commodity Trojan is common and often seen in high volumes throughout the world. Although this sparkline indicates what appears to emea_7

be a slight decline in February as compared to three to four months prior, the session volume still averages well over two thousand per day. For the three countries examined, the industries most targeted were Higher Education in the United Kingdom, Aerospace and Defence in France, and High Tech in Germany.

emea_8 emea_9

Globally, over the past six months, Cerber ransomware activity has been voluminous at over half a million sessions in total, much of which occurred in January and early February. Some individual days reached well into the tens of thousands of sessions. The industries most targeted included Higher Education in the United Kingdom, Government in France, and Wholesale in Germany.

Cerber is similar to many other ransomware families – using encryption, bitcoin ransom, and the TOR network for anonymity. It does have a few unique aspects not found in other ransomware however. Aside from the file extension ".cerber" used to indicate encrypted files, Cerber has conditional behaviour based on the language settings of the operating system. It will avoid infecting the following locales: Armenia, Azerbaijan, Belarus, Georgia, Kyrgyzstan, Kazakhstan, Moldova, Russia, Turkmenistan, Tajikistan, Ukraine and Uzbekistan. Cerber has been observed attacking databases as well as typical files. Infection methods are varied, including the use of malicious attachments in emails, malicious links, and the use of Exploit Kits. The Cerber malware payload uses a polymorphic model on its distribution servers making it very difficult for signature-based detection approaches to keep up with detecting all variants.

The following Figure shows a typical view of an system infected by Cerber including the ransom notice and support for the victim to get their files decrypted.

emea_10

Figure 4: Cerber Ransomware infection

emea_11 In France, we saw the highest volume of web-browsing sessions in February, followed by the United Kingdom and finally Germany. The majority of this volume in France was due to samples of Spora ransomware. Many ransomware attacks include a try-before-you-buy feature on their pay pages, where you can decrypt one or two files for free as an inducement to trust the crooks. Spora has many options such as: decrypt two files for free; decrypt a selection of files for $30; have the ransomware itself removed for $20; buy “immunity” for $50; and get a full restore for $120. Prices are quite low compared to other families that still charge one Bitcoin, which has almost doubled in value since the start of 2017 and is currently over the $2,000 USD mark. Spora seemed to appear on the ransomware scene earlier this year and since then as risen by hundreds if not thousands of sessions emea_12per day, indicating that it may be a threat that will be with us for some time. Many of the web-browsing sessions containing Spora ransomware use legitimate-sounding filenames such as “Chrome font v4.11.exe” that purport to be font files or other updates related to the Google Chrome web browser. Many sites hosting the malware appear to be compromised websites and in February, the majority of such sites were education-related, such as “edenhope.vic.edu[.]au/free.php”. The PHP (server side scripting framework used in web development) files often use filenames such as get, free, and info. The targeted industries globally are Higher Education followed by Securities and Investment Services. For the three countries examined, the industry most targeted was Higher Education.

Figure 5 shows a typical view of a system infected by Spora, showing the ransom notice and support details for the victim.

emea_13

Figure 5: Spora Ransomware infection

FTP as a malware delivery mechanism also deserves a mention as the activity remains quite high. This behavior has been ongoing for quite some time now, primarily due to the PhotoMiner malware I discussed in my last blog covering the EMEA region.

Threats

Country Specific

We can see further anomalies between the different countries, as Figure 6 below highlights. Despite the vast majority of malware families being common across all three countries and globally, there are some malware families, only in observed in one country. The following section describes each of these unique threats per country and shows their global trends for the last six months in the form of sparkline charts highlighting each malware’s peak and trend over the extended period.

emea_14

Figure 6: Unique malware families, by Country, February 2017

emea_15

Starting with the United Kingdom and the Nitol Trojan, which we have seen quite consistently over the past six emea_16 months, showing a spike of high volume towards the end of last year and slightly higher volume of traffic over the last two months. Nitol is a family of Trojans that perform DDoS (Distributed Denial of Service) attacks, allow remote access, download, and run additional files, and perform a number of other malicious activities on the victim host. In February, this malware was seen only in the Higher Education sector in the UK being downloaded with the filename “vip.exe”.

emea_17emea_18

The next threats only seen in the United Kingdom were PasswordFox and IEPassView both of which are command-line utilities allowing for the extraction of usernames and passwords saved in Firefox and Internet Explorer, respectively. Both utilities are developed by NirSoft as stand-alone tools to help with password recovery but as with such things, others find more nefarious uses for them.

Trends over the extended time period highlight a very similar pattern of volume globally between IEPassViewemea_19and PasswordFox emea_20

Despite sharing similar peaks, including the highest peak for both Trojans in the month of February itself, IEPassView has a higher average number of sessions per day at 7.5 compared to PasswordFox’s daily average of 3. IEPassView also accounts for almost three times the total volume during the extended time period compared to PasswordFox, indicating that targeting stored credentials in Internet Explorer may yield better results for the threat actors.

Session information reported in AutoFocus indicates that the attacks seen in February were targeting Senior lecturers and Professors at Universities in the United Kingdom using spear phishing emails with leading subject lines such as “RE:Bank payment receipt” and attached malware using file names such as “payment receipt order_February.scr”. All SMTP sessions originated from Nigeria with a mixture of sender email addresses including a potentially compromised business email address from a hotel chain based in the Middle East. AutoFocus does not relate these attacks to those detailed in our SilverTerrier white paper, however the objective of stealing credentials and information from victims is on par with other attacks originating from that region of Africa.

In Germany, two of the four top malware families observed are Android based, which is something not seen in previous threat reports produced over the last six to nine months.

emea_21

Android/SMSsend is a malicious mobile application that, once installed to your mobile device, reaps profit by silently sending SMS messages to premium-rate phone numbers increasing the bill from your provider.AutoFocus sessions indicate that some of the SMSsend samples seen were not being used in a malicious manner but instead uploaded to the internet to specialist websites that aid with the de-compilation of the Android app’s Dalvik byte code into source code. Given the source of these sessions – Higher Education – it’s highly likely the samples were being analyzed by students or faculty. Other sessions however do indicate potentially real cases of the malware being downloaded over web-browsing applications from sites that could be 3rd party app stores with less security restrictions.

Alternatively, these malware samples could have been delivered from compromised or other malicious websites where if a victim browsed the site from and Android devices a drive-by-download would occur. The app would then be automatically downloaded to the user’s device but not be installed automatically unless an exploit of some sort was used in conjunction. Often times, when the threat actor has no such exploit available they will rely on social engineering to lure the user into installing the app.

The sessions show Securities and Investment Services and High-Tech industries as those having the most SMSsend activity using file names such “FreeCola1.apk”. The trend for this malware globally over the extended time period shows a general decline since 6 months ago but clearly activity emea_22 persists.

chart-1

emea_23
The CTB-Locker family of ransomware is similar to the CryptoLocker family of ransomware as well as many other ransomware families. It encrypts files with specific extensions using a key retrieved from a server, requests ransom in Bitcoin and also uses the Tor network to further protect its operators’ identity and infrastructure. Globally the trend for CTB-Locker has been downward in emea_24the last six months, since the peak of activity about three months ago, and generally speaking we currently see approximately only fifteen sessions on average each day.

In Germany, the POP3 email sessions of CTB-Locker were primarily observed in the Hospitality sector, originating from Italy and using sender email addresses purporting to be from Telecom Italia or SDA (an Italian express courier company) with appropriate subject lines such as Fattura TIM linea Fissa - Gennaio 2016 scadenza 01/14/2016 (Invoice TIM Fixed Line – January 2016 deadline) and Partenza spedizione (Shipping Departure) respectively. Filenames of attached executables followed suite and used double extensions such as “.pdf.exe”, which is a highly suspect behavior.

emea_25

Meanwhile, in France, some of the unique malware families seen included an off the shelf keylogger – iSpySoftware – which is marketed to unsophisticated actors as a way to harvest credentials and other sensitive information from victims.

All SMTP sessions seen in February targeted the Higher Education sector and originated from China and Thailand. Globally there has been a slight resurgenceemea_26 in volume of late but nothing compared to the scale seen three months ago and prior.

emea_27Another malware family unique to France during February was CryptXXX. The group behind this project is the same as those driving emea_28 the legacy Reveton ransomware operations and is closely tied to Angler and Bedep operations. This malware has also been on a decline globally since five to six months ago and on average is seen in less than ten sessions per day. The number of sessions in France was low – less than twenty for the month of February.

emea_29

Another ransomware family seen exclusively in France in February was SamSa, also know as mokoponi. SamSa is different from most ransomware families in that it tends to target entire organizations versus individual endpoints. Instead of the indiscriminate methods used by most other contemporary ransomware families, leveraging mass malspam or phishing campaigns, SamSa attackers infiltrate the victim's network using network-based exploits or stolen credentials, and proceeds to install SamSa manually on individual hosts. SamSa will encrypt files using a provided RSA public key and demand either a large sum of Bitcoin in exchange for the recovery key to all victimized machines, or a small Bitcoin fee per infected machine.

Much of the activity emea_30 in the last six months surrounding SamSa happened two to three months prior to February where session volume peaked at over a hundred sessions per. Recently in February there has been a small uptick in activity.

chart2

Malicious Behaviours

As mentioned in my last blog on EMEA threat trends, malicious behaviours can be a powerful way of discovering new threats or suspicious applications in the network. The reason being that many malicious behaviours span across multiple malware families of the same type or even different types of malware, such as ransomware or a credential stealing Trojans. Persistence mechanisms, evasion techniques, or communicating channels  often times common between malware families. In this next section, we will investigate some of the most prevalent behaviours that were on the rise in the three studied countries in February as well as globally over the five months prior.

emea_31

emea_32 HttpNoUserAgent identifies applications that create HTTP connections but omit or use a blank user-agent. Typically, legitimate applications will include a user-agent value in HTTP requests to identify themselves to the receiving application. HTTP requests without the user-agent header, or with a blank user agent value, are may be suspect. This AutoFocus tag identifies these suspect samples, which have been continuously on the rise globally. Global session averages close to twenty thousand sessions per day.

emea_33

With digital currency values soaring, performing nefarious activities related to mining digital currency using victim CPU cycles or simply by stealing digital wallets through targeted credential theft are popular avenues for threat actors for financial gain. The AccessDigitalCurrency tag in AutoFocus reports applications seen in our Wildfire analyzer attempting to interact with known digital currencies, such as Bitcoin, Litecoin, and others. Malware will often seek out wallets for various digital currencies with the intent of stealing this data.

Globally, this type of malware as been on the rise as indicated by this sparkline. emea_34

emea_35

Image File Execution Options (IFEO) are used by developers for debugging applications on Windows. Malware will often check if debuggers are running when they infect a system as it may be an indication that someone is monitoring the system behaviour. This AutoFocus tag however is indicative of an application to setup itself up as a debugger for the system. The Windows operating system then enumerates application names and, when they run, launch the debugger (in this case the malware) at the same time. This provides the malware persistence on the system in case of reboot or application closure.

Globally the volume emea_36 of applications conducting this behaviour has averaged in the hundreds of sessions per day but in January and February this spiked to thousands and, in quite a few cases, in to the tens of thousands of sessions per day.

emea_37

Malicious Word documents often use VBA (Visual Basic for Application) macros to launch PowerShell scripts to perform malicious activity such as downloading payloads from the internet. This AutoFocus tag highlights when this behaviour is seen during WildFire analysis.

Globally, the volume emea_38 of samples conducting this behaviour is on the rise with some of the greatest volume to date being seen in February, where daily session numbers came close to breaking the one hundred thousand sessions per day mark. On the 20th February the session volume exceeded that, with over one hundred and twenty five thousand sessions. Given the earlier discussion about email-based malspam and phishing campaigns being so prevalent, it’s hardly any wonder this behaviour is growing so quickly as many attacks prefer weaponized Word and Excel documents that launch PowerShell.
emea_39Indicates where samples request a shortened URL provided by one of the many URL shortening services, which is leveraged often by malware to disguise potentially malicious web requests. In the six months prior to February the malware that typically had this behaviour appeared to be Adware related. The volume of sessions emea_40 peaked about two to three months ago but since then, session the volume has been quite consistent.

chart3

Conclusion

EMEA is a socially and economically diverse region with many interesting assets whether they be citizen data, financial information, or natural resources and, as such, is a target for cyber criminals the world over.

It’s probably no surprise to see ransomware as a prevalent malware crossing all borders into all countries as this malware is really victim-agnostic. Any data on any computer in any country is a viable target. We saw a slight change with one family, Spora, which made an appearance over the web-browsing application as opposed to the typical method of malspam over smtp.

Clearly information-stealing malware, such as Pony and tools, such as PasswordFox and IEPassView, are prevalent in countries that have a more service-based economy that manage and process plenty of user data and personally identifiable information (PII).

Cyber Hygiene

The threat landscape is vast and can be complex but you can minimize your risk of infection and enhance the overall health of your network by following some basic cyber hygiene habits:

Patch systems and applications wherever (and as soon as) possible. Alternatively, focus on other security solutions, such as exploit prevention technology to protect those systems and applications from attack or to help manage patching cycles to suit your requirements. Prioritize patching based on known exploits or in-the-wild-attacks. Segment those unpatched/unpatchable devices in the network with additional access controls based on users or application communication to minimize the risk of exploitation. Perform regular vulnerability scans of systems and review changes to spot new devices or changes in active vulnerabilities.

Change the file association for JavaScript to be opened using notepad (or something else benign) rather than the Windows Scripting Host or other shell capable of executing malcode. This can be done per PC or enterprise-wide using Group Policy. This will prevent many JavaScript-based threats from running in the context of weaponized documents.

Educate users and employees of the security risks faced by your organization and perform regular training and reminders about these and how they can help the effort. Provide a platform for users to learn about the risks and to report incidents to security-related staff. Create a culture whereby such reporting is important and valued. Monitor effectiveness of training for the purposes of gap analysis and creating dialogue between security teams and users.


Register for Ignite ’17 Security Conference
Vancouver, BC June 12–15, 2017

Ignite ’17 Security Conference is a live, four-day conference designed for today’s security professionals. Hear from innovators and experts, gain real-world skills through hands-on sessions and interactive workshops, and find out how breach prevention is changing the security industry. Visit the Ignite website for more information on tracks, workshops and marquee sessions.

LabyREnth CTF 2017: One Week Countdown

labyrenth_countdown

We’re one week away from the launch of the second LabyREnth Capture the Flag (CTF) challenge! It’s time to give all you players some more details on what you’re going to see next week.

We’ve got five tracks this year, and they’re a little different from last year. The skills we’ll be focusing on this year are the following:

  • Working with binaries (PE files, ELF files, Mach-O files, etc.)
  • Working with documents (MS Office Files, PDF Files, etc.)
  • Working with Mobile and IOT files (iOS, Android, ARM, MIPS, etc.)
  • Understanding the Threat Landscape (Yara, Networking, Intel, etc.)
  • Programming

While you’re in the LabyREnth, look out for some other challenges hidden throughout the CTF. Complete them quickly and you could win one of our individual first to solve prizes (tablets, VR equipment, etc.). Or just finish challenges in the five tracks to win some of the $32,000 in cash prizes we’re giving away this year! The overview, rules, and most importantly prize structure can all be seen at http://labyrenth.com.

We’ve selected these tracks and challenges as we believe they form the cross-section of skills necessary to be a solid security researcher. We’ll be revealing hints and more information about the challenges throughout the CTF. The countdown clock to the launch is running at http://labyrenth.com. We look forward to seeing you at 4pm PST on June 9!


Register for Ignite ’17 Security Conference
Vancouver, BC June 12–15, 2017

Ignite ’17 Security Conference is a live, four-day conference designed for today’s security professionals. Hear from innovators and experts, gain real-world skills through hands-on sessions and interactive workshops, and find out how breach prevention is changing the security industry. Visit the Ignite website for more information on tracks, workshops and marquee sessions.