We recently encountered some exploits from Angler Exploit Kit (EK) that are completely evading Microsoft’s Enhanced Mitigation Experience Toolkit (EMET). This is something we are seeing for the first time in the wild, and we only observed it affecting systems running Windows 7.

Angler EK uses complex multi-layered code obfuscation and leverages multiple exploits, as seen in Figure 1 and Figure 2. These capabilities make Angler EK one of the more sophisticated exploit kits in use at this time.

Figure 1: An excerpt of obfuscated javascript implemented by Angler EK is provided

Figure 2: Angler JavaScript Obfuscation

Within the deobfuscated JavaScript, which an attacker might inject into a webpage, we found that objects were being created for Flash (Figure 3) and Silverlight (Figure 4) to exploit vulnerabilities in those plugins.

Figure 3: Flash Object usage in deobfuscated content

Figure 4: Silverlight Object usage in deobfuscated content

While exploiting Flash and other third party frameworks is common practice, we identified that Angler EK has implemented exploits that are successfully evading EMET.

Evasion:

EMET consists of many exploit mitigations that thwart modern exploit kit attempts. These exploit mitigations include:

1. ASR
2. EAF
3. EAF+
4. Caller Check
5. SimExecFlow
6. StackPivot
7. MemProt

Modern exploit kits may contain VBScript, Flash, Silverlight and even Internet Explorer exploits. Out of these, VBScript exploits are mitigated by ASR check and there is no evasion for that as of now, since EMET simply restricts vbscript.dll from being loaded.

The ability of Angler EK to evade EMET mitigations and successfully exploit Flash and Silverlight is fairly sophisticated in our opinion. These exploits do not utilize the usual return oriented programming to evade DEP. Data Execution Prevention (DEP) is a mitigation developed to prevent the execution of code in certain parts of memory. The Angler EK uses exploits that do not utilize common return oriented programming (ROP) techniques to evade DEP. Instead, they use Flash.ocx and Coreclr.dll’s inbuilt routines to call VirtualProtect and VirtualAlloc, respectively, with PAGE_EXECUTE_READWRITE, thus evading DEP and evading return address validation-based heuristics.

DEP Evasion:

As seen in Figure 5, the Silverlight exploit uses coreclr.dll’s routines to evade DEP before shellcode is executed.

Figure 5: VirtualAlloc stub in coreclr.dll, helps mitigate DEP without ROP

The Flash exploit uses Flash.ocx’s routines to call VirtualProtect for DEP evasion before shellcode is executed, as seen in Figure 6. The same routine is then used to jump to shellcode.

Figure 6: flash.ocx

Since return address validation heuristics are evaded by utilizing these inbuilt functions from within ActionScript and Silverlight Engine, ROP checks by EMET’s DEP capability are not effective. EMET provides other protections, however, which Angler EK is also evading. Export Address Table Filtering (EAF) and EAF+ are two capabilities that seek to protect the contents of memory and prevent exploit code from identifying where things are loaded.

The following is the working chain of the payload after successfully evading DEP mitigations. Note that the APIs will differ for both fileless and process oriented infections. However the evasion code was found and executed in both the cases successfully evading EMET.

Evasion of EAF in Silverlight Exploit:

As we can see in Figure 7, Silverlight JIT code transfers control to shellcode.

Figure 7: Call Shellcode

After that, the shellcode queries User32 Import Address Table (IAT) to pull API addresses, thus evading EAF. We can see the same in Figure 8.

Figure 8: Shellcode reads IAT

The memory address of the GetProcAddress function also gets resolved by using IAT of user32.dll. After that, the APIs seen in Figure 9 get resolved from GetProcAddress.

Figure 9: List of APIs

Once the API addresses are resolved, EMET has no validation on API calls with regard to where they are coming from, thus resulting in the successful execution of the malicious program.

Note that Silverlight exploits are not subjected to EAF+ because “coreclr.dll” and other required dlls are not present in the default EMET configuration.

Evasion of EAF+ in Flash exploit:

1. Flash uses arbitrary read and write to read memory and finds base address of “flash.ocx”.
2. It finds Import Directory Table of flash.ocx and loops through ModuleName until it reaches “kernel32.dll”.
3. Reads the content of RvaImportLookupTable and RvaImportAddressTable, to locate the APIs that will be useful later along with VirtualAlloc, which will be used in first stage.

After identifying the required addresses, ActionScript code fills those values in already existing buffer of shellcode, performs ROPless VirtualProtect on the shellcode region to evade the DEP, and then transfers the control to the malicious shellcode.

As we can see in Figure 10, the first stage shellcode will call VirtualAlloc and copy the second stage shellcode to that memory, transferring the control to that code.

Figure 10: Call VirtualAlloc and second stage shellcode

As seen in Figure 11, in the second stage shellcode, the API resolution is again based on the IAT reading, which evades EAF. Additionally, several calls to GetProcAddress are performed, which go completely unscrutinized. As stated before, API calls have no validation from EMET with regard to where they are coming from, validation is only performed through EAT hardware breakpoints.

Figure 11: Shellcode reads IAT

Afterwards, the exploit shellcode launches the TeslaCrypt process under normal exploitation context. In the case of fileless infections, the shellcode does not launch anything, but changes the protection constant of kernel32!ExitProcess to RWX for 5 bytes, then overwrites it with an inline jump to ntdll!RtlExitUserThread. This ensures the process stays alive even after closing the tab or closing the Internet Explorer window. In either of above cases, the attacker has full control over shellcode and it can pretty much execute anything it wants without EMET doing anything.

In Figure 12 and Figure 13, we can see the successful execution of TeslaCrypt ransomware with the latest version of EMET installed on the system. Please note that we have tested this only on Windows 7.

Figure 12: EMET v5.5

Figure 13: EMET bypass - Successful execution of TeslaCrypt binary

Conclusion

The level of sophistication in exploits kit has increased significantly throughout the years. Where obfuscation and new zero days were once the only additions in the development cycle, evasive code has now been observed being embedded into the framework and shellcode.

Remediation guidance:

Although there are no quick solutions for the DEP, EAF, and EAF+ evasion techniques, organizations can mitigate this threat through a robust vulnerability management program for end user systems, which includes the installation of security updates for third party software. Applications such as Adobe Flash, web browsers, and Oracle Java should be patched routinely, prioritizing critical patches, or removed if possible. Because the web browser plays an important role in the infection process, disabling browser plugins for Flash or Silverlight may also reduce the browser attack surface.

At FireEye Labs we have an automated system designed to proactively detect newly registered malicious domains. This system observed some phishing domains registered in the first quarter of 2016 that were designed to appear as legitimate Apple domains. These phony Apple domains were involved in phishing attacks against Apple iCloud users in China and UK. In the past we have observed several phishing domains targeting Apple, Google and Yahoo users; however, these campaigns are unique as they are serving the same malicious phishing content from different domains to target Apple users.

Since January 2016 we have observed several phishing campaigns targeting the Apple IDs and passwords of Apple users. Apple provides all of its customers with an Apple ID, a centralized personal account that gives access to iCloud and other Apple features and services such as the iTunes Store and App Store. Users will provide their Apple ID to sign in to iCloud[.]com, and use the same Apple ID to set up iCloud on their iPhone, iPad, iPod Touch, Mac, or Windows computer.

iCloud ensures that users always have the latest versions of their important information –  including documents, photos, notes, and contacts – on all of their Apple devices. iCloud provides an easy interface to share photos, calendars, locations and more with friends and family, and even helps users find their device if they lose it. Perhaps most importantly, its iCloud Keychain feature allows user to store passwords and credit card information and have it entered automatically on their iOS devices and Mac computers.

Anyone with access to an Apple ID, password and some additional information, such as date of birth and device screen lock code, can completely take over the device and use the credit card information to impersonate the user and make purchases via the Apple Store.

This blog highlights some highly organized and sophisticated phishing attack campaigns we observed targeting Apple customers.

Campaign 1: Zycode phishing campaign targeting Apple's Chinese Customers

This phishing kit is named “zycode” after the value of a password variable embedded in the JavaScript code which all these domains serve in their HTTP responses.

The following is a list of phishing domains targeting Apple users detected by our automated system in March 2016. None of these domains are registered by Apple, nor are they pointing to Apple infrastructure:

The list shows that the attackers are attempting to mimic websites related to iTunes, iCloud and Apple ID, which are designed to lure and trick victims into submitting their Apple IDs.

Most of these domains appeared as an Apple login interface for Apple ID, iTunes and iCloud. The domains were serving highly sophisticated, obfuscated and suspicious JavaScripts, which was creating the phishing HTML content on the web page. This technique is effective against anti-phishing systems that rely on the HTML content and analyze the forms.

From March 7 to March 12, the following domains used for Apple ID phishing were observed, all of which were registered by a few entities in China using a qq[.]com email address: iCloud-Apple-apleid[.]com, Appleid-xyw[.]com, itnues-appid[.]com, AppleidApplecwy[.]com, appie-itnues[.]com, AppleidApplecwy[.]com, Appleid-xyw[.]com, Appleid-yun-iCloud[.]com, iCloud-Apple-apleid[.]com, iphone-ioslock[.]com, iphone-appdw[.]com.

From March 13 to March 20, we observed these new domains using the exact same phishing content, and having similar registrants: iCloud-Appleid-yun[.]win, iClouddd[.]top, iCloudee[.]top, iCloud-findip[.]com, iCloudhh[.]top, ioslock-Apple[.]com, ioslock-iphone[.]com, iphone-iosl0ck[.]com, lcloudmid[.]com

On March 30, we observed the following newly registered domains serving this same content: iCloud-mail-Apple[.]com, Apple-web-icluod[.]com, Apple-web-icluodid[.]com, AppleidAppleiph[.]com , icluod-web-ios[.]com and ios-web-Apple[.]com

Phishing Content and Analysis

Phishing content is usually available in the form of simple HTML, referring to images that mimic a target brand and a form to collect user credentials. Phishing detection systems look for special features within the HTML content of the page, which are used to develop detection heuristics. This campaign is unique as a simple GET request to any of these domains results in an encoded JavaScript content in the response, which does not reveal its true intention unless executed inside a web browser or a JavaScript emulator. For example, the following is a brief portion of the encoded string taken from the code.

This encoded string strHTML goes through a complex sequence of around 23 decrypting/decoding functions that include number system conversions, pseudo-random pattern modifiers followed by XOR decoding using a fixed key or password “zycode” for the actual HTML phishing content to be finally created (refer to Figure 15 and Figure 16 in Appendix 1 for complete code). Phishing detection systems that rely solely on the HTML in the response section will completely fail to detect the code generated using this technique.

Once loaded into the web browser, this obfuscated JavaScript creates an iCloud phishing page. This page is shown in Figure 1.

Figure 1: The page created by the obfuscated JavaScript as displayed in the browser

The page is created by the de-obfuscated content seen in Figure 2.

Figure 2: Deobfuscated content

Burp Suite is a tool to secure and penetrate web applications: https://portswigger[.]net/burp/.  The Burp session of a user supplying login and password to the HTML form is shown in Figure 3. Here we can see 5 variables (u,p,x,y and cc) and a cookie being sent via HTTP POST method to the page save.php.

Figure 3: Burp session

After the user enters a login and password, they are redirected and presented with the following Chinese Apple page, seen in Figure 4:  http://iClouddd[.]top/ask2.asp?MNWTK=25077126670584.html

Figure 4: Phishing page

On this page, all the links correctly point towards Apple[.]com, as can be seen in the HTML:

  * Apple <http://www.Apple[.]com/cn/>
  * <http://www.Apple[.]com/cn/shop/goto/bag>
  * Apple <http://www.Apple[.]com/cn/>
  * Mac <http://www.Apple[.]com/cn/mac/>
  * iPad <http://www.Apple[.]com/cn/ipad/>
  * iPhone <http://www.Apple[.]com/cn/iphone/>
  * Watch <http://www.Apple[.]com/cn/watch/>
  * Music <http://www.Apple[.]com/cn/music/>
  * <http://www.Apple[.]com/cn/support/>
  * Apple[.]com <http://www.Apple[.]com/cn/search>
  * <http://www.Apple[.]com/cn/shop/goto/bag>

Apple ID <https://Appleid.Apple[.]com/account/home>

  * <https://Appleid.Apple[.]com/zh_CN/signin>
  * Apple ID <https://Appleid.Apple[.]com/zh_CN/account>
  * <https://Appleid.Apple[.]com/zh_CN/#!faq>

When translated using Google Translate, the Chinese text written in the middle of the page (Figure 4) reads: “Verify your birth date or your device screen lock to continue”.

Next the user was presented with an ask3.asp webpage shown in Figure 5.

Figure 5: Phishing form asking for more details from victims

Translation: “Please verify your security question”

As shown in Figure 5, the page asks the user to answer three security questions, followed by redirection to an ok.asp page (Figure 6) on the same domain:

Figure 6: Successful submission phishing page

The final link points back to Apple[.]com. The complete trail using Burp suite tool is shown in Figure 7.

Figure 7: Burp session

We noticed that if the user tried to supply the same Apple ID twice, they got redirected to the page save[.]asp shown in Figure 8. Clicking OK on the popup redirected the user back to the main page.

Figure 8: Error prompt generated by phishing page

Domain Registration Information

We found that the registrant names for all of these phony Apple domains were these Chinese names: “Yu Hu” and “Wu Yan”, “Yu Fei” and “Yu Zhe”. Moreover, all these domains were registered with qq[.].com email addresses. Details are available in Table 1 below.

Table 1: Domain registration information

Looking closer at our malicious domain detection system, we observed that the system had been seeing similar domains at an increasing frequency. Analyzing the registration information, we found some interesting patterns. Since January 2016 to the time of writing, the system marked around 240 unique domains that have something to do with Apple ID, iCloud or iTunes. From these 240 domains, we identified 154 unique email registrants with 64 unique emails pointing to qq[.]com, 36 unique Gmail email accounts, and 18 unique email addresses each belonging to 163[.]com and 126[.]com, and a couple more registered with 139[.]com.

This information is vital, as it could be used in following different ways:

• The domain list provided here could be used by Apple customers as a blacklist; they can avoid browsing to such domains and providing credentials to any of the listed domains, whether they receive them via SMS, email or via any instant messaging service.
• The Apple credential phishing detection teams could use this information, as it highlights that all domains registered with these email addresses, registrant names and addresses, as well as their combinations, are potentially malicious and serving phishing content. This information could be used to block all future domains registered by the same entities.
• Patterns emerging from this data reveal that for such campaigns, attackers prefer to use email addresses from Chinese services such as qq.com, 126.com and 138.com. It has also been observed that instead of names, the attackers have used numbers (such as 545454@qq[.]com and 891495200@qq[.]com) in their email addresses.

Geo-location:

As seen in Figure 9, we observed all of these domains pointing to 13 unique IP addresses distributed across the U.S. and China, suggesting that these attacks were perhaps targeting users from these regions.

Figure 9: Geo-location plot of the IPs for this campaign

Campaign 2: British Apples Gone Bad

Our email attacks research team unearthed another targeted phishing campaign against Apple users in the UK. Table 2 is a list of 86 Apple phishing domains that we observed since January 2016.

Figure 9: Geo-location plot of the IPs for this campaign

Phishing Content and Analysis

All of these domains have been serving the same phishing content. A simple HTTP GET (via the wget utility) to the domain’s main page reveals HTML code containing a meta-refresh redirection to the signin.php page.

A wget session is shown here:

Content of the page is displayed here:

This code redirects the browser to this URL/page:

http://manageAppleid84913[.]net/signin.php?c=OTYwNzUyNjlGUjU0OTYwNTQ5NDY0MDgxMjQ4OTQ5OTk0MTQ3MDc1NjYyOA==&log=1&sFR=ODc0MjQyNTEyNzMyODE1NTMxNTQ5c2RmZ3M1ZjRzNjQzMDU5MjUzMzg4NDMzNzE1&email=#

This loads a highly obfuscated JavaScript in the web browser that, on execution, generates the phishing HTML code at runtime to evade signature-based phishing detection systems. This is seen in Figure 17 in Appendix 2, with a deobfuscated version of the HTML code being shown in Figure 18.

This code renders in the browser to create the fake Apple ID phishing webpage seen in Figure 10, which resembles the authentic Apple page https://Appleid.Apple[.]com/.

Figure 10: Screenshot of the phishing page as seen by the victims in the browser

On submitting a fake username and password, the form gets submitted to signin-box-disabled.php and the JavaScript and jQuery creates the page seen in Figure 11, informing the user that the Apple ID provided has been locked and the user must unlock it:

Figure 11: Phishing page suggesting victims to unlock their Apple IDs

, which requests personal information such as name, date of birth, telephone numbers, addresses, credit card details and security questions, as shown in Figure 12. While filling out this form, we observed that the country part of the address drop-down menu only allowed address options from England, Scotland and Wales, suggesting that this attack is targeting these regions onlyClicking on unlock leads the user to the page profile.php .

Figure 12: User information requested by phishing page

On submitting false information on this form, the user would get a page asking to wait while the entered information is confirmed or verified. After a couple of seconds of processing, the page congratulates the user that their Apple ID was successfully unlocked (Figure 13). As seen in Figure 14, the user is then redirected to the authentic Apple page at https://Appleid.Apple[.]com/.

Figure 13: Account verification page displayed by the phishing site

Figure 14: After a successful attack, victims are redirected to the real apple login page

Domain Registration Information

It was observed that all of these domains used the whois privacy protection feature offered by many registrars. This feature enables the registrants to hide their personal and contact information which otherwise is available via the whois service. These domains were registered with the email “contact@privacyprotect[.]org”

Geo-location

All these domains (Table 2) were pointing to IPs in the UK, suggesting that they were hosted in the UK.

Conclusion

Cybercriminals are targeting Apple users by launching phishing campaigns focused on stealing Apple IDs, as well as personal, financial and other information. We witnessed a high frequency of these targeted phishing attacks in the first quarter of 2016. A few phishing campaigns were particularly interesting because of their sophisticated evasion techniques (using code encoding and obfuscation), geographical targets, and because the same content was being served across multiple domains, which indicates the same phishing kits were being used.

One campaign we detected in March used sophisticated encoding/encryption techniques to evade phishing detection systems and provided a realistic looking Apple/iCloud interface. The majority of these domains were registered by individuals having email addresses pointing to Chinese services – registrant email, contact and address information points to China. Additionally, the domains were serving phony Apple webpages in Chinese, indicating that they were targeting Chinese users.

The second campaign we detected was launched against Apple users in the UK. This campaign used sophisticated evasion techniques (such as code obfuscation) to evade phishing detection systems and, whenever successful, was able to collect Apple IDs and personal and credit card information from its victims.

Organizations could use the information provided in this blog to protect their users from such sophisticated phishing campaigns by writing signatures for their phishing detection and prevention systems.

Credits and Acknowledgements

Special thanks to Yichong Lin, Jimmy Su, Mary Grace and Gaurav Dalal for their support.

Appendix 1

Figure 15: Obfuscated JavaScript served by the phishing site. In Green we have highlighted functions with: number system converters, pseudo-random pattern decoders, bit level binary operas

Figure 16: Obfuscated JS served by the phishing site. In Green we have highlighted functions with: number system converters, pseudo-random pattern decoders, bit level binary operaters. While in Red we have: XOR decoders.

Appendix 2

Figure 17: Obfuscated JavaScript content served by the site

Figure 18: Deobfuscated HTML content

For more information on phishing, please visit:

https://support.apple.com/HT203126
http://www.apple.com/legal/more-resources/phishing/
https://support.apple.com/HT204759

As vehicles become both increasingly complex and better connected to the Internet, their newfound versatility may be manipulated for malicious purposes. Three of the most concerning potential threats looking ahead to the next few years are those posed by manipulating vehicle operation, ransomware and using vehicular systems as command and control (C2) infrastructure for illicit cyber activity.

Car Hacking?

Vehicles have come a long way in terms of the high-tech features and connectivity that come standard in most new models. Modern cars are controlled almost entirely by software, and many drivers don’t realize the most complex digital device they own may be in their driveway. Of the growing number of devices in the “Internet of Things” (IoT), vehicles are among the most significant additions to the global Internet. An ever-growing list of features—including web browsing, Wi-Fi access points, and remote-start mobile phone apps—enhance user enjoyment, but also greatly expand vehicles’ attack surface, rendering them potentially vulnerable to advanced attacks. During the past year especially, numerous proof-of-concept demonstrations have revealed connected-car vulnerabilities that malicious actors can exploit, ranging from unauthorized entry to commandeering the vehicle’s operation. Unfortunately, as consumer demand drives ever more features, the opportunities for compromise will increase as well.

Ransomware

The scourge of ransomware has so far affected thousands of systems belonging to ordinary individuals, hospitals, and police stations. A vehicle’s increased connectivity, ever-expanding attack surface, and high upfront cost make them attractive ransomware targets. In contrast to ransomware that infects ordinary computer systems, vehicles are more likely susceptible to ransomware attacks when their disablement causes knock-on effects.

For example, where a single driver might be able to reinstall his car’s software with the help of a mechanic to remedy a ransomware infection, a group of vehicles disabled on a busy highway could cause far more serious disruption. Victims or municipal authorities may have little choice but to pay the ransom to reopen a busy commuting route. Alternatively, a logistics company might suddenly find a large portion of its truck fleet rendered useless by ransomware. The potential for lost revenue due to downtime might pressure the company to pay the ransom rather than risk more significant financial losses.

Malicious C2 and Final Hop Points

One effective law enforcement tactic in countering cyber espionage and criminal campaigns is identifying, locating and seizing the systems threat actors use to route malicious traffic through the Internet. Since many modern vehicles can be better described as a computer attached to four wheels and an engine, their mobility and power present challenges to this means of countering threat activity. We have already witnessed malware designed to hijack IoT devices for malicious purposes; vehicular systems’ greater computing power, compared to connected home thermostats, can significantly enhance their value as a C2 node.

Locating vehicles used to route malicious traffic would present a major challenge to law enforcement investigation, largely due to their mobility. We have not yet observed threat actors using connected vehicle systems to route malicious traffic, but it is most likely that a vehicle would be used as a final hop point to the intended target network. The perpetrators may use the vehicle only once, choosing to hijack the connectivity of a different vehicle on their next operation, and so on. This ever-changing roster of potential last-hop nodes situated on highly mobile platforms may allow threat actors to elude law enforcement for extended periods of time.

Understanding the Risk Landscape

The impact of cyber threats is most often considered in financial terms—the cost of a breach, whether direct financial losses or indirect costs of investigation, remediation, and improved security. As computers increasingly control vehicles, among other critical devices and systems, the potential for malfunction or manipulation that causes human harm rises dramatically. Automobile manufacturers may face greater liability, not only for the car’s physical components, but its software as well. How long before vehicles need a “cyber security rating,” similar to that awarded for crash testing and fuel economy?

These new risks point to the need for automotive manufacturers and suppliers to not only ensure the traditional operational safety of their vehicles, but to also secure both the vehicle's operations and occupant privacy. This requires an ongoing understanding about the nature of threats and vulnerabilities in a rapidly evolving landscape, and building in strong proactive security measures to protect against these risks. FireEye explores these risks to automotive safety in our latest FireEye iSIGHT Intelligence and Mandiant Consulting report: Connected Cars: The Open Road for Hackers. The report is available for download here.

FireEye Capabilities

FireEye combines our industry leading threat intelligence, incident response and red team capabilities with our ICS domain expertise to help the automotive industry improve their prevention, detection and response capabilities. FireEye’s Red Team Operations and Penetration Tests can provide firms in the automotive industry experience responding to real-world attacks without the risk of negative headlines. A one-time risk assessment is not enough, because threat attackers are consistently evolving.

For more information, contact FireEye.

FireEye iSIGHT Intelligence’s Horizons Team conducts strategic forecasting to anticipate risks posed by emerging technologies and geopolitical developments, helping clients and the public better assess their exposure to a dynamic cyber threat landscape.

Vpon is one of many mobile ad SDKs marketed towards mainland Chinese and Taiwanese developers and app users. Recently, FireEye mobile security researchers identified a branch of Vpon ad SDK on iOS containing code that allows a malicious actor (be it the app developer or the SDK creator) to remotely command the app to perform the following actions:

• Stealthily record audio
• Capture screenshots and videos
• Monitor and upload device location
• Read/delete/create/modify files within the app sandbox
• Exfiltrate data to remote servers
• Load URL schemes to identify and launch apps installed on the device
• Access and modify the address book

In our investigation, we found that not all SDKs provided by Vpon enable the above capabilities – only the SDKs that are integrated with another ad platform aggregator, AdsMogo. AdsMogo not only functions as a standalone ad serving platform, but also provides the unification of a dynamic list of third party ad SDKs such as Inmobi, Youmi, Millenial Meida, Tapjoy, Vungle, etc. The implementation allows the participating ad SDKs to integrate behaviors that are not advertised in their standalone offerings.

Malicious Impact

We found a total of 36 apps that have the risky version of Vpon SDK integrated with AdsMogo platform. These apps are still available in the App Store as of May 25, 2016. According to Vpon’s changelog for iOS, the latest version at the time of posting is 4.5.1.

The delivery of the abovementioned malicious capabilities is through Apache Cordova (formerly known as PhoneGap) plugins. Cordova is an open source, community contributed framework that supports hybrid app development. With Cordova, a developer can program an app in pure JavaScript and other web technologies while having it be executed in multiple native environments such as iOS and Android. The plugin implementations allow a developer to invoke OS functionality (e.g. Camera, Media, Contacts) through JavaScript code.

However, throughout the changelog, there is no mention of the use of Cordova plugins. Our investigation indicates that Cordova plugins have been used starting with version 4.2, when a major build took place. This has persisted through all subsequent releases.

Technical Machinery

Apache Cordova for Remote Command and Control

Vpon SDK leverages the popular open source cross-platform mobile app development framework Apache Cordova for remotely controlling the app behavior through JavaScript. In the community’s own words:

Due to the underlying bridging implementation of Cordova, there are numerous limitations that constrain a hybrid app from being as capable as its full-fledged native counterpart when it comes to interacting with the native OS and device hardware. To fill in the gap and to expand the app’s capability to access native functionalities, the Cordova community provides a series of plugins. For instance, the cordova-plugin-camera allows a JavaScript call to access the camera on the device and to perform system functions. Furthermore, on iOS, one can implement their own custom plugin. Figure 1 is a diagram of the architecture of a typical Cordova based mobile app.

Figure 1. A high-level view of the Cordova application architecture
Source: Apache Cordova under Apache License

Vpon implemented its own plugin that encapsulates all the existing open source plugins. This is not exposed to the developer in its standalone releases of the SDK, therefore, developers could not hook the functionality into their apps. However, AdsMogo provides a software adapter that allows Vpon SDK provider to conceal the plugin initialization and ad rendering. When an app developer integrates Vpon through AdsMogo provided interface, all the plugin capabilities are enabled within the app.

Objective-C Side of Story

Power of Cordova Plugin

The pivotal piece that bridges the communication within a hybrid app between its web contents and the native OS environment is an implementation of the HTML Rendering Engine, which is UIWebView in iOS. However, the OS determines that a large set of device and platform functionalities should not be available to web based applications through the single interface [UIWebView stringByEvaluatingJavaScriptFromString]. Plugins, therefore, serve as a workaround of the constraint.

According to the development guidelines, a plugin is a package of injected code that allows the Cordova webview within which the app renders to communicate with the native platform on which it runs. Plugins consist of a single JavaScript interface along with corresponding native code libraries for each supported platform. In essence, this hides the various native code implementations behind a common JavaScript interface.

Cornerstone of a Vpon Cordova Plugin

An iOS plugin is implemented as an Objective-C class that extends the CDVPlugin class. For Vpon SDK, this Objective-C class is VponCDVPlugin, which is further extended by the plugin implementation shown in Figure 2.

Figure 2. A list of plugin implementations in Vpon’s Cordova Plugin

Further examination shows that all the above plugin implementations are simply wrappers of the corresponding existing open source plugins in the Apache repository. Therefore, they export the same interfaces for JavaScript calls as those of the open source plugins.

The Inheritance Relationship of View Controllers

Cordova applications are ordinarily implemented as a browser-based WebView within the native mobile platform. However, as a third party ad library, one has little control over whether it is embedded in a hybrid app or a pure native one. Therefore, it is imperative to roll out a customized web view implementation within the ad library. According to the official documentation, the underpinning element is the CDVViewController from the Cordova library, which serves as the point of contact for the tailored communication between JavaScript and the native OS.

For the Vpon SDK, the embodiment of this view controller class is VponCDVViewController. Special setup and configuration was performed when an instance is instantiated. Figure 3 shows a subset of methods it has, as well as a look into one of its functions [VponCDVViewController webView:shouldStartLoadWithRequest:navigationType:].

Figure 3. Vpon Cordova plugin’s implementation of entry point view controller CDVViewController

VponCDVViewController is never directly instantiated and added to the host app’s view controller hierarchy, but rather is dependent on the instantiation of many of its child implementations, VponPhoneGapViewController. Figure 4 shows the parent and child relationship of these two view controllers.

Figure 4. VponCDVViewController is the parent of VponPhoneGapViewController

Furthermore, VponPhoneGapViewController is the parent of the following view controllers, as shown in Figure 5.

• VponVideoWebViewController
• VpadnNativeADViewController
• VponInAppWebViewController
• VpadnNativeAdActionViewController
• VponAdViewController
• VponInterstatialViewController

Figure 5. VponPhoneGapViewController is the parent of the list of UIViewController implementations

To better illustrate the workflow of Vpon Cordova plugin, let’s focus on one of the UIViewController implementations. A VponAdViewController instance is created and set into operation in a series of method invocations started when the Vpon SDK is activated through AdsMoGoAdapterVpon, an adapter implementation of the Adapter interface provided by AdsMoGo platform. The sequence of invocations is depicted in Figure 6.

Figure 6. Sequence of invocations that illustrates the integration of Vpon and AdsMoGo

Figure 7 displays the content of [VpadnBanner sendRequestGetAd] with the highlighted area showing the initialization of the child view controller implementation of VponCDVViewController .

Figure 7. The implementation of [VpadnBanner sendRequestGetAd] with the instantiation of VponCDVViewController

When VponAdViewController is used to open a video Ad through [VponAdViewController openVideoAd:], it effectively creates an instance of the VponVideoWebViewController and renders the remotely retrieved video content.

Malicious Capabilities

The capabilities that are beyond the realm of ad serving in Vpon are manifested by the plugin implementations. Each capability is supported by an implementation of an open source Cordova plugin. Figure 8 shows the full set of commands supported by vpadn-sdk-i-v4.2.16: the latest as of March 28, 2016, which is the required plugin mapping for a custom Cordova plugin.

Figure 8. Vpon Cordova Plugin Mapping

For those who are interested in knowing more about Cordova Plugin development, please refer to Apache’s plugin development guide.

Figure 9 gives a look into the implementation of one of the plugins, VponCDVCapture. It is a plugin that supports stealth recording in response to the corresponding command from JavaScript. The implementation within Vpon SDK is merely a wrapping of the open source plugin cordova-plugin-media-capture with a different class name that is consistent with Vpon’s naming convention.

Figure 9. Vpon’s implementation of the media capture plugin

According to Cordova’s documentation on the media capture plugin shown in Figure 10, the utilization should always be accompanied by a UI control that allows the user to accept or deny. While the OS prompts the user for granting the access to the microphone the first time it is going to be used by the app, it is not sufficient in raising the user’s suspicion if the host app provides functionalities that require legitimate access to the microphone.

Figure 10. Apache documentation on the media-capture plugin

In addition to accessing microphone, Vpon Cordova plugin also provides interface to JavaScript for using the device camera and the address book. Figure 11 and Figure 12 provide a glimpse into the relevant code.

Figure 11. Vpon’s cordova plugin supports JavaScript access to the device camera

Figure 12.  Vpon’s cordova plugin supports JavaScript access to the device address book

JavaScript Side of Story

JavaScript code is the linchpin for the framework that enables plugins to function as intended. As Apache Cordova has put it:

There are two ways to serve JavaScript content to a Cordova enabled app. First, the app is compiled and packaged with local JavaScript files and the HTML pages that consume them. Second, the app retrieves remote JavaScript at runtime through web technologies. They are not mutually exclusive; rather, they are supplemental to each other for robust and flexible cross-platform apps.

In the case of Vpon SDK, there is no local JavaScript content involved in the app’s lifecycle. Instead, it is delivered to the rendering view controllers during an ad request to the Vpon ad server. Figure 13 shows the hardcoded URL of loaded JavaScript for each and every ad request.

Figure 13. The hardcoded URL of loaded JavaScript for each and every ad request

The current content of the above JavaScript file on the server is shown in Listing 1. This piece further directs the rendering view to load JavaScript for an iOS device, which is a customized version of the Apache cordova.js file, the base of the Cordova JavaScript API. Listing 2 shows an excerpt of the current content of this JavaScript file, with highlights on the invocation of Vpon Cordova plugin VponSdk.

Listing 1. Content of file http://m.vpadn.com/sdk/vpadn-sdk-a-core-v1.js 

Listing 2. Content excerpt of JavaScript file vpadn-sdk-i-core-v1.js served by the Vpon server

Through our investigation and traffic monitoring within a limited time period, we did not observe active network communications that deliver malicious JavaScript from the remote server. However, this does not justify that it cannot be taken advantage of to behave maliciously. It is rather easy to replace the plugin name, the invocation method, and the relevant parameters specified to execute the functionalities of other plugins. For instance, to activate the microphone to record surroundings, one only needs to add the following JavaScript code (Listing 3) in the remote JS file.

Listing 3. PoC exploit

This is the functional equivalent to the following execution in cycript within a running app embedded with the malicious Vpon SDK, as shown in Figure 14.

Figure 14. Activate device microphone for voice recording through Vpon’s undisclosed Cordova plugin in Cycript

The subsequent execution of the above cmd resulted in a stealth recording saved to the Documents directory within the app sandbox.

Two Routes to Profit

While we did not capture real network traffic during our investigation that proves a perceived wrongdoing, we see no justification for an ad platform provider, such as Vpon, to have the code ability to use the microphone for voice recording, use the camera for taking pictures and recording videos, access the address book, manipulate the app sandbox, and perform other behaviors.

The current setup offers opportunity to two types of potential malicious actors who can profit from the developers and the app users.

• Profiter: Vpon SDK provider. To this point, it should not be surprising that it’s up to the Vpon SDK provider’s benevolence that apps embedded with this malicious SDK are not behaving improperly for their users. However, in the case where such benevolence runs out, the users will suffer undesirable loss of privacy and security.
• Profiter: A third party network hijacker. As we have illustrated, a portion of the contents provided to the user by the ad SDK provider are through the network communication on top of the HTTP protocol. The commands are delivered through the remote web pages, in the form of HTML and JavaScript. Therefore, a third party network attacker can take advantage of a man in the middle (MitM) setup to activate the seemingly dormant malicious behavior.

Food for Thought

In this blog post, we showed that a third party ad library provider, Vpon, is stowing aggressive and risky code ability into the apps that adopt it as an ad-serving platform. This is not the first time FireEye mobile security researchers have seen such attempts. In November 2015, we reported iBackdoor, a similar threat with a backdoored ad SDK leveraging remote JavaScript to manipulate the device and exfiltrate sensitive information without permission. Third party libraries – ad libraries in particular – are often unvetted by the community. It is common and expected that app developers will integrate third party libraries into their apps, so developers should exert caution.

Following our responsible disclosure guidelines, we contacted Apple and Vpon respectively on May 10, 2016. Apple acknowledged the findings, but offered no further feedback. Vpon did not respond when we reached out.

Since 2010, Mandiant, a FireEye company, has presented trends, statistics and case studies of cyber attacks involving advanced threat actors. As part of its many global investigations in 2015, Mandiant responded to several breaches in Europe, Middle East and Africa (EMEA). Throughout the year we collected statistics on the investigations specific to the region and analysed the trends.

To share what we have been seeing throughout this past year, we present “M-Trends – EMEA Edition 2016.” This report marks the start of an annual M-Trends edition focused on EMEA. The report aims to empower organisations and the security community, arm them with the knowledge relating to the unique challenges facing the region, and assist in improving security posture to combat advanced attacks.

Some of the key findings include:

• Organizations in EMEA took three times longer to detect a compromise: The mean dwell time (time between compromise and detection) in the region was 469 days, versus a global average of 146 days.
• EMEA organizations cannot rely on local agencies to notify them of compromises: Of all observed compromises in EMEA, 12% of notifications came from an external source. Globally, external sources accounted for 53% of notifications. EMEA organizations discovered breaches internally 88% of the time, but EMEA average dwell time (469 days) suggests this often came too late
• Many organisations in EMEA were re-compromised within months of an initial breach:  Unsuitable techniques to hunt for attacks within an environment often resulted in a failure to understand the true scope of the incident. Mandiant consultants found many EMEA organizations still opting for a traditional forensic methodology, only analysing a handful of machines, and subsequently increasing the risk of becoming re-compromised. 

The findings show that organisations in the EMEA region have a lot of room to improve their incident detection and response capabilities. 

Download M-Trends EMEA Edition 2016 for further insight.

Register for our webinar to discuss the findings with the authors of this report and to learn more about improving an organisation’s security posture.

At FireEye Labs, we recently detected the resurgence of a coin mining campaign with a novel and unconventional infection vector in the form of an iFRAME (inline frame) – an HTML document embedded inside another HTML document on a web page that allows users to get content from another separate source and display it within the main web page – embedded in a PE binary (Portable Executable Binary, or .exe).

We observed an anomaly when approximately 60 domains (all [.]top TLDs  registered on April 7, 2016) started serving a coin mining malware – to mine BitMonero, a form of digital currency – on their main page under the mime-type of html/text. All of these domains were registered by the same entity and they were resolving to the same IP.  

Only the PE binary file was directly hosted on the index page without any browser exploit (in general, browser exploits are delivered via third party software exploits such as JavaScript or Flash). However, an HTML IFRAME tag that was embedded inside the malware binary was being used to force the web browser to download its copy as a file named “Photo.scr”. This filename is perhaps designed to entice the human victim to click on the file and check the “Photo” that was downloaded.   

In the absence of a browser exploit mechanism, this appears to be a social engineering attack, where the attacker would trick a user into downloading and executing the binary hosted on this site. The page contents were downloaded and analyzed by FireEye team members. The SCR file had a md5sum: aba2d86ed17f587eb6d57e6c75f64f05. Our system classified this as a coinminer malware, which uses its victim’s computing resources to mine bitcoins.

What is a Bitcoin and BitMonero and how is it created?

Bitcoin and BitMonero are digital currencies that leverage a peer-to-peer (P2P) decentralized model for validating and transactions. Since no financial institutions are used, no central authority is necessary to control this currency. Bitcoins are accepted as currency by many merchants, can be used to pay for various online services, products and goods, and can be traded for traditional currency via Bitcoin/currency exchanges. Bitcoins are generated or “mined” after processing a “block” of data. A Bitcoin or BitMonero block is a cryptographic challenge that is solved by intensive computing power.

Domains list serving the content

These 55 domains (tabulated in Table 1) associated with BitMonero mining operations were registered on the same day and serving the same content. These domains belonged to the [.]top TLD.

Table 1: List of 55 registered domains for Bitcoin mining

IP and Whois Information

IP and whois registration information for all these domains contains the same registrant and these domains resolved to the same IP address as of April 20, 2016. The addresses were determined to belong to a single service provider located in North Kansas City, USA. The registrant whois information shown in the following table specifies an address in NanJing, China. This information is consistent for the domains registered for this campaign:

Web Content Analysis

These domains were pointing to the IP: 198.204.254[.]82. The server was configured to respond with the same content to any GET request for these domains. An analysis of one of the domains is presented in this post as a case study.

For this case study we chose a representative domain, “ggkuu[.]top”, from the list. Browsing to the site http://www.ggkuu[.]top with a user web browser results in the malware being loaded as an html/text MIME-type object.

Figure 1 shows a screenshot of the web browser after visiting the site. Because the Mime-type is set to html/text, the binary appears as html/text in the browser. Note the MZ header at the beginning of the page. MZ headers are associated with executable binaries. This appears to be a benign looking file to the end-user; however, it is treated by the end-user system as an executable.

Figure 1. www.Ggkuu[.]top content view in browser

The following is a session generated using the WGET utility, a command line tool that can be used to generate web requests, which verifies that the site serves the malware as mime-type of text/html.

Malware Delivery/Exploit method

The malware is delivered by way of a standard 1x1 iFRAME that will attempt to load the binary file, “Photo.SCR” upon visiting the website. The following is the iframe:

The binary object was obtained and is identical to “Photo.scr” based on the file MD5 hashsum, also shown in Figure 2.

Figure 2. www.Ggkuu[.]top the iframe embedded in the content triggering Photo.scr download in the web browser

A Historical Footprint

We observed that the original binary file (Photo.scr) is primarily a container (with some additional features discussed later) for known malware binary NSCpuCNMiner32.exe with the MD5 hash 3afeb8e9af02a33ff71bf2f6751cae3a, a binary we first saw in the wild in July 2014. The binary is packed with PolyEnE 0.01+.

Traditionally, the malware has been propagated using social engineering through Skype, email, removable media and by using phishing campaigns; where it has masqueraded as a legitimate application. During this campaign we have observed that NSCpuCNMiner32.exe is deployed after a victim visits one of the 55 malicious websites described previously, as a result of loading “photo.scr”.    

Execution & Dynamic Analysis

The binary file “photo.scr” requires no special arguments, executing on Windows and WINE-enabled systems through traditional user interaction such as double-clicking.

Configurational Settings

As soon as the executable is launched, the following changes to the host operating system are performed. 

The following mutex is created:

The following registry key is modified:

Within the registry path for Internet Settings, the following web proxy settings are modified or deleted:

The malware reconfigures caching of web content:

The malware then disables the security settings of Internet Explorer by modifying the following registry keys:

Next, the malware modifies global file extension settings for the infected system to prevent showing the user file extensions via the Windows Explorer.

Then it attempts to access potentially sensitive information from local browsers:

It also adds itself to the autorun registry keypath for persistence.

Upon installation, the following DNS request is made:

Encoded instructions for mining

The malware makes a GET request to http://hrtests[.]ru/test.html?0; this is the same domain against which a DNS request was first performed. In response to the GET request, the malware expects the following encoded data, as shown in Figure 3. The binary also contains a list of domains (given in the appendix, registered in 2016), from where it fetches the mining pool information.

Figure 3: Encoded response

We analyzed the encoded data and found that it is employing a simple decoding algorithm (ROT47 on custom characterset). Pseudocode is shown here:

A decoded response is depicted in Figure 4.

Figure 4: The decoded response containing coin mining hashes

The decoded text contains the mining parameters and credentials for mining.

Dropped Binary

The mining malware  – NsCpuCNMiner32.exe – is typically run from within a user temp directory. When executed in a standalone Windows virtual machine (VM), it detects the virtual environment and exits with a dialog box that “the application can’t run under virtual machine”. However, when we execute it through FireEye multi-vector virtual execution engine (MVX), it successfully executes and allowed us to analyze the malware behavior.

It is a general-purpose miner that has been used for mining cryptocurrencies in the past and is invoked by several families of malware using several parameters. These settings define which mining pool it will use.

NsCpuCNMiner32.exe is invoked by Photo.scr using the ShellExecuteA method with the following parameters:

Note that these parameters are the same as those which are decoded from the response from hrtests[.]ru (above). Photo.scr obtains the settings regarding mining pool from hrtests[.]ru and passes them as input to the miner, which uses this information to start mining activity.

The miner also checks for a Process Debug Port to detect execution within a virtual machine or for the presence of a debugger. It was successfully evading VMware and Qemu based virtualized sandboxes, and terminated after execution in those virtualization environments. If it executes successfully, it initiates mining activity by contacting the mining pool defined in the parameters passed from photo.scr.

Coin Mining traffic

The following network traffic is generated by the miner executable while mining activity is being performed, as shown in Figure 5.

Figure 5: Coin mining traffic

Mining pools contacted

The mining process contacts the mining pools, i.e. mine.moneropool.com:3333, monero.crypto-pool.fr:3333, pool.minexmr.com:5555, xmr.prohash.net:7777.

Propagation

The malware propagates from a victim system by copying photo.scr to the root of all lettered drives connected to the victim machine. This way, the malware propagates through both removable and network drives mounted to a victim system. The malware invokes a native command-line copying utility, “xcopy”, to propagate itself:

FTP Traffic Analysis

Once the malware has been successfully copied to all the drives connected to the system, it calls out to various public FTP servers including servers belonging to Government, Industry, Education and SME organizations. The binary was observed attempting to connect to almost 54,000 IPs via FTP; however, only 203 IPs were running active FTP services. The malware attempted to authenticate using six different usernames and 17 different passwords. The username and password combinations attempted suggest that the attacker is attempting to leverage weak or default credentials for authentication.

A geolocation map of the 203 active IPs is shown in Figure 6. (The list of IPs is removed for privacy, please note that geolocation metadata may not be reliable in all cases).

Figure 6: Geolocation of active FTP servers to which the binary attempts to connect

The binary attempted the following username and password combinations:

Usernames: anonymous, www-data, administrator, ftp, user, user123

Passwords: password, pass1234, 123456, 1234567, 12345678, 123456789, 1234567890, qwerty, 000000, 111111, 123123, abc123, admin123, derok010101, windows, 123qwe, 000000

The malware successfully authenticated to  three of the 203 FTP servers. In all three cases, the malware attempted to upload the file “Photo.scr” from the local machine to the remote server. In two cases the file upload wasn't allowed, leading to a “Permission denied” error. The file transfer was successful in one case, as seen in Figure 7. The malware was observed attempting to FTP a copy of itself to a HP printer with an Internet-routable IP address, but used the STOR command instead of the commonly used PUT command.

Figure 7: Successful FTP transfer for Photo.scr

Pervasiveness of Photo.scr

We attempted to locate files named “Photo.scr” available on the Internet using open sources. We identified both HTTP and FTP servers residing in eight countries, indicating that the malware has been present in many countries worldwide. A geolocation map of these domains is shown in Figure 8.

Figure 8: Geolocation map of the public Web and FTP servers containing the Photo.scr sample

URL Fuzzing on Domain List

Since there are no links on the site main page, we resolved to fuzz commonly used names of HTML pages and directories in an attempt to generate responses from the malicious web server. We found several malicious active pages such as Photos.html and Photo.html serving the same malicious content. As an example, browsing to the Photos.html page results in the malware being loaded into the browser as text/html and triggering the download via the iFRAME. However, there were other pages on this site that were serving different, rather benign looking content. Details of other pages found via fuzzing are mentioned in Appendix B.

Conclusion

Cryptocurrencies have been gaining popularity in recent years, particularly since Bitcoin emerged in 2009 as the first decentralized cryptocurrency. The decentralized nature of the internet and the widespread availability of vulnerable hosts has motivated cybercriminals to covertly target connected machines and abuse them to harvest cryptocurrencies.

Recently we observed a coin-mining campaign invovling around 60 unique domains being launched in April 2016, all pointing to a single IP host. Using social engineering techniques, users were tricked to browse to these domains, where they were presented with an HTML page containing an iframe that forced the browser to download a file named Photo.scr. This file was carefully named to entice curious users to click on it, thus executing the malware binary, infecting the user’s computer and enslaving its resources to mine BitMonero coins. 

For persistence, the malware implemented a common Registry autorun mechanism, attempted to infect removable and network drives, and attempted to propagate to globally distributed FTP servers using weak or default credentials. This hack-for-profit campaign is another example of how the underground economy flourishes with the innovation and ingenuity of cybercriminals. Analyzing this campaign provided insights into the threat this campaign poses to online users globally.

FireEye’s multi-flow detection mechanism identifies this malware at every level, from the point of entry to the callback. Additionally, the malware was unable to detect or bypass the FireEye sandbox.

Credits and Acknowledgements

We would like to thank and acknowledge Dan Caselden, Devon Kerr, Imad Khurram and Ali Hussain for their contribution.

Appendix A

Domain/URLs in the malware executable

An in-depth analysis into the binary revealed the following domains (available as plain text strings) hosting the pool information for the miner.

Figure 9: Map showing the location of the servers where these domains are hosted

Appendix B

Figure 10 shows browsing to Photo.html.

Figure 10: Browsing view of page Photo.html

Translating the title to Chinese results in this: “Magic Dragon spider pool ---- purchase please contact: dragon magic spider pool”. While the content on the page results in this: “Long sentences dynamic magic _”

All the links on the page point to: http://www.ggkuu[.]top/%3C%E9%BE%99%E9%AD%94_%E5%8A%A8%E6%80%81%E5%8F%A5%E5%AD%90%3E. Clicking on any of these links, results in redirection to a page serving the malware.

Looking for other HTML pages on this domain, we resorted to crawling and fuzzing and found more than 1,200 HTML pages. A few of them are illustrated in the following table. The majority of these pages seem to be serving the same malware binary as the main page.

The Sitemap page of this domain was particularly interesting, as it seems to be pointing to various news articles on ybnews[.]cn and 96hq[.]com. Each time we browse to this page, new content is generated. Figure 10 and Figure 11 show manifesting links to ybnews[.]cn and 96hq[.]com.

Figure 11: Sitemap containing URLs of ybnews[.]cn

Figure 12: Sitemap containing URLs from 96hq[.]com

Fuzzing and crawling for directories, we found more than 1,200 directory folders, which mostly point to pages that are serving malware. A few of these folders are illustrated as follows: ‘/desktop/’, ‘/category/’, ‘/nz/’,’/8/’, ‘/fr/’, ‘/d/’, ‘/cz/’, ‘/fk/’, ‘/dk/’, ‘/cu/’, ‘/gr/’, ‘/cc/’, ‘/o/’, ‘/be/’, ‘/ar/’, ‘/bj/’.

On Sept. 25, 2015, President Barack Obama and Chinese President Xi Jinping agreed that neither government would “conduct or knowingly support cyber-enabled theft of intellectual property” for an economic advantage. Some observers hailed the agreement as a game changer for U.S. and Chinese relations, while skeptics saw this as little more than a diplomatic formality unlikely to stymie years of state-sponsored intellectual property theft. Since the agreement, there has been much discussion and speculation as to what impact, if any, it would have on Chinese cyber operations.

To investigate this question, FireEye iSIGHT Intelligence reviewed the activity of 72 groups that we suspect are operating in China or otherwise supporting Chinese state interests. Going back nearly three and a half years to early 2013, our analysis paints a complex picture, leading us to assess that a range of political, economic, and other forces were contributing to a shift in Chinese cyber operations more than a year prior to the Xi-Obama agreement.

Between September 2015 and June 2016, we observed 13 active China-based groups conduct multiple instances of network compromise against corporations in the U.S., Europe, and Japan. During this same timeframe, other China-based groups targeted organizations in Russia and the Asia Pacific region. However, since mid-2014, we have observed an overall decrease in successful network compromises by China-based groups against organizations in the U.S. and 25 other countries. These shifts have coincided with ongoing political and military reforms in China, widespread exposure of Chinese cyber activity, and unprecedented action by the U.S. government.

Download the report, Red Line Drawn: China Recalculates Its Use of Cyber Espionage.

On June 21, 2016, FireEye’s Dynamic Threat Intelligence (DTI) identified an increase in JavaScript contained within spam emails. FireEye analysts determined the increase was the result of a new Locky ransomware spam campaign.

As shown in Figure 1, Locky spam activity was uninterrupted until June 1, 2016, when it stopped for nearly three weeks. During this period, Locky was the most dominant ransomware distributed in spam email. Now, Locky distribution has returned to the level seen during the first half of 2016.

Figure 1. Locky spam activity in 2016

Figure 2 shows that the majority of Locky spam email detections between June 21 and June 23 of this year were recorded in Japan, the United States and South Korea.

Figure 2. Locky spam by country from June 21 to June 23 of this year

The spam email – a sample shown is shown in Figure 3 – purports to contain an unpaid invoice in an attached ZIP archive. Instead of an invoice, the ZIP archive contains a Locky downloader written in JavaScript.

Figure 3. Locky spam email

JavaScript based Downloader Updates

In this campaign, few updates were seen in both the JavaScript based downloader and the Locky payload.

The JavaScript downloader does the following:

1. Iterates over an array of URLs hosting the Locky payload.
2. If a connection to one of the URLs fails, the JavaScript sleeps for 1,000 ms before continuing to iterate over the array of URLs.
3. Uses a custom XOR-based decryption routine to decrypt the Locky payload.
4. Ensures the decrypted binary is of a predefined size. In Figure 4 below, the size of the decrypted binary had to be greater than 143,360 bytes and smaller than 153,660 bytes to be executed.

Figure 4. Payload download function in JavaScript

5.     Checks (Figure 5) that the first two bytes of the binary contain the “MZ” header signature.

Figure 5: MZ header check

6.     Executes the decrypted payload by passing it the command line parameter, “123”.

Locky Payload Updates

The Locky ransomware downloaded in this campaign requires a command line argument to properly execute. This command line parameter, “123” in the analyzed sample, is passed to the binary by the first stage JavaScript-based downloader. This command line parameter value is used in the code unpacking stage of the ransomware. Legitimate binaries typically verify the number of arguments passed or compare the command line parameter with the expected value and gracefully exit if the check fails. However in the case of this Locky ransomware, the program does not exit (Figure 6) and the value received as a command line parameter is added to a constant value defined in the binary. The sum of the constant and the parameter value is used in the decryption routine (Figure 7). If no command line parameter is passed, it adds zero to the constant.

Figure 6. Command line parameter check

Figure 7. Decryption routine

If no command line parameter is passed, then the constant for the decryption routine is incorrect. This results in program crash as the decrypted code is invalid. In Figure 8 and Figure 9, we can see the decrypted code sections with and without the command line parameter, respectively.

Figure 8. Correct decrypted code

Figure 9. Incorrect decrypted code

By using this technique, Locky authors have created a dependency on the first stage downloader for the second stage to be executed properly. If a second stage payload such as this is directly analyzed, it will result in a crash.

Conclusion

As of today, the Locky spam campaign is still ongoing, with an added anti-analysis / sandbox evasion technique. We expect to see additional Locky spam campaigns and will remain vigilant in order to protect our customers.

Email Hashes

2cdf62f8aae20026418f143895c769a2009e6b9b3ac59bfa8fc79ca2f326b93a

1fd5c1f0ecc1d54324f3bdc327e7893032482a13c0914ef6f531bd93caef0a06

0ea7d59d7f1494fce8f45a1f35abb07a456de6d8d65327eca8ff84f307a49a06

22645be8553628574a7af3c32a45178e201e9af33b20b36d29b9c012b731da4c

198d8d1a89221c575d957c1f4342741f3675ebb10f95ffe3371150e124f4850e

Introduction

In April 2016, while investigating a Smishing campaign dubbed RuMMS that involved the targeting of Android users in Russia, we also noticed three similar Smishing campaigns reportedly spreading in Denmark (February 2016), in Italy (February 2016), and in both Denmark and Italy (April 2016).

Unlike the RuMMS campaign, these three campaigns in Europe used view overlay techniques (the same technique we described being used by SlemBunk malware) to present nearly identical credential input UIs as seen in benign apps, subsequently tricking unwary users into providing their banking credentials.

Figure 1 shows the process of how these overlay malware spread via Smishing and infect Android users.

Figure 1. Overview

Threat actors typically first setup the command and control (C2) servers and malware hosting sites, then put the malware apps on the hosting sites and send victims SMS messages with an embedded link that leads to the malware app. After landing on the user’s device, the malware launches a process to monitor which app is running in the foreground on the compromised device. When the user launches a benign app into the foreground that the malware is programmed to target (such as a banking app), the malware overlays a phishing view on top of the benign app. The unwary user, assuming that they are using the benign app, will enter the required account credentials, which are then sent to remote C2 servers controlled by threat actors.

Through our close monitoring of overlay malware spreading via Smishing messages, we recently observed that these types of attacks did not stop despite publicity from security researchers. Instead, our systematic study revealed some interesting and simultaneously worrying findings:

• From February 2016 to June 2016, we observed 55 malicious binaries used in a series of Smishing campaigns targeting different countries in Europe. All the malware samples use the same view overlay technique to phish banking credentials, and all share the same C2 communication protocol. Besides the three publicly disclosed campaigns in Denmark and Italy, we observed the same threats targeting Germany in March 2016 and Austria from April 2016 to May 2016. In June 2016, we still see new samples emerging and being used to target users in Denmark; a few other European countries could be impacted as well.
• The key functions of these samples have been the same; however, over time, we noticed that the samples keep evolving in a few different directions. For example, later campaigns usually targeted more benign apps than earlier campaigns, focusing on messaging apps, for example, as opposed to banking apps. Also, the malicious apps used in later campaigns are often harder to analyze because obfuscation techniques were adopted to evade detection. In addition, some new functionality was added; in particular, we noticed that more recent samples leveraged reflection to bypass the SMS writing restriction enforced by the App Ops service (introduced in Android 4.3). All of this suggests that threat actors are actively improving their code.
• Unlike the RuMMS campaign, which mainly used shared hosting services to distribute the malware, the Europe Smishing campaigns show more diversity in the associated infrastructure, including the use of self-registered domains, compromised websites, and URL shortening services. Since February 2016, we observed that 27 Bit.ly links have been used. In June 2016, we noticed that another three URL shorteners, including tr.im, jar.mar and is.gd, were adopted in the latest campaign. This suggests that threat actors are trying to diversify the URL shorteners to avoid detection.
• In total, we identified 12 C2 servers hosted in five different countries that were involved in these campaigns. Among them, the IP address 85.93.5.109 has been used by 24 malicious apps in two campaigns and 85.93.5.139 has been used by eight malicious apps. We also observed that four C2 servers are within the same 85.93.5.0/24 network segment. All this suggests that the threat actors have control over considerable network resources.
• URL shortening services usually provide link analytics services, which enables us to collect data on how many users (from which countries) clicked particular short links and when it happened. Using these services, we found there have been at least 161,349 clicks on the 30 short links redirecting to the overlay malware, each of which can lead to the infection of one Android device. The date information indicated that most of the clicks occurred in the first few days after the links were created.

Five Europe Smishing Campaigns

From February 2016 to April 2016, security researchers reported on three campaigns involving Android overlay malware being distributed via SMS phishing messages. As described in the reports, those campaigns started with SMS phishing messages being sent to a user’s phone. An example SMS message in the latest campaign is shown in Figure 1. The message roughly translates to, “We could not deliver your order. Please check your shipping information here hxxp://bit[.]ly/1ZfcNeV”. Users in Denmark and Italy were reported to be the primary targets of these three campaigns.

Our recent investigation revealed that these activities keep developing, with other European countries, including Germany and Austria, being impacted as well. We group these activities into five campaigns, as shown in Table 1.

Table 1. Overview of the five Europe Smishing campaigns ordered in the beginning dates

(*: First publicized by FireEye researchers)

Shortened links were commonly used in the five campaigns. In total, we identified 30 short links. Some URL shorteners provide analytics, through which anyone can see how many people clicked the link and the countries those clicks came from. For example, Figure 2 shows that there were 135 clicks from Germany on one of the Whats-Germany samples, and 1,633 clicks from Austria on one of the Post-Austria samples.

Figure 2. Analytics pages on one Whats-Germany sample and one post-Austria sample

Code Evolution

In the aforementioned Smishing campaigns, we observed that the malware code has been evolving over time. The malware author(s) seems to be working diligently to improve the code by adding new target apps, obfuscating the code to evade detection, and trying to bypass App Ops restrictions.

Adding New Target Apps

All five campaigns attempt to steal credentials from various targeted apps. When the malicious app is started, a background service is triggered to periodically monitor the apps running in the foreground. When the service detects that the foreground app is one of its targeted apps, it overlays a carefully designed phishing view on top of the target app.

Analysis of the malware code shows that this task is executed by a method in the main service, named initInjTask in most cases. Figure 3 shows the code of initInjTask in one of the earliest samples of the MPay-Denmark campaign, in which only a localized app named MobilePay was targeted.

Figure 3. MobileBank class to be started to overlay app named “dk.danskebank.mobilepay”

(code extracted from app with a MD5 of 49dac3b35afb2e8d3605c72d0d83f631)

Figure 4 shows the code of initInjTask in one Whats-Italy sample, in which the target was changed to a more widely used app: WhatsApp Messenger.

Figure 4. Cards class to be started to overlay app named “com.whatsapp”

(code extracted from app with a MD5 of 97c2d04aa0f3c3b446fc228c1dbc4837)

Figure 5 shows the code of initInjTask in one Whats-Germany sample, in which two apps – WhatsApp and the Google Play Store – were targeted.

Figure 5. Cards class to be started to overlay apps WhatsApp and Play Store

(code extracted from app with a MD5 of 9e9d9a3717eed4d558a3f5eddb260901)

Figure 6 shows the code of initInjTask in one Post-Austria sample (in this case, the malicious app was obfuscated; the code was extracted from the dropped jar file). In total, eight worldwide popular apps – including Uber and Tencent’s WeChat – were on its radar.

Figure 6. cqkwjqjtoz class to be started to overlay apps 8 popular apps

(code extracted from app with a MD5 of d70296d3dc4937dedd44f93bb3b74034)

The code examples demonstrate changes in the malware over time. Early samples targeted single apps (a localized banking app and WhatsApp) while later samples included a broader range of apps, suggesting that the threat actors continue to both improve their malware and broaden their targeting, presumably for greater financial gain.

Code Obfuscation

In earlier campaigns, including MPay-Denmark, Whats-Italy and Whats-Germany, most of the malicious apps were not obfuscated and experienced reverse engineers can work readily with the disassembled code.

Figure 7 shows the manifest file and code structures for these earlier samples. With these two pieces of information, we see that three receivers are registered for various purposes: to handle incoming SMS messages; to request device-admin privileges; and to start the app at booting time and handle two application-specific events. There are also two services designed to be running in the background and four activities meant to interact with users. With this basic information at hand, adept malware analysts can readily figure out the role played by each part of the code and further understand how these pieces work together to achieve the malware’s goal.

Figure 7. Code structure and manifest file of earlier un-obfuscated code

Since April 2016, we observed that all the samples in our dataset had adopted obfuscation techniques. With the obfuscation, the manifest file became harder to read and the code structure looked totally different.

Figure 8 presents one sample in the PostDanmark campaign. The code structure on the left shows that there are five classes named “a”, “b”, “c”, “d” and “mrtbeig” with a same package name of “com.atrdectn.ioitsrc”. At the right side, the manifest file shows there are four receivers, seven services and four activities declared, with a different package name of “com.lpygioep.tjzcverotl”. So where is the code of these declared classes? What are the purposes of these classes named at left? Here the code is much more complex to analyze.

Figure 8. Code structure and manifest file of later obfuscated code

Deeper investigation showed that these classes defined on the left side compose the real payload and overlay the phishing view on top of the eight popular benign apps. Their code is in fact hidden in the asset file named mptxip.dat, which was encoded in a special manner beforehand.

The classes at the left side are actually unpacking code to decode the asset file, to load the real payload at runtime, and leverage reflection to execute the malicious code in the payload. This process is usually much more complex, and involves a round of static analysis first to understand what is in the code, then dynamic analysis to recover the real payload, and then both analyses to understand the real payload. Antivirus vendors often have difficulty identifying such threats. As of June 8, 2016, only 6 out of 54 anti-virus tools labeled these samples as malicious.

Bypassing App Ops Restriction

Android uses app permissions to restrict the set of sensitive actions a particular app can take. With earlier versions of the Android operating system, when an app is installed, the user is prompted to agree to the permissions the app requests. If the user declines, then the app isn’t installed – it is an all or nothing situation. App Ops is a service framework introduced in Android 4.3 that allows the permissions of individual apps to be changed at runtime. With App Ops, users can disallow some permission requests at runtime. Interestingly, we observed that, starting from the Whats-Italy campaign, the overlay malware began to adopt some code to bypass these runtime restrictions.

Figure 10 shows a code snippet in the class MainService, called by the launcher activity at app start time. It checks whether the build version of the device is 19 (Android 4.4) and whether the WRITE_SMS ops are disabled. If both conditions are true, the malware will call the method setWriteEnabled of class SmsWriteOpUtil (at line 93) to re-enable the permission of writing SMS.

Figure 9. Code to check and re-enable the permission of writing SMS

Figure 10 shows the major code of SmsWriteOpUtil to re-enable the SMS writing permission. At line 60, a handle to the system service App Ops is fetched. At line 61, reflection is used to get access to the particular class. At line 64 and 65, the reflection methods getMethod and invoke are used to call a method named setMode. These API methods are usually designed for use by other framework code or pre-installed apps. However, in this case threat actors use reflection to bypass the App Ops restriction.

Figure 10. Code using reflection to call App Ops service and to enable writing SMS

Hosting Sites

To execute Smishing campaigns, threat actors first have to determine where to host their malware. Shared hosting services were used heavily in the RuMMS campaign, but the threat actors in these five campaigns varied it up a bit by using self-registered domains, URL shorteners, and compromised websites.

Self-Registered Domains

In our investigation, we noticed that some of the URL domains were registered a few days before malware was hosted on the sites. Also, we found no other services were provided on these domains. These facts lead us to believe that those sites were registered specifically for the Smishing campaigns.

To lure victim users to clicks these links, the domain names were often carefully crafted for a particular campaign. For example, in the earlier MPay-Denmark campaign, threat actors used the Danish postal service provider as a theme and the Smishing messages came as: “You received an MMS from XXX. Follow hxxp://mms4you[.]us/mms.apk to view the message.” Thus, many of the domains included the words “mms” and/or “you”, such as mmsforyou.pw, mmsservice.pw and mmstildig.net (“til dig” is “for you” in Danish).

In the later PostDanmark campaign, the Smishing messages came as: “Your package is available for pick up. Follow hxxp://postdanmark[.]org/post.apk to see all the information on your package:” Thus, many URL domains had the words “post” and/or “danmark” present, such as postdanmark.net, postdanmark.online, postdanmark.menu and postdanmarks.com. Note that the official website for Post Danmark is “www.postdanmark.dk”, so all these phishing URLs were actually mimicking the official website for Post Danmark.

Shortened URLs

A small screen size makes shortened URLs perfect for mobile devices. Threat actors seem to understand this, and will leverage it for their own gain. While monitoring these five Smishing campaigns in Europe, we observed shortened URLs being used frequently. In total, we observed four different URL shorteners were used at least once, including bit.ly, tr.im, is.gd and jar.ma.

Of the four, bit.ly has been the most commonly used URL shortener. In total, we identified 27 bit.ly links were used from February 2016 to June 2016. The other three URL shorteners were not observed until June 2016, and only one was used for each service. Diversifying URL shorteners suggests that the threat actors are trying to avoid detection.

Compromised Websites

It is costly to use self-registered domains to host malware. More capable threat actors might choose to use compromised websites for the same purpose. Despite the risk of the victim site detecting the compromise and removing the malware, this method can be effective: the compromise is often not noticed until some time later, and the number of victim clicks is usually highest at the start of a campaign and decays a few days after the malware goes online.

While monitoring the five Smishing campaigns, we observed compromised websites were used frequently. For example, the analytics page for the shortened URL hxxps://bitly[.]com/1qRey7a+ shows that on April 13, 2016, website kgiexport.com was hosting an Android app with the file named post.apk.

How Many Clicks?

Two of the four URL shorteners, bit.ly and tr.im, provide analytics pages for each short URL created. Figure 2 showed analytics pages provided by bit.ly. Figure 13 shows a screenshot of the analytics page provided by tr.im. From these pages, we can collect data on how many people clicked the shortened URL at particular dates, and also the countries these clicks came from.

Figure 11. Analytics page provided by tr.im

Table 2 shows relevant information on the 28 short URLs we monitored.

Table 2. Click counts on each short URL

In total, the 28 short links were clicked 161,349 times. Of these clicks, 130,636 were from the PostDanmark campaign, which shows that phishing messages claiming to be from the post office can be effective. We also noticed the number of clicks decayed a few days after these short links were created. For example, there were 96,631 clicks (67.06%) on the first day after short links were created, and there were 30,749 clicks (21.33%) on the second day after short links were created. These clicks come primarily from two countries: Denmark (88.66%) and Austria (5.30%). A handful of other countries might be impacted as well, including Germany, Luxembourg, Spain, Sweden, Norway, United Kingdom, Netherlands, Italy, Greece, and Turkey. 

C2 Server

All of the malicious apps we analyzed contacted a hard-coded C2 server for sending device relevant information and getting back instructions. The URL used is in the form of http://$C2.$SERVER.$IP/?action=command. In total, we found 12 C2 servers hosted in five different countries were involved in these campaigns. Table 3 shows relevant information for each C2 server used in these campaigns.

Table 3. C2 Server Relevant Information

In particular, IP address 85.93.5.109 has been used by 24 malicious apps in the PostDanmark and post-Austria campaigns. IP address 85.93.5.139 has been used by eight malicious apps in the PostDanmark campaign. Note that the first four C2 servers are within the same 85.93.5.0/24 network segment. In total, we found 38 malicious samples contacting these four C2 servers from March 2016 to June 2016.

Part of Something Bigger?

While monitoring the registration records for these self-registered domains, we found something interesting: in March 2016, a single email address (l[REDACTED]a@gmail.com) registered three domains, including postdanmark.org, postdanmark.menu and mmstildig.info, for two of the five campaigns. Using reverse lookup, we found another four similar domains were also registered by the same email address in March 2016. Table 4 shows the relevant information for these domains.

Table 4. Domains registered by the suspected threat actor (l[REDACTED]a@gmail.com)

The first three domains were used to host overlay malware for the MPay-Denmark and PostDanmark campaigns. We found no evidence that the latter four domains were used for similar campaigns, but the same registrant email address and the similar naming convention implies that they may have been created for a similar purpose.

Conclusion

Smishing (SMS phishing) offers a unique vector to infect mobile users. The latest Smishing campaigns spreading in Europe show that Smishing is still a popular means for threat actors to distribute their malware. In addition, threat actors have been using diversified host schemes and different C2 servers, and have been continuously refining their malicious code to keep infecting more users and evade detection.

To protect against these threats, FireEye suggests that users not install apps from outside official app stores, and take caution before clicking any links where the origin is unclear.

To detect and defend against such attacks, we advise our customers to deploy our mobile security solution, FireEye MTP/MSM. This helps our clients gain visibility into threats in their user base, and also enables them to proactively hunt down devices that have been compromised. In addition, we advise our customers with NX appliances to ensure that Wi-Fi traffic is scanned by NX appliances to extend coverage to include mobile devices.

Appendix: Samples

df53b59e354462cd0e704b7b21a750f7
6eb92667ebbbcb2c7ddf6230462222fd
3841abcef2b1b37aa7e2d47c535ca80e
265d37013e1ea39b868515cce157dfeb
49dac3b35afb2e8d3605c72d0d83f631
ffe98d97e7d827aa19abb968a528f3fe
f4b8d64af0a53472901b50621f19d6bf
e1d79608b649c22004ad7cc1cd049528
ef5c9b15755719597481c501f6b603ce
6a300ded487671ef39388b8d28927a83
d33b718737de5aa685672a2004e0fa3c
d83d833092a4fa5ecc436d4246c2f7ce
97c2d04aa0f3c3b446fc228c1dbc4837
82b1006a5f45a6d2baf69544414ada81
9e9d9a3717eed4d558a3f5eddb260901
82d89319fabd998328cc6d4efc4db863
228a4b723bf3d8adc53a69dd0f36c746
e911df33f1d156b3309a4ac220c52070
2b90fca41272bec8b8ffefbb2456c001
40449a2ec48c3e630b2eb8c8089828cf
8d0a03981daa93210e184e7fff02883c
fbdde37d41d12f21c049c570c9bda3de
a18818cb3fb6f189560991cef6d1f929
bf7b72dbb2a9155dabc4eda31d273b92
9762441d52bdec725eff6f2f65e721e9
dba6b4bbf61e054fb978acaf70c3d849
93922ee5fbd149f31b0161deca76df77
035d1f3b7fb532a33de7a8445f9fa325
3f2017a5acb3e57801e2771341287001
06e74df867e9cb5c1bafc98165c6c248
20f4cd2baa09e0bd5e12dab50c0898cd
af7a8d32865e8caf51a99c52834d4422
82d89319fabd998328cc6d4efc4db863
bee3746684b072867a5b202bfc5527dd
a18818cb3fb6f189560991cef6d1f929
8959513f65bcca6f16faef59ad2d152f
cfa92cbcb0674429cc9ce216cc008902
d73d54f6f86c58030477cc9a96eedb85
2f4d81ef1b10bf72d0dba0fdf354527f
701d57504444344b8d5e79bcabcd3dca
fcb4ef63f1d8a3a044ac6f8a7c262546
05131969af2ae6cbfddf789512f02aa2
6e93a7f7911b3e9b522be4b8f950cca4
542f8f77e101d4e8e5d1ef34a3f0df1c
d0a6ba40e05047dc2cff12935c4cf4fb
23988abad7c7b2ecdda23ae7194b7a0d
2c055d7b5199604cd5cf3441073b36b3
a72aa534973eeaf0782a246d502107a3
f1c8a3337cbd56e01e478774f5d55278
da222d4b7993a62665b9eaef10c1846f
152f626eb92676f940ada4b7077acf16
7a99b60349703aed3ab28f498320f247
1b9e1cd2c7f8e227b2ae5fb5bc735536
d84ff5a7e7c0c33dcfa237299869bc34
d70296d3dc4937dedd44f93bb3b74034
88b23b6a5c1b72aeff2fc42e05c173a7
036258e2c51e21c140b5838ce9bfb4f8

A security researcher recently published source code for a working exploit for CVE-2016-0189 and the Neutrino Exploit Kit (EK) quickly adopted it.

CVE-2016-0189 was originally exploited as a zero-day vulnerability in targeted attacks in Asia. The vulnerability resides within scripting engines in Microsoft’s Internet Explorer (IE) browser, and is exploited to achieve Remote Code Execution (RCE). According to the researcher’s repository, the open source exploit affects IE on at least Windows 10. It is possible that attackers could use or repurpose the attack for earlier versions of Windows.

Microsoft patched CVE-2016-0189 in May on Patch Tuesday. Applying this patch will protect a system from this exploit.

Attack Details

The popular Neutrino EK was quick to adopt this exploit. Neutrino works by embedding multiple exploits into one Shockwave Flash (SWF) file. Once run, the SWF profiles the victim’s system – shown in Figure 1 – to determine which of its embedded exploits to use.

Figure 1. Neutrino EK SWF profiles a victim

Next, it decrypts and runs the applicable exploit, as shown in Figure 2. This is different from most other EKs, in which an earlier HTML/JavaScript stage profiles the browser and selectively downloads exploits from the server.

Figure 2. Decrypt and embed the selected exploit into an iframe

In this example, Neutrino embedded exploits for five patched vulnerabilities: three for Adobe Flash Player (CVE-2016-4117, CVE-2016-1019, CVE-2015-8651) and two for Internet Explorer (CVE-2016-0189, CVE-2014-6332). CVE-2016-0189 is the newest addition to Neutrino’s arsenal.

CVE-2016-0189

This CVE-2016-0189 vulnerability stems from a failure to put a lock on an array before working on it. This omission can lead to an issue when the array is changed while another function is in the middle of working on it. Memory corruption can occur if the “valueOf “ property of the array is set to a script function that changes the array size, as shown in Figure 3.

Figure 3. Neutrino setting triggering conditions

After Microsoft released the patch, a security researcher compared the original and patched programs to identify the root cause of the vulnerability and create a fully functioning exploit. The exploit embedded within Neutrino is identical to this researcher’s exploit, except for the code that runs after initial control.

Ransomware is a common method of cyber extortion for financial gain that typically involves users being unable to interact with their files, applications or systems until a ransom is paid. Accessibility of cryptocurrency such as Bitcoin has directly contributed to this ransomware model. Based on data from FireEye Dynamic Threat Intelligence (DTI), ransomware activities have been rising fairly steadily since mid-2015.

On June 10, 2016, FireEye’s HX detected a Cerber ransomware campaign involving the distribution of emails with a malicious Microsoft Word document attached. If a recipient were to open the document a malicious macro would contact an attacker-controlled website to download and install the Cerber family of ransomware.

Exploit Guard, a major new feature of FireEye Endpoint Security (HX), detected the threat and alerted HX customers on infections in the field so that organizations could inhibit the deployment of Cerber ransomware. After investigating further, the FireEye research team worked with security agency CERT-Netherlands, as well as web hosting providers who unknowingly hosted the Cerber installer, and were able to shut down that instance of the Cerber command and control (C2) within hours of detecting the activity. With the attacker-controlled servers offline, macros and other malicious payloads configured to download are incapable of infecting users with ransomware.

FireEye hasn’t seen any additional infections from this attacker since shutting down the C2 server, although the attacker could configure one or more additional C2 servers and resume the campaign at any time. This particular campaign was observed on six unique endpoints from three different FireEye endpoint security customers. HX has proven effective at detecting and inhibiting the success of Cerber malware.

Attack Process

The Cerber ransomware attack cycle we observed can be broadly broken down into eight steps:

1. Target receives and opens a Word document.
2. Macro in document is invoked to run PowerShell in hidden mode.
3. Control is passed to PowerShell, which connects to a malicious site to download the ransomware.
4. On successful connection, the ransomware is written to the disk of the victim.
5. PowerShell executes the ransomware.
6. The malware configures multiple concurrent persistence mechanisms by creating command processor, screensaver, startup.run and runonce registry entries.
7. The executable uses native Windows utilities such as WMIC and/or VSSAdmin to delete backups and shadow copies.
8. Files are encrypted and messages are presented to the user requesting payment.

Rather than waiting for the payload to be downloaded or started around stage four or five of the aforementioned attack cycle, Exploit Guard provides coverage for most steps of the attack cycle – beginning in this case at the second step.

The most common way to deliver ransomware is via Word documents with embedded macros or a Microsoft Office exploit. FireEye Exploit Guard detects both of these attacks at the initial stage of the attack cycle.

PowerShell Abuse

When the victim opens the attached Word document, the malicious macro writes a small piece of VBScript into memory and executes it. This VBScript executes PowerShell to connect to an attacker-controlled server and download the ransomware (profilest.exe), as seen in Figure 1.

Figure 1. Launch sequence of Cerber – the macro is responsible for invoking PowerShell and PowerShell downloads and runs the malware

It has been increasingly common for threat actors to use malicious macros to infect users because the majority of organizations permit macros to run from Internet-sourced office documents.

In this case we observed the macrocode calling PowerShell to bypass execution policies – and run in hidden as well as encrypted mode – with the intention that PowerShell would download the ransomware and execute it without the knowledge of the victim.

Further investigation of the link and executable showed that every few seconds the malware hash changed with a more current compilation timestamp and different appended data bytes – a technique often used to evade hash-based detection.

Cerber in Action

Initial payload behavior

Upon execution, the Cerber malware will check to see where it is being launched from. Unless it is being launched from a specific location (%APPDATA%\&#60GUID&#62), it creates a copy of itself in the victim's %APPDATA% folder under a filename chosen randomly and obtained from the %WINDIR%\system32 folder.

If the malware is launched from the specific aforementioned folder and after eliminating any blacklisted filenames from an internal list, then the malware creates a renamed copy of itself to “%APPDATA%\&#60GUID&#62” using a pseudo-randomly selected name from the “system32” directory. The malware executes the malware from the new location and then cleans up after itself.

Shadow deletion

As with many other ransomware families, Cerber will bypass UAC checks, delete any volume shadow copies and disable safe boot options. Cerber accomplished this by launching the following processes using respective arguments:

Vssadmin.exe "delete shadows /all /quiet"

WMIC.exe "shadowcopy delete"

Bcdedit.exe "/set {default} recoveryenabled no"

Bcdedit.exe "/set {default} bootstatuspolicy ignoreallfailures

Coercion

People may wonder why victims pay the ransom to the threat actors. In some cases it is as simple as needing to get files back, but in other instances a victim may feel coerced or even intimidated. We noticed these tactics being used in this campaign, where the victim is shown the message in Figure 2 upon being infected with Cerber.

Figure 2. A message to the victim after encryption

The ransomware authors attempt to incentivize the victim into paying quickly by providing a 50 percent discount if the ransom is paid within a certain timeframe, as seen in Figure 3.

Figure 3. Ransom offered to victim, which is discounted for five days

Multilingual Support

As seen in Figure 4, the Cerber ransomware presented its message and instructions in 12 different languages, indicating this attack was on a global scale.

Figure 4.   Interface provided to the victim to pay ransom supports 12 languages

Encryption

Cerber targets 294 different file extensions for encryption, including .doc (typically Microsoft Word documents), .ppt (generally Microsoft PowerPoint slideshows), .jpg and other images. It also targets financial file formats such as. ibank (used with certain personal finance management software) and .wallet (used for Bitcoin).

Selective Targeting

Selective targeting was used in this campaign. The attackers were observed checking the country code of a host machine’s public IP address against a list of blacklisted countries in the JSON configuration, utilizing online services such as ipinfo.io to verify the information. Blacklisted (protected) countries include: Armenia, Azerbaijan, Belarus, Georgia, Kyrgyzstan, Kazakhstan, Moldova, Russia, Turkmenistan, Tajikistan, Ukraine, and Uzbekistan.

The attack also checked a system's keyboard layout to further ensure it avoided infecting machines in the attackers geography: 1049—Russian, ¨ 1058—Ukrainian, 1059—Belarusian, 1064—Tajik, 1067—Armenian, 1068—Azeri, (Latin), 1079—Georgian, 1087—Kazakh, 1088—Kyrgyz (Cyrillic), 1090—Turkmen, 1091—Uzbek (Latin), 2072—Romanian (Moldova), 2073—Russian (Moldova), 2092—Azeri (Cyrillic), 2115—Uzbek (Cyrillic).

Selective targeting has historically been used to keep malware from infecting endpoints within the author’s geographical region, thus protecting them from the wrath of local authorities. The actor also controls their exposure using this technique. In this case, there is reason to suspect the attackers are based in Russia or the surrounding region.

Anti VM Checks

The malware searches for a series of hooked modules, specific filenames and paths, and known sandbox volume serial numbers, including: sbiedll.dll, dir_watch.dll, api_log.dll, dbghelp.dll, Frz_State, C:\popupkiller.exe, C:\stimulator.exe, C:\TOOLS\execute.exe, \sand-box\, \cwsandbox\, \sandbox\, 0CD1A40, 6CBBC508, 774E1682, 837F873E, 8B6F64BC.

Aside from the aforementioned checks and blacklisting, there is also a wait option built in where the payload will delay execution on an infected machine before it launches an encryption routine. This technique was likely implemented to further avoid detection within sandbox environments.

Persistence

Once executed, Cerber deploys the following persistence techniques to make sure a system remains infected:

• A registry key is added to launch the malware instead of the screensaver when the system becomes idle.
• The “CommandProcessor” Autorun keyvalue is changed to point to the Cerber payload so that the malware will be launched each time the Windows terminal, “cmd.exe”, is launched.
• A shortcut (.lnk) file is added to the startup folder. This file references the ransomware and Windows will execute the file immediately after the infected user logs in.
• Common persistence methods such as run and runonce key are also used.

A Solid Defense

Mitigating ransomware malware has become a high priority for affected organizations because passive security technologies such as signature-based containment have proven ineffective.

Malware authors have demonstrated an ability to outpace most endpoint controls by compiling multiple variations of their malware with minor binary differences. By using alternative packers and compilers, authors are increasing the level of effort for researchers and reverse-engineers. Unfortunately, those efforts don’t scale.

Disabling support for macros in documents from the Internet and increasing user awareness are two ways to reduce the likelihood of infection. If you can, consider blocking connections to websites you haven’t explicitly whitelisted. However, these controls may not be sufficient to prevent all infections or they may not be possible based on your organization.

FireEye Endpoint Security with Exploit Guard helps to detect exploits and techniques used by ransomware attacks (and other threat activity) during execution and provides analysts with greater visibility. This helps your security team conduct more detailed investigations of broader categories of threats. This information enables your organization to quickly stop threats and adapt defenses as needed.

Conclusion

Ransomware has become an increasingly common and effective attack affecting enterprises, impacting productivity and preventing users from accessing files and data.

Mitigating the threat of ransomware requires strong endpoint controls, and may include technologies that allow security personnel to quickly analyze multiple systems and correlate events to identify and respond to threats.

HX with Exploit Guard uses behavioral intelligence to accelerate this process, quickly analyzing endpoints within your enterprise and alerting your team so they can conduct an investigation and scope the compromise in real-time.

Traditional defenses don’t have the granular view required to do this, nor can they connect the dots of discreet individual processes that may be steps in an attack. This takes behavioral intelligence that is able to quickly analyze a wide array of processes and alert on them so analysts and security teams can conduct a complete investigation into what has, or is, transpiring. This can only be done if those professionals have the right tools and the visibility into all endpoint activity to effectively find every aspect of a threat and deal with it, all in real-time. Also, at FireEye, we go one step ahead and contact relevant authorities to bring down these types of campaigns.

Click here for more information about Exploit Guard technology.

FireEye has identified a campaign involving phishing websites that appear as legitimate Amazon sites. Amazon is the largest online retailer and threat actors frequently target its customers. In this attack, a person browsing the internet would be directed to authentic looking – yet fake – Amazon webpages that request a variety of information, including Amazon credentials, home address and payment card data. Any information entered into the phishing websites could be sent to the attackers and potentially used to make fraudulent charges and commit other crimes.

FireEye detected this phishing campaign through our email MPS platform and has seen attacks primarily targeting Amazon customers in the U.S., Canada and Europe. FireEye has made Amazon.com aware of this phishing campaign. In addition to aggressively investigating all suspicious email reports, Amazon.com provides resources for customers to identify whether an email is from Amazon.com and to protect their systems.

While there have been numerous reports on Amazon phishing attacks in the past, this campaign is particularly interesting for security analysts because of the evasion techniques being used by the attackers. Though various instances of this phishing practice have been previously used, we’ve been following this particular campaign variant since June 21, 2016. Some of the evasion techniques used in this campaign include:

• The phishing page sitting in a legitimate domain, leveraging the good reputation of the compromised (non-Amazon) site.
• The campaign being browser-aware in terms of the URL it displays in the browser.
• The use of numerical HTML encoding of Unicode Characters.
• IP-based evasion, URL path randomization and redirection to an endpoint host to ensure the final phishing URL is always unique.

Phishing Template Presentation and Techniques

After clicking the initial URL, the user is redirected to the phishing template page hosted on another compromised site. The campaign is browser-aware in terms of the URL it displays in the browser.  Hexadecimal encoded domains are displayed when Firefox or Safari are used while clear text is displayed in Chrome. An example rendering is shown in Figure 1.

Figure 1. Initial Phishing Page

To the user, the page appears to be a legitimate Amazon login page. Behind the scenes, however, numerical HTML encoding of Unicode characters are prevalent throughout the page serving up the fake Amazon login page, as shown in Figure 2. This tactic helps to evade text-based detections.

Figure 2. Numerical HTML encoding of Unicode Characters in the Amazon phishing page.

Redirection Analysis and Evasion Techniques

The malicious actor behind this phishing campaign regularly updated connect.php on the initial compromised host. The purpose of the initial host is to redirect users to infected machines hosting phishing sites where the phishing template page has been uploaded. As these endpoint phishing sites get taken down, a new one is established and the redirection page is modified to point to the new phishing page location.

Figure 3 shows an example of a complete redirection chain.

Figure 3. Redirection Chain example

After the initial redirection to the second URL in the chain, the first thing the server does is include an anti-detection module. This anti-detection module blocks certain IPs, including search engines such as Google, anti-phishing tools such as Netcraft, and other network service providers. This makes the website not detectable by bots by returning a 404 Not Found page instead of continuing redirection to the phishing template. An example of the extracted IP based anti-detection code is shown in Figure 4.

Figure 4. IP based anti-detection code

The next action the server takes if their IP is not banned is to record a log of the victims who visit the page. Code extracted shows that the logging includes the visitor’s IP, user-agent, operating system, browser, hostname and referer information, as shown in Figure 5.  

Figure 5. Visitor tracking code

Figure 6 shows the debug log file left by the template writer.

Figure 6. Debug log file

After logging the user information, code is executed to create a random md5 hash path name for the phishing page that will ultimately be served to the end user. After all resources are copied to the random path, the server redirects the visitor to this path (redirections 3 through 5 in Figure 3), thus rendering the actual phishing page in the user’s browser. The code responsible for generating the random path is shown in Figure 7.

Figure 7. Path randomization code

Credential Harvesting and Final Redirection

At this point, the initial phishing template page shown in Figure 1 is rendered in the user’s browser.  After entering their initial login credentials, the user is taken through a series of two more pages shown in Figure 8 and Figure 9. This is to harvest address and billing information.

Figure 8. Fake Address Verification Page

Figure 9. Fake Billing Information Page

After the victim has entered all the requested information, the server sends an email containing the information to the attacker’s email address and redirects the user to the real Amazon webpage.

The code shown in Figure 10 is the code that builds the email message sent to the phisher.

Figure 10. Email building code

The victim’s information is contained in the $message variable that is built from the user’s responses to the pages shown in Figure 8 and Figure 9.  Figure 11 shows the code that builds the message contents, which contains the harvested user’s information.

Figure 11. Message building code

After the harvested credentials are emailed to the attackers, the user is sent a final redirection to the legitimate Amazon page. The code behind this redirection is shown in Figure 12.

Figure 12. Final redirection

Conclusion

Detecting these types of threats can be tricky, particularly when the attacker is leveraging some interesting evasion techniques. Oftentimes users are redirected to phishing pages after clicking on a malicious link. FireEye recommends that users exercise caution when clicking on links from untrusted parties, avoid opening emails from unknown senders, and be wary of emails from anyone requesting personally identifiable information. Additionally, and most importantly, users should only log into Amazon by visiting the website directly.

In many cases Red Team tools are not written because someone feels like writing a tool, or wakes up one morning thinking, “I want to write a tool today”. Red Teamers generally identify tedious tasks in their methodology and then create tools that automate these tasks for current and future assessments. As my boss likes to say, jokingly: laziness breeds ingenuity!

At Mandiant, we’ve developed (or significantly contributed to) a fair number of tools and scripts to make our lives easier. In order to ensure the broader security community is aware of these tools and where to download them from, we’re going to start releasing a “tool roundup” blog post on a semi-regular basis. The intent of these blog posts is to highlight newly developed tools, or major changes to existing tools. We also make this a fun read by including some case studies to demonstrate tool use.

Our Red Team is frequently introduced to diverse networks, technologies, defenses, and organizational structures. Each network presents new challenges that must be overcome, and with all clients, there is overlap with infrastructure and configuration. Existing public tools might not scale properly in larger environments or might not help the Red Team address specific phases of an attack life cycle. The tools being discussed have all been revised or developed in some form or fashion over the last couple of months. We hope they make your engagements easier and bring awareness to the community.

Domain Enumeration

Tool: ADEnumerator (https://github.com/chango77747/AdEnumerator)

Domain enumeration is an essential task during the reconnaissance phase of the attack life cycle. When you compromise a domain-joined system, it is fairly simple to enumerate objects from the domain using Active Directory Service Interfaces (ADSI) or the Windows “net” commands. ADSI works well from non-domain joined systems using the “runas” command with the “netonly” switch, as shown in Figure 1. It can be a hassle to craft detailed LDAP queries for ADSI to perform domain enumeration, so we automated this processing using raw LDAP queries in a tool called ADEnumerator.

Figure 1. Using PowerShell and ADSI for domain enumeration

ADEnumerator is a PowerShell module designed to query Active Directory servers from non-domain systems. The following use cases apply to ADEnumerator:

1. You harvest domain credentials from a printer, via NBNS spoofing, etc., and want to start performing domain enumeration. Note: Any domain user credential can query LDAP.
2. You want to gather more information about an account you harvested. Group naming conventions often reveal where you can use those credentials (for example, group name {systemName}_localAdmin).
3. You are provided with credentials to start an internal penetration test from a known compromise perspective, but not a domain-joined system.
4. You want to perform Active Directory enumeration from the command line so you can chain commands together.

Figure 2 demonstrates importing the ADEnumerator.psm1 module, establishing an LDAP connection to a domain controller, and executing various domain enumeration methods. There are plenty of additional methods within ADEnumerator – see the header of the script for a full list of methods.

Figure 2. ADEnumertor.psm1 import and enumeration

Alternatively, you can install Remote Server Administration Tools on your attack platform and use “runas” to execute “mmc” and add the Active Directory snap-in. Then you can change the domain to your target domain and view the entire Active Directory structure in a GUI, as shown in Figure 3.

Figure 3. Active Directory snap-in running as different user

Privilege Escalation and Lateral Movement

Tools: CredNinja (https://github.com/Raikia/CredNinja) & WMIOps (https://github.com/ChrisTruncer/WMIOps)

Have you been in a situation where you have a list of more than 100 credentials, but you are not sure which credentials are valid? Or, you’re not sure which credentials have administrative rights to a target system? CredNinja was created for just that (and it can do more!). Use cases and general functionality are as follows:

• Leverages SMB access (TCP port 445)
• Attempts to mount C$ of all provided systems, returns:

        o   Logon Failure – Invalid credentials (protection against locking out accounts included)
        o   Access Denied – Not local admin
        o   File listing – Local admin!

• Multi-threaded – so you can scale properly in those large environments
• Fingerprints target operating system version and domain membership
• If “–users” flag is enabled, it will perform a directory listing of “C:\Users” (or C:\Documents and Settings if its XP), look at the timestamp of all the home folders, and print out the users that have a home folder modified timestamp of within 100 days (this value is customizable, but the default is 100 days).
      o   Provides a quick user-hunting functionality to identify active users on the targeted system.

CredNinja is very useful when performing privilege escalation and lateral movement because you can identify systems for which your credentials have elevated privileges, and continue dumping credentials on those systems. Figure 4 demonstrates the power of CredNinja by identifying various systems where the domain credentials have local administrator rights, and whether or not credentials are invalid. CredNinja can also be run against a single system to clean up your credential list by removing invalid credentials.

Figure 4. CredNinja run against various systems using credential list

Windows Management Instrumentation (WMI) is the new hotness in terms of offensive capabilities. WMIOps is a PowerShell script that uses WMI to perform a variety of actions on hosts, local or remote, within a Windows environment. It was designed primarily for use on penetration tests or Red Team engagements. Some existing tools use WMI for offensive tasks; WMIOps was built to combine these techniques into a single tool to accomplish various tasks in the attack life cycle.

Figure 5 shows the Get-ProcessOwnersWMI method in WMIOps to get a list of users from target system Win7-Client02. User “Dick.Grayson” had local administrator privileges on Win7-Client02 and was authorized to execute arbitrary WMI commands. User “Bruce.Wayne” had running processes on Win7-Client02, which indicates that the user potentially has clear text credentials stored in Local Security Authority Subsystem Service (LSASS).

To obtain credentials for “Bruce.Wayne”, WMIOps method Invoke-RemoteScriptWithOutput is used in Figure 6 to execute a remote PowerShell process that issues command “Invoke-Expression” to download and execute the “Invoke-Mimikatz” script over HTTPS. The command also instructs the output to be sent to web server 10.181.73.210 listening on HTTPS. Mimikatz output was sent to the web server, as shown in Figure 7.

Figure 5. Get-ProcessOwnersWMI method in WMIOps to get a list of users with running processes

Figure 6. Invoke-RemoteScriptWithOutput method to call Invoke-Mimikatz and send output to the "callbacksite"

Figure 7. Mimikatz output sent from the command executed in Figure 4

Initial Vectors

Tool: EyeWitness (https://github.com/ChrisTruncer/EyeWitness)

One of the most common initial vectors into a network is default credentials to known web administrative portals such as Jboss, Apache Tomcat, Jenkins, etc. EyeWitness is known to scale networks by taking screenshots of the web page of each web server identified in your reconnaissance phase. We added an “active-scan” module to EyeWitness that provides the following functionalities:

• Signature authentication – Checks if the host has a known default credential signature and attempts to login using default credentials stored in a data file.
• Check for login – Checks to see if the root path is a web login form, or is HTTP basic authentication, and attempts to authenticate to the web application using username and password combinations stored in a data file.
• Append URLs to check for logins – Appends a list of common login pages to the web root directory. Examples of these pages are “admin”, “login”, “login.php” and more. The list of pages is stored in a data file so that it is easily customizable; feel free to add more and contribute!
      o   If a page receives a HTTP 200 response code, it will check to see if it’s a login form.
      o   EyeWitness will attempt to login to the form using username and password combinations stored in a data file.

The “active-scan” Boolean flag is shown in Figure 8. Example report and console output is shown in Figure 9 and Figure 10. An additional category called “Identified Logins” is also added to the report if EyeWitness identified a login, but was not able to authenticate to it. If you want to learn more about this module, a full blog post on this module was written here: https://www.christophertruncer.com/eyewitness-and-active-account-enumeration/.

Figure 8. Active-scan flag in EyeWitness

Figure 9. Successful authentication using the active-scan module

Figure 10. EyeWitness report output

Attacker Simulation

Tool: Egress-Assess (https://github.com/ChrisTruncer/Egress-Assess)

The combined capabilities of Mandiant, FireEye, and iSIGHT Partners brings unparalleled threat intelligence and technology to every engagement. Clients regularly ask us to identify threat actors targeting their industry specifically and to emulate their TTPs to assess the organization’s current detection capabilities. Egress-Assess is a Python tool that was created to emulate known attacker TTPs, such as IP addresses and Fully Qualified Domain Names (FQDNs) connecting to the Internet. Egress-Assess is publicly available; however, Mandiant maintains a proprietary version of Egress-Assess that contains known network-based indicators (NBIs) that replicate real threat groups.

Egress-Assess modifies the host value in the HTTP(s) header request to be a known-bad IP address or FQDN, and generates web requests to known-bad URIs. Furthermore, the tool can generate fake PII, PHI, or PCI data to emulate data theft. We use Egress-Assess to assess our client’s detection capabilities by emulating real threat group indicators and/or data theft. A list of supported threat actor groups available in the public version of Egress-Assess is shown in Figure 11. If you want to learn more about this Egress-Assess, a full blog post on this module was written here: https://www.christophertruncer.com/egress-assess-testing-egress-data-detection-capabilities/.

Figure 11. List of threat actors available in Egress-Assess

Conclusion

These are just a handful of tools and practical examples of using those tools for Red Team operations. We encourage you to play with these tools and start using them on your assessments or in your labs.

We want to reemphasize that each tool was created or modified as the need was identified. It can be very exciting to identify a need and develop tools and techniques to automate a task or accomplish an objective. Some tools introduce new techniques to accomplish a goal, while other tools simply automate existing tools and techniques to scale better. Whatever your motive, introducing new tools and techniques is an excellent way to provide awareness in our industry and generate higher quality security.

As a reverse engineer on the FLARE (FireEye Labs Advanced Reverse Engineering) team, I regularly perform basic dynamic analysis of malware samples. The goal is to quickly observe runtime characteristics by running binaries in a safe environment. One important task during dynamic analysis is to emulate the network environment and trick the malware into thinking it is connected to the Internet. When done right, the malware reveals its network signatures such as command and control (C2) domain names, User-Agent strings, URLs queried, and so on.

One tool of choice is FakeNet. In this blog, I will discuss a major overhaul to FakeNet and how it helps you perform basic malware dynamic analysis. Some of the new features include full support for Windows Vista and later operating systems, process logging, advanced process and host traffic filtering engine, support for third party tools (e.g. debuggers, HTTP proxies, etc.) and many others.

This blog covers the basic installation and most common scenarios for running FakeNet-NG. I invite you to review the complete documentation available here.

Getting and Installing FakeNet-NG

The tool can be found on FLARE’s official Github repository here.

From the releases page, download the latest pre-compiled archive. Next, copy the release archive to the Malware Analysis VM and extract it in an easily accessible location.

Running FakeNet-NG

The simplest way to run FakeNet-NG is to double click on fakenet64.exe or fakenet32.exe for the 64-bit or 32-bit versions of Windows, respectively, as illustrated in Figure 1.

Figure 1: Running FakeNet-NG

The tool requires Administrator access, so you will have to confirm the UAC prompt requesting elevated privileges. Once launched you will see a console window similar to the one in Figure 2.

Figure 2: FakeNet-NG Startup

By default, FakeNet-NG is configured to start several most commonly used services:

• DNS Listener on UDP port 53
• HTTP Listener on TCP port 80
• HTTPS Listener on TCP port 443
• SMTP Listener on TCP port 25
• Raw Binary Listener on both TCP and UDP ports 1337. This service is also used as a default listener to handle all communications. Default listeners are explained below.

At this point you are ready to run a malware sample and observe its behavior. Figure 3 illustrates sample malware communication to the C2 server.

Figure 3: Sample malware communication

There are quite a few things going on in the log output above so let’s break it down into smaller components.

Once launched, the malware attempts to resolve a C2 domain evil.mandiant.com by querying the configured DNS server 4.2.2.2. Figure 4 illustrates how FakeNet-NG diverts the traffic from 4.2.2.2 to the local machine’s IP address 172.16.163.131.

Figure 4: Diverting DNS traffic

A major benefit of running FakeNet-NG on the same host as the malware is that it can perform additional analysis of running executables. For example, FakeNet-NG is capable of detecting the exact executable name that is generating traffic. In this case, we can see that level1_payload.exe is generating the above DNS traffic.

Continuing with the analysis, Figure 5 shows FakeNet-NG’s DNS listener providing a fake response to the query pointing malware to a fake C2 IP address 192.0.2.123.

Figure 5: Faking DNS response

After successfully resolving the domain, the malware proceeds to communicate with the C2 domain name, as shown in Figure 6.

Figure 6: Faking C2 communication

FakeNet-NG implements a few popular network listeners. In this case, the malware is communicating using the HTTP protocol on port 80. The output above provides us with several good network indicators such as the exact URL requested and User-Agent used in the communication, as well as the unencrypted beacon payload containing the compromised host’s machine name. All of these indicators can be used to create good network signatures to detect this malware sample.

By default, FakeNet-NG captures all of the intercepted traffic in PCAP files so you can perform additional analysis. For example, Figure 7 shows both original and diverted packets performing DNS resolution as well as HTTP POST requests to the C2 server.

Figure 7: Wireshark PCAP

Captured PCAP files are stored in the same directory as the FakeNet-NG’s executable. As an added logging feature, FakeNet-NG will also preserve complete HTTP POST payloads in separate text files also stored in the executable’s working path.

Configuring FakeNet-NG

By default, FakeNet-NG is configured to cover the majority of malware analysis scenarios. However, if you encounter a more complex sample, then you can easily adapt the tool by editing one of the few configuration files located in the configs directory. By default, FakeNet-NG loads default.ini configuration file when it loads. You can either modify that file or create a new one and point FakeNet-NG to load it with the –c command-line parameter. Consider a sample scenario, where you have malware communicating using a binary protocol on port 4444. Figure 8 illustrates a sample listener configuration that will fake this service.

Figure 8: Custom Listener Configuration

The key elements of the configuration above are Port, Protocol and Listener. Port and Protocol attributes define the port and protocol used to both setup the listener service and define the rule to divert traffic. The Listener attribute is used to define a specific listener class. In this case, RawListener is used to handle arbitrary binary protocols. Alternatively, if you wanted to setup a listener to handle HTTP or HTTPS traffic you would use HTTPListener instead. Please refer to the documentation for a complete list of supported listeners and available options.

With the above configuration appended to the active configuration file, we can now launch FakeNet-NG and intercept traffic destined to TCP port 4444, as shown in Figure 9.

Figure 9: Diverting to Custom Listener

The scenario above was for a single, known port that the malware would use for its communication. In many cases it is hard to predict the exact port used from basic static or dynamic analysis. Instead, let’s use another powerful feature that essentially allows you to handle any traffic to any port by a default listener. In order to configure the default listener, edit the [Diverter] section in the configuration file as follows in Figure 10.

Figure 10: Default Listener Configuration

Now, if the same malware sample decided to communicate on another port (e.g. 5555), it would still be intercepted and handled by the previously defined CustomListener4444.

Figure 11: Diverting to Default Listener

The Figure 11 illustrates traffic going to the unknown port 5555 being diverted to the previously defined custom listener on port 4444. It is important to note that any explicitly defined listeners will take precedence over the default listener. So if you have DNS or HTTP listeners defined on UDP port 53 and TCP port 80 respectively, then they would handle diverted traffic instead of the default listener as expected.

New Code Base

The new FakeNet-NG is developed completely in Python so it is easy to implement new services and features. It no longer uses the deprecated LSP (WinSock Layered Service Provider) driver implemented in the original FakeNet. Instead, FakeNet-NG relies on the excellent PyDivert\WinDivert library, which comes with a WFP (Windows Filtering Platform) driver that performs all of the traffic redirection.

Conclusion

This blog shares a few techniques that can be used to quickly perform basic dynamic malware analysis and extract good network-based indicators. FakeNet-NG is a powerful and highly configurable tool that can be used to perform more advanced tasks such as process and traffic filtering, aiding in automatic malware unpacking, security assessment of thick-client applications and many others. Stay tuned for future blog posts that demonstrate the full features of this tool.

Try out FakeNet-NG the next time you need to perform malware analysis, security assessment or simply to divert network traffic and fake network responses. We hope you love this tool as much as we do on the FLARE team.

In the past several years, a flood of vulnerabilities has hit industrial control systems (ICS) – the technological backbone of electric grids, water supplies, and production lines. These vulnerabilities affect the reliable operation of sensors, programmable controllers, software and networking equipment used to automate and monitor the physical processes that keep our modern world running.

FireEye iSIGHT Intelligence has identified nearly 1,600 publicly disclosed ICS vulnerabilities since 2000. We go more in depth on these issues in our latest report, Overload: Critical Lessons from 15 Years of ICS Vulnerabilities, which highlights trends in total ICS vulnerability disclosures, patch availability, vulnerable device type and vulnerabilities exploited in the wild.

FireEye’s acquisition of iSIGHT provided tremendous visibility into the depth and breadth of vulnerabilities in the ICS landscape and how threat actors try to exploit them. To make matters worse, many of these vulnerabilities are left unpatched and some are simply unpatchable due to outdated technology, thus increasing the attack surface for potential adversaries. In fact, nation-state cyber threat actors have exploited five of these vulnerabilities in attacks since 2009.

Unfortunately, security personnel from manufacturing, energy, water and other industries are often unaware of their own control system assets, not to mention the vulnerabilities that affect them. As a result, organizations operating these systems are missing the warnings and leaving their industrial environments exposed to potential threats.

Click here to download the report and learn more.

Throughout August, FireEye Labs has observed a few massive email campaigns distributing Locky ransomware. The campaigns have affected various industries, with the healthcare industry being hit the hardest based on our telemetry, as seen in Figure 1.

Figure 1. Top 10 affected industries

Numerous countries are affected, with the United States, Japan, and Republic of Korea topping the list, as seen in Figure 2.

Figure 2. Top affected countries

From our trend analysis seen in Figure 3, Locky ransomware started being delivered via DOCM format email attachments more extensively beginning in August. This marks a change from the large campaigns we observed in March, where a JavaScript based downloader was generally being used to infect systems.

These detection spikes and change in tactics suggest that the cybercriminals are investing more to infect systems and maximize their profits. Additionally, we have observed that the delivery of Dridex via this distribution channel seems to have stopped, or nearly so, which could explain why we are seeing the Locky uptick.

Figure 3. Massive DOCM related campaigns on Aug. 9, Aug. 11 and Aug. 15, 2016

Our analysis showed high similarity in the macro code that was used in the Aug. 9, Aug. 11 and Aug. 15 campaigns. The following are the key comparisons:

1. Each email campaign has a specific “one-off” campaign code that is used to download the Locky ransomware payload from the malicious malware server (see network pattern in Figure 4).
2. The malicious URL embedded within macro code is encoded using the same encoding function, but with a different key for each campaign. Each character is encoded by multiplying its ASCII code with a specified key (an integer). Hence, its decoder would perform a division using the specified integer (see URL Decoder in Figure 4).
3. The downloaded payload is encoded using 32 bytes rolling XOR key. A different key is used for each campaign. Rolling XOR is described as follows:

Plain [i] = Cipher [i] ^ Key [i % length of Key], where Plain is the computed plain text, Cipher is the cipher text, Key is the xor key, and i is the byte offset (see File Decoder in Figure 4).

Figure 4. Technical Overview

The volume of Locky ransomware downloaders is increasing and the tools and techniques being used in campaigns are constantly changing. In this instance, we are seeing a shift from using a JavaScript based downloader to infect victims to using the DOCM format. On top of that, cybercrime trends have shown that attackers are distributing more ransomware these days than banking trojans, as the former appears to be more lucrative.

These latest campaigns are a reminder that users must be cautious when it comes to opening attachments in emails or they run the risk of becoming infected and possibly disrupting business operations.

Hello my name is: WMI

WMI has been a core component of Windows since Windows 98, but it is not exactly old wine in a new bottle. WMI more closely resembles that bottle of ‘61 Bordeaux wine that continues to impress us as it ages and matures. WMI was developed as Microsoft’s interpretation of web-based enterprise management (WBEM) for system management and auditing; however, adversaries can use it for all stages of the Attack Lifecycle (shown in Figure 1), from creating the initial foothold on a system to stealing data from the environment and everything in-between. From an investigative perspective, WMI has only recently been used by a select few groups of attackers and it is an artifact that may be overlooked during investigations. Though WMI does not provide a default detailed tracing log[1] of execution or persistence activity.

Figure 1. The Attack Lifecycle

In this blog post we will discuss how attackers can use WMI as a remote execution utility and as a persistence mechanism to execute malware, as well as what you can do to detect this activity at enterprise scale.

The Problem

We were recently onsite for a Red Teaming for Security Operations engagement, where our Red Team utilized WMI as a remote execution utility (similar to PsExec) and as a malware persistence mechanism (similar to a system service). We quickly realized that the client’s Security Operations Center (SOC) did not have the capabilities to detect this activity from both a network and endpoint perspective, so we opted to pause the red teaming activities and work with the client to identify a solution to this lack of visibility.

The Solution

We determined that following the attacker adage of “living off the land” was what we needed to solve the problem from a defense perspective. In other words, we leveraged WMI to monitor itself and feed WMI-invoked process creations and persistence activity directly into the system’s Application event log. This allowed our client the ability to feed these logs from endpoints into their SIEM and achieve greater visibility into their entire environment.

To accomplish this, we created a WMI subscription. A subscription is the term used for WMI persistence, and it consists of the following three items:

1. An Event Consumer: An action to perform upon triggering an event of interest
2. An Event Filter: The event of interest
3. A Filter to Consumer Binding: The registration mechanism that binds a filter to a consumer

This WMI Subscription is similar to the Subscriptions created by attackers for persistence; however, we’re repurposing this method to perform a different type of action. Instead of executing malware when a condition is met, such as when the system uptime reaches 200 seconds, we’re instructing WMI to log any newly created Consumers or WMI-induced process executions to the Application event log. We utilized PowerShell to configure WMI with these new instructions. At a high level, the PowerShell script performs the following:

1.     Uses WMI Query Language (WQL) to identify:
    a.    Recently created “__EventConsumer” events (persistence mechanisms)
    b.    WMI-based process executions

2.     Creates an Event Filter (condition), to perform an action if any of the above WQL conditions are true

3.     Creates an Event Consumer (action), to log details of the newly created “__EventConsumer” or executed process
    a.    To log details, we call the “NTEventLogEventConsumer” WMI class that logs a custom message to the Application event log that contain the following details, depending on if this was a new Event Consumer or Process Creation:

                                                  i.     Event Consumer Name
                                                  ii.     Event Consumer Command
                                                  iii.     Process Call Method
                                                  iv.     Process Call Command

4.     Creates and registers the Binding, which associates the Condition to the Action

The Result

Figure 2 shows the general details of the newly created WMI Consumer that we aptly named “_EvilConsumer_” in the Application event log.

Figure 2. General view of WMI Persistence event log

Figure 3 shows the detailed view of the event log, which contains the Consumer Name and Command Executed for the creation of the new WMI Consumer “_EvilConsumer_”.

Figure 3. Detailed view of the WMI Persistence event log

The following example illustrates another common use-case, demonstrating how attackers utilize WMI for process execution against remote systems. Figure 4 shows a command-line example of Windows Management Instrumentation Command-line (WMIC) usage to execute a remote PowerShell process. The command used the “Invoke-Expression” (IEX) cmdlet to download and execute the “execPayload.ps1” script over HTTP on the remote system “WIN-RD35VEB5LRT”.

Figure 4. WMIC command used to execute PowerShell on WIN-RD35VEB5LRT

Because the PowerShell process was ultimately executed via WMI, our WMI monitoring subscriber logged the process name and the process arguments. Figure 5 shows the general details of the WMI process execution in the Application event log on the victim system “WIN- RD35VEB5LRT”.

Figure 5. General view of the WMI process creation event log

Figure 6 shows the detailed view of the event log, which contains the command executed “powershell.exe” from the WMI-invoked process creation.

Figure 6. Detailed view of the WMI process creation event log

Monitoring in the Enterprise

Now that we can log newly created Event Consumers and processes spawned via WMI, we can take steps to make this more enterprise-friendly. Our client’s SOC used a third-party utility to inject log data into their SIEM. Our client could now feed the newly defined Application event logs into their SIEM and alert on these events to perform follow-up analysis. Environments of all sizes can follow these similar steps to enact this WMI persistence monitoring and alert on new events:

1. Deploy the WMI monitoring PowerShell script to endpoints via GPO, SCCM or other third party utility. This creates a permanent WMI subscription that will monitor for newly created Event Consumers on endpoint systems.
2. Push or pull the Application event logs that match the WMI persistence or process creation events using Snare or a similar utility into a SIEM.
3. Alert on the WMI persistence or process creation logs through the SIEM. Note: some environments may heavily utilize WMI invoked process creations for system administration. In these cases, we recommend coordinating with your IT team to establish baselines for WMI activity, and only ingest anomalous events, such as process creations from “%SYSTEMDRIVE%\Windows\Temp”.
4. Perform follow-up analysis on the system(s) with newly created WMI event consumers or process creations.

This process provided an enterprise-friendly way to monitor and detect for certain WMI events in near-real time for our client, without having to perform endpoint forensic collection and analysis.

Download the Script

You can download the PowerShell script from the GitHub page here. Note: You must run PowerShell as administrator before using the script. The script requires PowerShell version 3 or above (most recent is version 5) and will run in its current state as two separate PowerShell functions. Figure 7 shows a screenshot of how to import the modules from the script and how to run each module.

Figure 7. Screenshot showing the import of the WMIMonitor script modules and running each module

An Acknowledgment

We would like to thank Matt Graeber (@mattifestation) for his help with developing Windows Management Instrumentation (WMI) as an Intrusion Detection System. We combined and modified two PowerShell scripts – originally developed by Matt – to alert on WMI Event Consumers and process creations and output details of these events directly to the Application event log. Matt Graeber’s WMI work that we used to identify and log malicious WMI actions can be found here and here.

[1] Windows 7 and above operating systems contain the WMI Activity Operational event log, however, this does not provide details of newly created Consumers, Filters or Bindings used for WMI persistence.

Why Embedded Hacking?

Devices that are connected to the Internet or run a full operating system are becoming more and more prevalent in today’s society. From devices for locomotives to wireless light switches, the Internet of Things (IoT) trend is on the rise and here to stay. This has the potential to make our lives much easier; however, the increasing sentience of once analog devices also enables adversaries to target them and potentially misuse them.

With the ubiquity of these Internet-connected devices, there is a surplus of “Things” to exploit. The main intent of this blog post is to generalize how an individual would reverse engineer an embedded device and the process for attempting to find vulnerabilities.

For this demonstration, we will be looking at the WeMo Link, which is a part of the Belkin WeMo LED Lighting Starter Set (http://www.belkin.com/us/p/P-F5Z0489/). There have been vulnerabilities identified in previous iterations of this device; however, these vulnerabilities were more focused on the web services component and not based on analyzing the built-in security of the physical components.

Steps to Analyzing Hardware

There are several steps that an analyst should take when examining their device. These steps, at a high-level, are:

1. Research the device
2. Identify the components
3. Identify debugging ports
4. Dump the flash
5. Extract/analyze firmware

These steps are crucial to understanding the device being analyzed and are required to help identify vulnerabilities. In the following scenario, I will walk through the aforementioned steps and explain each, the path I took, and what other potential sub-paths one could take, given their specific scenario.

Research the Device

The scope of this project involved examining IoT embedded hardware devices that primarily ran embedded Linux as its operating system. I looked at several IoT devices and decided on the WeMo Link due to its ability to be controlled by a mobile application and to be used for home automation, its utilization of wireless components, and its ability to be controlled over the Internet.

The WeMo product allows a mobile application to dim or turn the bulbs on and off remotely, or add a bit of intelligence to the bulbs by having them sync with the sunrise or sunset automatically. There are two main components that drive the device: the WeMo Link and the WeMo bulb. The WeMo Link is comprised of a WiFi 2.4GHz radio component as well as a ZigBee component that communicates on the same band. In terms of the software, the user downloads a mobile application for their Android or iOS device to initially setup the WeMo Link, which then allows them to control the WeMo bulb.

When initially setup, the WeMo Link broadcasts its SSID of “WeMo.Bridge.XXX”. The user then connects to this AP (Access Point) with their mobile device, shares the user’s wireless AP credentials, and the WeMo takes care of the rest. The WeMo then takes any command sent from the mobile application, sends it to the user’s router, to the WeMo Link, and then transmits the command over ZigBee to execute the command to the appropriate bulb(s). Pretty simple.

Identify the Components

In this example, the brains of the operation appear to be the WeMo Link component. In order to be certain, we need to take the device apart. The lid easily pops off by applying force with a flathead under the lip of the plastic. There are several ways of identifying how to properly disassemble a device – from identifying pull tabs to uncovering screws that are covered with warranty warning tape. In this case, the device had a slightly protruding lid held down by four tabs. Behind the plastic lid were two main components: the mainboard, and the AC/DC converter consisting of a transformer, rectifier, etc.

As we examine the mainboard, we will need to identify the datasheets associated with each component in order to get a better idea as to how the device works. On the mainboard itself, what is immediately visible (we will remove the shielding in a bit) is a Winbound W9825G6KH-61 (https://www.winbond.com/resource-files/da00-w9825g6khc1.pdf) 32MB SDRAM and a Winbound 25Q128FVSG (https://www.winbond.com/resource-files/w25q128fv_revhh1_100913_website1.pdf) 16MB serial NOR flash memory with the ability to communicate over SPI (Serial Peripheral Interface) (this will be important later), as seen in Figure 1. The latter chip is used for storing the more permanent memory on the board, even while the device is powered off.

Figure 1: Winbound 25Q128FVSG flash memory

After removing the two metal pieces of shielding on the opposite-side of the board (easily pried-off with a flathead screw driver), we uncover three more main components.

As seen in Figure 2, the first chip is a SoC (System-on-a-Chip) Ralink RT5350F (https://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf), which is a MIPS embedded processor commonly used for networking devices and supports SPI communication, 360 MHz MIPS24KEc CPU core, 802.11n wireless communication, and more. This component is used to drive the device’s main functions, communicate over its debugging interface, interact with its ZigBee component, and communicate with our router over its built-in Wi-Fi component.

Figure 2: Ralink RT5350F chip

As shown in Figure 3, the other shielded section contains the SoC for the ZigBee device labeled as Silicon Labs EM357 (https://www.silabs.com/Support%20Documents/TechnicalDocs/EM35x.pdf), which handles all of the ZigBee 2.4GHz communication and processing power (32-bit ARM Cortex M3 processor) used to relay information to and from the WeMo light bulbs. The other chip residing in the same section is a SkyWorks SKY65336 (http://www.skyworksinc.com/uploads/documents/200939H.pdf) transmit/receive front-end module used for the ZigBee transmission, which appears to be utilized by the aforementioned Silicon Labs EM357 ZigBee SoC to perform the actual transmission of the data to the light bulbs.

Figure 3: Silicon Labs EM357 chip

Identify Debugging Ports

When debugging/interacting with a device, the two most common ways consist of JTAG (Joint Test Action Group) and UART (Universal Asynchronous Receiver/Transmitter). JTAG is a dedicated debugging port implemented as a serial interface used for communicating with the target device. UART is a means of serial communication that can easily be bridged over USB via any UART-to-USB bridge. When looking for UART communication, a lot of times you will see three to four pins that are grouped together with tracings routed to other parts of the board. To help us identify these pins, we can use a multimeter. By touching each of the suspect pins with the positive end on the pad and negative end to a ground (such as the shielding), we can monitor the voltage and identify what the pins are. However, in this case, the WeMo’s circuit board silk screening was friendly enough to label exactly what pads were utilized for interfacing with the device. They were labeled conveniently as UART_RX, UART_TX, GND, and VCC, as seen in Figure 4.

Figure 4: Accessible UART pads found on board

To be sure that the labels are accurate, we can still utilize the multimeter to test each pad’s connection. By powering up the device and monitoring each pin, the UART_RX oscillated throughout a series of voltages. This indicates that data is being streamed across this pad, which is what we will later utilize to view the device’s console. UART_TX is utilized for transmitting commands to the device and can be a bit tricky to identify. This pad also displayed as 3.3V, but given its placement, I did not anticipate this to be VCC. VCC sometimes will also have a thicker trace than the other pads, indicating it is used for supply power. The GND pad provided 0 volts on the multimeter, implying it was the ground pin, and the VCC supplied a steady 3.3 volts, implying it was the power pad. We will utilize these connections later on after we analyze the extracted firmware from the flash dump.

Dump the Flash

As mentioned earlier in the WeMo teardown section of this post, we identified the flash memory that is used to store the bootloader and firmware for this device. This is the core component of the device that an attacker would attempt to modify. We have two ways to dump the memory off of this component, and I will highlight one method. These methods consist of: connecting a test clip to the chip itself while it is still soldered to the board and utilizing a tool such as the bus pirate to dump the flash memory, or desoldering the chip and then placing the chip in a programmer to read the memory off of the chip.

For the sake of being as hardware-oriented as possible, I went with the method of dumping of the SPI flash memory via the bus pirate without desoldering the chip. I wanted to take a non-invasive approach such that my analysis might not be discovered (no physical modifications) by the naked eye. For this method, I purchased a bus pirate from Dangerous Prototypes and an SOIC8/SOP8 test clip (these stand for different types of chip packages, meaning small outlined integrated circuit and small outlined package). This particular flash chip fit perfectly with my 8-pin test clip and was used to make a connection while not removing the chip from the board. I then correctly wired the chip with respect to the bus pirate ports, while following the datasheet and pinout of the chip, as seen in Figure 5.

Figure 5: Chip pin layout

To dump the flash memory from the chip, it must be powered by something. In this case, we utilize the bus pirate’s 3.3v line to provide power to the chip, as seen in Figure 6 and Figure 7.

Figure 6: Attaching the test clip to the chip

Figure 7: Full setup for dumping the memory with the Bus Pirate

The problem with this is that, at times, voltage injection may occur and wake up other chips on the board. This means that other chips will communicate with our flash chip, interrupting our flash dumping process. This is why it is generally recommended to desolder the chip with a rework station and read the contents of the chip with a programmer. Thankfully, we were lucky and this was not the case. To dump the entire 16777232 bytes (exactly 16MB) worth of content from the flash chip, I utilized a tool called flashrom, which works well with the bus pirate device to extract the flash memory in full, as seen in Figure 8.

Figure 8: Dumping the content from the flash chip

Extract/Analyze the Firmware

Now that we have a flash dump from the device, we can use the tool binwalk to analyze the headers within the flash dump to get a better understanding of what the dump consists of, as seen in Figure 9.

Figure 9: Binwalk analysis of the flash dump

At first glance, we see that the device utilizes U-Boot as its bootloader (common for embedded Linux devices), and that there are several file system types such as SquashFS, JFFS2, and the like. Luckily, binwalk has a very neat feature that can automatically extract as much as it can identify from signatures in the flash dump and provide us with the full filesystem of the device. By running binwalk with the filesystem extraction flag (binwalk -e), we are presented with several filesystems, one of which is displayed in Figure 10.

Figure 10: The extracted filesystem

Within this directory, we can now take off our hardware reverse engineering hat and put on our software reverse engineering hat and begin looking for interesting items such as encryption keys used to sign WeMo device firmware, hashed root passwords, interesting services that may start on boot, etc.

Further Testing

What I found interesting after dumping the flash memory was that all of the memory was directly readable from the chip, and that the bootloader was bundled onto the same flash chip. This implies that, since there are no read controls on the flash chip as well as the bootloader existing on the same (potentially unprotected) chip, I might be able to write my own data to the device. I performed a few tests where I manipulated the flash dump binary itself, such as changing the serial of the device (which in turn changed the wireless broadcasting AP SSID). This initial test was to see if I could successfully modify part of the flash memory to display these changes in a real-world environment, this case being renaming the broadcast AP SSID, “WeMo.Bridge.HAK” as opposed to the original “WeMo.Bridge.CBD”, as seen in Figure 11.

Figure 11: Modified AP broadcast by the WeMo device

I was encouraged in my efforts because I could write a new binary file to the device, completely overwriting the original content. To examine this further, I needed to make modifications to the flash dump and judge the results by viewing the startup console for the device. This involved connecting to the device’s UART debugging pads, as described earlier, and viewing the output of the console. To interact with the UART_TX pad, I used an alligator clip wrapped with electrical tape to hold down a wire that touched the pad and connected to my UART to USB device, attached to the UART_RX pin. It is important to note that since the device was plugged into an outlet and was already receiving power, that I only needed to connect to the transmission pad(s) as well as ground – but not power. This would have fried the device. As illustrated in Figure 12, I decided to connect the ground wire to the shielding, which already acts as a ground. This was much easier than attempting to connect the ground wire to the corresponding ground pad.

Figure 12: Wiring the board to communicate via UART

On the software side, I used the program baudrate.py to easily determine the baud rate (transmission rate) of the device via UART. After powering on the device and cycling through several garbled lines of text, I was met with a baud rate of 57600, which presented readable text, displaying the entire boot process of this device, as shown in Figure 13.

Figure 13: WeMo device booting process displayed via UART

I now had the ability to compare the strings found in the flash dump to what was displayed during the boot process of the device. To confirm my theory of potentially modifying the bootloader, I matched strings found in the binary to what was displayed in the console and attempted to modify those strings and rewrite this section of the bootloader, U-Boot. While using a hex editor to modify the binary file and flashrom to erase/write my file to the flash chip, I successfully modified the strings found in the bootloader process. I changed the bootloader header from “U-Boot 20140225_MFG (Feb 13 2015 - 16:58:37)” to “Mandiant Bootloader (May 18, 2016 – 15:38:25)”, as seen in Figure 14.

Figure 14: Modified bootloader to display “Mandiant Bootloader” instead of “U-Boot 20140225_MFG”

I was also able to modify various field names regarding the image verification process, most likely around the time where the bootloader checks the validity of the firmware, as seen in Figure 15.

Figure 15: A modified field name to display “MandiantHak”

The checks present in the image verification process are irrelevant if portions of the bootloader can be modified. In theory, if the above assertions are correct, an adversary could non-invasively rewrite a new, malicious bootloader and firmware to the device, with the ability to perform malicious acts on the user’s network as a trusted device. Such a scenario could consist of a reseller of this product placing a custom bootloader and firmware onto this device, and then selling the product to an unsuspecting customer, having a control point in the user’s network. This could theoretically enable an attacker to intercept traffic on the network, acquire data on the network, modify data, and more.

Remediation

The following recommendations do not take into consideration all of the variables that are involved when making significant changes to a device in order to implement security improvements. These recommendations are things to consider when attempting to remediate the aforementioned scenario.

There are a few hardware-based actions that could be taken that would make it significantly more difficult for an adversary to read/write to the flash chip, among other areas. One such action is to implement hardware authentication chips. This involves storing a cryptographic mechanism on the board along with the required key for decryption, hindering an adversary’s ability to clone or tamper the data on the device. This is a cost-effective method for IoT device manufacturers.

A second action is to protect the bootloader by storing it in protected storage or a SoC, or to require the SoC to communicate with an authentication chip during the boot process. The problem with implementing the bootloader on a flash chip that is unprotected and can be manipulated by disabling the CRC checks in place when decompressing the firmware image on boot and overwriting the image with a malicious one. If the bootloader must be stored on the flash chip, it could be included in OTP (One-Time Programmable) memory, disallowing this area to be written by a third party.

Conclusion

It is important to keep in mind the amount of attention paid to security is generally proportional to the value of the device. Implementing strict security features for a relatively inexpensive home automation system may not make sense for all but the most security-conscious consumer. That said, it is important to understand how easily an adversary can implement a malicious bootloader/firmware with a backdoor, allowing for command-and-control on devices we may rely on in our homes. A device as simple as a wireless light bulb can still be used as an entry point to our home systems.

By taking the previously outlined steps to analyze an embedded device, we successfully identified relevant chips, a UART debugging port, and how to read and write raw data to the accessible flash chip, affecting the boot process of the device. Following the previously defined steps will help you further investigate most embedded devices in order to identify vulnerabilities.

Upon notifying Belkin of our intention to release this research, they provided the following statement:

“Wemo appreciates the work of FireEye and other white hat researchers who often play a critical role in identifying potential security issues and keeping connected devices safe for consumers. As malicious hackers grow more sophisticated, it is critical that we, and other smart home manufacturers, work with these groups to mitigate any serious threats to safety and security.

“Though Wemo is aware of the potential vulnerability published by FireEye in their recent blogpost, we do not believe it is serious enough to warrant what would be a major change to our hardware production. In order to facilitate this attack scenario, a hacker would have to have physical access to a Wemo Link device, tamper with its circuitry and then either return the hacked device or resell it, both of which are extremely unlikely. With this particular vulnerability, there is no remote or even local network threat to users, so we believe that the best way to prevent this is to always purchase new, unopened merchandise from an official Wemo dealer.”

Risks Posed by Sensitive Corporate Communications, Broadened Attack Surface

In 2015, a record $5 trillion dollars was tied up in mergers and acquisitions (M&A) deals, according to JP Morgan. So far, mega deals in 2016 include Microsoft’s purchase of LinkedIn, Shire’s acquisition of Baxalta, and Marriott’s acquisition of Starwood. These market-moving events often involve a massive expenditure of capital and are largely conducted in secret to comply with legal requirements, making them attractive targets for cybercriminals and nation-state threat groups alike. Threat actors are primarily driven by three motives related to M&A activity:

1. Stealing non-public information leading up to the deal’s announcement for future financial gain.
2. Exploiting sensitive financial information generated during the M&A process.
3. Exploiting the increased attack surface created by companies combining their operations.

Additionally, acquisition targets may be compromised prior to the M&A for reasons wholly unrelated to the transaction. Enterprises should be especially alert for malicious cyber activity before, during, and shortly after M&A-related activities, ensuring that due-diligence processes incorporate assessments of each party’s cyber security practices.

Trove of Documents to Exploit Capital Markets

M&A activity generates significant amounts of sensitive corporate communications, which cyber criminals may attempt to obtain and exploit for financial gain. For example, cyber criminals could attempt to gather data about a company's operations, financial status or future plans, which could then be used in stock market trades. To obtain such sensitive information, attackers can target the companies directly involved in the M&A activity themselves or other organizations involved in the deal, such as law firms and PR agencies.

The U.S. Securities and Exchange Commission (SEC) in 2015 announced that since at least 2010, two Ukrainian cyber criminals breached multiple newswire services and distributed pre-release information to a rogue network of international traders and hedge fund managers.

In 2013 and 2014, a group of cyber criminals known as FIN4 sought to acquire information about M&A discussions in order to game the stock market. The group frequently used M&A and SEC-themed lures with Visual Basic for Applications (VBA) macros implemented to steal the usernames and passwords of key individuals. Many of FIN4’s lures were apparently stolen documents from actual deal discussions that the group then weaponized and sent to individuals directly involved in the deal. FIN4 typically included links to fake Outlook Web App (OWA) login pages designed to capture the user’s credentials. Once equipped with the credentials, FIN4 then obtained access to real-time email communications and presumably insight into potential deals and their timing.

Seeking Insights to Gain the Upper Hand in Negotiations

One side involved in M&A negotiations could use cyber espionage to acquire sensitive information about a deal counterparty in an attempt to obtain more favorable terms. Based on past threat actor activity, we have observed multiple China-based threat actors breach companies to observed this type of activity in sizeable deals involving Chinese state-owned enterprises.  

High tech companies in particular face an evolving cyber risk as Chinese interests advance toward acquisition of technology and expertise that will sustain the country’s economic growth through a shift to an economy built on knowledge-based products and services. During the past decade, flush with cash and often with state backing, Chinese companies have snatched up well-known Western companies in industries ranging from agriculture to energy to consumer products. The Wall Street Journal reported that as of May 2016, Chinese companies have struck over $110.8 billion in overseas deals, surpassing the $106.8 billion in deals done in 2015, despite a slowdown in the Chinese economy.

As recently as late 2015, we have observed several likely China-based threat groups targeting companies engaged in M&A-related activity. At least four different China-based APT groups conducted computer network intrusions that we believe were primarily motivated by the targeted companies’ involvement in an acquisition.

In 2015, Mandiant conducted a compromise assessment for a business services company. We identified two periods of activity by the China-based threat group APT8 within the network, the most recent of which coincided with the victim company's participation in acquisition negotiations. Although our visibility into APT8's operations was limited, the threat group possibly sought information pertaining to the negotiation and acquisition itself, based on the timing in which APT8 resumed their activity within the network.

New Companies, New Attack Surfaces

Mergers and acquisitions often result in an increased attack surface for the companies involved. As two or more companies integrate their IT assets, a group that has compromised one company could potentially use that access to compromise the other(s). For instance, the Australian telecom firm Telstra in 2015 announced that the networks of a recently acquired subsidiary, Pacnet, were exploited.

Although the most obvious example of the increased attack surface issue is when M&A activity causes companies to combine their networks, it can also include factors such as one company’s particular susceptibility to social-networking attacks or vulnerabilities in products produced by one of the companies. In other words, strong security practices at one company can be obviated by poor practices at the other.

This threat is likely elevated during and immediately after a merger or acquisition, since IT employees at the purchasing company may not have had time to analyze the security posture of the purchased company, or the combined staffs are unable to comprehensively monitor the entirety of the newly combined network. Mergers and acquisitions also generally increase the opportunities for “lateral compromise” by targeting trusted relationships (i.e., the relationship between the companies involved in the M&A activity). When a well protected network recognizes a less secure network as trusted, the overall security posture of the combined network is lowered, allowing intruders to gain access by exploiting hastily-granted trust between systems.

Mandiant has observed instances where APT actors were able to regain a foothold in an organization’s network following remediation by compromising the network of an affiliate. Actors targeting companies during M&A activity could use similar tactics to move laterally from one company to another.

An example of this is when Mandiant performed an incident response investigation for Company A, where we identified the presence of several advanced threat actors. After remediating Company A’s networks, an APT group attempted to re-compromise the network through a sister organization (Company B), which had also been previously compromised. Although this effort failed, a different APT group was able to regain access to Company A’s systems through a strategic web compromise embedded on Company B’s website. Our investigation of the sister company’s network revealed that the vast majority of stolen data there pertained to the network infrastructure linking the organizations.

Another example occurred at Company C, where we identified four APT groups active in a network. Analysis about the timing and behavior of at least one of these groups suggested that they were able to leverage their previously attained access at Company D (a sister organization) to access Company C’s network. During our investigation at Company D, we discovered at least two threat groups, with activity dating back three years earlier. We believe these actors used information harvested from Company D’s network to help exploit Company C in a subsequent operation.

Mitigation

Business leaders responsible for M&A business strategy should be aware that threat actors often target companies engaged in mergers and acquisitions, and that malicious activities such as phishing attacks will likely increase during such periods. Additionally, a data breach or severe security posture weaknesses could negate the business strategy of acquisition due to the often-high cost of fixing weaknesses or conducting incident response. Technology risk should be evaluated and incorporated into the overall business risk strategy before an M&A transaction is completed. In addition, companies engaged in M&A should ensure that an examination of cyber security is included as a key component of the due diligence process.

Today cyber due diligence is oftentimes performed superficially and as an afterthought. This examination should include details of the company’s security capabilities such as data safeguards, access controls, threat detection, incident response and infrastructure security controls, the threat landscape of the organization, any records of past attacks, and any underground actors known to be particularly interested in targeting the company. Allowing sufficient time (four to six weeks) to perform an actual compromise assessment on the sellers’ infrastructure will provide the optimal visibility into the security posture of the acquisition.

When sufficient time is provided and cyber due diligence is conducted, senior executives at the acquiring organization will understand the business threats and technology risk posed by the acquisition target, enabling them to incorporate this information into the overall enterprise risk picture for informed decision-making. In the majority of transactions, the decision to move forward with the acquisition will still continue; however, senior executives will be better equipped to make informed decisions about:

• Deal value
• Terms
• Cost of remediation of security weaknesses or breach response
• Return on investment of the acquisition
• Purchase of a cyber insurance to transfer risk
• Probability and cost of future litigation resulting from a breach

When to Start Cyber Security Due Diligence

It’s important for all parties to a transaction to work with their respective counsel to ensure any cyber due diligence activities are performed in a compliant manner (e.g., to avoid creating privacy issues) and in a way that helps preserve any available legal privileges.

Cyber security should be planned for like any other due diligence – as early as possible. Because of some fairly specific requirements to ensure the quality of cyber security due diligence, some language may need to be inserted into agreement documents such as a Letter of Intent (LOI). This will enable key components of a cyber security due diligence, such as network monitoring.

M&A due diligence teams sometimes contain information technology (IT) subject matter experts (SMEs) who are occasionally asked to also provide an opinion on cyber security posture; however, cyber security is a specialized field, and if security expertise is not available on staff, due diligence providers should start planning to retain outside resources.

What Cyber Security Due Diligence Should Be

The following are factors that should be incorporated into effective cyber security due diligence planning. Note that M&As can vary widely in terms of ramp-up time. Some allow for a very short due diligence effort, while longer deals can afford months to assess risk. Business decisions control this pace, not the due diligence team – therefore it is important to have relatively quick and lightweight cyber due diligence options as well as longer, more in-depth approaches.

Quick Diligence

If the window for due diligence is short (e.g., 1-2 weeks), there is still substantial cyber security due diligence that can be accomplished to provide a high-level view of the risk levels of the seller’s environment. A week provides time for cyber security experts to conduct documentation review and interviews with seller staff, which they then analyze in a focused risk framework. The product of this activity should be a quantified risk assessment across important cyber security domains (e.g., data safeguarding, infrastructure security, and others) that results in a brief, easy-to-understand report on risk and general recommendations for the buyer.

Even minimal cyber security due diligence should have a technical component to provide an objective view of the health of the seller’s security posture. One of the most important aspects of a technical assessment is creating a historical scorecard going back in time: Have the seller’s computers been compromised in the past, and what was the character of those breaches (advanced and persistent, commodity, insider, financial fraud, etc.)? The Freshfields survey discovered 90% of respondents believed that a past breach could reduce the value of a deal.

Also important is a current snapshot: detecting malicious activity (or the lack of such activity) from the seller provides insight into the overall security posture and types of possible intruders already in place. This information needs to be derived and analyzed in a relatively short time frame.  With this kind of analysis, the buyer already can act knowledgably and prevent major missteps.

In-Depth Due Diligence

If more time is available, more detailed and granular cyber security due diligence is possible. In addition to a risk assessment conducted by cyber security analysts, software agents can be deployed in the seller’s network to report on the state of the endpoints.

Network monitoring can examine traffic to and from the network for a period of time to collect very detailed information on the state of the organization’s cyber security and what compromises are already happening, or have already happened. This allows the buyer to know the seller’s environment inside and out from a real-world risk perspective, and would provide both the high-level view needed to inform decisions and granular detail to estimate remediation costs.

Only with due diligence can risk be incorporated in planning, with various planned costs and benefits. Without due diligence, there are only unexpected costs and reputational impacts.

Post-Acquisition Activities

Information gathered during due diligence can be further used to guide post-acquisition activities.

Integration

A fairly common follow-on activity, particularly with mergers, is integration of the two companies’ IT infrastructure. In the long run, this should reduce costs and ease management; however, in the short-term it can create its own set of problems and become a long-term effort.

One of the first questions to answer is: what can be trusted? Is it safe for the buyer to connect to certain acquired systems? Can two-way trust relationships be established? All of these depend on assessing the security of both the overall environment and specific systems. Cyber security due diligence provides a good start down this road, and can allow for a level of effort and cost estimates to be made and included in IT planning.

The Future Has Already Been Here

The impact of adverse cyber security events has been felt by businesses for some time, and paying a little attention to the news gives some sense of the scale of the challenges that have emerged as even local businesses become exploitable by global criminals. Cyber security risk is not science fiction, even though it has essentially been treated as science fiction by being left out of M&A processes. Acquiring companies and due diligence practitioners must now catch up to the reality of the costs and risks that cyber security issues create, and the benefits that cyber security due diligence can bring. Doing so will eventually separate successes from the also-rans.

For more information on how Mandiant Consulting can help before, during and after a merger or acquisition, visit Fireeye.com/services.html.

Let fall be the season for reverse engineering! On Sept. 23, 2016, the FireEye Labs Advanced Reverse Engineering (FLARE) team will be hosting its third annual Flare-On reverse engineering contest with a designated start time of 8pm ET. This is a CTF-style challenge for all active and aspiring reverse engineers, malware analysts and security professionals. The contest will run for six full weeks, ending Nov. 4, 2016, at 8pm ET.

A total of 10 exquisitely crafted challenges stand between you and a famed prize that serves as a badge of honor. The progressively challenging binaries will cover a variety of software platforms and puzzle techniques. The challenge runs the gamut of skills we believe are necessary to succeed on the FLARE team. The contest is designed for individuals, not teams, and there are no parallel tracks of challenges.

Contestants who finish all 10 challenges prior to Nov. 4 will receive the prize and recognition on the website. Last year’s prize was a big custom rodeo-style belt buckle and the previous year’s prize was a challenge coin. This year’s prize is a surprise and will be announced after the close of the contest.

A live countdown timer on our website is ticking away the moments until the third annual contest begins, and visitors to the site can also marvel at the splendor and glory of last year’s winners. Additionally, you can share your enthusiasm on Twitter with #flareon3.