Malware RSS Feed

CowerSnail, from the creators of SambaCry

Malware Alerts - 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.

Go With Passphrases

SANS Tip of the Day - Tue, 07/25/2017 - 01:00
Passphrases are the strongest type of passwords and the easiest to remember. Simply use an entire sentence for your password, such as "What time is coffee?" By using spaces and punctuation, you create a long password that is hard to guess but easy to remember.

Spring Dragon – Updated Activity

Malware Alerts - 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

Malware Alerts - 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

Malware Alerts - 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.



Don't Login on Untrusted Computers

SANS Tip of the Day - Tue, 07/18/2017 - 01:00
A password is only as secure as the computer or network it is used on. As such, never log in to a sensitive account from a public computer, such as computers in a cyber cafe, hotel lobby or conference hall. Bad guys target public computers such as these and infect them on purpose. The moment you type your password on an infected computer, these cyber criminals can harvest your passwords. If you have no choice but to use a public computer, change your password at the next available opportunity you have access to a trusted computer.

Secure Your Home Wi-Fi Router

SANS Tip of the Day - Mon, 07/17/2017 - 01:00
The most effective steps you can take to secure your wireless network at home is to change the default admin password, enable WPA2 encryption and use a strong password for your wireless network.

Unique Passwords

SANS Tip of the Day - Fri, 07/14/2017 - 01:00
Make sure each of your accounts has a separate, unique password. Can't remember all of your passwords/passphrases? Consider using a password manager to securely store all of them for you.

No Free Pass for ExPetr

Malware Alerts - 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

Malware Alerts - 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.



If You Are a Victim of Identity Theft

SANS Tip of the Day - Tue, 07/11/2017 - 01:00
Report any identity theft immediately by following these steps:Contact the three major credit bureaus and have them place a fraud alert on your credit report.If a credit card was involved, contact the credit card company and have a new credit card with a new number issued.Contact your local law enforcement agency and file a report.File a complaint with the Federal Trade Commission.Document all conversations so you know whom you spoke to and when.

Bitscout – The Free Remote Digital Forensics Tool Builder

Malware Alerts - 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

Malware Alerts - 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

Paper Documents Also Have to Be Protected

SANS Tip of the Day - Tue, 07/04/2017 - 01:00
Keep in mind that digital data is not the only thing that needs to be protected. Paper documents also need to be protected. When disposing of any confidential documents, make sure they are shredded first or disposed of in bins for shredding. Also, be sure to lock up any sensitive documents before you go home at the end of the day.

From BlackEnergy to ExPetr

Malware Alerts - 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.












Lock Your Mobile Devices

SANS Tip of the Day - Fri, 06/30/2017 - 01:00
The number one step for protecting your mobile device is making sure it has a strong passcode or password lock on it so only you can access it.