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"

The Dukes R&D Finds a New Anti-Analysis Technique

Posted on by Robert Falcone

Threat actors constantly hunt for evasion and anti-analysis techniques in order to increase the success rate of their attacks and to lengthen the duration of their access on a compromised system. In some cases, threat groups use techniques they find discussed on the Internet during their operations, such as the Office Test Persistence method that the Sofacy group found within a blog published in 2014. While analyzing a recent attack that occurred on August 10, 2016, we observed an interesting anti-analysis technique used by the Dukes threat group (aka APT29, CozyBear, Office Monkeys) that we had not seen in the past. The use of the anti-analysis technique that we will discuss in this blog confirms that this threat group continually researches new anti-analysis techniques.

Continue reading "The Dukes R&D Finds a New Anti-Analysis Technique"

Pythons and Unicorns and Hancitor…Oh My! Decoding Binaries Through Emulation

Posted on by Jeff White

This blog post is a continuation of my previous post, VB Dropper and Shellcode for Hancitor Reveal New Techniques Behind Uptick, where we analyzed a new Visual Basic (VB) macro dropper and the accompanying shellcode. In the last post, we left off with having successfully identified where the shellcode carved out and decoded a binary from the Microsoft Word document.

Often when analysts are faced with an embedded payload for which they want to write a decoder, they simply re-write the assembly algorithm in their language of choice and process the file. The complexity of these algorithms varies when attempting to translate from machine code to a higher-level language. It can be quite frustrating at times, depending on the amount of coffee you’ve had and complexity of the algorithms.

In this post, I’ll show how we can use an attacker’s own decoding algorithm combined with CPU emulation to decode or decrypt payloads fairly easily by simply reusing the assembly in front of us. Specifically, I’ll be focusing on using the Unicorn Engine module in Python to run the attacker’s decoding functions within an emulated environment to extract our encoded payloads. Our end goal is to identify the command and control (C2) servers being used by the final Hancitor payload by running our Python script against the Microsoft Word document. Continue reading "Pythons and Unicorns and Hancitor…Oh My! Decoding Binaries Through Emulation"

Exploring the Cybercrime Underground: Part 2 – The Forum Ecosystem

Posted on by Rob Downs

In this second part of Unit 42’s Cybercrime Underground blog series, we dive into the cybercrime forum ecosystem and focus on observed cybercriminal roles, as well as prevalent tools and services bought and sold in the underground. The goal of this post is not to provide an exhaustive directory, but rather to provide additional context on the operations and highly prevalent threats observed within this ecosystem. Continue reading "Exploring the Cybercrime Underground: Part 2 – The Forum Ecosystem"

LabyREnth Capture the Flag (CTF): Unix Track Solutions

Posted on by Richard Wartell

Thanks to the incredibly talented community of threat researchers that participated in LabyREnth, the Unit 42 Capture the Flag (CTF) challenge. Now that the challenge is closed, we can finally reveal the solutions of each challenge track. We’ll be rolling out the solutions for one challenge track per week. Next up, the Unix track. Continue reading "LabyREnth Capture the Flag (CTF): Unix Track Solutions"

VB Dropper and Shellcode for Hancitor Reveal New Techniques Behind Uptick

Posted on by Jeff White

The Hancitor downloader has been relatively quiet since a major campaign back in June 2016. But over the past week, while performing research using Palo Alto Networks AutoFocus, we noticed a large uptick in the delivery of the Hancitor malware family as they shifted away from H1N1 to distribute Pony and Vawtrak executables. In parallel, we received reports from other firms and security researchers seeing similar activity, which pushed us to look into this further.

hani_01_alt

Figure 1 AutoFocus view of new sessions of Hancitor since July 2016

The delivery method for these documents remained consistent to other common malicious e-mail campaigns. Lures contained subjects related to recent invoices, or other matters requiring the victim’s attention, such as an overdue bill. These lures were expected, until we started digging into the actual documents attached and saw an interesting method within the Visual Basic (VB) macros in the attached documents used for dropping the malware.

This blog will review in detail the dropping technique, which isn’t technically new, but this was the first time we’ve seen it used in this way. The end goal is to identify where the binary was embedded, but we’ll cover the macro and the embedded shellcode throughout this post. Continue reading "VB Dropper and Shellcode for Hancitor Reveal New Techniques Behind Uptick"

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

Default Heading

Read the article Right Arrow