SamSa Ransomware Attacks: A Year in Review

In March of this year, Unit 42 investigated the SamSa actors that were attacking the healthcare industry with targeted ransomware. With this group being active for roughly one year, we decided to revisit this threat to determine what, if any, changes had been made to their toolset. In doing so, we discovered that it’s been a very profitable year for SamSa, with an estimated $450,000 in ransom payments from samples we have identified. This blog serves to discuss changes made by this group and the SamSa malware family since we last discussed them.

Updates to Malware Toolset

In the past 12 months, Unit 42 has collected and analyzed 60 unique samples that have been identified as belonging to the SamSa malware family. SamSa has a very small number of samples overall when compared to more common ransomware families such as Locky, Cerber, and CryptoMix. This is simply a byproduct of the targeted nature of SamSa, which targets specific organizations instead of a wide number of Internet users.

During the past 12 months, a number of changes were made by the authors to make analysis and reverse-engineering more difficult. While we classify all of these samples as “SamSa,” the attackers have used various names to identify their projects. The following chart shows the various internal .NET project names used by SamSa from December 2015 until November of 2016.

samsa_1

Figure 1 Versions of SamSa Ransomware over time

The following list of internal .NET project names were witnessed, in order:

  • samsam
  • MIKOPONI
  • RikiRafael
  • showmehowto
  • wanadoesme
  • wanadoesme2
  • gonomore
  • gotohelldr
  • WinDir

The majority of the name changes took place after April of this year. When discussing changes made internally to the code base, we witnessed the following events since we last discussed SamSa:

samsa_2

Figure 2 SamSa modifications over time

  1. A number of internal .NET name changes, starting with RikiRafael.
  2. A number of changes to the encrypted filename extensions used after encryption took place.
  3. Changes to the format of the encrypted file header.
  4. Modifications to the dropped helper HTML file that informs the victim of what has occurred.
  5. Different temporary folder names used to hold SamSa while it is running.
  6. Encryption of embedded strings using the AES-128 algorithm.
  7. Internal PDB debug strings obfuscated.
  8. Internal PDB debug strings removed altogether.

Profits

When we originally discussed SamSa, there were confirmed profits of $70,000 for the threat actors, with estimates by other researchers as high as $115,000. Unlike most ransomware, SamSa ransomware executables often contain the Bitcoin Wallet address victims are supposed to use to pay the ransom. Since March 24th 2016, we’ve witnessed 24 unique SamSa samples containing 19 unique Bitcoin (BTC) addresses. This allows us to monitor the blockchain for transfers to those wallets and identify ransom payments.  In one unusual case, we saw a version of SamSa where the BTC address was input as a second argument, preventing us from seeing what payment, if any, was received by the actors. This not only makes tracking monetary payments extremely difficult, but also is yet another example of how the SamSa actors take a very targeted approach to their victims, generating unique data for each victim they infect.

Of those 19 unique BTC addresses we observed since March 24th, 14 of these have received payments totaling roughly 394 BTC. Prior to March 24, 2016, we observed roughly 213 BTC received, giving us a total of 607 BTC received by the SamSa actors. Using today’s current BTC rate of $744.43, this allows us to estimate that the attackers have obtained roughly $450,000 since their operations began. It’s important to also note that there are likely a number of samples that exist, which we were unable to obtain, causing the actual figure to likely be much higher. A visual of the money obtained by the SamSa actors can be seen in the following figure:

samsa_3

Figure 3 SamSa BTC profits over time

As we can see, there is a large gap in between June and September of 2016. This is most likely due to the sample set used during research, as there were only a few samples obtained in recent months.

Conclusion

In the past year, the SamSa actors have showed no sign in stopping their attacks. They’ve successfully compromised a number of organizations, and continue to reap significant rewards for their efforts. In the past year alone, they’ve collected an estimated $450,000 from their scam. As the group continues to make money, it is unlikely we shall see them stop in the near future. Palo Alto Networks customers are protected from this threat via the following ways:

  1. All malware is classified as malicious in WildFire.
  2. Domains used by SamSa have been flagged as malicious in Threat Prevention.
  3. AutoFocus users can track this family using the SamSa tag.

A full list of indicators of compromise (IOCs) related to SamSa can be found here.

Shamoon 2: Return of the Disttrack Wiper

In August 2012, an attack campaign known as Shamoon targeted a Saudi Arabian energy company to deliver a malware called Disttrack. Disttrack is a multipurpose tool that exhibits worm-like behavior by attempting to spread to other systems on a local network using stolen administrator credentials. More importantly, its claim to fame is the ability to destroy data and to render infected systems unusable. The attack four years ago resulted in 30,000 or more systems being damaged.

Last week, Unit 42 came across new Disttrack samples that appear to have been used in an updated attack campaign. The attack targeted at least one organization in Saudi Arabia, which aligns with the targeting of the initial Shamoon attacks. It appears the purpose of the new Disttrack samples were solely focused on destruction, as the samples were configured with a non-operational C2 server to report to and were set to begin wiping data exactly on 2016/11/17 20:45. In another similarity to Shamoon, this is the end of the work week in Saudi Arabia (their work week is from Sunday to Thursdays), so the malware had potentially the entire weekend to spread.  The 2012 Shamoon attacks took place on Lailat al Qadr, the holiest night of the year for Muslims; another time the attackers could be reasonably certain employees would not be at work.

Composition of Disttrack

Disttrack is comprised of three distinct parts: the dropper, communications and wiper components. The main Disttrack executable is a dropper that extracts additional tools from embedded resources and coordinates when to save and execute them. Embedded within each Disttrack sample is a component responsible for communicating with a C2 server and a separate component used to carry out the wiping functionality.

The dropper extracts the communications and wiper components from resources named "PKCS7" and "PKCS12" respectively, while the x86 sample extracts the x64 variant of Disttrack from a resource named “X509”. To extract the components, the dropper is configured to seek specific offsets within the resource, read a specified number of bytes and decrypt the contents using a specified key. The key exists in the sample as a base64 encoded string that the dropper will decode then use each byte of the resulting string to XOR the data obtained from the resource. When determining the location of the ciphertext within the resource, the dropper subtracts 14 from the offset value in the sample's configuration as an additional layer of obfuscation. Table 1 shows the resources within the Disttrack x86 sample, the component it contains and the values needed to decrypt its contents.

Component Resource Name Offset Size Base64 key
x64 Variant X509 812 -14 = 798 717312 5tGLQqku0m02...
Communications PKCS7 879 -14 = 865 159744 UPi0IzQOAyiL...
Wiper PKCS12 792 -14 = 778 282112 3Lmqr/nJgzFZ7...

Table 1 Resources containing Disttrack components

Disttrack Functionality

Disttrack is mainly focused on data destruction and attempting to damage as many systems as possible. To do so, this malware attempts to spread to other systems on network using what are likely stolen administrator credentials. This is again similar to the 2012 Shamoon attacks, where compromised but legitimate credentials obtained in advance of the attacks were also hard coded into the malware to aid in its propagation. Disttrack also has the ability to download and execute additional applications to the system, as well as remotely set the date to start wiping systems.

Local Network Spreading

The Disttrack malware spreads to other systems automatically using stolen credentials. The Disttrack we analyzed contained the internal domain names and administrator credentials associated with the targeted organization. The internal domain and credentials appear to be stolen prior to the creation of this tool, as it is not a public domain and the credentials are not weak enough to have obtained through guessing, brute force or dictionary attacks.

Disttrack uses the internal domain names and credentials to log into remote systems on the same network segment. The malware determines the local network segment associated with the target system (call to gethostname) by obtaining the IP address for the system (call to gethostbyname). It then uses the system's IP addresses to enumerate the /24 network (x.x.x.0-255) that the system is networked with, and will attempt to spread to each of these remote systems.

The dropper then attempts to open the service manager on each remote system to start the RemoteRegistry service, which it will connect to using RegConnectRegistryW. Once connected, the dropper attempts to disable UAC (User Access Control) remote restrictions by setting the following registry key to a value of "1":

SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy

After disabling UAC, the dropper connects to the remote system (using NetUseAdd) and logs in using the embedded stolen credentials. The dropper then checks to see if it has administrator privileges on the remote system by attempting to open "\system32\csrss.exe", which allows it to determine if it can write its payload to the "\system32" folder on the remote system. The dropper then has two different methods in which it can pivot to the remote system.

The first method involves the dropper writing itself to "\system32\ntssrvr32.exe" on the remote system. After writing itself to the remote system, the dropper creates a service named "ntssrv", with a display name of "Microsoft Network Realtime Inspection Service" and a description of "Helps guard against time change attempts targeting known and newly discovered vulnerabilities in network time protocols" to execute the payload.

The second, alternative method also involves the dropper copying itself to "\system32\ntssrvr32.exe" on the remote system; however, instead of creating a remote service, this method calls the NetScheduleJobAdd function within the Windows netapi32 library to create a scheduled task to run the payload. Scheduled tasks require a time in which the task will run, which the dropper determines by calling the function NetRemoteTOD to obtain the time of day from the remote system. The dropper then adds 90 seconds to the time of day value on the remote system and uses this value as the "JobTime" to run the task in three minutes, which executes the payload on the remote system. The following pseudo-code shows the scheduled task creation process:

C2 Communications

Disttrack extracts the communication component from its resource named “PKCS7”, decrypts it and saves the resulting cleartext to the file %WINDOWS%\system32\netinit.exe.

The communication module interacts with its C2 server using HTTP requests. The communications modules in both the x86 and x64 variants of Disttrack we analyzed were configured to use “1.1.1.1:8080” for its C2 server, which does not host an operational Disttrack C2 server. The lack of an operational C2 server suggests that the threat actors did not desire remote access to infected systems, rather the actors sought to render them unusable instead. If the modules were configured with an operational C2 server,  the module would generate an HTTP GET request that resembles the following:

shamoon_1

The interesting part of the request above is that the host "server", the URL "category/page.php", the parameter "shinu" and the user-agent "Mozilla/5.0 (MSIE 7.1; Windows NT 6.0)" are hardcoded into the tool. The data in "shinu" parameter is a combination of the system's tickcount, local IP address, operating system version, keyboard layout and the contents of %WINDOWS%\inf\netimm173.pnf. The C2 server can respond to this HTTP request with one of the following two commands:

Command Description
E Provides an executable to run on the system. The executable is saved to %TEMP%\Temp\filer\<tickcount>.exe
T Sets the time to start wiping the system, by writing the date to %WINDOWS%\inf\usbvideo324.pnf.

We believe the HTTP host value of "server" and the non-operational "1.1.1.1" C2 address may suggest that the communication module is created with a builder tool, which in this case the actor mistakenly or purposefully did not provide an active C2 server when building this module. While completely speculative, the word “shinu” used as a parameter could be a reference to the Arabic slang for the word “what”, as well as a reference to a village name in northwestern Iran.

Disttrack Data Destruction

The Disttrack dropper is responsible for installing the wiper component of this Trojan, however, it will only activate this component if the system time is greater than a preset date. The dropper obtains a date used to activate the wiping functionality by reading a specific file, or using a hardcoded timestamp of "2016/11/17 20:45". The file containing this timestamp is named "\inf\usbvideo324.pnf", which is not initially installed but is provided by the C2 server if it sends the communications module the "T" command. The "usbvideo324.pnf" file would have the following structure:

BYTE year;
BYTE month;
BYTE day;
BYTE hour;
BYTE year;
BYTE minute;

If the dropper determines the system date is larger than the specified date, the dropper will extract the wiper component from a resource named "PKCS12" and save it to the "system32" folder with one of the following filenames appended with a ".exe" extension:

  • caclsrv
  • certutl
  • clean
  • ctrl
  • dfrag
  • dnslookup
  • dvdquery
  • event
  • findfile
  • gpget
  • ipsecure
  • iissrv
  • msinit
  • ntfrsutil
  • ntdsutl
  • power
  • rdsadmin
  • regsys
  • sigver
  • routeman
  • rrasrv
  • sacses
  • sfmsc
  • smbinit
  • wcscript
  • ntnw
  • netx
  • fsutl
  • extract

The dropper then runs the wiper component with a command line argument of "1". The wiper component extracts a driver from its resource section and decrypts it with a 226 byte XOR key. The wiper saves the extracted driver to "C:\Windows\System32\Drivers\drdisk.sys" and installs the kernel driver by creating a service named "drdisk" with the following command line commands:

The kernel driver is a commercial product that the attackers are abusing called RawDisk by EldoS Corporation, which provides direct access to files, disks and partitions. It appears that the “drdisk.sys” driver (SHA256: 4744df6ac02ff0a3f9ad0bf47b15854bbebb73c936dd02f7c79293a2828406f6) is the exact same driver as used in the Shamoon attack in 2012. With the kernel driver installed, the wiper can begin writing to protected system locations, such as the master boot record (MBR) and partition tables of storage volumes. The wiper can be configured to overwrite files in three different ways, specified by a configuration setting of "F", "R" or "E". If configured with the "F" setting, the wiper loads a resource named AJKEOA, which extracts a JPEG image to use to overwrite files and partition tables. If the wiper is configured with the "E" setting, the wiper will encrypt the contents of the file using a random value as a key and the RC4 algorithm. If configured with the "R" setting, the wiper will overwrite files with the random values that would be used as a key in "E".

The sample we analyzed was configured with "F", meaning it would overwrite files with an image obtained from its resource section. The image extracted is a picture of a Syrian boy named Alan Kurdi, whose drowning on September 2, 2015 received international attention in regards to the ongoing Syrian refugee crisis. The previous Shamoon attack in 2012 used an image of a burning American flag, continuing the political image theme.

From a functionality standpoint, the wiper relies on EldoS' RawDisk driver to overwrite files on the system. During this activity, we noticed the wiper changing the system time to August 2012, as the temporary license key for the RawDisk driver requires the system time to not exceed the month of August, which is when the temporary license would expire. This modification to the system time was seen in the previous campaign, and the temporary license key within the wiper component is the exact same as wiper component from the 2012 attacks. The wiper itself queries the following registry keys to obtain a list of partitions to overwrite:

In addition to these partitions, the wiper attempts to overwrite files and subfolders within in the following folders:

After overwriting these files and the partition tables, the wiper issues the following command to restart the system:

The arguments and switches used in the “shutdown” command above forces all running applications to close and causes the system to reboot (‘-r’) after 2 seconds (‘-t 2’). This command does result in a dialog prompt, seen in Figure 1, that informs the user that the system is shutting down.

shamoon_2

Figure 1 Dialog prompt displayed when the Wiper component runs the 'shutdown' command

With the partition tables overwritten, the system will no longer be able to properly boot, which renders the system unusable. During analysis, our analysis system was rendered unusable, as the virtual machine was unable to find the operating system during boot up, as seen in Figure 2.

shamoon_3

Figure 2 Analysis virtual machine unable to boot after executing Disttrack Wiper

Conclusion

After a four year hiatus, threat actors likely associated with the Shamoon attack campaign have used their Disttrack malware to target at least one organization in Saudi Arabia. The current attack campaign has several TTP overlaps with the original Shamoon campaign, especially from a targeting and timing perspective. Also, Disttrack malware used in the recent attacks is very similar to the variant used in the 2012 attacks, which uses the exact same RawDisk device driver as well (down to the same, temporary license key).. The main purpose of the Disttrack malware is to overwrite files and storage partitions in an attempt to destroy data and render the system unusable. To maximize its destruction, the Disttrack tool attempts to spread to other systems on the network using stolen administrator credentials, which suggests that the threat actors had previous access to the network or carried out successful phishing attacks prior to the attack using Disttrack.

Palo Alto Networks customers are protected from Disttrack:

  • All known samples have a malicious verdict in WildFire
  • AutoFocus customers can monitor Disttrack activity via the Disttrack tag

Indicators of Compromise

Disttrack Droppers

47bb36cd2832a18b5ae951cf5a7d44fba6d8f5dca0a372392d40f51d1fe1ac34 (x64)
394a7ebad5dfc13d6c75945a61063470dc3b68f7a207613b79ef000e1990909b
(x86)

Communication Components

772ceedbc2cacf7b16ae967de310350e42aa47e5cef19f4423220d41501d86a5 (x64)
61c1c8fc8b268127751ac565ed4abd6bdab8d2d0f2ff6074291b2d54b0228842 (x86)

Wiper Components

c7fc1f9c2bed748b50a599ee2fa609eb7c9ddaeb9cd16633ba0d10cf66891d8a (x64)

128fa5815c6fee68463b18051c1a1ccdf28c599ce321691686b1efa4838a2acd (x86)

EldoS RawDisk Samples

5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a (x64)
4744df6ac02ff0a3f9ad0bf47b15854bbebb73c936dd02f7c79293a2828406f6 (x86)

PluginPhantom: New Android Trojan Abuses “DroidPlugin” Framework

Recently, we discovered a new Google Android Trojan named “PluginPhantom”, which steals many types of user information including: files, location data, contacts and Wi-Fi information. It also takes pictures, captures screenshots, records audios, intercepts and sends SMS messages. In addition, it can log the keyboard input by the Android accessibility service, acting as a keylogger.

PluginPhantom is a new class of Google Android Trojan: it is the first to use updating and to evade static detection. It does this by leveraging the Android plugin technology. It abuses the legitimate and popular open source framework “DroidPlugin”, which allows an app to dynamically launch any apps as plugins without installing them in the system. PluginPhantom implements each element of malicious functionality as a plugin, and utilizes a host app to control the plugins. With the new architecture, PluginPhantom achieves more flexibility to update its modules without reinstalling apps. PluginPhantom also gains the ability to evade the static detection by hiding malicious behaviors in plugins. Since the plugin development pattern is generic and the plugin SDK can be easily embedded, the plugin architecture could be a trend among Android malware in the future.

Evolution of PluginPhantom

We believe PluginPhantom is a successor to the Android Trojan “Android.Trojan.Ihide”, which was discovered by TrustLook in July of 2016, since they share the same certificate and package name. PluginPhantom not only includes and improved all malicious functionalities from “Android.Trojan.Ihide”, but also adopts a very innovative design architecture. In the new architecture, the original malware app is divided into multiple apps (plugin apps) and a single app (a host app). The host app embeds all plugin apps in resources, which implement different functional modules. After victims install the host app, it can directly load and launch plugin apps without installing plugin apps, by abusing the legitimate open source plugin framework – DroidPlugin [2].

1. Introduction of DroidPlugin:

DroidPlugin is an innovative application-level virtualization/proxy framework, which was originally developed for purposes of hot patching, reducing the released APK size, and removing the 65535 methods limitation. The popular application scenario of DroidPlugin is launching multiple instances of apps on the same device (e.g. using multi-accounts in social apps). Fundamentally, DroidPlugin is very different from the widely known dynamic code loading (e.g. loading a dex or jar file), since it can directly load and launch an app from its APK file without installation. There are five basic concepts or mechanisms in the implementation of DroidPlugin:

  • Shared UID. All plugin apps share the same UID with the host app.
  • Pre-defined stub components and permissions. The host app has pre-defined components and permissions for plugin apps.
  • Dynamic Proxy Hook. The host app has hooked API invocations of plugin apps by the dynamic proxy technique, so that the Android system thinks that all API requests and components are from the host app.
  • Resource loading. As the plugin app is not installed in the system, so the host app must take over the process of loading app resources in the plugin app process.
  • Component Lifecycle Management. When the component in the plugin process is ready to be destroyed, the corresponding stub component should also be destroyed simultaneously.

2. Plugin Design of PluginPhantom:

In the plugin design architecture, PluginPhantom has one host app (i.e. the malicious APK we captured) and nine plugin apps that are embedded in the host app as assets files.  In these nine plugins, there exists 3 core plugins (“task”, “update” and “online”) and six additional plugins (“file”, “location”, “contact”, “camera”, “radio” and “wifi”), shown in Figure 1.

phantom_1

Figure 1 Plugin Architecture of PluginPhantom

The host app, as the controller and the entry point of PluginPhantom, schedules plugin apps by launching them and sending commands. In the initialization stage, the host app loads nine APK files in asset files and installs them as plugins in the DroidPlugin framework. Then, the host app can launch and communicate with plugins the same way it would with normal Apps installed on Android.

The online plugin, connects to the command and control (C2) server to upload device information (e.g. the screen state, the battery volume and the free RAM size) and retrieve commands to execute. The online plugin firstly finishes a “ThrowOut” step to probe the remote server by sending the “UUID” (from “java.util.UUID.randomUUID()”) in a UDP socket.  If the “UUID” is sent successfully, then, the online plugin continues to utilize the WebSocket to pull the command data from the server.

The task plugin, fetches the command data through the bridge of the host app. According to different command types, the task plugin forwards commands to six additional plugins to launch different attacks. The task plugin also uploads stolen data to the remote server through the WebSocket. In addition, the task plugin launches the update plugin to download new plugin APK files and update plugins, if it receives the “update” command type. Once the update plugin finishes downloading plugins, the task plugin sends a message to the host app to reload and relaunch plugins.

3. IPC and Data Sharing in PluginPhantom:

In the DroidPlugin framework, the host app and all plugin apps share different PIDs, but same UID. Thus, the IPC between the host app and plugin apps or among plugin apps is same as the IPC mechanism in the Android system. The IPC in PluginPhantom includes the Intent and AIDL. The host app can launch all plugin apps by starting the entry service of plugin apps with an Intent. In particular, to keep plugin services alive, the host app uses the alarm manager to restart the entry service of plugin apps in an interval. In addition, AIDL is used for IPC between the host app and plugin apps.  For example, “AbsAidl” is used by the task plugin to send commands to the host app for hooking keyboard inputs. The update plugin uses “ClientAidl”, “InfoAidl” and “PluginAidl” to synchronize the updated plugin information with the host app.

Even though the Intent and AIDL can share parts of data, PluginPhantom mainly uses the Content Provider and the file system to share data between the task plugin and six additional plugins. For example, the radio plugin gets commands from the task plugin by the URI “content://***.task.cntPrv/Command”, and stores the command response and recorded audio file paths into the URI “content://***.task.cntPrv/CmdRespond” and “content://***.task.cntPrv/CmdRespondFile” respectively.  Later, the task plugin parses last two content providers, and then reads and uploads recorded audio files from the external storage path “/sdcard/AndroidMedia/.audio/record”.

Stealing Information through Plugins

1. File Plugin

The file plugin scans a specific directory and retrieves information (e.g. file name, file type, file size, create time, edit time, file path, canonical path and read state), from the files inside it. It also scans media files in the external storage and can download and delete specific files.  During the file operation, the root privilege is used by the file plugin if necessary. In existing samples, PluginPhantom is trying to use the root privilege, but does not root the device. If the attacker wanted root access on the device, they could use the C2 channel to install an APK which exploits an unpatched local root vulnerability, but we have not yet observed this occur with PluginPhantom infections.

2. Location Plugin

The location plugin obtains both fine-grained and coarse-grained location information. It converts coordinates in the Android default geographic coordinate system to coordinates in two other coordinate systems, which are used by Baidu Maps and Amap Maps, the top two navigation apps in China.  To successfully obtain the location, the plugin can enable WIFI, GPS (under Android 4.4) and mobile data (under or in Android 5.0) options.

3. Contact Plugin

The contact plugin intercepts incoming SMS and phone calls for specific numbers received from the remote server. To avoid detection, it turns off the ringtone and phone screen and deletes call logs when SMS and phone calls are coming in. The contact plugin also steals call logs, device IDs and contacts info (including deleted contacts) in both the phone contact list and the SIM card contact list. Additionally, it sends SMS messages to specific numbers, which is finished after checking the current phone bill balance.

4. Camera Plugin

The camera plugin takes pictures in the background through either the front or the back camera. It uses a surface view with 0.1*0.1 size for camera previewing, and a full screen Activity with the transparent theme and no title, so victims may be not aware of this behavior. It also takes screen shots by the command “screencap –p” if it has obtained root privileges on the device.

5. Radio Plugin

The radio plugin records the audio in the background with two trigger conditions: commands from the remote server and incoming/outgoing phone calls. To avoid detection, it doesn’t record audio if other apps are also recording.

6. WIFI Plugin

The WIFI plugin steals WIFI information (e.g. SSID, password, IP address, mac address), software information (e.g. app name, version, last update time, is system app), running process information (e.g. PID, process name, app name, app resource path, app data path, timestamp), and trace information (e.g.  browser visiting history and bookmarks).

Stealing Keyboard Inputs through Accessibility in the Host App

In the host app, a developer defined service named “AutoService” extends the “AccessibilityService” to hook all GUI events in the system (Figure 2). First it needs to trick users into enabling the accessibility permission to this app using it’s description shown in Figure 3, which pretends describes a fake “memory cleaning service.”

phantom_2

Figure 2 Accessibility Service for hooking

phantom_3

Figure 3 Lure users to enable the accessibility service

The host app uses the Android Accessibility feature to hook and operate on the specific Activity and package by referring the class name and package name, for two purposes:

1. Grant or activate if a GUI dialog asks for authorizations. If the text of a clickable button matches keywords in “this.b” (Figure 4), or the text of a checkbox matches keywords “Don’t show this again” in “this.c” (Figure 4), the app will automatically click the button or the checkbox.

2. Record the keyboard inputs for specific apps.  PluginPhantom logs user inputs, such as the text and window id, for all leaf nodes in the UI tree (Figure 5). Thus, the victims’ inputs in the EditText element can be logged. Note that password inputs cannot be logged. The text of password EditText node is always empty since the password attribute of this node is true.

phantom_4

Figure 4 Matched keywords for clicking

phantom_5

Figure 5 Log the text and window id of the UI node

Conclusion

While the Android plugin technology is very hot in the Android app development, it also gives a chance to malware developers to redesign malware in a more flexible way. Like the PluginPhantom family, malware can easily update or add modules by updating or installing plugin apps. In terms of evasion, the plugin malware can hide all malicious behaviors in plugin apps, which can be downloaded and launched to bypass static detection. Additionally, the plugin technology might be a replacement of the repackage technique in the future. The plugin malware only needs to launch the original app as one plugin, and later launch malicious modules as other plugins. Even though the PluginPhantom is the first malware using the legitimate DroidPlugin framework, we will continue to watch and report this threat as attackers may use other plugin frameworks and launch more attacks.

Customers of Palo Alto Networks are protected with our WildFire, URL filtering and IPS services. AutoFocus users can identify samples of this malware using the PluginPhantom tag.

Acknowledgments

We greatly appreciate the help from Zhi Xu, Claud Xiao, Xin Ouyang, Ryan Olson and others from Palo Alto Networks in working on the analysis of PluginPhantom family.

Sample Hashes

002e568047074093ca43153b806fb29ec60bcf1b3040487f8ec727ace1209316
1f739108dc2a6520ad736249cd8ed0dbc674e59e687337005b3fa3ab52956bb2
1fe181823dbab09aee5cc72b83822977c64ec17cdbf739f5e6edf9b2f5697d11
8255149b6d3ffaa029c6302659aec00d17418fefc5cde9572fbf23bb996d9fde
91f7d9663d259b0c57619bbdd73fb763b6567cce0c1ae05542d8f55644e12d20
92b6a68ea66c73d5d05dff7d8d290ea8ba242846b05d6d4e2e477eb662944cac
b642b9de56218696cf5fe7f47aa914bfe3fec22a754d68c03e0e8d130efbb14f
d56f9157d5b9aabd01bc0476c1a5e5e398a90c75efb9da37f0f7fcaf61b896b8
e4977499171b475e8fd450477574b36b8d1bf0af62a5782fb77c702bcf4fb408

C2 Domains and URLs

1519j010g4[.]iok[.]la
58[.]222.39.215:8088/dmrcandroid/ws/httpsData/command

Tropic Trooper Targets Taiwanese Government and Fossil Fuel Provider With Poison Ivy

Taiwan has been a regular target of cyber espionage threat actors for a number of years. Reasons for Taiwan being targeted range from being one of the sovereign states of the disputed South China Sea region to its emerging economy and growth with Taiwan being one of the most innovative countries in the High-Tech industry in Asia.

In early August, Unit 42 identified two attacks using similar techniques. The more interesting one was a targeted attack towards the Secretary General of Taiwan's Government office – Executive Yuan. The Executive Yuan has several individual boards which are formed to enforce different executing functions of the government. The Executive Yuan Council evaluates statutory and budgetary bills and bills concerning martial law, amnesty, declaration of war, conclusion of peace and treaties, and other important affairs. Given the important functions undertaken by the Executive Yuan office, it is not a surprise that they were targeted. The second attack was against an energy sector company also located in Taiwan.

The attacks in this case are associated with a campaign called Tropic Trooper, which has been active since at least 2011 and is known for heavily targeting Taiwan. One of the attacks used their known Yahoyah malware, but the other attack deployed the widely available Poison Ivy RAT.  This confirms the actors are using Poison Ivy as part of their toolkit, something speculated in the original Trend Micro report but not confirmed by them. Further analysis uncovered a handful of ties indicating the actors may also be using the PCShare malware family, which has not been previously tied to the group.

Figure 1 shows the spear phishing email which was sent to the Secretary General of Executive Yuan. The email is spoofed so that it appears as though it was sent from a staff member at the Democratic Progressive Party (DPP).

tropictrooper_1

Figure 1. Spear-phishing email with malicious attachment.

The document attached to this e-mail exploits CVE-2012-0158, a Microsoft Office vulnerability. This process is described in the Malware Analysis section later in this report, but one interesting aspect of this malicious was the decoy document the attacker chose to deploy.

Decoy Document

As we have noted in many earlier reports, attackers commonly use decoy files to trick victims into thinking a malicious document is actually legitimate. After infecting the computer, the display a clean document to the victim that contains content that is relevant to them.

The decoy document used in this case is a spreadsheet with four tabs, respectively titled “example,” “0720,” “0721,” and “1041109 full update”. All of the text uses Traditional Chinese, in contrast to Simplified Chinese, which is the official written language of the People's Republic of China. Traditional Chinese is used in Taiwan, Hong Kong, Macau, and many overseas Chinese communities.  The overarching theme of the spreadsheet is documenting protestor activity and/or progressive reform attempts in progress across Taiwan and the tone of the spreadsheet suggests it was compiled by progressive supporters. Because we were unable to find the spreadsheet online, and there is specific persona data included related to these movements and protests, we are not including any screen shots except for the one below.

tropictrooper_2

Figure 2. The four tabs in the decoy spreadsheet.

The “example” spreadsheet tab is exactly as described – it contains the headers and suggested information within two of the remaining three tabs. The headers themselves translate, from left to right, to “responsible department,” “issue,” “developments this week,” “political situation judgment,” and “related information.”  The tab labeled 0721 only has the matching headers and no additional information.  None of the information in the spreadsheet relates to activities past 2015, and there are references made to the then upcoming January 16, 2016 elections in Taiwan. In that election the DPP won, displacing the Chinese Nationalist Party (KMT) for only the second time in history, and with Taiwan’s first female President.

The spreadsheet labeled 0720 refers to the Anti-Black Box Movement, which was a protest by Taiwanese high school students against certain proposed curriculum changes. The use of “black box” by the protestors is in reference to former Taiwanese President Ma Ying-Jeou’s government and its lack of transparency concerning government decisions. Protestors occupied Taiwan’s Ministry of Education last July. A resolution passed by Taiwan’s legislature and approved by the Executive Yuan in May of this year delayed implementing that curriculum until 2020 to allow time for the act to be amended.

The Anti-Black Box Movement is related to the Sunflower Student Movement, a coalition of both student groups and other civic organizations that protested the Cross-Strait Trade Agreement between Taiwan and the PRC, feeling it would hurt Taiwan’s economy and increase the PRC’s sway over the island.  On March 17 2014, the KMT, the ruling party at the time, tried to force a vote without a previously agreed clause by clause review with the DPP. The following evening protesters occupied the Legislative Yuan, the first time that had occurred Taiwan’s history. On March 23 of the same year, after then President Ma re-affirmed he supported the pact and would not alter or drop it, protestors occupied the Executive Yuan where over 150 were injured and 61 arrested.

The final tab contains the most information of the three and has different headers. From left to right, the headers are titled “responsible person(s),” “summary of issues and major groups,” “crisis simulation, political judgment, and recommendations,” “degree of tension,” and “participating members.”

  • Information related to the November 2015 "Autumn Struggle" protest, which is an annual protest first done in 2013.
  • Information on a Taichung City government development proposal being protested largely on environmental impact grounds, and protestor demands.
  • Army 1st Special Forces veterans attempt to receive compensation for alleged illegal extension of forced military service
  • The recently settled case where toll workers forced into unemployment by the Taiwanese government’s agreement with the Far Eastern Electronic Toll Collection Company to create a national electronic toll collection system ended up resulting in the 2013 layoffs of hundreds, who have since protested for new jobs as well as lost severance and pension.
  • Kaohsiung refinery closing and protestor demands, also largely related to environmental effects and necessary cleanup; the refinery officially closed at the end of December 2015
  • Closely watching any trade agreements between the Malaysian government and Taiwan
  • Potential environmental and current residential issues related to the development of the Aerotropolis around Taoyuan International Airport, which is intended to create a major transportation hub and industry center for Asia with infrastructure for corporate research and development, conference centers, and other facilities.
  • The Puyu Development Plan, which is part of Taiwan’s Knowledge-based Economy plan
  • Taiwan’s 12-year compulsory education plan
  • Anti-Black Box Movement demands and recent activity
  • Improving working conditions for Taiwanese firefighters
  • Pension reforms
  • The Nest Movement, which started in 2014 and is related to the older “Shell-less Snail Movement,” focused on affordable housing, neighborhood and urban development, ending forced demolition and relocation, property tax reform, and related housing issues
  • The Environmental Impact Assessment (EIA) voted on by the Environmental Protection Bureau (EPB) for the Dongshi-Fengyuan Expressway, part of the National Highway #4 Project and anti-eviction efforts
  • Kaohsiung water quality issues and related projects
  • Same sex marriage legalization
  • Protecting old trees in Kaohsiung amidst construction for a new “green” library; most of the designated “precious trees” are rare exotic species
  • Indigenous peoples in Kaohsiung land return
  • Activities against the Miramar Resort Village, including the revocation of the EIA, forcing development to halt
  • Lowering the voting age in Taiwan from 20 to 18

Malware Analysis

The documents attached to spear-phishing e-mails used in both attacks contain code that exploits CVE-2012-0158, which despite its age remains one of the most common Microsoft Word vulnerabilities being exploited by multiple threat actors. This matches with known Tactics, Techniques, and Procedures (TTPs) for Tropic Trooper, targeting both government institutions and also the energy industry in Taiwan.

The delivery document uses the XLSX extension typically used by OpenXML documents, but the file itself is actually an OLE (XLS) document. The file extension to file type discrepancy was caused by the actor using Excel's built-in encryption capability, which stores XLSX ciphertext and the information needed for decryption in an OLE document.

Filename: 進步議題工作圈議題控管表.xlsx
MD5: a89b1ce793f41f3c35396b054dbdb749
SHA1: f45e2342e40100b770d73dd06f5d9b79bfce4a72
SHA256: 2baa76c9aa3834548d82a36e150d329e3268417b3f12b8f72d209d51bbacf671
Type: CDF V2 Document, No summary info
Size: 327128 bytes

Table 1. Details of the malicious document attached to the e-mail.

The embedded shellcode enumerates open handles for a file with a size greater than 0xa6f0 (Decimal - 42736) bytes. It will then set the file pointer to 0xa6e8 (Decimal - 42728) and starts looking for the following delimiter:

GfCv\xef\xfe\xec\xce

If it finds this delimiter, the shellcode knows it is working with the correct file and continues by reading 0x600 (decimal 1536) bytes following this delimiter. The shellcode then decrypts the first 0xc0 (decimal 192) DWORDs of the data read from the file using an XOR algorithm that decrypts one DWORD of ciphertext at a time with 0x29f7c592. The resulting cleartext is a second piece of shellcode that continues carrying out further functionality.

The secondary shellcode starts by resolving the following API functions using a ROT13 hashing algorithm:

kernel32.dll!CreateFileA
kernel32.dll!ReadFile
kernel32.dll!WriteFile
kernel32.dll!SetFilePointer
kernel32.dll!CopyFileA
kernel32.dll!MoveFileExA
kernel32.dll!CreateToolhelp32Snapshot
kernel32.dll!Process32Next
kernel32.dll!CloseHandle
kernel32.dll!VirtualAlloc
kernel32.dll!WinExec
kernel32.dll!TerminateProcess
kernel32.dll!LoadLibraryA
kernel32.dll!lstrlenA
kernel32.dll!lstrcpyA
kernel32.dll!lstrcatA
kernel32.dll!GetTempPathA
kernel32.dll!WideCharToMultiByte
kernel32.dll!QueryDosDeviceA
ntdll.dll!NtQueryObject
advapi32.dll!RegOpenKeyA
advapi32.dll!RegSetValueExA
advapi32.dll!RegCloseKey

Immediately following these API functions there are three DWORDS; one used to locate the payload embedded within the exploit file, one for the size of the payload, and one for the size of decoy document. The two size values are added together to get the length of the ciphertext that the shellcode will decrypt. In the sample we analyzed, the following values were present, showing that the payload is at offset 0xabc0 and has a size of 0x45218:

DWORD offset_toPayload; (0ABC0h)
DWORD payload_Size; (1C600h)
DWORD decoy_Size; (28C18h)

The shellcode then creates a string that it uses to create a registry key to automatically run the final payload each time the system starts. It then opens the registry key 'Software\Microsoft\Windows NT\CurrentVersion\Winlogon' and sets the value to the "Shell" subkey to the previously created string. Ultimately, the following registry key is created for persistence:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell:
"explorer.exe,rundll32.exe "C:\Documents and Settings\Administrator\Application
Data\Identities\Identities.ocx" SSSS"

It then uses the "offset_toPayload" value as an offset that it will read 283160 (45218h) bytes from the XLS file. The shellcode then enters a decryption loop to convert the embedded payload from ciphertext to cleartext. The algorithm uses the length of the ciphertext negated as the initial encryption key, which it bit rotates right by 1 to adjust the key for each of decryption. It will use this key to decrypt four bytes of the ciphertext with the XOR operation until all the ciphertext is decrypted. During each iteration of the decryption process, the algorithm will check to make sure the four bytes of ciphertext are not equal to the key or equal to zero before decrypting the ciphertext.  The following table contains the first five rounds of the algorithm to explain the decryption process:

 Key Ciphertext  Cleartext
0  ~0x45218 = 0xFFFBADE8 >> 1 = 0x7FFDD6F4  0x7F6D8CB9  0x00905a4d = MZ\x90\x00
1  0x7FFDD6F4 >> 1 = 0x3FFEEB7A  0x3FFEEB79  0x03 = \x03\x00\x00\x00
2  0x3FFEEB7A >> 1 = 0x1FFF75BD  0x1FFF75B9  0x04 = \x04\x00\x00\x00
3  0x1FFF75BD >> 1 = 0x8FFFBADE  0x8FFF4521  0xFFFF = \xff\xff\x00\x00
4  0x8FFFBADE >> 1 = 0x47FFDD6F  0x47FFDDD7  0xB8 = \xb8\x00\x00\x00
5  0x47FFDD6F >> 1 = 0xA3FFEEB7  0x00000000  0x00000000 = \x00\x00\x00\x00
6  0xA3FFEEB7 >> 1 = 0xD1FFF75B  0xD1FFF71B  0x40 = \x40\x00\x00\x00
7  0xD1FFF75B >> 1 = 0xE8FFFBAD  0x00000000  0x00000000 = \x00\x00\x00\x00
8  0xE8FFFBAD >> 1 = 0xF47FFDD6  0x00000000  0x00000000 = \x00\x00\x00\x00
9  0xF47FFDD6 >> 1 = 0x7A3FFEEB  0x00000000  0x00000000 = \x00\x00\x00\x00
10  0x7A3FFEEB >> 1 = 0xBD1FFF75  0x00000000  0x00000000 = \x00\x00\x00\x00
11  0xBD1FFF75 >> 1 = 0xDE8FFFBA  0x00000000  0x00000000 = \x00\x00\x00\x00
12  0xDE8FFFBA >> 1 = 0x6F47FFDD  0x00000000  0x00000000 = \x00\x00\x00\x00
13  0x6F47FFDD >> 1 = 0xB7A3FFEE  0x00000000  0x00000000 = \x00\x00\x00\x00
14  0xB7A3FFEE >> 1 = 0x5BD1FFF7  0x00000000  0x00000000 = \x00\x00\x00\x00
15  0x5BD1FFF7 >> 1 = 0xADE8FFFB  0xADE8FEF3  0x108 = \x08\x01\x00\x00
16  0xADE8FFFB >> 1 = 0xD6F47FFD  0xD84E60F3  0xEBA1F0E = \x0e\x1f\xba\x0e
17  0xD6F47FFD >> 1 = 0xEB7A3FFE  0x26738BFE  0xCD09B400 = \x00\xb4\x09\xcd
18  0xEB7A3FFE >> 1 = 0x75BD1FFF  0x39BCA7DE  0x4C01B821 = \x21\xb8\x01\x4c
19  0x75BD1FFF >> 1 = 0xBADE8FFF  0xD28AAE32  0x685421CD = \xcd!Th
20  0xBADE8FFF >> 1 = 0xDD6F47FF  0xAD4F3496  0x70207369 = is p
21  0xDD6F47FF >> 1 = 0xEEB7A3FF  0x9CD0CC8D  0x72676F72 = rogr
22  0xEEB7A3FF >> 1 = 0xF75BD1FF  0x947BBC9E  0x63206D61 = am c
23  0xF75BD1FF >> 1 = 0xFBADE8FF  0x94C3869E  0x6F6E6E61 = anno
24  0xFBADE8FF >> 1 = 0xFDD6F47F  0x98B4D40B  0x65622074 = t be
25  0xFDD6F47F >> 1 = 0xFEEB7A3F  0x909E081F  0x6E757220 =  run

Table 2.  Decrypting the payload

As you can see from the table above, the algorithm decrypts what is an embedded portable executable that acts as the payload in this attack. The embedded payload is written to %APPDATA\Identities\Identities.ocx and has the following attributes:

The decoy document, described in the section above, is saved to %TEMP%\進步議題工作圈議題控管表.xlsx and has the following attributes:

The shellcode will move the decoy document to the location of the originally executed XLSX file and will create the following command:

cmd /c start excel /e  “<path to original XLSX file, now decoy
document>”

Before running the above command to open the decoy document, the shellcode enumerates the running processes on the system, specifically looking for processes created for an executable with a filename that starts with “avp.”, presumably in an attempt to find Kaspersky’s antivirus process. If the process is found, the shellcode will not open the decoy document and exits.

The shellcode does not launch the payload, rather it relies on the registry key it created for persistence to execute the payload when the user reboots the system, meaning during dynamic analysis the execution of the payload may be missed.

Delivered Payload – Poison Ivy

When the system starts up, the persistence registry key will launch the Identities.ocx payload and call its “SSSS” exported function. The “SSSS” function checks to make sure that the DLL is running within the context of a “rundll32.exe” process and then begins piecing 0x141B bytes of data together in the correct order to build the shellcode of the Poison Ivy Trojan.

We found and parsed the following configuration from the Poison Ivy shellcode:

Looking for more samples which exhibited the same file structure, encryption and obfuscation to deliver the above Poison Ivy sample yielded only two additional samples. In the other two instances the delivered payloads were respectively PCShare and Yahoyah.  PCShare has not been previously associated with Tropic Trooper, but in addition to the aforementioned overlaps, the two samples have passive DNS overlap with some known Tropic Trooper infrastructure. For those reasons, we assess with limited confidence the group is also using this malware family.

tropictrooper_3

Figure 3. The limited ties between C2 infrastructure used by Yahoyah samples (top) and PCShare malware samples (bottom).

The below table shows the details of the documents, payload delivered and the C2 servers used for communications.

SHA256 a3becf3639fa82bfbf01740ce5a8335f291fb83b544e02a6cc9f1e9c96fb3764
Filename CTC Statement.xlsx
Payload d76d7d64c941713d4faaedd5c972558c5136cd1b7de237280faaae89143e7d94
Tool PCShare
C2 belindianlab[.]itemdb[.]com
C2 IP 210.108.146[.]20
SHA256 ca10489091b71b14f2c3dc0b5201825e63a1f64c0a859ba2bd95900f45580fc4
Filename 全台餐廳更新版餐廳_.xlsx
Payload bff5f2f84efc450b10f1a66064ed3afaf740c844c15af88a927c46a0b2146498
Tool Yahoyah
C2 www[.]dpponline[.]trickip[.]org
C2 www[.]myinfo[.]ocry[.]com
C2 IP 223.27.35[.]244

 

It is interesting to see that the exploit documents we found had either low or no detections on most popular antivirus engines, showing that the threat actors behind this campaign have been having considerable success in bypassing static analysis undertaken by traditional antivirus solutions with this technique.

We further expanded our search using the AutoFocus Threat Intelligence platform on the IOCs extracted from the PIVY, PCShare and Yahoyah payloads and found 42 samples which either matched unique behaviors, the unique PIVY mutex or had common C2 infrastructure.  The hashes of all the samples found are given in the appendix section at the end of this blog.

Figure 4 below shows the compilation timestamps of the payload samples found using AutoFocus. Given some of the payloads that were used in recent attacks, which were compiled months before, it shows that the threat actor group continues to reuse the payload within their exploit documents.

tropictrooper_4

Figure 4. Payload Compilation Timelines

The below Maltego graph shows some of the shared infrastructure which have been used by Tropic Trooper. The complete list of indicators on the graph can also be found in the appendix section of this report.

 

tropictrooper_5

Figure 5 Maltego graph of Tropic Trooper infrastructure

Conclusion

The Tropic Trooper threat actor group has been known to target governments and organizations in the Asia Pacific region for at least six years. In addition to using Yahoyah malware, we were able to confirm they are also using Poison Ivy and possibly PCShare malware families.  They are also still exploiting CVE 2012-0158, as are many threat actors. Palo Alto Networks customers are protected from Tropic Trooper’s malicious activities by:

  • WildFire correctly identifies all related malware as malicious
  • The C2 infrastructure are classified as malicious in PAN-DB
  • Traps prevents exploitation of CVE-2012-0158

Autofocus customers can discover additional information on Tropic Trooper via the following AutoFocus tags:

Appendix

Samples matching unique indicators, behaviors and C2 infrastructure from the payload extracted out of the malicious documents:

SHA256 hashes
Winsloader
c098235a43d9788661490d2c7b09b1b2b3544d22ee8d9ae6cd5d16a977fd1155
e81bc530075d6d31358aea5784d977d1ac2932a13a615cd1319d01d6e39c2995
cf32fb6371cc751b852c2e2e607c813e0de71cd7bcf3892a9a23b57dfd38d6fc
07663f8bca3c2118f3f77221c35873fd8dd61d9afa30e566fe4b51bcfb000834
92da05bae1d9694a1f63b854e86b5b17ef27d5fc2551318e49e17677c7c90042
e267ecfd37f3af55e8b02b081e7c9d8c0bf633e1d5acb0228be694eae4660eee
PCShare
d76d7d64c941713d4faaedd5c972558c5136cd1b7de237280faaae89143e7d94
66d672a94f21e86655f243877ee04d7e67a515a7153891563f1aeedb2edbe579
Yahoyah
85904e7b88b5049fb99b4b8456d9f01bdbf8f6fcf0f77943aed1ce7e6f7127c2
2fce75daea5fdaafba376a86c59d5bc3e32f7fe5e735ec1e1811971910bc4009
aa812b1c0b24435b8e01100760bc4fef44032b4b0d787a8cf9aef83abd9d5dbd
9623d6f3a3952280f3e83f8dbb29942694bb682296d36c4f4d1d7414a7493db0
f0aa64c1646d91b0decbe4d4e6a7cc53bfd770c86ded9a7408034fa14d2bad83
73bba13d1c7b6794be485a5eeb7b79a62f109c27c4c698601945702303dbcd6c
25809242472a9e1f08ff83c00fae943a630867604ff95c7a57313187287384d2
72d14f0a7ecb04eb2962bc9d8491194deb856ceebf30e7ecd644620932f3d4b0
2172cc228760d6e4fa297bc485637a2b17103ae88237b30df39babe548cefaa5
fdeb384ff68b99514f329eeffb05692c4c1580ca52e43e6dcbb5d760c2a78aa4
1432a8a6ae6faa5d9f441b918ddc3edddb9c133458853ad356756835fe7b3291
a4334a33e4a87cfa52e9e24f6b4d3da0b686f71b25e5cc9a6f144485ea63108a
7f8abefcc4598c643dff1ebf570677fd5c2a4f3d08bc8ddabbfbef1eed097fb3
8e1a0d93ae644ac80048e5c3485bc6282a69d52cf26f94d2be1ce634851ac3aa
c2ad0204ff90c113f7984a9db6006c9f09631c4983098803591170be62cdfaa7
8ccaade84c9c7d5955e8aa1a0d36542beeaed5b8f619aedf82f74e8fd5a5283b
03e9c25fe979f149f6dafb0398cdf3d2223b26f24009ef0f83825b60e961d111
bee4cc2c3c393953f9247eab45767e01cd26d40037fb00bd69441e026d860a63
626f65d4d638437aaa8352fe06589165d52a91e0963c988348b00734b0a3419f
5395f709ef1ca64c57be367f9795b66b5775b6e73f57089386a85925cc0ec596
72cc8c41008310024e9339b9e45bec7815b7fa8a0c3b6a56769d22bc4ced10ed
fefd9bfb0f984590b54908c6868b39ca587a3e0d8198b795ff58f67adee4b9e9
4ee115734733dae0705e5b2cb6789a1cdb877bc53e2fdb6e18ab845c0522d43b
6b6ec318ede71baf79004fe22c46a8d7a500dc6ba6dd40b2641fe9a1c2b3dbd5
78eda231bf494c7008a4ad49e982f2470597199829d46b166a75f654e3cb8d59
21857cdd794649d72ab1bf90acfa8a57767a2a176b46cdb930025cf9242303bb
bff5f2f84efc450b10f1a66064ed3afaf740c844c15af88a927c46a0b2146498
6597c49bedf3fb1964e7f6ccbb03db9e38a5903a671209ae4d3fb4f9f4db4c95
 
Poison Ivy
6966e511a45e42a9cfa32799dd3ecf9ec1c2cf62ed491f872210334a26e8a533
84f9d3c0895fbcc3148ec77b967eb9cdf33eb90915937b91a61664d36eed7464
c4b73d2102c25e31e3b73a8547a0120e1d3706eed96392acb174ecbf1218fa37
c9d0d7e3ba9a1369b670511966f2c3b5fa3618d3b8ac99cbc3a732bd13501b99
ee3f29d2a68217825666dae6a56ae7ee96297ea7f88ae4fd78819983ae67a3ce
edfedfad21bd37b890d0e21c3c832ff9493612f9959a32d6406750b2d4a93697
 

 

C2 domains
news[.]hpc[.]tw
www[.]dpponline[.]trickip[.]org
www[.]forensic[.]zyns[.]com
www[.]bannered[.]4dq[.]com
www[.]forensic611[.]3-a[.]net
bbs[.]zzbooks[.]net
bbs[.]ccdog[.]net
wallstreet[.]1dumb[.]com
www[.]cham[.]com[.]tw
pinkker[.]zzux[.]com
www[.]amberisic611[.]4dq[.]com
www[.]metacu[.]ygto[.]com
bbs[.]zzbook[.]net
www[.]myinfo[.]ocry[.]com
www[.]gmal1[.]com
news[.]hpc[.]tw
www[.]dpponline[.]trickip[.]org
pinkker[.]zzux[.]com
wallstreet[.]1dumb[.]com
redpeach[.]youdontcare[.]com
redapple[.]justdied[.]com
stone[.]mypop3[.]org
zeus[.]jkub[.]com
sniper[.]mynumber[.]org
unclesam[.]jungleheart[.]com
arora[.]x24hr[.]com
flanando[.]fartit[.]com
www[.]dpponline[.]trickip[.]org
www[.]myinfo[.]ocry[.]com
belindianlab[.]itemdb[.]com
kr[.]dns1[.]us

 

C2 HTTP requests
hxxp://www[.]dpponline[.]trickip[.]org/images/D2015_id[.]jpg
hxxp://223[.]27[.]35[.]244/images/D2015_id[.]jpg
hxxp://www[.]myinfo[.]ocry[.]com/images/D2015_id[.]jpg
hxxp://belindianlab[.]itemdb[.]com/1613986301|C7A5398FBD8214C92F6596CC39B8866B0121E53422D6B8378E5D1F5F63844D693810BDED362511ED3630DC4F6A2B1302354C31242753DACB331EF3CF808E4E107B12F103F0C040F87DAA6CAB0676A25EBC673D9DFA078915F93361308E10BB5BA7DF1A90FEB614F1A1F12C7A135B60926A5D49FCE025F577FE0DEE937C803BE27D
hxxp://202[.]153[.]193[.]73/images/kong[.]24[.]jpg
hxxp://113[.]10[.]221[.]89/images/kong[.]24[.]jpg
hxxp://61[.]221[.]169[.]31/images/kongj[.]24[.]jpg
hxxp://www[.]forensic611[.]3-a[.]net/monitor/images/Smarp140102[.]24[.]gif
hxxp://www[.]bannered[.]4dq[.]com/monitor/images/Smarp140102[.]24[.]gif
hxxp://www[.]forensic[.]zyns[.]com/monitor/images/Smarp140102[.]24[.]gif
hxxp://113[.]10[.]221[.]89/Pictures/sbsb_0620[.]24[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/sbsb_0620[.]24[.]jpg
hxxp://www[.]forensic611[.]3-a[.]net/monitor/images/Smartzh131225[.]24[.]gif
hxxp://www[.]bannered[.]4dq[.]com/monitor/images/Smartzh131225[.]24[.]gif
hxxp://www[.]forensic[.]zyns[.]com/monitor/images/Smartzh131225[.]24[.]gif
hxxp://bbs[.]zzbooks[.]net/Pictures/lclc_0523[.]24[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/lclc_0523[.]24[.]jpg
hxxp://113[.]10[.]221[.]89/Pictures/lclc_0523[.]24[.]jpg
hxxp://50[.]117[.]38[.]164/Pictures/dzh_0925[.]24[.]jpg
hxxp://www[.]cham[.]com[.]tw/images/dzh_0925[.]24[.]jpg
hxxp://113[.]10[.]221[.]89/Pictures/dzh_0925[.]24[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/jpg_140430[.]24[.]jpg
hxxp://198[.]100[.]122[.]66/Pictures/jpg_140430[.]24[.]jpg
hxxp://192[.]69[.]221[.]92/Pictures/jpg_140430[.]24[.]jpg
hxxp://www[.]bannered[.]4dq[.]com/monitor/images/SmartNav141216[.]64[.]gif
hxxp://www[.]amberisic611[.]4dq[.]com/monitor/images/SmartNav141216[.]64[.]gif
hxxp://www[.]metacu[.]ygto[.]com/monitor/images/SmartNav141216[.]64[.]gif
hxxp://www[.]metacu[.]ygto[.]com/monitor/images/SmartNav141216[.]32[.]gif
hxxp://www[.]amberisic611[.]4dq[.]com/monitor/images/SmartNav141216[.]32[.]gif
hxxp://www[.]bannered[.]4dq[.]com/monitor/images/SmartNav141216[.]32[.]gif
hxxp://bbs[.]ccdog[.]net/Pictures/20150120-hex[.]64[.]jpg
hxxp://23[.]27[.]112[.]216/Pictures/20150120-hex[.]64[.]jpg
hxxp://bbs[.]zzbook[.]net/Pictures/20150120-hex[.]64[.]jpg
hxxp://bbs[.]zzbook[.]net/Pictures/20150120-hex[.]32[.]jpg
hxxp://23[.]27[.]112[.]216/Pictures/20150120-hex[.]32[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/20150120-hex[.]32[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/h20141212012[.]64[.]jpg
hxxp://23[.]27[.]112[.]216/Pictures/h20141212012[.]32[.]jpg
hxxp://113[.]10[.]221[.]89/Pictures/h20141212012[.]32[.]jpg
hxxp://bbs[.]ccdog[.]net/Pictures/h20141212012[.]32[.]jpg
hxxp://113[.]10[.]221[.]89/Pictures/ooba_0823[.]24[.]jpg
hxxp://198[.]100[.]122[.]66/Pictures/ooba_0823[.]24[.]jpg
hxxp://50[.]117[.]38[.]164/Pictures/ooba_0823[.]24[.]jpg
hxxp://www[.]metacu[.]ygto[.]com/monitor/images/SmartNav0120[.]64[.]gif
hxxp://www[.]amberisic611[.]4dq[.]com/monitor/images/SmartNav0120[.]64[.]gif
hxxp://www[.]bannered[.]4dq[.]com/moitor/images/SmartNav0120[.]64[.]gif
hxxp://www[.]bannered[.]4dq[.]com/moitor/images/SmartNav0120[.]32[.]gif
hxxp://www[.]metacu[.]ygto[.]com/monitor/images/SmartNav0120[.]32[.]gif
hxxp://www[.]amberisic611[.]4dq[.]com/monitor/images/SmartNav0120[.]32[.]gif
hxxp://www[.]dpponline[.]trickip[.]org/images/D2015_id[.]jpg
hxxp://223[.]27[.]35[.]244/images/D2015_id[.]jpg
hxxp://www[.]myinfo[.]ocry[.]com/images/D2015_id[.]jpg
hxxp://49[.]254[.]211[.]75//tedws/1[.]64[.]jpg
hxxp://107[.]183[.]183[.]235/public/1[.]64[.]jpg
hxxp://49[.]254[.]211[.]75//tedws/1[.]32[.]jpg
hxxp://107[.]183[.]183[.]235/public/1[.]32[.]jpg
hxxp://flanando[.]fartit[.]com/2015/p1[.]64[.]jpg
hxxp://flanando[.]fartit[.]com/2015/p1[.]32[.]jpg

Exploit Kits Exposed: Automated Attacks at Scale

Put yourself in the shoes of an attacker: Your objective is to infiltrate an organization, deploy ransomware and get paid. It is your job to launch the most effective, lowest cost attack possible, which also delivers the highest return. When adversaries balance the equation of effort versus potential reward, they are increasingly turning toward automated tools, like exploit kits (EKs), to help them achieve their malicious goals at massive scale. In short, EKs allow a malicious actor to silently exploit vulnerabilities in a browser-based application, deliver a malware payload, and operationalize the attack using rental-based EK infrastructure.

Before we look forward, it is important to understand the history of exploit kits and how they’ve become one of the most prevalent and effective methods of breaching an organization today. The popularity of EKs dates back to 2006, when the first documented case appeared; but it really took off in 2010 with the introduction of the Blackhole EK and its associated software-as-a-service (SaaS) based business model. Now, instead of setting up malicious infrastructure, compromising websites, identifying vulnerability exploits, and delivering malware, malicious actors could outsource nearly the entire attack flow to an expert. This is cyberattacking for the masses, with a modern and simple-to-use interface to match.

exploit_1

Over time, network defenders identify and take down prevalent exploit kits, as we saw with the disappearance of Blackhole after the arrest of its author; but there is always another one ready to take over the mantle and reap the profits. In recent years, we have seen an explosion in the scale of EK usage against organizations, especially as they have been increasingly used to deliver ransomware payloads. In fact, according to research by the Palo Alto Networks Unit 42 threat intelligence team, “Exploit kits are now, on average, about twice as expensive as they were two years ago.” We expect this trend to continue, with malicious actors continuing to leverage the automation, scale and silent malware delivery offered by exploit kits.

As organizations build their prevention infrastructure, they should consider how their security controls can identify and prevent this significant threat across the network, cloud and endpoint. Learn more about the past, present and future of exploit kits, and how to prevent them:

That Nigerian Prince Has Evolved His Game

Today Unit 42 published its latest paper focused on Nigerian cybercrime. Applying advanced analytics to a dataset of 8,400 malware samples resulted in the attribution of over 500 domains supporting malware activity linked to roughly 100 unique actors or groups. The breadth and depth of this research has enabled a modern, comprehensive assessment focused on the collective threat rather than individual actors.

As a whole we have observed that Nigerian actors have graduated from their traditional 419-style email scams. Malware attacks have grown steadily over the past two years from fewer than 100 attacks in July 2014 to their current rate of 5,000–8,000 per month. These attacks are largely victim-agnostic, spanning all major industry verticals and focusing more on businesses than individuals. Having learned how to successfully employ commodity malware tools with precision, these actors have seen lucrative returns ranging from tens of thousands up to millions of dollars from victim organizations in the past year alone. Given our findings, we believe that historical assessments concerning this threat warrant reassessment as these actors have now demonstrated that they pose a formidable threat to businesses and government organizations worldwide.

The paper we released today details the history of Nigerian cybercrime, the tactics being employed, and unique insights into how the threat has matured in size, scope, complexity and technical competence over the past two years. Additionally, it provides a detailed look at the following:

Actor Profiles

Attribution of these actors revealed that, first and foremost, they are educated. Many have attended secondary schools and hold undergraduate degrees in technical fields. These actors range in age from late teenage years to their mid-40s, representing a wide range of generations. This results in a combination of older actors who were successful with traditional 419 scams and social engineering, working with younger actors who bring an understanding of malware to the table. More importantly, these actors are becoming organized, using social media to communicate, coordinate and share tools and techniques.

Financial Losses

The losses inflicted by these actors have significant impacts to businesses worldwide. In 2015, an annual report released by the FBI’s Internet Cyber Crime Center identified 30,855 victims of traditional 419/Overpayment scams resulting in losses in excess of $49 million. While that number is substantial, on August 1, 2016, Interpol announced the arrest of a Nigerian actor believed to be responsible for worldwide losses in excess of $60 million with over $15.4 million originating from just one victim organization.

Techniques

Business Email Compromise (BEC) and Business Email Spoofing (BES) are two techniques that have recently gained popularity among these actors. To support these techniques, domains designed to impersonate legitimate organizations, “crypters” used to disguise commodity malware, and other methods are employed to gain a foothold within a victim network. Once inside, social engineering is used to fool victims into authorizing electronic bank transfers.

Download your copy of “SilverTerrier: The Next Evolution in Nigerian Cybercrime” to learn more about this threat.

PSA: Conference Invite used as a Lure by Operation Lotus Blossom Actors

Actors related to the Operation Lotus Blossom campaign continue their attack campaigns in the Asia Pacific region. It appears that these threat actors have begun using Palo Alto Networks upcoming Cyber Security Summit hosted on November 3, 2016 in Jakarta, Indonesia as a lure to compromise targeted individuals. The payload installed in attacks using this lure is a variant of the Emissary Trojan that we have analyzed in the past, which has direct links to threat actors associated with Operation Lotus Blossom.

As our readers and customers in Indonesia are likely recipients of this phishing e-mail, we want to release some key facts to clarify the situation.

  1. The malicious email will have an attachment named “[FREE INVITATIONS] CyberSecurity Summit.doc” that if opened will exploit CVE-2012-0158. The legitimate invitation emails from Palo Alto Networks did not carry any attachments.
  2. In response to this incident, we have halted our email invitations, so please disregard all new emails related to invitations to this conference, as it may be malicious.
  3. Individuals wishing to attend the conference should register on our official CYBERSECURITY SUMMIT – JAKARTA website.

Summit Invitation: Legitimate and Counterfeit

Palo Alto Networks hosts cyber security summits all over the world, and in many cases we send invitations via email to individuals we believe would be interested in attending. Figure 1 shows a legitimate invitation email in our most recent batch of invitations that has an image for its message body.

lotusblossom_1

Figure 1 Legitimate invitation email sent out regarding our Cyber Security Summit in Jakarta, Indonesia

We received a tip (thanks Marcus!) regarding a recent delivery document that we believe was attached to spear-phishing emails sent to individuals that would likely be interested in attending our conference. While we do not have detailed targeting information or access to the attack emails, we believe the malicious document was delivered as an email attachment with a filename of “[FREE INVITATIONS] CyberSecurity Summit.doc”. This file name contains the first portion of the subject of the legitimate invitation emails we sent out, suggesting the Operation Lotus Blossom actor had access to an inbox that received the invite email or received the email themselves.

The delivery document (SHA256: 61de3df463f94f8583934edb227b174c7e4473b89bd110a6f6ba44fad8c41943) attempts to exploit CVE-2012-0158 to install a payload and open a decoy document on the compromised system. The decoy is a Word document that contains an image from a previous invitation email, as seen in Figure 2.

lotusblossom_2

Figure 2 Decoy document showing image of previous invitation to the Cyber Security Summit in Jakarta

Emissary Payload

The payload associated with this attack is installed in the background while the decoy document is displayed. The payload itself is a variant of the Emissary Trojan that we have discussed in our blogs titled “Attack on French Diplomat Linked to Operation Lotus Blossom” and “Emissary Trojan Changelog: Did Operation Lotus Blossom Cause It to Evolve?”. The payload runs each time the operating system starts up thanks to the following registry key:

The Emissary payload is comprised of the following three files:

Filename %APPDATA%\Programs\Dsdcmsoon.dll
SHA256 aefa519feab9c8741af98ae2ddc287c404117e208cecd6479ee427f682814286
Description Loader Trojan responsible for injecting payload into Internet Explorer process

 

Filename %APPDATA%\Programs\DCMOS3124.DAT
SHA256 c9d1daab044a4d4e21e3b1f2da0b732a9d48d82c27e723d221be499bcb7f1aa3 (trimmed)
Description Emissary Trojan that runs within Internet Explorer process. This file is 500MB in size as it has a significant amount of junk data appended to the core DLL. The SHA256 is associated with the core DLL with the junk data trimmed.

 

Filename %APPDATA%\Programs\CVNX044.DAT
SHA256 121e844022c04dbe2d152195fbfab297701c050fc6d8d08ddb8a4c27f2be138e
Description Configuration file used by Emissary payload.

We decrypted the CVNX044.DAT file and found the following configuration for this Emissary payload:

This version of Emissary attempts to obtain the external IP address of the compromised system using the website “b4secure[.]com”. Figure 3 shows this HTTP GET request issued by Emissary to obtain the systems IP.

lotusblossom_3

Figure 3 Emissary version 6.4 issues an HTTP GET request to b4secure[.]com to obtain an IP address for the compromised system

The Emissary payload will communicate with the C2 server from its configuration file using HTTP GET requests. These requests will an added “MSG” field that contains the configuration values in encrypted and base64 encode form, along with the a custom “Cookie” field. Figure 4 shows an example C2 beacon from Emissary version 6.4, with the MSG field and the Cookie containing the GUID from the configuration, a field “fun” that specifies which function within Emissary issued the request and the system’s IP address.

lotusblossom_4

Figure 4 Emissary version 6.4 beacon to its C2 server

Insight into Threat Actor

During our analysis of the decoy document that used our Cyber Security Summit as a lure, we were able to determine how the threat actor created the decoy document. As shown in Figure 2 earlier in this blog, the decoy document was two pages that contained images that make up the legitimate invitation to the conference.

We were able to determine that the threat actor used Microsoft Word to crop these images from larger images, specifically screenshots of that the actor took of the images opened in Foxit’s PDF reader. Figure 5 and 6 show the original screenshots of the invitation that were cropped using Word’s cropping tool. These screenshots are of the threat actor’s system, which allows us to glean some intelligence on the actor.

lotusblossom_5

Figure 5 Original screenshot that actor cropped to create the first image within the decoy document

Figure 6 Original screenshot that the actor cropped to create the second image within decoy document

As you can see from the screenshots above, the threat actor is running Windows localized for Chinese users, which suggests the actor’s primary language is Chinese. The “CH” icon in the Windows tray shows that the built-in Windows input method editor (IME) is currently set to Chinese. Also, the screenshot shows a popular application in China called Sogou Pinyin, which is an IME that allows a user to type Chinese characters using Pinyin. Pinyin is critical to be able to type Chinese characters using a standard Latin alphabet keyboard, further suggesting the threat actor speaks Chinese.

Another interesting observation is the clock in the bottom right corner of the screenshots, which suggest that the threat actor took these screenshots at a local time of 8:35 and 8:36 AM on October 19, 2016. The decoy document was created on October 19, 2016 at 7:51 AM, but this timestamp is in UTC not local time. Obviously the screenshots could not have been taken in the future, suggesting that the actor is at least in UTC+1 or greater. We can speculate that if the actor’s clock was set to China Standard Time (UTC+8), then it would suggest that the final decoy document was created 7 hours and 15 minutes after the screenshots were taken.

Conclusion

Threat actors associated with Operation Lotus Blossom continue to carry out attack campaigns, which in this case involved a lure associated with a conference hosted by Palo Alto Networks. We have used emails to invite individuals to this conference; however, our legitimate invitation emails contained an image within the body of the email and did not contain any attachments. We have halted our invitation emails, but recipients of previous and future related emails should scrutinize them to determine if they were sent by these threat actors.

We have published a lot of content on the threat group involved and Emissary payload used in this attack. The payload installed appears to be a relatively new version of Emissary, specifically version 6.4. The decoy document itself contained cropped images of a screenshot that allowed us to determine the threat actor speaks Chinese as their primary language.

Lastly, if you received a malicious email that has an attachment named “[FREE INVITATIONS] CyberSecurity Summit.doc”, please check the system that accessed that file for the indicators of compromise listed at the bottom of this blog. For those individuals wishing to attend the conference, please register on our official CYBERSECURITY SUMMIT – JAKARTA website.

Palo Alto Networks customers are protected from the delivery document and payload associated with this attack, as both have malicious verdicts within WildFire. Palo Alto Networks customers are also protected via our Traps product, as it does not allow the delivery document to exploit the CVE-2012-0158 vulnerability. AutoFocus customers can track this delivery document and payload using the Emissary tag.

Indicators of Compromise

Delivery Document
61de3df463f94f8583934edb227b174c7e4473b89bd110a6f6ba44fad8c41943

Emissary Loader
aefa519feab9c8741af98ae2ddc287c404117e208cecd6479ee427f682814286

C2 server
103.249.31[.]49

Houdini’s Magic Reappearance

Unit 42 has observed a new version of Hworm (or Houdini) being used within multiple attacks. This blog outlines technical details of this new Hworm version and documents an attack campaign making use of the backdoor. Of the samples used in this attack, the first we observed were June 2016, while as-of publication we were still seeing attacks as recently as mid-October, suggesting that this is likely an active, ongoing campaign.

Deconstructing the Threats:

The investigation into this malware began while searching through WildFire execution reports within AutoFocus. Looking for newly submitted malicious samples with no family label, a unique mutex surfaced, “RCSTEST”. Pivoting around the creation of this mutex, as well as other dynamic behaviors, a group of samples slowly began to emerge. The group of samples has common delivery mechanisms, lures and decoy file themes, payloads (Hworm), as well as control infrastructure.

Samples from this attack came in the form of SFX files. The original filenames of these delivery files are related to political figures and groups in the Middle East and the Mediterranean. They include:

Mohamed Dahlan Abu Dhabi Meeting.exe
فضيحة من العيار الثقيل اردوغان يشرب الخمر.exe
صراعات داخلية في صفوف الاخوان المسلمين.exe
عملية اغتيال الدكتور محمد كمال.scr
الملك عبد الله يهدد دول الخليج ويتوعد دحلان.exe
بالفيديو امير سعودي يهين مواطنين على الهواء.scr

When executed each SFX file opens a decoy document, video, or URL, and eventually executes an Hworm payload in the background. The decoy files are similarly themed when compared to the above delivery file names. Figure 1 shows a screenshot from a video one sample opens as a decoy.

houdini_1

Figure 1 Decoy video

Another sample displays a YouTube video by dropping a .url shortcut and opening it using the system’s default web browser. Figure 2 illustrates the .url file contents:

houdini_2

Figure 2 .url file

When the .url file is opened, the above YouTube video is displayed as a decoy. It is unclear at this time if the uploader of this video has any relation to this particular attack

Besides decoys, the samples also execute Hworm payloads, all of which are packed. Each Hworm payload created a unique mutex (while some SFX files delivered the same Hworm payload). All of the samples beaconed to one of three network locations as shown in Figure 3:

houdini_3

houdini_4

houdini_5

Figure 3 C2 Infrastructure

While prior reports on Hworm have been published, we were unable to identify any report detailing this particular version of Hworm. Some previous versions would embed AutoIT scripts in resource sections of PE files while others would execute obfuscated VBS scripts. Some previous versions of the Hworm implant would embed data in the headers of HTTP requests or POST bodies as a method of command and control. Beacons of that HTTP protocol example are easily recognized by the use of ‘<|>’ as a delimiter and the URI of the request. This new version of Hworm uses a mixed binary and ASCII protocol over TCP. Figure 4 is a packet capture of the protocol used by Hworm samples in this attack. It includes the string “new_houdini”, the mutex used by the implant, the name of the user, the operating system version, the version of the implant, and the name of the foreground process:

houdini_6

Figure 4 Packet capture of new communications protocol

During the investigation of this malware a forum post on dev-point[.]com, an Arabic speaking technology and security forum, by a user with the handle “Houdini”, outlined plans for a rewrite of a backdoor in Delphi. This post occurred around July 2015.

Around October 2015, a password protected beta version of the builder used to create Delphi Hworm implants (a4c71f862757e3535b305a14ff9f268e6cf196b2e54b426f25fa65bf658a9242) was uploaded to VirusTotal. Unfortunately, the builder used to create the samples outlined in the above attack was not located. Unit 42 believes the samples used in the above attack are a version which were released after the beta.

Analyzing the Hworm Malcode:

Upon configuring and building a server, the builder prompts the user to save a VBS file and modifies a stub file to create the implant. The VBS file is used to load and inject the implant. It appears that the operators behind the above attack either chose to not use the VBS loader or the newer versions of the builder no longer produce a VBS script.

The VBS Loader:

The script contains three files encoded in base64. The first file is DynamicWrapperX (DCOM_DATA), the second file is the RunPE shellcode (LOADER_DATA), and the third file is the file which gets injected into host process (FILE_DATA). DynamicWrapperX provides access to all Windows APIs from a Visual Basic Script providing a wide range of functionality to this VBS script.

The configuration of the script is at the beginning of the file (Figure 5).

houdini_7

Figure 5 Script configuration section

In the above example, the script will use the registry as a startup method, it will drop itself into the system’s %appdata% directory using the filename myhworm.exe and it will inject itself into svchost.exe.

As the script executes it first adds one of three startup methods which will execute the script on Windows startup:

Following the installation of persistence, the script checks if the current environment is WOW64. If so, the script will execute:

The script then drops DynamicWrapperX in the configured installation directory with file extension “.bin”.

It will then register DynamicWrapperX:

Next, the script will load the registered object:

It registers /load VirtualAlloc and CallWindowProcW as functions which can be directly called in the script using “dcom.VirtualAlloc <arguments>”.

Using VirtualAlloc it will allocate new memory and copy RunPE shellcode (LOADER_DATA, loader.hex) and the to-be-injected binary (FILE_DATA) into memory.

Using CallWindowProcW the script will jump to the RunPE shellcode and the shellcode will inject the file (FILE_DATA) into the host process.  The host process is by default svchost.exe but for .NET files injection can occur into the file:

Figure 6 shows the main routine of the script:

houdini_8

Figure 6 Main routine

Figure 7shows a hex dump of LOADER_DATA (RunPE shellcode):

houdini_9

Figure 7 Hex dump of LOADER_DATA

Similarities in comments and coding styles between previous versions of the Hworm VBS script and the VBS script provided in this beta builder can be seen in Figure 1. Top is the VBS file from the HTTP version of Hworm, compared with the VBS script produced by the beta builder of Hworm (below).

houdini_10

houdini_11

Figure 8 Similarities between HWorm versions

The Beta Server:

The main server which the builder produces is developed in Delphi and is not encrypted. Unit 42 has seen variants packed with VMProtect and ASPack. In some versions of the Delphi Hworm implants discovered (unpacked beta versions) the settings are stored in the resource section RCData\“CONFIG” and are in clear text (Figure 9).

houdini_12

Figure 9 Settings

Some versions also have an unfinished PE spreader in the resource section (a65fd78951590833904bd27783b1032b7cc575220a12c6d6f44cb09061999af3). The spreader will terminate all running processes named “sm?rtp.exe” and execute a VBS file using wscript.exe:

houdini_13

Figure 10 Spreader

The server exports some unused functions (they all just have RET instruction). We have seen “wrom.exe” and “server.exe” used as the name in the export table (Figure 11).

houdini_14

Figure 11 Export table

The author used the open source library Indy Components for network communication. They also used BTMemoryModule to load DLLs from memory (without saving it on the disc).

The Hworm implants use a connect-back communication. This means the server (implant) connects back to the client (remotely controlling system). It also has some modules implemented in the server and each module uses its own socket for communication (on the same port defined in the configuration).

The following modules provide features of this malware:

  • Screenshot: Provides the ability to capture screenshots in JPEG/BMP formats
  • Keylogger: Provides the ability to log key strokes
  • Internet IO: Provides the ability to download and execute files from the internet. It also provides the ability to load the executables via the RunPE technique
  • File Manager: Provides the ability to list files and directories, delete, rename, and execute files, and upload or download files via TCP or HTTP
  • Password: Provides the ability to steal passwords from Firefox, Opera, and Chrome browsers
  • Misc: Provides the ability to list processes or modules and kill running processes
  • USB Notifier: Provides the ability to notify the controller when a USB device is attached
  • Houdini Client: Provides the main client, which contains the server’s configuration.

Final Thoughts:

The similarities in coding styles and features of the server, as well as languages and handles used by the author of the malware, lead us to believe the beta builder is a version of Hworm which was created somewhere between the HTTP version and the version used in the above outlined attack.

As this RAT can be found online in semi-public locations it is possible the malware is used by both surgical threat actors as well as within casual compromises. The above attack is only one such campaign Unit 42 has discovered using the Delphi versions of Hworm.

Palo Alto Networks customers can use AutoFocus to find all versions of Hworm samples using the “Hworm” tag.

Indicators:

Delphi Hworm Beta Builder
a4c71f862757e3535b305a14ff9f268e6cf196b2e54b426f25fa65bf658a9242

Delivery Files
70c55fef53fd4bdeb135ed68a7eead45e8d4ba7d17e0fd907e9770b2793b60ed
9af85e46344dadf1467c71d66865c7af98a23151025e7d8993bd9afc5150ad7d
773716bc2d313e17326471289a0b552f90086a2687fa958ef8cdb611cbc9a8c9
e0db0982c437c40ceb67970e0a776e9448f428e919200b5f7a0566c58680070c
1f45e5eca8f8882481b13fd4a67ffa88a1aa4d6e875a9c2e1fbf0b80e92d9588
5e42e61340942fc0c46a6668a7f54adbbb4792b01c819bcd3047e855116ae16f
fec925721b6563fec32d7a4cf8df777c647f0e24454fa783569f65cdadff9e03
106934ff7f6f93a371a4561fff23d69e6783512c38126fbd427ed4a886ca6e65
ba739f3f415efe005fbed6fcfcb1e6d3b3ae64e9a8d2b0566ab913f73530887c
0672e47513aefcbc3f7a9bd50849acf507a5454bc8c36580304105479c58772a

Payloads
386057a265619c43ef245857b66241a66822061ce9bd047556c4f3f1d262ef36
44b52baf2ecef2f928a13b17ba3a5552c32ca4a640e6421b8bc35ef5a113801b
8428857b0c7dfe43cf2182dd585dfdfd845697a11c31e91d909dc400222b4f78
d69e0456ddb11b979bf303b8bb9f87322bd2a9542dd9d9f716100c40bd6decd1
bd5d64234e1ac87955f1d86ee1af34bd8fd11e8edf3a449181234bb62816acab
774501f3c88ebdd409ec318d08af2350ec37fdbc11f32681f855e215e75440d7
c66b9e8aaa2ac4ce5b53b45ebb661ba7946f5b82e75865ae9e98510caff911a7

Decoy files
7916ca6ae6fdbfb45448f6dcff374d072d988d11aa15247a88167bf973ee2c0d
947d264a413f3353c43dafa0fd918bec75e8752a953b50843bc8134286d6f93f
9ddf2f2e6ac7da61c04c03f3f27af12cb85e096746f120235724a4ed93fac5aa
3d287cce7fe1caa5c033a4e6b94680c90a25cb3866837266130ba0fd8fab562c
444b82caf3c17ea74034c984aeca0f5b2e6547af88a0fb15953f2d5b80e3b448
3d3db84b6ad760540f638713e3f6a8daf8a226bd045351bcc72c6d22a7df8b3a
fffda1e2d794a5645f973900083a88ef38c3d20a89c5e59ca21412806db28197

Command and Control Network Locations
start.loginto[.]me
samah.sytes[.]net
52.42.161[.]75
78.47.96[.]17
136.243.104[.]200

Palo Alto Networks Researcher Discovers Four Critical Vulnerabilities in Adobe Flash Player

Palo Alto Networks was recently credited with the discovery of four new vulnerabilities affecting Adobe Flash Player.

Researcher Tao Yan discovered critical vulnerabilities CVE-2016-6982, CVE-2016-6983, CVE-2016-6984, CVE-2016-6985 affecting Adobe Flash Player. Descriptions of each, as well as details on affected versions and products, are included in the Adobe Security Bulletin. Adobe has released security updates for Adobe Flash Player.

For current customers with a Threat Prevention subscription, Palo Alto Networks has also released IPS signatures providing proactive protection for these vulnerabilities.

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Android and other ecosystems. By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users, and compromise enterprise, government and service provider networks.

Can I spam from here: An Unusually Clever Spambot Tests Blacklists

Unit 42 researchers recently observed an unusually clever spambot’s attempts to increase delivery efficacy by abusing reputation blacklist service APIs. Rather than sending spam as soon as the host is infected, the bot checks common blacklists to confirm its e-mails will actually be delivered, and if not, shuts itself down. This spambot, commonly downloaded by the Andromeda malware, has been observed delivering pharmaceutical industry spam as well as further propagating the main Andromeda bot. Microsoft refers to this family of malware as Sarvdap, however it must be noted that the detection appears somewhat generic. We have not identified any other public names for this malware, so rather than introduce a new name to the industry we’ll refer to this family as Sarvdap.

The Malware

The malware uses hardcoded addresses for function names and strings but to properly execute, it relies on the base of the module to be at 0x20010000.  If this is not the case, the malware will not be able to resolve function addresses or string references and will not function.  Upon initial execution the malware drops a copy of itself into the %windir% folder, executes a new svchost.exe process, initializes itself by allocating memory, injects the main bot code into this process, checks for a debugger to evade analysts, and creates the mutex "Start_Main_JSM_complete".

Once this stage is finished the malware checks the connection by attempting to connect to www.microsoft.com. If this connectivity check passes, the malware proceeds to enumerate multiple blacklist feeds to determine the host IP's reputation status. Provided the malware determines it is not located on a blacklisted host, which would cause it to terminate, it then beacons to its hardcoded command and control server over TCP port 2352. Details of this exchange are located in the Appendix below.

Provided the C2 is online and the host passes RBL checks, the malware expects to download and read a configuration file and use this information to populate fields in numerous data structures.  The server which served configurations was offline at the time of analysis and we were not able to pull the actual configuration file that was being served/expected.  In order to maintain accuracy, no suppositions will be made as to what the configuration contained; this is because the most interesting capability of this malware is still present within the original code.

spam1

Figure1. DNS lookups performed by the malware shown in AutoFocus.

Additional host enumeration commands were identified during memory analysis of this sample on a live host:

RBL Check Functionality

This malware is interesting because it contains a hardcoded list of commonly known blacklist servers. These servers are used as a means to check the infected host/zombie to determine if this infection is live and not on any of the provided blacklists.  The blacklists checked are from all around the world and rather comprehensive, indicating the author was trying to get global coverage rather than that of a specific region.

The semantics of this check are similar to code snippets found online. The pseudocode of this function can be seen below:

spam2

Figure 2. Pseudocode representing DNS RBL lookups and decision tree.

The GetHostByName() function is called for each blacklist URL to see if the IP is blacklisted, if the IP address is in the DNS blacklist then it will return the hostname (IP+BlacklistAddress) instead of an IP address.

If the IP is not on the blacklist, then the malware sends S5R: %u: OK (%u argument is going to be the current blacklist server that is being checked) to the server.  If the malware determines it is on a blacklisted host, the process will terminate.

Conclusion

Phishing emails remain a highly prevalent threat for enterprise, government and home users. For-hire, large-scale spam focused botnets continue to churn out hundreds of thousands of messages a day from compromised hosts. Sarvdap is particularly interesting not due to its scale, but rather due to its attempts to increase overall spam delivery by abusing reputation blacklists.

Palo Alto Networks customers are protected from this family through Threat Prevention and WildFire, and AutoFocus customers can track this malware via the Sarvdap tag.

Appendix: Example Phone Home Exchange

The following is an example of the exchange between the Sarvdap infected host. Note that the host identifier (srv_00000000000000000000000000000000) changes depending on the infected host.

Initial Beacon:

C2 Response:

Host Reply:

Note that the “rbl” field in the Host Reply message appears to report total number of blacklist hits.

IOCs

Sample used for analysis:
117172d6c59957be3c7a3c60cc0978ae430e3c15cb2e863cc5227b5fd0058ded

C2 Servers
dop.premiocastelloacaja[.]com
k1.clanupstairs[.]com
mall.giorgioinvernizzi[.]com

‘DealersChoice’ is Sofacy’s Flash Player Exploit Platform

Unit 42 has reported on various Sofacy group attacks over the last year, most recently with a post on Komplex, an OS X variant of a tool commonly used by the Sofacy group. In the same timeframe of the Komplex attacks, we collected several weaponized documents that use a tactic previously not observed in use by the Sofacy group. Weaponizing documents to exploit known Microsoft Word vulnerabilities is a common tactic deployed by many adversary groups, but in this example, we discovered RTF documents containing embedded OLE Word documents further containing embedded Adobe Flash (.SWF) files, designed to exploit Flash vulnerabilities rather than Microsoft Word. We have named this tool that generates these documents DealersChoice.

In addition to the discovery of this new tactic, we were able to identify two different variants of the embedded SWF files: the first being a standalone version containing a compressed payload which we have dubbed DealersChoice.A and a second variant being a much more modular version deploying additional anti-analysis techniques which we have dubbed DealersChoice.B. The unearthing of DealersChoice.B suggests a possible code evolution of the initial DealersChoice.A variant. Also, artifacts within DealersChoice suggests that Sofacy created it with the intentions to target both Windows and OSX operating systems, as DealersChoice could potentially be cross-platform due to its use of Adobe Flash files.

Targeting data of Sofacy group attacks remain limited, but we were able to identify a Ukrainian based defense contractor as well as the Ministry of Foreign Affairs of a nation state in that same region as being targeted by these attacks. The following post focuses on our study of DealersChoice, though it is worth noting that the U.S. government has recently attributed many of the same indicators of compromise associated with this entity during the DNC intrusion to Russia. (Sofacy, also known as APT 28, is a group commonly attributed to Russia.)

DealersChoice Attacks

Based on our telemetry, the attacks delivering DealersChoice documents occurred in August 2016 and focused primarily on organizations in countries that were part of the former Soviet republic. These malicious documents were delivered to a Ukrainian-based defense contractor as well as a Ministry of Foreign Affairs of a nation state in the same region, both via phishing attacks.

We were able to collect the actual phishing email targeting the Ukrainian based defense contractor, which can be seen in Figure 1. The emails shows a fairly well crafted phish, which had a spoofed sender address masquerading as part of the European Parliament’s Press Unit and used an existing person’s signature block to increase the appearance of legitimacy. The file attachment is a sample of the DealersChoice.A variant named Bulletin.doc containing details about a possible Russian invasion of Ukraine.

dealerschoice_1

Figure 1 Attack Email Delivered to Ukrainian defense organization and MFA of nearby country

If the recipient opens the Bulletin.doc attachment, a decoy document is displayed that has a title of “Russian invasion possible ‘at any minute’”, as seen in Figure 2. The contents of the decoy document were copied and pasted from an August 7, 2016 article posted at the Irish Times with very little modification.

dealerschoice_2

Figure 2 Decoy document displayed by DealersChoice documents on Possible Russian Invasion of Ukraine

During our analysis of the DealersChoice delivery document, we found a second, albeit different, version of DealersChoice that we do not have the associated targeting information, although we believe it was delivered in another phishing attack. This additional sample also opened a decoy document, which in this case was a document detailing Turkish politics. Again, it appears the threat actors took content from an online news article, as the contents in this decoy documents match an August 4, 2016 article posted to the Huffington Post. Figure 3 shows this decoy content, which in this case the threat actors appear to be less careful when they copied and pasted the content, as they introduced a spelling error (see “STANBUL”) at the beginning of the document.

dealerschoice_3

Figure 3 Decoy document opened by the additional DealersChoice sample

Deal with it

While the decoy documents are displayed to victim, the DealersChoice delivery document is busy carrying out malicious activities in an attempt to exploit the system. As previously mentioned, we have seen two different variations of DealersChoice. Both variations share a common core of components, however, how they exploit vulnerabilities and install the payload is markedly different. We will describe specifics on how both DealersChoice.A and DealersChoice.B operate in further sub-sections; however, we need to first describe the core components shared between the two.

At face value, DealersChoice is a rich text file (RTF) that has two responsibilities: display the decoy content embedded within the RTF and to load an embedded Word document (OLE). The Word document loads an embedded Flash file (SWF), which ultimately executes ActionScript that begins the malicious activity on the system. The ActionScript within the embedded Flash file, specifically the code and the actions it carries out is where the two variants of DealersChoice differ. As depicted in the diagram in Figure 4, the ActionScript in DealersChoice.A checks the version of Flash player and attempts to exploit a vulnerability by loading one of three embedded Flash files (SWF) to install an embedded payload. The ActionScript in DealersChoice.B differs dramatically, as it contacts a C2 server to receive a Flash file and a payload in order to exploit a vulnerability and install a Trojan.

dealerschoice_4

Figure 4 DealersChoice variants A and B use different approaches to achieve the same goal

As you can see, DealersChoice.A is more of a standalone toolkit with all components embedded within one file, whereas DealersChoice.B requires an active C2 server to obtain additional resources required to exploit the system. The filename “allInFlash.swf” of the Flash file embedded in the Word document of DealersChoice.A suggests it author intended it to be standalone as well.

DealersChoice.A

The DealersChoice.A variant is a standalone tool that contains all the necessary components to exploit the system. Based on embedded metadata, the DealersChoice.A SWF file was created on August 15, 2016, which is the same day in which the attack on the Ukrainian defense organization and a day before the attack on the targeted Ministry of Foreign Affairs.

The Flash SWF file that contained the malicious ActionScript also had four files embedded within it, named ExtSwf, ExtSwf1, ExtSwf2 and Main22_Pay. The ActionScript uses the zlib library to decompress the Main22_Pay file, which contains the shellcode and the payload that the shellcode will install on the system. The ActionScript will check the version of Flash player and will use zlib to decompress followed by a decryption routine (0xb7 as a key) on one of the ExtSwf, ExtSwf1 or ExtSwf2 files as an embedded SWF. The following ActionScript shows the custom algorithm that will decrypt the embedded SWF file:

The embedded SWF decrypted contains ActionScript that attempts to exploit a vulnerability. The purpose of aforementioned version check is to make sure that the correct malicious ActionScript is executed to exploit a vulnerability that the Flash player is vulnerable to. Table 1 shows the range of Flash player versions within DealersChoice.A, the embedded SWF file loaded and the associated vulnerability exploited by the loaded SWF.

Flash Player Version Embedded File CVE Exploited
11.5.502.146 - 19.0.0.207 ExtSwf1 CVE-2015-7645
20.0.0.228 - 20.0.0.306 ExtSwf CVE-2016-1019
20.0.0.306 - 21.0.0.242 ExtSwf2 CVE-2016-4117

Table 1 Versions of Flash player DealersChoice.A looks for and the associated vulnerability exploited

It appears the author(s) of DealersChoice did extensive research, as the range of versions for each vulnerability aligns with the vulnerable versions as described in the vendor’s advisory. It should also be noted that if the Flash version on the system is not within these ranges, DealersChoice will not load any of the malicious SWF files and therefore not attempt to exploit the system.

The result of exploiting any of the vulnerabilities listed in Table 1 is the execution of shellcode from the Main22_Pay file embedded within the SWF. The shellcode appears to use the Mersenne Twister algorithm with an initial seed value of 0xD01A7C2 to generate a pseudo-random number to use as a key to decrypt an embedded payload. Once decrypted, the shellcode installs the payload to %APPDATA%\Local\nshwmpfs.dll (SHA256: 73db52c0d4e31a00030b47b4f0fa7125000b19c6c9d462c3d0ce0f9d68f04e4c). The shellcode also creates the following registry key for persistence, which is the Office Test Persistence method used by Sofacy in previous attacks:

The ‘nshwmpfs.dll’ payload is a sample of Sofacy’s Carberp-based tool, which is very similar to the payload we described in our previous blog. This payload communicates with servicecdp[.]com as its C2 server, which is also mentioned in our prior blog as well, which suggests the Sofacy group is reusing their infrastructure across separate attacks.

While analyzing DealersChoice.A, we found an interesting artifact in the "ExtSwf" SWF file, which sets a flag with the following line of code if the system is running on Apple's OSX operating system:

This artifact is interesting as the shellcode executed relies on Windows APIs and the payload installed is a Windows DLL that would not run on OSX. This flag does suggest that the threat actors do consider the OSX operating system when developing their malicious exploit code in cross platform file types, such as Flash SWF files. While we cannot confirm this, it is possible that the threat actors could use DealersChoice.A to exploit and load an OSX Trojan if prepared with the appropriate shellcode.

DealersChoice.B

While researching DealersChoice.A, we found DealersChoice.B delivery documents that shared many of the same attributes, but were newer as the metadata within the embedded Flash file suggests they were created on August 25, 2016. DealersChoice.B documents are slightly different than their predecessors, specifically in that they do not contain three separate SWF files to exploit vulnerabilities on the system. Instead, DealersChoice.B relies on an active C2 server to provide a malicious SWF file to exploit a vulnerability, as well as the payload to execute. We presume that the threat actor checks the version of Flash player at the C2 and loads the malicious exploit code on the fly. We named these documents DealersChoice.B based on this difference. During our analysis, the C2 server was not operational so we were unable to obtain the malicious SWF or payload associated with this delivery document.

The core components of DealersChoice are in variant B, specifically an RTF file with an embedded Word document that loads an embedded Flash file (SWF). However, the Flash file in variant B are different than its predecessor, which contains one embedded file named Main64_Pay. The Main64_Pay file is decompressed using the zlib library and decrypted using the same algorithm as discussed in the DealersChoice.A section, but using 0x8f as a key instead of 0xb7. When loaded, Main64_Pay runs ActionScript in a function named “Main32”, which begins creating and sending HTTP GET request to the following URL:

The <Capabilities.serverString> portion of the URL is the output of the read only string provided within the flash.system.Capabilities.serverString property, which contains a string of system specific information that the webserver can use to determine the system's operating system, Flash version and more. During our analysis, the HTTP GET request appears as the following, which shows the system specific information sent to the C2 server:

dealerschoice_5

We believe the threat actors use the system information in this beacon for the following reasons (and possibly others):

  1. Determine the version of Flash to serve an appropriate malicious SWF to exploit a vulnerability in that version of Flash
  2. Determine the operating system to provide the appropriate payload, possibly making this a cross-platform exploit framework
  3. Filter out analysis systems based on operating system, architecture, screen resolution and/or language

If the C2 server is operational, it is going to respond to the beacon to “server.php” with data that include variables named "k1","k2","k3" and "k4". The function is going to use the value in the "k1" variable in another HTTP request to the following URL:

The C2 will respond to this request with a compressed and encrypted SWF file as the response data. The function uses the "k3" variable as a key to decrypt the SWF using the same encryption algorithm, and  will then make another request to the following URL:

The C2 server will respond to this request with compressed and encrypted binary data that the function will decrypt using the "k4" variable as a key using the same encryption algorithm. The decrypted binary data is the payload that is loaded into memory, suggesting the payload provided by the C2 server will be similar to the payload embedded in the other version of this toolkit, specifically starting with shellcode that decrypts and installs an embedded DLL.

Infrastructure

Amongst the two known DealersChoice variants, DealersChoice.A was found to drop a payload onto the victim host after exploiting an available Adobe Flash vulnerability which then communicated with a C2 server located at servicecdp[.]com. This C2 was previously reported on by Unit 42 in a June 2016 blog regarding an attack campaign targeting government organizations. The payload discovered communicating to servicecdp[.]com in June was then linked to other Sofacy group attacks in that time frame using the same Microsoft Word DLL side-loading technique.

While we were unable to retrieve the payload for DealersChoice.B, we were able to identify appexsrv[.]net as the C2 server used to deliver the malicious exploit code and the payload. Examination of passive DNS records did not show overlaps with previous attack campaigns, but we were able to identify two other domains, appexrv[.]com and upmonserv[.]net registered by the same email address, Kellen.green82@mail.com. These additional domains do not appear to be active C2s at this time. Figure 5 shows the infrastructure and samples associated with DealersChoice.

dealerschoice_6

Figure 5 Infrastructure and samples associated with DealersChoice

Evidence of a Tiered Infrastructure

The remote server used by DealersChoice.B to obtain its malicious exploit code and its payload is appexsrv[.]net (resolved to 95.183.50.23). During our analysis, the remote server did not serve a SWF file or a payload, but instead it responded with the following HTTP 503 error that is quite interesting:

The HTTP 503 error shows that the server at 95.183.50.23 is running a Squid HTTP proxy. The response shows that the proxy was unable to connect to the server that the proxy is configured to communicate, specifically with a 110 error that occurs when the connection timed out. This suggests that the server is most likely set up as a transparent proxy to forward HTTP requests to another server. The use of this Squid proxy suggests the threat actors want to conceal the true location of their C2 server.

Conclusion

DealersChoice is an exploit platform that allows the Sofacy threat group to exploit vulnerabilities in Adobe Flash. Cross-platform exploits are obviously a focus for Sofacy, as they included checks within DealersChoice to determine the operating system of the targeted system. These checks were specifically for Apple’s OS X operating system, which coupled with our discovery of Sofacy’s Komplex OSX Trojan suggests that this threat group is capable of operating in both Windows and Apple environments. Our analysis of DealersChoice has also led us to the discovery of a potential tiered infrastructure that leverages transparent proxies to hide the true location of Sofacy’s C2 servers.

Palo Alto Networks customers are protected from DealersChoice delivery documents and the Sofacy Carberp payload via:

  • WildFire detection of all known samples as malicious
  • All known C2s are classified as malicious in PAN-DB
  • Traps was able to block exploit code used by DealersChoice

AutoFocus customers can gather additional information on DealersChoice and Sofacy Carberp via:

  • AutoFocus tags have been created DealersChoice
  • Payload matches SofacyCarberp tag in AutoFocus

Indicators of Compromise

DealersChoice.A

dc2c3314ef4e6186b519af29a246679caa522acd0c44766ecb9df4d2d5f3995b

DealersChoice.B

cc68ed96ef3a67b156565acbea2db8ed911b2b31132032f3ef37413f8e2772c5

af9c1b97e03c0e89c5b09d6a7bd0ba7eb58a0e35908f5675f7889c0a8273ec81

DealersChoice.B C2

appexsrv[.]net

Sofacy Carberp

73db52c0d4e31a00030b47b4f0fa7125000b19c6c9d462c3d0ce0f9d68f04e4c

Sofacy Carberp C2

servicecdp[.]com

Palo Alto Networks Discovers Two Adobe Reader Privileged JavaScript Zero-Days

We recently discovered two zero-day vulnerabilities in Adobe Reader. Adobe has since released a patch (on October 6, 2016) to fix these vulnerabilities, which are named CVE-2016-6957 and CVE-2016-6958. These vulnerabilities could allow an attacker to compromise Adobe Reader by bypassing restrictions on JavaScript API execution (CVE-2016-6957) and security provisions that prevent arbitrary execution of scripts such as those written in Python (CVE-2016-6957). In this blog post, I will provide a technical walkthrough of these vulnerabilities, how they can be exploited, and how Palo Alto Networks customers are protected.

JavaScript in PDF Files

PDF file format is quite rich. It allows you to render text, pictures, and even 3D objects. It also contains a JavaScript engine that renders scripts embedded within a document. Such scripts are used to create dynamic content that interacts with the user. Adobe’s JavaScript API manual documents most of the usable functions and global variables from such scripts.

JavaScript within a PDF file is executed under one of two different contexts – “priviledged” and “nonprivileged.”. In “privileged” context, the set of API functions that can be called is richer and contains some functions that can be dangerous if not used with great care. These functions are called secured functions, marked in the JavaScript API Manual by a red ‘S’ enclosed in a circle.

zeroday_1

There is a set of vulnerabilities called ‘JavaScript Privilege Escalation’. Such bugs allow JavaScript executing under nonprivileged context to run arbitrary scripts under privileged context and thus call any desired, secured function. Let’s look at an example of this scenario.

Execution Stages

JavaScript code usually executes under nonprivileged context. There are three exceptions where the context is automatically escalated to privileged context by Adobe’s engine:

  1. Batch Application Initialization – JavaScript that executes when a document is loaded. This is done at a very early stage where an attacker cannot inject any JavaScript code. We will describe that stage in details later on.
  2. Console – JavaScript that is executed from Adobe Reader’s debugging console.
  3. Application Initialization Events – Callbacks for certain events.

zeroday_2

Batch Stage

At this stage Adobe Reader executes all the JavaScript files located under the
C:\Program Files\Adobe\Reader 11.0\Reader\Javascripts directory. Unless some custom script or plugin is deployed, this directory should only include the JSByteCodeWin.bin file.

JSByteCodeWin.bin consists of SpiderMonkey 1.8 XDR bytecode. It can be decompiled using a tool written by Gabor Molnar, which is found in his github. By decompiling it you can see that Adobe implements many functions in JavaScript rather than native code. Since some of these functions need to execute secured functions, there is a need for some mechanism that allows it to execute them later on and not just in early/unique stages.

Trusted Functions

To solve this problem, Adobe introduced the concept of trusted functions. These can be defined by the secured function app.trustedFunction. Such functions can call secured functions, regardless of the execution stage.

Adobe defines many functions as trusted functions at the Batch stage in JSByteCodeWin.bin, so they can later be called.

An example is the ANSendApprovalToAuthorEnabled function:

Being a trusted function doesn’t mean that its entire code executes under privileged context. This only means that the function can modify its context by calling app.beginPriv. Only code that executes in between app.beginPriv and app.endPriv block is privileged. Note that privileged context isn’t “passed down” between functions you call from within the beginPriv/endPriv block, and those will have to call app.beginPriv to raise their privilege level as well. If a function context was ended without decreasing the privilege level (by calling app.endPriv), it will automatically decrease at the end of its scope.

zeroday_3

Abusing Trusted Functions

Imagine Adobe defines a trusted function at ‘Batch’ stage that looks like this:

That means it can later raise its context to privileged by calling app.beginPriv. The vulnerableFunc function accepts an argument, ‘doc’, which it assumes to be of type ‘Doc’ object.

Since there are no type-safety checks in JavaScript, an attacker can pass any object as a doc argument. This allows attackers to execute any secured function they desire by abusing the above code.

We create a new object named ‘fakeDoc’. We then set the member ‘displayText’ to reference some secured function we want to call. Then, we call ‘vulnerableFunc’ passing ‘fakeDoc’ as an argument.

The vulnerableFunc function then changes context to privileged, calling app.beginPriv. This is allowed since vulnerableFunc was previously defined as a trusted function (for instance, at Batch stage). It then calls doc.displayText, which, at this point, references the secured function someSecuredFunction. This will then trigger a call to that secured function, which is allowed since the context is now privileged.

In this example, we abused the fact that a trusted function receives a callback as an argument. But since JavaScript is a very dynamic language, there are many other cases in which callbacks are unintentionally called. Getters and setters functions can be defined, global variables can be overridden, and much more.

The approach Adobe takes to fix such vulnerabilities is to tweak the JavaScript engine to prevent specific behaviors. Examples include preventing the call to a privileged function from getters/setters, eval(), etc.

ANSendApprovalToAuthorEnabled

While manually auditing all the trusted functions, I came across the function that follows:

This seems like the perfect candidate for calling an arbitrary secured function. It takes doc as an argument and calls doc.requestPermission twice – which is fully controlled. The only thing is that doc.requestPermission isn’t called within the privileged portion of ANSendApprovalToAuthorEnabled (not between app.beginPriv/app.endPriv). This is very easy to bypass though; all you have to do is to set requestPermission to reference app.beginPriv, which will raise the privilege level.

To bypass the hasAddr condition, all we have to do is set doc.Collab.initiatorEmail to ‘true’. Note that we cannot execute privileged code from there since this isn’t a function call but a member reference.

What happens then is the first call to doc.requestPermission is translated to a call to app.beginPriv that raises the context to privileged. Its return value is then compared to permisison.granted, which triggers the custom getter function I created. That function modifies fakeDoc.requestPermission to the secured function we want to call. ANSendApprovalToAuthorEnabled then calls doc.requestPermission again, this time calling an arbitrary secured function from privileged context.

When I investigated Adobe Reader, I didn’t review its latest version by mistake. After I upgraded it, I found out this vulnerability was patched and previously discovered by MWR Labs (CVE-2015-4451).

CVE-2015-4451 Patch

Still, the way my exploit failed surprised me. An exception was raised when I copied the reference to the app.beginPriv function into fakeDoc.requestPermission.

This means that the way Adobe fixed the bug is by preventing attackers from copying a reference to app.beginPriv. Without a reference to that function, they are unable to raise the context to privileged, so they can only call an unsecured function that isn’t a threat. Besides that, the bug still exists. So if I can find an alternative way to gain a reference to app.beginPriv, this bug is still exploitable.

JavaScript to the Rescue!

I tried to find a creative way to abuse JavaScript into copying a reference to app.beginPriv, and I came up with the following solution:

Rather than copying a reference to app.beginPriv straight from the global app object, I copied its prototype into another newly created object. Copying the prototype of an object means to copy all of its members and methods. I then gained a reference to beginPriv from that copied instance, which Adobe didn’t prevent. This means I can still abuse ANSendApprovalToAuthorEnabled into executing an arbitrary secured function.

Gaining Native Code Execution

In their presentation at DEFCON 2015, the HP ZDI team showed how to abuse such vulnerabilities into native code execution. This is done using undocumented, secured APIs that allow writing files to the disk.

zeroday_4

The function Collab.uriPutData can be used to write arbitrary files to the disk. The only thing is that it executes from the rendered process of Adobe Reader, which, in turn, executes at a low integrity level. This means that the locations where you can write files to are very limited. The strategy described in ZDI’s presentation only works for Adobe Acrobat Pro edition, which does not use the sandbox. They used Collab.uriPutData to write a DLL to the disk and abuse a DLL-hijacking bug in Adobe Reader to load it.

I tried to take a different approach that would work for the free edition of Adobe Reader too.

app.launchURL

This is a secured function that launches the browser to a URL, supplied as an argument. By abusing the above privileged JavaScript vulnerability, an attacker can call it.

zeroday_5

Calling this function I found out it launches the default browser. So I was wondering how it knows which executable file to launch (chrome.exe, firefox.exe, iexplore.exe, or any other browser).

Setting a breakpoint on kernel32!CreateProcessW, I noticed that it creates a process using shell32!ShellExecute.

The shell32!ShellExecute function is a winapi that launches the right process, given a file and an optional protocol handler. It knows which process to launch, matching a registry key for a protocol/extension. That is why the default browser is launched when calling app.launchURL – it registers itself as the handler of the ‘http:’ protocol. You can read more about it in the MSDN page for ShellExecute.

As opposed to what the documentation of app.launchURL states, you can launch a URL beginning with the ‘file://’. The only difference is that there’s a message box asking users whether they accept launching an application from that path. This means that we can call shell32!ShellExecute with an arbitrary path and an arbitrary extension. So I tried launching a PowerShell script ending with the ‘ps1’ extension.

That didn’t work; no PowerShell script was executed.

Extensions Denylist

Adobe did think that giving the ability to call shell32!ShellExecute is dangerous, so they created a denylist for all extensions they think allow an attacker to execute arbitrary code. That denylist is found under the following registry key:

I reviewed the list, trying to find an extension Adobe forgot to denylist. They did quite a good job of excluding all trivial extensions. I noticed that they tried to prevent Python scripts from executing:

But they forgot to denylist the ‘.pyw’ extension, which corresponds to Python File (no console). This means that an attacker can execute arbitrary Python scripts (if installed) using app.launchURL.

Conclusion

The JavaScript engine that Adobe implements contains functions that can introduce potential security vulnerabilities. In order to enforce security measures for the JavaScript API, they introduced features such as secured and trusted functions. But it is possible to abuse the nature of the JavaScript language to cause some unexpected behaviors when combined with those security features. Their efforts to mitigate such issues are thorough, but there still appear to be viable exploitation pathways. We thank Adobe for their quick attention to the issues described in this post, and for the release of the October 6 patch.

Palo Alto Networks customers who deploy our Next-Generation Security Platform are protected from zero-day vulnerabilities such as these. Threat Prevention (an essential service for our next-generation firewalls that includes capabilities such as application controlIPS, anti-malware, and command and control protection), WildFire, and URL Filtering services provide our customers with comprehensive protection and automatic updates against previously unknown threats within as little as 5 minutes.

zeroday_6

OilRig Malware Campaign Updates Toolset and Expands Targets

Since our first published analysis of the OilRig campaign in May 2016 , we have continued to monitor this group for new activity. In recent weeks we've discovered that the group have been actively updating their Clayslide delivery documents, as well as the Helminth backdoor used against victims. Additionally, the scope of organizations targeted by this group has expanded to not only include organizations within Saudi Arabia, but also a company in Qatar and government organizations in Turkey, Israel and the United States. Continue reading "OilRig Malware Campaign Updates Toolset and Expands Targets"

EITest Campaign Evolution: From Angler EK to Neutrino and Rig

EITest is a long-running campaign that uses exploit kits (EKs) to distribute a variety of malware. This campaign was first identified in October 2014, and we reviewed how the EITest campaign evolved in a March 2016 blog post. In this blog post, I’ll give an update of how the EITest campaign has evolved since March including the changes in patterns and the chain of events that lead to a successful infection. Continue reading "EITest Campaign Evolution: From Angler EK to Neutrino and Rig"

Confucius Says...Malware Families Get Further By Abusing Legitimate Websites

Introduction

When malware wants to communicate home, most use domain names, allowing them to resolve host names to IP addresses of their servers. In order to increase the likelihood of their malware successfully communicating home, cyber espionage threat actors are increasingly abusing legitimate web services, in lieu of DNS lookups to retrieve a command and control address. This negates the requirement to make DNS requests for domains that may be considered malicious and are therefore blocked. For attackers, that's an advantage because it allows their initial communications channel to be obscured amongst other traffic to legitimate services.

This blog post examines two similar malware families that utilize the aforementioned technique to abuse legitimate websites, their connections to each other, and their connections to known espionage campaigns. The first of which we call ‘CONFUCIUS_A’, a malware family that has links to a series of attacks associated with a backdoor attack method commonly known as SNEEPY (aka ByeByeShell) first reported by Rapid7 in 2013. The second of which we call ‘CONFUCIUS_B’, which has a loose link to the series of attacks associated with Operation Patchwork and The Hangover Report.

Confucius says… resolve your command and control domains using web services.

Continue reading "Confucius Says...Malware Families Get Further By Abusing Legitimate Websites"