Category: #IT/CYBER/TECHNOLOGY

In recent months, we’ve been tracking a malicious spam (malspam) campaign using emails with no message content and an attached zip archive to spread ransomware. We’ve nicknamed this campaign “Blank Slate” because the malspam messages are blank with nothing to explain the malicious attachments.

Last month, we published a blog  that discussed farming Microsoft Word documents in AutoFocus associated with the Blank Slate campaign. It revealed more than 500 domains were used. These malicious domains were quickly taken offline, but Blank Slate actors quickly registered new ones, revealing a cycle of abuse towards legitimate hosting providers.

Today’s blog describes the delivery, exploitation, and installation components of this attacker’s playbook, and it explores the cycle of abuse criminals follow against legitimate hosting providers to host ransomware associated with these infections.

The infection chain

The infrastructure behind the Blank Slate campaign has two distinct phases. The first phase is receiving malspam from a botnet. The second phase is when an attachment from the malspam retrieves ransomware from a web server. The ransomware is designed to infect Microsoft Windows computers, and a successful infection chain consists of the following steps:

• Attacker’s botnet sends malspam to the intended recipient.
• User ignores security warnings and opens the zip archive included in the malspam.
• User ignores security warnings and manually extracts either a Microsoft Word document or a JavaScript (.js) file.
• User ignores warnings and manually enables macros for the Word document or user double-clicks the .js file.
• Word macro or .js file retrieves a ransomware executable from a web server.
• Word macro or .js file executes the ransomware on the user’s computer in the user’s security context.

Figure 1: The user receives an email from a host in the botnet.

These Blank Slate emails come from a botnet consisting of numerous compromised hosts across the globe. Sending email addresses are always spoofed, and they have no relation to the actual botnet host sending the message.  The emails only consist of a zip archive sent as a file attachment.  As shown in Figure 2, these email messages have no text whatsoever, only an attachment that intended victims are meant to open.

Figure 2: One of the malspam email messages.

The malspam’s zip attachment is actually a double-zipped file, meaning it contains another zip archive which itself holds the malicious active content. We believe the attackers chose to use a double-zip tactic as a countermeasure against antispam/antimalware technologies. With an additional layer of user interaction, some intended victims may become frustrated or distracted, and this might lead to an increased failure/abandon rate. However, we believe the attackers decided this was less of a risk than detection by antispam/antimalware technologies.

That second zip archive contains either a Microsoft Word document with a malicious macro as shown in Figure 3, or it contains a .js file as shown in Figure 4.

Figure 3: Example of a malspam attachment with a double-zipped Word document.

Figure 4 Example of a malspam attachment with a double-zipped .js file.

The Word document macro has malicious Visual Basic for Applications (VBA) script that will execute after the user has opened the document and enabled macros. The .js file has malicious JavaScript that will execute within Windows Script Host when it is double-clicked.  In both cases, once the malicious script executes, it launches a PowerShell process to download and run ransomware on the Windows host as shown in Figure 5.

Figure 5: Communications between malicious script and server hosting ransomware.

Figure 6 shows an example of the traffic between a malicious .js file and a server hosting the Cerber ransomware.

Figure 6: Traffic from February 2nd 2017 of a .js file retrieving Cerber.

We primarily see Cerber ransomware distributed by the Blank Slate campaign, but other forms of ransomware like Sage 2.0 and Locky have also been noted.

The Blank Slate campaign has followed consistent patterns, and we’ve confirmed matching activity in AutoFocus as early as July 5th 2016 as shown in Figure 7.

 

Figure 7: Using AutoFocus to find Word documents from the Blank Slate campaign.

These results indicate at least seven months of obvious malspam, which raises the question: if the malspam is obvious, why is the Blank Slate campaign so long-lived?

Abusing hosting providers

A key factor to Blank Slate’s longevity the abuse of hosting providers. Our previous post on this campaign listed 555 domains associated with this campaign over the span of seven months. These domains were active for a few days before they were taken off line. Then the criminals behind Blank Slate moved to newly-registered domains, sometimes using the same hosting provider. This cycle has repeated itself over and over since July 2016.

To examine more closely, we reviewed a five-day period from January 29th to February 2nd 2017. During that timeframe, we found at least eight domains across seven IP addresses hosting Cerber ransomware. The following list shows each domain followed by its IP address.

• adibas[.]top – 46.173.219.161
• footarepu[.]top – 35.165.86.173
• guntergoner[.]top – 35.163.101.72
• guntergoner[.]top – 185.159.130.89
• ibm-technoligi[.]top – 35.165.251.24
• ibm-technoligi[.]top – 62.109.29.26
• polkiuj[.]top – 35.165.251.241
• polkiuj[.]top – 46.173.219.161
• suzemodels[.]top – 35.163.101.72
• astrovoerta[.]top – 185.159.130.89
• zofelaseo[.]top – 35.163.101.72

These domain names were registered a day or two before they were active. They remained active for up to seven days or more, depending on how quickly the hosting providers were notified.

So how do Blank Slate and other campaigns continue abusing hosting providers?

The requirements for establishing an account at a hosting provider are easy to acquire. The criminals only require a valid email, phone number, and credit card.

Most of these requirements are easy to obtain. Various free email services easily provide anyone a valid email address. Criminals can also purchase pre-paid phones without a contract (known as “burner phones”) that are hard to track. And finally, criminals often use stolen credit card data when establishing these accounts.

Figure 8: Requirements for an account at a hosting provider.

Criminal accounts on hosting providers are relatively short-lived, since the domains are quickly discovered and reported to the provider’s abuse department. However, these domains can stay online for a week or more before an abuse complaint is resolved. When a server is taken off-line, the criminals can easily establish another server through a new account using a different email, phone number, and stolen credit card data.

The cost is relatively inexpensive. A new email account can be established for free. Burner phones are cheap, as low as 20 to 30 dollars in the US. In the Russian underground, prices for a set of stolen credit card credentials are as low as five US dollars.

The situation lends itself to a cycle of abuse as criminals establish new servers, those servers are reported, the hosting provider shuts them down, and the criminals establish new servers.

Figure 9: The cycle of hosting provider abuse.

Conclusion

As implied by the cycle of abuse, domains and IP addresses associated with the Blank Slate campaign are constantly changing. With the current popularity of ransomware, we continue to see malspam daily in both targeted attacks and wide-scale distribution. We expect this trend will continue.

Palo Alto Networks customers are protected against this threat through our next-generation security platform. Our advanced endpoint solution Traps is designed to prevent such Word documents or .js files from compromising a system. WildFire continues to identify Microsoft Office documents using these techniques as malicious. Finally, AutoFocus users can identify associated malware by using the PowerShellCaretObfuscation and CerberSage_Distribution tags.

Brad Duncan

[Palo Alto Networks Research Center]

The New York State Department of Financial Services (DFS) cybersecurity regulations go into effect today. In this blog post, I’ll share what these regulations mean and the biggest changes that financial services companies can expect over the next several months.

As a recap, in late December 2016, the DFS published its revised proposal for cybersecurity regulations. The proposal explicitly calls out the need for and the responsibilities of a Chief Information Security Officer (CISO) function. The occupant of this role must be a qualified individual responsible for overseeing and implementing the cybersecurity program. Similarly, the regulation calls for the use of qualified cybersecurity personnel with current knowledge and ongoing training in that discipline. Although the qualifications of these individuals are not explicitly defined, the implication is that they are and must remain well-versed in cybersecurity.

The DFS also puts explicit demands on the senior officers or board of directors to ensure their active participation in the cybersecurity program. This includes approval of the cybersecurity policy, review of an annual report by the CISO (effective February 15, 2018), and an annual certification of compliance – signed by an individual. This last piece is reminiscent of the Sarbanes-Oxley Act and opens the door for potential individual liability. Clearly, the intent is for that senior officer and the entire board to take their cybersecurity responsibility seriously.

Compliance dates for various portions of the proposed regulation are staggered over the next 24 months. This was a change from the original proposal and is an acknowledgement of the challenges that covered financial institutions will face in complying with specific provisions of the regulation. Here’s a look at a few of these just to provide a flavor for the difficulties to achieve compliance.

At the 12-month stage, covered entities will need to have multi-factor or risk-based authentication in place for access to nonpublic information – even internally. Many financial institutions use multi-factor authentication (MFA) for remote access to their corporate networks, but few have adopted it for access to internal resources as there are additional complexities and costs involved. Moreover, for legacy applications or systems that do not support MFA natively, a compensating control will be needed to protect the nonpublic information there.

At 18 months, encryption of nonpublic information both in transit and at rest will be required.  Where this is infeasible, CISO-approved compensating controls are acceptable, but they must be reviewed annually. Financial institutions typically encrypt the data on laptops as those are prone to loss or theft. However, encryption of data at rest on servers or in databases may not be common practice, except where payment cardholder information is involved. This will have to be expanded to include any nonpublic information. Data, in transit, should ideally be encrypted by the application. Consequently, this may require changes to a large number of commercial and internally developed applications. However, some older applications may be unable to encrypt natively. In such cases, encryption could be delegated to the network as an alternate control.

At the 24-month mark, financial institutions will need measures in place to ensure the security of nonpublic information that is accessible to or held by third-party service providers. The long lead time for this is necessary, given the quantity of suppliers or partners that may have access to or handle nonpublic information. The initial risk assessment, definition of minimum cybersecurity practices, subsequent contract revisions, etc. with third-party services providers will clearly be time-consuming. Some financial institutions already have enterprise risk management programs in place, which include some degree of vendor risk management.  However, even these will need to be broadened to monitor cybersecurity risks at providers that touch nonpublic information.

At the federal level, the themes of active board participation and concern over third-party cybersecurity risks have also been echoed. The Federal Reserve Board, the Office of the Comptroller of the Currency (OCC), and the Federal Deposit Insurance Corporation (FDIC) have issued an advance notice of proposed rulemaking (ANPR) for enhanced cyber risk management.   Public comments were due in late January 2017, but as written, the ANPR calls for more active board-level involvement in cybersecurity programs and the extension of enhanced standards to address cyber risk at third-party providers to the financial sector as well.

Financial institutions licensed by the state of New York should develop their plans to address the provisions of the newly effective cybersecurity regulation but keep an eye on the progress of the proposed federal regulations as well, if applicable. In the end, financial institutions may be better served by developing an overarching cybersecurity program that will encompass their risks and ultimately subsume regulatory requirements. Other states may follow New York’s lead and conceivably introduce their own cybersecurity regulations as well. As global financial institutions already know, variations in regulations across jurisdictions can be complex to manage in a piecemeal fashion.

Lawrence Chin

[Palo Alto Networks Research Center]

Recently, we have discovered 132 Android apps on Google Play infected with tiny hidden IFrames that link to malicious domains in their local HTML pages, with the most popular one having more than 10,000 installs alone. Our investigation indicates that the developers of these infected apps are not to blame, but are more likely victims themselves. We believe it is most likely that the app developers’ development platforms were infected with malware that searches for HTML pages and injects malicious content at the end of the HTML pages it finds. If this is this case, this is another situation where mobile malware originated from infected development platforms without developers’ awareness. We have reported our findings to Google Security Team and all infected apps have been removed from Google Play.

Figure 1: A subset of all infected samples on Google Play

The infected apps that we observed included apps for design ideas ranging from cheesecake, to gardening and coffee tables, as shown in Figure 1. What all the apps have in common is that they employ Android WebView to display static HTML pages. At the first glance, each page does nothing more than loading locally stored pictures and show hard-coded text.  However, a deep analysis of the actual HTML code reveals a tiny hidden IFrame that links to well-known malicious domains. Although the linked domains were down at the time of investigation, the fact that so many apps on Google Play are infected is notable.

What is more notable is that, one of the infected pages also attempts to download and install a malicious Microsoft Windows executable file at the time of page loading, but as the device is not running Windows, it will not execute. This behavior fits well in the Non-Android Threat category recently released by the Google Android Security. According to the classification, Non-Android Threat refers to apps that are unable to cause harm to the user or Android device, but contains components that are potentially harmful to other platforms.

How the Infection Works

All infected apps currently only require the INTERNET permission and are equipped with two activities, one is to load interstitial advertisements and the other one is to load the main app. The latter one instantiates an Android WebView component and displays a local HTML page (Figure 2). The WebView component has JavaScriptInterface enabled. This functionality isn’t used by the samples we’ve examined, but this enables loaded JavaScript code to access the app’s native functionality.

Figure 2: An example of the infected sample’s UI and its underlying code

Each HTML page only displays pictures and text. However, at the end of each HTML page, a tiny hidden IFrame component has been added. We have observed two techniques used to hide this IFrame. One is to make the IFrame tiny by setting its height and width to be 1pixel. The other one is to set the display attribute in the IFrame specification to None. Finally, to evade detection based on simple string matching, the source URLs are obfuscated using HTML number codes.  In the examples shown in Figure 3, browser automatically performs the following conversions:

 

• ‘.’ → ‘.’
• ‘i’ → ‘i’
• ‘u’ → ‘u’

Figure 3: Two techniques observed in infected samples to hide the IFrame region

Eventually, all IFrame sources converge to two domains:

• www[.]Brenz[.]pl/rc/
• jL[.]chura[.]pl/rc/

The Polish CERT (cert.pl) took over both of these domains in 2013 and directed them to their sinkhole server to prevent them from harming users (Figure 4). Given that, both domains are not hosting malware at the time of our investigation, but they have a notorious history[1,2,3,4,5].

Figure 4: Both malicious domains current resolve to a sinkhole server.

During our investigation, we also identified a sample that didn’t contain an infected IFrame, but an entire VBScript was injected into the HTML (Figure 5). The script contained a Base64 encoded Windows executable that (on a Windows system) the script would decode, write to the file system, and execute. Since VBScript is a proprietary Microsoft Windows scripting language, the script is inert and does not execute on the Android platform: this piece of code will not cause damage to Android users. First of all, the code is appended outside the <HTML> tag, which makes it an illegal HTML page. But browsers have always attempted to render pretty much anything, whether it is malformed or not, in order not to make creating HTML pages difficult for people who might not understand the standard completely.

WildFire detects several malicious behaviors within the dropped PE file, including:

• modify the network hosts file
• modify windows firewall settings
• inject code into another process
• copy itself

Figure 5: Infected sample attempts to drop a window executable file

The Origin of the Infection

The 132 infected apps we discovered belong to seven different, unrelated developers. There is a geographical connection among the seven different developers: all seven have connections to Indonesia. The most straightforward clue comes from the app name. A significant number of discovered samples have the word “Indonesia” in their names. Moreover, one developer’s website links to a personal blog page written in Indonesian. The clearest pointer, though, is one developer’s certificate clearly states the state to be Indonesia.

Figure 6: Infected samples’ connection to Indonesia

One common way HTML files have been infected with malicious IFrames has been through file infecting viruses like Ramnit. After infecting a Windows host, these viruses search the hard drive for HTML files and append IFrames to each document. If a developer was infected with one of these viruses, their app’s HTML files could be infected. However, given that the developers may all be Indonesia, it’s also possible they may have downloaded an infected IDE from the same hosting website or they used the same infected online app generation platform.

In either case, we believe the developers are not malicious and are victims in this attack. There are a few other pieces of supporting evidences from our investigation:

• All samples share similarities in their coding structure, suggesting that they may be generated from the same platform;
• Both malicious domains used resolve to sinkholes. If developers were the attacks behind all these, they could have replaced them with working domains to cause real damage;
• One infected sample attempts to download windows executable file. It suggests that, the attacker does not know about the target platform. Clearly, this is not the case for app developers.

Potential Damages and Mitigation

Currently, infected apps will not cause damage to Android users. However, this does represent a novel way for platforms to be a “carrier” for malware: not be infected themselves but spread the malware to other platforms without realizing it. Similar to the XcodeGhost attack we identified in 2015, this threat shows how attacking developers can impact end-users.

It’s easy to envision a more focused and successful attack: an attacker could easily replace the current malicious domains with advertising URLs to generate revenue. This not only steals revenue from app developers, but also can damages the developers’ reputation. Secondly, aggressive attackers could place malicious scripts on the remote server and utilize the JavaScriptInterface to access the infected apps’ native functionality. Through this vector, all resources within the app would be available to the attackers and under their control. They could also operate silently to replace the developer’s designated server with their own, and as a result, whatever information that was sent to developer’s server now falls in hands of the attacker. Advanced attackers can also directly modify the app’s internal logic, i.e., adding rooting utility, declaring additional permissions, or dropping malicious APK file, to escalate their capabilities.

WildFire customers are automatically protected against all infected samples. The APK analysis engine inside WildFire is capable of not only identifying the tiny hidden IFrame, but also correlating with the embedded domains.

Acknowledgements

We would like to thank Zhi Xu and Claud Xiao from Palo Alto Networks for their assistance and comments during the investigation. We greatly appreciate the expedited response from Google Security Team to help verify and take actions on the infected apps.

Appendix

Malicious domains:

• www[.]Brenz[.]pl/rc/
• jL[.]chura[.]pl/rc/

Infected samples’ hashes and package names (additional samples are available upon request through the blog comments):

• c6e27882060463c287d1a184f8bc0e3201d5d58719ef13d9ab4a22a89400cf61, com.aaronbalderapps.awesome3dstreetart
• a49ac5a97a7bac7d437eed9edcf52a72212673a6c8dc7621be22c332a1a41268, com.aaronbalderapps.awesomecheesecakeideas
• 1d5878dce6d39d59d36645e806278396505348bddf602a8e3b1f74b0ce2bfbe8, com.aaronbalderapps.babyroomdesignideas
• db95c87da09bdedb13430f28983b98038f190bfc0cb40f4076d8ee1c2d14dae6, com.aaronbalderapps.backyardwoodprojects
• 28b16258244a23c82eff82ab0950578ebeb3a4947497b61e3b073b0f5f5e40ed, com.aaronbalderapps.bathroominteriordesigns
• b330de625777726fc1d70bbd5667e4ce6eae124bde00b50577d6539bca9d4ae5, com.aaronbalderapps.beautifulbotanicalgardens
• d6289fa1384fab121e730b1dce671f404950e4f930d636ae66ded0d8eb751678, com.aaronbalderapps.bedroomdesign5d

Xiao Zhang, Wenjun Hu and Shawn Jin

[Palo Alto Networks Research Center]