Malware Alerts

Subscribe to Malware Alerts feed Malware Alerts
Online headquarters of Kaspersky Lab security experts.
Updated: 1 hour 48 min 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.


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



APT Trends report Q2 2017

Tue, 08/08/2017 - 10:00


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:

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

  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

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.


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.


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


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 – 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 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 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.



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 – – 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.


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

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


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


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

  1. Securelist –
  2. Palo Alto Networks –
  3. Palo Alto Networks IoC2 –
  4. Palo Alto Networks 2 –
  5. Palo Alto Networks Unit 42, full report –
  6. TrendMicro –
  7. TrendMicro –
  8. PwC –

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 “” 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/’ 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.



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:// 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.


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.



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:

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”.


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.












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 “”, 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


Yara rules

rule ransomware_PetrWrap {

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


$a1 = "MIIBCgKCAQEAxP/VqKc0yLe9JhVqFMQGwUITO6WpXWnKSNQAYT0O65Cr8PjIQInTeHkXEjfO2n2JmURWV/uHB0ZrlQ/wcYJBwLhQ9EqJ3iDqmN19Oo7NtyEUmbYmopcq+YLIBZzQ2ZTK0A2DtX4GRKxEEFLCy7vP12EYOPXknVy/+mf0JFWixz29QiTf5oLu15wVLONCuEibGaNNpgq+CXsPwfITDbDDmdrRIiUEUw6o3pt5pNOskfOJbMan2TZu" fullword wide
$a2 = "" fullword wide
$a4 = "1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX" fullword ascii
$a5 = "" fullword wide


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.


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.