Black Hat USA Talks: Sidewinder Targeted Attack Against Android in The Golden Age of Ad Libs

While Google Play has little malware, many vulnerabilities exist in the apps as well as the Android system itself, and aggressive ad libs leak a lot of user privacy information. When they are combined together, more powerful targeted attacks can be conducted.

In this presentation, FireEye’s Yulong Zhang and Tao Wei will present one practical case of such attacks called “Sidewinder Targeted Attack.” It targets victims by intercepting location information reported from ad libs, which can be used to locate targeted areas such as a CEO’s office or some specific conference rooms. When the target is identified, “Sidewinder Targeted Attack” exploits popular vulnerabilities in ad libs, such as Javascript-binding-over-HTTP or dynamic-loading-over-HTTP, etc.

During the exploit, it is a well-known challenge to call Android services from injected native code due to the lack of Android application context. So they will also demonstrate how attackers can invoke Android services such as taking photos, calling phone numbers, sending SMS, reading/writing the clipboard, etc. Once intruding into the target, the attackers can exploit several Android vulnerabilities to get valuable privacy information or initiate more advanced attacks. We will reveal how to exploit new vulnerabilities we discovered in this phase.

In addition, they will show demos using real-world apps downloaded from Google Play.

Although they notified Google, ad vendors and app developers about related issues half a year ago, there are still millions of users under the threat of “Sidewinder Targeted Attacks” due to the slow patching/upgrading/fragmentation of the Android ecosystem.

Attend this presentation on August 7 at 10:15am PT in South Seas GH. Make sure to use #BHUSA and @FireEye if you plan to tweet highlights from the talk.

To view the whitepaper, click here.

Announcing the FLARE Team and The FLARE On Challenge

I would like to announce the formation of the FireEye Labs Advanced Reverse Engineering (FLARE) team. As part of FireEye Labs, the focus of this team is to support all of FireEye and Mandiant from a reverse engineering standpoint. Many FireEye groups have reversing engineering needs: Global Services discovers malware during incident response, Managed Defense constantly discovers threats on monitored client networks, and Products benefit from in-depth reversing to help improve detection capabilities.

We primarily focus on malware analysis, but we also perform red-teaming of software and organizations, and we develop tools to assist reverse engineering. Our research and tools assist with automatic malware triage to quickly get initial results out to incident responders in the field. Auto-unpackers unravel obfuscated samples without the need for an analyst. Automatic clustering and classifying samples helps identify if a binary is good or bad and whether we have analyzed it before. We develop reverse engineering scripts for IDA Pro and systems that help us quickly share our analysis results. We also write scripts that can help incident responders decrypt and interpret malware network traffic and host artifacts.

This elite technical enclave of reversers, malware analysts, researchers, and teachers, will team up with our FireEye Labs peers to help bring the best detection to our customers and promote knowledge sharing with the security research community. We’ll continue to provide technical training on malware analysis privately and at conferences like Black Hat. Look for us to present webinars on malware analysis and a blog series of scripts for IDA Pro to aid reverse engineering of malware.

The Challenge

To commemorate our launch, the FLARE team is hosting a challenge for all reverse engineers and malware analysts. We invite you to compete and test your skills. The challenge runs the gamut of skills we believe are necessary to succeed on the FLARE team. We invite everyone who is interested to solve the challenge and get their just reward!

The puzzles were developed by Richard Wartell, a reverse engineer with a PhD in “IDA Pro” (actually Computer Science, but his thesis used IDA Pro) from the University of Texas at Dallas where he worked on binary rewriting techniques for the x86 instruction set. He recently presented this work at the REcon conference in Montreal. At Mandiant Richard focused on incident response, but now on the FLARE team he reverse engineers malware, teaches malware classes, and helps develop our auto-unpacking technology.

As reverse engineers we’ve seen a variety of anti-reverse engineering techniques. Oftentimes the armoring malware authors employ is sophisticated and requires time to unravel. Sometimes it is misguided and easily circumvented.

Writing these binary puzzles has given us a chance to recreate some of the sophisticated (and sometimes ridiculous) techniques we see. The seven puzzles start with basic skills and escalate quickly to more difficult reversing tasks. At FLARE we have to deal with whatever challenges come our way, so the challenge reflects this. If you take on the challenge you might see malicious PDFs, .NET binaries, obfuscated PHP, Javascript, x86, x64, PE, ELF, Mach-O, and so on.

And after completing the final challenge, you’ll win a prize and be contacted by a FLARE team member. The full details can be found at: www.flare-on.com.

So on behalf of the FLARE team, I say Happy Reversing!

Turing Test in Reverse: New Sandbox-Evasion Techniques Seek Human Interaction

Last year, we published a paper titled Hot Knives Through Butter, Evading File-Based Sandboxes. In this paper, we explained many sandbox evasion methods-and today’s blog post adds to our growing catalog.

In the past, for example, we detailed the inner workings of a Trojan we dubbed UpClicker. The malware was notable for a then-novel technique to evade automated dynamic analysis systems (better known as sandboxes). UpClicker activates only when the left mouse button is clicked and released — a sign that it is running on a real, live, human-controlled PC rather than within an automated sandbox.

If the malware determines it is running in a sandbox, it lies dormant so that the sandbox doesn’t observe any suspicious behavior. Once the sandbox incorrectly clears it as a benign file, UpClicker goes on to a real computer to do its dirty work.

Last year, our colleague Rong Hwa shared the technical details of another sandbox-detecting Trojan called BaneChant. Like UpClicker, BaneChant uses human interaction to ascertain whether it is running in a virtual-machine environment, activating only after it detects more than three left clicks.

Since then, we’ve seen a spate of new malware that pushes the concept further. The newest sandbox-evading malware counters recent efforts to mimic human behavior in sandbox environments.

This blog post describes three tactics that FireEye has discovered in recent attacks.

Sandbox evasion: a primer

Most sandbox-evasion techniques fall into one of three categories:

Human interaction. This category includes malware that requires certain actions on the user’s part (a sign that the malicious code is running on a real-live PC rather than within an automated sandbox).

Configuration specific. Malware in this category takes advantage of the inherent constraints of file-based sandboxes. For example, knowing that a sandbox can spend, say, five minutes running suspicious code for analysis, malware creators can create code that automatically lies dormant for a longer period. If the code is still running after that, it’s probably not in a sandbox.

Environment specific. In this category, malware checks for telltale signs that its code is running in widely used VM environments. It checks for obscure files unique to VMware, for instance, or VM-specific hardware drivers.

The first category of sandbox evasion is one of the trickiest to counter. To fool sandbox-detecting malware, some vendors now simulate mouse movement and clicks in their virtual-machine environments to mimic human activity. But malware authors are upping the ante with even more sophisticated sandbox detection and evasion techniques.

To scroll is human

One malware we discovered lies dormant until the user scrolls to the second page of a Rich Text Format (RTF) document. So simulating human interaction with random or preprogrammed mouse movements isn’t enough to activate its malicious behavior.

Here’s how it works:

RTF documents consist of normal text, control words, and groups. Microsoft’s RTF specification includes a shape-drawing function, which includes a series of properties using the following syntax:

{\sp {\sn propertyName } {\sv propertyValueInformation}}

In this code, \sp is the control word for the drawing property, \sn is the property name, and \sv contains information about the property value. The code snippet in Figure 1 exploits a vulnerability that occurs when using an invalid \sv value for the pFragments shape property.

turing1

Figure 1: Code exploiting vulnerability in the RTF pFragments property

A closer look at the exploit code reveals a series of paragraph marks (./par) that appears before the exploit code.

turing2

Figure 2: A series of \.par (paragraph marks) that appears before the exploit code

The repeated paragraph marks push the exploit code to the second page of the RTF document. So the malicious code does not execute unless the document scrolls down to bring the exploit code up into the active window—more likely a deliberate act by a human user than simulated movement in a virtual machine.

When the RTF is scrolled down to the second page, then only the exploit code triggers, and as shown in Figure 3.0, it makes a call to URLDownloadToFileA function from the shell code to download an executable file.

turing3

Figure 3: Exploit code

In a typical file-based sandbox, where any mouse activity is random or preprogrammed, the RTF document’s second page will never appear. So the malicious code never executes, and nothing seems amiss in the sandbox analysis.

Two clicks and you’re out

Another sandbox-evading attack we spotted in recent attacks waits for more than two mouse clicks before executing. The two-click condition aims to more accurately determine whether an actual person is operating the targeted machine—most people click mouse buttons many times throughout the day—or a one-time programmed click designed to counter evasion techniques.

Here’s how this technique works:

The malware invokes the function Get AsyncKeyState in a loop. The function checks whether any mouse buttons are clicked by looking for the parameter 0×01, 0×02, or 0×04. (The parameter 0×01 is the virtual key code for the mouse’s left button, 0×02 is the code for the right button, and 0×04 is the code of the middle button.)

The instruction “xor edi edi” sets the edi to 0. If any of the buttons is pressed, the code invokes the instruction “inc edi,” as shown in Figure 4. After that, the instruction “cmp edi,2” checks whether the left, right or middle mouse buttons have been clicked more than two times. If so, code exits from the loop and gets to its real work. Otherwise, it stays under the radar, continuously checking for more mouse clicks.

turing4

Figure 4: Assembly code for evasion employing left, middle or right mouse clicks

Slow mouse, fast sandbox

Another recently discovered evasion technique involves checking for suspiciously fast mouse movement. To make sure an actual person is controlling the mouse or trackpad, malware code checks how quickly the cursor is moving. Superhuman speed is a telltale sign that the code is running in a sandbox.

This technique also makes use of the Windows function GetCursorPos, which retrieves the system’s cursor position. In the example malware code shown in Figure 5, GetCursorPos returns 614 for the x-axis value and 185 for the y-axis value.

turing5

Figure 5: Malware making first call to API GetCursorPos

After few instructions, malicious code again calls GetCursorPos to check whether the cursor position has changed. This time the function returns x= 1019 and y = 259, as shown in Figure 6.

turing6

Figure 6: Malware making second call to API GetCursorPos

A few instructions after the second GetCursorPos call, the malware code invokes the instruction “SUB EDI, DWORD PTR DS:[410F15]”. As shown in the figure 5.0, the value in EDI is 0×103 (259 in decimal) and DS:[410F15] = 0xB9 (185 in decimal). The value 259 and 185 are the Y coordinates retrieved from the two GetCursorPos calls. If the difference between the two Y-coordinate measurements is not 0, then the malware terminates.

turing7

Figure 7: Subtracting the Y coordinates to detect whether the cursor is moving too quickly to be human-controlled

In other words, if the cursor has moved between the two GetCursorPos calls (which are only a few instructions apart), then the malware concludes that the mouse movement is simulated. That’s too fast to be a real-world mouse or track pad in normal use, so the code must be running in a sandbox.

A growing challenge

Cybersecurity is a constant arms race. Simulating mouse movement and clicks is not enough to fool the most advanced sandbox-evading malware. Now malware authors are incorporating real-world behaviors into their evasion strategies.

Simulating these behaviors—the way actual people scroll documents, click the mouse button, and move the cursor— is a huge challenge for cybersecurity. Anticipating future evasion techniques might be even tougher. Expect malware authors to employ more novel techniques that look for that human touch.

In the paper “Hot Knives Through Butter: Evading File Based Sandboxes,” we’ve outlined 15 prior evasion techniques that have been used by advanced malware in real attacks to bypass file based sandboxes. We plan to continue updating the evasion series as we come across new techniques used by the latest threats and advanced malwares to bypass file based sandboxes.

Strategic Analysis: As Russia-Ukraine Conflict Continues, Malware Activity Rises

Cyber conflicts are a reflection of traditional, “real life” human conflicts. And the more serious the conflict in the “real world,” the more conspicuous its cyber shadow is likely to be. So let’s look at a serious, current international conflict – the one between Russia and Ukraine – to see if we can find its reflection in cyberspace.

One of the most reliable ways to discover computer network operations is to look for malware “callbacks” – the communications initiated from compromised computers to an attacker’s first-stage command-and-control (C2) server. At FireEye, we detect and analyze millions of such callbacks every year.

Table 1, below, shows the top 20 countries to receive first-stage malware callbacks over the last 16 months, according to the latest FireEye data.

ru1

Table 1 – Callback Infrastructure: the Last 16 Months

As we track the evolution of callbacks during this period, we see a likely correlation between the overall number of callbacks both to Russia and to Ukraine, and the intensification of the crisis between the two nations. The two key indicators we see are:

  • In 2013, Russia was, on average, #7 on this list; in 2014, its average rank is #5.
  • In 2013, Ukraine was, on average, #12 on this list; in 2014, its average rank is #9.

The biggest single monthly jump occurred in March 2014, when Russia moved from #7 to #3. In that same month, the following events also took place in Russia and Ukraine:

  • Russia’s parliament authorized the use of military force in Ukraine;
  • Vladimir Putin signed a bill incorporating the Crimean peninsula into the Russian Federation;
  • The U.S. and EU imposed travel bans and asset freezes on some senior Russian officials;
  • Russian military forces massed along the Ukrainian border; and
  • Russian energy giant Gazprom threatened to cut off Ukraine’s supply of gas.

The graphs below provide a closer look at the crucial month of March 2014, specifically comparing it to malware callback data from February.

Figure 1 shows a significant rise in malware callbacks to Russia from three of the top four source countries in February: Canada, South Korea, and the U.S. (Great Britain had a slight decline).

ru2

Figure 1 – Callbacks to Russia in Feb/Mar 2014: Top Four Countries

Figure 2 depicts the same, general rise in callbacks to Russia from many other countries around the world.

ru3

Figure 2 – Callbacks to Russia in Feb/Mar 2014: Rest of World

Figure 3 shows that the sharp rise in callbacks to Russia in March 2014 was seen in every FireEye industry vertical.

ru4

Figure 3 – Callbacks to Russia in Feb/Mar 2014: Industry Verticals

Tables 2 and 3, below, compare the rise in callbacks to Russia and Ukraine against the rise in callbacks to other countries for February and March 2014. It is important to note that nearly half of the world’s countries experienced a decrease in callbacks during this same time frame.

Table 2 shows the countries that received the highest increase, from February to March 2014, in the number of source countries sending callbacks to them. Ukraine and Russia both placed in the top ten countries worldwide, with Ukraine jumping from 29 source countries to 39, and Russia moving from 45 to 53.

ru5

Table 2 – Callbacks in 2014: Number of Source Countries

Table 3 shows the increase in the number of malware signatures associated with the callbacks to each country for February and March 2014. Ukraine does not appear in the top ten (it tied for #15), but Russia was #4 on this list (again, nearly half of the world’s countries showed no increase or a decrease).

ru6

Table 3 – Callbacks in 2014: Number of Malware Signatures

It is not my intention here to suggest that Russia and/or Ukraine are the sole threat actors within this data set. I also do not want to speculate too much on the precise motives of the attackers behind all of these callbacks. Within such a large volume of malware activity, there are likely to be lone hackers, “patriotic hackers,” cyber criminals, Russian and Ukrainian government operations, and cyber operations initiated by other nations.

What I want to convey in this blog is that generic, high-level traffic analysis – for which it is not always necessary to know the exact content or the original source of individual communications – might be used to draw a link between large-scale malware activity and important geopolitical events. In other words, the rise in callbacks to Russia and Ukraine (or to any other country or region of the world) during high levels of geopolitical tension suggests strongly that computer network operations are being used as one way to gain competitive advantage in the conflict.

In the near future, we will apply this methodology to other global occurrences to further identify patterns that could provide valuable advanced threat protection insights.

Operation Saffron Rose

There is evolution and development underway within Iranian-based hacker groups that coincides with Iran’s efforts at controlling political dissent and expanding offensive cyber capabilities. The capabilities of threat actors operating from Iran have traditionally been considered limited and have focused on politically motivated website defacement and DDoS attacks.

Our team has published a report that documents the activities of an Iran-based group, known as the Ajax Security Team, which has been targeting both US defense companies as well as those in Iran who are using popular anti-censorship tools to bypass Internet censorship controls in the country.

This group, which has its roots in popular Iranian hacker forums such as Ashiyane and Shabgard, has engaged in website defacements since 2010. However, by 2014, this group had transitioned to malware-based espionage, using a methodology consistent with other advanced persistent threats in this region.

It is unclear if the Ajax Security Team operates in isolation or if they are a part of a larger coordinated effort. We have observed this group leverage varied social engineering tactics as a means to lure their targets into infecting themselves with malware. They use malware tools that do not appear to be publicly available. Although we have not observed the use of exploits as a means to infect victims, members of the Ajax Security Team have previously used exploit code in web site defacement operations.

The objectives of this group are consistent with Iran’s efforts at controlling political dissent and expanding offensive cyber capabilities, but we believe that members of the group may also be dabbling in traditional cybercrime. This indicates that there is a considerable grey area between the cyber espionage capabilities of Iran’s hacker groups and any direct Iranian government or military involvement.

Although the Ajax Security Team’s capabilities remain unclear, we believe that their current operations have been somewhat successful. We assess that if these actors continue the current pace of their operations they will improve their capabilities in the mid-term.

To view a full version of the report on “Operation Saffron Rose,” please visit: https://www.fireeyesolution.com/resources/pdfs/fireeye-operation-saffron-rose.pdf.

RSA 2014: New Thinking to Narrow the Security Gap

Attacking the gap and preparing for the new frontiers in security is our focus for the 2014 RSA Conference. Around the show floor, in our booth, and in the conference tracks, you’ll hear from FireEye experts on how to address this new frontier. We’ll have updates on the latest threats from our research teams as well as live demonstrations of our new FireEye Security Platform. Find us at our booth and make sure to catch our research team presenting throughout the conference:

  • Kevin Mandia, SVP and COO for FireEye, Inc., will be presenting on the New Frontiers in Security on Tuesday, February 25 at 2:40 PM. Listen in as Kevin joins a group of industry experts to discuss how organizations must rethink their security approach in this Security Mash-Up panel session.
  • Also on Tuesday, February 25 at 1:20 PM, FireEye’s Zheng Bu Vice President, FireEye Research Labs will present Twilight of Legacy AV Models - A Different Long Tail Story. Malware has a very short lifetime. But how short is it? The findings may surprise you and while large portions of malware objects only appear once, the lifetime of malware forms a very fat-head long-tail chart. The anti-virus industry presents a reactive model, and it performs very badly on the fat-head. In this session Bu will present the study, the challenge and a possible mitigation plan.
  • On Wednesday, February 26 at 12 PM, Amanda Stewart, Malware Research Engineer at FireEye, will dig into techniques to sneak malware past Anti-Virus scanners. APT developers used this technique in a highly-targeted attack against a Fortune 50 company last year. Learn more during this must-see technical session, DLL Side-Loading: A Thorn in the Side of the Anti-Virus (AV) Industry.
  • One year after the well-known APT 1 Report, Kevin Mandia will discuss the fallout from exposing China’s espionage effort during the State of the Hack: One Year after the APT1 Report technical session. While there will be other sessions at RSA 2014 around the industry changing APT1 report, come hear directly from the source on the latest approaches attackers are using to compromise organizations and what organizations should be doing to narrow their security gap. Kevin will be speaking on Thursday, February 27 at 3:55 PM.

Don’t forget to stop by our booth located at North Expo #2813 to learn more about the newly expanded FireEye Security Platform, which integrates expertise from Mandiant and is designed to give customers one solution to go from threat alert to remediation. We’ll have live demonstrations of all the new FireEye products. In the mean time, be sure to follow @FireEye for the latest threat research and updates from the company.

An Encounter with Trojan Nap

[Update: February 14, 2013] We recently encountered a stealthy malware that employs extended sleep calls to evade automated analysis systems capturing its behavior. It further makes use of the fast flux technique in order to hide the identity of the attacker controlling it. We call it Trojan Nap. The purpose of this blog is to share the technical details of the execution steps by Nap.

Continue reading »

Who Do I Trust? Me, That’s Who…

Malware using digital signatures to dupe endpoints has been on the rise. We saw this tactic pick up momentum with the rise of attacks like Stuxnet, Duqu, and Flame (to name a few). As the problem continues to grow, it affects both enterprises and the companies whose digital signatures are hijacked and used for evil. This is especially a problem when the trusted signer is a well-known organization, increasing the likelihood that files bearing their signature will be trusted. We’ve all seen the headlines…

It happened with Microsoft. And Adobe. And the list goes on…

Continue reading »

To Russia With Targeted Attack

Looking at the human aspect of offensive cyber operations is one of the most interesting parts of a malware analyst’s day. Malware that was generated by an algorithm, such as a polymorphic PDF, is a little boring because you know you aren’t fighting against a human on the other side of the keyboard. However, when dealing with nation-state sponsored intrusions, or at least deliberate attacks against a specific group of people, it’s interesting to look at the different stages of the attack, from victim selection, to attack method, to what kind of data is exfiltrated. We recently discovered an attack that appeared to be against primarily Russian targets.

Continue reading »