Malware Alerts

Subscribe to Malware Alerts feed Malware Alerts
Online headquarters of Kaspersky Lab security experts.
Updated: 1 week 4 days ago

The return of Mamba ransomware

Wed, 08/09/2017 - 10:00

At the end of 2016, there was a major attack against San Francisco’s Municipal Transportation Agency. The attack was done using Mamba ransomware. This ransomware uses a legitimate utility called DiskCryptor for full disk encryption. This month, we noted that the group behind this ransomware has resumed their attacks against corporations.

Attack Geography

We are currently observing attacks against corporations that are located in:

  • Brazil
  • Saudi Arabia
Attack Vector

As usual, this group gains access to an organization’s network and uses the psexec utility to execute the ransomware. Also, it is important to mention that for each machine in the victim’s network, the threat executor generates a password for the DiskCryptor utility. This password is passed via command line arguments to the ransomware dropper.

Example of malware execution

Technical Analysis

In a nutshell, the malicious activity can be separated into two stages:

Stage 1 (Preparation):

  • Create folder “C:\xampp\http
  • Drop DiskCryptor components into the folder
  • Install DiskCryptor driver
  • Register system service called DefragmentService
  • Reboot victim machine

Stage 2 (Encryption):

  • Setup bootloader to MBR and encrypt disk partitions using DiskCryptor software
  • Clean up
  • Reboot victim machine
Stage 1 (Preparation)

As the trojan uses the DiskCryptor utility, the first stage deals with installing this tool on a victim machine. The malicious dropper stores DiskCryptor’s modules in their own resources.

DiskCryptor modules

Depending on OS information, the malware is able to choose between 32- or 64-bit DiskCryptor modules. The necessary modules will be dropped into the “C:\xampp\http” folder.

The malware drops the necessary modules

After that, it launches the dropped DiskCryptor installer.

The call of the DiskCryptor installer

When DiskCryptor is installed, the malware creates a service that has SERVICE_ALL_ACCESS and SERVICE_AUTO_START parameters.

The creation of the malicious service’s function

The last step of Stage 1 is to reboot the system.

Force reboot function

Stage 2 (Encryption)

Using the DiskCryptor software, the malware sets up a new bootloader to MBR.

The call for setting up a bootloader to MBR

The bootloader contains the ransom message for the victim.

Ransomware note

After the bootloader is set, disk partitions would be encrypted using a password, previously specified as a command line argument for the dropper.

The call tree of encryption processes

When the encryption ends, the system will be rebooted, and a victim will see a ransom note on the screen.

Ransom notes

Kaspersky Lab products detect this threat with the help of the System Watcher component with the following verdict: PDM:Trojan.Win32.Generic.

Decryption

Unfortunately, there is no way to decrypt data that has been encrypted using the DiskCryptor utility because this legitimate utility uses strong encryption algorithms.

IOCs:

79ED93DF3BEC7CD95CE60E6EE35F46A1

APT Trends report Q2 2017

Tue, 08/08/2017 - 10:00

Introduction

Since 2014, Kaspersky Lab’s Global Research and Analysis Team (GReAT) has been providing threat intelligence reports to a wide-range of customers worldwide, leading to the delivery of a full and dedicated private reporting service. Prior to the new service offering, GReAT published research online for the general public in an effort to help combat the ever-increasing threat from nation-state and other advanced actors.  Since we began offering a threat intelligence service, all deep technical details on advanced campaigns are first pushed to our subscriber base. At the same time, to remain true to our efforts to help make the internet safer, important incidents, such as WannaCry or Petya are covered in both private and public reports.

Kaspersky’s Private Threat Intelligence Portal (TIP)

In Q1 of 2017 we published our first APT Trends report, highlighting our top research findings over the last few months. We will continue to publish quarterly reports as a representative snapshot of what has been offered in greater detail in our private reports in order to highlight significant events and findings we feel most users should be aware of.  If you would like to learn more about our intelligence reports or request more information for a specific report, readers are encouraged to contact: intelreports@kaspersky.com.

Russian-Speaking Actors

The second quarter of 2017 has seen multiple incidents involving Russian-speaking threat actors. Topping the list of ‘attention grabbers’ were the Sofacy and Turla threat actors.

March and April started off with a bang, with the discovery of three zero-day exploits being used in-the-wild by Sofacy and Turla: two of these targeted Microsoft Office’s Encapsulated PostScript (EPS) and the third being a Microsoft Windows Local Privilege Escalation (LPE).  Sofacy was discovered utilizing both CVE-2017-0262 (an EPS vulnerability) and CVE-2017-0263 (LPE) over the Easter holiday, targeting a swath of users throughout Europe.  Prior to this attack, Turla was also discovered using CVE-2017-0261 (a different EPS vulnerability).  Neither actor appeared to deviate from their usual payload repertoire, with Sofacy dropping their typical GAMEFISH payload and Turla utilizing what we refer to as ICEDCOFFEE (a.k.a. Shirime).  Targeting for these attacks was also directly within the normal wheelhouse for both actors, focusing mainly on foreign ministries, governments, and other government-affiliated organizations.

GReAT produced additional reports on Sofacy and Turla beyond those mentioned above.  In April, we notified customers of two new experimental macro techniques utilized by Sofacy.  These techniques, while not particularly sophisticated, caught our attention as they had not been seen before in-the-wild.  The first technique involved using the built-in ‘certutil’ utility in Microsoft Windows to extract a hardcoded payload within a macro. The second technique involved embedding Base64-encoded payloads within the EXIF metadata of the malicious documents.  While the targeting for this new set of activity was again fairly standard, we discovered some noteworthy targeting against a French political party member prior to the 2017 elections.  Moving into May and June, we wrote two additional reports of interest involving these two actors: the first was an update on the long running “Mosquito Turla” campaign showing the usage of fake Adobe Flash installers and continued targeting of foreign Ministries. The other documented yet another update on Sofacy’s unique Delphi payload we call ‘Zebrocy’.

June saw the massive outbreak of a piece of malware dubbed “ExPetr”.  While initial assessments presumed that this was yet another ransomware attack à la WannaCry, a deeper assessment by GReAT places the initial intent as constituting an operation destructive in nature.  We were also able to confidently identify the initial distribution of the malware, as well as indicate a low confidence assessment that the attacks may share traits with the BlackEnergy actors. 

Below is a summary of report titles produced for the Eastern European region only.  As stated above, if you would like to learn more about our threat intelligence products or request more information on a specific report, please direct inquiries to intelreports@kaspersky.com.

  1. Sofacy Dabbling in New Macro Techniques
  2. Sofacy Using Two Zero Days in Recent Targeted Attacks – early warning
  3. Turla EPS Zero Day – early warning
  4. Mosquito Turla Targets Foreign Affairs Globally
  5. Update on Zebrocy Activity June 2017
  6. ExPetr motivation and attribution – Early alert
  7. BlackBox ATM attacks using SDC bus injection
English-Speaking Actors

English-speaking actors are always particularly fascinating due to their history of complex tooling and campaigns. Actors like Regin and Project Sauron have proven fascinating examples of new techniques leveraged in long-lasting, hard to catch campaigns and as such make ideal subjects for further research. Not to be outdone, Equation and the Lamberts were the subjects of our most recent investigations.

Continuing our practice of conducting malware paleontology while integrating new discoveries, we published a report on EQUATIONVECTOR, an Equation backdoor first used as early as 2006. This backdoor is a fascinating passive-active shellcode staging implant. It’s one of the earliest noted instances of a NObody But US (‘NOBUS’) backdoor for staging further attacks. Despite its age, the EQUATIONVECTOR backdoor (identified as ‘PeddleCheap’ in the latest ShadowBrokers disclosures) incorporates many advanced techniques for prolonged stealthy operations in victim networks, allowing the Equation operators to deliver further payloads without arousing suspicion. The report tracks the development of these tools through subsequent iterations year-by-year.

Our tracking of the Lamberts toolkit continues with the publication of the Gray Lambert report in June, the most advanced Lambert known to date. This too is a NOBUS backdoor, a passive implant operating strictly in user-land. The intricate usefulness of Gray Lambert lies in its ability to orchestrate multiple sniffer victims on a network via broadcast, multicast, and unicast commands, allowing the operators to employ surgical precision in networks with many infected machines. The sniffers double as next-stage payload delivery mechanisms for an infected network. A notable feature of the Lambert campaigns is the level of precision with which targets are chosen; Gray Lambert’s victimology is primarily focused on strategic verticals in Asia and Middle East. During this investigation, GReAT researchers have also discovered two additional Lambert families (Red Lambert and Brown Lambert) currently under investigation for Q3.  Below is a list of report titles for reference:

  1. EQUATIONVECTOR – A Generational Breakdown of the PeddleCheap Multifunctional Backdoor
  2. The Gray Lambert – A Leap in Sophistication to User-land NOBUS Passive Implants
Korean-speaking Actors

Our researchers focusing on attacks with a Korean nexus also had a very busy quarter, producing seven reports on the Lazarus group and WannaCry attacks.  Most of the reports on Lazarus directly involved a sub-group we refer to as BlueNoroff.  They are the arm that focuses mainly on financial gain, targeting banks, ATMs, and other “money-makers”.  We revealed to customers a previously unknown piece of malware dubbed ‘Manuscrypt’ used by Lazarus to target not only diplomatic targets in South Korea, but also people using virtual currency and electronic payment sites. Most recently, ‘Manuscrypt’ has become the primary backdoor used by the BlueNoroff sub-group to target financial institutions.

WannaCry also created quite a stir in the second quarter, with our analysts producing three reports and multiple blog posts on this emerging threat.  What proved most interesting to us, was the probable linkage to Lazarus group as the source of the attacks, as well as the origins of the malware.  GReAT researchers were able to trace back some of its earliest usage and show that before the ‘EternalBlue’ exploit was added to version 2, WannaCry v1 was used in spearphishing attacks months prior.  Here is a listing of our reports from Q2 on actors with a Korean nexus:

  1. Manuscrypt – malware family distributed by Lazarus
  2. Lazarus actor targets carders
  3. Lazarus-linked ATM Malware On the Loose In South Korea
  4. Lazarus targets electronic currency operators
  5. WannaCry – major ransomware attack hitting businesses worldwide – early alert
  6. WannaCry possibly tied to the Lazarus APT Group
  7. The First WannaCry Spearphish and Module Distribution
Middle Eastern Actors

While there wasn’t much high-end activity involving Middle Eastern actors, we did produce two reports revolving around the use of a zero-day exploit (CVE-2017-0199).  The most notable involved an actor we refer to as BlackOasis and their usage of the exploit in-the-wild prior to its discovery.  We have previously reported on BlackOasis using other zero-days in the past; CVE-2016-4117 in May 2016, CVE-2016-0984 in June 2015, and CVE-2015-5119 in June 2015.  It is believed that BlackOasis is a customer of Gamma Group and utilizes the popular ‘lawful surveillance’ kit FinSpy.  Other than the usage of the exploit, this report was significant because it also showed one of the earliest known uses of a new version of FinSpy, which is still being analyzed by our researchers.

After the discovery of CVE-2017-0199, a plethora of threat actors also began to leverage this exploit in their attacks.  We reported to customers on the usage of this exploit by a well-known Middle Eastern actor dubbed ‘OilRig’.  OilRig has actively targeted many organizations in Israel with the exploit via spearphishes appearing to originate from well-known doctors within Ben Gurion University.  While their execution was less than stellar, it highlighted the widespread usage of this exploit shortly after its discovery.

  1. OilRig exploiting CVE-2017-0199 in new campaign
  2. BlackOasis using Ole2Link zero day exploit in the wild
Chinese-Speaking Actors

On the Chinese speaking front, we felt it necessary to produce two reports to our customers.  While Chinese speaking actors are active on a daily basis, not much has changed and we prefer to avoid producing reports on ‘yet another instance of APTxx’ for the sake of padding our numbers.  Instead we try to focus on new and exciting campaigns that warrant special attention.

One of those reports detailed a new finding regarding a fileless version of the well-known ‘HiKit’ malware dubbed ‘Hias’.  We have reported on Hias in the past, and one of our researchers was finally able to discover the persistence mechanism used, which also allowed us to tie the activity to an actor we call ‘CloudComputating’.

Another report detailed a new campaign we referred to as ‘IndigoZebra’.  This campaign was targeting former Soviet Republics with a wide swath of malware including Meterpreter, Poison Ivy, xDown, and a previously unknown malware called ‘xCaon’.  This campaign shares ties with other well-known Chinese-speaking actors, but no definitive attribution has been made at this time.

  1. Updated technical analysis of Hias RAT
  2. IndigoZebra – Intelligence preparation to high-level summits in Middle Asia
Best of the rest

Sometimes we find new and exciting campaigns or entirely new threat actors to report to our subscribers without being able to make an immediate or definitive determination on regional provenance.  Several reports fell into this category in the last quarter.  ChasingAdder is a report describing a new persistence technique that hijacked a legitimate WMI DLL for the purposes of loading a malicious payload. This activity targeted high-profile diplomatic, military, and research organizations beginning in the fall of 2016, but to date we have not been able to pinpoint the specific actor responsible.

Demsty is a new piece of MacOS malware that is targeting University researchers in Hong Kong, among others.  At the time of writing, we have a low confidence assessment that the campaign was conducted by Chinese-speaking actors, and thus categorize this as ‘Unknown’ until greater evidence comes to light.

During Q2, the mischievous ShadowBrokers also continued their regular activities dumping multiple tools and documentation allegedly stolen from Equation Group. In April, the ShadowBrokers released another dump of information detailing the alleged targeting of SWIFT service bureaus and other banks by Equation Group.  Since some of our customers are financial entities, we found it necessary to evaluate the data and provide an expert’s opinion on the validity of the dump.

Reports in the ‘unknown’ category:

  1. ShadowBrokers’ Lost in translation leak – SWIFT attacks analysis
  2. ChasingAdder – WMI DLL Hijacking Trojan Targeting High Profile Victims
  3. University Researchers Located in Hong Kong Targeted with Demsty
Predictions

Based on the trends we’ve seen over the last three months, as well as foreseeable geopolitical events, we have listed a few predictions for the upcoming quarter (Q3). As always, this isn’t an exact science and some cases won’t come to fruition. Analyzing current and future events and combining those with the motivations of known active actors can help organizations prepare for likely forthcoming activity:

  1. Misinformation campaigns will remain a threat to countries with upcoming elections, specifically Germany and Norway, as they have been previous targets for Eastern European based actors.
  2. ‘Lawful Surveillance’ tools will continue to be utilized by governments that don’t have well-established Cyber Operations capabilities, mainly based out of the Middle East. Companies such as Gamma Group, Hacking Team, and NSO will continue to offer new zero-day exploits to those customers. As prices increase and exchanges thrive, new organizations and marketplaces will continue popping up.
  3. Destructive malware disguised as ransomware will continue to be a problem. In the last quarter we’ve seen two instances of this, and with the continued release of tools / exploits from dumps like Vault7 and ShadowBrokers, this is going to be a new alarming trend to deal with.
  4. In China, the past months have been marked by the dwindling economic growth, rising tensions with North Korea and the US, and increased exchanges between South Korean / Japanese / American organizations. In addition to these, the 19th Party Congress is set to be held in the fall of 2017 and according to multiple public predictions, it is likely that some major changes will happen in the leadership. It’s possible that these events will have wide regional influences that could affect the way that threat actors operate in Asia, both in terms of targeting and TTPs.
  5. Targeting energy-related companies and organizations will be on the rise. Countries such as Norway may be a top target moving forward given their control on oil and gas in the region in the buildup to an election. Saudi Arabia will also top the charts for potential targeting as they have in years past.
  6. Lower-tier threat actors continue to increase cyber-espionage efforts and capabilities both in complexity and size. Expect more activity with varied technical capabilities coming from lesser known or previously unseen actors.
How to keep yourself protected

One of the biggest problems when it comes to leveraging threat intelligence is judging the quality of the data and how it can be used for defense. For instance, we may observe an increase in the number of fileless attacks or attacks in which all IOCs are unique or specific per victim. In such situations, having not only host-based IOCs, but also network IOCs and Yara rules that can help identify malware in all cases is very important.

Another problem comes from the fact that many threat intelligence providers have a limited world view and their data covers only a small set of threats. It’s easy for an enterprise to fall into the trap of thinking that ‘actor X’ is not something they need to worry because their focus has been only certain countries or certain industry sectors; only to discover later that their ignorance left them blind to those attacks.

As shown by many incidents, but especially by WannaCry and ExPetr’s EternalBlue-based spreading subroutines, vulnerabilities remain a key approach to infecting systems. Therefore timely patching is of utmost importance – which, being one of the most tedious IT maintenance tasks, works much better with good automation. Kaspersky Endpoint Security for Business Advanced and Kaspersky Total Security include Vulnerability & Patch management components, offering convenient tools for making patching much easier, and much less time-consuming for IT staff.

Given the above, it is highly recommended that prevention (such as endpoint protection) along with advanced detection capabilities, such as a solution that can detect all types of anomalies and scrutinize suspicious files at a deeper level, be present on users’ systems. The Kaspersky Anti Targeted Attack solution (KATA) matches events coming from different infrastructure levels, discerns anomalies and aggregates them into incidents, while also studying related artifacts in a safe environment of a sandbox. As with most Kaspersky products, KATA is powered by HuMachine Intelligence, which is backed by on premise and in lab-running machine learning processes coupled with real-time analyst expertise and our understanding of threat intelligence big data.

The best way to prevent attackers from finding and leveraging security holes, is to eliminate the holes altogether, including those involving improper system configurations or errors in proprietary applications. For this, Kaspersky Penetration Testing and Application Security Assessment services can become a convenient and highly effective solution, providing not only data on found vulnerabilities, but also advising on how to fix it, further strengthening corporate security.

Steganography in contemporary cyberattacks

Thu, 08/03/2017 - 05:00

Steganography is the practice of sending data in a concealed format so the very fact of sending the data is disguised. The word steganography is a combination of the Greek words στεγανός (steganos), meaning “covered, concealed, or protected”, and γράφειν (graphein) meaning “writing”.

Unlike cryptography, which conceals the contents of a secret message, steganography conceals the very fact that a message is communicated. The concept of steganography was first introduced in 1499, but the idea itself has existed since ancient times. There are stories of a method being used in the Roman Empire whereby a slave chosen to convey a secret message had his scalp shaved clean and a message was tattooed onto the skin. When the messenger’s hair grew back, he was dispatched on his mission. The receiver shaved the messenger’s scalp again and read the message.

In this article, the following definitions are used:

  • Payload: the information to be concealed and sent secretly, or the data covertly communicated;
  • Carrier (stego-container): any object where the payload is secretly embedded;
  • Stego-system: the methods and means used to create a concealed channel for communicating information;
  • Channel: the data communication channel via which the carrier is transferred;
  • Key: the key used to extract the payload from the carrier (not always applied).

Steganography was actively developed throughout the 20th century, as was steganalysis, or the practice of determining the fact that concealed information is being communicated within a carrier. (Basically, steganalysis is the practice of attacking stego-systems.) Today, however, a dangerous new trend is emerging: steganography is increasingly being used by actors creating malware and cyber-espionage tools. Most modern anti-malware solutions provide little, if any, protection from steganography, while any carrier in which a payload can be secretly carried poses a potential threat. It may contain data being exfiltrated by spyware, communication between a malicious program and its C&C, or new malware.

A variety of steganographic methods and algorithms have been scientifically developed and tested. A description of some of them is provided below.

  • In LSB steganography, the payload is encoded into and communicated in one or several least significant bits of the carrier. The smaller the number of bits used to carry the payload, the lower the impact on the original carrier signal.
  • Discrete cosine transform or DCT-based steganography is a sub-type of LSB steganography that is often applied on JPEG-format carriers (i.e., when JPEG images are used to carry the payload). In this method, the communicated data is secretly encoded into the DCT coefficients. With all other factors being equal, this method provides a somewhat lower data carrying capacity; one of the reasons for this is that the coefficient values of 0 and 1 cannot be altered, so no data can be encoded whenever the coefficients take on these values.
  • Palette-based image steganography is basically another sub-type of LSB steganography, in which the communicated data is encoded into least significant bits of the image palette rather than into those of the carrier. The obvious downside to this method is its low data carrying capacity.
  • Use of service fields in data formats. This is a relatively simple method, in which the payload is embedded into the service fields of the carrier’s headers. The downsides are, again, a low data carrying capacity and low payload protection: the embedded payload may be detected using regular image viewing software that can sometimes display the contents of the service fields.
  • Payload embedding is a method whereby the payload is encoded into the carrier and, upon delivery, is decoded using an algorithm known to both parties. Several payloads can be independently encoded into the same carrier provided that their embedding methods are orthogonal.
  • Wideband methods fall into the following types:
    • Pseudorandom sequence method, in which a secret carrier signal is modulated by a pseudorandom signal.
    • Frequency hopping method, in which the frequency of the carrier signal changes according to a specific pseudorandom law.
  • Overlay method – strictly speaking, this is not proper steganography, and is based on the fact that some data formats contain data size in a header, or the fact that the handler of such formats reads the file till it reaches the end-of-data marker. An example is the well-known RAR/JPEG method based on concatenating an image file, so that it is composed of a JPEG format section, followed by a RAR archive section. A JPEG viewer software program will read it till the boundary specified in the file’s header, while a RAR archiver tool will disregard everything prior to the RAR! signature that denotes the beginning of an archive. Therefore, if such a file is opened in an image file viewer, it will display the image, and if it is opened in a RAR archiver, it will display the contents of the RAR archive. The downside to this method is that the overlay added to the carrier segment can be easily identified by an analyst visually reviewing the file.

In this article, we will only review methods of concealing information in image-type carriers and in network communication. The application of steganography is, however, much wider than these two areas.

Recently, we have seen steganography used in the following malware programs and cyberespionage tools:

  • Microcin (AKA six little monkeys);
  • NetTraveler;
  • Zberp;
  • Enfal (its new loader called Zero.T);
  • Shamoon;
  • KinS;
  • ZeusVM;
  • Triton (Fibbit).

So why are malware authors increasingly using steganography in their creations? We see three main reasons for this:

  • It helps them conceal not just the data itself but the fact that data is being uploaded and downloaded;
  • It helps bypass DPI systems, which is relevant for corporate systems;
  • Use of steganography may help bypass security checks by anti-APT products, as the latter cannot process all image files (corporate networks contain too many of them, and the analysis algorithms are rather expensive).

For the end user, detecting a payload within a carrier may be a non-trivial task. As an example, let’s review the two images below. One is an empty carrier, and the other is a carrier with a payload. We will use the standard test image Lenna.

Lenna.bmp Lenna_stego.bmp

Both images are 786 486 bytes; however, the right-hand image contains the first 10 chapters of Nabokov’s novel Lolita.

Take a good look at these two images. Can you see any difference? They are identical in both size and appearance. However, one of them is a carrier containing an embedded message.

The problems are obvious:

  • Steganography is now very popular with malware and spyware writers;
  • Anti-malware tools generally, and perimeter security tools specifically, can do very little with payload-filled carriers. Such carriers are very difficult to detect, as they look like regular image files (or other types of files);
  • All steganography detection programs today are essentially proof-of-concept, and their logic cannot be implemented in commercial security tools because they are slow, have fairly low detection rates, and sometimes even contain errors in the math (we have seen some instances where this was the case).

A list was provided above (though it does not claim to be complete) of malicious programs that use steganography to conceal their communication. Let’s review one specific case from that list, the malicious loader Zero.T.

We detected this loader in late 2016, though our colleagues from Proofpoint were first to publish a description.

We named it Zero.T because of this string in its executable code (in the path leading to the project’s PBD file):

We will not dwell here on how the malicious loader penetrates the victim system and remains there, but will note that it loads a payload in the form of Bitmap files:

Then it processes them in a particular way to obtain malicious modules:

On the face of it, these three BMP files appear to be images:

However, they are more than just regular images; they are payload-filled carriers. In each of them, several (the algorithm allows for variability) least significant bits are replaced by the payload.

So, is there a way to determine whether an image is carrying a malicious payload or not? Yes, there are several ways of doing so, the simplest being a visual attack. It is based on forming new images from the source image, containing the least significant bits of different color planes.

Let’s see how this works using the Steve Jobs photo as a sample image.

We apply a visual attack to this image and construct new images from the separate significant bits in the appropriate order:

In the second and the third images, high entropy (high data density) areas are apparent – these contain the embedded payload.

Sounds simple, right? Yes and no. It’s simple in that an analyst – and even an average user – can easily see the embedded data; it’s difficult in that this sort of analysis is not easy to automate. Fortunately, scientists have long since developed a number of methods for detecting carriers with payloads, based on an image’s statistical characteristics. However, all of them are based on the assumption that the encoded payload has high entropy. This is true in most cases: since the container’s capacity is limited, the payload is compressed and/or encrypted before encoding, thus increasing its entropy.

However, our real-life example, the malicious loader Zero.T, does not compress its malicious modules before encoding. Instead, it increases the number of least significant bits it uses, which can be 1, 2 or 4. Yes, using a larger number of least significant bits introduces visual artefacts into the carrier image, which a regular user can detect visually. But we are talking about automatic analysis. So, the question we have to answer is: are statistical methods suitable for detecting embedded payloads with low levels of entropy?

Statistical methods of analysis: histogram method

This method was suggested in 2000 by Andreas Westfeld and Andreas Pfitzmann, and is also known as the chi-squared method. Below we give a brief overview.

The entire image raster is analyzed. For each color, the number of dots possessing that color is counted within the raster. (For simplicity, we are dealing with an image with one color plane.) This method assumes that the number of pixels possessing two adjacent colors (i.e. colors different only by one least significant bit) differs substantially for a regular image that does not contain an embedded payload (see Figure A below). For a carrier image with a payload, the number of pixels possessing these colors is similar (see Figure B).

Figure A. An empty carrier Figure B. A filled carrier.

The above is an easy way to visually represent this algorithm.

Strictly speaking, the algorithm consists of the following steps that must be executed sequentially:

  • The expected occurrence frequency for the pixels of color i in a payload-embedded image is calculated as follows:
  • The measured frequency of the occurrence of a pixel of specific color is determined as:
  • The chi-squared criterion for k-1 degrees of freedom is calculated as:
  • P is the probability that the distributions ni and ni* are equal under these conditions. It is calculated by integrating the density function:

Naturally, we have tested whether this method is suitable for detecting filled stego-containers. Here are the results.

Original image Visual attack image Chi-squared attack, 10 zones

The threshold values of the chi-squared distribution for p=0.95 and p=0.99 are 101.9705929 and 92.88655838 respectively. Thus, for the zones where the calculated chi-squared values are lower than the threshold, we can accept the original hypothesis “adjacent colors have similar frequency distributions, therefore we are dealing with a carrier image with a payload”.

Indeed, if we look at the visual attack images, we can clearly see that these zones contain an embedded payload. Thus, this method works for high-entropy payloads.

Statistical methods of analysis: RS method

Another statistical method of detecting payload carriers was suggested by Jessica Fridrich, Miroslav Goljan and Andreas Pfitzmann in 2001. It is called the RS method, where RS stands for ‘regular/singular’.

The analyzed image is divided into a set of pixel groups. A special flipping procedure is then applied for each group. Based on the values of the discriminant function before and after the flipping procedure is applied, all groups are divided into regular, singular and unusable groups.

This algorithm is based on the assumption that the number of regular and singular pixel groups must be approximately equal in the original image and in the image after flipping is applied. If the numbers of these groups change appreciably after flipping is applied, this indicates that the analyzed image is a carrier with a payload.

The algorithm consists of the following steps:

  • The original image is divided into groups of n pixels (x1, …, xn).
  • The so-called discriminant function is defined which assigns to each group of pixels G = (x1, …, xn) a real number f(x1, …, xn) ∈
  • The discriminant function for the groups of pixels (x1, …, xn) can be defined as follows:
  • Then we define the flipping function which has the following properties:

Depending on the discriminant function’s values prior to and after flipping is applied, all groups of pixels are divided into regular, singular and unusable groups:

We have put this method to the test as well, and obtained the following results. We used the same empty and payload-embedded carriers as in the previous test.

Original image Visual attack image Chi-squared attack, 10 zones

Note that this attack method does not pass the binary verdict in terms of “whether this specific carrier contains an embedded payload or not”; rather, it determines the approximate length of the embedded payload (as a percentage).

As can be seen from the results above, this method returned a verdict for the empty message that it was filled less than 1% with payload, and for the payload-embedded carrier it returned a verdict that it was about 44% filled. Obviously, these results are slightly off. Let’s look at the filled container: from the visual attack it follows that more than 50% of the container is filled, while the RS attack tells us that 44% of the container is filled. Therefore, we can apply this method if we establish a certain “trigger threshold”: our experiments showed that 10% is a sufficient threshold of reliability. If the RS attack claims that more than 10% of the container is full, you can trust this verdict and mark the container as full.

Now it’s time to test these two methods in real-world conditions, on the Zero.T carriers in which the payload has regular entropy.

We ran the appropriate tests and here are the results:

Original image Chi-squared attack RS attack

As we see, a chi-squared attack is not applicable on low entropy images – it yields unsatisfactory or inaccurate results. However, the RS attack worked well: in both cases, it detected a hidden payload in the image. However, what do we do if automatic analysis methods show there is no payload, but we still suspect there might be one?

In that case, we can apply specific procedures that have been developed for specific malware families to extract the payload. For the aforementioned Zero.T loader, we have written our own embedded payload extraction tool. Its operation can be schematically presented as follows.

+ =

Obviously, if we get a valid result (in this specific case, an executable file), then the source image has an embedded payload in it.

Is DNS tunneling also steganography?

Can we consider use of a DNS tunnel a subtype of steganography? Yes, definitely. For starters, let’s recap on how a DNS tunnel works.

From a user computer in a closed network, a request is sent to resolve a domain, for example the domain wL8nd3DdINcGYAAj7Hh0H56a8nd3DdINcGYAlFDHBurWzMt[.]imbadguy[.]com to an IP address. (In this URL, the second-level domain name is not meaningful.) The local DNS server forwards this request to an external DNS server. The latter, in turn, does not know the third-level domain name, so it passes this request forward. Thus, this DNS request follows a chain of redirections from one DNS server to another, and reaches the DNS server of the domain imbadguy[.]com.

Instead of resolving a DNS request at the DNS server, threat actors can extract the information they require from the received domain name by decoding its first part. For example, information about the user’s system can be transmitted in this way. In response, a threat actor’s DNS server also sends some information in a decoded format, putting it into the third- or higher-level domain name.

This means the attacker has 255 characters in reserve for each DNS resolution, up to 63 characters for subdomains. 63 characters’ worth of data is sent in each DNS request, and 63 characters are sent back in response, and so on. This makes it a decent data communications channel! Most importantly, it is concealed communication, as an unaided eye cannot see that any extra data is being communicated.

To specialists who are familiar with network protocols and, in particular, with DNS tunneling, a traffic dump containing this sort of communication will look quite suspicious – it will contain too many long domains that get successfully resolved. In this specific case, we are looking at the real-life example of traffic generated by the Trojan Backdoor.Win32.Denis, which uses a DNS tunnel as a concealed channel to communicate with its C&C.

A DNS tunnel can be detected with the help of any popular intrusion detection (IDS) tool such as Snort, Suiricata or BRO IDS. This can be done using various methods. For example, one obvious idea is to use the fact that domain names sent for DNS resolution are much longer than usual during tunneling. There are quite a few variations on this theme on the Internet:

alert udp any any -> any 53 (msg:”Large DNS Query, possible cover channel”; content:”|01 00 00 01 00 00 00 00 00 00|”; depth:10; offset:2; dsize:>40; sid:1235467;)

There is also this rather primitive approach:

Alert udp $HOME_NET and -> any 53 (msg: “Large DNS Query”; dsize: >100; sid:1234567;)

There is plenty of room for experimenting here, trying to find a balance between the number of false positives and detecting instances of actual DNS tunneling.

Apart from suspiciously long domain names, what other factors may be useful? Well, anomalous syntax of domain names is another factor. All of us have some idea of what typical domain names look like – they usually contain letters and numbers. But if a domain name contains Base64 characters, it will look pretty suspicious, won’t it? If this sort of domain name is also quite long, then it is clearly worth a closer look.

Many more such anomalies can be described. Regular expressions are of great help in detecting them.

We would like to note that even such a basic approach to detecting DNS tunnels works very well. We applied several of these rules for intrusion detection to the stream of malware samples sent to Kaspersky Lab for analysis, and detected several new, previously unknown backdoors that used DNS tunnels as a covert channel for C&C communication.

Conclusions

We are seeing a strong upward trend in malware developers using steganography for different purposes, including for concealing C&C communication and for downloading malicious modules. This is an effective approach considering payload detection tools are probabilistic and expensive, meaning most security solutions cannot afford to process all the objects that may contain steganography payloads.

However, effective solutions do exist – they are based on combinations of different methods of analysis, prompt pre-detections, analysis of meta-data of the potential payload carrier, etc. Today, such solutions are implemented in Kaspersky Lab’s Anti-Targeted Attack solution (KATA). With KATA deployed, an information security officer can promptly find out about a possible targeted attack on the protected perimeter and/or the fact that data is being exfiltrated.

DDoS attacks in Q2 2017

Tue, 08/01/2017 - 05:00

News Overview

The second quarter of 2017 saw DDoS attacks being more and more frequently used as a tool for political struggle. The Qatar crisis was accompanied by an attack on the website of Al Jazeera, the largest news network in the area, Le Monde and Le Figaro websites were targeted in the heat of the presidential election in France, and in Great Britain they recalled a year-old incident with the Brexit voter registration website where some citizens were excluded from the referendum because of the continuous attacks on the website.

Quite a significant event took place in the USA: the Federal Communications Commission (FCC) revealed plans for abolishing the principle of net neutrality, legislatively mandated two years before. The public comment system of the Commission website was rendered inoperative for about a day and eventually was completely disabled as a result of a massive attack. The reason for the crash remained unclear: it was either an invasion of the opponents of net neutrality, who were flooding the system with identical comments, or, on the contrary, an attack launched by the supporters of net neutrality, who tried to prevent their adversaries from flooding the FCC website with fake comments.

And yet, money remains the driving force of DDoS attacks. The growing interest in cryptocurrencies led to an increase in their exchange-value in the second quarter of 2017, which in turn drew the attention of cybercriminals. The largest bitcoin exchange, Bitfinex underwent an attack at the same time as the trading of a new IOT-currency IOTA was launched. Somewhat earlier the BTC-E exchange stated that its services were slowed down because of a powerful DDoS attack. Apparently, this way cybercriminals attempt to manipulate the currency rates, which can be quite easily achieved considering the high volatility of cryptocurrencies.

Owners of DDoS botnets do not limit themselves to renting out their computing powers. At the end of June, there was registered a large-scale attempt of extortion under threat of a DDoS attack. The group that calls itself Armada Collective demanded about $315,000 from seven South Korean banks in exchange for not disrupting their online services. According to a Radware report, this was not the first case of extortion through a DDoS attack initiated by this group.

With growing financial losses from DDoS attacks law enforcement agencies begin to take the attack initiators more seriously. In April 2017 in Great Britain, a young man was sentenced to two years in prison for a series of attacks, which he had carried out five years before while still being a student. The man had created the Titanium Stresser botnet and traded its services on a darknet, thus yielding a profit of approximately £386,000.

There were not many technical innovations in DDoS attacks in the second quarter; however, news concerning a new DDoS-attack vector deserves attention. Researchers from Corero Network Security reported that they had registered more than 400 attacks with the help of misconfigured LDAP servers. The largest attack volume was at 33 Gb/s. As amplified reflection was used in that case, the organization of such attacks requires relatively few resources.

The most infamous attack of the second quarter became a DDoS attack on Skype servers. Many users of the messenger all over the world experienced connectivity problems. The responsibility for the campaign was claimed by CyberTeam, but its motives remain unknown.

Quarter Trends Ransom DDoS

The trend of extorting money under threat of DDoS attacks is becoming more prominent during this quarter. This approach was dubbed “ransom DDoS”, or “RDoS”. Cybercriminals send a message to a victim company demanding a ransom of 5 to 200 bitcoins. In case of nonpayment, they promise to organize a DDoS attack on an essential web resource of the victim. Such messages are often accompanied by short-term attacks which serve as demonstration of the attacker’s power. The victim is chosen carefully. Usually, the victim is a company which would suffer substantial losses if their resources are unavailable.

There is another method as opposed to the above-mentioned one: hoping to gain revenue quickly and without much effort cybercriminals contact a great number of companies by sending out ransom messages with threats of launching a DDoS attack, not taking into account the specifics of these companies’ operation. In most cases, they do not launch a demonstrative attack. Paying the ransom would create a certain reputation for a company and provoke further attacks of other cybercriminal groups.

It should be noted that these groups now are more and more represented not by well-coordinated hacker professional teams but by beginners who do not even possess the skills to launch a DDoS attack and only have the means for a “demonstrative attack”. Those who fall victim to this scheme are companies that for one reason or another have no resources to organize security for their services yet capable of parting with available funds in order to pay the ransom.

SambaCry

There is yet another important event of the quarter, which is the discovery of a vulnerability in the Samba network software. The vulnerability allows cybercriminals to execute code remotely on devices running Linux and Unix. Samba is a software suite that allows addressing network disks and printers and runs on a majority of Unix-like operating systems, such as Linux, POSIX-compatible Solaris and Mac OS X Server and various BSD OSes.

According to the Samba company, “all versions of Samba from 3.5.0 onwards have a remote code-execution vulnerability, allowing a malicious client to upload a shared library to a writable share, and then cause the server to load and execute it”.

The total number of devices with the vulnerable software reaches over 500,000, roughly estimated. This means that cybercriminals can use the devices to create botnets with the goal of carrying out large-scale DDoS attacks.

Statistics for botnet-assisted DDoS attacks Methodology

Kaspersky Lab has extensive experience of combating cyber threats, including DDoS attacks of various complexity types and ranges. The experts of the company have been tracking the actions of botnets by using the DDoS Intelligence system.

Being part of the Kaspersky DDoS Prevention solution, the DDoS Intelligence system is intended to intercept and analyze commands sent to bots from command-and-control servers and requires neither infecting any user devices nor the actual execution of cybercriminals’ commands.

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

In the context of this report, it is assumed that an incident is a separate (single) DDoS-attack if the interval between botnet activity periods does not exceed 24 hours. For example, if the same web resource was attacked by the same botnet with an interval of 24 hours or more, then this incident is considered as two attacks. Also, bot requests originating from different botnets but directed at one resource count as separate attacks.

The geographical locations of DDoS-attack victims and C&C servers that were used to send commands are determined by their respective IP addresses. The number of unique targets of DDoS attacks in this report is counted by the number of unique IP addresses in the quarterly statistics.

It is important to note that DDoS Intelligence statistics are limited only to those botnets that have been detected and analyzed by Kaspersky Lab. It should also be noted that botnets are just one of the tools for performing DDoS attacks; thus, the data presented in this report do not cover every single DDoS attack occurred during the indicated period.

Q2 summary
  • The resources in 86 countries were attacked in Q2 2017, 14 countries increase over the Q1 2017.
  • Just as in Q1, almost one-half of the attacks (47.42%) were aimed at the targets in China.
  • China, South Korea, and the USA remained leaders by both the number of attacks and the number of targets. According to the number of reported C&C servers, the same countries are in the TOP 3; but South Korea took the first place this time.
  • The long-term DDoS attacks made it back in Q2. The record duration was 277 hours, which was a 131% increase compared to Q1. At the same time, the share of the attacks that lasted less than 50 hours remained practically unchanged (99.7% in Q2 vs. 99.8% in Q1).
  • There was a considerable drop in the share of attacks over TCP (down to 18.2% from 26.6%) and ICPM (down to 7.3% from 8.2%). This caused a rise in the percentage of SYN floods and attacks over UDP and HTTP.
  • Linux botnets recovered from the decline of their share in Q1. Those botnets were responsible for 51.23% of attacks in Q2 compared to 43.40% in Q1.
Geography of attacks

DDoS attacks were registered in 86 countries in Q2, where the largest number of the attacks were aimed at China (58.07% of all of the attacks), which is 3 p.p. higher compared to the previous quarter. South Korea went down from 22.41% to 14.17% and retained second place nonetheless, while the USA rose from 11.37% up to 14.03%, almost catching up with South Korea.

The top 10 accounted for 94.60% of attacks and included Italy (0.94%) and Netherlands (0.84%), pushing down Vietnam and Denmark in Q2. Russia (1.60%) lost 0.37 p.p., moving down from fourth to sixth place, while Great Britain went up from 0.77% to 1.38%, a rise from seventh to fifth place.

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

95.3% of the attacks were aimed at targets in the countries of top 10 in Q2 2017.

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

China maintained its leading position in distribution by number of targets: 47.42% of them were located in the territory of the country, a fall of 0.36 p.p. compared to Q1. At the same time, the USA pushed down South Korea by going up from third to second place. Respectively, the USA rose to 18.63% (vs. 13.80% in Q1), while South Korea went from 26.57% down to 16.37%.

The share of targets located in the territory of Russia dropped from 1.55% in Q1 to 1.33% in Q2, pushing Russia down from fifth to seventh place. Vietnam and Denmark left the top 10 and were replaced by Italy (1.35%) and Australia (0.97%).

Dynamics of the number of DDoS attacks

The number of attacks per day ranged from 131 (April 17) to 904 (April 13) in Q2 2017. The peak numbers were registered on April 24 (581), May 7 (609), June 10 (614), and June 16 (621). A relative downturn was registered on April 14 (192), May 31 (240), and June 23 (281).

Dynamics of the number of DDoS attacks in Q2 2017*
*Since DDoS attacks may continuously last for several days, one attack may be counted several times in the timeline, i.e., once per day.

Monday stayed as the quietest day for DDoS attacks (11.74% of all of the attacks) in Q2 2017, while Sunday became the busiest day (15.57%) on account of the activity slacking on Saturday, a fall from 16.05% in Q1 to 14.39% in Q2. Thursday became the second busiest day, coming right behind Sunday (15.39%).

Distribution of DDoS attacks by day of the week

Types and duration of DDoS attacks

SYN floods partially recovered their positions lost during the previous quarter, rising from 48.07% to 53.26% in Q2 2017. There was an increase of percentage for both UDP attacks (from 8.71% up to 11.91%) and HTTP attacks (from 8.43% up to 9.38%). At the same time, the share of TCP DDoS attacks plummeted from 26.62% down to 18.18%, while the popularity of ICMP attacks slightly decreased from 8.17% down to 7.27% (out of all of the registered attacks).

Distribution of DDoS attacks by type

Long-term attacks made it back to the statistics in Q2 2017: 0.07% of the attacks lasted more than 100 hours, while the record attack continued for 277 hours, 157 hours longer than the record of the previous quarter. At the same time, the share of attacks that lasted 4 hours or less increased from 82.21% in Q1 to 85.93% in Q2. Thus, the percentage of attacks lasting from 5 to 49 hours decreased.

Distribution of DDoS attacks by duration (hours)

C&C servers and botnet types

The top 3 countries with the greatest number of detected C&C servers was slightly changed in Q2: China retained the third place with its 7.74%, ousting Netherlands, which moved down to fourth place despite an increase from 3.51% to 4.76%. South Korea kept its leading position and saw a fall from 66.49% down to 49.11%, while the USA still retained the second place (16.07%). The top 3 countries accounted for 72.92% of C&C servers in total.

The top 10 included Canada and Denmark (each at 0.89%), ousting Romania and Great Britain in Q2. Compared to Q1 2017, there was a significant decrease in the shares of Hong Kong (down to 1.19% from 1.89%) and Russia (down to 2.68% from 3.24%).

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

Distribution by operating system became almost balanced in Q2: the share of Linux-based botnets comprised 51.23%; accordingly, Windows-based botnets comprised 48.77%.

Correlation between Windows- and Linux-based botnet attacks

Conclusions

There were no particular changes in the statistics of the second quarter of 2017 when compared to the previous quarter. As before about one half of DDoS attacks still originated in China, also in China was one half of the detected attack targets.

The second quarter quite clearly showed that the DDoS-attack threat is perceived rather seriously. Some companies were prepared to pay cybercriminals literally after their first demand without waiting for the attack itself. This set off a whole new wave of fraud involving money extortion under threat of a DDoS attack, also known as “ransom DDoS”. The gravity of the situation can be seen in the cybercriminals’ frequent disregard for demonstrating their capabilities; instead, the fraudsters would just send out ransom messages directed at a large pool of addresses. Certainly, the “entry threshold” for ransom DDoS is extremely low, fraudsters need neither significant resources nor technical skills or knowledge.

A new era in mobile banking Trojans

Mon, 07/31/2017 - 05:00

In mid-July 2017, we found a new modification of the well-known mobile banking malware family Svpeng – Trojan-Banker.AndroidOS.Svpeng.ae. In this modification, the cybercriminals have added new functionality: it now also works as a keylogger, stealing entered text through the use of accessibility services.

Accessibility services generally provide user interface (UI) enhancements for users with disabilities or those temporarily unable to interact fully with a device, perhaps because they are driving. Abusing this system feature allows the Trojan not only to steal entered text from other apps installed on the device, but also to grant itself more permissions and rights, and to counteract attempts to uninstall the Trojan.

Attack data suggests this Trojan is not yet widely deployed. In the space of a week, we observed only a small number of users attacked, but these targets spanned 23 countries. Most attacked users were in Russia (29%), Germany (27%), Turkey (15%), Poland (6%) and France (3%). It is worth noting that, even though most attacked users are from Russia, this Trojan won’t work on devices running the Russian language. This is a standard tactic for Russian cybercriminals looking to evade detection and arrest.

The Svpeng malware family is known for being innovative. Starting from 2013, it was among the first to begin attacking SMS banking, to use phishing pages to overlay other apps to steal credentials, and to block devices and demand money. In 2016, cybercriminals were actively distributing Svpeng through AdSense using a vulnerability in the Chrome browser. This makes Svpeng one of the most dangerous mobile malware families, and it is why we monitor the functionality of new versions.

The attack process

After starting, the Trojan-Banker.AndroidOS.Svpeng.ae checks the device language and, if it is not Russian, asks the device for permission to use accessibility services. In abusing this privilege, it can do many harmful things. It grants itself device administrator rights, draws itself over other apps, installs itself as a default SMS app, and grants itself some dynamic permissions that include the ability to send and receive SMS, make calls, and read contacts. Furthermore, using its newly-gained abilities the Trojan can block any attempt to remove device administrator rights – thereby preventing its uninstallation. It is interesting that in doing so it also blocks any attempt to add or remove device administrator rights for any other app too.

Svpeng was able to become a device administrator without any interaction with the user just by using accessibility services.

Using accessibility services allows the Trojan to get access to the UI of other apps and to steal data from them, such as the names of the interface elements and their content, if it is available. This includes entered text. Furthermore, it takes screenshots every time the user presses a button on the keyboard, and uploads them to the malicious server. It supports not only the standard Android keyboard but also a few third-party keyboards.

Some apps, mainly banking ones, do not allow screenshots to be taken when they are on top. In such cases, the Trojan has another option to steal data – it draws its phishing window over the attacked app. It is interesting that, in order to find out which app is on top, it uses accessibility services too.

From the information Svpeng receives from its command and control server (CnC), I was able to intercept an encrypted configuration file and decrypt it to find out the attacked apps, and to obtain a URL with phishing pages.

I uncovered a few antivirus apps that the Trojan attempted to block, and some apps with phishing URLs to overlay them. Like most mobile bankers, Svpeng overlays some Google apps to steal credit card details.

Also, the config file contained a phishing URL for the PayPal and eBay mobile apps to steal credentials and URLs for banking apps from different countries:

  • UK– 14 attacked banking apps
  • Germany – 10 attacked banking apps
  • Turkey– 9 attacked banking apps
  • Australia– 9 attacked banking apps
  • France– 8 attacked banking apps
  • Poland– 7 attacked banking apps
  • Singapore– 6 attacked banking apps

There was one more app in this configuration file – Speedway app, which is a rewards app, not a financial app. Svpeng will overlay it with a phishing window to steal credentials.

It can also receive commands from the CnC:

  • To send SMS
  • To collect info (Contacts, installed apps and call logs)
  • To collect all SMS from the device
  • To open URL
  • To start stealing incoming SMS
Distribution and protection

The Trojan-Banker.AndroidOS.Svpeng.ae is distributed from malicious websites as a fake flash player. Its malicious techniques work even on fully-updated devices with the latest Android version and all security updates installed. By accessing only one system feature this Trojan can gain all necessary additional rights and steal lots of data.

MD5

F536BC5B79C16E9A84546C2049E810E1

CowerSnail, from the creators of SambaCry

Tue, 07/25/2017 - 09:32

We recently reported about SambaCry, a new family of Linux Trojans exploiting a vulnerability in the Samba protocol. A week later, Kaspersky Lab analysts managed to detect a malicious program for Windows that was apparently created by the same group responsible for SambaCry. It was the common C&C server that both programs used – cl.ezreal.space:20480 – that suggested a relationship between them.

Kaspersky Lab products detect the new malicious program as Backdoor.Win32.CowerSnail. MD5: 5460AC43725997798BAB3EB6474D391F

CowerSnail was compiled using Qt and linked with various libraries. This framework provides benefits such as cross-platform capability and transferability of the source code between different operating systems. This, however, has an effect on the resulting file size: the user code ends up as a small proportion of a large 3 MB file.

First stage

First of all, CowerSnail escalates the process priority and the current thread’s priority.

Then it uses the StartServiceCtrlDispatcher API to launch the main C&C communication thread as a control manager service.

If the thread is successfully launched as a service, further communication with the C&C is carried out through that service; otherwise, CowerSnail operates without it. CowerSnail can also accept various variables as input, such as the C&C host. When these are absent, the required data is extracted from the file itself.

Invoking the main C&C communication method will look like this in the control service routine (the method is stated as ‘route’).

C&C server communication

Traffic analysis shows that the bot communicates with the C&C via the IRC protocol. This can be seen from the characteristic ‘CHANNEL’ command and the subsequent exchange of pings, which often occurs in IRC botnets made up of IoT devices.

The first two bytes are the ‘pk’ signature which occurs in each packet except the CHANNEL command. The DWORD that follows is the size of the remaining part of the packet:

The name of each field is encoded in Unicode and is preceded by field length. The RequestReturn/Request DWORD coming after the status bar shows the number of variables for the variable RequestReturn. In this example, there are three variables: ‘success’, ‘I’ and ‘result’. Each of these fields, in turn, can contain more nested variables. The screenshot below shows the response to the SysInfo request in which CowerSnail sends 14 (0xE) different strings containing information about the infected system. The type of variable is stated after its name, followed by its value.

The structures of the request packet and the response packet are slightly different. The server’s request includes the request name coded as Request->arg->type->”Ping/SysInfo/Install”, as well as extra parameters that are nested into the arg field.

Here are examples of several variable types:

0x00000005 – Integer variable

0x0000000A – String variable

After registering the infected host at the C&C server, which includes sending information about the infected system, CowerSnail exchanges pings with the server and waits for commands.

Commands

Unlike SambaCry, CowerSnail does not download cryptocurrency mining software by default, but instead provides a standard set of backdoor functions:

  • Receive update (LocalUpdate)
  • Execute any command (BatchCommand)
  • Install CowerSnail as a service, using the Service Control Manager command line interface (Install)
  • Uninstall CowerSnail from service list (Uninstall)
  • Collect system information:
    • Timestamp
    • Installed OS type (e.g. Windows)
    • OS name
    • Host name
    • Information about network interfaces
    • ABI
    • Core processor architecture
    • Information about physical memory
Conclusion

SambaCry was designed for *nix-based systems. CowerSnail, meanwhile, was written using Qt, which most probably means the author didn’t want to go into the details of WinAPI, and preferred to transfer the *nix code “as is”. This fact, along with the same C&C being used by both programs, strongly suggests that CowerSnail was created by the same group that created SambaCry. After creating two separate Trojans, each designed for a specific platform and each with its own peculiarities, it is highly probable that this group will produce more malware in the future.

Spring Dragon – Updated Activity

Mon, 07/24/2017 - 05:05

Spring Dragon is a long running APT actor that operates on a massive scale. The group has been running campaigns, mostly in countries and territories around the South China Sea, since as early as 2012. The main targets of Spring Dragon attacks are high profile governmental organizations and political parties, education institutions such as universities, as well as companies from the telecommunications sector.

In the beginning of 2017, Kaspersky Lab became aware of new activities by an APT actor we have been tracking for several years called Spring Dragon (also known as LotusBlossom).

Information about the new attacks arrived from a research partner in Taiwan and we decided to review the actor’s tools, techniques and activities.

Using Kaspersky Lab telemetry data we detected the malware in attacks against some high-profile organizations around the South China Sea.

Spring Dragon is known for spear phishing and watering hole techniques and some of its tools have previously been analyzed and reported on by security researchers, including Kaspersky Lab. We collected a large set (600+) of malware samples used in different attacks, with customized C2 addresses and campaign codes hardcoded in the malware samples.

Spring Dragon’s Toolset

The threat actor behind Spring Dragon APT has been developing and updating its range of tools throughout the years it has been operational. Its toolset consists of various backdoor modules with unique characteristics and functionalities.

The threat actor owns a large C2 infrastructure which comprises more than 200 unique IP addresses and C2 domains.

The large number of samples which we have managed to collect have customized configuration data, different sets of C2 addresses with new hardcoded campaign IDs, as well as customized configuration data for creating a service for malware on a victim’s system. This is designed to make detection more difficult.

All the backdoor modules in the APT’s toolset are capable of downloading more files onto the victim’s machine, uploading files to the attacker’s servers, and also executing any executable file or any command on the victim’s machine. These functionalities enable the attackers to undertake different malicious activities on the victim’s machine.

A detailed analysis of known malicious tools used by this threat actor is available for customers of Kaspersky Threat Intelligence Services.

Command and Control (C2) Infrastructure

The main modules in Spring Dragon attacks are backdoor files containing IP addresses and domain names of C2 servers. We collected and analyzed information from hundreds of C2 IP addresses and domain names used in different samples of Spring Dragon tools that have been compiled over the years.

In order to hide their real location, attackers have registered domain names and used IP addresses from different geographical locations. The chart below shows the distribution of servers based on geographical location which the attackers used as their C2 servers.


Distribution chart of C2 servers by country

More than 40% of all the C2 servers used for Spring Dragon’s operations are located in Hong Kong, which hints at the geographical region (Asia) of the attackers and/or their targets. The next most popular countries are the US, Germany, China and Japan.

Targets of the Attacks

As was mentioned, the Spring Dragon threat actor has been mainly targeting countries and territories around the South China Sea with a particular focus on Taiwan, Indonesia, Vietnam, the Philippines, Hong Kong, Malaysia and Thailand.

Our research shows that the main targets of the attacks are in the following sectors and industries:

  • High-profile governmental organizations
  • Political parties
  • Education institutions, including universities
  • Companies from the telecommunications sector

The following map shows the geographic distribution of attacks according to our telemetry, with the frequency of the attacks increasing from yellow to red.

Geographic map of attacks

Origin of the Attacks

The victims of this threat actor have always been mainly governmental organizations and political parties. These are known to be of most interest to state-supported groups.

The type of malicious tools the actor has implemented over time are mostly backdoor files capable of stealing files from victims’ systems, downloading and executing additional malware components as well as running system commands on victims’ machines. This suggests an intention to search and manually collect information (cyberespionage). This activity is most commonly associated with the interests of state-sponsored attackers.

As a routine analysis procedure, we decided to figure out the attacker’s possible time zone using the malware compilation timestamps from a large number of Spring Dragon samples. The following diagram shows the frequency of the timestamps during daytime hours. The timestamps range from early 2012 until now and are aligned to the GMT time zone.

Assuming the peak working hours of malware developers are the standard working day of 09:00-17:00, the chart shows that compilation took place in the GMT+8 time zone. It also suggests that either there is a second group working another shift in the same time zone or the attackers are cross-continental and there is another group, possibly in Europe. The uneven distribution of timestamps (low activity around 10am, 7-8pm UTC) suggests that the attackers didn’t change the timestamps to random or constant values and they might be real.

Histogram of malware files’ timestamps

Conclusions

Spring Dragon is one of many long-running APT campaigns by unknown Chinese-speaking actors. The number of malware samples which we managed to collect (over 600) for the group surpassed many others, and suggests an operation on a massive scale. It’s possible that this malware toolkit is offered in specialist public or private forums to any buyers, although, to date, we haven’t seen this.

We believe that Spring Dragon is going to continue resurfacing regularly in the Asian region and it is therefore worthwhile having good detection mechanisms (such as Yara rules and network IDS signatures) in place. We will continue to track this group going forward and, should the actor resurface, we will provide updates on its new modus operandi.

More information is available to Kaspersky Lab private report subscribers. Please contact intelreports@kaspersky.com.

References

Below is the list of public references and reports related to the Spring Dragon attackers:

  1. Securelist – https://securelist.com/blog/research/70726/the-spring-dragon-apt/
  2. Palo Alto Networks – http://researchcenter.paloaltonetworks.com/2015/06/operation-lotus-blossom/
  3. Palo Alto Networks IoC2 – https://github.com/pan-unit42/iocs/tree/master/lotusblossom
  4. Palo Alto Networks 2 – http://researchcenter.paloaltonetworks.com/2015/12/attack-on-french-diplomat-linked-to-operation-lotus-blossom/
  5. Palo Alto Networks Unit 42, full report – https://app.box.com/s/xhn6ru62qqom1kuxoe3mxnqrtb1sqw2q
  6. TrendMicro – http://www.trendmicro.com.my/vinfo/my/security/news/cyber-attacks/esile-targeted-attack-campaign-hits-apac-governments
  7. TrendMicro – http://s.itho.me/infosec/2016/AT8.pdf
  8. PwC – http://pwc.blogs.com/cyber_security_updates/2015/12/elise-security-through-obesity.html

A King’s Ransom It is Not

Thu, 07/20/2017 - 05:00

The first half of 2017 began with two intriguing ransomware events, both partly enabled by wormable exploit technology dumped by a group calling themselves “The ShadowBrokers”. These WannaCry and ExPetr ransomware events are the biggest in the sense that they spread the quickest and most effectively of known ransomware to date. With this extraordinary effectiveness and speed, one might expect that at least one of the groups would walk away with a very large cash haul. But that is not the case.

King Richard the I, held for a King’s Ransom of 100,000 marks. The largest ransom in known history. At the time, twice England’s GDP

Both of these incidents were carried out by two very different groups that appear to have been capable of obtaining, but minimally interested in, a king’s ransom. This missing financial motivation is strange, considering the royal capabilities of the exploits that they used to deploy their ransomware.

Also unusual, and preceding and relevant to these 2017 ransomware events, is that groups carrying out aggressive, destructive acts were more straightforward about the matter. We first posted our destructive BlackEnergy (BE) findings in 2014, along with discussion of their “dstr” plugin and odd DDoS features. Allegedly BE later took down large parts of the electrical grid in Ukraine for almost a half day. Later we described the Destover components used in the worm-enabled, destructive, politically motivated Sony incident. And Shamoon and StonedDrill have been pushed in the Middle East around turbulent political situations as well. These components were all wiper technology, delivered in a very intentional and destructive manner. It’s interesting that these spectacles all coincided with large political events and interests. So this new need to cloak their destructive activity or sabotage is an interesting shared change in tactics.

WannaCry Deployment

WannaCry deployment efforts began much earlier than has been publicly discussed. Our private report subscribers received early information that the attackers were spearphishing targets globally by at least March 14th. These messages contained links to files hosted at file sharing services. When clicked, the link led to what recipients thought were resumes related to job applications with a filename “Resume.zip” containing “Job Inquiry – Resume 2017.exe”.

This executable maintained a modified Adobe pdf file icon, and dropped both more malware (droppers and downloader chains that later led to WannaCry installations) and immediately opened decoy job applications. Here is an image of one of the decoys. While we couldn’t find it online, it may be a rip of a legitimate document:

Most of these targets were soft (likely to run the exe and likely did not have advanced network defense programs in place), their locations dispersed globally, and their organizations’ profiles inconsistent.

The group attempted to deploy the first version of WannaCry ransomware to these and various other targets over the next two months, with no success or observable effort to collect bitcoin from this activity. And, even after the ETERNALBLUE spreader exploit with the DOUBLEPULSAR code and its oddly mistaken kill switch likely was hastily added to the ransomware, the attackers did not focus much more development or attention on collecting bitcoin. At one point, the actor sent a light set of messages encouraging users to pay BTC to their wallet.

This sort of inexpensive, two month long activity also may tell us a bit about the actor, their capabilities, and their interests — slow, practical, and somewhat hiding their interests in a very odd way.

While the Sony incident demonstrated the theft and use of stolen credentials and reliable lateral movement, even that credential theft itself required little effort on the part of the attackers. Entire spreadsheets of admin passwords were left open on network shares. Bizarre permission configurations were maintained within the network. The actor had little to do in order to spread a wiper with its audio-video payload to lob oddball jibes at Sony and its executives, and post  pastebin threats at movie-goers and share the company’s dirty laundry over p2p. Understanding and co-opting a software update infrastructure was unnecessary in the Sony incident. But a low-tech worming component was also built into the toolset, highly effective most likely because of a low security environment, not because of a previously 0day component.

ExPetr Deployment

ExPetr deployment was sharp, advanced, and technically agile. The group precisely targeted a major accounting software supplier to Ukrainian organizations. They also compromised a news website in UA to further waterhole targets outside the reach of the M.E.Doc network.

Once inside the M.E.Doc network, they gained access to the software update infrastructure and used that access to further steal credentials within target customer organizations. It’s interesting that delivery of the original poisoned installer occurred in April, and the large scale wiping event occurred much later. Also, not all systems receiving attempted Telebot deployments later received an ExPetr deployment. And, not all systems receiving attempted ExPetr deployments had previously received an attempted Telebot deployment.

Oddly, the two month delay in delivering the worm-enabled ExPetr variant is unexpectedly similar to the delay we saw with WannaCry. Later, they delivered the WMI/PsExec/ETERNALBLUE/ETERNALROMANCE-weaponized ExPetr sabotage variant. But in a substantial advance from Wannacry, even if Windows systems were patched, the attackers had stolen credentials for effective lateral movement and could wipe/crypt target systems. This addition also tells us that this attacker wanted to focus on effectively operating the confines of Ukrainian-connected organizations. The worming components also didn’t generate random network connections outside of the target networks. The variant included both native win64 and win32 MSVC-compiled Mimikatz-inspired components dropped to disk and run, stealing passwords for maximum privilege and spread, like those for domain admin and various network service accounts.

The ExPetr attackers apparently did not return with widely spread taunts or messages for their targets, or drag out the incident by requesting BTC transactions for disk decryption.

Comparison Table

WannaCry ExPetr Spearphishing Yes – dependent Minimal (if any) – reported initial entry Waterholing No Yes Supply side server compromise No Yes Capable of developing wormable exploit No Seemingly not Initial activity March 14 April 15 Ransomware/wiper spread date May 12 (two months later) June 27 (two months later) Targeting Global and opportunistic Focused primarily within one country ETERNALBLUE Yes Yes ETERNALROMANCE No Yes DOUBLEPULSAR Yes  Yes (minor modification) Advanced credential theft and spreading No Yes Advanced anti-malware evasion No Yes Wiper functionality No Yes Properly implemented crypto No Yes Rushed mistakes Unregistered kill switch domain Not really – possibly MBR overwrite algorithm (unlikely) Financial draw No Minimal Code sharing with other projects Yes Yes

The recent ETERNALBLUE/ETERNALROMANCE/DOUBLEPULSAR-enabled WannaCry and ExPetr incidents share similarities. Not in the sense that they were carried out by the same actor; it is most likely that they were not. One APT was rushed, opportunistic, not as technically capable as the other, while the other APT was practical, agile, and focused. But we are at the start of a trend emerging for this unusual tactic – APT camouflage destructive targeted activity behind ransomware.

More info:
Ransomware in targeted attacks
PetrWrap: the new Petya-based ransomware used in targeted attacks

The NukeBot banking Trojan: from rough drafts to real threats

Wed, 07/19/2017 - 05:20

This spring, the author of the NukeBot banking Trojan published the source code of his creation. He most probably did so to restore his reputation on a number of hacker forums: earlier, he had been promoting his development so aggressively and behaving so erratically that he was eventually suspected of being a scammer. Now, three months after the source code was published, we decided to have a look at what has changed in the banking malware landscape.

NukeBot in the wild

The publication of malware source code may be nothing new, but it still attracts attention from across the IT community and some of that attention usually goes beyond just inspecting the code. The NukeBot case was no exception: we managed to get our hands on a number of compiled samples of the Trojan. Most of them were of no interest, as they stated local subnet addresses or ‘localhost/127.0.0.1’ as the C&C address. Far fewer samples had ‘genuine’ addresses and were ‘operational’. The main functionality of this banking Trojan is to make web injections into specific pages to steal user data, but even from operational servers we only received ‘test’ injections that were included in the source code as examples.

Test injections from the NukeBot source code

The NukeBot samples that we got hold of can be divided into two main types: one with plain text strings, and the other with encrypted strings. The test samples typically belong to type 1, so we didn’t have any problems extracting the C&C addresses and other information required for analysis from the Trojan body. It was a bit more complicated with the encrypted versions – the encryption keys had to be extracted first and only after that could the string values be established. Naturally, all the above was done automatically, using scripts we had developed. The data itself is concentrated in the Trojan’s one and only procedure that is called at the very beginning of execution.

A comparison of the string initialization procedure in plain text and with encryption.

Decryption (function sub_4049F6 in the screenshot) is performed using XOR with a key.

Implementation of string decryption in Python

In order to trigger web injections, we had to imitate interaction with C&C servers. The C&C addresses can be obtained from the string initialization procedure.

When first contacting a C&C, the bot is sent an RC4 key which it uses to decrypt injections. We used this simple logic when implementing an imitation bot, and managed to collect web injections from a large number of servers.

Initially, the majority of botnets only received test injects that were of no interest to us. Later, however, we identified a number of NukeBot’s ‘combat versions’. Based on an analysis of the injections we obtained, we presume the cybercriminals’ main targets were French and US banks.

Example of ‘combat-grade’ web injections

Of all the Trojan samples we obtained, 2-5% were ‘combat-grade’. However, it is still unclear if these versions were created by a few motivated cybercriminals and the use of NukeBot will taper off soon, or if the source code has fallen into the hands of an organized group (or groups) and the number of combat-grade samples is set to grow. We will continue to monitor the situation.

We also managed to detect several NukeBot modifications that didn’t have web injection functionality, and were designed to steal mail client and browser passwords. We received those samples exclusively within droppers: after unpacking, they downloaded the required utilities (such as ‘Email Password Recovery’) from a remote malicious server.

Kaspersky Lab products detect the banking Trojans of the NukeBot family as Trojan-Banker.Win32.TinyNuke. Droppers containing this banking Trojan were assigned the verdict Trojan-PSW.Win32.TinyNuke.

MD5

626438C88642AFB21D2C3466B30F2312
697A7037D30D8412DF6A796A3297F37E
031A8139F1E0F8802FF55BACE423284F
93B14905D3B8FE67C2D552A85F06DEC9
A06A16BD77A0FCB95C2C4321BE0D2B26
0633024162D9096794324094935C62C0
9E469E1ADF9AAE06BAE6017A392B4AA9
078AA893C6963AAC76B63018EE4ECBD3
44230DB078D5F1AEB7AD844590DDC13E
FAF24FC768C43B95C744DDE551D1E191
8EBEC2892D033DA58A8082C0C949C718
6DC91FC2157A9504ABB883110AF90CC9
36EB9BDEFB3899531BA49DB65CE9894D
D2F56D6132F4B6CA38B906DACBC28AC7
79E6F689EECB8208869D37EA3AF8A7CA
9831B1092D9ACAEB30351E1DB30E8521

No Free Pass for ExPetr

Thu, 07/13/2017 - 15:55

Recently, there have been discussions around the topic that if our product is installed, ExPetr malware won’t write the special malicious code which encrypts the MFT to MBR. Some have even speculated that some kind of conspiracy might be ongoing. Others have pointed out it’s plain and simple nonsense. As usual, Vesselin Bontchev, a legend in IT security, who’s become famous for usually getting things right, said it best:

So, what is going on here? As a wise man once said, “the code doesn’t lie,” so let’s analyze the ExPetr MBR disk infection/wiping code in details.

In a nutshell, the malware does these actions:

  1. Checks administrator privileges
  2. Enumerates running processes
  3. Depending on the processes found, initialize a special runtime config
  4. Depending on this runtime config, malware execution branches are chosen

 

The malware’s main function

The “check privileges” function

An interesting fact is that malware tries to find several running processes (it calculates a hash from running process names and compares it with several hard-coded values).

Enumerating running processes

The most interesting part that happens here is:

After this condition two malicious functions could be executed:

  1. InfectMbr This routine will write the malicious GoldenEye encryptor code to the MBR. After reboot, this code will encrypt MFT and 1024 bytes of each file.
  2. WipePhysicalDrive This routine will overwrite the first 10 sectors of the disk with random trash.

Let’s describe this condition in detail:

  1. The WipePhysicalDrive function will be initiated if:
    • the special bit in runtime config is not set (that happens when malware finds the avp.exe running process).
    • the InfectMbr function fails.

This is what happens after an initial infection:


Graphic illustration of condition

Very important additions:

  1. WipePhysicalDrive could be initiated regardless of whether the avp.exe process is running or not. This function will be called when the malware could not write the malicious code to MBR. For example, it could be caused by the activity of other security solutions blocking this write.
  2. Regardless of whether MBR was infected with malicious code or was overwritten with random trash, malware will still try to encrypt the victim’s files using the AES and RSA ciphers and the attacker’s public key.

Overall, it appears that the group behind ExPetr have built what is usually called a stone soup. This is a mix of old code, new code, dirty hacks, test checks and parts of unusual code. For instance, there is a special condition block in which the AES file encryption doesn’t run at all, however, this condition is always false. It very much looks like something that was rushed out the door before it was polished and ready, from many points of view.

Why the rush, you may wonder? We do not know, but there could be several explanations. One of them could be they tried really hard to catch the EternalBlue/EternalRomance “train”. After WannaCry, a lot of organizations started patching their Windows installations to close these vulnerabilities, effectively shrinking the window of opportunity. It’s possible the authors of ExPetr wanted to infect as many targets as possible before these exploits were widely patched.

Despite the rush, the attackers were obviously aware of our technologies (and other companies’ technologies, obviously), notably System Watcher, which is extremely effective at fighting ransomware. System Watcher works by collecting information about the suspicious actions of running programs and builds a score. For instance, when a program reads a full file in memory, it then writes another file of similar size yet different format, then deletes the original, and the score increases. Other similar known bad behavior is used to increase the score and good behavior to decrease it. If multiple malicious actions happen several times, over and over, the score can reach a threshold where it’s pretty obvious that something is wrong. In that case, System Watcher warns the user and offers to terminate the offending process and restore the data.

To fight against this technology, the ExPetr authors have included multiple “counter measures.” One of them is to avoid writing the GoldenEye encryptor code to the MBR if our product is running. This is done in order to prevent raising the suspicion score and getting terminated too early. It actually seems that they put significant energy into trying to bypass our products and target our users, meaning they were pretty worried about being stopped. Nevertheless, these didn’t work too well, reinforcing the theory of a big pile of hacks, put together in a rush. The System Watcher component fires anyway and stops the file encryption, terminating the process and undoing the changes.

To conclude, our users have been protected despite the measures built into ExPetr to target them.

So why we are writing this longer explanation? With complex malware code and retro measures built to bypass antivirus products, it is complicated to understand all the functionality of today’s malware. It is easy to get tricked and believe certain code checks give a free pass to Kaspersky users. In reality, they were intended as a means of trying to pass under the System Watcher’s radar. In the end, it didn’t work. Our users do not need a free pass from ExPetr, since they have an universal “free pass” from our products and System Watcher.

The Magala Trojan Clicker: A Hidden Advertising Threat

Wed, 07/12/2017 - 05:29

One large group will slowly conquer another large group, reduce its numbers, and thus lessen its chance of further variation and improvement. <…> Small and broken groups and sub-groups will finally tend to disappear.

Charles Darwin. ‘On the Origin of Species’

The golden age of Trojans and viruses has long gone. Malicious programs created by enthusiasts for research purposes and for fun are now largely confined to history books and dusty computer incident reports. They have been replaced by programs that put a heavy emphasis on making money.

If we ignore targeted attacks prepared by professionals for very specific purposes, what sort of malware do we most often hear about today? Encryption malware and DDoS botnets made up of IoT devices. Both types are profitable for cybercriminals and relatively easy to implement. However, they are not the only types of malware capable of generating cash; we mustn’t overlook a third particularly numerous borderline malware family that includes advertising bots and modules, and partnership programs – all of which is typically referred to as potentially unwanted adware/potentially unwanted programs (PUA/PUP). They are borderline because there is a fine line between classifying a program as adware and defining the same program as an outright Trojan. In this paper, we will deal with one such renegade that has gone well beyond the limits of ‘fair play’ when it comes to advertising.

The malware in question is detected by Kaspersky Lab products as Trojan-Clicker.Win32.Magala.

Operating algorithm

Magala falls into the category of Trojan Clickers that imitate a user click on a particular webpage, thus boosting advertisement click counts. It’s worth pointing out that Magala doesn’t actually affect the user, other than consuming some of the infected computer’s resources. The main victims are those paying for the advertising; typically they are small business owners doing business with unscrupulous advertisers.

The first stage of infection involves the Trojan checking which version of Internet Explorer is installed and locating it in the system. If it’s version 8 or earlier, the Trojan won’t run. So, if you still have this version on your computer, there’s nothing to worry about.

Checking the version of Internet Explorer, virtual desktop initialization.

If the desired version of Internet Explorer is found, then, unbeknown to the user, a virtual desktop is initialized. All further activities are performed here. After that a sequence of utility operations is run (something that is typical for this malware family): autorun is set up, a report is sent to a hardcoded URL, and the required adware is installed. To interact with the content of an open page, Magala uses IHTMLDocument2, the standard Window interface that makes it easy to use DOM tree. The Trojan uses it to load MapsGalaxy Toolbar, installs it on the system and adds the site hxxp://hp.myway.com to the system registry, also associated with MapsGalaxy, so that it becomes the browser’s home page.

A simple check is incorporated into the Trojan to find out if the search bar has already been installed – this is done with the help of the appropriate registry branch.

Magala then contacts the remote server and requests a list of search queries for the click counts that need to be boosted.

Receiving the list of search queries

This list is sent ‘as is’, in a plain text file with lots of strings.

List of search queries

Using this list, the program begins to send the requested search queries and click on each of the first 10 links in the search results, with an interval of 10 seconds between each click.

Profit margin

As far as we know, an average cost per click (CPC) in a campaign like this is 0.07 USD. The cost per thousand (CPM) comes to 2.2 USD. It should be noted that Trojan Clickers are certainly not the most popular way of selling advertising: the method most in demand is the displaying of a set homepage, where each installation also costs 0.07 USD.

A botnet consisting of 1000 infected computers clicking 10 website addresses from each search result and performing some 500 search requests with no overlaps in the search results could ideally mean the virus writer earns up to 350 USD from each infected computer. However, these cost estimates are only approximations, and don’t typically occur in the real world. The costs of different requests may vary greatly, and the price of 0.07 USD per click is also an average value.

Propagation statistics

As can be seen in the diagram below, Trojan-Clicker.Win32.Magala infections occur most often in Germany and the US. This finding is corroborated by an analysis of the search requests for which the click numbers need to be boosted. These statistics were collected from March to early June 2017.

Conclusion

Programs belonging to the potentially unwanted adware class do not typically pose as much of a threat to the end user as, say, encryption or banking malware does. However, there are two characteristic features to this malware class which make it difficult to deal with. Firstly, there is the borderline functionality that blurs the lines between legitimate and malicious software. It has to be clarified whether a specific program is part of a secure and legal advertising campaign or if it is illegitimate software performing similar functions. A second important aspect of this class – its sheer quantity – also means a fundamentally different approach to any analysis is required.

MD5

1EB2D932BB916D4DB7F483859EEBABF8
206DD0B0E8FAA2D81AB617491F80AD0B
25BC675D23C2ACD5F288856F6B91818D
44A408386B983583CAEB0590433BE07B
4E4FA0B8C73889E9AA028C8FD7D7B3A5
6D3D80E89ABDED981AE329203F1779EB
6FA035264744E9C9A30409012BAB18DE
732B82A7424B60FEBB1E874B205E2D76
771E742D6C110F8BD68A7304EF93B131
A6B288A3B8C48A23092246FBBF6DB7C2
CF5A5C45778C793477ECAB02F1B3B2C3
DC16BA21BFE4838FD2A897FF13050FF4
F364B043BD6E2CC9C43F86E2004D71D3
F36672933F3CBACF8D8B396DFE259526

Bitscout – The Free Remote Digital Forensics Tool Builder

Thu, 07/06/2017 - 05:00

Being a malware researcher means you are always busy with the struggle against mountains of malware and cyberattacks around the world. Over the past decade, the number of daily new malware findings raised up to unimaginable heights: with hundreds of thousands of malware samples per day! However, while there are some rare and dangerous malware, not every sample is as malicious as these. Moreover, some of the biggest threats exist only when several ingredients are put together, including multiple malware tools, malicious infrastructure, and interactive commands coming from their operators.

This is why, instead of only looking at malware, we have started tracking groups of attackers and have focused on campaigns and isolated incidents. This has been an increasingly challenging job, because it involves searching for a needle in a haystack of haystacks, and sometimes we’re searching across very distant locations. There are different ways of undergoing searches like this, but the most reliable is that used by law enforcement agencies: full digital forensics. This procedure is time consuming, highly dependent on the availability of a skilled expert on site, and usually involves physical travelling. Our natural response to this problem is to find a solution – and surprisingly no one was offering one. Well, at least not one that was up to our standards!

My Bitscout project started years ago as a hobby. I had been playing with the creation and customisation of LiveCDs. Some time afterwards, when we needed to find traces of a certain attacker on a compromised PC in an African country, I thought I could help. I built a simple and minimal LiveCD on Linux, with a preconfigured VPN client and SSH server, and shared it with the system owner over the Internet. The owner burnt the CD and started the infected PC from it. It worked like a charm: a full control over remote computer connected via the Internet became available from my desk. It was a slow connection but it luckily for me I didn’t use a bandwidth-heavy remote desktop access. A text terminal was more than enough to do the job over a slow modem line. I managed to help the owner acquire a forensically sound disk image of the compromised system, point out the malware and related file locations and, most importantly, extract precious pieces of information, including a malware dropper and spearphishing email.

Time passed, and similar requests appeared again and again. We worked with INTERPOL using the same model: a law enforcement officer would go to the physical disk acquisition location, and with permission from local law enforcement agencies, would let us find the most important evidence on the site – instantly. This cut our time traveling and helped law enforcement with the quick discovery of key artefacts left after a cyberattack.

Bitscout booting process

Some time afterwards many new scenarios started popping up:

  1. Manually remediatiating an infected PC (from a rootkit)
  2. Sharing remote sessions let us educate new users and increase the speed of analysis
  3. Once, I traveled to a customer but I had no expensive enterprise SAS disk controller with me to complete a disk image acquisition with. Using LiveCD I was able to clone the disk via the original server hardware. And I didn’t even have to stay in the cold server room to monitor the progress!

We also worked on making the tool simple and friendly for users who are not familiar with commandline Linux environments. Still, for the sake of having a small disk size, we decided to keep away from GUI tools and X11 servers. Naturally we settled on a TUI (Text UI), which is simple to operate with just arrow keys.

Bitscout 2.0 main window for general users

However, when you work with someone who has never met you, trust is an inherent problem. Just think about it: would you let some remote expert have access to your precious system? If so, I’d be delighted to work with you. But if I were in your shoes, I would be paranoid, and would like to control the process myself. This is quite natural and is something that bothered me in the previous versions of LiveCDs.

This issue of trust could be resolved if we could somehow limit an expert’s access to hardware, and monitor and record everything that he/she does. Following this idea, we built a new version of Bitscout: Bitscout 2.0, which we have just released. The remote expert has root privileges only inside a virtual unprivileged container. The expert can access only those disk devices that are permitted by the owner, and it’s possible for them to install additional software and change system files – all without the risk of compromising the host system or data on the harddrive. This is all done in RAM, and is gone once the system is shutdown. In addition, all remote sessions are recorded and stored outside of the container. This provides a good level of isolation and a way to reconstruct the forensic process for learning purposes, or prove the existince of evidence.

But that’s not all! Bitscout 2.0 is not only based on open-source tools, it is actually an open source tool itself that let’s you build your own LiveCDs – your own types of Bitscout systems. So, the tool is essentially a collection of scripts which anyone can validate, customize and improve.

And you are welcome to do so, because now it’s on Github: https://github.com/vitaly-kamluk/bitscout

In ExPetr/Petya’s shadow, FakeCry ransomware wave hits Ukraine

Tue, 07/04/2017 - 14:22

While the (cyber-)world was still shaking under the destructive ExPetr/Petya attack that hit on June 27, another ransomware attack targeting Ukraine at the same time went almost unnoticed.

So far, all theories regarding the spread of ExPetr/Petya point into two directions:

  • Distribution via trojanized updates to MeDoc users
  • Distribution via waterhole attacks in Ukrainian news websites (one case known)

While there is little doubt that MeDoc users were infected via malicious updates with ExPetr, it appears that ExPetr was not the only malware they received. Our telemetry confirms that MeDoc users received at least one other malicious program at the same time. This additional malware, which was run as “ed.exe” in the “MeDoc” program folder (eg. c:\programdata\medoc\medoc\ed.exe) was run on victim machines by the parent process ezvit.exe, a component of the MeDoc software. This suggests the delivery mechanism abused the same MeDoc updates vector as ExPetr.

The malware, which unsurprisingly, is also ransomware, is written in .NET and includes a “WNCRY” string, which obviously refers to the massive WannaCry epidemic that hit global businesses back in May 2017.

A “forgotten” PDB path inside also points to the project’s name being “WannaCry”:

Amusingly, in what we believe to be a false flag, it pretends to be “made in China”:Based on the strings and the pretense that it’s WannaCry, we’ve decided to call this “FakeCry”.

FakeCry technical details

Sample:MD5: 0BDE638B274C7F9C6C356D3987ED1A2D
Size: 3,880,448 bytes
Compilation timestamp: Fri Jan 01 01:25:26 2016
First seen in the wild: 2017.06.27 12:34:00 (GMT)
Filename on disk: wc.exe

This program acts as a dropper for a ransomware module.

The dropper supports the following commands:

  • extract – drops the ransomware component
  • ed – begin encryption
  • dd – begin decryption
  • <Key>:
    • If ed is passed then it is a public key
    • If dd is passed then it is a private key
  • demo (encryption or decryption with hardcoded RSA keys)

The ransomware component has the following identification data:
MD5: 5C7C894A1CCFD8C8E0F174B0149A6601
Size: 442,880 bytes
Compilation timestamp: Fri Jan 01 01:20:53 2016
First seen in the wild:  2017.06.27 12:34:00 (GMT)
Filename on disk: ed.exe

The ransomware component supports the following command

  • genrsa – generate RSA-2048 key pair


  • Df – decrypt file
  • Dd – decrypt disk
  • ef- encrypt file
  • Ed – encrypt disk
  • delshadowcopies – delete shadow copies on machine

Example command line for the execution of the ransomware component:

  • exe -ed C:\ 3ds,uot,stw,sxw,ott,odt,pem,p12,csr,crt,key,pfx,der windows BgIAAACkAABSU0ExAAgA….

When run, the ransomware executes the following steps:

  1. deletes shadow copies
  2. initializes keys
  3. creates file list for encryption
  4. encrypts files
  5. shows window with the ransom demand
Keys initialization process

The malware creates a RSA key pair for encryption. The private RSA key is encrypted with the attacker’s public RSA key, which is passed via arguments.

The generated, the public RSA key and encrypted private RSA key are stored in this registry key:

  • HKCU\Software\WC
File encryption process

 List of extensions targeted for encryption:

  • doc,docx,xls,xlsx,ppt,pptx,pst,ost,msg,eml
  • vsd,vsdx,txt,csv,rtf,123,wks,wk1,pdf,dwg
  • onetoc2,snt,docb,docm,dot,dotm,dotx,xlsm,xlsb,xlw
  • xlt,xlm,xlc,xltx,xltm,pptm,pot,pps,ppsm,ppsx
  • ppam,potx,potm,edb,hwp,602,sxi,sti,sldx,sldm
  • sldm,vdi,vmdk,vmx,gpg,aes,ARC,PAQ,bz2,tbk
  • bak,tar,tgz,gz,7z,rar,zip,backup,iso,vcd
  • raw,cgm,tiff,nef,psd,ai,svg,djvu,m4u,m3u
  • mid,wma,flv,3g2,mkv,3gp,mp4,mov,avi,asf
  • mpeg,vob,mpg,wmv,fla,swf,wav,mp3,sh,class
  • jar,java,rb,asp,php,jsp,brd,sch,dch,dip
  • pl,vb,vbs,ps1,bat,cmd,js,asm,h,pas
  • cpp,c,cs,suo,sln,ldf,mdf,ibd,myi,myd
  • frm,odb,dbf,db,mdb,accdb,sql,sqlitedb,sqlite3,asc
  • lay6,lay,mml,sxm,otg,odg,uop,std,sxd,otp
  • odp,wb2,slk,dif,stc,sxc,ots,ods,3dm,max
  • 3ds,uot,stw,sxw,ott,odt,pem,p12,csr,crt,key,pfx,der

 If a file to be encrypted is locked by other processes, the ransomware can kill this process, using a Sysinternals tool (Handler Viewer) to accomplish the task.

The file encryption algorithm in a nutshell:

  • Attacker’s RSA public key is received by the ransomware via command line
  • “Session” RSA-2048 key-pair is generated
  • “Session” RSA private key is encrypted with public RSA key (which was received in point №1)
  • For each file, an AES-256 key and IV are generated
  • Key and IV are encrypted with generated “Session” RSA key and saved in the encrypted file

Interestingly, the ransomware contains a list of extensions called “DEMO_EXTENSIONS”. The attackers provide the claim that that the files from this  DEMO_EXTENSION list (which contains only image file extensions – “jpg, jpeg, png, tif, gif, bmp”) will be decrypted for free, something that appears to be working as advertised.

Here’s a screenshot of the ransomware component running on a victim machine:

To decrypt the files, the attackers are asking for 0.1BTC, which is approximately 260$ at today’s exchange price. The wallet number is fixed, 13KBb1G7pkqcJcxpRHg387roBj2NX7Ufyf for all infections. Interestingly, the wallet has received seven payments so far, totalling 0.51 BTC. Most of the 0.1 payments took place on June 26, suggesting that was the day when the attack peaked.  Interestingly, the attackers have withdrawn 0.41 BTC from the ransom account.

Transaction for wallet FakeCry

So far, there is no further activity on the receiving wallet 1FW1xW8kqNg4joJFyTnw6v5bXUNyzKXtTh.

To check the payment and receive the decryption key, the malware uses an Onion server as C2, which is “4gxdnocmhl2tzx3z[.]onion”.

Conclusions

Although the software company developing the MeDoc software has been so far denying all evidence that its users have been infected through malicious updates, our telemetry suggests that the vast majority of the ExPetr/Petya victims on June 27, 2017 were attacked this way.

Unfortunately ExPetr/Petya was not the only ransomware that was distributed via MeDoc updates on June 27. In parallel, another ransomware, FakeCry, was also distributed to MeDoc users at exactly the same time as ExPetr/Petya. Our telemetry shows about 90 attacked organizations received the FakeCry ransomware, almost all in Ukraine.

What makes FakeCry interesting is the fact that it appears to have been designed with false flags in mind. Its interface and messages closely emulate those of WannaCry, yet this is an entirely different malware. In what we believe to be a false flag, samples also include a “made in china” string.

Of course, one of the biggest questions here is if FakeCry and ExPetr are related. So far, the most important evidence that would suggest it, is the fact they were both distributed through MeDoc updates, at the same time.

As usual, our recommendations to protect against ransomware include:

Here’s our shortlist of recommendations on how to survive ransomware attacks:

  • Run a robust anti-malware suite with embedded anti-ransomware protection such as System Watcher from Kaspersky Internet Security.
  • Make sure you update Microsoft Windows and all third party software. It’s crucial to apply the MS17-010 bulletin immediately.
  • Do not run open attachments from untrusted sources.
  • Backup sensitive data to external storage and keep it offline.

Last but not least, never pay the ransom. Paying the ransom funds the next wave of attacks.

For sysadmins, our products detect the samples used in the attack by these verdicts:

  • UDS:DangerousObject.Multi.Generic
  • PDM:Trojan.Win32.Generic

Our behavior detection engine SystemWatcher detects the threat as:

  • PDM:Trojan.Win32.Generic
  • PDM:Exploit.Win32.Generic

From BlackEnergy to ExPetr

Fri, 06/30/2017 - 17:39

Much has been written about the recent ExPetr/NotPetya/Nyetya/Petya outbreak – you can read our findings here:Schroedinger’s Pet(ya) and ExPetr is a wiper, not ransomware.

As in the case of Wannacry, attribution is very difficult and finding links with previously known malware is challenging. In the case of Wannacry, Google’s Neel Mehta was able to identify a code fragment which became the most important clue in the story, and was later confirmed by further evidence, showing Wannacry as a pet project of the Lazarus group.

To date, nobody has been able to find any significant code sharing between ExPetr/Petya and older malware. Given our love for unsolved mysteries, we jumped right on it.

Analyzing the Similarities

At the beginning of the ExPetr outbreak, one of our team members pointed to the fact that the specific list of extensions used by ExPetr is very similar to the one used by BlackEnergy’s KillDisk  ransomware from 2015 and 2016 (Anton Cherepanov from ESET made the same observation on Twitter).

The BlackEnergy APT is a sophisticated threat actor that is known to have used at least one zero day, coupled with destructive tools, and code geared towards attacking ICS systems. They are widely confirmed as the entity behind the Ukraine power grid attack from 2015 as well as a chain of other destructive attacks that plagued that country over the past years.

If you are interested in reading more about the BlackEnergy APT, be sure to check our previous blogs on the topic:

Going back to the hunt for similarities, here’s how the targeted extensions lists looks in ExPetr and a version of a wiper used by the BE APT group in 2015:

ExPetr 2015 BlackEnergy wiper sample

3ds, .7z, .accdb, .ai, .asp, .aspx, .avhd, .back, .bak, .c, .cfg, .conf, .cpp, .cs, .ctl, .dbf, .disk, .djvu, .doc, .docx, .dwg, .eml, .fdb, .gz, .h, .hdd, .kdbx, .mail, .mdb, .msg, .nrg, .ora, .ost, .ova, .ovf, .pdf, .php, .pmf, .ppt, .pptx, .pst, .pvi, .py, .pyc, .rar, .rtf, .sln, .sql, .tar, .vbox, .vbs, .vcb, .vdi, .vfd, .vmc, .vmdk, .vmsd, .vmx, .vsdx, .vsv, .work, .xls

.3ds, .7z, .accdb, .accdc, .ai, .asp, .aspx, .avhd, .back, .bak, .bin, .bkf, .cer, .cfg, .conf, .crl, .crt, .csr, .csv, .dat, .db3, .db4, .dbc, .dbf, .dbx, .djvu, .doc, .docx, .dr, .dwg, .dxf, .edb, .eml, .fdb, .gdb, .git, .gz, .hdd, .ib, .ibz, .io, .jar, .jpeg, .jpg, .jrs, .js, .kdbx, .key, .mail, .max, .mdb, .mdbx, .mdf, .mkv, .mlk, .mp3, .msi, .my, .myd, .nsn, .oda, .ost, .ovf, .p7b, .p7c, .p7r, .pd, .pdf, .pem, .pfx, .php, .pio, .piz, .png, .ppt, .pptx, .ps, .ps1, .pst, .pvi, .pvk, .py, .pyc, .rar, .rb, .rtf, .sdb, .sdf, .sh, .sl3, .spc, .sql, .sqlite, .sqlite3, .tar, .tiff, .vbk, .vbm, .vbox, .vcb, .vdi, .vfd, .vhd, .vhdx, .vmc, .vmdk, .vmem, .vmfx, .vmsd, .vmx, .vmxf, .vsd, .vsdx, .vsv, .wav, .wdb, .xls, .xlsx, .xvd, .zip

Obviously, the lists are similar in composition and formatting, but not identical. Moreover, older versions of the BE destructive module have even longer lists. Here’s a snippet of an extensions list from a 2015 BE sample that is even longer:

Nevertheless, the lists were similar in the sense of being stored in the same dot-separated formats. Although this indicated a possible link, we wondered if we could find more similarities, especially in the code of older variants of BlackEnergy and ExPetr.

We continued to chase that hunch during the frenetic early analysis phase and shared this gut feeling of a similarity between ExPetr and BlackEnergy with our friends at Palo Alto Networks. Together, we tried to build a list of features that we could use to make a YARA rule to detect both ExPetr and BlackEnergy wipers.

During the analysis, we focused on the similar extensions list and the code responsible for parsing the file system for encryption or wiping. Here’s the code responsible for checking the extensions to target in the current version of ExPetr:

This works by going through the target file system in a recursive way, then checking if the extension for each file is included in the dot-separated list. Unfortunately for our theory, the way this is implemented in older BlackEnergy variants is quite different; the code is more generic and the list of extensions to target is initialized at the beginning, and passed down to the recursive disk listing function.

Instead, we took the results of automated code comparisons and paired them down to a signature that perfectly fit the mould of both in the hope of unearthing similarities. What we came up with is a combination of generic code and interesting strings that we put together into a cohesive rule to single out both BlackEnergy KillDisk components and ExPetr samples. The main example of this generic code is the inlined wcscmp function merged by the compiler’s optimization, meant to check if the filename is the current folder, which is named “.”.  Of course, this code is pretty generic and can appear in other programs that recursively list files. It’s inclusion alongside a similar extension list makes it of particular interest to us –but remains a low confidence indicator.

Looking further, we identified some other candidate strings which, although not unique, when combined together allow us to fingerprint the binaries from our case in a more precise way. These include:

  • exe /r /f
  • ComSpec
  • InitiateSystemShutdown

When put together with the wcscmp inlined code that checks on the filename, we get the following YARA rule:

rule blackenergy_and_petya_similarities { strings: //shutdown.exe /r /f $bytes00 = { 73 00 68 00 75 00 74 00 64 00 6f 00 77 00 6e 00 2e 00 65 00 78 00 65 00 } //ComSpec $bytes01 = { 43 00 6f 00 6d 00 53 00 70 00 65 00 63 00 } //InitiateSystemShutdown $bytes02 = { 49 6e 69 74 69 61 74 65 53 79 73 74 65 6d 53 68 75 74 64 6f 77 6e 45 78 57} //68A4430110 push 0100143A4 ;'ntdll.dll' //FF151CD10010 call GetModuleHandleA //3BC7 cmp eax,edi //7420 jz ... $bytes03 = { 68 ?? ?? ?1 ?0 ff 15 ?? ?? ?? ?0 3b c7 74 ?? } // "/c" $bytes04 = { 2f 00 63 00 } //wcscmp(... $hex_string = { b9 ?? ?? ?1 ?0 8d 44 24 ?c 66 8b 10 66 3b 11 75 1e 66 85 d2 74 15 66 8b 50 02 66 3b 51 02 75 0f 83 c0 04 83 c1 04 66 85 d2 75 de 33 c0 eb 05 1b c0 83 d8 ff 85 c0 0f 84 ?? 0? 00 00 b9 ?? ?? ?1 ?0 8d 44 24 ?c 66 8b 10 66 3b 11 75 1e 66 85 d2 74 15 66 8b 50 02 66 3b 51 02 75 0f 83 c0 04 83 c1 04 66 85 d2 75 de 33 c0 eb 05 1b c0 83 d8 ff 85 c0 0f 84 ?? 0? 00 00 } condition: ((uint16(0) == 0x5A4D)) and (filesize < 5000000) and (all of them) }

When run on our extensive (read: very big) malware collection, the YARA rule above fires on BlackEnergy and ExPetr samples only. Unsurprisingly, when used alone, each string can generate false positives or catch other unrelated malware. However, when combined together in this fashion, they become very precise. The technique of grouping generic or popular strings together into unique combinations is one of the most effective methods for writing powerful Yara rules.

Of course, this should not be considered a sign of a definitive link, but it does point to certain code design similarities between these malware families.

This low confidence but persistent hunch is what motivates us to ask other researchers around the world to join us in investigating these similarities and attempt to discover more facts about the origin of ExPetr/Petya. Looking back at other high profile cases, such as the Bangladesh Bank Heist or Wannacry, there were few facts linking them to the Lazarus group. In time, more evidence appeared and allowed us, and others, to link them together with high confidence. Further research can be crucial to connecting the dots, or, disproving these theories.

We’d like to think of this ongoing research as an opportunity for an open invitation to the larger security community to help nail down (or disprove) the link between BlackEnergy and ExPetr/Petya. Our colleagues at ESET have published their own excellent analysis suggesting a possible link between ExPetr/Petya and TeleBots (BlackEnergy).  Be sure to check out their analysis. And as mentioned before, a special thanks to our friends at Palo Alto for their contributions on clustering BlackEnergy samples.

Hashes

ExPetr:

027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745

BE:

11b7b8a7965b52ebb213b023b6772dd2c76c66893fc96a18a9a33c8cf125af80

5d2b1abc7c35de73375dd54a4ec5f0b060ca80a1831dac46ad411b4fe4eac4c6

F52869474834be5a6b5df7f8f0c46cbc7e9b22fa5cb30bee0f363ec6eb056b95

368d5c536832b843c6de2513baf7b11bcafea1647c65df7b6f2648840fa50f75

A6a167e214acd34b4084237ba7f6476d2e999849281aa5b1b3f92138c7d91c7a

Edbc90c217eebabb7a9b618163716f430098202e904ddc16ce9db994c6509310

F9f3374d89baf1878854f1700c8d5a2e5cf40de36071d97c6b9ff6b55d837fca

ExPetr/Petya/NotPetya is a Wiper, Not Ransomware

Wed, 06/28/2017 - 14:51

After an analysis of the encryption routine of the malware used in the Petya/ExPetr attacks, we have thought that the threat actor cannot decrypt victims’ disk, even if a payment was made.

This supports the theory that this malware campaign was not designed as a ransomware attack for financial gain. Instead, it appears it was designed as a wiper pretending to be ransomware.

Below the technical details are presented. First, in order to decrypt victim’s disk the attackers need the installation ID:

In previous versions of “similar” ransomware like Petya/Mischa/GoldenEye, this installation ID contains crucial information for the key recovery. After sending this information to the attacker they can extract the decryption key using their private key.

Here’s how this installation ID is generated in the ExPetr ransomware:

This installation ID in our test case is built using the CryptGenRandom function, which is basically generating random data.

The following buffer contains the randomly generated data in an encoded “BASE58” format:

If we compare this randomly generated data and the final installation ID shown in the first screen, they are the same. In a normal setup, this string should contain encrypted information that will be used to restore the decryption key. For ExPetr, the ID shown in the ransom screen is just plain random data.

That means that the attacker cannot extract any decryption information from such a randomly generated string displayed on the victim, and as a result, the victims will not be able to decrypt any of the encrypted disks using the installation ID.

What does it mean? Well, first of all, this is the worst-case news for the victims – even if they pay the ransom they will not get their data back. Secondly, this reinforces the theory that the main goal of the ExPetr attack was not financially motivated, but destructive.

Our friend Matt Suiche from Comae Technologies independently came to the same conclusion.

Schroedinger’s Pet(ya)

Tue, 06/27/2017 - 14:57

Earlier today (June 27th), we received reports about a new wave of ransomware attacks spreading around the world, primarily targeting businesses in Ukraine, Russia and Western Europe. If you were one of the unfortunate victims, this screen might look familiar:

Kaspersky Lab solutions successfully stop the attack through the System Watcher component. This technology protects against ransomware attacks by monitoring system changes and rolling back any potentially destructive actions.

At this time, our telemetry indicates more than 2,000 attacks:

Our investigation is ongoing and our findings are far from final at this time. Despite rampant public speculation, the following is what we can confirm from our independent analysis:

How does the ransomware spread?

To capture credentials for spreading, the ransomware uses custom tools, a la Mimikatz. These extract credentials from the lsass.exe process. After extraction, credentials are passed to PsExec tools or WMIC for distribution inside a network.

Other observed infection vectors include:

  • A modified EternalBlue exploit, also used by WannaCry.
  • The EternalRomance exploit – a remote code execution exploit targeting Windows XP to Windows 2008 systems over TCP port 445 (Note: patched with MS17-010).
  • An attack against the update mechanism of a third-party Ukrainian software product called MeDoc.

IMPORTANT: A single infected system on the network possessing administrative credentials is capable of spreading this infection to all the other computers through WMI or PSEXEC.

What does the ransomware do?

The malware waits for 10-60 minutes after the infection to reboot the system. Reboot is scheduled using system facilities with “at” or “schtasks” and “shutdown.exe” tools.

Once it reboots, it starts to encrypt the MFT table in NTFS partitions, overwriting the MBR with a customized loader with a ransom note. More details on the ransom note below.

Network survey

The malware enumerates all network adapters, all known server names via NetBIOS and also retrieves the list of current DHCP leases, if available. Each and every IP on the local network and each server found is checked for open TCP ports 445 and 139. Those machines that have these ports open are then attacked with one of the methods described above.

Password extraction

Resources 1 and 2 of malware binary contain two versions of a standalone tool (32-bit and 64-bit) that tries to extract logins and passwords of logged on users. The tool is run by the main binary. All extracted data is transferred back to the main module via a named pipe with a random GUID-like name.

File Decryption

Are there any hopes of decrypting files for victims already infected? Unfortunately, the ransomware uses a standard, solid encryption scheme so this appears unlikely unless a subtle implementation mistake has been made. The following specifics apply to the encryption mechanism:

  • For all files, one AES-128 key is generated.
  • This AES key is encrypted with threat actors’ public RSA-2048 key.
  • Encrypted AES keys are saved to a README file.
  • Keys are securely generated.

The criminals behind this attack are asking for $300 in Bitcoins to deliver the key that decrypts the ransomed data, payable to a unified Bitcoin account. Unlike Wannacry, this technique would work because the attackers are asking the victims to send their wallet numbers by e-mail to “wowsmith123456@posteo.net”, thus confirming the transactions. We have seen reports this email account has already been shut down, effectively making the full chain decryption for existing victims impossible at this time.

At the time of writing, the Bitcoin wallet has accrued 24 transactions totalling 2.54 BTC or just under $6,000 USD.

Here’s our shortlist of recommendations on how to survive ransomware attacks:

  • Run a robust anti-malware suite with embedded anti-ransomware protection such as System Watcher from Kaspersky Internet Security.
  • Make sure you update Microsoft Windows and all third party software. It’s crucial to apply the MS17-010 bulletin immediately.
  • Do not run open attachments from untrusted sources.
  • Backup sensitive data to external storage and keep it offline.

For sysadmins, our products detect the samples used in the attack by these verdicts:

  • Trojan-Ransom.Win32.PetrWrap.d
  • HEUR:Trojan-Ransom.Win32.PetrWrap.d
  • PDM:Trojan.Win32.Generic
  • UDS: DangerousObject.Multi.Generic
  • Intrusion.Win.MS17-010.e
IOCs

71B6A493388E7D0B40C83CE903BC6B04
0df7179693755b810403a972f4466afb
42b2ff216d14c2c8387c8eabfb1ab7d0
E595c02185d8e12be347915865270cca
e285b6ce047015943e685e6638bd837e

Yara rules


rule ransomware_PetrWrap {
meta:

copyright = "Kaspersky Lab"
description = "Rule to detect PetrWrap ransomware samples"
last_modified = "2017-06-27"
author = "Kaspersky Lab"
hash = "71B6A493388E7D0B40C83CE903BC6B04"
version = "1.0"

strings:

$a1 = "MIIBCgKCAQEAxP/VqKc0yLe9JhVqFMQGwUITO6WpXWnKSNQAYT0O65Cr8PjIQInTeHkXEjfO2n2JmURWV/uHB0ZrlQ/wcYJBwLhQ9EqJ3iDqmN19Oo7NtyEUmbYmopcq+YLIBZzQ2ZTK0A2DtX4GRKxEEFLCy7vP12EYOPXknVy/+mf0JFWixz29QiTf5oLu15wVLONCuEibGaNNpgq+CXsPwfITDbDDmdrRIiUEUw6o3pt5pNOskfOJbMan2TZu" fullword wide
$a2 = ".3ds.7z.accdb.ai.asp.aspx.avhd.back.bak.c.cfg.conf.cpp.cs.ctl.dbf.disk.djvu.doc.docx.dwg.eml.fdb.gz.h.hdd.kdbx.mail.mdb.msg.nrg.ora.ost.ova.ovf.pdf.php.pmf.ppt.pptx.pst.pvi.py.pyc.rar.rtf.sln.sql.tar.vbox.vbs.vcb.vdi.vfd.vmc.vmdk.vmsd.vmx.vsdx.vsv.work.xls" fullword wide
$a3 = "DESTROY ALL OF YOUR DATA! PLEASE ENSURE THAT YOUR POWER CABLE IS PLUGGED" fullword ascii
$a4 = "1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX" fullword ascii
$a5 = "wowsmith123456@posteo.net." fullword wide

condition:

uint16(0) == 0x5A4D and
filesize < 1000000 and any of them }

Neutrino modification for POS-terminals

Tue, 06/27/2017 - 07:01

From time to time authors of effective and long-lived Trojans and viruses create new modifications and forks of them, like any other software authors. One of the brightest examples amongst them is Zeus (Trojan-Spy.Win32.Zbot, based on classification of “Kaspersky Lab”), which continues to spawn new modifications of itself each year. In a strange way this malware becomes similar to his prototype from Greek mythology. We can also attribute such malware familes as Mirai, NJRat, Andromeda and so on to this “prolific” group. Malware named “Neutrino” takes an important place in this row of well-known trojans, providing various types of infection, spreading and a useful payload.

In this article we analyze a very special species – a variant which could collect credit card information from POS.

Products of “Kaspersky Lab” detect it as Trojan-Banker.Win32.NeutrinoPOS

MD5 of descripted file: 0CF70BCCFFD1D2B2C9D000DE496D34A1

First stage

The Trojan takes a long “sleep” before it starts. It seems that such code was added to fool some AV sandboxes. To determine the period of delay, the Trojan uses a pseudorandom number generator.

C&C Communication

At the next stage, the Trojan extracts a C&C-address list from its body. The list is encoded at Base64. After decoding, the Trojan tries to find a working C&C, using the following algorithm:

  • Sends POST-request to server, passing through its body encoding in base64 string “enter” (ZW50ZXI=). All encoded strings contains prefix “_wv=”
  • Working server responds with 404 page, which contains at the end of it encoded string c3VjY2Vzcw== (success). In case of “success”, the rTojan marks the address of the used servers as working.

We should also notice that in the header of each POST-request there is “auth” field, which stays the same for each sample from family NeutrinoPOS.

Restored code of C&C-server check

 

The C&C address stored at registry branch HKCR\Sofrware\alFSVWJBis the same as other variables and data usedby NeutrinoPOS sample. Branch name differs from the one described here, but after full comparison of both samples, we can claim that both samples are the same modification of Neutrino.

C&C Commands

The described variant contains listed functions:

  • Download and start file;
  • Make screenshot;
  • Search process by name;
  • Change register branches;
  • Search file by name on infected host and send it to C&C;
  • Proxy

The server sends commands in plain view, like “PROXY”, “screenshot” and so on, encoded in base64. Following analysis we can claim that in the current versions of Neutrino there is no functions for DDOS attacks.

Implementation of command control sum calculating

 

Examples of few commands (marked with red line on screenshot above):

  • Rolxor(“PROXY”) = 0xA53EC5C
  • Rolxor(“screenshot”) = 0xD9FA0E3

NeutrinoPOS command handler

 

Stealing of credit cards

The algorithm for stealing credit card information is implemented in the Trojan in quite a simple way and described as follows:

  1. The Trojans start to work through currently running processes, using CreateToolhelp32Snapshot\ Process32FirstW\Process32NextW.
  2. Using OpenProcess\VirtualQuery\ReadProcessMemory, the Trojan gets information about the memory pages of the process.
  3. The Trojan scans the memory pages for string “Track1”, which marks fields of the first track of the magnetic card. All described fields going one by one:
    • Sequence of symbols in range from ‘0’ to ‘9’ with length equal to 15, 16 or 19. Sequence checking with Luhn algorithm.
    • Check presence of separation symbol ‘^’ in next and previous fields.
    • Extract card holder name, with max length, basing on ISO/IEC 7813, equal to 26 symbols:
    • Rest data (CVC32, expiration date, CVV) extracts as whole block, with check of length and content :
  4. Collected data sends to server with mark “Track1”.
  5. After that, the Trojan starts to extracts next fields with mark “Track2” at the beginning:
    • At firsts, it extracts PAN with the same checks as on the previous stage.
    • As separation symbol using ” ‘ ” or ‘D’
    • Track2 doesn’t contains card holder name — rest data extracts as whole block
  6. Collected data sent to server with mark “Track2”
Distribution Statistics

The largest areas of infection are Russia and Kazakhstan. Nearly 10% of infected computers belong to small business corporate customers.

Conclusion

As we can see from the described Trojan Neutrino, despite belonging to an old, well-known and researched family, it continues to bring various surprises to malware analysts and researchers in the form of atypical functionality or application. We can see the same situation with Mirai forks, for example, which generate an enormous count across all platforms and in different species

Generally speaking, all publications of malware source code with good architecture and various functionality will cause interest and attention from malware authors, who will try to use it for nearly all possible ways of illegal money gain. We can assume that right now there may already be new modifications of Neutrino with functionality for crypto-currency mining.

MD5

CECBED938B10A6EEEA21EAF390C149C1

66DFBA01AE6E3AFE914F649E908E9457

4DB70AE71452647E87380786E065F31E

9D70C5CDEDA945CE0F21E76363FE13C5

B682DA77708EE148B914AAEC6F5868E1

5AA0ADBD3D2B98700B51FAFA6DBB43FD

A03BA88F5D70092BE64C8787E7BC47DE

D18ACF99F965D6955E2236645B32C491

3B6211E898B753805581BB41FB483C48

7D28D392BED02F17094929F8EE84234A

C2814C3A0ACB1D87321F9ECFCC54E18C

74404316D9BAB5FF2D3E87CA97DB5F0C

7C6FF28E0C882286FBBC40F27B6AD248

729C89CB125DF6B13FA2666296D11B5A

855D3324F26BE1E3E3F791C29FB06085

2344098C7FA4F859BE1426CE2AD7AE8E

C330C636DE75832B4EC78068BCF0B126

CCBDB9F4561F9565F049E43BEF3E422F

53C557A8BAC43F47F0DEE30FFFE88673

C&C

hxxp://pranavida.cl/director/tasks.php

hxxps://5.101.4.41/panel/tasks.php

hxxps://5.101.4.41/updatepanel/tasks.php

hxxp://jkentnew.5gbfree.com/p/tasks.php

hxxp://124.217.247.72/tasks.php

hxxp://combee84.com/js/css/tasks.php

hxxp://nut29.xsayeszhaifa.bit/newfiz29/logout.php

hxxp://nut29.nsbacknutdoms11war.com/newfiz29/logout.php

hxxp://jbbrother.com/jbb/meaca/obc/pn/tasks.php

hxxp://ns1.posnxqmp.ru/PANEL/tasks.php

hxxp://nut25.nsbacknutdoms11war.com/newfiz25/logout.php

hxxp://propertiesofseyshellseden.com/newfiz21/logout.php

hxxp://n31.propertiesofseyshellseden.com/newfiz31/logout.php

hxxp://propertiesofseyshellseden.com/newfiz21/logout.php

hxxp://n31.propertiesofseyshellseden.com/newfiz31/logout.php

KSN Report: Ransomware in 2016-2017

Mon, 06/26/2017 - 05:00

This report has been prepared using depersonalized data processed by Kaspersky Security Network (KSN). The metrics are based on the number of distinct users of Kaspersky Lab products with the KSN feature enabled, who encountered ransomware at least once in a given period, as well as research into the ransomware threat landscape by Kaspersky Lab experts.

This report covers the evolution of the threat from April 2016 to March 2017 and compares it with the period of April 2015 to March 2016.

A brief look at ransomware evolution over a year The rise of Ransomware-as-a-Service

In May 2016 Kaspersky Lab discovered Petya ransomware that not only encrypts data stored on a computer, but also overwrites the hard disk drive’s master boot record (MBR), leaving infected computers unable to boot into the operating system.

The malware is a notable example of the Ransomware-as-a-Service model, when ransomware creators offer their malicious product ‘on demand’, spreading it by multiple distributors and getting a cut of the profits. In order to get their part of the profit, the Petya authors inserted certain “protection mechanisms” into their malware that do not allow the unauthorized use of Petya samples.

While Ransomware-as-a-Service is not a new trend, this propagation model continues to develop, with more and more ransomware creators offering their malicious product. This approach has proved immensely appealing to criminals who lack the skills, resources or inclination to develop their own malware.

Notable examples of ransomware that appeared in 2016 and used this model were Petya/Mischa and Shark ransomware, which was later rebranded under the name Atom.

The growth of targeted attacks

In early 2017, Kaspersky Lab’s researchers have discovered an emerging and dangerous trend: more and more cybercriminals are turning their attention from attacks against private users to targeted ransomware attacks against businesses.

The attacks are primarily focused on financial organizations worldwide. Kaspersky Lab’s experts have encountered cases where payment demands amounted to over half a million dollars.

The trend is alarming as ransomware actors start their crusade for new and more profitable victims. There are many more potential ransomware targets in the wild, with attacks resulting in even more disastrous consequences.

The analysis in this report attempts to assess the scale of the problem, and to highlight possible reasons for the new angles of ransomware developments globally.

Main numbers
  • The total number of users who encountered ransomware between April 2016 and March 2017 rose by 11.4% compared to the previous 12 months (April 2015 to March 2016) – from 2,315,931 to 2,581,026 users around the world;
  • The proportion of users who encountered ransomware at least once out of the total number of users who encountered malware fell by almost 0.8 percentage points, from 4.34% in 2015-2016 to 3.88% in 2016-2017;
  • Among those who encountered ransomware, the proportion who encountered cryptors rose by 13.6 percentage points, from 31% in 2015-2016 to 44.6% in 2016-2017;
  • The number of users attacked with cryptors rose almost twice, from 718,536 in 2015-2016 to 1,152,299 in 2016-2017;
  • The number of users attacked with mobile ransomware fell by 4.62% from 136,532 users in 2015-2016 to 130,232.
Conclusions and predictions

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

  • Ransomware actors are starting to devour each other. This is a sign of growing competition between ransomware gangs.
  • The geography statistics show that attackers switch to previously unreached countries, where users are not as well prepared for fighting ransomware, and where competition among criminals is not so high.
  • The worrying thing here is the fact that ransomware attacks are becoming increasingly targeted, hitting financial infrastructure across the globe. The reason for the trend is clear – criminals consider targeted ransomware attacks against businesses potentially more profitable than mass attacks against private users.
  • The numbers show that ransomware on PCs are still on the rise – albeit at a slower growth rate.
  • Moreover, the number of users attacked with mobile ransomware in the observed period fell. This could be a sign of successful collaboration between vendors of security solutions, various law enforcement agencies, and other actors. Increased threat awareness, fueled by global media coverage on the most prominent fraudulent campaigns can also have a part to play.
  • Another reason is the development of joint industry efforts to protect users from encryption ransomware.
  • Although the statistics show that attacks with ransomware operate on a massive scale, responsibility for most of the mobile attacks rests with just a few groups of malware, most of them spread via affiliate programs. At the same time, PC ransomware shows quite the opposite status, with a lot of malicious actors in the wild conducting ad hoc attacks.

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

Predictions
  • The extortion model is here to stay. More stable growth, which is at a higher level on average, could indicate an alarming trend: a shift from chaotic and sporadic actors’ attempts to gain foothold in threat landscape, to steadier and higher volumes.
  • Given the signs of growing competition on the ransomware market, Ransomware-as-a-Service is also becoming more and more popular, attracting new actors.
  • Ransomware is growing in sophistication and diversity, offering a lot of ready-to-go solutions to those with fewer skills, resources or time – through a growing and increasingly efficient underground ecosystem.
  • Development of criminal-to-criminal infrastructure is fueling the emergence of easy-to-go, ad hoc tools to perform targeted attacks and extort money, making attacks more dispersed. This trend has already taken place and will likely continue in the future.
  • Global initiatives which protect users from encryption ransomware will keep gaining momentum.
Fighting back

Through technology: Kaspersky Lab provides a free anti-ransomware tool which is available for all businesses to download and use, regardless of the security solution they have installed.

Through collaboration: The No More Ransom Initiative. On 25 July 2016, the Dutch National Police, Europol, Intel Security and Kaspersky Lab announced the launch of the No More Ransom project – a non-commercial initiative that unites public and private organizations and aims to inform people of the dangers of ransomware and help them to recover their data. The online portal currently carries 50 decryption tools, seven of which were made by Kaspersky Lab. Since the NMR launch, more than 29.000 victims from all over the world have been able to unlock their files for free thanks to Kaspersky Lab tools. The NMR portal is currently available in 14 languages: English, Dutch, French, Italian and Portuguese, German, Spanish, Slovenian, Finnish, Hebrew, Ukrainian, Korean, and Japanese.

KSN Report: Ransomware in 2016-2017 (full report, English):

MktoForms2.loadForm("//app-sj06.marketo.com", "802-IJN-240", 12737);

Ztorg: from rooting to SMS

Tue, 06/20/2017 - 05:01

I’ve been monitoring Google Play Store for new Ztorg Trojans since September 2016, and have so far found several dozen new malicious apps. All of them were rooting malware that used exploits to gain root rights on the infected device.

Then, in the second half of May 2017 I found one that wasn’t. Distributed on Google Play through two malicious apps, it is related to the Ztorg Trojans, although not a rooting malware but a Trojan-SMS that can send Premium rate SMS and delete incoming SMS. The apps had been installed from Google Play more than 50,000 and 10,000 times respectively.

Kaspersky Lab products detect the two Trojan apps as Trojan-SMS.AndroidOS.Ztorg.a. We reported the malware to Google, and both apps have been deleted from the Google Play Store.

The first malicious app, called “Magic browser” was uploaded to Google Play on May 15, 2017 and was installed more than 50,000 times.

Trojan-SMS.AndroidOS.Ztorg.a on Google Play Store

The second app, called “Noise Detector”, with the same malicious functionality, was installed more than 10,000 times.

Trojan-SMS.AndroidOS.Ztorg.a on Google Play Store

What can they do?

After starting, the Trojan will wait for 10 minutes before connecting to its command and control (C&C) server. It uses an interesting technique to get commands from the C&C: it makes two GET requests to the C&C, and in both includes part of the International Mobile Subscriber Identity (IMSI). The first request will look like this:

GET c.phaishey.com/ft/x250_c.txt, where 250 – first three digits of the IMSI.

If the Trojan receives some data in return, it will make the second request. The second request will look like this:

GET c.phaishey.com/ft/x25001_0.txt, where 25001 – first five digits of the IMSI.

Why does the Trojan need these digits from the IMSI?

The interesting thing about the IMSI is that the first three digits are the MCC (mobile country code) and the third and fourth digits are the MNC (mobile network code). Using these digits, the cybercriminals can identify the country and mobile operator of the infected user. They need this to choose which premium rate SMS should be sent.

In answer to these requests, the Trojan may receive an encrypted JSON file with some data. This data should include a list of offers, and every offer carries a string field called ‘url’, which may or may not contain an actual url. The Trojan will try to open/view the field using its own class. If this value is indeed a url, the Trojan will show its content to the user. But if it is something else and carries an “SMS” substring, the user will send an SMS containing the text supplied to the number provided.

Malicious code where the Trojan decides if it should send an SMS.

This is an unusual way to send SMS. Just after it receives urls to visit, or SMS to send, the Trojan will turn off the device sound, and start to delete all incoming SMS.

I wasn’t able to get any commands for the Trojans distributed through Google Play. But for other Trojans located elsewhere that have the same functionality, I got the command:

{“icon”:”http://down.rbksbtmk.com/pic/four-dault-06.jpg”,”id”:”-1″,”name”:”Brower”,”result”:1,”status”:1,”url”:”http://global.621.co/trace?offer_id=111049&aff_id=100414&type=1″}

It was a regular advertising offer.

WAP billing subscriptions

I was able to find several more malicious apps with the same functionality distributed outside the Google Play Store. The interesting thing is that they don’t look like standalone Trojans, more like an additional module for some Trojan.

Further investigation revealed that these Trojans were installed by a regular Ztorg Trojan along with other Ztorg modules.

In a few of these Trojans, I found that they download a JS file from the malicious url using the MCC.

Malicious code where the Trojan downloads a JS file.

I downloaded several JS files, using different MCC’s, to find out what cybercriminals are going to do with users from a different countries. I wasn’t able to get a file for a US MCC, but for other countries that I tried I received files with some functions. All the files contain a function called “getAocPage” which most likely references AoC – Advice of Charge. After analyzing these files, I found out that their main purpose is to perform clickjacking attacks on web pages with WAP billing. In doing so, the Trojan can steal money from the user’s mobile account. WAP billing works in a similar way to Premium rate SMS, but usually in the form of subscriptions and not one-time payments as most Premium rate SMS.

JS file from a CnC for Russian users (MCC = 250)

It means that urls which the Trojan receives from the CnC may not only be advertising urls, but also urls with WAP billing subscriptions. Furthermore some Trojans with this functionality use CnC urls that contain “/subscribe/api/” which may reference subscriptions too.

All of these Trojans, including Trojans from Google Play, are trying to send SMS from any device. To do so they are using lots of methods to send SMS:

Part of the “Magic browser” app’s code

In total, the “Magic browser” app tries to send SMS from 11 different places in its code. Cybercriminals are doing this in order to be able to send SMS from different Android versions and devices. Furthermore, I was able to find another modification of the Trojan-SMS.AndroidOS.Ztorg that is trying to send an SMS via the “am” command, although this approach should not work.

Connection with the Ztorg malware family

The “Magic browser” app was promoted in a similar way to other Ztorg Trojans. Both the Magic browser” and “Noise detector” apps shared code similarities with other Ztorg Trojans. Furthermore, the latest version of the “Noise detector” app contains the encrypted file “girl.png” in the assets folder of the installation package. After decryption, this file become a Ztorg Trojan.

I found several more Trojans with the same functionality that were installed by a regular Ztorg Trojan along with the other Ztorg modules. And it isn’t the first case where additional Ztorg modules were distributed from Google Play as a standalone Trojan. In April 2017, I found that a malicious app called “Money Converter”, had been installed more than 10,000 times from Google Play. It uses Accessibility Services to install apps from Google Play. Therefore, the Trojan can silently install and run promoted apps without any interaction with the user, even on updated devices where it cannot gain root rights.

Trojan-SMS vs. rooting

There were two malicious apps on Google Play with the same functionality – “Noise Detector” and “Magic browser” but I think that they each had a different purpose. “Magic browser” was uploaded first and I assume that the cybercriminals were checking if they were able to upload this kind of functionality. After they uploaded the malicious app they didn’t update it with newer versions.

But it is a different story with “Noise Detector” – here it looks like the cybercriminals were trying to upload an app infected with a regular version of the Ztorg Trojan. But in the process of uploading they decided to add some malicious functionality to make money while they were working on publishing the rooting malware. And the history of “Noise Detector” updates prove it.

On May 20 they uploaded a clean app called “Noise Detector”. A few days later they updated it with another clean version.

Then, a few days after that, they uploaded a version to Google Play that contained an encrypted Ztorg Trojan, but without the possibility of decrypting and executing it. On the following day they finally updated their app with the Trojan-SMS functionality, but still didn’t add the possibility to execute the encrypted Ztorg module. It is likely that, if the app hadn’t been removed from Google Play, they would have added this functionality at the next stage. There is also the possibility that attempting to add this functionality is what alerted Google to the Trojan’s presence and resulted in its deletion.

Conclusions

We found a very unusual Trojan-SMS being distributed through Google Play. It not only uses around a dozen methods to send SMS, but also initializes these methods in an unusual way: by processing web-page loading errors using a command from the CnC. And it can open advertising urls. Furthermore, it is related to Ztorg malware with the same functionality, that is often installed by Ztorg as an additional module.

By analyzing these apps I found that cybercriminals are working on clickjacking WAP billing. It means that these Trojans may not only open ad urls, or send Premium rate SMS, but also open web-pages with WAP billing and steal money from a user’s account. To hide these activities the Trojans turn off the device sound and delete all incoming SMS.

This isn’t the first time that the cybercriminals distributed Ztorg modules through Google Play. For example, on April 2017 they uploaded a module that can click on Google Play Store app buttons to install or even buy promoted apps.

Most likely, the attackers are publishing Ztorg modules to make some additional money while they are trying to upload the regular rooting Ztorg Trojan. I suggest this because one of the malicious apps had an encrypted Ztorg module but it wasn’t able to decrypt it.

MD5
  • F1EC3B4AD740B422EC33246C51E4782F
  • E448EF7470D1155B19D3CAC2E013CA0F
  • 55366B684CE62AB7954C74269868CD91
  • A44A9811DB4F7D39CAC0765A5E1621AC
  • 1142C1D53E4FBCEFC5CCD7A6F5DC7177

Honeypots and the Internet of Things

Mon, 06/19/2017 - 05:08

There were a number of incidents in 2016 that triggered increased interest in the security of so-called IoT or ‘smart’ devices. They included, among others, the record-breaking DDoS attacks against the French hosting provider OVH and the US DNS provider Dyn. These attacks are known to have been launched with the help of a massive botnet made up of routers, IP cameras, printers and other devices.

Last year the world also learned of a colossal botnet made up of nearly five million routers. The German telecoms giant Deutsche Telekom also encountered router hacking after the devices used by the operator’s clients became infected with Mirai. The hacking didn’t stop at network hardware: security problems were also detected in smart Miele dishwashers and AGA stoves. The ‘icing on the cake’ was the BrickerBot worm that didn’t just infect vulnerable devices like most of its ‘peers’ but actually rendered them fully inoperable.

According to Gartner, there are currently over 6 billion IoT devices on the planet. Such a huge number of potentially vulnerable gadgets could not possibly go unnoticed by cybercriminals. As of May 2017, Kaspersky Lab’s collections included several thousand different malware samples for IoT devices, about half of which were detected in 2017.

The number of IoT malware samples detected each year (2013 – 2017)

Threat to the end user

If there is an IoT device on your home network that is poorly configured or contains vulnerabilities, it could cause some serious problems. The most common scenario is your device ending up as part of a botnet. This scenario is perhaps the most innocuous for its owner; the other scenarios are more dangerous. For example, your home network devices could be used to perform illegal activities, or a cybercriminal who has gained access to an IoT device could spy on and later blackmail its owner – we have already heard of such things happening. Ultimately, the infected device can be simply broken, though this is by no means the worst thing that can happen.

The main problems of smart devices Firmware

In the best-case scenario, device manufacturers are slow to release firmware updates for smart devices. In the worst case, firmware doesn’t get updated at all, and many devices don’t even have the ability to install firmware updates.

Software on devices may contain errors that cybercriminals can exploit. For example, the Trojan PNScan (Trojan.Linux.PNScan) attempted to hack routers by exploiting one of the following vulnerabilities:

  • CVE-2014-9727 for attacking Fritz!Box routers;
  • A vulnerability in HNAP (Home Network Administration Protocol) and the vulnerability CVE-2013-2678 for attacking Linksys routers;
  • ShellShock (CVE-2014-6271).

If any of these worked, PNScan infected the device with the Tsunami backdoor.

The Persirai Trojan exploited a vulnerability present in over 1000 different models of IP cameras. When successful, it could run arbitrary code on the device with super-user privileges.

There’s yet another security loophole related to the implementation of the TR-069 protocol. This protocol is designed for the operator to remotely manage devices, and is based on SOAP which, in turn, uses the XML format to communicate commands. A vulnerability was detected within the command parser. This infection mechanism was used in some versions of the Mirai Trojan, as well as in Hajime. This was how Deutsche Telekom devices were infected.

Passwords, telnet and SSH

Another problem is preconfigured passwords set by the manufacturer. They can be the same not just for one model but for a manufacturer’s entire product range. Furthermore, this situation has existed for so long that the login/password combinations can easily be found on the Internet – something that cybercriminals actively exploit. Another factor that makes the cybercriminal’s work easier is that many IoT devices have their telnet and/or SSH ports available to the outside world.

For instance, here is a list of login/password combinations that one version of the Gafgyt Trojan (Backdoor.Linux.Gafgyt) uses:

root root root – telnet telnet !root – support support supervisor zyad1234 root antslq root guest12345 root tini root letacla root Support1234 Statistics

We set up several honeypots (traps) that imitated various devices running Linux, and left them connected to the Internet to see what happened to them ‘in the wild’. The result was not long in coming: after just a few seconds we saw the first attempted connections to the open telnet port. Over a 24-hour period there were tens of thousands of attempted connections from unique IP addresses.

Number of attempted attacks on honeypots from unique IP addresses. January-April 2017.

In most cases, the attempted connections used the telnet protocol; the rest used SSH.

Distribution of attempted attacks by type of connection port used. January-April 2017

Below is a list of the most popular login/password combinations that malware programs use when attempting to connect to a telnet port:

User Password root xc3511 root vizxv admin admin root admin root xmhdipc root 123456 root 888888 root 54321 support support root default root root admin password root anko root root juantech admin smcadmin root 1111 root 12345 root pass admin admin1234

Here is the list used for SSH attacks. As we can see, it is slightly different.

User Password admin default admin admin support support admin 1111 admin user user Administrator admin admin root root root root admin ubnt ubnt admin 12345 test test admin <Any pass> admin anypass administrator admin 1234 root password root 123456

Now, let’s look at the types of devices from which the attacks originated. Over 63% of them could be identified as DVR services or IP cameras, while about 20% were different types of network devices and routers from all the major manufacturers. 1% were Wi-Fi repeaters and other network hardware, TV tuners, Voice over IP devices, Tor exit nodes, printers and ‘smart-home’ devices. About 20% of devices could not be identified unequivocally.

Distribution of attack sources by device type. January-April 2017

Most of the IP addresses from which attempted connections arrived at our honeypots respond to HTTP requests. Typically, there are several devices using each IP address (NAT technology is used). The device responding to the HTTP request is not always the device that attacked our honeypot, though that is usually the case.

The response to such a request was a web page – a device control panel, some form of monitoring, or maybe a video from a camera. With this returned page, it is possible to try and identify the type of device. Below is a list of the most frequent headers for the web pages returned by the attacking devices:

HTTP Title Device % NETSurveillance WEB 17.40% DVR Components Download 10.53% WEB SERVICE 7.51% main page 2.47% IVSWeb 2.0 – Welcome 2.21% ZXHN H208N V2.5 2.04% Web Client 1.46% RouterOS router configuration page 1.14% NETSuveillance WEB 0.98% Technicolor 0.77% Administration Console 0.77% MГіdem – Inicio de sesiГіn 0.67% NEUTRON 0.58% Open Webif 0.49% hd client 0.48% Login Incorrect 0.44% iGate GW040 GPON ONT 0.44% CPPLUS DVR – Web View 0.38% WebCam 0.36% GPON Home Gateway 0.34%

We only see a portion of the attacking devices at our honeypots. If we need an estimate of how many devices there are globally of the same type, dedicated search services like Shodan or ZoomEye can help out. They scan IP ranges for supported services, poll them and index the results. We took some of the most frequent headers from IP cameras, DVRs and routers, and searched for them in ZoomEye. The results were impressive: millions of devices were found that potentially could be (and most probably are) infected with malware.

Numbers of IP addresses of potentially vulnerable devices: IP cameras and DVRs.

HTTP Title Devices WEB SERVICE 2 785 956 NETSurveillance WEB 1 621 648 dvrdvs 1 569 801 DVR Components Download 1 210 111 NetDvrV3 239 217 IVSWeb 55 382 Total 7 482 115

Numbers of IP addresses of potentially vulnerable devices: routers

HTTP Title Devices Eltex NTP 2 653 RouterOS router 2 124 857 GPON Home Gateway 1 574 074 TL-WR841N 149 491 ZXHN H208N 79 045 TD-W8968 29 310 iGate GW040 GPON ONT 29 174 Total 3 988 604

Also noteworthy is the fact that our honeytraps not only recorded attacks coming from network hardware classed as home devices but also enterprise-class hardware.

Even more disturbing is the fact that among all the IP addresses from which attacks originated there were some that hosted monitoring and/or device management systems with enterprise and security links, such as:

  • Point-of-sale devices at stores, restaurants and filling stations
  • Digital TV broadcasting systems
  • Physical security and access control systems
  • Environmental monitoring devices
  • Monitoring at a seismic station in Bangkok
  • Industry-grade programmable microcontrollers
  • Power management systems

We cannot confirm that it is namely these types of devices that are infected. However, we have seen attacks on our honeypots arriving from the IP addresses used by these devices, which means at least one or more devices were infected on the network where they reside.

Geography of infected devices

If we look at the geographic distribution of the devices with the IP addresses that we saw attacking our honeypots, we see the following:

Breakdown of attacking device IP addresses by country. January-April 2017

As we mentioned above, most of the infected devices are IP cameras and DVRs. Many of them are widespread in China and Vietnam, as well as in Russia, Brazil, Turkey and other countries.

Geographical distribution of server IP addresses from which malware is downloaded to devices

So far in 2017, we have recorded over 2 million hacking attempts and more than 11,000 unique IP addresses from which malware for IoT devices was downloaded.

Here is the breakdown by country of these IP addresses (Top 10):

Country Unique IPs Vietnam 2136 Taiwan, Province of China 1356 Brazil 1124 Turkey 696 Korea, Republic of 620 India 504 United States 429 Russian Federation 373 China 361 Romania 283

If we rank the countries by the number of downloads, the picture changes:

Country Downloads Thailand 580267 Hong Kong 367524 Korea, Republic of 339648 Netherlands 271654 United States 168224 Seychelles 148322 France 68648 Honduras 36988 Italy 20272 United Kingdom 16279

We believe that this difference is due to the presence in some of these countries of bulletproof servers, meaning it’s much faster and easier to spread malware than it is to infect IoT devices.

Distribution of attack activity by days of the week

When analyzing the activities of IoT botnets, we looked at certain parameters of their operations. We found that there are certain days of the week when there are surges in malicious activity (such as scanning, password attacks, and attempted connections).

Distribution of attack activity by days of the week. April 2017

It appears Monday is a difficult day for cybercriminals too. We couldn’t find any other explanation for this peculiar behavior.

Conclusion

The growing number of malware programs targeting IoT devices and related security incidents demonstrates how serious the problem of smart device security is. 2016 has shown that these threats are not just conceptual but are in fact very real. The existing competition in the DDoS market drives cybercriminals to look for new resources to launch increasingly powerful attacks. The Mirai botnet has shown that smart devices can be harnessed for this purpose – already today, there are billions of these devices globally, and by 2020 their number will grow to 20-50 billion devices, according to predictions by analysts at different companies.

In conclusion, we offer some recommendations that may help safeguard your devices from infection:

  1. Do not allow access to your device from outside of your local network, unless you specifically need it to use your device;
  2. Disable all network services that you don’t need to use your device;
  3. If the device has a preconfigured or default password and you cannot change it, or a preconfigured account that you cannot deactivate, then disable the network services where they are used, or disable access to them from outside the local network.
  4. Before you start using your device, change the default password and set a new strong password;
  5. Regularly update your device’s firmware to the latest version (when such updates are available).

If you follow these simple recommendations, you’ll protect yourself from a large portion of existing IoT malware.