Cryakl/Fantomas victims rescued by new decryptor

The No More Ransom project for assisting victims of ransomware has good news to report: The Belgian police, in cooperation with Kaspersky Lab, managed to obtain keys for recovering files encrypted with new versions of Cryakl ransomware, also known as Fantomas. The updated decryption tool is already available on the project’s website.

How to decrypt files encrypted by the Shade ransomware

What is Cryakl?

The Trojan ransomware Cryakl (Trojan-Ransom.Win32.Cryakl) has been . At first, it was distributed through attached archives in e-mails that appeared to come from an arbitration court in connection with some alleged wrongdoing. There is something about such messages that sets nerves to jangling, and even those who know better might be inclined to click on the attachment. Later, the e-mails diversified, looking like messages from other organizations, such as a local homeowners’ association.

When encrypting files on a victim’s computer, Cryakl creates a long key that it sends to a command-and-control C&C server. Without this key, it is nearly impossible to recover files impacted by the malware. After that, Cryakl replaces the desktop wallpaper with contact details for its creators together with a ransom demand. Cryakl also displays an image of the mask of the 1964 French movie villain Fantomas, hence its alternative name. Cryakl mostly targeted users in Russia, so information about it is mostly available in Russian.

Ransomware’s history and evolution in facts and figures

Success story

As we already said, the joint efforts of our experts and Belgian police resulted in obtaining the master keys. The investigation began when the computer crime unit learned about victims of the ransomware in Belgium, and then they discovered a C&C server in a neighboring country. An operation led by the Belgian federal prosecutor neutralized the server, along with several other C&C servers that received master keys from infected machines. Then Kaspersky Lab stepped in to assist the law enforcement agencies, not for the first time. As before, the results were first-class: Our experts helped analyze the data found and extract the decryption keys.

The keys have already been added to the RakhniDecryptor tool on the No More Ransom website, and the Belgian federal police is now an official partner of the project. No More Ransom, which has been running since July 2016, has to date provided free help to tens of thousands of people in decrypting files rendered unusable by ransomware, and deprived cyberblackmailers of at least 10 million euros of potential booty.

No More Ransom: A very productive year

How to rescue files encrypted by Cryakl ransomware

The No More Ransom site offers two tools for decrypting files corrupted by Cryakl. One, named RannohDecryptor and around since 2016, is for older versions of Cryakl. You can download it at, and get decryption instructions here.

We recently updated the second tool, RakhniDecryptor, by adding the master keys from the servers seized by the Belgian police. It can be downloaded from the same site; instructions are available here. RakhniDecryptor is needed to decrypt files hit by newer versions of Cryakl. Either one of the tools should restore Cryakl-infected files to full health.

How to stay safe in the future

When dealing with cryptoransomware, prevention is far cheaper and simpler than a cure. In other words, it’s better to secure yourself now and sleep easy than to mess around with file decryption. We’d like to share a few preemptive file protection tips:

1. Always keep a copy of your most important files somewhere else: in the cloud, on another drive, on a memory stick, or on another computer. More details about backup options are available here.

2. Use reliable AV software. Some security solutions — for example, Kaspersky Total Security — can also assist with file backup.

3. Don’t download programs from suspicious sources. Their installers might contain something you’d rather not have on your computer.

4. Don’t open attachments in e-mails from unknown senders, even if they look important and credible. If in doubt, look up the phone number on the organization’s official website and call to check.

Go to Source
Author: Anna Markovskaya

The Many Tentacles of the Necurs Botnet


Over the past five years the Necurs botnet has established itself as the largest purveyor of spam worldwide. Necurs is responsible for emailing massive amounts of banking malware, ransomware, dating spam, pump-n-dump stock scams, work from home schemes, and even cryptocurrency wallet credential phishing. Necurs sends so much spam that at times Necurs’ spam campaigns can make up more than 90% of the spam seen by Cisco Talos in one day.

To conduct a deeper analysis of Necurs, Talos extracted 32 distinct spam campaigns sent by Necurs between August 2017 and November 2017. The result was a collection of over 2.1 million spam messages, sent from almost 1.2 million distinct sending IP addresses in over 200 countries and territories.

Necurs Recipients

From an email marketing and delivery perspective, Necurs doesn’t appear to be too sophisticated. Necurs’ recipient database includes email addresses that have been harvested online, commonly deployed role-based accounts, as well as email addresses that appear to have been auto-generated. These are among the worst, most unreliable sources for obtaining email addresses, and any legitimate email marketer wouldn’t last a day mailing to addresses such as these. Of course, an illegitimate botnet such as Necurs has no such concerns. For many months the email addresses in Necurs database seemed to be largely static; Necurs hasn’t actively added any new addresses for at least the past year, possibly two years or more. In November of 2017, Necurs stopped mailing to many of the autogenerated accounts.

At one of my personal domains, Necurs has been seen mailing to addresses such as ‘equifax@’ –an email address that was originally stolen from Equifax years before the 2017 breach. Necurs also often mails to ‘thisisatestmessageatall@’, another email address I generated and put into the wild, long ago. There are also variations on other legitimate addresses, for example ‘aeson@’, ’20jaeson@’, and ‘eson@’ which are all variations on my address ‘jaeson@’. The number 20 was present at the beginning of many of Necurs recipients. Hex 20 corresponds with the space character and is used in percent-encoding, etc. This provides further indication of the harvested nature of these addresses.

Other addresses in Necurs’ mailing list appear to have been auto-generated. For example ‘EFgUYsxebG@’, ‘ZhyWaTmu@’, and ‘MTAyOvoYkx@’ have never been aliases at my domain that I’ve ever used, and the only mail these accounts ever receive comes from Necurs.

Necurs email received at an auto-generated email address

From our set of Necurs’ spam messages, Talos extracted only the user alias portion of the To: address. There are numerous email aliases, such as role-based addresses, that appear to be in Necurs’ recipient DB across many different recipient domains. Strangely, the list also included some odd email aliases deployed at multiple domains such as ‘unity_unity[0-9]@’, ‘petgord32truew@’, ‘iamjustsendingthisleter@’, ‘docs[0-9]@’, and others.

Email alias and the number of domains in our data in which that alias was found

Interestingly, some of these same strange aliases can be found on Project Honeypot’s list of the Top Dictionary Attacker Usernames, though it is unclear whether Necurs obtained their aliases from this list, or whether these aliases made Project Honeypot’s list as a result of Necurs’ spamming activity.

Project Honeypot’s Top Dictionary Attacker Usernames

Necurs Sending IPs

Next, Talos extracted the sending IP addresses responsible for transmitting Necurs’ spam emails, and we grouped the data according to geographical location. Rather than being uniformly distributed worldwide, a majority of Necurs’ nodes were concentrated among just a few countries –India (25.7% of total spam), Vietnam (20.3% of total spam), and Iran (7.3% of total spam). More than half (51.3%) of the sending IP addresses in our data came from just these three countries. In contrast, other large industrialized nations were only responsible for tiny fraction of the spam. For example, the United States, was home to 6,314 (less than 1%) of Necurs sending IPs. The country of Russia was only attributed to 38 sending IP addresses out of a nearly 1.2 million total sender IPs!

Number of spam messages sent per country

Talos also analyzed the individual spam campaigns in order to determine how often the sending IP addresses were reused from campaign to campaign. We found very little infrastructure reuse. In fact, none of the sending IP addresses in our data were seen across all thirty-two of the campaigns we extracted. Only three sending IP addresses could be found across thirty of Necurs’ spam campaigns. The vast, vast majority of sending IP addresses, 937,761 (78.6% of the total), were only ever seen in a single Necurs spam campaign! This means that Necurs botnet is large enough to conduct attacks over several months without substantial reuse of most sending nodes –an impressive feat.

Number of unique IP addresses vs. how many campaigns in which they appeared

Necurs Spam Campaigns

Typically email campaigns from Necurs fall into one of two categories: high-volume weekday campaigns, or low volume continuous campaigns. Necurs has occasionally been seen sending high volume campaigns on weekends, but the vast majority of the time high volume campaigns are limited to the business week only. The mailing list database Necurs is using seems to be segmented, such that the high volume campaigns use one subset of email addresses from the DB, and the low volume campaigns use a different set of email addresses.


Below is an example of a pump-n-dump stock spam sent on April 12th, 2017 by Necurs touting the stock symbol QSMG, Quest Management Incorporated. On the following day the price of QSMG peaked at $2.33, probably netting the criminals a tidy gain on their initial investment. QSMG is currently worth less than $0.02.

A message touting the penny stock, QSMG
QSMG was at $2.33 on April 13. Currently it is worth less than $0.02


Necurs also sends dating spam. Recent dating spam have arrived without any URLs in the body, except a mailto: link to an email address. Current dating campaigns have involved the free email provider, but other previous dating campaigns have taken advantage of similar free email services such as Necurs’ dating campaigns have also been known to include HTML links to fast-fluxed domains, or sometimes compromised websites (WordPress, etc.).

Necurs dating spam featuring an email address at

If you respond to one of these dating messages, you may be enrolled in a Russian dating website such as In this case, the criminals are making money by referring new users to these dating sites. Most likely they are being paid on an affiliate model.

Marmeladies is one of the dating sites to which victims who reply are directed


Of course one of Necurs’ most well-known payloads is ransomware. Necurs has been one of the biggest distributors of the Locky ransomware. Locky also works on an affiliate model. Inside of each locky sample, in the metadata, is an affiliate ID, which is always the same (3) for Necurs mailings. Most of the time, very little investment is made in the design of the messages themselves, as in the following example.

A typical ransomware campaign from Necurs


The rise (and fall) in the value of digital currencies such as Bitcoin and Etherium has not escaped the attention of the Necurs criminals. They have been seen conducting attack campaigns using domains designed to look similar to legitimate wallet management websites. In the email below, note the extra word ‘my’ in the domain ‘’.

This domain is registered to appear similar to the real Etherium wallet management site,

Recently, the Necurs attackers have drawn from previous stock pump-n-dump scams to come up with a relatively new tactic related to cryptocurrency. They had a spam campaign pumping Swisscoin (SIC).

A Necurs spam email encouraging recipients to buy Swisscoin (SIC)


Necurs was recently sending a low volume job spam campaign which includes links to freshly registered domains. For example, in the email below, sent October 30th 2017, we can see they are using a link to the domain, ‘’. (The affiliate id in the URL is always the same)

An example of a low volume, job-related spam campaign from Necurs



Checking the whois record for this domains we see the following registration details. Note the registrant email ‘’. This is an attempt by the threat actors to convince the casual observer that the domain is somehow registered through a third party whois privacy protection service. Email accounts are free to the public, and in this instance the attackers have simply generated the alias ‘whois-agent’ for their use in registering domains.

A review of the domains registered to ‘’ yields 399 domains (from DT as of January 17, 2018). The list of domains registered to ‘’ reads like a who’s-who of criminal activity.

Among some of the more notable domains we can see obvious phishing domains:

Typo-squattish domains targeting cryptocoin-related sites:

Fake Flash Player Update domains:

Even domains intended to masquerade as government resources:

A review of some of the domains in passive DNS gives us some other important clues. While most domains are only registered for the minimum of one year, the attackers have chosen to maintain the registration for a longer time on other domains such as ‘’. That domain is home to an online marketplace for buying and selling stolen credit card numbers, stolen ssh account credentials and more.

‘’ is a website dedicated to buying and selling stolen credit card numbers

Passive DNS also reveals instances where the attackers have hosted domains belonging to different registrants on the same IP address. For example, when Talos analyzed the passive DNS records for one of the attacker’s domains: ‘’ we found that this domain was hosted on a single IP address for a couple months in late 2016 before being parked. When we reviewed the other domains living on that same IP address we saw a bit of a pattern, and most importantly, some of these domains were NOT in the list of domains owned by ‘’.


When we check the registration information for one of the above domains ‘’, we find that there is a different registrant. This time the email address used to register the domain was ‘’. Just as with the ‘’ address, this is an attempt to appear to a casual observer that the domain is protected by whois privacy protection when in reality this email account appears to be under the direct control of the attackers themselves.

Reviewing the list of 1103 domains (Domain Tools as of January 17, 2018) associated with the ‘’ email address we see much of the same illicit activity we saw before.

More phishing domains:

More domains targeting cryptocoin-related resources:

Similar themed, fake Flash Player updates:

We even see targeting of government resources, just as we did with the other registrant account:


Checking the registration on some of the domains associated with ‘’, we can find some domains in which there are other registrants and the whois-privacy@ address is simply an Administrative and Technical Contact. This reveals an additional registrant email address employed by the attackers, ‘’.

According to Domain Tools (as of January 17, 2017), that email address is associated with over 2500 domains. Most of the domains belonging to this registrant email appeared to be domainer-style domains located at TLDs such as .bid and .top, but we also see a heavy dose of illegitimate looking domains in the set as well.

Some typical ‘Domainer’-ish domains:

Illegitimate Domains:


We can associate even more registrant email accounts with these same threat actors using similar techniques. While researching passive DNS for one of the domains we found previously, ‘’, we ran across something very interesting. That particular domain was hosted October 21, 2017 on the IP address which belongs to Alibaba as part of their cloud hosting product. When we analyze all the other domains which have been hosted on that same IP we see many domains that belong to the registrant email addresses we already knew about, ‘’ and ‘’. However we also see several domains associated with different registrants.


Looking at the list of domains found on this same Alibaba IP we find the domain ‘’. This domain is registered to the registrant email address, ‘’. This registrant has registered 125 domains (Domain Tools as of January 17, 2018), many of which have been linked to malicious activities. According to these links, domains associated with this registrant email have been used as part of the Rig Exploit Kit infrastructure. The domain, ‘’, was hosted on the Alibaba IP address on October 19, 2017 –only two days before the IP was used to host domains belonging to ‘’.


The domain ‘’ belongs to the registrant email address ‘’. The ‘’ domain was hosted on the IP on October 25th through October 30th, 2017 –also very close to the timeframe in which we saw the IP hosting the other malicious domains.

As of January 16, 2017, DomainTools attributes 918 domains to the registrant email address ‘’. Among some of the domains associated with this address we find gems such as:


The domain ‘’ is registered to ‘’. A Google search for this domain produces this linkat Hybrid Analysis and indicates that this particular domain was contacted as part of a piece of malware. At Virus Total, 50/68 antivirus engines detect this particular sample as malicious.


Searching Google for this registrant email address yields multiple links to malware that reaches out to domains owned by ‘’. Virus Total corroborates this information showing 48 and 53 antivirus detections respectively.


Reaching out through various contacts, Talos was able to confirm that, in fact, a single Alibaba cloud instance was controlling this same IP address for the entire time period from October 19, 2017 through October 30, 2017. Is this IP address some part of a criminal domain hosting service? Or is it that a single nefarious enterprise is behind all of these various registrant email accounts and their associated domains? Only the criminals involved in this enterprise can say for certain. Talos continues to monitor this situation with an eye towards further deciphering the business model deployed by these miscreants.


Now that Necurs is back from their regular holiday break they are attempting to fill our inboxes with junk mail and malware once again. On one hand, the size of the Necurs botnet, and its ability to send from different nodes in every campaign makes it difficult to defend against; Standard IP address blacklists are ineffective against such tactics. Fortunately for network defenders, the fact that Necurs does relatively little to curate their recipient database limits the damage they can do. There are only so many times the same recipients will fall for Necurs’ same, repetitive tricks. We can expect that Necurs will continue to try variations on some of their tried and true attacks, and so user education against these threats remains paramount.

Go to Source
Author: Talos Group

Napoleon: a new version of Blind ransomware

The ransomware previously known as Blind has been spotted recently with a .napoleon extension and some additional changes. In this post, we’ll analyze the sample for its structure, behavior, and distribution method.

Analyzed samples

31126f48c7e8700a5d60c5222c8fd0c7 – Blind ransomware (the first variant), with .blind extension

9eb7b2140b21ddeddcbf4cdc9671dca1 – Variant with .kill extension

235b4fa8b8525f0a09e0c815dfc617d3.napoleon (main focus of this analysis)

//special thanks to @demonslay335  for sharing the older samples

Distribution method

So far we are not 100 percent sure about the distribution method of this new variant. However, looking at the features of the malware and judging from information from the victims, we suspect that the attackers spread it manually by dropping and deploying on the hacked machines (probably via IIS). This method of distribution is not popular or efficient, however we’ve encountered similar cases in the past, such as DMALocker or LeChiffre ransomware. Also, few months ago, hacked IIS servers were used as a vector to plant Monero miners. The common feature of samples dropped in this way is that they are not protected by any cryptor (because it’s not necessary for this distribution method).

Behavioral analysis

After the ransomware is deployed, it encrypts files one-by-one, adding its extension in the format [email].napoleon.

Looking at the content of the encrypted test files, we can see that the same plaintext gave different ciphertext. This always indicates that different key or initialization vectors were used for each file. (After examining the code, it turned out that the difference was in the initialization vector).

Visualizing the encrypted content helps us guess the algorithm with which the files were encrypted. In this case, we see no visible patterns, so this leads us to suspect an algorithm with some method of chaining cipher blocks. (The most commonly used is AES in CBC mode, or eventually in CFB mode). Below, you can see the visualization made with the help of the file2png script: On the left is a BMP file before encryption. And on the right, after encryption by Napoleon:

At the end of each file, we found a unique 384-long block of alphanumeric characters. They represent 192 bytes written in hexadecimal. Most probably this block is the encrypted initialization vector for the particular file):

The ransom note is in HTA format and looks like this:

It also contains a hexadecimal block, which is probably the victim’s key, encrypted with the attackers’ public key.

The GUI of Napoleon looks simplified in comparison to the Blind ransomware. However, the building blocks are the same:

It is common among ransomware authors to prepare a tor-base website that allows automatic processing for payments and better organizes communication with the victim. In this case, the attackers decided to use just an email—probably because they planned for the campaign to be small.

Among the files created by the Napoleon ransomware, we will no longer find the cache file (netcache64.sys) that in the previous editions allowed to recover the key without paying the ransom.

Below is the cache file dropped by the Blind ransomware (the predecessor of Napoleon):

Inside the code

The malware is written in C++. It is not packed by any cryptor.

The execution starts in the function WinMain:

The flow is pretty simple. First, the ransomware checks the privileges with which it runs. If it has sufficient privileges, it deletes shadow copies. Then, it closes processes related to databases—Oracle and SQL Server—so that they will not block access to the database files it wants to encrypt. Next, it goes through the disks and encrypts found files. At the end, it pops up the dropped ransom note in HTA format.

Comparing the code of Napoleon with the code of Blind, we see that not just the extension of encrypted files has has changed, but also many functions inside have been refactored.

Below is a fragment of the view from BinDiff: Napoleon vs Blind:

What is attacked?

First, the ransomware enumerates all the logical drives in the system and adds them into a target list. It attacks both fixed and remote drives ( type 3 -> DRIVE_FIXED  and 4 -> DRIVE_REMOTE):

This ransomware does not have any list of attacked extensions. It attacks all the files it can reach. It skips only the files that already have the extension indicating they are encrypted by Napoleon:

The email used in the extension is hardcoded in the ransomware’s code.

Encryption implementation

Just like the previous version, the cryptographic functions of Napoleon are implemented with the help of the statically-linked library Crypto++ (source).

Referenced strings pointing to Crypto++:

Inside, we found a hardcoded blob—the RSA public key of the attackers:

After conversion to a standardized format, such as PEM, we were able to read its parameters using openssl, confirming that it is a valid 2048 bit–long RSA key:

Public-Key: (2048 bit)
Exponent: 17 (0x11)

This attacker’s public key is later used to encrypt the random key generated for the particular victim. The random key is the one used to encrypt files – after it is used and destroyed, it’s encrypted version is stored in the victim’s ID displayed in the ransom note. Only the attackers, having the private RSA key, are capable to recover it.

The random AES key (32 bit) is generated by the function provided by Crypto++ library:

It uses underneath the secure random generator: CryptGenRandom:

All the files are encrypted with the same key, however the initialization vector is different for each.

Encrypting single file:

Inside the function denoted as encrypt_file, the crypto is initialized with a new initialization vector:

The fragment of code responsible for setting the IV:

Setting initialization vector:

Encrypting file content:

The same buffer after encryption:


Napoleon ransomware will probably not become a widespread threat. The authors prepared it for small campaigns—lot of data, like email, are hardcoded. It does not come with any external configuration like Cerber that would allow for fast customization.

So far, it seems that the authors fixed the previous bug in Blind of dropping the cache file. That means the ransomware is not decryptable without having the original key. All we can recommend is prevention.

This ransomware family is detected by Malwarebytes as Ransom.Blind.


Read about how to decrypt the previous Blind variant here.

The post Napoleon: a new version of Blind ransomware appeared first on Malwarebytes Labs.

Go to Source
Author: Malwarebytes Labs

LokiBot: If not stealing, then extorting

Remember the Hydra of ancient mythology? The many-headed serpent that grew two heads when one was chopped off? A similarly dangerous beast has appeared in the Android malware zoo.


LokiBot as a banking Trojan

How do ordinary banking Trojans behave? They present the user with a fake screen that simulates the mobile banking interface. Unsuspecting victims enter their login credentials, which the malware redirects to the attackers, giving them access to the accounts.

How does LokiBot behave? Roughly the same way, but it simulates not only a banking app screen, but also WhatsApp, Skype, and Outlook client interfaces, displaying notifications purporting to come from these applications.

This means that a person can receive a fake notification, supposedly from their bank, saying that funds have been transferred to their account, and seeing the good news. then log in to the mobile banking client for confirmation. LokiBot even makes the smartphone vibrate when it displays the notification about the alleged transfer, which helps hoodwink even clued-in users.

But LokiBot has other tricks in store: It can open a browser, navigate to specific pages, and even use an infected device to send spam, which is basically how it distributes itself. Having pinched money from your account, LokiBot keeps going, sending a malicious SMS to all contacts in the phone book to infect as many smartphones and tablets as possible, and even replying to incoming messages if necessary.

If an attempt is made to remove LokiBot, the malware reveals another facet: To steal funds from a bank account, it needs administrator rights; if you try to deny it permission, it mutates from a banking Trojan into ransomware.


LokiBot as ransomware. How to unlock infected smartphone

In this case, LokiBot locks the screen and displays a message accusing the victim of viewing child pornography and demanding ransom; it also encrypts data on the device. Examining LokiBot’s code, researchers discovered that it uses weak encryption and doesn’t work properly; the attack leaves unencrypted copies of all files on the device, only under different names, so restoring the files is relatively simple.

However, the device screen is still locked, and the malware creators ask for about $100 in Bitcoin to unlock it. But you don’t have to oblige: After rebooting the device in safe mode, you can strip the malware of administrator rights and delete it. To do so, you first need to determine which version of Android you have:

  • Select Settings.
  • Select the General tab.
  • Select About the device.
  • Find the line Android version — the numbers below it indicate your OS version

To enable safe mode on a device with Version 4.4 to 7.1, do the following:

  • Press and hold the power button until a menu appears with the option Power off or Disconnect power source.
  • Press and hold Power off or Disconnect power source.
  • In the Turn on safe mode menu that appears, click OK.
  • Wait for the phone to reboot.

Owners of devices with other versions of Android should look online for information about how to enable safe mode for their particular phone.

Unfortunately, not everyone knows about this method of killing the malware: LokiBot victims have already coughed up nearly $1.5 million. And with LokiBot available on the black market for a mere $2,000, it is likely that the criminals responsible have repaid their investment many times over.


How to protect against LokiBot

In effect, the measures that can be taken to protect against LokiBot are applicable to any mobile malware. Here’s how to protect yourself:

– Never click on suspicious links — that’s how LokiBot spreads.

– Download apps only via Google Play — but be cautious even in the official store.

– Install a reliable security solution on your smartphone and tablet. Kaspersky Internet Security for Android detects all variants of LokiBot. With the paid version, there’s no need to scan the smartphone after installing each new application.

Go to Source
Author: Alexandra Golovina

BACKSWING – Pulling a BADRABBIT Out of a Hat

Executive Summary

On Oct. 24, 2017, coordinated strategic web compromises started to
distribute BADRABBIT ransomware to unwitting users. FireEye appliances
detected the download attempts and blocked our user base from
infection. During our investigation into the activity, FireEye
identified a direct overlap between BADRABBIT redirect sites and sites
hosting a profiler we’ve been tracking as BACKSWING. We’ve identified
51 sites hosting BACKSWING and four confirmed to drop BADRABBIT.
Throughout 2017, we observed two versions of BACKSWING and saw a
significant increase in May with an apparent focus on compromising
Ukrainian website. The pattern of deployment raises the possibility of
a strategic sponsor with specific regional interests and suggest a
motivation other than financial gain. Given that many domains are
still compromised with BACKSWING, we anticipate that there is a risk
that they will be used for future attacks.

Incident Background

Beginning on Oct. 24 at 08:00 UTC, FireEye detected and blocked
attempts to infect multiple clients with a drive-by download
masquerading as a Flash Update (install_flash_player.exe) that
delivered a wormable variant of ransomware. Users were redirected to
the infected site from multiple legitimate sites (e.g.
simultaneously, indicating a coordinated and widespread strategic web
compromise campaign.

FireEye network devices blocked infection attempts at over a dozen
victims primarily in Germany, Japan, and the U.S. until Oct. 24 at
15:00 UTC, when the infection attempts ceased and attacker
infrastructure – both 1dnscontrol[.]com and the legitimate websites
containing the rogue code – were taken offline.

BACKSWING Framework Likely Connected to BADRABBIT Activity

Strategic web compromises can have a significant amount of
collateral targeting. It is common for threat actors to pair a
strategic web compromise with profiling malware to target systems with
specific application versions or victims. FireEye observed that
BACKSWING, a malicious JavaScript profiling framework, was deployed to
at least 54 legitimate sites starting as early as September 2016.  A
handful of these sites were later used to redirect to BADRABBIT
distribution URLs.

FireEye iSIGHT Intelligence tracks two distinct version of BACKSWING
that contain the same functionality, but differ in their code styles.
We consider BACKSWING a generic container used to select attributes of
the current browsing session (User-Agent, HTTP Referrer, Cookies, and
the current domain). This information is then relayed to a “C2”
sometimes to referred to as a “receiver.” If the receiver is online,
the server returns a unique JSON blob to the caller which is then
parsed by the BACKSWING code (Figure 1).

Figure 1: BACKSWING Reply

BACKSWING anticipates the JSON blob to have two fields,
“InjectionType” (expected to be an integer) and “InjectionString”
(expected to be string containing HTML content). BACKSWING version 1
(Figure 2) explicitly handles the value of “InjectionType” into two
code paths:

  • If InjectionType == 1 (Redirect browser to URL)
  • If
    InjectionType != 1 (render HTML into the DOM)

Figure 2: Backswing Version 1

In Version 2 (Figure 3), BACKSWING retains similar logic, but
generalizes the InjectionString to be handled strictly to render the
reply into the DOM.

Figure 3: BACKSWING Version 2

Version 1:

  • FireEye observed the first version of BACKSWING in late 2016
    on websites belonging to a Czech Republic hospitality organization
    in addition to a government website in Montenegro. Turkish-tourism
    websites were also injected with this profiler.
    v1 was commonly injected in cleartext to affected websites, but over
    time, actors began to obfuscate the code using the open-source
    Dean-Edwards Packer and injected it into legitimate JavaScript
    resources on affected websites. Figure 4 shows the injection
  • Beginning in May 2017, FireEye observed a number of
    Ukrainian websites compromised with BACKSWING v1, and in June 2017,
    began to see content returned from BACKSWING receivers.
  • In
    late June 2017, BACKSWING servers returned an HTML div element with
    two distinct identifiers. When decoded, BACKSWING v1 embedded two
    div elements within the DOM with values of
    07a06a96-3345-43f2-afe1-2a70d951f50a and
    9b142ec2-1fdb-4790-b48c-ffdf22911104. No additional content was
    observed in these replies.

Figure 4: BACKSWING Injection Content

Version 2:

  • The earliest that FireEye observed BACKSWING v2 occurred on
    Oct. 5, 2017 across multiple websites that previously hosted
  • BACKSWING v2 was predominantly injected into
    legitimate JavaScript resources hosted on affected websites;
    however, some instances were injected into the sites’ main
  • FireEye observed limited instances of websites hosting
    this version were also implicated in suspected BADRABBIT infection
    chains (detailed in Table 1).

Malicious profilers allow attackers to obtain more information about
potential victims before deploying payloads (in this case, the
BADRABBIT “flash update” dropper). While FireEye has not directly
observed BACKSWING delivering BADRABBIT, BACKSWING was observed on
multiple websites that were seen referring FireEye customers to
1dnsccontrol[.]com, which hosted the BADRABBIT dropper.

Table 1 highlights the legitimate sites hosting BACKSWING that were
also used as HTTP referrers for BADRABBIT payload distribution.

Compromised Website BACKSWING Receiver BACKSWING Version Observed BADRABBIT Redirect
blog.fontanka[.]ru Not Available Not Available 1dnscontrol[.]com[.]jp http://185.149.120[.]3/scholargoogle/ v2 1dnscontrol[.]com
www.fontanka[.]ru http://185.149.120[.]3/scholargoogle/ v2 1dnscontrol[.]com
www.mediaport[.]ua http://172.97.69[.]79/i/ v1 1dnscontrol[.]com
www.mediaport[.]ua http://185.149.120[.]3/scholargoogle/ v2 1dnscontrol[.]com
www.smetkoplan[.]com http://172.97.69[.]79/i/ v1 1dnscontrol[.]com
www.smetkoplan[.]com http://38.84.134[.]15/Core/Engine/Index/default v1 1dnscontrol[.]com
www.smetkoplan[.]com http://185.149.120[.]3/scholargoogle/ v2 1dnscontrol[.]com

Table 1: Sites hosting BACKSWING profilers and
redirected users to a BADRABBIT download site

The compromised websites listed in Table 1 demonstrate one of the
first times that we have observed the potential weaponization of
BACKSWING. FireEye is tracking a growing number of legitimate websites
that also host BACKSWING underscoring a considerable footprint the
actors could leverage in future attacks. Table 2 provides a list of
sites also compromised with BACKSWING

Compromised Website BACKSWING Receiver BACKSWING Version
akvadom.kiev[.]ua http://172.97.69[.]79/i/ v1[.]ua http://dfkiueswbgfreiwfsd[.]tk/i/ v1[.]ua http://172.97.69[.]79/i/ v1[.]ua http://172.97.69[.]79/i/ v1[.]ua http://172.97.69[.]79/i/ v1[.]me http://38.84.134[.]15/Core/Engine/Index/two v1
Evrosmazki[.]ua http://172.97.69[.]79/i/ v1
forum.andronova[.]net http://172.97.69[.]79/i/ v1
forum.andronova[.]net http://91.236.116[.]50/Core/Engine/Index/two v1
grandua[.]ua http://172.97.69[.]79/i/ v1
grupovo[.]bg http://185.149.120[.]3/scholargoogle/ v2
hr.pensionhotel[.]com http://38.84.134[.]15/Core/Engine/Index/default v1[.]ua http://172.97.69[.]79/i/ v1[.]ua http://185.149.120[.]3/scholargoogle/ v2
icase.lg[.]ua http://172.97.69[.]79/i/ v1
montenegro-today[.]com http://38.84.134[.]15/Core/Engine/Index/two v1
montenegro-today[.]ru http://172.97.69[.]79/i/ v1
most-dnepr[.]info http://172.97.69[.]79/i/ v1
most-dnepr[.]info http://185.149.120[.]3/scholargoogle/ v2
obereg-t[.]com http://172.97.69[.]79/i/ v1
sarktur[.]com http://104.244.159[.]23:8080/i v1
sarktur[.]com http://38.84.134[.]15/Core/Engine/Index/default v1[.]ua http://172.97.69[.]79/i/ v1
sinematurk[.]com http://91.236.116[.]50/Core/Engine/Index/two v1
vgoru[.]org http://172.97.69[.]79/i/ v1
www.2000[.]ua http://172.97.69[.]79/i/ v1
www.444android[.]com http://172.97.69[.]79/i/ v1
www.444android[.]com http://91.236.116[.]50/Core/Engine/Index/two v1[.]jp http://38.84.134[.]15/Core/Engine/Index/default v1
www.alapli.bel[.]tr http://91.236.116[.]50/Core/Engine/Index/two v1
www.ambilet[.]ro http://185.149.120[.]3/scholargoogle/ v2
www.andronova[.]net http://91.236.116[.]50/Core/Engine/Index/two v1[.]ua http://172.97.69[.]79/i/ v1
www.dermavieskin[.]com https://bodum-online[.]gq/Core/Engine/Index/three v1
www.evrosmazki[.]ua http://172.97.69[.]79/i/ v1
www.hercegnovi[.]me http://38.84.134[.]15/Core/Engine/Index/two v1
www.len[.]ru http://185.149.120[.]3/scholasgoogle/ v2
www.montenegro-today[.]com http://38.84.134[.]15/Core/Engine/Index/two v1
www.montenegro-today[.]com http://91.236.116[.]50/Core/Engine/Index/two v1
www.otbrana[.]com http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]be http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]cz http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]de http://172.97.69[.]79/i/ v1
www.pensionhotel[.]de http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]dk http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]nl http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]pl http://38.84.134[.]15/Core/Engine/Index/default v1
www.pensionhotel[.]ro http://46.20.1[.]98/scholargoogle/ v1
www.pensionhotel[.]sk http://38.84.134[.]15/Core/Engine/Index/default v1
www.sinematurk[.]com http://91.236.116[.]50/Core/Engine/Index/two v1
www.t.ks[.]ua http://172.97.69[.]79/i/ v1
www.teknolojihaber[.]net http://91.236.116[.]50/Core/Engine/Index/two v1
www.uscc[.]ua http://172.97.69[.]79/i/ v1
www.vertizontal[.]ro http://91.236.116[.]50/Core/Engine/Index/three v1
www.visa3777[.]com http://172.97.69[.]79/i/ v1
www.www.pensionhotel[.]de http://38.84.134[.]15/Core/Engine/Index/default v1

Table 2: Additional sites hosting BACKSWING
profilers and associated receivers

The distribution of sites compromised with BACKSWING suggest a
motivation other than financial gain. FireEye observed this framework
on compromised Turkish sites and Montenegrin sites over the past year.
We observed a spike of BACKSWING instances on Ukrainian sites, with a
significant increase in May 2017. While some sites hosting BACKSWING
do not have a clear strategic link, the pattern of deployment raises
the possibility of a strategic sponsor with specific regional interests.

BADRABBIT Components

BADRABBIT is made up of several components, as described in Figure 5.

Figure 5: BADRABBIT components

Install_flashPlayer.exe (MD5: FBBDC39AF1139AEBBA4DA004475E8839)

The install_flashplayer.exe payload drops infpub.dat (MD5:
C4F26ED277B51EF45FA180BE597D96E8) to the C:Windows directory and
executes it using rundll32.exe with the argument
C:Windowsinfpub.dat,#1 15. This execution format mirrors that of EternalPetya.

infpub.dat (MD5: 1D724F95C61F1055F0D02C2154BBCCD3)

The infpub.dat binary is the primary ransomware component
responsible for dropping and executing the additional components shown
in the BADRABBIT Components section. An embedded RSA-2048 key
facilitates the encryption process, which uses an AES-128 key to
encrypt files. The extensions listed below are targeted for encryption:

The following directories are ignored during the encryption process:

  • Windows
  • Program Files
  • ProgramData
  • AppData

The malware writes its ransom message to the root of each affected
drive with the filename Readme.txt.

The inpub.dat is capable of performing lateral movement via WMI or
SMB. Harvested credentials provided by an embedded Mimikatz executable
facilitate the infection of other systems on the network. The malware
contains lists of common usernames, passwords, and named pipes that it
can use to brute-force other credentials for lateral movement.

If one of four Dr.Web antivirus processes is present on the system,
file encryption is not performed. If the malware is executed with the
“-f” command line argument, credential theft and lateral movement are bypassed.

dispci.exe (MD5: B14D8FAF7F0CBCFAD051CEFE5F39645F)

The dispci.exe binary interacts with the DiskCryptor driver
(cscc.dat) to install the malicious bootloader. If one of three McAfee
antivirus processes is running on the system, dispci.exe is written to
the %ALLUSERSPROFILE% directory; otherwise, it is written to
C:Windows. The sample is executed on system start using a scheduled
task named rhaegal.

cscc.dat (MD5s: B4E6D97DAFD9224ED9A547D52C26CE02 or EDB72F4A46C39452D1A5414F7D26454A)

A 32 or 64-bit DiskCryptor
driver named cscc.dat facilitates disk encryption. It is installed in
the :Windows directory as a kernel driver service named cscc.

Mimikatz usage (MD5s: 37945C44A897AA42A66ADCAB68F560E0 or 347AC3B6B791054DE3E5720A7144A977)

A 32 or 64-bit Mimikatz variant is written a temporary file (e.g.,
651D.tmp) in the C:Windows directory and executed by passing a named
pipe string (e.g., \.pipe{8A93FA32-1B7A-4E2F-AAD2-76A095F261DC}) as
an argument. Harvested credentials are passed back to infpub.dat via
the named pipe, similar to EternalPetya.

BADRABBIT Compared to EternalPetya

The infpub.dat contains a checksum algorithm like the one used in
EternalPetya. However, the initial checksum value differs slightly:
0x87654321 in infpub.dat, 0x12345678 in EternalPetya. infpub.dat also
supports the same command line arguments as EternalPetya with the
addition of the “-f” argument, which bypasses the malware’s credential
theft and lateral movement capabilities.

Like EternalPetya, infpub.dat determines if a specific file exists
on the system and will exit if found. The file in this case is
cscc.dat. infpub.dat contains a wmic.exe lateral movement capability,
but unlike EternalPetya, does not contain a PSEXEC binary used to
perform lateral movement.

Both samples utilize the same series of wevtutil and fsutil commands
to perform anti-forensics:

wevtutil cl Setup & wevtutil cl
System & wevtutil cl Security & wevtutil cl Application
& fsutil usn deletejournal /D %SYSTEMDRIVE%

FireEye Detections

Product Detection Names
NX,EX,AX,FX,ETP malware.binary.exe,
Trojan.Ransomware.MVX, Exploit.PossibleWaterhole.BACKSWING
Created], WINDOWS METHODOLOGY [Service Installation], WINDOWS
Ordinal Arg], WINDOWS METHODOLOGY [Wevtutil Clear-log],
METHODOLOGY [Multiple Admin Share Failures]

We would like to thank Edward Fjellskål for his assistance with
research for this blog.


File: Install_flashPlayer.exe
install_flashplayer.exe drops infpub.dat

File: infpub.dat
Hash: 1D724F95C61F1055F0D02C2154BBCCD3
Description: Primary ransomware component

File: dispci.exe
Hash: B14D8FAF7F0CBCFAD051CEFE5F39645F
Description: Interacts with the DiskCryptor driver (cscc.dat) to
install the malicious bootloader, responsible for file decryption.

File: cscc.dat
Hash: B4E6D97DAFD9224ED9A547D52C26CE02 or
Description: 32 or 64-bit
DiskCryptor driver

File: .tmp
37945C44A897AA42A66ADCAB68F560E0 or
Description: 32 or 64-bit
Mimikatz variant

File: Readme.txt
Hash: Variable
Description: Ransom note

Command: system32rundll32.exe C:Windowsinfpub.dat,#1 15
Description: Runs the primary ransomware component of BADRABBIT. Note
that “15” is the default value present in the malware and may be
altered by specifying a different value on command line when executing install_flash_player.exe.

Command: %COMSPEC% /c schtasks /Create /RU SYSTEM /SC ONSTART /TN
rhaegal /TR “<%COMSPEC%> /C Start “”
“” -id
Description: Creates
the rhaegal scheduled task

Command: %COMSPEC% /c schtasks /Create /SC once /TN drogon /RU
SYSTEM /TR “%WINDIR%system32shutdown.exe /r /t 0 /f” /ST

Description: Creates the drogon scheduled task

Command: %COMSPEC% /c schtasks /Delete /F /TN drogon
Description: Deletes the drogon scheduled task

Command: %COMSPEC% /c wswevtutil cl Setup & wswevtutil cl System
& wswevtutil cl Security & wswevtutil cl Application &
fsutil usn deletejournal /D :
Description: Anti-forensics

Scheduled Task Name: rhaegal
Scheduled Task Run:
“<%COMSPEC%> /C Start “”
“” -id
&& exit”
Description: Bootloader interaction

Scheduled Task Name: drogon
Scheduled Task Run:
“%WINDIR%system32shutdown.exe /r /t 0 /f”
Description: Forces a reboot

Service Name: cscc
Service Display Name: Windows Client Side
Caching DDriver
Service Binary Path: cscc.dat

Embedded usernames from infpub.dat (1D724F95C61F1055F0D02C2154BBCCD3)
other user
Embedded passwords from infpub.dat (1D724F95C61F1055F0D02C2154BBCCD3)
Embedded pipe names from infpub.dat (1D724F95C61F1055F0D02C2154BBCCD3)

Yara Rules

rule FE_Hunting_BADRABBIT {
@TekDefense & nicholas.carr @itsreallynick”
md5 =
// Messages
$msg1 =
“Incorrect password” nocase ascii wide
$msg2 = “Oops! Your files have been encrypted.”
ascii wide
$msg3 = “If you see this text,
your files are no longer accessible.” ascii wide
$msg4 = “You might have been looking for a way to
recover your files.” ascii wide
$msg5 =
“Don’t waste your time. No one will be able to recover
them without our” ascii wide
$msg6 =
“Visit our web service at” ascii wide
$msg7 = “Your personal installation key#1:” ascii
$msg8 = “Run DECRYPT app at your
desktop after system boot” ascii wide
= “Password#1” nocase ascii wide
$msg10 = “caforssztxqzf2nm.onion” nocase ascii
$msg11 = /partition (unbootable|not
(found|mounted))/ nocase ascii wide

// File
$fref1 =
“C:\Windows\cscc.dat” nocase ascii wide
$fref2 = “\\.\dcrypt” nocase ascii wide
$fref3 = “Readme.txt” ascii wide
$fref4 = “\Desktop\DECRYPT.lnk” nocase ascii
$fref5 = “dispci.exe” nocase
ascii wide
$fref6 =
“C:\Windows\infpub.dat” nocase ascii wide
$meta1 =
“” nocase ascii wide
$meta2 = “dispci.exe” nocase ascii wide
$meta3 = “GrayWorm” ascii wide
$meta4 = “viserion” nocase ascii wide
$com1 = “ComSpec” ascii
$com2 = “\cmd.exe” nocase ascii
$com3 = “schtasks /Create” nocase
ascii wide
$com4 = “schtasks /Delete /F /TN
%ws” nocase ascii wide
(uint16(0) == 0x5A4D)
(8 of
($msg*) and 3 of ($fref*) and 2 of ($com*))
(all of ($meta*) and 8 of ($msg*))

author =
md5 =
rev = 1
$api1 =
“GetSystemDirectoryW” fullword
$api2 = “GetModuleFileNameW” fullword
$dropped_dll = “infpub.dat” ascii fullword
$exec_fmt_str = “%ws
C:\Windows\%ws,#1 %ws” ascii fullword wide
$extract_seq = { 68 ?? ?? ?? ?? 8D 95 E4 F9 FF FF 52 FF
15 ?? ?? ?? ?? 85 C0 0F 84 C4 00 00 00 8D 85 A8 ED FF FF 50 8D
8D AC ED FF FF E8 ?? ?? ?? ?? 85 C0 0F 84 AA 00 00 00 }
(uint16(0) == 0x5A4D and
uint32(uint32(0x3C)) == 0x00004550) and filesize < 500KB
and all of them

author = “muhammad.umair”
md5 = “1d724f95c61f1055f0d02c2154bbccd3”
rev = 1
$api1 =
“WNetAddConnection2W” fullword
$api2 = “CredEnumerateW” fullword
$api3 = “DuplicateTokenEx” fullword
$api4 = “GetIpNetTable”
$del_tasks = “schtasks /Delete /F /TN drogon” ascii
fullword wide
$dropped_driver =
“cscc.dat” ascii fullword wide
$exec_fmt_str = “%ws C:\Windows\%ws,#1 %ws” ascii
fullword wide
$iter_encrypt = { 8D 44 24 3C
50 FF 15 ?? ?? ?? ?? 8D 4C 24 3C 8D 51 02 66 8B 31 83 C1 02 66
3B F7 75 F5 2B CA D1 F9 8D 4C 4C 3C 3B C1 74 07 E8 ?? ?? ?? ??
$share_fmt_str =
“\\%ws\admin$\%ws” ascii fullword wide
(uint16(0) == 0x5A4D and
uint32(uint32(0x3C)) == 0x00004550) and filesize < 500KB
and all of them

author =
md5 =
rev = 1
$api1 =
“WriteProcessMemory” fullword
$api2 = “SetSecurityDescriptorDacl” fullword
$api_str1 = “BCryptDecrypt” ascii fullword
$mimi_str = “CredentialKeys”
ascii fullword wide
$wait_pipe_seq = { FF 15
?? ?? ?? ?? 85 C0 74 63 55 BD B8 0B 00 00 57 57 6A 03 8D 44 24
1C 50 57 68 00 00 00 C0 FF 74 24 38 4B FF 15 ?? ?? ?? ?? 8B F0
83 FE FF 75 3B }
(uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550)
and filesize < 500KB and all of them

author =
md5 =
rev = 1
$api1 =
“CryptAcquireContextW” fullword
$api2 = “CryptEncrypt” fullword
$api3 = “NetWkstaGetInfo” fullword
$decrypt_seq = { 89 5D EC 78 10 7F 07 3D 00 00 00 01 76 07 B8
00 00 00 01 EB 07 C7 45 EC 01 00 00 00 53 50 53 6A 04 53 8B F8
56 89 45 FC 89 7D E8 FF 15 ?? ?? ?? ?? 8B D8 85 DB 74 5F
$msg1 = “Disk decryption
progress…” ascii fullword wide
$task_fmt_str = “schtasks /Create /SC ONCE /TN
viserion_%u /RU SYSTEM /TR “%ws” /ST
%02d:%02d:00″ ascii fullword wide
= “\\.\dcrypt” ascii fullword wide
$tok2 = “C:\Windows\cscc.dat” ascii fullword
(uint16(0) ==
0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and filesize
< 150KB and all of them

Go to Source
Author: Barry Vengerik

BadRabbit: a closer look at the new version of Petya/NotPetya

Petya/NotPetya (aka EternalPetya), made headlines in June, attacking users around the world. Today, we noted an outbreak of a similar-looking malware, called BadRabbit, probably prepared by the same authors. Just like the previous edition, BadRabbit has an infector allowing for lateral movements, using SMB to propagate laterally with a hardcoded list of usernames and passwords. However, unlike NotPetya, it doesn’t use EternalBlue and is more widely spread. (Impacted countries include Ukraine, Russia, Turkey, and Bulgaria).

Another key difference between Petya/NotPetya and BadRabbit is that the initial vector is different (a website dropping a fake Flash update). Also, some of its components have been replaced. The malware package is complex, and we will likely dedicate future articles to describing all its features. But let’s have an initial look.

Analyzed samples

Behavioral analysis

The dropper is an executable that pretends to be a Flash update. The malware must run with Administration privileges, but no UAC bypass technique has been deployed— it relies purely on social engineering, trying to convince the user to elevate it. After being run, it drops and deploys the main module in C:Windows directory. This time, it is named infpub.dat. (We can see the analogy to the previous NotPetya outbreak, where the DLL was named perfc.dat):

It is run by the rundll32.exe called with parameters:

"C:\Windows\system32\rundll32.exe C:\Windows\infpub.dat,#1 15"

Notice that the malware scans computers in the LAN:

Our guess is that the information about the detected machines is used for lateral movements.

The malware also drops other elements in the Windows directory: cscc.dat and dispci.exe

The malware encrypts files with the selected extensions. All the files are encrypted with the same key (the same plaintext gives the same ciphertext).

Below, we demonstrate a visualization of a sample BMP file before and after being encrypted by BadRabbit:

It does not change files extensions. The marker indicating that the file has been encrypted is added at the end of the file content—it’s a unicode text: “%encrypted”:

Here’s the dropped ransom note. As before, it’s in TXT format, named Readme.txt:

As NotPetya did before, BadRabbit adds a scheduled task for the system reboot:

After the attack is completed, the system is restarted and the bootlocker screen pops up:

We can clearly see the similarity with the screen that was displayed by Petya/NotPetya:

However, this time there is no fake CHKDSK known from each of the Petya editions.

Following the ransom notes, we see that there are two encryption keys that the victim must get in order to be able to recover the files. The first one is the key to the bootlocker. After unlocking the first stage, the second key is required to unlock the files.

Website for the victim

Last time, the authors of the attack tried to use a single email account to communicate with the victims. Of course, this was unreliable, as they soon lost the access to the account. This time, like most of the ransomware authors, they created a Tor-based webpage. The authors invested more effort in the user experience, and the website contains visual effects, including a ransom note that slowly emerges from colorful, animated text:

After pasting the key from the ransom note, the victim is given an individual bitcoin address:

They also provide a box that can be used for reporting problems.


This malware has multiple elements. Execution starts in the PE file that is responsible for dropping and installing other elements.

The first component—infpub.dat—is analogical to the perfc.dat known from the NotPetya attack. This time, the DLL exports two functions:

The function at ordinal #1 is deployed first by the main dropper:

This DLL contains an infector that spreads malware into other machines in the LAN. Among other methods, we see WMIC being used to deploy the modules dropped on remote machines. The responsible code looks similar to the analogical elements of Petya/NotPetya:

This time, in addition to the credentials dumped with the help of the Mimikatz-based module, the sample tries to perform a dictionary attack and “guess” some of the passwords for remote logins. The list consists of commonly used passwords:

The same DLL is also responsible for infecting files one by one. Encryption is performed with the help of Windows Crypto API:

Some of the system directories are exempted from the attack:

\Program Files

Their list of the attacked extensions looks like the extended version of the list used by Petya/NotPetya:

3ds 7z accdb ai asm asp aspx avhd back bak bmp brw c cab
cc cer cfg conf cpp crt cs ctl cxx dbf der dib disk djvu
doc docx dwg eml fdb gz h hdd hpp hxx iso java jfif jpe 
jpeg jpg js kdbx key mail mdb msg nrg odc odf odg odi odm
odp ods odt ora ost ova ovf p12 p7b p7c pdf pem pfx php 
pmf png ppt pptx ps1 pst pvi py pyc pyw qcow qcow2 rar rb
rtf scm sln sql tar tib tif tiff vb vbox vbs vcb vdi vfd
vhd vhdx vmc vmdk vmsd vmtm vmx vsdx vsv work xls xlsx x
ml xvd zip

The AES key is generated with a cryptographically secure function CryptGenRand.

Then it is passed to the encrypting routine, along with other parameters, such as a hardcoded public key (used later to protect the random key and preserve it in a form that can be decrypted only by the attackers):


This module drops and installs other modules used to carry out other stages of the attack. One of them is a legitimate disk cryptor (cscc.dat). It is dropped and installed as a service:

The random key is later passed to another application that is dropped by this module—dispci.exe. That element is responsible for carrying the operation of encrypting the disk.

That module gets the randomly generated key in the -id parameter:

So, the random AES key is preserved for some time in unencrypted form as a command given to be deployed.


This module communicates with the dropped driver using appropriate IOCTLs. The dropped driver is a legitimate module used for disk encryption—dispci.exe is made to adopt the driver’s features for malicious purpose. Example:

In its resources, we can find the low-level components that are installed directly to the disk (analogically to the Petya kernel installed by the previous version). The first resource is a bootloader, and the other two are analogical variants of the malicious kernel:

The low-level components: bootloader and kernel

This time the low-lever part looks different than in the case of NotPetya. Fragment of the bootloader:

It seems that authors decided to write their own kernel rather than using the one from Petya. It is also installed in a different position of the disk—at the end rather than at the beginning, as Petya did. The kernel is encrypted using a simple routine:


The code has many overlapping and analogical elements to the code of Petya/NotPetya, which suggests that the authors behind the attack are the same. Again, they tried to compose their malicious bundle out of stolen elements, however, the stolen Petya kernel has been substituted with a more advanced disk crypter in the form of a legitimate driver. It looks like the authors tried to improve upon previous mistakes and finish unfinished business. So far, it seems that in the current release, encrypted data is recoverable after buying the key, which means the BadRabbit attack is not as destructive as the previous one. However, the malware is complex and its detailed analysis will take more time. We will be updating this article with the latest findings.

Users of Malwarebytes for Windows are protected from BadRabbit. It is detected as Ransom.BadRabbit.

Summary about the previous attack, Petya/NotPetya:

This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog:

The post BadRabbit: a closer look at the new version of Petya/NotPetya appeared first on Malwarebytes Labs.

Go to Source
Author: Malwarebytes Labs

Magniber Ransomware Wants to Infect Only the Right People


Exploit kit (EK) use has been on the decline since late 2016;
however, certain activity remains consistent. The Magnitude Exploit
Kit is one such example that continues to affect users, particularly
in the APAC region.

In Figure 1, which is based on FireEye Dynamic threat Intelligence
(DTI) reports shared in March 2017, we can see the regions affected by
Magnitude EK activity during the last three months of 2016 and the
first three months of 2017.

Figure 1: Magnitude EK distribution as
seen in March 2017

This trend continued until late September 2017, when we saw
Magnitude EK focus primarily on the APAC region, with a large chunk
targeting South Korea. Magnitude EK activity then fell off the radar
until Oct. 15, 2017, when it came back and began focusing solely on
South Korea. Previously it had been distributing Cerber ransomware,
but Cerber distribution has declined (we have also seen a decline of
Cerber being distributed via email) and now it is distributing
ransomware known as Magniber.


The first reappearance of Magnitude EK on Oct. 15 came as a
malvertising redirection from the domain: fastprofit[.]loan. The
infection chain is shown in Figure 2.

Figure 2: Infection chain

The Magnitude EK landing page consisted of CVE-2016-0189, which was
first reported by FireEye as being used in Neutrino
Exploit Kit
after it was patched. Figure 3 shows the landing
page and CVE usage.

Figure 3: Magnitude EK landing page

As seen previously with Magnitude EK, the payload is downloaded as a
plain EXE (see Figure 4) and domain infrastructure is hosted on the
following server:

“Apache/2.2.15 (CentOS) DAV/2 mod_fastcgi/2.4.6”

Figure 4: Magnitude payload header and
plain MZ response


In the initial report published
by our colleagues at Trend Micro
, the ransomware being
distributed is referred to as Magniber. These ransomware payloads only
seem to target Korean systems, since they won’t execute if the system
language is not Korean.

Magniber encrypts user data using the AES128. The sample used
(dc2a2b84da359881b9df1ec31d03c715) for this analysis was pulled from
our DTI system when the campaign was active. Of note, this sample
differs from the hash shared publically by Trend Micro, but the two
exhibit the same behavior and share the infection vector, and both
were distributed around the same time.

The malware contains a binary payload in its resource section
encrypted in reverse using RC4. It starts unpacking it from the end of
the buffer to its start. Reverse RC4 decryption keys are 30 bytes long
and also contain non-ASCII characters. They are as follows:

  • dc2a2b84da359881b9df1ec31d03c715 RC4 key:
    • { 0x6b,
      0xfe, 0xc4, 0x23, 0xac, 0x50, 0xd7, 0x91, 0xac, 0x06, 0xb0,
      0xa6, 0x65, 0x89, 0x6a, 0xcc, 0x05, 0xba, 0xd7, 0x83, 0x04,
      0x90, 0x2a, 0x93, 0x8d, 0x2d, 0x5c, 0xc7, 0xf7, 0x3f }

The malware calls GetSystemDefaultUILanguage, and if the
system language is not Korean, it exits (instructions can be seen in
Figure 5). After unpacking in memory, the malware starts executing the
unpacked payload.

Figure 5: Language check targeted at Korea

A mutex with name “ihsdj” is created to prevent multiple
executions. The payload then generates a pseudorandom 19-character
string based on the CPU clock from multiple GetTickCount calls.
The string is then used to create a file in the user’s %TEMP%
directory (e.g. “xxxxxxxxxxxxxxxxxxx.ihsdj”), which contains
the IV (Initialization Vector) for the AES128 encryption and a copy of
the malware itself with the name “ihsdj.exe”.

Next, the malware constructs 4 URLs for callback. It uses the
19-character long pseudorandom string it generated, and the following
domains to create the URLs:


In order to evade sandbox systems, the malware checks to see if it’s
running inside a VM and appends the result to the URL callback. It
does this by sandwiching and executing CPUID instructions (shown in
Figure 6) between RDTSC calls, forcing VMEXIT.

Figure 6: CPUID instruction to detect VM presence

The aforementioned VM check is done multiple times to gather the
average execution time of the CPUID, and if the average execution time
is greater than 1000, it considers the system to be a VM. In case the
test fails and the malware thinks the system is a VM, a “1”
is appended at the end of the URL (see Figure 7); otherwise,
“0” is appended. The format of the URL is as follows:

  • http://[19 character pseudorandom string].[callback
    domain]/new[0 or 1]

Examples of this would be:

  • http://7o12813k90oggw10277.bankme[.]date/new1
  • http://4bg8l9095z0287fm1j5.bankme[.]date/new0

Figure 7: Command and control communication

If the malware is executed a second time after encryption, the
callback URL ends in “end0” or “end1” instead of
“new”. An example of this would be:

  • hxxp://j2a3y50mi0a487230v1.bankme[.]date/end1

The malware then starts to encrypt user files on the system,
renaming them by adding a “.ihsdj” extension to the end. The
public key for the AES128 and IV for the sample analyzed are:

  • IV: EP866p5M93wDS513
  • Public Key AES128: S25943n9Gt099y4K

A text file “READ_ME_FOR_DECRYPT_xxxxxxxxxxxxxxxxxxx_.txt”
is created in the user’s %TEMP% directory and shown to the user. The
ransom message is shown in Figure 8.

Figure 8: Ransom message for the infected user

The malware also adds scheduled tasks to run its copy from %TEMP%
with compatibility assistant, and loads the user message as follows:

  • schtasks /create /SC MINUTE /MO 15 /tn ihsdj /TR
    “pcalua.exe -a %TEMP%ihsdj.exe
  • schtasks /create /SC
    MINUTE /MO 15 /tn xxxxxxxxxxxxxxxxxxx /TR

The malware then issues a command to delete itself after exiting,
using the following local ping to provide delay for the deletion:

  • cmd /c ping localhost -n 3 > nul & del

Figure 9 contains the Python code for unpacking the malware payload,
which is encrypted using RC4 in reverse.

Figure 9: Python script for unpacking
malware payload


Ransomware is a significant threat to enterprises. While the current
threat landscape suggests a large portion of attacks are coming from
emails, exploit kits continue to put users at risk – especially those
running old software versions and not using ad blockers. Enterprises
need to make sure their network nodes are fully patched.


Malware Sample Hash
  • dc2a2b84da359881b9df1ec31d03c715 (decryption key shared)
Malverstiser Domains
  • fastprofit[.]loan
  • fastprofit[.]me
EK Domain Examples
  • 3e37i982wb90j.fileice[.]services
  • a3co5a8iab2x24g90.helpraw[.]schule
  • 2i1f3aadm8k.putback[.]space
Command and Control Domains

Go to Source
Author: Muhammad Umair

Magniber ransomware: exclusively for South Koreans

The Magnitude exploit kit has been pretty consistent over the last few months, dropping the same payload—namely, the Cerber ransomware—and targeting a few select countries in Asia. Strangely, Magnitude EK disappeared in late September, and for a while we wondered whether this was yet another casualty in the already deflated exploit kit scene.

However, a few days ago Magnitude EK resurfaced, this time with a new payload. The delivered malware is also a ransomware, but of a family that was not known before. It has been named Magniber.

This Magniber ransomware is highly targeted, as it checks at several levels (external IP, the language installed, etc.) to ensure that the attacked system is only South Korean. Targeting a single country is unusual on its own, but performing multiple checks to be sure of the country and language of origin makes this a first for ransomware.

Analyzed samples

Older sample

Distribution method

So far, we found this ransomware is dropped only by the Magnitude exploit kit:

No other distribution method is known at the moment.

Behavioral analysis

If the malware is executed on non-Korean systems, the only thing we can see is the operation of deleting itself, delayed by running the ping command:

It only starts its malicious operations on systems with Korean language detected. The executable is pretty noisy, because it implements various tasks just by command line. Running it on the sandbox, we can see the following graph of calls:

The malware copies itself in %TEMP% and deploys itself with the help of task scheduler:

In the same folder, we can see also the ransom note and yet another file. Its name is the same as the part of the domain that has been generated for the particular user, and its extension is the same as the extension of the encrypted files:

To each encrypted file is added an extension that is composed of small Latin characters and is constant for the particular sample of Magniber.

The same plain-text makes the same cipher-text. This means each and every file is encrypted using exactly the same key.

Below, we demonstrate a visualization of bytes of a sample BMP file before and after being encrypted by Magniber:

As you can see, there are no visible patterns in the encrypted version; it suggests that some strong algorithm has been used, probably AES in CBC mode.

At the beginning of each encrypted file, we find a 16-character long identifier that is constant for the particular sample of Magniber:

After the encryption of all the found files is done, the ransomware runs notepad, displaying the dropped ransom note:

The ransom note is in the TXT format and its structure is minimalistic. It gives four alternative addresses pointing to the page for the victim.

Page for the victims

The page for the victims is in English only. Its template is very similar to the one used by the Cerber ransomware (this is the only similarity between those ransomware families—internally they are quite different):

Network communication

We found Magniber connecting domains that are generated by the built-in algorithm. The same domains that are used as CnC are later used for individual websites for the victim (only they are called with a different parameter). Examples of the called URLs:

Compare the URLs from the ransom note with the corresponding run:

At the beginning of the execution, the ransomware sends a request to the URL ending with new1 (or new0). At the end of the execution, it requests end1 (or end0). The meaning of those URLs will be explained in detail in the next part of the article.

What’s interesting is that the server gives a valid response if, and only if, the public IP of the victim was Korean. Otherwise, the response is empty. Example of the captured initial request and response (the request was made from the Korean IP):

In the response, we get a 16-character long, random string: ce2KPIak3cl6JKm6. The new random URL can be requested only once. If we try to repeat the request, we will get an empty response.

The other request (the ending one) also gives a 16-character long, random string in response. But contrary to the first one, it responds on every request (a different random string each time). Example of the ending request and response:

Inside the code

As always, to understand what is really going on here, we will have to take a deeper dive inside the code.

Magniber is delivered packed by various crypters, and the unpacking method will depend on the crypter’s features. You can see the process of unpacking the current sample in the video below.

After defeating the first layer, we obtain the second PE file: the malicious core. The core does not contain any advanced obfuscation. The authors made the strings just slightly difficult to follow by loading them into memory character by character:

Execution flow

Looking inside the unpacked payload, we can clearly see why it doesn’t run on most systems. At the beginning, there is a language check (using the API function GetSystemDefaultUILanguage):

The only accepted UI language is Korean (code 1042). In case of any other detected, the sample just deletes itself and causes no harm. This language check has been added in the recent Magniber samples and was not found in the earlier versions, such as aa8f077a5feeb9fa9dcffd3c69724c942d5ce173519c1c9df838804c9444bd30.

After the check is passed, Magniber follows with a typical ransomware functionality. Overview of the performed steps:

  1. Creates mutex
  2. Checks in the temp folder if the marker file has been dropped
  3. Drops the copy of itself in %TEMP% and adds the scheduled task
  4. Queries the generated subdomains to retrieve the AES key (if retrieving the key failed, loads the hardcoded one)
  5. Enumerates and encrypts files with the selected extensions
  6. Reports finishing the task to the CnC
  7. Executes the notepad displaying the ransom note
  8. Deletes itself

What is attacked?

The list of extensions attacked by Magniber is really long. It includes documents, source code files, and many others. The complete list is below:

docx xls xlsx ppt pptx pst ost msg em vsd vsdx 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 vdi vmx gpg 
aes raw cgm nef psd ai svg djvu sh class jar java rb asp php jsp brd sch dch 
dip vb vbs ps1 js asm pas cpp cs suo sln ldf mdf ibd myi myd frm odb dbf db 
mdb accdb sq sqlitedb sqlite3 asc lay6 lay mm 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 1cd cd arw jpe eq adp odm dbc frx db2 dbs pds pdt dt cf cfu 
mx epf kdbx erf vrp grs geo st pff mft efd rib ma lwo lws m3d mb obj x3d c4d 
fbx dgn 4db 4d 4mp abs adn a3d aft ahd alf ask awdb azz bdb bib bnd bok btr 
cdb ckp clkw cma crd dad daf db3 dbk dbt dbv dbx dcb dct dcx dd df1 dmo dnc 
dp1 dqy dsk dsn dta dtsx dx eco ecx emd fcd fic fid fi fm5 fo fp3 fp4 fp5 
fp7 fpt fzb fzv gdb gwi hdb his ib idc ihx itdb itw jtx kdb lgc maq mdn mdt 
mrg mud mwb s3m ndf ns2 ns3 ns4 nsf nv2 nyf oce oqy ora orx owc owg oyx p96 
p97 pan pdb pdm phm pnz pth pwa qpx qry qvd rctd rdb rpd rsd sbf sdb sdf spq 
sqb stp str tcx tdt te tmd trm udb usr v12 vdb vpd wdb wmdb xdb xld xlgc zdb 
zdc cdr cdr3 abw act aim ans apt ase aty awp awt aww bad bbs bdp bdr bean 
bna boc btd cnm crw cyi dca dgs diz dne docz dsv dvi dx eio eit emlx epp err 
etf etx euc faq fb2 fb fcf fdf fdr fds fdt fdx fdxt fes fft flr fodt gtp frt 
fwdn fxc gdoc gio gpn gsd gthr gv hbk hht hs htc hz idx ii ipf jis joe jp1 jrtf
kes klg knt kon kwd lbt lis lit lnt lp2 lrc lst ltr ltx lue luf lwp lyt lyx man 
map mbox me mel min mnt mwp nfo njx now nzb ocr odo of oft ort p7s pfs pjt prt 
psw pu pvj pvm pwi pwr qd rad rft ris rng rpt rst rt rtd rtx run rzk rzn saf 
sam scc scm sct scw sdm sdoc sdw sgm sig sla sls smf sms ssa sty sub sxg tab 
tdf tex text thp tlb tm tmv tmx tpc tvj u3d u3i unx uof upd utf8 utxt vct vnt 
vw wbk wcf wgz wn wp wp4 wp5 wp6 wp7 wpa wpd wp wps wpt wpw wri wsc wsd wsh wtx
xd xlf xps xwp xy3 xyp xyw ybk ym zabw zw abm afx agif agp aic albm apd apm 
apng aps apx art asw bay bm2 bmx brk brn brt bss bti c4 ca cals can cd5 cdc 
cdg cimg cin cit colz cpc cpd cpg cps cpx cr2 ct dc2 dcr dds dgt dib djv dm3 
dmi vue dpx wire drz dt2 dtw dv ecw eip exr fa fax fpos fpx g3 gcdp gfb gfie 
ggr gih gim spr scad gpd gro grob hdp hdr hpi i3d icn icon icpr iiq info ipx 
itc2 iwi j2c j2k jas jb2 jbig jbmp jbr jfif jia jng jp2 jpg2 jps jpx jtf jw 
jxr kdc kdi kdk kic kpg lbm ljp mac mbm mef mnr mos mpf mpo mrxs my ncr nct 
nlm nrw oc3 oc4 oc5 oci omf oplc af2 af3 asy cdmm cdmt cdmz cdt cmx cnv csy 
cv5 cvg cvi cvs cvx cwt cxf dcs ded dhs dpp drw dxb dxf egc emf ep eps epsf 
fh10 fh11 fh3 fh4 fh5 fh6 fh7 fh8 fif fig fmv ft10 ft11 ft7 ft8 ft9 ftn fxg
 gem glox hpg hpg hp idea igt igx imd ink lmk mgcb mgmf mgmt mt9 mgmx mgtx 
mmat mat ovp ovr pcs pfv plt vrm pobj psid rd scv sk1 sk2 ssk stn svf svgz 
tlc tne ufr vbr vec vm vsdm vstm stm vstx wpg vsm xar ya orf ota oti ozb 
ozj ozt pa pano pap pbm pc1 pc2 pc3 pcd pdd pe4 pef pfi pgf pgm pi1 pi2 pi3 
pic pict pix pjpg pm pmg pni pnm pntg pop pp4 pp5 ppm prw psdx pse psp ptg 
ptx pvr px pxr pz3 pza pzp pzs z3d qmg ras rcu rgb rgf ric riff rix rle rli
 rpf rri rs rsb rsr rw2 rw s2mv sci sep sfc sfw skm sld sob spa spe sph spj 
spp sr2 srw wallet jpeg jpg vmdk arc paq bz2 tbk bak tar tgz gz 7z rar zip 
backup iso vcd bmp png gif tif tiff m4u m3u mid wma flv 3g2 mkv 3gp mp4 mov
avi asf mpeg vob mpg wmv fla swf wav mp3 

The list loads at the beginning of the file encrypting function:

As usual, some of the directories are exempted:

:documents and settingsall users 
:documents and settingsdefault user 
:documents and settingslocalservice 
:documents and settingsnetworkservice 
local settings 
publicmusicsample music 
publicpicturessample pictures 
publicvideossample videos 
tor browser 
program files (x86) 
program files 
system volume information 

How does the encryption work?

Magniber encrypts files with AES 128 bit in CBC mode. It is implemented with the help of Windows Crypto API.

 The DGA and the victim ID

In the usual scenario, the malware tries to retrieve the AES key from the CnC by querying pseudo-random subdomains:

The pseudo-random part is used to uniquely identify the victim. It is generated by the following simple algorithm:

Each character is based on the tick count, converted to the given charset:

The number 0 or 1 is appended to the URL depending if the sample is running under the debugger or not (detected using time check).

Four domains are being queried for the key:

If any of them give a 16-byte long response, that means the valid key is copied to the buffer and used further. Otherwise, it falls back to the hardcoded key.

The default AES key and IV

The interesting thing is that each sample comes with the AES key hardcoded. However, it is used only as a backup if downloading the key from the CnC was for some reason impossible (that occurs also in the case if the public IP was not from Korea). The key is unique per each sample. In the currently analyzed sample, it is S25943n9Gt099y4K:

If any of them gives 16  byte long response, that means the valid key, it is copied to the buffer and used further. Otherwise, it falls back to the hardcoded key.

Similarly, the initialization vector is always hardcoded in the sample (but not downloaded). The same 16-character long string was also saved at the file beginning. In the currently analyzed sample it is EP866p5M93wDS513:

The algorithm

First, the crypto context is initialized. The malware imports the key and initialization vector with the help of functions CryptImportKey, CryptSetKeyParam:

Encrypting the file:

The first write stores the 16-byte long string at the beginning of the file. Then, the file is read chunk by chunk and encrypted using Windows Crypto API.


Magniber ransomware is being distributed instead of Cerber from the same exploit kit, approaching the same targets. However, internally it has nothing in common with the Cerber and is much simpler. The only feature that makes it unique is being so picky about the targeted country. For the first time, we are seeing country checks being performed at various levels of execution.

This ransomware family appeared recently and probably is still under active development. We will keep an eye on its evolution and keep you informed.

The users of Malwarebytes for Windows (with real-time, anti-ransomware technology deployed) are protected against Magniber.


The post Magniber ransomware: exclusively for South Koreans appeared first on Malwarebytes Labs.

Go to Source
Author: hasherezade

Necurs attackers now want to see your desktop

Recently we have seen a resurgence of emails sent by the Necurs botnet. The latest blast of emails is spreading a new variant of the Locky ransomware (Ransom.Locky) or Trickybot (Trojan.Trickybot). What’s interesting about this new wave is that the downloader now contains new functionality to gather telemetry from victims. It can take screen grabs and send them back to a remote server. There’s also an error-reporting capability that will send back details of any errors that the downloader encounters when it tries to carry out its activities.

Beware of strangers offering fake invoices

The new emails use a tried-and-tested invoice-based social engineering format, and generally contain the following details:

Subject: Status of invoice [FAKE INVOICE NUMBER]

Attachment:  [FAKE INVOICE NUMBER].html

The body of the email contains a message urging the reader to open the attachment to check the invoice.

Standard precautions apply here; when strangers offer you unsolicited invoices or deliveries via email, the safest course of action is to simply trash the email.

An example of Necurs spam email

Figure 1. Typical invoice email sent by Necurs botnet

If the attached .html file is opened, it will download a JavaScript via an embedded iframe. The JavaScript will download the payload which will either be Locky or Trickybot.

Attackers need operational intelligence too

Besides the standard download and execute final payload functionality, the downloader also runs a PowerShell script that takes a screen grab and saves it to a file named generalpd.jpg.

It then waits a few seconds for the Save operation to complete and then starts off a command to upload the saved .jpg to a remote server.

PowerShell script used by Necurs

Figure 2. PowerShell script that captures a screenshot and then uploads it

This functionality is interesting because downloaders tend to just deliver a payload and then disappear as quickly as possible. When you consider the screen grab functionality together with the new error-reporting capability, it suggests that the Necurs attackers are actively trying to gather operational intelligence (OPINTEL) about the performance of their campaigns. Much like crash reports in OSes can help software companies fix issues and build better products, these error reports can help attackers spot problems in the field and address them to improve success rates. After all, you can’t count on the victims to report back errors and issues!

Attackers need operational intelligence too. #Necurs downloader now also collecting OPINTEL.CLICK TO TWEET

Necurs: back with a vengeance

Necurs went through a long spell of silence from end of 2016 and into early 2017. It burst back onto the scene around March and since then, it has been cranking up its activity levels, with recent months seeing the most action so far in 2017.

Figure 3. Symantec telemetry shows Necurs emails with script attachments have grown fourfold since June

Figure 3. Symantec telemetry shows Necurs emails with script attachments have grown fourfold since June

With our data showing a resurgence in activity, and the apparent efforts to collect operational intelligence, we can expect to see continued evolution of the capabilities and a steady increase in Necurs activity levels in the coming months.

Whatever the attackers choose to do, our analysts will be keeping a close eye on developments as the campaigns continue to evolve.


Symantec recommends users follow these best practices to stay protected from ransomware and other threats:

  • Delete any suspicious-looking emails you receive, especially if they contain links or attachments.
  • Always keep your security software up to date to protect yourself against any new variants of malware.
  • Keep your operating system and other software updated. Software updates will frequently include patches for newly discovered security vulnerabilities that could be exploited by attackers.
  • Regularly back up any files stored on your computer. If your computer does become infected with ransomware, your files can be restored once the malware has been removed.

Go to Source
Author: Symantec Security Response

Threat Brief: Understanding Kernel APC Attacks

In the months since the WanaCrypt0r/WannaCry and the Petya/NotPetya attacks, security researchers have delved into the nuts and bolts these incidents and the malware involved.

One key thing that research into these security incidents shows is that these attacks used a relatively new and unknown technique called kernel APC attacks as part of their toolkit.

Kernel APC attacks occur in a way that increases the “stealth” factor and makes standard detection and prevention very difficult. And kernel APC attacks do this while still maximizing the power and control that the code has on the target system.

While kernel APC attacks aren’t well known and can be hard to understand, their proven success in WanaCrypt0r/WannaCry and the Petya/NotPetya make them an important threat to understand because proven attack techniques are quickly adopted widely. And understanding is a first step to prevention.

To understand what makes kernel APC attacks so dangerous, it’s important to understand what they are.

The kernel is the heart of the operating system. When talking about operating systems with security permissions and controls like Windows or UNIX/Linux, the kernel operates with the highest level of control. Because of this, attacks against the kernel are used to gain complete control over a system, generally as part of an “elevation or privilege” (EoP) or “privilege escalation” attack. Typically, attacks against the kernel are used in conjunction with code execution attacks so that an attacker can target a limited privilege user but ultimately gain full control over the system.

Privilege escalation attacks against the kernel have been around for some time and are well-known and can be well protected against.

Kernel APC attacks however are a different class of attack. These don’t attack the kernel to gain privileges. Instead kernel APC attacks already have kernel privileges and use them to further carry out their attack. In this case by making legitimate programs execute malicious code rather than their own legitimate code.

Kernel APC attacks do this using their control over the kernel to redirect APCs: “Asynchronous Procedure Calls”. APCs can basically be thought of as places in line for the CPU that the kernel gives access to. In a kernel APC attack, the attacker gives a legitimate program’s place in line to the attacker’s code.

The crux of what makes this attack technique so important is how the technique uses this level of control to have legitimate programs run illegitimate commands. It’s easier to detect and prevent illegitimate programs (malware) from executing commands. But when legitimate programs execute illegitimate commands, it’s harder to detect and prevent: it’s not always clear whether a command is legitimate or not, and interfering with commands from legitimate programs can have significant (sometimes catastrophic) unintended consequences. And finally because of ways that kernel APC attacks are carried out, it doesn’t leave the usual fingerprints you find after an attack making detection harder still.

Taken altogether, these make kernel APC attacks an effective and sophisticated technique. And while this technique alone isn’t solely responsible for the damaging power of WanaCrypt0r/WannaCry and Petya/NotPetya it is certainly an important contributing factor.

Perhaps more importantly, it’s a piece of those attacks that has escaped relative notice outside of some specialized parts of the research community.

New effective attack techniques that escape notice are always inviting for other copycat attackers. A good way to defend against this is to understand and be aware of the thread: forewarned is forearmed.

If you want a more detailed understanding of kernel APC attacks as they occurred in WanaCrypt0r/WannaCry, two good resources are Microsoft’s MMPC blog “WannaCrypt ransomware worm targets out-of-date systems” and Countercept’s “DOUBLEPULSAR Usermode Analysis: Generic Reflective DLL Loader”.

The post Threat Brief: Understanding Kernel APC Attacks appeared first on Palo Alto Networks Blog.

Go to Source
Author: Christopher Budd

Powered by WPeMatico