Malware Alerts

Subscribe to Malware Alerts feed Malware Alerts
Online headquarters of Kaspersky Lab security experts.
Updated: 1 hour 29 min ago

Kaspersky DDoS Intelligence Report for Q1 2016

Thu, 04/28/2016 - 06:57

Q1 events

We have selected the events from the first quarter of 2016 that, in our view, illustrate the main trends in the field of DDoS attacks and the tools used to perform them.

A record-breaking reflection DDoS attack

DDoS attacks using amplification/reflection techniques are still popular and allow cybercriminals to break their peak power records. From a technical point of view, amplification methods are nothing new in DDoS attacks, but cybercriminals are discovering new ways and resources to enhance the capacity of their botnets. For example, according to a recently published report, 2015 saw the largest ever DDoS attack on record at 450-500 Gbps.

DDoS attack on Trump

It’s possible that last year’s record didn’t last very long – at the very beginning of the year the official website of Donald Trump’s election campaign were subjected to DDoS attacks whose strength, according to unconfirmed sources, reached 602 Gbps. The hacktivist group New World Hacking claimed responsibility for both incidents.

Use of the DNSSEC protocol

Criminals are increasingly using the DNSSEC protocol to carry out DDoS attacks. The protocol is intended to minimize DNS spoofing attacks, but besides the domain data a standard DNSSEC reply also contains additional authentication information. Thus, unlike a standard DNS reply of 512 bytes, the DNSSEC reply comes to about 4096 bytes. Attackers exploit this feature to perform amplification DDoS attacks. They usually use domains in the government zone .gov, because in the US such domains are required by law to maintain DNSSEC.

Pingback attacks on WordPress

Web resources powered by the WordPress content management system (CMS) are still popular with cybercriminals carrying out DDoS attacks. Popular CMS-based resources often become targets of DDoS attacks exploiting the WordPress pingback function. The pingback function notifies the author of a post published on a WordPress site when someone else links to that post on another site running the same CMS. If the administrator of the site running WordPress has enabled the function, all links leading to the materials published on a site can perform a so-called pingback, i.e. send a special XML-RPC request to the original site. A huge number of pingback requests sent to the original site can cause a “denial of service”. This feature continues to attract the attention of cybercriminals and helps them perform DDoS attacks at the application level.

Linux Mint hacking

On 21 February 2016, the head of Linux Mint, Clement Lefebvre, reported that someone had managed to hack the project infrastructure including its official website and forum, and substituted the link to the legitimate ISO image of the Linux Mint 17.3 Cinnamon edition with their own URL. The hacker’s modified ISO contained malicious code that used infected machines to perform DDoS attacks.

Attacks on security companies

Cybercriminals also target companies working in information security, with most of the major players – especially those offering anti-DDoS services – having to regularly combat DDoS attacks on their resources. These attacks can’t cause much damage because all these resources are well-protected, but that doesn’t stop the cybercriminals.

In Q1 2016, resources in 74 countries were targeted by #DDoS attacks #KLreport

Tweet

In general, cybercriminals don’t go all out to bring down an IT security company’s site. The attacks tend not to last long, and in most cases, they are terminated as soon as the source notices that protection systems are working. The cybercriminals don’t want to waste their botnet resources when they could be earning money elsewhere. Nevertheless, the attacks continue.

Analysis of the correspondence on underground forums suggests that the criminal fraternity uses the websites of IT security companies as test bed, i.e. to test new methods and tools. This approach is no worse than others, but it does give us some valuable information. If worldwide DDoS statistics show the current state of things, then attacks on IT security companies allow us to some extent to predict the future of DDoS.

Data on the tactics, strength and types of attacks targeting Kaspersky Lab sites also allows us to forecast the trends in the DDoS industry for the coming months.

Once again, we have had to deal with amplification attacks. Their number has declined slightly compared to last year, but their maximum strength has increased fourfold. This confirms the trend of a general strengthening of these attacks – the criminals have to increase the strength to overcome protection measures used by Internet providers and information security companies. In our case, none of these attacks led to our sites being unavailable.

In Q1 2016, 93.6% of resources targeted by #DDoS attacks, were located in 10 countries #KLreport

Tweet

Considering the number of attacks on Kaspersky Lab resources in the first quarter of 2016, the “cream” of the cybercriminal community has gone back to the good old methods of attacks at the application level. Already in the first quarter of this year, we combated several times more HTTP(s) attacks than we did in the whole of 2015. Interestingly, there were several application-layer attacks performed simultaneously against a number of Kaspersky Lab resources. The strength of the DDoS resources was spread between several targets, reducing the effect on each target. This is most probably because the aim was not to disrupt Kaspersky Lab’s sites but to test tools and to see how we responded. The longest attack of this type lasted less than six hours.

We can assume that the proportion of Data Link layer attacks will gradually decline, and application-layer and multi-layer attacks (a combination of hardware and application-layer attacks) will come to the fore.

Powerful UDP amplification attacks came into general use a few years ago and are still a favorite tool of cybercriminals. The reasons for their popularity are clear: they are relatively easy to perform, they can be very powerful with a relatively small botnet, they often involve a third party, and it is extremely difficult to detect the source of the attack.

Although in Q1 of 2016 our Kaspersky DDoS Prevention service continued to combat UDP amplification attacks, we believe that they will gradually disappear. The once daunting task of combining the efforts of Internet providers and IT security companies to effectively filter the junk traffic generated by UDP attacks is almost solved. Having faced the risk of their main channels being clogged up due to large volumes of UDP packets, providers have acquired the necessary equipment and skills and cut this traffic off at the root. This means amplification attacks on a Data Link Layer are becoming less effective and, as a result, less profitable.

In Q1 2016, the largest numbers of #DDoS attacks targeted victims in #China, the #USA & #SouthKorea #KLReport

Tweet

To execute application-layer attacks on web services, large botnets or several high-performance servers and a wide output channel are required, as well as thorough preparatory work to study the target and find its vulnerabilities. Without this, they are ineffective. If the application-layer attack is carried out properly, it is difficult to counter it without blocking access to legitimate users – malicious requests look authentic and every bot faithfully fulfills the connection procedure. The only anomaly is the high demand for the service. We registered these sorts of attempts in the first quarter. This suggests that the DDoS market has developed so that complex, expensive attacks are becoming cost-effective, and better qualified cybercriminals are trying to make money using them.

Moreover, there is a real danger of these methods being used by cybercriminals en masse – the more popular the technique, the more tools are offered for it on the black market. And if application-layer attacks really do become widespread, we should expect to see a growth in the number of customers for this type of DDoS attack and more competent attackers.

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.

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 first 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 longest #DDoS attack in Q1 2016 lasted for 197 hours (or 8.2 days) #KLreport

Tweet

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.

It is important to note that DDoS Intelligence statistics are limited to those botnets that were detected and analyzed by Kaspersky Lab. It should also be highlighted 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.

Q1 Summary
  • In Q1, resources in 74 countries were targeted by DDoS attacks (vs. 69 in Q4 of 2015).
  • 93.6% of the targeted resources were located in 10 countries.
  • China, the US and South Korea remained the leaders in terms of number of DDoS attacks and number of targets. France and Germany were newcomers to the Top 10.
  • The longest DDoS attack in Q1 2016 lasted for 197 hours (or 8.2 days) which is far less than the previous quarter’s maximum (13.9 days). Multiple attacks on the same target became more frequent (up to 33 attacks on one resource during the reporting period).
  • SYN DDoS, TCP DDoS and HTTP DDoS remain the most common DDoS attack scenarios, while the number of UDP attacks continues to fall from quarter to quarter.
  • Overall, command servers remained located in the same countries as the previous quarter, but Europe’s contribution increased – the number of C&C servers in the UK and France grew noticeably.
Geography of attacks

In Q1 2016, the geography of DDoS attacks narrowed to 74 countries.

93.6% of targeted resources were located in 10 countries.

Distribution of DDoS attacks by country, Q1 2016 vs. Q4 2015

The Top 3 most targeted countries remained unchanged. However, South Korea’s share grew from 18.4% to 20.4% while the US’s contribution dropped by 2.2 percentage points. Also of note is the fact that Q1 2016 saw an increase in the number of attacks targeting resources in Ukraine – from 0.3% to 2.0%.

The statistics show that 94.7% of all attacks had targets within the Top 10 most targeted countries:

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

The number of targets in South Korea increased by 3.4 percentage points. China’s share fell from 50.3% in Q4 2015 to 49.7% in the first three months of 2016. The percentage of DDoS attacks targeting resources in the United States also decreased (9.6% in Q1 2016 vs. 12.8% in Q4 2016). Despite the change in figures, South Korea, China and the US maintained their positions in the Top 3, coming well ahead of all other countries.

SYN #DDoS, TCP DDoS & HTTP DDoS remain the most common DDoS attack scenarios in Q1 2016 #KLreport

Tweet

The first quarter of 2016 saw Ukraine enter the Top 5 DDoS targets: its share grew from an insignificant 0.5% at the end of last year to 1.9% in Q1 2016.

Taiwan and the Netherlands’ share fell 0.8 and 0.7 percentage points respectively, meaning both dropped out of the Top 10 most attacked countries.

Changes in DDoS attack numbers

In Q1 2016, DDoS activity was distributed more or less evenly, with the exception of one peak on 6 February. The peak number of attacks in one day was 1,272, recorded on 31 March.

Number of DDoS attacks over time* in Q1 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.

As in the previous quarter, Monday (16.5% of attacks) was the most active day of the week for DDoS attacks. Thursday moved up to second (16.2%). Tuesday, which was in second place in Q4 2015 (from 16.4% to 13.4%), became the quietest day of the week in terms of DDoS attacks.

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 constant from quarter to quarter. Those used most often were the SYN DDoS method, although its share fell compared to the previous quarter (57.0% vs 54.9%), and TCP DDoS which fell by 0.7 percentage point. The proportion of ICMP DDoS attacks grew significantly, rising to 9%; however, it did not affect the order of the Top 5.

Distribution of DDoS attacks by type

Noticeably, the figure for UDP DDoS has fallen continually over the last year: from 11.1% in Q2 2015 to 1.5% in Q1 2016.

Like the previous quarter, about 70% of attacks lasted no more than 4 hours. At the same time, the maximum duration of attacks decreased considerably. The longest DDoS attack in the last quarter of 2015 lasted for 333 hours; in Q1 2016, the longest registered attack ended after 197 hours.

Distribution of DDoS attacks by duration (hours)

C&C servers and botnet types

In Q1, South Korea remained the leader in terms of the number of C&C servers located on its territory, with its share growing from 59% in the previous quarter to 67.7% in the first quarter of 2016.

China came second; its share grew from 8.3% to 9.5%. As a result, China pushed the US down to third (6.8% vs 11.5% in Q4 of 2015). For the first time during the reporting period France appeared in the Top 10 countries hosting the most C&C servers. This correlates with the increased number of attacks in the country.

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

99.73% of DDoS targets in Q1 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.25% of cases. In 0.01% of cases three or more bots were used, mainly from the Sotdas, Xor and BillGates families.

Correlation between attacks launched from Windows and Linux botnets

When it came to the number of attacks launched from Windows and Linux botnets in Q1 2016, Windows-based botnets were the clear leader. For the third quarter in a row, the difference between the share of Windows- and Linux-based attacks was approximately 10 percentage points.

Conclusion

The events of the first quarter of 2016 once again demonstrated that the attackers are not resting on their laurels and are increasing their computing resources to perform DDoS attacks. Amplification scenarios, which have de facto become the standard tool for carrying out a powerful attack, exploit vulnerabilities in new network protocols. The reasons for an attack can vary: from disrupting pre-election campaigns and attacking candidates’ resources to showdowns between competitors on the black market. There have been frequent incidents of DDoS attacks targeting the very organizations that specialize in countering them. With the spread of vulnerable devices and workstations and the abundance of configuration drawbacks at the application level, the cost of a significant attack is going down. Therefore, reliable protection is needed to ensure these attacks are financially unviable for the criminals.

Contributing to the Annual DBIR

Wed, 04/27/2016 - 12:27

This year’s DBIR release from Verizon exposes valuable and well organized data on global incidents this past year. Our contributions on targeted attack activity and other areas to a report like this one over the past several years is important to help to improve cyber-security awareness and education both in the security industry and the general public.

The report is well organized, offering trending information from Point of Sale incidents to cyber-espionage, web application hacking, cybercrime, and skimming. And it simplifies most of the data into nine categories for ease of discussion. The data demonstrates that intruders will use tried and true techniques before moving on to the newest and most expensive. Like most years in cybersecurity, “It’s like déjà vu, all over again.” —Yogi Berra

You can download the 2016 DBIR here, its 85 pages of data and diagrams can help provide informed discussion around these topics on a greater scale. We look forward to another great writeup in 2017 from the DBIR guys at Verizon.

Freezer Paper around Free Meat

Wed, 04/27/2016 - 07:20

BeEF Wrapped Up and Delivered in 2016

In late February 2016, a University website in Iran stood out for thoroughly vetting its current and potential students and staff. The University’s web site served repackaged content from the Browser Exploitation Framework (BeEF) with embedded JavaScript content maintaining the potential to hook visitors’ web browsers, identify visited websites and domains, explore for vulnerabilities (we did not observe any auto-pwning), and provide tracking through evercookies. Even a partial listing of visited sites can be sensitive and valuable information, and this sort of “sites visited” data gathering via other techniques, like screengrabbing and keylogging, were observed in past APT incidents like the Madi campaigns. Currently, it’s advisable to avoid the site.

The embedded BeEF content appears not to be fully configured, and only partially implemented. Perhaps a limited data set was of interest for this attacker, or this was an early attempt at deploying BeEF.

This incident is interesting because at the same time and a bit earlier, another group was heavily relying on repackaging open source offensive security product in their toolset by deploying both BeEF and Metasploit-produced components across a select set of strategic web compromises. This particular APT has years of low-tech elaborate social engineering schemes and re-purposed open source efforts under its belt.

While we call them the NewsBeef APT, they have been reported in the past as Charming Kitten or Newscaster in 2014, social engineering their way into sensitive circles of trust with spoofed LinkedIn profiles and phony news media organizations.

They continue to be highly active, but this time, they are using a slightly more technical toolset. On one hand, they have developed skills or discovered tools to compromise select web applications and sites, supporting their watering hole campaigns. On the other hand, they have repackaged leaked bot source code and repackaged open source Metasploit and PowerSploit components to produce and administer backdoors and downloaders.

Newsbeef/Newscaster will find a way to compromise a web site, usually the vulnerability appears to be CMS related, in an outdated WordPress plugin, Joomla version, or Drupal version. Attackers usually perform one of two things, Newsbeef has been performing the first of the two:

  • inject a src or iframe link into web pages or css sheets
  • inject the content of an entire BeEF web page into one of the internally linked javascript helpers

The injected link will redirect visitors’ browsers to a BeEF server. Usually, the attackers deliver some of the tracking and system/browser identification and evercookie capabilities. Sometimes, it appears that they deliver the metasploit integration to exploit and deliver backdoors (we haven’t identified that exploitation activity in our ksn data related to this group just yet). Sometimes, it is used to pop up spoofed login input fields to steal social networking site credentials. We also haven’t detected that in ksn, but some partners have privately reported it about various incidents. But we have identified that attackers will redirect specific targets to laced Adobe Flash and other installers from websites that they operate.

So, the watering hole activity isn’t always and usually isn’t delivering backdoors. Most of the time, the watering hole injections are used to identify and track visitors or steal their browser history. Then, they deliver the backdoors to the right targets.

In addition to the University site and the NewsBeef APT, in the past couple of months, we identified a variety of compromised sites around the world serving the BeEF. Most are cleaned up. Deployments to interesting and strategic web sites and their true reach on a global scale appears to be on the increase:

  • Middle eastern embassy in the Russian Federation
  • Indian military technology school
  • High conflict regional presidency
  • Ukrainian ICS Scanner mirror
  • European Union education diversification support agency
  • Russian foreign trade management organization
  • Progressive Kazakh news and politics media
  • Turkish news organization
  • Specialized German music school
  • Japanese textile manufacturing inspection corporate division
  • Middle Eastern social responsibility and philanthropy
  • surprisingly popular British “lifestyle” blog
  • Algerian University’s online course platform
  • Chinese construction group
  • Russian overseas business development and holding company
  • Russian gaming developer forum
  • Romanian Steam gaming developer
  • Chinese online gaming virtual gold seller
  • Brazilian music instrument retailer

 

BeEF Capabilities

Key to these incidents are the development, distribution, and ease of use of toolkits like BeEF.

BeEF itself is an open source collection of tools and tricks, some years old, that combined together can effectively hook a visiting web browser for evaluation and full exploitation. Because of its capabilities, we have seen increased adoption of the framework for the past year or so.

  • Browser enumeration and reporting
  • Plugin enumeration and reporting
  • Retrieve visited domains (based on an old browser cache fetch timing trick)
  • Social engineering via live sessions and phishing within the browser
  • Network exploration, discovery, and exfiltration tunneling
  • Metasploit exploit integration and autopwning
  • Evercookie deployment for persistent tracking – multiple platforms
  • XSS evaluation and exploitation

At the same time, many of the techniques implemented are very old and public. The kit is extensible, customizable, and integrates with metasploit for autopwnage. Some of the techniques were discussed during Jeremiah Grossman’s 2006 Black Hat conference presentation. The delay in deployment for techniques of this type indicates that some teams are dependent on open source tool packaging and ease of use. We have seen this sort of reliance on both open source offensive toolkits and legitimate software in the past from APT like Crouching Yeti, TeamSpy, and now the Newsbeef.

Fighting against the use of browser hooking frameworks for identification, tracking, live session social engineering, and precision and auto-exploitation effectively requires a mix of technologies. When these JavaScript-based frameworks are used in a malicious manner, the combination of network and host based detection is required to fully handle more serious incidents.

Unfortunately, these incidents are on the increase. You can disable JavaScript in your own browser with NoScript, but that’s much like just moving to Lynx or a text-based browser – people don’t want that because it kills functionality in the browser they do want. A Chrome plugin that detects the BeEF cookie is easily evaded by serious players. And preventing the tracking methods altogether is another whole ball of wax, because much of the functionality is tied into legitimate web pages by third party marketers and retailers.

Preventing the social engineering sessions for credential theft and Metasploit exploit integration makes immediate sense and can be incorporated at the network and more effectively at the host level. AntiAPT can help wipe out most of an operation on the network at scale, but these measures can be evaded as well. In other words, dealing with a determined attacker using tools like this one is difficult.

References

NEWSCASTER – An Iranian Threat Inside Social Media
The Browser Exploitation Framework Project
Metasploit: Penetration Testing Software

Malware and non-malware ways for ATM jackpotting. Extended cut

Tue, 04/26/2016 - 07:02

Cash machines have been part of our lives since 1967 when a London branch of Barclays Bank unveiled the first ATM. Millions of people around the world now use ATMs every day to withdraw cash, pay in to their account or make a variety of payments. When using ATMs people give little or no thought to the hardware, software or security of the machines. Unfortunately, ATM manufacturers and their primary customers – banks – don’t pay much attention to the security of cash machines either. This is confirmed by the increasing number of thefts from ATMs using non-destructive methods, i.e. without the use of metal cutting tools or explosives.

To understand why this is happening, let’s first look at what exactly a cash machine is.

Hardware

An ATM is basically a construction kit. The manufacturer builds them from a dispenser, a card reader and other units produced by different companies. The units are placed in a housing which usually consists of two parts: the top box called the cabinet, or the servicezone, and the lower section called thesafe.

The cabinet includes units such as the system unit (yes, a standard system unit, which sometimes even has the same housing as a typical home computer), the EPP (Encrypting PIN Pad) the card reader, and so on. The service zone, according to ATM manufacturers, contains everything that makes it impossible to access the money. Probably for this reason the cabinet cover is made of plastic and the service zone is protected from unauthorized access by just a simple lock. By the way, a set of locks and separate keys can both easily be purchased online as the manufacturers install the same locks on their devices, and most banks usually don’t bother to replace them.

The safe has much better protection: it is a ‘sandwich’ of steel and concrete with two types of locks – one coded (electronic or limb, sometimes electro-mechanical) and the other a key lock (usually a lever tumbler lock). The safe contains the devices directly related to the money – a dispenser from which cash is withdrawn, and a cash-in module.

All devices are connected to the system unit, which in this case performs the function of the host (as we shall refer to it) via the USB or RS232 ports (often referred to as a COM port). Sometimes these ports are located directly on the system unit; if there aren’t enough ports, a USB/COM hub is used. Older ATM models can still be found that are connected via the SDC bus.

Software

The software used on almost every ATM is straightforward:

  • operating system
  • ATM units management software
  • software used to interact with the user (ATM consumer or operator)
  • software used to communicate with the processing center (which provides the information and technological sides of the transaction)
  • anti-virus software, or integrity control software.

This is sufficient for the ATM to carry out its immediate functions, but for some reason certain banks also install Acrobat Reader 6.0, Radmin, TeamViewer and other unnecessary and in some cases even dangerous software.

When it comes to the operating system, the vast majority of ATMs still use … Windows XP! Despite the fact that Microsoft stopped issuing security updates for it in April 2014. Of course, 0-day vulnerabilities for this system will remain unpatched. The engineers servicing ATMs often think that if the ATM is working, it is better “not to touch” (read: “not to update”) it. As a consequence, some cash machines still have the unpatched critical vulnerability MS08-067 which allows remote code execution.

ATM units are implemented on microcontrollers based on real-time operating systems (RTOS), which is particularly irksome for the guys with IDA Pro because static analysis is almost unheard for such systems.

That’s basically all the information cybercriminals need to start hacking.

Malware

In 2009, the appearance of Trojan Backdoor.Win32.Skimer caught the world’s attention: it was the first malicious program targeting ATMs. Skimer attacked ATMs from a particular manufacturer – one of the market leaders. Using this malicious program the criminals emptied the cash dispensers and also skimmed the data from bank cards processed in infected ATMs. Since then, ATMs of different manufacturers have been repeatedly exposed to malware infection.

The process of stealing money from ATMs using malware consists of four stages:

  • The attacker gains local/remote access to the machine.
  • Malicious code is injected into the ATM system.
  • As a rule, infection is followed by rebooting of the ATM. The system seems to reboot in standard mode but at the same time comes under the control of a malicious program, i.e. cybercriminals.
  • The final stage, i.e. the main aim of the process, is the theft of money.

Getting access to the inside of an ATM is not a particularly difficult task, as the experts at the Positive Hack Days, the international forum on practical information security, demonstrated. The process of infecting is also fairly clear – arbitrary code can be executed on an insecure (or insufficiently secure) system. There seems to be no problem with withdrawing money either – the malware interface is usually opened by using a specific key combination on the PIN pad or by inserting a “special card”, and then all you need to do is stuff your pockets full of cash.

Here we will focus on how a malicious program can gain control of an ATM.

The XFS standard

So the attackers have infected the ATM system unit. What next?

Here again, a short explanation is required. As already mentioned, the ATM is managed by a Windows-based application. Its task is to organize interaction between the user (client or services), the processing center which sends commands to the ATM and the equipment that executes these commands. The message exchange with the processing center occurs via direct connect protocols (NDC or DDC): users communicate with the GUI while service providers are responsible for the operation of each ATM unit (gateways to these units). To send commands to the service providers and on to the equipment as well as to receive status messages, a level called XFS Manager is used in accordance with WOSA.

ATM operations in the context of the XFS standard

XFS (CEN/XFS, and earlier WOSA/XFS), or the eXtensions for Financial Services, is a standard that provides a client-server architecture for financial applications on the Microsoft Windows platform, especially peripheral devices such as ATMs. XFS is intended to standardize software so that it can work on any equipment regardless of the manufacturer, and provides a common API for this purpose.

Thus, any application that is developed with the XFS standard in mind can control low-level objects by using only the logic described in this standard. And that application could well be the Tyupkin backdoor or any other malicious program.

What opportunities does XFS offer?

For example, the dispenser, which is the most interesting part for the attackers, can give out money without authorization. Or use of XFS on some ATM models means cybercriminals can manipulate the code to open the safe and unlock the ATM cassettes.

Exploitation of the MS08_067 vulnerability allowing execution of arbitrary code. The video was shot by experts at BlackHat Europe 2014

With regard to the card reader, XFS allows the reading and recording of data from the bank card magnetic stripe and even retrieval of the transaction history stored on the EMV card chip.

Of special note is the Encrypting PIN Pad (EPP). It is believed that the PIN cannot be intercepted because it is entered on the ATM PIN pad and is converted directly inside the encryption module into a PIN block (EPP contains keys to do this, two of which are in the bank’s Hardware Security Module). However, XFS allows the PIN pad to be used in two modes:

  1. Open Mode – for entering different numeric values, such as the sum to be withdrawn;
  2. Secure Mode, which EPP switches to in order to enter a PIN and encryption keys.

This allows cybercriminals to implement a “man-in-the-middle” (MiTM) attack. They only have to intercept the command sent from the host to the EPP to switch to Secure Mode and then to inform the device that work is continuing in Open Mode. In the reply message, the EPP will send the keystrokes as plain text – exactly what the attacker needs.

But what about authentication and exclusive access? And surely the standard’s specifications are inaccessible?

Unfortunately, this is not the case with XFS. The standard does not provide any authentication, and exclusive access to service providers is implemented, but not for security reasons. This is just a single-threaded command sending function to avoid accidentally breaking delicate hardware by simultaneously sending two identical commands.

Surprisingly, although it is a standard for financial applications, it doesn’t even mention security. Where can you find the specifications to check if this is true? Just try entering “ATM XFS” in any search engine and you’ll find the answer among the first few results.

Integrity control software

Banks sometimes use integrity control software on their ATMs that supposedly prevents the execution of unauthorized code based on a whitelist, controls connected devices and drives, as well as providing other useful methods which should, in theory, counter attacks.

But we shouldn’t forget that first of all it is software, and just like any other software, it’s not perfect. It may be vulnerable to attacks as such kiosk mode bypassing, whitelist bypassing, buffer overflow, privileges escalation to SYSTEM user, etc. As you know, existing vulnerabilities often allow cybercriminals to gain access to the operating system and to do their dirty work.

Undocumented features

The bad guys may use modified utilities that were originally provided by ATM developers or manufacturers to test a machine’s operability. One of the functions of these utilities is to test the dispenser function, including the dispensing of cash. In order to carry out a test, the engineer has to confirm his legitimacy by opening the safe door or performing actions with the dispenser cassettes. The logic is simple: if you can open the safe, you have the key, i.e. you are a licensed engineer or a cash-in-transit guard. But by simply replacing a couple of bytes in the utility, the “right” people can “test” cash withdrawals without any checks.

Yet another way criminals have of lining their pockets is to change the denomination of banknotes dispensed by the ATM using a diagnostic utility. As a result, the attacker receives banknotes with the largest nominal value (e.g., a 100 dollar/euro banknote) while the ATM “thinks” it is dispensing the smallest of the available denominations (five or ten). It means several hundred thousand can be withdrawn from a card with a balance of just a few hundred.

Black box

So-called black box attacks are another type of attack that is getting increased coverage in the news. On surveillance camera videos the following occurs: someone opens the service zone, connects a magic box to the ATM, closes the cabinet and leaves. A little later several people who appear to be customers approach the ATM and withdraw huge sums of money. Of course, the criminals retrieve their little device from the ATM once they have achieved their goal. Usually, these black box attacks are only discovered a few days later when the empty cassettes and the withdrawal logs don’t tally, leaving the bank employees scratching their heads.

However, there is no magic involved – the attackers connect a specially programmed microcomputer to the dispenser in such a way that it bypasses the security measures implemented on the host (antivirus, integrity control, full disk encryption, etc.).

Communications insecurity

As mentioned above, USB, RS232, or SDC can be used as a data transmission channel between the system unit and the devices. It’s likely that nothing will prevent the attackers from sending the necessary commands directly to the device port bypassing its service provider. The standard interfaces often do not require any specific drivers. Authorization is not required either, which basically makes these insecure proprietary protocols an easy target – just sniff and replay. The result is direct control over ATM units, the use of undocumented functions (e.g., changing the unit firmware). The criminals may also use a software or hardware traffic analyzer, installing it directly on the port of a particular device such as a card reader in order to obtain the transmitted data. And this analyzer will be difficult to detect.

Direct control over the dispenser means the ATM cassettes can be emptied without any entries being made in the ATM software logs.

A typical packet – the command to dispense a banknote from the first cassette of the dispenser

For those who are unaware, it may look like magic. Every great magic trick consists of three parts or acts. There are dispensing money from the cassette, opening the shutter, and presenting money to the client.

A black box attack on an ATM. Video was prepared by experts for demonstration purposes at BlackHat Europe 2014

Hardware skimmers are ‘so yesterday’. Direct connection makes it possible to read and record the magnetic strip of a credit card. Traffic analyzers, which are freely available on the Internet, can also be used as a direct connection. Rumor has it that in one fairly large bank all the ATMs were used as skimmers: the attackers had found vulnerabilities in the bank’s network and installed a USB sniffer on the ATMs, allowing them to collect bank card data in plain text for five years! Who knows, maybe your card was among those affected.

The intercepted data of a Track2 card

The network

The connection between ATMs and the processing center can be protected in various ways. For example, using a hardware or software VPN, SSL/TLS encryption, a firewall or MAC-authentication, implemented in xDC protocols. However, all these measures often appear to be so complex for banks that they don’t bother using any network protection at all.

In such cases, a MiTM attack can be launched that will result in the attacker getting both bank card data and all the money in the ATM. This requires remote access to the device, which is usually obtained by using vulnerable services that can be accessed from the Internet, as well as social engineering techniques. Physical access to the network hardware, including the ATM Ethernet-cable will also suffice.

On the way to the real processing center a fake one pops up; it sends commands to the ATM software to dispense banknotes. Withdrawing money is possible with any card, even one that has expired or has a zero balance, as long as the fake processing center “recognizes” it. A fake processing center can be either “homemade” software that supports communication with the ATM via the xDC-protocol, or a processing center simulator originally designed to check network settings (yet another “gift” from the vendors to the cybercriminals).

The commands for giving out 40 banknotes from the fourth cassette sent from a fake processing center and stored in the ATM software logs. They look almost like the real thing.

Where do the criminals find ATMs that can be attacked via the network? Do they scan all the nearby networks or buy the information on underground forums?

It turns out that you just need to enter the correct request in a search engine – https://www.shodan.io/ (this Internet of Things scanner is well-known by the experts). The data collected by this scanner is usually enough to launch such attacks.

#Shodan shows thousands of exposed ATMs potentially vulnerable to a network attack @_endless_quest_ #TheSAS2016 pic.twitter.com/9E3SSYwG89

— Eugene Kaspersky (@e_kaspersky) 9 февраля 2016 г.

Or you could just take a closer look at the ATMs in retail and business centers.

Sometimes the ATM system can be accessed without even opening it – all the communications are located on the outside

Who’s to blame and what can be done

This part is usually the most depressing, and here’s why.

When we detect a vulnerability while analyzing ATM security, we send a notification to the vendor with a description of the problem and ways to solve it. And often the answers are bewildering:

“The vulnerabilities are essentially normal specifications of the card readers and not unexpected. As long as the ATM is running within normal parameters, these problems cannot possibly occur.”

“However this vulnerability is inherent in the USB technology and is expected be mitigated by the use of appropriate physical controls on access to the ATM top box.”

“We regret informing you that we had decided to stop producing this model more than 3 years ago and warranties for our distributors been expired.”

Indeed, why should vendors bother about ATMs with expired warranties that are still used by banks around the world, and whose physical security often leaves much to be desired? Unfortunately, reality shows that manufacturers are only interested in selling new products and not in eliminating the shortcomings of existing systems, while banks lack the necessary skills to cope with the problems on their own.

Fortunately, some manufacturers understand the dangers of unauthorized ATM use, and release security updates. To prevent attacks on dispensers, two-way authentication and cryptography are used. It should be noted, however, that not all cryptography is correctly implemented cryptography.

While the existing countermeasures can protect ATMs from malware, they are powerless against black box or network attacks. A huge number of security flaws and vulnerabilities that can be exploited with minimum expertise make cash machines a prime target for those desperate to get rich illegally.

So. Is everything lost?

ATM manufacturers can reduce the risk of attack on cash machines.

  • Firstly, it is necessary to revise the XFS standard with an emphasis on safety, and introduce two-way authentication between devices and legitimate software. This will help reduce the likelihood of unauthorized money withdrawals using Trojans and attackers gaining direct control over ATM units.
  • Secondly, it is necessary to implement “authenticated dispensing” to exclude the possibility of attacks via fake processing centers.
  • Thirdly, it is necessary to implement cryptographic protection and integrity control over the data transmitted between all hardware units and PC inside ATM.

And what should banks do? They need to take action!

Encourage those who sell ATMs and software to make them secure. The manufacturer must eliminate vulnerabilities as soon as possible; it is necessary to tell them about it as often as possible. To prevent hacking of ATMs it is necessary to make use of all the available protection tools. A completed PCI DSS Self-Assessment Questionnaire is not a silver bullet and won’t protect ATMs from attacks, or banks from financial and reputational losses. Proactive protection, including regular ATM security assessment and penetration testing, is better (and often much cheaper) than security incident and the subsequent investigation.

Bad guys are watching.

Stay safe!

PS: No cash machines were harmed in the preparation of this material.

PPS: This overview of the security issues in cash machines is not intended as a hacking guide.

Spammers all geared up for Euro 2016!

Fri, 04/22/2016 - 06:59

Major football tournaments such as the World Cup and the European Championship, traditionally attract a lot of spammer activity. Euro 2016 will be held this summer in France, and it’s not only the fans and players who are getting ready but also Internet fraudsters. The latter have started sending out fake notifications about lottery wins dedicated to the upcoming tournament. Their emails often contain attachments adorned with graphic elements including official emblems, the Euro 2016 logo and those of its sponsors.

The contents of the attachments are the standard stuff: the lottery was held by an authorized organization, the recipient’s address was randomly selected from a large number of email addresses, and in order to claim your prize you have to reply to the email and provide some personal information. We have recorded cases where the same attachment was sent in messages with a different text, but the theme of the email is essentially the same. The fraudsters also use different email addresses and change those used in the body of the message and the attachment.

We have also come across advertising spam in different languages, for example in Dutch, asking recipients to buy a 2-euro commemorative coin issued specifically for Euro 2016.

We expect to see a growth in football-themed spam as the start date of Euro 2016 approaches. This type of fraudulent spam can be one of the most dangerous for users: the perpetrators are unlikely to limit their activity to fake lotteries, and will start spreading various emails offering the chance to win tickets to the games, as was the case before the World Cup in Brazil. The amount of spam targeting users in France, which is hosting the championship, may also increase.

How to trick traffic sensors

Mon, 04/18/2016 - 07:00

A detailed presentation of this research was delivered at RSA US 2016, and is available at https://www.rsaconference.com/writable/presentations/file_upload/tech-t09-smart-megalopolises.-how-safe-and-reliable-is-your-data.pdf

In the past two years traffic sensors have mushroomed in Russian cities. Drivers using speed camera detectors were the first to spot the white boxes stuck to posts along the roadside. Their devices, designed to warn drivers about traffic enforcement cameras, react to the signals emanating from the new sensors in the same way they do to the radar guns used by traffic police. Helping enforce the speed limit is merely a positive side effect, however; the city authorities installed the sensors for a completely different reason. The devices count the number of cars of varying size in each lane, determine their average speed, and send the data to a unified traffic control center.

A traffic sensor in Moscow

As a result, the city authorities receive information about traffic intensity, which allows them to, for example, adjust traffic light phasing or plan further road infrastructure. The weekly reports issued by Moscow’s traffic authorities present information about the slowest and the fastest highways, based on data coming from both the Center for Road Traffic Management and from Yandex. While the latter’s data comes from apps running on users’ smartphones, the former would not be able to collect its data without the road infrastructure that will be discussed here.

Each week the Moscow city authorities publish data about the city’s fastest and slowest highways

These sensors are the lowest tier of ‘smart city’ infrastructure – they collect raw data about traffic and pass it on; without that data, no analysis can be done and systems cannot be configured properly. Therefore, the information coming from the sensors has to be accurate. But is that actually the case? Can an outsider manipulate the operation of the sensors and the information that they collect? We will try to answer these questions and identify any improvements that can be made to the urban IT infrastructure.

How to search for devices and information about them

Any research begins by collecting all the available data, and research into embedded systems, to which traffic sensors belong, is no exception. Even in a narrow market segment, you cannot know all sensor types and models by sight unless you are dealing with them professionally every day. The odds are that you won’t be able to immediately identity the manufacturer of a device by just looking at it. This makes all the logos and manufacturer labels on devices all the more valuable.

If you do succeed in identifying the model of a road sensor just by looking at it, you can find various documentation on the vendor’s site (or that of their integrator), and, if you are lucky enough, you will also find the software used for working with the devices. You will almost certainly find a marketing leaflet about your device; there is also a good chance you will find a larger sales-oriented document. It is also not uncommon to come across documentation, but finding a full-fledged technological description with the device’s command system is a rare piece of luck.

It is practical to automate the process of working with the sensors, so you don’t have to sit under each and every device with a laptop. Nowadays, such automation is quite normal – wireless connections are no longer a rarity for ‘smart city’ components. However, to ensure such automation, you first need to know which communication protocol each sensor uses, and how to separate the devices you need from all the other devices.

For this purpose, you can use any identifiers, including peculiarities in how the devices communicate their data. For example, most MAC addresses are reserved to specific manufacturers (however, anonymous MAC addresses also exist). As well as numeric IDs, devices also typically have alphabetic names that may also follow some type of standard, i.e. the device model plus an incremental index.

All of this makes it possible to write a scanner to search for devices that are of interest to us. One of the sensor models installed in Moscow uses Bluetooth for data communication. These devices have both MAC addresses and ‘friendly names’ that are quite distinctive, so we can add only these traffic sensors to the list and filter out all nearby smartphones and TV sets. A discussion on Bluetooth security goes beyond the scope of this topic, so we will not talk here of compromising Bluetooth devices. We informed the Moscow city authorities about the configuration drawbacks in November 2015.

Traffic sensor records saved to a database

I used Python, PostgreSQL and a bit of C. In real time, as I drive by each traffic sensor, the scanner identifies each device’s MAC address, friendly name and coordinates. The fields with the vendor name and the physical address are filled out later on a separate pass through the database based on the data already collected. Determining the device’s physical address from coordinates is, to a certain degree, a time-consuming procedure, so it shouldn’t be done simultaneously while searching for devices. Establishing a Bluetooth connection is not fast either, so if you want to find traffic sensors, you’ll have to drive slowly.

What can be done with the firmware

The openness shown by the manufacturers to installation engineers, their readiness to give them access to tools and documents, automatically means they are open to researchers. (I respect this sort of approach; in my view, this sort of openness combined with a ‘bug bounty’ approach yields better results than secrecy.) After selecting any of the identified sensors, you can install the device configuration software supplied by the vendor on your laptop, drive to the location (the physical address saved in the database), and connect to the device.

As we do in any research of embedded system security, we first of all check if it’s possible to reinstall the firmware on the device.

The configuration software allows the firmware on the traffic sensor to be changed

Yes, we can install new firmware on the device via this wireless connection designated for servicing purposes. It is just as easy to find the manufacturer’s firmware and as it is its software. The firmware looks reminiscent of Intel iHex or Motorola SREC, but this is the manufacturer’s proprietary product. If we remove the overhead information (‘:’ – the write instruction, serial numbers, memory addresses and checksums) from the data blocks for the digital signal processor (DSP) and the main processing unit (MPU), we obtain the clean code. However, we don’t know the architecture of the controllers in the device, so we cannot simply open the file with a disassembler.

The traffic sensor firmware

Oddly enough, LinkedIn helps out here – it’s not just a handy resource for careerists and HR departments. Sometimes the device architecture is not a secret, and engineers who used to work for the manufacturer may be willing to talk about it. Now, as well as the file, we also have an understanding of the architecture which the firmware was compiled for. However, our good fortune only lasts until we launch IDA.

You can find the controller types even if they aren’t specified in the documentation

Even when we know the architecture, the firmware remains a meaningless jumble of bytes. However, we could find out from the same engineer how exactly the firmware is encrypted, as well as the encryption algorithms and key tables. I didn’t have the device to hand, so at that stage I decided this black box mode of firmware modification was showing little promise, and set it aside. We have to admit that in this specific case the microelectronics engineers know how to protect firmware. However, this did not mean the end of the road for our sensor research.

Only trucks travel at night

Firmware modification is “good” in that new functional capabilities can be added. However, there is sufficient functionality in the manufacturer’s standard software. For example, the device has about 8 MB of memory that is used to keep a copy of traffic data until the memory is full. This memory can be accessed. The firmware allows you to change the way that passing vehicles are classified according to their length, or change the number of lanes. Would you like a copy of the information collected on traffic? No problem. Would you like to classify all vehicles as trucks driving in the right lane? You can do that too. Of course, this will affect the accuracy of the statistics that are collected, with all ensuing consequences.

Sample of the data traffic sensors collect and pass along. The same data is stored on the device

If someone wants to get a copy of Moscow traffic statistics or manipulate the data, they will have to walk or drive around all the traffic sensors; however, they won’t have to launch software for each of the thousands of sensors and modify the settings manually. In this specific case, there is a description of the proprietary system of commands for the devices. This is not something that you come across a lot when researching embedded systems. In any case, after establishing a connection to the traffic sensor using the manufacturer’s software, the commands are no longer a secret – they are visible using a sniffer. Even then, there’s a description in English that saves us the trouble of analyzing the machine-language communication protocol.

Documented device commands make traffic analysis unnecessary

Bluetooth services are not actually implemented on the traffic sensor; the wireless protocol in this case is only a data communication environment. The data is communicated via a regular serial port. Software handling of such ports is no different from reading and writing to files, the code for sending commands is trivial. For these purposes, it’s not even necessary to implement the usual multithreaded port handling – it’s sufficient to send bytes and receive the response in a single thread.

To sum up, a car driving slowly around the city, a laptop with a powerful Bluetooth transmitter and scanner software is capable of recording the locations of traffic sensors, collecting traffic information from them and, if desired, changing their configurations. I wouldn’t say that traffic stats are a major secret, but tampering with sensor configurations could affect their validity. And that data could be used as a basis for controlling ‘smart’ traffic lights and other traffic equipment.

The sensor sent a response, the command has been accepted. Because we know the command system, it is easy to ‘translate’ the response

What can be done?

It turns out that the answers to both questions we raised at the beginning are negative: traffic data is not protected, and it can be manipulated. Why is that? Well, there was no authorization except that required for Bluetooth, and that was not configured properly. The manufacturer of the road sensors we examined is very generous when it comes to service engineers, with a lot of information about the devices publicly available on the manufacturer’s official website and elsewhere. Personally, I agree with the manufacturer and respect them for this, as I don’t think the “security through obscurity” approach makes much sense these days; anyone determined enough will find out the command system and gain access to the engineering software. In my view, it makes more sense to combine openness, big bounty programs and a fast response to any identified vulnerabilities, if for the only reason that the number of researchers will always be bigger than the number of employees in any information security department.

At the installation stage, it makes sense to avoid using any standard identifiers. Obviously, manufacturers need to advertise their products, and the servicing teams may need to collect additional information from the adhesive labels on a device, but besides the convenience there are also issues of information security to consider. Last but not least, it’s not worth relying solely on the standard identification implemented in well-known protocols. Any additional proprietary protection that is properly implemented will be relevant and make penetration much more difficult.

A detailed presentation of this research was delivered at RSA US 2016, and is available at RSA conference website.

InfiltrateCon 2016: A Lesson in Thousand-Bullet Problems

Mon, 04/11/2016 - 11:06

Last week vulnerability developers, security researchers, and even a couple of friendly govies descended upon my native Miami for two daily servings of novel implants, exploits, and the latest in offensive research. To contrast the relaxed bikini-clad environment, an adversarial tone was set by conference badges in the form of survival paracord bracelets with Infiltrate dogtags. In good spirits, white-, grey-, and black-hats sparred for tech supremacy and today I’d like to share some thoughts on insightful talks that forecast the intricacies and stumbling blocks that await us as defenders.

This industry has seen its fair share of military analogies for cyberconflict (including Chris Hoff’s brilliant 2015 SAS keynote) and this conference did not disappoint in that area. Kicking off Infiltrate, Nate Fick (CEO of Endgame) brought to bear his wealth of experience in the Marines to the current situation in infosec to great effect. Perhaps doing a disservice to an insightful talk, I’d like to recall some key concepts of Nate’s keynote that build up to a cohesive argument for understanding the role of escalation dominance in our space:

  • ‘A dollar of offense almost always beats a dollar of defense’. Let that sink in.
  • ‘One of the tenets of civilized societies is that governments have a monopoly on the legitimate use of force’, a just-war theory concept worth remembering when the preposterous suggestion of ‘hacking back’ is thrown around as a legitimate option for companies.
  • ‘What level of hacking warrants a bullet, rendition, or a drone?’. This is not a trivial question in our space. As Nate discussed, if we are going respect the cyber-equivalent of a monopoly on the legitimate use of force so that only the government is allowed to conduct offensive cyber-operations in retaliation for an attack on private industry, and we expect this to function as some form precedent-based deterrence, then we should have a clear idea of what offenses merit certain types of retribution.

This is all by way of preparing the ground for the concept of ‘escalation dominance’. As Nate stated, “Escalation dominance, if you don’t have it then don’t fight someone who does”. And that is to say, “You can only deter an adversary if you have the escalatory capability to beat them all the way up the ladder”. I hope these serve as timely takeaways as companies weigh the possibility of ‘hacking back’, an option that is sure to yield meager gains when compared to the next play that awaits on the escalatory ladder.

Further highlights, include Joe Fitzpatrick’s talk on hardware implants titled ‘The TAO of Hardware, the Te of Implants’. Joe is one of those rare unicorns that focuses on hardware security and showcased his skills by trying to convince us of the ease and accessibility of hardware implants. A common misconception is that hardware implants are so difficult to design and expensive to manufacture that they’re only available to the most well-resourced and technologically-capable tier of attackers but Joe shows that this is clearly no longer the case. A valuable takeaway was his starting premise, that the role of a good hardware implant is simply to provide software access and then back off entirely.

As ‘Cyber-Pathogens’ are all the rage with kids these days, I want to discuss Travis Morrow and Josh Pitt’s talk on ‘Genetic Malware’. The title is a reference to their analogies to different types of attack targeting, in this case that of bioweapons and chemical weapons. In reality, the intention is to provide a framework (now public) with which to execute Gauss-style attacks: malware binaries whose final payload is encrypted in such a way as to only decrypt and execute on a specific victim system thereby stumping third-party research efforts to reverse engineer and understand the ultimate objective of the attackers.

Travis and Josh’s E.B.O.W.L.A. (Ethnic BiO Weapon Limited Access) framework drastically lowers the entry threshold for attackers to perform Gauss-style attacks by encrypting their payloads based on specific environment variables on the victim system, environmental factors like IP range or time ranges to trigger, or even a one-time pad based off of a specific system binary. This strategy for buying time was ultimately effective in the case of Gauss whose encrypted payload remains a mystery to this day and, if popularized, will surely prove an interesting challenge for the anti-malware industry going forward.

Finally, as a result of the historic work done by Katie Missouris to help launch the federal government’s first public bug bountry program, Lisa Wiswell of the newly formed Department of Defense Digital Defense Service joined us with an articulate plea to enlist the best and brightest to ‘Hack the Pentagon’ (within scope) and help better defend the country. The crowd was accommodating and we can only hope this program proves a success if only to set precedent for further friendly outreach efforts between the US government and the larger infosec community (in all of its monochromed haberdashery).

Locky: the encryptor taking the world by storm

Wed, 04/06/2016 - 04:59

In February 2016, the Internet was shaken by an epidemic caused by the new ransomware Trojan Locky (detected by Kaspersky Lab products as Trojan-Ransom.Win32.Locky). The Trojan has been actively propagating up to the present day. Kaspersky Lab products have reported attempts to infect users with the Trojan in 114 countries around the world.

Analysis of the samples has shown that this Trojan is a brand new ransomware threat, written from scratch. So, what is Locky, and how can we protect against it?

Propagation

In order to spread the Trojan, cybercriminals sent out mass mailings with malicious loaders attached to spam messages.

Initially, the malicious spam messages contained an attached DOC file with a macro that downloaded the Locky Trojan from a remote server and executed it.

An early-stage spam message with a malicious document attached

A fragment of the malicious macro

Kaspersky Lab products detect files with malicious macros as Trojan-Downloader.MSWord.Agent and HEUR:Trojan-Downloader.Script.Generic.

We should note that in modern versions of Microsoft Office, automatic execution of macros is disabled for security reasons. However, practice shows that users often enable macros manually, even in documents from unknown sources, which may lead to some damaging consequences.

At the time of writing, the malicious spam is still being sent, but instead of the DOC files being attached there are now ZIP archives containing one or more obfuscated scripts in JavaScript. The messages are mostly in English, though some bilingual variants have appeared.

Spam message in English with the archive attached

Message in German and English with the archive attached

The user is prompted to manually launch the scripts.

Contents of the archive attached to the message

Fragment of the archived script

When launched, the script downloads the Locky Trojan from a remote server and launches it.

Kaspersky Lab products detect these script loaders as Trojan-Downloader.JS.Agent and HEUR:Trojan-Downloader.Script.Generic.

Geography of attacks

Kaspersky Security Network has reported Locky attacks in 114 countries. Below is a list of countries where the Trojan was detected most often:

Country Number of attacks Germany 3989 France 2372 Kuwait 976 India 512 China 427 South Africa 220 United States 188 Italy 128 Spain 105 Mexico 92

We should note that these statistics only include cases where the actual Trojan was detected, and does not include early-stage detections reported as malicious spam or malicious downloaders.

The geography of Trojan-Ransom.Win32.Locky attacks

As we can see, the Trojan carries out attacks in practically all regions of the world. We can assume which countries the cybercriminals see as their main targets based on the list of languages used on the ransom payment webpage (see details below).

How it works

The Locky Trojan is an executable file, about 100 kb in size. It is written in C++ using STL, and is compiled in Microsoft Visual Studio. When launching, it copies itself to %TEMP%\svchost.exe and deletes the NTFS data stream Zone.Identifier from its copy – this is done to ensure that when the file is launched, Windows does not display a notification saying that the file has been downloaded from the Internet and may be potentially dangerous. The Trojan then launches from %TEMP%.

Once launched, the Trojan checks for the presence and the contents of the below registry keys.

Path Type Value HKEY_CURRENT_USER\Software\Locky\id REG_SZ Infection ID HKEY_CURRENT_USER\Software\Locky\pubkey REG_BINARY Public RSA key in MSBLOB format HKEY_CURRENT_USER\Software\Locky\paytext REG_BINARY Text shown to the victim HKEY_CURRENT_USER\Software\Locky\completed REG_DWORD Status (whether encryption is completed)

If data already exists in the registry keys (this is the case if the Trojan has launched before, but its previous session aborted for some reason), Locky reads that data and continues with the infection process.

If launched for the first time, the Trojan performs the following actions:

  1. Contacts C&C and reports infection;
  2. Receives a public RSA-2048 key and infection ID from C&C, saves them in the registry;
  3. Sends information about the language of the infected operating system, receives the cybercriminals’ ransom demand text that will be shown to the victim, saves the text in the registry;
  4. Searches for files with specific extensions on local disk drives, encrypts them;
  5. Deletes shadow copies of files;
  6. Registers itself for autostart (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run);
  7. Searches for and encrypts files with specific extensions on network drives and on network file resources with no assigned drive letter;
  8. Displays the cybercriminals’ ransom demands to the victim;
  9. Terminates its process and removes itself.

Fragment of code that determines the language of the operating system

File encryption

The Trojan searches for files matching a given list of extensions. Then, these files are encrypted as described below.

List of file extensions that are subject to encryption

For each file that matches an extension on the list, the Trojan generates a new 128-bit key and encrypts the file’s contents with the algorithm AES-128 in CTR mode. The encrypted file is given the name <16 HEX characters as ID><16 random HEX characters>.locky. Then the following structure is added to the end of the file:

Structure appended by the Trojan to the end of an encrypted file

In C language syntax, this structure may be described as follows:

struct file_data { uint32_t start_marker; //Structure start marker = 0x8956FE93 char id[16]; //Infection ID uint8_t aes_key[256]; //AES key encrypted with RSA-2048 uint32_t name_marker; //Name start marker encrypted with AES (= 0xD41BA12A after decryption) uint8_t orig_name[520]; //Original file name encrypted with AES WIN32_FILE_ATTRIBUTE_DATA attr; //Original file attributes encrypted with AES };

Appended structure described in C language syntax

Ransom demands

After encrypting the user’s files, the Trojan displays the following message with the cybercriminals’ ransom demands.

Ransom demand in English

Ransom demand in German

The ransom message contains the address of the cybercriminals’ ‘secret server’ where they placed information about the ransom they demand for the decryption program. All four links in the message lead to the same website in the Tor network.

During the early spamming campaigns, the ransom payment page looked like this:

Early version of Locky’s ransom demand page

On this page, the cybercriminals suggested that the victims pay in bitcoins to decrypt the affected files on their computer. They also gave recommendations about where and how to get the cryptocurrency.

The contents and the design of the page changed with time. Today, the page is available in more than 20 languages (that can be selected from a dropdown list), and looks like this:

Latest version of Locky’s ransom payment page

If we look at the page’s source code, we will see a complete list of supported languages. The cybercriminals obviously see the corresponding countries as the main targets for this ransomware Trojan. Interestingly, Russian and other CIS languages are not on the list. For some reason the cybercriminals are not that keen on targeting users in countries where those languages are spoken – something that KSN statistics confirm.

List of languages supported on Locky ransom payment page

Communication with C&C

The Trojan’s code contains between one and three C&C IP addresses. On top of that, the code contains an algorithm generating new C&C addresses (DGA, domain generation algorithm) depending on the current day, month and year. With this algorithm, six C&C addresses are generated each day. The pseudo-code to illustrate the DGA Locky algorithm is highlighted in the screenshot below.

Pseudo-code of Locky C&C domain generation algorithm

Communication with a C&C is performed using the HTTP protocol. The Trojan sends a POST request to an address with the format http://<cnc_url>/main.php; the transmitted data is encrypted with a simple symmetric algorithm.

Let’s have a look at the possible types of transmitted parameters.

  1. Notification about infection and request for key.
    id=<infection id>
    &act=getkey&affid=<partner id contained in the Trojan’s body>
    &lang=<language of the operating system>
    &corp=<whether the OS is a corporate OS>
    &serv=<whether the OS is a server OS>
    &os=<OS version>
    &sp=<version of OS service pack>
    &x64=<whether the OS is 32- or 64-bit>

    Judging by the affid parameter, Locky is distributed via an affiliate, or partnership, program.

  2. Sending list of encrypted paths.
    id=<infection id>
    &act=report&data=<list of paths>

    For each disk drive it has handled, the Trojan sends the C&C a list of all paths to all encrypted files.

  3. Sending statistics for each handled disk drive.
    id=<infection id>
    &act=stats&path=<path>
    &encrypted=<number of files encrypted>
    &failed=<number of errors>
    &length=<total size of encrypted files>

It should be noted that the cybercriminal collects very detailed statistics for each infection. Other ransomware families that we analyzed earlier were not this thorough at collecting statistics.

Countermeasures

Kaspersky Lab products protect against the Locky ransomware Trojan at all stages of the attack:

  • The anti-spam module detects emails sent by the Trojan’s distributors;
  • Script loaders are detected by static and heuristic signatures of email and file antivirus with the verdicts Trojan-Downloader.MSWord.Agent, Trojan-Downloader.JS.Agent, HEUR:Trojan-Downloader.Script.Generic;
  • The Trojan’s executable file is detected by file antivirus signatures as Trojan-Ransom.Win32.Locky;
  • Unknown samples of Locky are proactively detected by the System Watcher module with the verdict PDM:Trojan.Win32.Generic.
Preventing infections

Locky is a typical ransomware Trojan, and it exhibits no major differences from other ransomware families in its internal arrangement or its principles of operation. However, it caught the attention of researchers because it was so active and so widespread. According to KSN data, Kaspersky Lab products have blocked Locky attacks in over 100 countries around the world – no other ransomware Trojan to date has attacked so many countries at once.

To protect yourself from this ransomware Trojan, follow these preventive measures:

  • Do not open attachments in emails from senders you don’t know;
  • Back up your files on a regular basis and store the backup copies on removable storage media or in cloud storages – not on your computer;
  • Regularly run updates for your antivirus databases, operating system and other software installed on your computer;
  • Create a separate network folder for each user when managing access to shared network folders.

For more detailed information about protection from ransomware Trojans, please follow this link.

The evolution of Brazilian Malware

Thu, 03/31/2016 - 07:01

Introduction

Brazilian malware continues to evolve day by day, making it increasingly sophisticated. If you want to know how the various malicious programs work nowadays, you can jump to the corresponding section here. Meanwhile, before that, we would like to show how the techniques used by Brazilian cybercriminals have changed, becoming more advanced and increasingly complex.

Taking a look at the wider picture we can see that the authors are improving their techniques in order to increase malware lifetime as well as their profits.

Some time ago, analyzing and detecting Brazilian malware was something that could be done pretty fast due to no obfuscation, no anti-debugging technique, no encryption, plain-text only communication, etc. The code itself used to be written in Delphi and Visual Basic 6, with a lot of big images inside making it a huge file, as well as poor exception handling where the process would regularly crash.

Nowadays, the scenario is not the same; the attackers are investing time and money to develop solutions where the malicious payload is completely hidden under a lot of obfuscation and code protection. They do still use Delphi and VB, but have also adopted other languages like .NET and the code quality is much better than before, making it clear to us that they have moved to a new level.

Let’s walk through some samples showing the difference between what we used to find a few years ago and the threats being delivered today.

What we used to find Keylogger

In the beginning, the first samples used to steal banking information from customers were simple keyloggers, most of them using code publicly available with some minor customizations in order to log only specific situations. At the time it was sufficient since banking websites were not using any kind of protection against this threat.

Public keylogger source code

Code implemented on malicious binary

The code was pretty simple; it just used the function GetAsyncKeyState in order to check the state of each key and then logged it as necessary. Most of the keyloggers were not using any obfuscation to hide the targets, helping in the identification of such attacks.

Plaintext strings used to detect navigation

Phishing Trojan

After the banks introduced virtual keyboard to their systems, the use of keyloggers was no longer effective. To bypass these protections, the Brazilian bad guys started developing mouselogger malware and later Phishing Trojans.

This type of malware was using DDE (Dynamic Data Exchange) in order to get the current URL opened in the browser; this method still works nowadays, but most of these malicious programs have updated their code to use OLE Automation instead of DDE because it provides more advanced options.

Code using DDE to get URL information

After getting the current URL the malware just checks if the URL is in the target list. If found, the malware would show a phishing screen asking for banking information.

Phishing Trojan being shown inside Internet Explorer

At this time the malware was not using any kind of encryption or encoding – all strings were plaintext making the analysis easier.

Malware strings without any encryption/encoding

The stolen information is then sent to the attacker by email.

Email containing the stolen information

Hosts

In order to steal information without making it easy to identify a phishing Trojan they started redirecting users to malicious web pages by changing the hosts file to resolve the banking domain names to hardcoded servers. In this way, after infection it would be more transparent to the user increasing the chances of a successful attack.

Data written to the hosts file in order to redirect access

Code used to write data to host file

These types of attack were very effective at the time, while not all anti-malware vendors were able to identify and block them. We can still see some samples using host modifications, but they are not so effective anymore.

Anti-rootkit

At this stage they realized that anti-malware solutions and internet banking security plugins were making their work more difficult. They then started to focus their efforts on removing security solutions before running the malicious payload in order to increase the chances of a successful execution and to keep running on the infected machine for much longer.

Nothing could be better than using well known command line tools that already have this capability –and most of them are already whitelisted.

  • RegRun Partizan

This tool is a Native Executable which runs on system startup before the Win32 subsystem starts up. It is able to delete files and registry keys even if they are protected by Kernel mode drivers, since it is executed before the drivers are loaded to the system. The commands to be executed are specified on the .RRI file as shown below.

Partizan RRI script containing the list of files to remove

  • The Avenger

A Windows driver designed to remove persistent files and registry keys. The commands to be executed on the system are written to a script that will be read by the driver once it starts.

The Avenger GUI and script to delete security solutions

  • Gmer

Gmer is a well-known rootkit detector and remover with lots of functions to detect rootkit activities on the system as well as delete files by using its own device driver. As it has a command-line interface, it is easy to remove protected files.

BAT file using GMER’s killfile function to remove security solution

More details about banking Trojans using GMER to uninstall security software can be found in a separate blogpost.

Malicious Bootloader

After using anti-rootkits Brazil’s cybercriminals went deeper and started to develop their own bootloaders, tailored exclusively to remove the security solutions from user’s machine. The downloader is in charge of installing the malicious files and then rebooting the machine. After reboot the malicious bootloader can remove the desired files from the system.

Basically, the malware replaces the original NTLDR, the bootloader for Windows NT-based systems up to Windows XP, to a modified version of GRUB.

Modified GRUB loader acting as NTLDR

This loader will read the menu.lst file that points to the malicious files already installed on the system xp-msantivirus and xp-msclean.

Menu.lst file containing the parameters to execute malicious commands

When executed the malware will remove files related to security solutions and then restore the original NTLDR files that were previously renamed to NTLDR.old.

Commands executed to remove security modules and restore the original NTLDR

What we have nowadays

Automation

Most banks were using machine identification to prevent unauthorized attempts to perform operations using the stolen information. To bypass this the bad guys started performing the malicious operations from the infected machine, by using Internet Explorer Automation (formerly OLE automation) to interact with the page content.

The first samples using this type of attack were Browser Helper Objects (BHOs) that could detect a transfer transaction and then change the destination account, sending the money to the attacker instead of the real destination.

Later, the same method was heavily used in Boleto attacks, where they were using automation to get the inputted barcode and then replace it with the fraudulent one.

Since this method only works for Internet Explorer, the malware needs to force the user to access internet banking via that browser. Therefore, it implements a timer which checks if Firefox or Chrome is being used and then kills the process.

Code to avoid use of Chrome and Firefox

When an instance of IE is found, the malware will search for a tab instance in order to be able to read the window text and then to know which URL is being accessed.

Finding the tab handle and obtaining the URL being accessed

Search for target’s specific titles

As the automation will process the page structure, it needs to know if the victim is on the page to input the Boleto information. It installs a handle to the event OnDocumentComplete in order to collect the full URL as soon as it is loaded and then checks if the user is on the target page.

Search for target’s specific pages

After confirming that the user is on the target page, the malware will process the page structure and install a handler to the submit button, then it can take control of the execution right after the user has submitted the page and then process the inputted content.

Search for a specific textbox and get the inputted data

After collecting the inputted data, it can be processed and then changed to the malicious content before submitting the page.

For those samples we could find, string obfuscation, debugger detection and virtual machine detection as well as this method mean they are not as easy to detect as other attacks involving phishing Trojans and hosts.

Code Obfuscation and RunPE

Looking for new ways to bypass detection, Brazilian criminals started using obfuscation in order to hide the parts of code that perform their main operations.

In the code below the coder has encrypted the original code of the function used to download the malicious payload; on a static analysis you cannot figure out what the purpose of this function is.

Encrypted downloader function

In runtime the malware will call the function to decrypt this code prior to executing it.

Decrypt code call

Decryption routine

As we can see in the code above, the decryption is a simple sub operation using the key 0x42 on the encrypted byte – a simple and fast way to hide parts of code.

Decrypted downloader function

In order to avoid detection by a network firewall, the downloaded file is encrypted using its own encryption function.

Encrypted file

Decrypted file

The encryption function is also hidden by using the same method used in the download function – after decrypting the code we can find a XOR-based encryption combined with a shift-right operation on the XOR key.

After decrypting the file, it will not be executed using the normal methods usually found in malicious code. To hide the process on the machine the malware uses a trick known as RunPE where the code will execute a clean process (like iexplorer.exe or explorer.exe) in a suspended state and then modify its memory content to the malicious code and execute.

Code launching clean process as suspended state

After creating the process in a suspended state the code will write the new code to the memory space, set the new EIP for execution and then resume the thread.

Writing malicious code and resuming the thread

Internet explorer process hosting the malicious file

Since the malicious code is running on the memory space allocated to Internet Explorer, using tools like Process Explorer to verify the publisher signature does not work because they check the signature of the process on the disk.

It was clear that they had moved on completely from using beginner’s code to a much more professional development and we realized it was time to update the analysis process for Brazilian malware. We are sure most of this evolution happened due to contact and the exchange of knowledge with other malware scenes, mostly those in Eastern Europe, which we described in this article.

AutoIt Crypto

AutoIt is now often used as a downloader and crypto for the final payload in order to bypass detection. After being compiled the AutoIt script is encrypted and embedded to the generated binary which makes it necessary to extract the original script before analyzing its code.

Looking for a better way to hide the final payload, the Brazilian cybercriminals have developed a new crypto using AutoIt language where the decrypted payload is executed by using a RunPE technique.

AutoIt Crypto execution flow

The crypto uses two different methods to store the encrypted file: the first one is by using the FileInstall function that already exists on AutoIt, and the other one is embedding the file at the end of the binary.

When using the second method the crypto writes a key which is used to mark where the encrypted payload content starts and is then able to find the content to decrypt. On the sample below, the key used is a short version of “Sei que ganharei 20K” which means “I know that I will win R$ 20,000”.

Key used to mark where the encrypted payload starts

AutoIt Crypto main code

After reading the encrypted payload it decrypts the content using the decryption key “VENCIVINICI” and then executes the malicious payload using RunPE.

The decryption function code is not written in AutoIt – it is written in C language. After being compiled the bytes are included in the code as a string and then mapped to memory and executed by using CallWindowProc API.

Decryption function implementation

We found the following algorithms being implemented as the encryption/compression method for this crypto:

  • RC4
  • XXTEA
  • AES
  • LZMA
  • ZLIB

The use of AutoIt for malware development is not something new, but in the middle of 2014 we saw a wave of attacks using AutoIt in Brazil, as we can see on the graph below.

Trojan.Win32.Autoit: number of users attacked in Brazil

MSIL Database

Another type of malware that emerged recently was malware developed in .NET instead of Visual Basic 6.0 and Delphi, following a trend we saw worldwide. It is not hard to find a downloader written in .NET. Anyway, some samples of Trojan-Banker.MSIL.Lanima grabbed our attention when we found some of them were not using functions commonly used to download the payload.

Download function

As we can see in the picture above this samples does not use any download function because it uses SQL Server to host the binary content and then just uses an SQL command to retrieve the content and save to disk.

The strings are encoded with base64 and encrypted with Triple DES algorithm in order to hide the text related to the main actions of the malware.

Decrypt function

This family of malware is very prevalent in Brazil and China:

MSIL Crypto

Following the same method used by AutoIt Crypto the bad guys developed another crypto, this time using .NET language. The process to extract the real executable is almost the same as AutoIt Crypto but it has an intermediate module which is responsible for extracting the final payload.

Looking at the main module we have a .NET code and the main function of this main module is to extract and load the embedded DLL.

.NET Crypto execution flow

Crypto main function

As we can see, the function above will split the binary content by using the separator string “cdpapxalZZZsssAAA” and use the second block which contains the encrypted code of the Loader DLL.

Loader DLL encrypted content

Then it is time to decrypt it by calling the function named “fantasma” (or “ghost” in English), the official name used for this crypto in the forums is PolyRevDecrypt which is basically an XOR operation between the encrypted byte, the last byte of the encrypted buffer and one byte of the password provided to the function.

Decryption function

After being decrypted, the code will be loaded and executed by the function “docinho” (or “candy” in English).

Function to load and execute the DLL

The code of the library is almost the same as the main executable except that now it will use the second block of the split content.

Loader DLL main function

RAT

In a bid to reduce the losses related to cyber attacks, banks implemented two-factor authentication using a hardware token and SMS token for online banking transactions in addition to the solutions already in place like machine identification. To solve this problem the cybercriminals have created a remote administration tool specially developed to request the information required to process internet banking transactions.

RAT execution flow

The browser watcher will monitor the user browser and see if any of the target banks are accessed; if they are, it will decompress and execute the RAT Client and notify the C&C about the new infection.

Internet banking access monitoring

The strings used by this malware are encrypted using their own encryption routine. After decrypting it we are able to identify the targets as well as the important parts of the code.

Decrypted strings

For this type of infection it is common for the bad guys to create a way to manage the attacks. Here we can see the number of computers infected on the same day, keeping in mind that this number means the amount of users that have accessed internet banking while the malware was running on their computer.

C&C panel showing the list of infected users

The RAT Client will connect to the server to alert the attacker that a new victim is accessing the internet banking system. It is then possible to execute the attack in real time.

RAT Server showing a new victim is connected

At this stage the attacker just needs to wait for the user to login and then proceed with the attack. When the user is already logged in, the attacker can see the user screen, lock it and control the execution as well as ask for specific information that will help him to steal the account, like:

  • Token
  • Access card code
  • Date of birth
  • Account password
  • Internet banking password
  • Electronic signature

To prevent the user from seeing that the computer is being remotely controlled, this RAT has a function that simulates an update for the bank security plugin showing a progress bar and disabling all user interactions. Meanwhile, the attacker can perform the banking operations by using the active browser section because the overlay screen is not shown to the attacker.

Lock screen simulating an update

If some information is requested to confirm the transaction, e.g. SMS token, the attacker can ask the victim who will think the information is necessary in order to proceed with the update process.

Screen asking for token code

As soon as the user provides the information, the attacker can enter it on the internet banking screen, bypassing the 2FA used in the transaction.

Information received from the victim

Ransomware

Brazilian cybercriminals not only work with banking malware – they are also exploring other types of attacks involving ransomware. Some years ago, we found TorLocker which contains details inside the malware code suggesting that the developer is from Brazil.

Code containing some strings suggesting the author is from Brazil

As we can see in the image above, we found the sentence highlighted in blue: “Filho de Umbanda não cai!” (“Umbanda’s son never falls down”). Umbanda is an unorthodox religion in Brazil. The name marked in red is the nickname of the author and it also uses the extension .d74 for the encrypted files. This user is very active on underground forums looking for malicious services in Brazil.

We also found other references, like the use of a service in Brazil to get the victim IP in order to notify about an infection.

Request to a Brazilian service to obtain the victim IP

Some months ago, we found another ransomware program based on the Hidden Tear source code that was modified to target Brazilian users, differing from the initial program that was found targeting English- and Japanese-speaking users.

Victim’s machine showing messages in Portuguese, asking to pay in order to receive the files

Why they evolve

We have sufficient evidence that Brazilian criminals are cooperating with the Eastern European gangs involved with ZeuS, SpyEye and other malware created in the region. This collaboration directly affects the quality and threat level of local Brazilian malware, as its authors are adding new techniques to their creations and getting inspiration to copy some of the features used in the malware originating from Eastern Europe. Brazilian cybercriminals are not only developing the quality of their code but also using the cybercrime infrastructure from abroad.

We saw the first sign of this ‘partnership’ in the development of malware using malicious PAC scripts. This technique was heavily exploited by Brazilian malware starting in 2011 and was later adopted by Russian banking Trojan Capper. This cooperation continued as Brazilian criminals started to use the infrastructure of banking Trojans from Eastern Europe – the Trojan-Downloader.Win32.Crishi was the first to use DGA domains hosted at bulletproof companies from Ukraine. Also the Boleto malware adopted the massive usage of fast flux domains, aiming to avoid the takedown of C2s – we saw that with the “bagaça” (bagasse in Portuguese) domains, registered using anonymous services, which hosted crimeware and boleto stuff and was resolving different IPs for every request.

The “bagaça” domains: fast flux and bulletproof from Eastern Europe

Other strong signs of their cooperation are the constant presence of Brazilian cybercriminals on Russian or Eastern European underground forums. It’s not unusual to find Brazilian criminals on Russian underground forums looking for samples, buying new crimeware and ATM/PoS malware, or negotiating and offering their services. The results of this cooperation can be seen in the development of new techniques adopted in Brazilian malware.

The Brazilian malicious author of TorLocker negotiating in a Russian underground forum

These facts show how Brazilian cybercriminals are adopting new techniques as a result of collaboration with their European counterparts. We believe this is only the tip of the iceberg, as this kind of exchange tends to increase over the years as Brazilian crime develops and looks for new ways to attack businesses and regular people.

Conclusion

Cybercrime in Brazil has changed drastically in the last few years, as it shifted from simple keyloggers built from public source code to tailored remote administration tools that can run a complete attack by using the victim machine.

Malware that used to show a phishing screen as soon as it was executed is now completely reactive and waits for a valid session in order to start the job.

That means that the criminals are investing much more money and time in order to develop their malicious code, enhancing anti-debugging techniques and then running the malware undetected for much longer.

As we know, they are in touch with cybercriminals from Eastern Europe, mainly Russians, where they exchange information, malware source code and services that will be used in Brazilian attacks. We can see that many of the attacks used in Brazil were first seen in Russian malware as well as Brazilian techniques later being used in Russian attacks.

Based on that, we can expect to find Brazilian malware with enhanced code obfuscations, anti-debugging tricks, encryption algorithms and secure communications making our work much harder than now.

PNG Embedded – Malicious payload hidden in a PNG file

Thu, 03/24/2016 - 05:56

One of the most complex tasks for the cybercriminals is to ensure their malicious code goes undetected by antivirus and achieves its goal. For this, they have invested a lot on more complex infection processes, going beyond the traditional phishing and using techniques where the malicious payload is hidden in encrypted files – even using a known file format. This is what we found in a new Brazilian Trojan in the wild: it tries to conceal the malicious files in a PNG image. And the attack starts with a simple phishing PDF.

Malware distribution

It looks like Brazilian cybercriminals follow the security news – this type of attack was publicized several months ago in the US and now they are using the same method in Brazil. The phishing aspect used in this campaign distributes a PDF attached to the email. The file is clean. The type of attack is the same as that used to distribute an executable file or a .ZIP file containing the .pdf extension in the filename.

The attached PDF contains a text commonly used in mail content, while the link (see screenshot below) directs the user to the malicious file.

Closer inspection of the PDF content reveals the malicious link as well as the URL of the tool used to generate the PDF from HTML content.

The malicious payload

The link prompts us to download a malicious JAR which downloads a ZIP file containing other files. Among those files we found three without any extension, but containing a PNG (Portable Network Graphics) file header – a common image format. Usually the header shows the file type that will be used in order to open the file. Something similar to this was discovered some years ago in BMP files.

Looking at the file we can see that it is a solid color image of 63 x 48 pixels, but with a file size of 1.33 MB, which is too big for this specific image. Analyzing the binary that performs some operations on these files we identified the function that loads the PNG files to the memory:

This function is responsible for loading the PNG file to memory, decrypting and executing the extracted binary using a technique known as RunPE, where the malicious code is executed in the context of another process, in this case iexplore.exe.

From this code we could identify that the PNG file was only 179 bytes (0xB3) – the remaining content is the encrypted malicious file.

Based on this we managed to write a script to decrypt the content of the PNG files.

By giving the key that can be found in the malware code we can successfully decrypt the files.

Conclusion

Brazilian attacks are evolving day-by-day, becoming more complex and efficient. It is there necessary to be wary of emails from unknown sources, especially those containing links and attached files.

Since the malicious payload hosted in the PNG file cannot be executed without its launcher, it cannot be used as the main infector; that is usually delivered to your mailbox, so it has to be installed by a different module.

This technique allows the criminals to successfully hide the binary inside a file that appears to be a PNG image. It also makes the analysis process harder for antivirus companies as well as bypassing the automated process to detect malicious files on hosting servers.

The files related to this attack are detected by Kaspersky Lab products as:

Trojan.Win32.KillAv.ovo
HEUR:Trojan.Win32.Generic
Trojan-Downloader.Win32.Banload.cxmj
Trojan-Downloader.Win32.Agent.hgpf
HEUR:Trojan-Downloader.Java.Generic

The URLs related to this attack are also blocked by Kaspersky Lab products.

Hospitals are under attack in 2016

Thu, 03/24/2016 - 04:52

The year 2016 started with a quite a number of security incidents related to hacks of hospitals and medical equipment. They include a ransomware attack on a Los Angeles hospital, the same in two German hospitals, a case of researchers hacking a patient monitor and drug dispense system, an attack on a Melbourne hospital and so on – in just two months of 2016! This should be a real concern for the security industry.

This is not a surprise actually. The industry of Internet of things is on the rise; and, of course, the medical devices industry is one of the biggest concerns in terms of security. Modern medical devices are fully-functional computers that have an operating system and applications installed on them; and most of these devices have a communication channel to the Internet, external networks and different types of custom cloud base servers. These devices are full of sophisticated state-of-art technologies made for one goal – to help doctors treat their patients at the highest level possible. But like all other industrial systems, they are built with a focus on these technologies – to be precise, to be helpful in terms of medical science, but putting security aspects in second or even third place. And this is a quite a concern right now. Program design architecture vulnerabilities, unsecured authorization, unencrypted communication channels and finally critical bugs in software – all this leads to potential compromises.

Unauthorized access to these devices could have serious effects: it could lead not only to theft of personal data – important as it is – but it could directly affect the health, or even the lives, of the patients. Sometimes it’s really scary how simple it is to hack into the hospital, stealing personal information from a medical device or getting access to this device with the possibility of obtaining access to file system, user interface, etc. Imagine a scenario – one that could be called a truly “targeted attack” – whereby cybercriminals with full access to the medical infrastructure at a specific facility can manipulate the results of diagnosis or treatment systems. Because doctors in some cases will depend heavily on these sophisticated medical systems, such manipulation could result in the wrong treatment being given to a patient, worsening his or her medical condition.

In the research that I showed at the Kaspersky Security Analysts Summit, I presented an example of how easy it was to find a hospital, get access to its internal networks and finally gain a control of an MRI device – locating personal data about patients, their personal information, treatment procedures and then getting access to the MRI device file system. The problem is not only one of weak protection of medical equipment, it has a much wider scope – the whole IT infrastructure of modern hospitals is not properly organized and protected, and the problem persists worldwide.

Let’s see how cybercriminals could perform their attacks. I highlighted three major flaws that I see when speaking about proper protection of a medical facility:

First of all – exposure to the Internet with weak or even no authorization at all.

There are a number of ways to find vulnerable devices, for example using the Shodan search engine. Using proper requests to Shodan you can find thousands of medical devices exposed to the Internet: a hacker could discover MRI scanners, cardiology equipment, radioactive medical and other related equipment connected to the Internet. A lot of these devices still operate under the Windows XP OS and have dozens of old, unpatched vulnerabilities that could lead to the full compromise of a remote system. Moreover, in some cases these devices have unchanged default passwords that could easily be found in manuals published on the Internet.

Shodan search results

When I was performing my research and penetration testing on a real hospital, I found a few devices connected to Internet, but they were protected quite well: no default passwords, no vulnerabilities in web control interfaces, etc. But even if the facility is protected from the Internet-side, it won’t stop a cybercriminal from looking for other methods to break in if his goal is to get access no matter what.

And here’s the second flaw – devices are not protected from being accessed from local networks.

In my case I just drove to the hospital location and discovered a number of Wi-Fi access points belonging to the hospital. One of them had a weak Wi-Fi password that I was able to crack within two hours. With this password I was able to get access to the internal hospital network; and I found the same medical equipment I previously discovered on the Internet, but with one major difference – now I was able to connect to them because the local network was a trusted network for them. Manufacturers of medical devices, when creating a whole system, protect them from external access. But for some reason they thought that if someone tries to access them internally – it’s trusted by default. This is radically wrong – do not rely on local system administrators and how they organize the internal network protection of a hospital.

This is where the third flaw comes in – vulnerabilities in software architecture.

When I connected to a device and passed through the default login screen, I immediately got access to the control interface and personal data and diagnosis information about hospital patients. But this is not what attracted my attention. There was a command shell implemented in the user interface giving me access to the file system on the device.

Patient MRI result

In my opinion, it’s a major vulnerability in the application design – even if there was no remote access at all, why would software engineers take this opportunity to provide command shell access to the doctor’s interface? It definitely should not be there by default. This is what I was talking about at the beginning. You can provide good protection from one side, but you can completely fail to pay attention to others; and someone who is planning an attack will likely discover something like this and will compromise the whole device.

The other concern about application vulnerabilities is of course outdated versions of operating systems and patch management difficulties. This is a completely different environment from the standard IT infrastructure for PCs or mobile devices; you cannot simply release a patch for a vulnerability and then upload it to medical devices. It’s a complex manual process and in many cases a qualified engineer is needed on the hospital site to perform a system upgrade and to test that the devices are working properly after the update. That takes time and money, so it’s essential to create a protected system from the very beginning – at the development stage – with as few application vulnerabilities as possible.

The vendors of medical equipment and hospital IT teams should pay close attention to the topic of medical cyber-security; they are now on the list of valuable targets in the cybercriminal underground. We will see a growing number of attacks on medical facilities in the year ahead, including targeted attacks, ransomware infections, DDoS, and even attacks to physically damage medical devices. And finally, the industry has started to pay attention – for example the U.S. Food and Drug Administration (FDA) issued guidance outlining important steps medical device manufacturers should take to continually address cyber-security risks to keep patients safe and to better protect the public health.

I would like to give some recommendations to the local IT personnel working in hospitals:

  • Be aware that cybercriminals are now targeting medical facilities, read about these incidents and try to figure out if the attack methods could affect your own infrastructure.
  • Stick as close to the implemented IT security policies as possible, and develop timely patch management and vulnerability assessment policies as well.
  • Focus not only on protecting your infrastructure from outside threats such as malware and hacker attacks but also on maintaining strict control over what’s going on inside your local network, who has access to what, and any other things that could lead to local systems being compromised.

Thank you, CanSecWest16!

Mon, 03/21/2016 - 15:00

This year, we had the absolute pleasure of being a part of CanSecWest’s fantastic lineup of talks, well-rewarded pwnage, and entertainment among a jovial crowd of infosec practitioners of every stripe. The diversity of the crowd really cannot be overstated as your usual network defenders, hardware and software developers, threat intelligencers (like ourselves) are peppered in with a fair amount of exploit developers sizing up their competition. This year’s Pwn2Own awarded a whopping $460,000 to four out of five teams for successful exploitations of Google Chrome, Microsoft Edge, and Apple Safari browsers. Of these, Tencent Security’s Team Sniper took the lead and the title of ‘Master of Pwn’ embroidered in a pretty sweet purple smoking jacket. We only wished someone would have mastered the always difficult “VM escape”.

The mix of talks was heavily skewed towards exploitation with some very interesting vulnerabilities discussed like Haifei Li and Chong Xu’s talk on Microsoft Outlook security. This talk should’ve scared the pants off of anyone in the crowd as Haifei demoed his now patched BadWinMail exploit that allowed the mere preview of an email on outlook to pop calc.exe. This is the sort of exploit that reminds us that all of the tips and explanations we give end users don’t carry that much weight in the face of a truly advanced attacker with a sense of creativity. There were no links clicked or attachments executed, in some cases (if the malicious email is the latest received when Outlook is first run) the application will preview the malicious email without user interaction required. Zooming out a little bit, we should consider that even though many threat actors are moving away from fancy exploits (finding that inexpensive phishing or macro-laced documents provide good enough results), this is the sort of exploit that the 1% threat actors absolutely love. So perhaps the immediate takeaway should be: “Why the hell isn’t Outlook sandboxed?”

While the majority of the talks focused heavily on exploitation and vulnerabilities, our talk dealt with the usage of false flags and deception techniques by well-known (and some unknown) APT actors. We were skeptical we could hold a full crowd given the skew towards vuln-centric talks, but were pleasantly surprised by the turnout and the warm reception. As we took the crowd through a brief overview of attribution, pitfalls encountered, and techniques being utilized by the bad guys, it was clear to us this topic has not received enough attention in the community. The questions asked during and after the presentation focused mainly on opinions as to whether or not attribution is even needed in the grand scheme of things. While we don’t want to give away our secret sauce just yet (as this is an ongoing project), some of the actors we focused on included Cloud Atlas (AKA Inception Framework), Turla, Lazarus, Sofacy, big bad Duqu, and perhaps a new player. Stay tuned for a very thorough treatment of this topic.

CanSecWest has become a true favorite with GReAT researchers for its welcoming atmosphere and diverse but friendly crowd open to new research topics and hard discussions on ongoing problems. It’s rare to find such a great mix of people from all walks at a conference that isn’t so large or overly commercial. We are looking forward to CSW 2017! Won’t you join us?

Who viewed you Instagram account? And who stole your password?

Mon, 03/21/2016 - 09:33

Introduction

Mobile applications have become one of the most efficient attack vectors, and one of the favorite methods of cybercriminals is the abuse of popular applications. Maybe you would think twice before installing any application that asks for the credentials you use to connect to your social networks, email accounts or cloud storage services?

Recently, a malicious application called “InstaCare – Who cares with me” was released via Google Play Store and App Store. David Layer-Reiss from Peppersoft, a mobile development company from Germany who discovered this threat, provided a good analysis on his blog.

This application serves as a hook to lure Instagram users, pretending to let them know who has viewed their profile; but in reality it abuses the authentication process to connect to Instagram.

In fact, it’s common for many applications to use API’s or authorization protocols such as OAuth to authenticate with third-party applications. This is very convenient for users as they can use the same credentials to authenticate with different applications and services.

The problem here is that this feature can be used maliciously for some applications to gain access to the user’s information, such as their profile and contacts, or to steal their credentials.

This isn’t the first time that this has happened. Last year we published some blog posts outlining where attackers had used malicious applications or email campaigns. Either to steal the user’s credentials – Stealing to the sound of music; or just to get access to user information – Fraudsters can have rights, too; sometimes using popular applications as a cover – Del phishing al acceso persistente (Spanish).

This kind of strategy is very successful. In this particular case, the Android version of this application alone was installed on more than 100K devices with more than 20K reviews, most of them saying that you have to pay in order for it to work correctly.

As with Google Play, we can also find some users in the App Store complaining about problems after installing this app.

It is interesting that this application was able to pass the Apple security checks and was published without any problem, even though its controls are more restrictive, without mentioning that apparently this developer already had a history of having published a malicious application before.

Attack vector

This attack installs JavaScript code into the Submit button on the Instagram login page as soon as the page has finished loading.

This code gets the content of the input fields named “username” and “password” and stores it in the local variable named “str” with the pattern “<username>,-UPPA-,<password>”. After that, it calls the function “processHTML” which stores the collected data in a class variable.

Other information is also collected from the user’s device and sent to the C&C via a POST request.

The value of the parameter “hash” is the data shown in the image above plus the Instagram username and password. This value is encrypted with AES 128 and then encoded with base64. The encryption key is generated from the ID generated by the server.

The iOS version also uses AES 128 but the block cipher mode used is CBC instead of ECB.

Consequently, it uses as Initialization Vector (IV) the string “IOS123SECRETKEYS”.

Once opened it forces the user to login to Instagram.

After that the username and password are sent to the server, as well as some metadata.

Since we have the ID, we can decrypt the content by using a modified version of the Java code published by David. We just need to modify the crypto class initialization

By inputting the content of the “hash” parameter, we can decrypt the data send and find out with information has been sent to the server. As expected, the Instagram username and password is also included in this list.

The username and password will later be used to post spam messages to the user’s Instagram account.

The threats mentioned in this blog post are detected by Kaspersky Lab products as HEUR:Trojan-Spy.AndroidOS.Instealy.a and HEUR:Trojan-Spy.IphoneOS.Instealy.a.

Conclusion

Mobile environments are one of the best targets for cybercriminals; they usually have access to email accounts, social networks, contacts and even the places you have visited.

The use of social networking is one of the best ways to distribute malicious content. We have to be aware of unknown applications that promise something that isn’t provided by the service that we are using. Usually, if the feature does not exist on the service website, it will be hard for third-party software to provide it.

All your creds are belong to us

Tue, 03/15/2016 - 06:59

 Download the full report (PDF)

With astonishing annual revenues of over a hundred billion dollars, the gaming industry has in the past been compared to Hollywood’s burgeoning business, repeatedly demonstrating the influence behind its ever expanding and loyal fan base. Having an endless list of “big hit” video-games coexisting peacefully with humble but still fun-filled “indie” productions makes digital platforms not just a convenient means of purchasing new games, but also a fair one.

With over 140 million registered users and more than seven thousand games available for download, Valve’s multi-OS digital distribution platform, Steam, offers a myriad of possibilities for gamers. This includes the latest games from an always-on cloud-environment, as well as an ever-growing community of like-minded enthusiasts. Steam experiences steady growth in the number of active users registered on the platform, many of them using a credit card to buy content; willingly providing personal information and exchanging items with other network participants via in-game trades or traditional auctions. Security research has tragically ignored gaming malware in the mistaken assumption that nothing of any real value is traded there. This blind spot is being abused by cybercriminals to steal money and affect real damage!

It’s all fun and games until someone’s account gets hijacked

Organized criminal crews from all over Eastern Europe have been paying close attention to Steam’s growing user base and the security techniques and procedures offered to users by the company; waiting patiently for their opportunity. As in the majority of social networks, many profiles don’t reveal their true nature, hiding personal details and payment information behind a carefully crafted identity or digital persona; or, as Jung would put it: “A kind of mask, designed on the one hand to make a definite impression upon others, and on the other to conceal the true nature of the individual.” However, what happens when that mask unexpectedly slips? When your account and all its related, sensitive information stored becomes the ill-gotten gains of an unknown third party? Surprisingly, this nightmare turns to reality for almost 77 thousand unsuspecting users every month, according to Steam’s own statistics. Estimating the financial impact, however, is quite difficult, given that Steam is not obliged to make this information public. While several community websites exist (such as SteamSpy or SteamCompanion) to calculate how much money you have spent on your account, we couldn’t find a single one that kept historical records in order to calculate an average value. An educated guess based on available password dumps makes the value for the credentials a mere $15 USD on the black market.

However, that’s just for accessing the victim’s profile; what the bad guys do afterwards could yield even higher gains, depending on the user.

A characteristic stealer that claimed to “revolutionize” the Steam Item Stealing Industry, its website has been offline for a while now and its Twitter account is basically dead. Yet, its legacy carries on with the malware still being distributed in the wild.

Even though phishing and spear-phishing attacks are always popular among the most active social engineers in the dark corners of the Internet, a new breed of malware, known innocently as a “Steam Stealer” is the prime suspect in the pilfering of numerous user accounts from Valve’s flagship platform. Evolving bit-by-bit from a leaked source on a remote Russian forum, stealers took off once they were proven to be extremely profitable by criminals all around the globe. Available for sale in different versions, with distinct features, free upgrades, user manuals, custom advice for their distribution, and more, stealers have turned the threat landscape for the entertainment ecosystem into a devil’s playground.

An almost perfectly-cloned website for the gaming messenger Razer Comms, which, together with TeamSpeak is one of the most popular baits used by cybercriminals.

One of the reasons behind the growth of specific malware targeting gamers has been the simplicity behind its operation and the ubiquity of its offering. The focus on selling stealers to anyone with money to spend means that a staggering number of script-kiddies and technically-challenged individuals resort to this type of threat as their malware of choice to enter the cybercrime scene.

Everything in one simple package, ready to use and with plenty of documentation for its use. Different functionality is offered as part of each Steam Stealer package, starting from $15 USD.

Adding new features is simple. The average developer just needs to select their favorite programming language and know just enough about Steam’s client design and protocol. There are many APIs and libraries available that interface seamlessly with the Steam platform, significantly reducing the effort required. It’s not uncommon for the bad guys to repurpose legitimate tools and open source libraries for their nefarious campaigns, although in this case the possibilities are just too tempting to pass on to others.

A starting price of 200 rubles ($3 USD) would get you usage rights for a credential stealer for the Steam platform. Paying 450 rubles ($7 USD), would add source code and a user manual.

Every step of the process, from the initial malware distribution to obtaining a profit after the infection is completed, is documented in one of several guides available online (at a cost, of course). In this business model everything has a price and every individual goes above and beyond to make their offer more attractive to potential customers. Malware-as-a-service is not a revolutionary practice. However, when it comes to these types of malicious campaigns we usually see prices starting in the range of $500 dollars (taking as a reference earlier ransomware-as-a-service markets).

A strong focus on Marketing is evident in the “stealing industry”.

With Steam Stealers, a ludicrously low price is usually asked of wannabe criminals for the use of the malware. For an extra cost, the full source code and a user manual is included in the package, making this scheme laughable and terrifying at the same time. Of course, the aforementioned prices represent the low end of the “industry” spectrum, but it would be hard to find any stealer being sold for more than $30 dollars. With so much competition in this niche market, it’s tough making a living as a stealer-seller without daring to go the extra mile.

Past and current trends

Reviewing how Steam Stealers have evolved from “simple” malware to flooding all corners of the Internet, we can assume that this is indeed a booming business.

In the past, there was no obfuscation whatsoever, and sometimes FTP or SMTP credentials were sent over in plain text. Gradually, improvements were introduced to the stealers as well as to the social-engineering aspect: screenshots got better, duplicate sites improved, delivery methods were more diverse and bots got better in mimicking human behavior.

A short rundown of past trends:

  • Use of obfuscators to make analysis and detection harder.
  • Use of file extensions hidden by default by Windows (fake ‘screensaver’ files).
  • Use of NetSupport added (providing remote access to the attacker).
  • Use of fake TeamSpeak servers.
  • Use of automatic Captcha bypass (DeathByCaptcha and others).
  • Use of fake game servers (Counter-Strike: Global Offensive most notably).
  • Use of Pastebin to fetch the actual Steam Stealer.
  • Use of fake screenshot sites impersonating Imgur, LightShot or SavePic.
  • Use of fake voice software impersonating TeamSpeak, RazerComms and others.
  • Use of URL shortening services like bit.ly.
  • Use of Dropbox, Google Docs, Copy.com and others to host the malware.

Current trends are as follows:

  • Use of fake Chrome extensions or JavaScript, scamming via gambling websites.
  • Use of fake gambling sites, including fake deposit bots.
  • Use of AutoIT wrappers to make analysis and detection harder.
  • Use of RATs (Remote Access Trojans) such as NanoCore or DarkComet.

This list may grow, as 2016 has only just begun.

 Download the full report (PDF)

The Steam Stealing industry in numbers

The statistics included in the following section reflect the period between January 1st 2015 and January 1st 2016, concentrating on the most prevalent malware families for Steam Stealers. However, since many detections are made by heuristics or different generic verdicts, the problem is actually much worse and it is hard to get an exact measure. The percentage of infected users is calculated only for countries with over 1,000 detections in the specified period (baseline).

Statistics for Trojan-Downloader.MSIL.Steamilik

Trojan-Downloader.MSIL.Steamilik geography

Trojan-Downloader.MSIL.Steamilik, % of infected users

Trojan-Downloaders can download and install new malicious programs onto the user’s computer – including other Trojans, or the ever annoying adware. This two-stage infection process allows the bad guys to modularize their components and create an initial downloader with reduced functionality which can then gather the malicious contents once the environment has proved worthy.

Statistics for Trojan.MSIL.Steamilik

Trojan.MSIL.Steamilik geography

Trojan.MSIL.Steamilik, % of infected users

This broad category of Trojans contains all malicious programs that perform actions that have not been authorized by the user, such as reading information form the registry key and copying files from the system in order to send them to a command a control server owned by the cybercriminal. It’s worth noting the MSIL sub-category which represents a .NET assembly. The rise of Trojans and the increased use of Microsoft’s flagship development framework go hand in hand, making the lives of all developers (including those with a not so white hat) easier.

Statistics for Trojan-PSW.MSIL.Steam

Trojan-PSW.MSIL.Steam geography

Trojan-PSW.MSIL.Steam, % of infected users

Trojan-PSW programs are designed to steal user account information such as logins and passwords from infected computers. PSW or Password Stealing Ware, when launched, searches specific files which store a range of confidential data or crawl the registry for specific keys. If such data is found, the Trojan sends it to its “master.” Email, FTP, HTTP (including data in a request), or other methods may be used to transmit the stolen data. Brazil caught our attention by taking the second place in this malware category after the Russian Federation. Latin America is certainly a growing malware ecosystem and gamers are not forgotten.

With an extensive range of obfuscators used to protect their intellectual property, together with a decline in detection by security solutions, cybercriminals resort to open source projects such as ‘ConfuserEx’ (the successor of the infamous Confuser project) or even commercially available obfuscators for the .NET Framework such as SmartAssembly. For calculating the previous statistics regarding obfuscators, a group of over 1,200 samples collected via different means was used. All the hash values for this collection will be uploaded to our publicly available IOC repository.

Valve’s counter-measures

Valve has acknowledged the problem, but even if there has been a progressive improvement in the number of protective measures implemented, Steam Stealers are still rampant and many users will at some point find themselves wondering what went wrong. Among the new security measures there are several that have been adopted network-wide and others which you can easily configure for your account to prevent this type of incident and enjoy a secure gaming session:

  • Two-factor authentication either by email or mobile application.
  • Blocking URL’s throughout Steam.
  • Nickname censorship (Steam/Valve).
  • Captcha on trades (briefly), and then bypassed.
  • Limited accounts introduced.
  • Steam e-mail confirmations for utilizing the market and trading items.
  • Verifying e-mail address.
  • $5 USD purchase to combat ‘free abuse’ accounts (expanded on limited accounts).
  • Information about who you are trading with (record).
  • Market will become blocked when logging in from new devices, changing your profile password etc.
  • Steam mobile trade confirmations.
  • Steam account recovery via phone number.
  • Restrict chat from users who do not share a friends, game server, or multi-user chat relationship with you.
  • More restrictive block referral of spam and scam sites.
  • Trade hold duration (15 days).

In terms of preventive measures, we recommend users familiarize themselves with Steam’s updates and new security features, and enable two-factor authentication via Steam Guard as a bare minimum. Bear in mind that propagation is mainly (but not solely) done either via fake cloned websites distributing the malware, or through a social engineering approach with direct messages to the victim. Always have your security solution up to date and never disable it; most products nowadays have a “gaming mode” which will let you enjoy your games without getting any notifications until you are done playing. We have listed all the options Steam offers users to protect their accounts. Remember that cybercriminals aim for numbers and if it’s too much trouble they’ll move on to the next target. Follow these simple recommendations and you will avoid becoming the low hanging fruit.

And if you think the current state of steam stealers is bad, we get the shivers imagining what we will face after Gaben releases Half Life 3. Stay safe, game on, and enjoy Steam!

PlugX malware: A good hacker is an apologetic hacker

Thu, 03/10/2016 - 06:59

It happens that malware writers and other miscreants in the digital world put messages in their malware. Sometimes they do it just for the “lulz”, sometimes to insult a person who hampers their criminal business, sometimes to deliver information to the guys on the other side who oppose them. We hope the case described in this blogpost falls into the first category, i.e. funny message. At least it seemed funny for us.

Our first research into PlugX was published in 2012 – since then this remote access tool (RAT) has become a well-known instrument used in a series of attacks all over the globe targeting multiple industry verticals. PlugX has been detected in targeted attacks not only against military, government or political organizations but also against more or less ordinary companies. In 2013, we discovered that the Winnti group responsible for attacking companies in the online gaming industry has been using the PlugX remote administration tool since at least May 2012.

This time, looking through some anomalous PlugX samples, we stumbled upon one specimen that had an RC4 encoded resource inside. Actually, it turned out to be a test sample with dummy settings. Luckily, it was quite easy to find the initial builder that generates such samples.

PlugX builder

Basically, the builder compiles a handful of different PlugX droppers, including the notorious SFX RAR archives containing the PlugX trinity – a legitimate signed executable susceptible to a DLL side-loading attack, a DLL that is picked up by an executable and the payload file that maintains all the juicy stuff – the PlugX functional library, C2s and other settings.

One such trinity includes Lenovo’s RGB LCD Display Utility for ThinkPad: tplcdclr.exe, wtsapi32.dll (loaded by the application) and the “payload” file wts.chm (loaded by the DLL).

First PlugX trinity from the builder

Legitimate executable from the first PlugX trinity

Another set of three includes a signed version of Steve Gibson’s Domain Name System Benchmarking Utility sep_NE.exe, the winmm.dll file, which the application is dependent on, and the “payload” file sep_NE.slf.

Second PlugX trinity from the builder

Legitimate executable from the second PlugX trinity

But among all the droppers that the builder generates there are two templates posing as executables, with the data maintained usually in a separate “payload” file, embedded in the initial body of the file as a resource.

Encrypted “payload” stuff as a resource in the dropper

The “payload” stuff is kept in encrypted form in the file body. After decryption, this stuff looks like one of the usual PlugX “payload” files, those with easily recognizable shellcode at the beginning:

Decrypted “payload” stuff

The algorithm used to encrypt the payload resource is RC4. And finally (and this is what impelled us to write this blogpost) – the RC4 key for the resource decryption – “SORRY.i_have_to_do_this“.

Apologetic RC4 key

Hmm, interesting… That’s not the message one might expect to find in APT malware that has swamped almost every vertical in nearly every corner of the world. There have been investigations into the infamous PlugX developer in the past. We also have found a number of malware families that are related in some way to PlugX and have likely been developed by the same person. All together it seems that this person has been quite busy in generating malware for different Chinese-speaking APT groups for a long time. That’s obviously a job, already work with no room for sentiment. That’s why the text looks inappropriate here. Unless the malware writer was in a playful mood and had put this in for trolling.

There’s a second option that occurs. Since this is a dropper feature, the dropper for the PlugX could have been developed by another person, not the PlugX developer. In an ordinary cybercriminal hierarchy there are, for example, developers of a bot, ransomware, etc. and packers who create wrappers/droppers to try and allow the core malware to evade AV detection.

Probably some other person, who is not yet such a veteran in the Chinese-speaking APT world and still sees the malware writing practice as some sort of game, was just kidding around.

If you use your imagination, we’re sure you’ll be able to come to your own interesting or quirky conclusions as to how that message ended up in these PlugX droppers. In any case, we really hope this was a bit of fun and not a cry for help from some desperate person forced by circumstances to do bad things.

We detect samples generated by the builder and the builder itself with following modifications of the Gulpix family:
Backdoor.Win32.Gulpix.ajp
Backdoor.Win32.Gulpix.ams
Backdoor.Win32.Gulpix.axe
Backdoor.Win32.Gulpix.axf
Backdoor.Win32.Gulpix.axg
Backdoor.Win32.Gulpix.axi
Backdoor.Win32.Gulpix.axj
Backdoor.Win32.Gulpix.axm
Backdoor.Win32.Gulpix.axn
Backdoor.Win32.Gulpix.axo

And two heuristic verdicts:
HEUR:Trojan.Win32.Generic
HEUR:Trojan.Win32.Invader

The builder MD5 hash is e57691e4f220845df27806563c7dca0b.

Legitimate executables included in PlugX trinities mentioned in the blog-post:
ce2ae795117e54ca8403f86e7a3e19a7 – DNS Benchmark Utility;
d9978f95ce30e85943efb52c9c7d731b – Lenovo’s ThinkPad Display Utility tplcdclr.exe.