Exploit Kits Exposed: Automated Attacks at Scale

Posted on by Scott Simkin

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

Posted on by Peter Renals

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

Posted on by Robert Falcone

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

Posted on by Anthony Kasza

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

Posted on by Ryan Olson

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

Posted on by Brandon Levene

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

Posted on by Robert Falcone

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

Posted on by Gal De Leon

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 control, IPS, 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

Posted on by Josh Grunzweig

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

Posted on by Brad Duncan

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

Posted on by Tom Lancaster

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"

Sofacy’s ‘Komplex’ OS X Trojan

Posted on by Dani Creus

Unit 42 researchers identified a new OS X Trojan associated with the Sofacy group that we are now tracking with the 'Komplex' tag using the Palo Alto Networks AutoFocus threat intelligence platform.

The Sofacy group, also known as APT28, Pawn Storm, Fancy Bear, and Sednit, continues to add to the variety of tools they use in attacks; in this case, targeting individuals in the aerospace industry running the OS X operating system. During our analysis, we determined that Komplex was used in a previous attack campaign targeting individuals running OS X that exploited a vulnerability in the MacKeeper antivirus application to deliver Komplex as a payload. Komplex shares a significant amount of functionality and traits with another tool used by Sofacy - the Carberp variant that Sofacy had used in previous attack campaigns on systems running Windows. In addition to shared code and functionality, we also discovered Komplex command and control (C2) domains that overlapped with previously identified phishing campaign infrastructures associated with the Sofacy group. Continue reading "Sofacy’s ‘Komplex’ OS X Trojan"

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

Posted on by Ryan Olson

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

Researcher Tao Yan discovered critical vulnerabilities CVE-2016-4182, CVE-2016-4237, CVE-2016-4238, CVE-2016-4281, CVE-2016-4282, CVE-2016-4283, CVE-2016-4284, and CVE-2016-4285 affecting Adobe Flash Player. Descriptions of each, as well as details on affected versions and products, are included in the following Adobe Security Bulletins:

Continue reading "Palo Alto Networks Researcher Discovers Eight Critical Vulnerabilities in Adobe Flash Player"

MILE TEA: Cyber Espionage Campaign Targets Asia Pacific Businesses and Government Agencies

Posted on by Kaoru Hayashi

In June 2016, Unit 42 published the blog post “Tracking Elirks Variants in Japan: Similarities to Previous Attacks”, in which we described the resemblance of attacks using the Elirks malware family in Japan and Taiwan.

Since then, we continued tracking this threat using Palo Alto Networks AutoFocus and discovered more details of the attacks, including target information. We’ve seen examples of this attack campaign, which we’ve named “MILE TEA” (MIcrass Logedrut Elirks TEA), appearing as early as 2011, and that it has since expanded the scope of targets. It involves multiple malware families and often tricks targets by sending purported flight e-tickets in email attachments. The identified targets include three separate Japanese trading companies, a Japanese petroleum company, a mobile phone organization based in Japan, the Beijing office of a public organization of Japan, and a government agency in Taiwan. Continue reading "MILE TEA: Cyber Espionage Campaign Targets Asia Pacific Businesses and Government Agencies"

DualToy: New Windows Trojan Sideloads Risky Apps to Android and iOS Devices

Posted on by Claud Xiao

Over the past two years, we’ve observed many cases of Microsoft Windows and Apple iOS malware designed to attack mobile devices. This attack vector is increasingly popular with malicious actors as almost everyone on the planet carries at least one mobile device they interact with throughout any given day. Thanks to a relative lack of security controls applied to mobile devices, these devices have become very attractive targets for a broad range of malicious actors. For example:

  • WireLurker installed malicious apps on non-jailbroken iPhones
  • Six different Trojan, Adware and HackTool families launched “BackStab” attacks to steal backup archives of iOS and BlackBerry devices
  • The HackingTeam’s RCS delivered its Spyware from infected PCs and Macs to jailbroken iOS devices and BlackBerry phones

Recently, we discovered another Windows Trojan we named “DualToy” which side loads malicious or risky apps to both Android and iOS devices via a USB connection. Continue reading "DualToy: New Windows Trojan Sideloads Risky Apps to Android and iOS Devices"

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

Default Heading

Read the article Right Arrow