Meeting Cliff Stoll

Today I had the chance to meet the man who unintentionally invented the modern digital forensics practice, Cliff Stoll. In 1989 he published a book about his 1986-87 detection and response against KGB-backed spies who hacked his lab and hundreds of government, military, and university computers. I read his book in high school and it later inspired my military and private computer security services. Cliff was kind enough to take a photo with me today at the SANS Institute Cyber Threat Intelligence Summit in Virginia.

A look back at the Zyns iframer campaign

We often get asked about drive-by download attacks, how they work, and specifically about what sites people may have visited just prior to getting infected. This is an interesting aspect when tracking campaigns and what they lead to.

Typically, one can divide the drive-by landscape into two categories: malvertising and compromised websites. The former involves legitimate websites that rely on advertising as their source of revenue. Crooks have long been able to insert themselves into the ad delivery chain in order to push malicious code such that the simple fact of viewing a page with ads actually infects your computer. The latter is made of websites that have been hacked and injected with malicious code and are also used to redirect users to malicious content.

What we refer to as “campaigns” are specific attributes from the same threat actor or group similar to what is used to categorize malware families. There are many different campaigns for both streams, some come and go while others stick around for long periods of time. For instance, EItest is one particular campaign for compromised sites which has been going on for years.

Campaigns are an essential part of the underground ecosystem because they continuously feed potential new victims into the infection funnel which ultimately translates into revenues for online criminals.

Today we are taking a look at an iframe campaign (Zyns iframer) that has been going on since at least 2014. There are specific indicators of compromise (IOCs) that haven’t really changed over time and the underlying structure has also remained pretty similar. We have seen this attack chain primarily associated with malvertising, and in particular via adult sites. During its course, we noted several different exploit kits being pushed by this campaign (Angler EK, Nuclear Pack, Neutrino EK, RIG EK).

Patterns (IOCs)

The redirection infrastructure had very distinct patterns and also shared many of the same server IP addresses over time. We also saw the evolution from dynamic DNS (via sub domains) to domains on dubious top-level domains (TLDs).

URL patterns:


Server headers:

HTTP/1.1 200 OK
Server: Apache/2.2.22 (@RELEASE@)
X-Powered-By: PHP/5.3.3

Redirection URL:

<iframe src="[EK URL HERE]" width="468" height="60" 

First spotted, 2014

Our earliest records are from the fall of 2014 with malvertising attacks mostly affecting Russian users. A capture from later that year shows a drive-by download from via JetSwap, an “Active Promotion System!” where members and advertisers are linked together via an affiliate program. In this particular case, the advert loads a malicious iframe to which performs a 302 redirect to another domain and in turn redirects to the Angler exploit kit.


Payload: SmokeLoader.

2014-2015 transition

The campaign kept going as 2015 rolled in with an almost identical structure. Note the addition of ‘link.php’ to the domain in charge of loading iframes to EK. Angler wasn’t the only exploit kit used by these actors. For example we see Nuclear Pack below:


Payloads: Bedep (2nd Bedep), Troldesh.

Sucuri Labs post shows another domain involved in redirect:

A piece of code containing the same iframe redirection structure was posted in May 2015 to an online PHP editor. It shows a distinct URL pattern for the RIG exploit kit (RIG EK version 3).


2016 was an interesting year for exploit kits with the disappearance of Angler EK in June. The capture shown below is one of the latest artifacts we have from Angler EK before it went missing.


Payload: JuicyLemon (ransomware).

As we know, criminals transitioned to Neutrino EK after Angler EK went down. During the next few months, up until sometime in September there was a mix of both Neutrino EK and RIG EK used by the actors behind this campaign. Below, Neutrino EK in July:


The campaign was spotted in late June by Malekal (link) via malvertising on adult sites (with Gootkit mentioned as the payload).

Malware Traffic Analysis wrote a blog entry shortly after (link): port 80 - - GET /engine/classes/js/jquery.js - file with injected script port 80 - - GET /linkx.php - gate port 80 - - RIG EK

and in July Broad Analysis did too (link): – – GET /engine/classes/js/jquery.js – Rig EK REDIRECT – – GET /linkx.php – Rig EK REDIRECT – ds.pacificbeachcar.comRig EK LANDING PAGE

RIG EK (also known as RIG Standard), seen in September:


Payload: Vawtrak.

In early December, we noticed a slight change with a new domain used as a redirector. At the same time, there were several instances where two different RIG EKs were pushed from the same redirection chain, leading to two different malware payloads.

Payloads: Gootkit,  Moker.


In January we started seeing the same redirector that had been pushing this campaign switch to a different chain, this time via compromised sites. This was interesting because throughout December, we were seeing the usual sequence of events with the standard iframe, even though this chain came via a different sid (sid 3) than the typical sid 1.

December 2016 (with sid=3)

Payload: Gootkit.

Come January and we have a completely new pattern where an iframe is now inserted via a double chain of events, most notably malicious code injection that looked new to me within a WordPress plugin called Contact Form 7.

January 2017 (also with sid=3)

Payload: Gootkit.

The end of the road?

In January, several different trails we were tracking began to disappear, showing that the Zyns iframer campaign was likely evolving or got merged into something else. The diversity of payloads and exploit kits may indicate there was no particular tie with any specific malware distributor.

Threat actors will buy traffic from various sources to push malware, with malvertising often being the top choice for its wide impact. This particular case is a mix of malvertising and bogus adult websites aimed at driving a lot of users into exploit kit landing pages.

To protect yourself against drive-by download attacks, the first thing to do is to ensure that your computer is fully up-to-date. Use Malwarebytes to stay safe from malicious websites and thwart exploits (known and unknown) before they launch their payload.

Thanks to @hasherezade for help with payload identification!


Dec 2014


July 2015


June 2016


July 2016


September 2016


December 2016


Malware hashes:


Locky Bart ransomware and backend server analysis

In this post we will cover the Locky Bart ransomware. The developers of Locky Bart already had 2 very successful ransomware campaigns running called “Locky” and “Locky v2”. After some users reported being infected with Locky Bart, we investigated it to find the differences as to gain greater knowledge and understanding of this new version.

The Locky Bart ransomware has new features that are different from its predecessors. It can encrypt a machine without any connection to the Internet. It also has a much faster encryption mechanism.

Our research would also indicate that the backend infrastructure of Locky Bart might be maintained by a different threat actor than the original versions. While the internals of the malicious binary share a great number of similarities, there were some notable differences.

These included: Comments in the code of the application, but more notably the kind of software used in the backend server.

This did not come as a surprise, as cyber-criminals are known to share, rent, sell, and even steal malicious code from one another.

Analysis of Locky Bart’s binary

In their previous incarnations, Locky and Locky v2 used a simpler encryption process. They enumerated the files targeted for encryption, placed each in a password protected ZIP archive, and repeated this process until all the files were encrypted. The creators did not use the AES ZIP protection, but an older algorithm, and because of this, researchers were able to make a decrypting application.

Locky Bart performs a fairly straight forward set of actions to encrypt the victim’s files. They are as follows:

  • Wipe System Restore Points with VSSadmin.
  • Generate a seed to create a key to encrypt user’s files.
  • Enumerate the files it wants to encrypt, skipping certain folders to speed it up.
  • Encrypt the enumerated files with the generated key.
  • Encrypt the key used to encrypt the files with a master Kkey, which now becomes the victim’s “UID” used to identify them.
  • Create a ransom note on the desktop with a link to a payment page and their “UID”.

The function used to generate a seed, which is used to create a key to encrypt the files with. It uses variables like system time, process ID, thread ID, Process Alive Time, and CPU ticks to generate a random number.

The function used to enumerate and encrypt the files.

Bart will skip any folders with these strings in them.

The file-types that Bart targets to encrypt.

The string that Bart uses to make a Ransom Note. The “khh5cmzh5q7yp7th.onion” is the payment server, and the “AnOh/Cz9MMLiZMS9k/8huVvEbF6cg1TklaAQBLADaGiV” is a sample UID that would be sent with the URL to the server for the victim to make a payment. Remember that the UID is only an encrypted version of the key that can be used to decrypt a victim’s files.

How the creators of Bart Locky acquire the key is what differentiates this version from its predecessors. When the victim of the ransomware visits the URL to make their payment for the ransom, they are unknowingly sending their decryption key to the criminals.

Let’s break down the process in a more granular method, to better understand it.

  • Bart Locky gathers information on the victim’s machine to create an encryption key.
  • Bart Locky encrypts the user’s files using the seeded key created in the previous step.
  • Bart Locky then encrypts the key that was used for the original encryption with a one way encryption mechanism, using the public key of a public / private key pair method. The private key for this second encryption resides on the malicious server and is never accessible to the victim.
  • Bart Locky then generates a URL on the victim’s machine. It contains the link to a TOR cloaked .onion address where the malicious backend website is hosted. This URL has a user ID within it. This UID is the original decryption key, in encrypted form.
  • The victims visits the .onion site and the malicious server harvests the encrypted UID.

This UID is useless to the victim though, because they do not have the private key to decrypt their files. However, the ransomware creator’s server does, meaning his server can not only use the UID to identify the victim, but also decipher the UID into their victim’s key upon payment of the ransom.

In the end, only the ransomware creators can decrypt the user’s files, and because of this feature, there is no need to access the malicious server to encrypt them.

Locky Bart Software Protection technique

The Bart Locky binary also uses a software protection technique. This technique is known as code virtualization and is added to Bart Locky binary by using a program called “WPProtect”.

This makes reversing the binary significantly more difficult to disassemble and complicates stepping through the code, a technique used to understand what it does. Legitimate uses of this type of software are most typically seen in anti-piracy mechanisms. An example of a commercial version of this type of software would be Themida. The author of Bart Locky probably chose this particular anti-tampering mechanism as it is free, open source, and provides many features. This adoption of software protection techniques is a troubling development. These applications, including WPProtect, make reversing and analysis significantly more challenging.

The Locky Bart server

The second half of Locky Bart is the server and backend. This server is used to provide the victims with a payment mechanism to pay the ransom.

  • Receive the bitcoins used as a payment method.
  • Transfer the bitcoins to other wallets.
  • Generate a decryption EXE for the victims.
  • Provide the victims with the decryption EXE to the victims.
  • Accrue additional information on the victims.

The Bart Locky backend runs on a framework called yii. Yii is a high-performance PHP framework best for developing Web 2.0 applications.

This framework contains a wealth of information on the inner workings of Bart Locky.

TheYii debug panel that contained extensive information about the configuration server. 

Access to this control panel revealed:

  • Every configuration setting for all the software running on the server such as PHP, Bootstrap, Javascript, Apache (if used), Nginx (If used), ZIP, and more.
  • Every request that was made to the server including their request information, header information, body, timestamp, and where they originated.
  • Logs that showed every error, trace, and debug item.
  • All the automated email functions.
  • MYSQL Monitoring that showed every statement made and its return.

Locky Bart stores information in a MYSQL database. The credentials to the MYSQL server reside in a “Config” PHP file in the “Common” folder of the site. An example path looks like the following: /srv/common/config/main-local.php

The contents of Bart’s server MYSQL config file

The information contained in the MYSQL database consists of the victims Unique IDentifier, the encryption key, BitCoin Address, Paid Status, and Timestamps.

A small part of the table holding the ransomware information in the database.

The Locky Bart server also contains a second database that contains further information on the victims of the ransomware.

Locky Bart ransomware’s “Stats” table example.

A “ReadMe” file found on the server that seems to detail some features on the Stats database.

The Locky Bart server contains a “BTCwrapper.php” which used a “controller” method that exposes a BTC Wallet Class that all other PHP files can call. This class initiates a connection to the Bitcoin servers through a username and password. This class contained complete methods on controlling and using the main BTC wallet set up by the criminal to store all the money received. This wallet is emptied regularly. This class can create new BTC Addresses as well and had the ability to empty those wallets on payment to the main wallet. There were also methods to check on the status of payments from each victim.

Some of the functions that the BTCWrapper Class calls.

The first few functions of the BTCWrapper Class. The class uses CURL to contact a locally ran bitcoin server that communicates with the block chain.

The Locky Bart server had 2 Bitcoin addresses where victims’ payments were transferred to. The current one:


The current BTC address associated with Locky Bart has accumulated $ 7,671.60 in its life time.

And a second one, that was referenced in PHP configurations on the malicious server.

An older BTC address also associated with Locky Bart had accumulated $ 457,806.06.

The server portion of this ransomware was configured to function very similar to a legitimate business. It mirrored a “Support Ticket Department” where the user could contact the ransomware support for any issues they may have experienced.

The process was completely automated. The user would get infected and visit the site as their ransom note instructed. When they visited the site, the server would then generate their unique BTC address and present it to them automatically.

After this, if the user made the decision to pay the ransom, but if they had any questions, they could literally contact support.

If they did indeed make the decision to pay, they would proceed to buy Bitcoins through the many methods available (BTC ATM, LocalBitcoins – which allows you to meet people local to trade BTC for money or use banks and wiring like Western Union, or buy them with a credit card online).

Once the user has the amount specified by the ransomware in their own BTC Wallet, they would then transfer the money from their wallet to the Payment Address the Ransomware Payment Page generated for them.

The Ransomware Server checks every few minutes if a payment has been made for any of its victims and if the payment had been confirmed. Once the server verifies a payment they mark that victim in the Database as “Paid”.

When a victim is marked as “Paid” the server then generates a “Decryption Tool EXE” and writes the users Encryption Key in the binary of that exe, and presents a link to download it on the personal payment page of the victim. Later when the victim checks their payment page again, they will see the link, download the tool, and decrypt their files.

The generation of the victim’s decryption tool on the fly.


This research into Locky Bart ransomware gives a great view of the side of a ransomware operation that we typically do not get to see, the backend. The criminals who run these operations do so on an extremely professional level, and users should always take an extra step in protecting themselves from these types of attacks.

Ransomware will continue to grow and get more advanced and users need to make sure they are protected in the form of backup’s, security application protection like Malwarebytes, and make sure they have some type of anti-ransomware technology protecting them from these advanced attacks. Users running Malwarebytes already have protection from ransomware, as Malwarebytes is equipped with our anti-ransomware technology.