Blog CryptoLocker Deep-Dive: Why We Use Bitcoin Addresses as an IOC

CryptoLocker Deep-Dive: Why We Use Bitcoin Addresses as an IOC

Follow the Money: Tracking Adversaries Through the Blockchain

WhiteRabbit is an open source research tool we're debuting at Black Hat and DEF CON 2018 that allows security analysts to link Bitcoin addresses to known malware campaigns and track payments made to these addresses. Our goal is to provide a tool that can act as an early warning system for SOC analysts, threat hunters, malware researchers, and other defenders by leveraging Bitcoin public ledger data.

As cryptocurrency gains traction in public market and criminal networks, we at TruSTAR believe Bitcoin wallet addresses (and other cryptocurrency addresses) should be added as indicators of compromise (IOCs) to the “Pyramid of Pain.” In fact, TruSTAR is the first threat intelligence platform to track Bitcoin wallet addresses as an IOC on our GraphDB.

The interesting aspect of cryptocurrency addresses is that they share characteristics of both hashes and TTPs. The research and examples outlines in this blog post will discuss why this is.

Bitcoin’s Unusual History

A new era for economic activity on the Internet started after Satoshi Nakamoto published his paper about Bitcoin, spinning up the first Bitcoin mining node. This created a stateless and decentralized currency where any person owning a device connected to the Internet can transfer money across state boundaries. No one can stop a farmer in Kenya from receiving a payment from an investor in Cairo. But this invention also allowed bad actors to leverage this new form of payment for Dark Web transactions, money laundering, and ransomware payments. Thus, as cyber professionals we entered a new epoch of digital forensics.

On September 5, 2013, CryptoLocker, a particularly tenacious malware that encrypts your personal and precious data until you pay a ransom, mainly in Bitcoin, was out in the wild. The first CryptoLocker campaign, which lasted from September 2013 to May 2014, collected nearly $534,000. Figure 1 shows payments to CryptoLocker-controlled BTC addresses starting from September 2013 till February 2014.


There are compelling reasons for cybercriminals to use Bitcoin and other cryptocurrencies:

  • It is decentralized. Money can easily be transferred across state and national territories without interception or regulation.
  • It’s pseudo-anonymous. We do know that someone transacted but we do not know exactly who.

But it’s not all roses for bad actors. Cryptocurrency also has properties that are valuable for defenders:

  • The ledger is publicly available. Anyone can spin up a node on AWS or some other cloud provider and start navigating the blockchain.
  • The data is immutable. This gives researchers the ability to study the criminals at any point in time.

TruSTAR’s WhiteRabbit research tool was created for security analysts to better leverage these two characteristics.

About our WhiteRabbit Tool

Our tool was designed to help analysts monitor clusters of Bitcoin addresses associated with known ransomware campaigns. Here’s how we created our “known-bad” Bitcoin dataset and how we keep it updated in real-time.

Step 1: Collect Seeds. We started by collecting Bitcoin addresses observed with ransomware binaries. These Bitcoin addresses are known as seed addresses. Seed addresses are the Bitcoin addresses used to collect money from the victims. Figure 2 is an example of a pop-up window that appears when a ransomware payload is delivered. You can see the seed Bitcoin address at the lower right corner of the popup window.


Step 2: Reconstruct Clusters. We leveraged the most up-to-date Bitcoin blockchain information to reconstruct the clusters of Bitcoin addresses associated to the same ransomware family. There are different proposed heuristics to reconstruct these clusters. We decided to go with the multi-input heuristic (aka co-spending heuristic). The multi-input heuristic is a an algorithm that recursively searches for addresses that were co-spent with the seed addresses. The assumption is that Bitcoin addresses that have been spent together within a given transaction belong to the same wallet and are operated by the same user. 

In the figure below, we show the balance of the clusters of Bitcoin addresses operated by the criminals behind CryptoLocker.


Step 3: Justify the Fidelity. The balance of the cluster with its peaks and valleys can be used as an indicator of money flowing to, or being cashed out by, criminals. Because we have verified these clusters are associated with the ransomware family, when we see certain cluster balances trending up, security analysts can conclude with high confidence that a new variant of ransomware is ramping up in the wild. The amount of money paid to the bad actors can also give the analyst a sense of the severity of the attack. Usually victims pay criminals when they are desperate to recover their data, therefore the higher the severity, the more money will be paid. Once security analysts determine which ransomware family is trending up they can be on the lookout and focus on collecting other indicator types associated to that ransomware.


CryptoLocker Use Case and Analysis

Given the prescribed workflow outlined above, it becomes clear that as intelligence and security practitioners we must propose an updated pyramid of pain that takes into consideration Bitcoin addresses as a valid indicator of compromise (IOC). We will consider the CryptoLocker ransomware to showcase how we leveraged Bitcoin addresses in order to get a deeper understanding of this campaign.

Bitcoin addresses are different than other IOCs because they both have the attributes of a hash as well as Techniques, Tactics, and Procedures (TTPs). Just like hashes, Bitcoin addresses are extremely accurate indicators that allow analysts to link different malicious events to each other. They are also pretty simple to generate by using any open source wallet service. Savvy hackers can easily manage a large number of private and public keys associated with them.

On the other hand, Bitcoin addresses can create a number of challenges for criminals.

Performing link analysis using Bitcoin addresses is accurate and valuable, especially since the shelf life of a seed Bitcoin address for severe attacks such as the CryptoLocker seems to be of the order of days even months. In fact, some CryptoLocker seed addresses were still receiving payments weeks after the start of the campaign on Sept 5, 2013. (See Figure 4).


In the above Figure 4 the “first_block_time” column represents the time of the first received payment for that particular address, and the “last_block_time” represents the time of the last received payment. The table shows that a Bitcoin address could still be a valuable indicator for link analysis for weeks in some cases.

The most irritating characteristic of Bitcoin for criminals is that the ledger of Bitcoin addresses is public and immutable. The public ledger gives researchers and authorities a unique insight into the workings of the payment system and of the TTPs of the criminals. Worse yet, if a payment infrastructure is disrupted it could cause severe pain for the attackers because they would need to figure out a different payment system to cash out their gains.

Let’s take a closer look at the CryptoLocker data. We’ll assert that by looking at the transaction data we can get a good idea about the evolution of that ransomware.


CryptoLocker, CryptoDefense, and CryptoWall are different versions of the same piece of ransomware (Figure 5). In the above figure, we observe that CryptoLocker had many different releases and updates. The first “software” was released in September 2013, as well as a clone of it in November 2013.

Let’s see how we can leverage the blockchain data to track the evolution and success / failure of each release.

By looking at the USD balance of the addresses associated with the first version of CryptoLocker (Figure 3), we notice that these Bitcoin addresses were collecting money from September 2013 to February 2014. The end date of CryptoLocker coincides exactly with the first release of CryptoDefense. Take that and combine it with the fact that the amount of money that the first version of CryptoLocker was making was trending down, you can see a pattern emerge.

The CryptoLocker campaign peaked at $218K in monthly revenue to a monthly average of $60K in January and February. The bad actors probably thought that CryptoDefense will allow them to make more money and went ahead with the new release after cashing out the revenues from CryptoLocker.

CryptoLocker_Fig6Unfortunately for our attackers, CryptoDefense was short lived because it had a bug that allowed easy decryption. This can also be backed by data coming from the blockchain (Figure 6). While money was still being collected for a short period between March and April 2014, the amount was tiny compared to what they were making before. The total collected amount was $80K in two months.


Next came CryptoWall, which started in March 2014 after CryptoDefense was shut down. CryptoWall 1.0 was the first sample officially tagged as CryptoWall. This version of CryptoLocker (or CryptoWall) had a properly-implemented RSA public/private key pair which made this strain of ransomware particularly tenacious. From analyzing blockchain data, we can clearly see that the amount of money collected by each of these versions was substantial (Figure 7).

After the attackers fixed the cryptography bug their revenues increased substantially after the release of CryptoWall 1.0. We found six wallets or clusters of Bitcoin addresses associated with CryptoWall 1.0 that started being active after the release. (You can see this in Figure 8 as well as by viewing different clusters on the WhiteRabbit landing page.) The total ransom collected amounted to $734K. One interesting hypothesis to consider is that every cluster of Bitcoin addresses is potentially linked to minor releases and updates to the software.

CryptoWall 2.0 appeared on the scene in October 2014 and again we found a cluster of active Bitcoin addresses associated to it (Figure 8). The main change in CryptoWall 2.0 had to do with Command & Control communications.


CryptoWall 2.0 was another flop and it only generated $75K. With the release of CryptoWall 3.0 we saw a new anonymization network embedded within the infrastructure of the ransomware.

By looking at the blockchain data we were able to find five clusters of Bitcoin addresses associated with CryptoWall 3.0 that were active around the same time of the release. The attackers were able to substantially increase their revenues with CryptoWall 3.0, bringing in a hefty $2,518K (Figure 8). Finally came CryptoWall “4” which seems to be another flop given that estimated revenues decreased to $38K (Figure 8).



In addition to allowing us to perform accurate link analysis, as corroborated by the CryptoLocker study, we’ve shown that Bitcoin addresses can give us unique intelligence about new updates and software releases from attackers (TTPs).

Based on this analysis, we propose adding Bitcoin addresses to the Pyramid of Pain (Figure 9). As we have demonstrated in our CryptoLocker analysis, Bitcoin addresses are different because they have the attributes both of a hash and/or of a TTP. On average, we could argue that for severe attacks and campaigns Bitcoin address indicators can be smacked just in the middle and right below Network and Host Artifacts. Of course, different cryptocurrencies can be added along with Bitcoin addresses, but only if they share characteristics similar to Bitcoin.  

Presidential Executive Order: “Collect and Preserve” Incident Data. Is this the Catalyst for Cybersecurity’s Black Box? President Biden’s Executive Order (EO) on Improving the Nation’s Cybersecurity defines a solid path forward for the Federal government and its ... Read More
Only the Paranoid Survive, Recast for Cybersecurity Andrew Grove's seminal business management book Only the Paranoid Survive offers a fitting title for the current state of cybersecurity and a roadmap ... Read More
The Data Dilemma in Cybersecurity Last week, the Wall Street Journal reported that the “scarcity of data needed to train models is slowing progress” toward the promise of fortifying ... Read More
The Good, Bad, and Ugly of Threat Intelligence with Patrick Coughlin Recently Co-Founder and CEO of TruSTAR, Patrick Coughlin, sat down with Ron Eddings and Chris Chocran from Hacker Valley Podcast to discuss how ... Read More