The state of Ransomware in 2015


Ransomware has been a threat for quite some years, although the ransomware as its currently known, encrypting files, has only been around a few years. This change started with the initial 2013 CryptoLocker infections authored by the creator of the notorious Zeus banking malware, Slavik. Since CryptoLocker, many new variants as well as completely new families of ransomware have been appearing. Some stayed alive and ran successful operations for a long period of time which spanned years in some cases, while others disappeared as quickly as they appeared.

Takedowns in the world of ransomware are few and far between. Occasionally large operations with law enforcement result in successful takedowns as seen with the original CryptoLocker takedown; Operation Tovar in which Fox-IT InTELL played a key role and released a whitepaper about: GameOver Zeus: Backgrounds on the Badguys and Backends. Together with the joint effort takedown with law enforcement, Fox-IT InTELL was also able to support CryptoLocker victims in decrypting and recovering their files.

Sadly there is still a lot of ransomware going around. In this article we describe what we consider the top 3 of ransomware families currently active. We take a look at how and what they target for encryption as well as how we at Fox-IT combat them, looking at it in terms of detection and prevention.

Top 3 Ransomware families

We consider the following three ransomware families to be at the top of the ransomware threats alive right now:

  • CryptoWall
  • CTB-Locker
  • TorrentLocker

All three of these have been around for quite some time making a lot of victims along the way. Using a combination of exploit kits and faked emails, posing to be postal or financial agencies for example, they have been making victims all through-out the world.

In the case of TorrentLocker we were, in cooperation with the Dutch NCSC, able to fend them off which ended in them abandoning their campaigns against the Netherlands. We first documented a new variant being active on October 15, 2014 in a blog article. This however did not end their campaigns in other countries which are still ongoing as of writing this article.

In the following subsections we will give a brief analysis of the individual ransomware variants listed in the top 3. The analysis structure will be the same formal setup for all three families to keep it nicely standardized, straight forward and allow for easy comparison between the three. In this analysis we will be referring to the criminal’s command and control server from which they control the ransomware as the ‘C&C’ in short.


Ransomware analysis: CryptoWall


This Ransomware has been around since at least November 2013, although the operators were active developing and using this ransomware before it was officially dubbed ‘CryptoWall’.

CryptoWall has gone through a lot of changes on all aspects including, persistence, cryptography and C&C communication. Initially when it was still called ‘CryptoDefense’, CryptoWall would generate its encryption keys on the local machine which was proven to be flawed in a new article; which was read by the authors who fixed this ‘issue’. The encryption for the current version of CryptoWall, version 3.0, uses AES for file encryption while versions below that used RSA-2048 directly for the files. Version 3.0 receives a 2048 bit RSA key from the C&C, but doesn’t use it directly to encrypt files; an AES key is generated to encrypt a file with, this AES key is then encrypted with the obtainedRSA-2048.

Originally CryptoWall’s first versions communicated via proxy servers setup by the criminals which would forward traffic towards the C&C server residing in Tor. In a newer version of CryptoWall communication was directly over the Tor network, this was originally seen as test version by the authors but it was later also used as their main way of C&C communication. A few days after the Tor only version it changed back to non-direct Tor followed by a version using the I2P network, a lot of testing was going on. After all these tests the authors settled on a communication setup consisting of two layers of proxies, basically the first original setup for the initial CryptoWall, but with one extra layer of proxies. These proxies are setup on hacked websites. While these servers are cleaned up or taken offline quickly, it is workable for the CryptoWall authors as the ransomware needs to get one single connection out in order to be able to obtain a key and encrypt files, it doesn’t need a constant C&C connection as seen with other types of malware.

The spread of CryptoWall has only been increasing since its start with constant active campaigns mostly through the use of exploit kit services. The authors have an affiliate program running which makes it even more interesting and profitable for other criminals to spread CryptoWall to get a cut of the profit. This affiliate program has greatly improved their business income.

Network behavior

As said earlier, CryptoWall communicates via proxy servers to its real, hidden within the Tor network, command and control server. These proxies are hosted on compromised websites mainly consisting of outdated WordPress and Joomla instances although Drupal instances are also spotted at times. All communication is done via plain HTTP POST requests in which the POST data and response data being encrypted with RC4.

After getting on a victim’s PC, CryptoWall will start looking for a proxy server that is functioning. When it has found one it will start by sending the C&C server a few things to start of:

  • A unique campaign identifier (basically the source of the infection like spam or an exploit kit)
  • Its IP address (because the C&C runs inside Tor it needs to know the real IP address to be able to geolocate an infection)
  • Its unique identifier (identifier generated for an infected machine to be able to identify it from other infections)

The C&C server responds with:

  • The location of the ransom payment page (where victims can buy the decryption software)
  • The country the victim is originating from
  • An RSA-2048 public key used for file encryption

After receiving this information the client will start encrypting files on the machine. After it is finished encrypting the files, the ransomware reports the amount of encrypted files back to the C&C. The C&C responds with an image shown to the user indicating that CryptoWall encrypted all their files:

CryptoWall ransom note

File-system behavior

Besides encrypting all the files specified in its target file-types list, CryptoWall also performs the following operations on the file-system of the infected system:

  • Drop the lock screen image
  • Drop a TXT file containing the same instructions as seen on the image

CryptoWall will also run a set of commands to disable volume shadow copies (Windows automatic volume backups) and the Windows Error Recovery boot screen. It also disables Windows updates and if enabled various security services like Windows Defender.


Distribution source(s) :
  • Exploit kits
  • Email
C&C communication scheme : Traffic send through a proxy (usually a hacked website) towards a server (controlled by the criminals) that proxies the data further onto the C&C server hidden within the Tor network.
Cryptography scheme for files : AES
Targets network shares : Yes, enumerates all connected drives networked or not.

Targeted file types

Documents Photos Code Images Audio & Video Backup
odt         ppt         indd       oab        ods         pptx pct          nk2         odp       pptm     prf          eml odm       rtf           des       wb2       odc         msg

iif            pdd        odb

pages    nd           thm

doc         tex         qba

der         docx      txt

tlg           cer          docm

wpd       qbb        crt

wps        pdf         qbm

pem       xls           db

qbr         pfx         xlr

dbf         qbw       p12

xlsx        mdb       qby

p7b        xlsm       mdf

ach         p7c         xlsb

pst          key         xlk

sql          ost          wallet

pps         accdb    pab

3dm       kd

dxf         3ds

erf          dxg

max       mef

psd         obj

mrw       dds

ai             nef


eps         nrw

tga          ps

orf          yuv

svg         raf

dng        cdr

rwl          arw

rw2        srf

raw        sr2

r3d         bay

ptx         crw

pef         3fr

srw         cr2

x3f          dcr


pdb        c

cpp         hhpp

class       cs

dtd         fla

java        lua

m            pl

py           pas

jpe         jpg


3g2         3gp

asf          asx

avi          flv

m4v       mov

mp4       mpg

rm          srt

swf         vob

vmw      mp3

wav        flac




Ransomware analysis: CTB-Locker


CTB-Locker was first seen being sold in the underground communities back in the middle of June 2014. Researcher Kafeine wrote an article on this original sale by the author. The name CTB stands for Curve-Tor-Bitcoin, referring to items it utilizes: Curve refers to the elliptic curve encryption scheme used for file encryption, Tor refers to its usage of the Tor network to hide its C&C server and Bitcoin refers to the single ransom payment method available: Bitcoins.

CTB was originally only supporting Russian and English translations for its ransom demand message, but has been supporting more languages as it was being developed. It currently supports Russian, English, Italian, Dutch, German, Spanish, French and Latvian for its ransom message. In the Netherlands we’ve seen several waves of CTB-locker, mostly impersonating a financial institution normally involved with sending out payment forms which CTB fakes as attachments.

CTB’s command and control servers reside in the Tor network, but are not needed for the initial infection. A user’s files can be encrypted while the machine has no internet connectivity. This is possible due to the way the encryption and payment system of CTB works. The file encryption is a combination of SHA256 from Curve25519 operations, the exact details of this are explained in great detail by a researcher named Massimiliano Felici, who published an article on his blog named ‘CTB-Locker encryption/decryption scheme in details’.

Just like CryptoWall, CTB-locker has an affiliate program where other criminals can spread CTB-locker in order to get a cut of the profits. This affiliate program has been publicly exposed and researched by researcher Kafeine on his blog. This affiliate program has a website running inside the Tor network just like the C&C server. On this affiliate website the author of CTB-locker also keeps an updated log on the updates/extending in the functionality of CTB-locker.

Network behavior

As said earlier CTB-locker does not require an internet connection to be present on the infected client. Would it have internet connectivity, it does send the encryption information to the C&C within Tor. It does this by having the ability to talk to its server inside the Tor network via variants of the Tor2Web service, which act like a proxy into the Tor network.

Besides sending this information to the C&C it will also do an online lookup for its external IP address.

File-system behavior

Besides encrypting all the files specified in its target file-types list, CTB-locker also performs the following operations on the file-system of the infected system:

  • Drop the lock screen image and set it as a background; an example of this:
  • CTB Lock screen
  • Have an application pop-up with similar instructions as seen on the background image. This application is stored on the local machine. It contains a payment ID, a list of encrypted files, a countdown counter and instruction on how to pay the ransom amount to recover encrypted files. This example is the English translation, clicking any of the flags at the top of the application changes the language:
  • CTB Lock screen


Besides these graphical messages a copy of the text is also put on the file-system in the form of a text file as well as a copy of the background image.

CTB-locker will also run a set of commands to disable volume shadow copies (Windows automatic volume backups).


Distribution source(s) :
  • Exploit kits
  • Email
C&C communication scheme : Doesn’t need an internet connection to start file encryption. Due to its implementation it is able to encrypt files offline.
Cryptography scheme for files : AES
Targets network shares : Yes, enumerates all connected drives networked or not.

Targeted file types

Documents Photos Code Images Audio & Video Other
doc         docx

rtf           docm

xls           xlsx

txt          xlk

xlsb        xlsm

mdb       dwg

accdb    odb

odm       odp

ods         odt

odf         wb2

vsd         wpd



kdc         nef


cpp         c

php        js

cs            pas

bas         pl


3fr          dds

jpe         jpeg

jpg          cr2

rw2        psd ai             dd

rwl          dxf

dxg         arw

cdr          crw

eps         dcr

dng        indd

mrw       nrw

srw         ims




arp cer          crt

der         pem

7z            zip

rar          pwm

kwm      safe

groups  mdf

dbf         sql

md         bay

blend    erf

mef        p12

p12f       dbx

gdb        bsdr

bsdu      bdcr

bdcu      bpdr

bpdu     bsd

bdd        bdp

gsf          gsd

iss           rik

fdb         abu



Ransomware analysis: TorrentLocker


TorrentLocker was first documented in February 2014 when Turkish victims received emails from ‘Turkcell’, which is the leading mobile phone operator in Turkey. Users were lured onto a fake turkcell website where they had to download a document. This was the first documented attack from TorrentLocker who at the time didn’t have a name yet. It was named TorrentLocker to distinguish it from other ransomware threats based on the first registry key it used which contained ‘Torrent’:

HKCU\Software\Bit Torrent Application\

From that time on TorrentLocker has been evolving in how it shows the user the ransom demand messages and implementation of cryptography. Their method of spreading however hasn’t changed a bit, they impersonate local telecom providers or postal service websites sending users emails indicating a document is ready for them to download.

There have also been a few instances where malicious Word documents containing macros were used to infect systems with TorrentLocker.

The way the TorrentLocker group obtains the email addresses to send spam messages to is also interesting. They (most likely) started with an initial list of victims to started spamming and this list was extended by infecting victims. When TorrentLocker infects a machine it will harvest any possible email address from address books for Thunderbird, Outlook and Windows Live Mail present on the system. We’ve documented this process and their success in the past on our blog: Update on the TorrentLocker ransomware’. In our investigation of the run we saw back then they were able to obtain 2.6 million email addresses with this harvesting technique, a lot more possible victims to start sending their spam to.

TorrentLocker tries to impersonate CryptoLocker and uses this name on both the ransom messages shown to the user as well as the ransom payment website. This ransom payment website is hosted within the Tor network while the C&C used for communication with the malware from an infected machine is a server outside of the Tor network.

Network behavior

TorrentLocker communicates with a C&C server directly. With this server TorrentLocker speaks a small protocol in which it can send the encryption key, encrypted file count, stolen email information as well as possible (crash) logs. It will also obtain a ransom page from the C&C server.

The whole communication protocol is encapsulated in HTTPS.

File-system behavior

Besides encrypting all the files specified in its target file-types list, TorrentLocker also performs the following operations on the file-system of the infected system:

  • Make a copy of itself to a location in which it can make sure it will be present the next time the system starts.
  • Show a ransom instruction screen to the victim with information on how to pay the required ransom (in Bitcoins), where to get Bitcoins and where to send them. This screen does not give information on a possible deadline for the payment or the amount of affected files:
  • TorrentLocker lock screen


Distribution source(s) : Email
C&C communication scheme : Contacts a dedicated C&C server directly.
Cryptography scheme for files : AES-256
Targets network shares : Yes, enumerates all connected drives networked or not.

Targeted file types

Documents Photos Code Images Audio & Video Other
3ds         ab4

bgt         ac2

blend    cdf

cfp          csv

dbf         ddd

djvu       doc

docm     docx

dot         dotm

dotx       odb

odf         odg

odm       odp

ods         odt

otg         oth

otp         ots

ott          pdf

pot         potm

potx       ppam

pps         ppsx

ppsm     ppt

pptm     pptx

rtf           sldm

sldx        std

stw         scx

sxg         sxi

sxw        txt

wb2       xla

xlam      xll

xlm         xls

xlsb        xlsm

xlsx        xlt

xltm       xltx





cib          cmt

craw      crw

dc2         dcr

dng        mos

mrw       nef

orf          pcd

ra2          raf

raw        rw2

rwl          sd0

sd1         sr2

srf           srw

st4          st5

st6          st7

st8          x3f


asm        asp

c              cpp

css          h

erbsql   js

hpp        lua

php        pl


3fr          3pr

acr          agd1

ai             ait

arw        cdr

cdr3       cdr4

cdr5       cdr6

cdrw      ce1

ce2         cgm

cr2          csh

dcs         ddoc

ddrw               design

fpx         fxg

jpeg       jpg

psd         sda



al             bik

cpi          mpg


7z            accdb

accde    accdr

accdt     adb

apj          awg

backup               backupdb

bak         bdb

bgt         bkp

bpw       cdx

cer          cls

crt           csl

dac         db


db3        der

dgc         drf

drw        dwg

dxb        erf

exf         fdb

ffd          fff

fh            fhd

gray       grey

gry          hbk

ibank     ibd

ibz          idx

iiq           incpass

kc2         kdbx

kdc         kpdx

mdb       mdc

mef        mfw

mmw    myd


ndd        nop

nrw        ns2

ns3         ns4

nsd         nsf

nsg         nsh

nwb       nx1

nx2         nyf

p12         p7b

pat         p7c

pem       pfx

ps           psafe3

ptx         rdb

rwz         s3db


sav         sdf

sql          sqlite

sqlite3   sqlitedb

stc          sti

stx          sxm

xml         zip



The generic traits of Ransomware

While the different ransomware variants are unique in most behavior, file types they are after and in some cases cryptographic implementations are similar. When having to defend a client network on different levels, network and host based, there are quite some generic traits seen with all of these.

File-system behavior

Most ransomware will place payment instruction files in the directory of the files that it’s going to encrypt. These files are usually in the form of a text, image and/or URL. Usually it will also change the background wallpaper of the infected computer to these instructions including a popup window so the user knows his files are being held ransom and he can get them back by paying for it.

Network behavior

Most ransomware families will contact a C&C server in some form, either via Tor or via compromised WordPress websites. While the current state of ransomware does not yet look actively for shares, it does encrypt files on drives that are network mapped on the computer as a side effect. This highly impacts businesses that do not have proper backup protocols.

Because decryption instructions files are dropped, it can also be detected on a network level when this happens on a network share. Our Network Monitoring service has detection for this.

When you see encrypted files on a network share you can easily check which user was infected with the ransomware and started to encrypt the files. Just check the creator of the instruction files on the share. This can help the system administrator to disconnect the infected user as quickly as possible from the network to prevent any further damage.



Having looked at the ransomware variants described there’s a few things we can conclude in terms of security:

  1. Unlike normal malware, ransomware does not need an extended presence on the system in order to ‘do-its-thing’. Once the key has been sent to the criminals it is over as it is in most cases unrecoverable.
  2. On the networking side there are quite a lot of indicators to work with in order to detect the presence or the initial infection of these ransomware variants in most cases.
  3. As seen with CTB-Locker, ransomware doesn’t always need internet connectivity. This is where endpoint protection should be able to determine the ransomware.


Based on our findings in the ’ generic traits’ section, we can also say that in many cases we’re quite lucky in terms of detection. Many authors of ransomware have the same goal and perform the same actions.

Ransomware is (sadly) not a thing that will pass on some point, as seen with fake antiviruses for example. The past years ransomware threats have only grown in size and numbers. Where in the past lockers wouldn’t affect files but solely the users’ current session, ransomware has been a very effective threat as users are forced to take action in order to get their personal files back..

The usage of the Tor network only makes it harder to stop these threats and only continued operations where law enforcement and the private industry work together are an effective way of frustrating and/or wearing down these criminals.


–  Fox-IT Security Research Team

How a research project at Fox-IT enhances your security career

Internships are a great way to assess a student’s capabilities, Fox-IT is always looking for talented individuals, that have proven that they have what it takes to be ‘a foxer’.

At Fox-IT we hold our colleagues to the highest (technical) knowledge standard. If everyone is held to this high standard, we can insure the quality of our products and services, as well having capable colleagues in a challenging but foremost exciting environment.

Internships are an excellent method of engaging in research that can be futuristic or visionary. Not all research however leads to positive expected results, but that’s why it’s called research after all. Typically, a student will research, and then PoC (Proof of Concept) one of the many processes or technologies that we need. We introduce the student to the world of IT security, in a very focused manner.This usually involves a very narrow area of research that concentrates on only one problem. Supervision by ‘a foxer’ that knows the intricacies of the problems that we are trying to solve, allows us to get the best out of the student. “The more focused the research the better” is the motto here. Students usually spend 5 months on their project, which is quite short for research, testing and quality work, especially if you include all the documentation that is needed for the educational institutes as well.

How does one enrol for security research at Fox-IT?

I’ll start with an example of how our enrolment process works. A student will look at the list of available projects that we have on our website: They register by sending an email to, with their CV, which projects interest them, and why. This email is then forwarded to the responsible division student coordinators for processing. Let me just say that there are always custom projects for capable motivated students. This online list can never be considered complete or extensive. If you have a brilliant idea of your own, do not hesitate to submit that as a proposal.

I will get the students details that relate to MSS (Managed Security Monitoring), send them an email or ring them for a time for an interview at Fox-IT HQ. As part of the process, I will interview the candidate. This will allow me to get to know them, their capabilities and guide them towards projects that best suit their skills (that they already have). At this stage, we will figure out the best course of action. In the end, we have a research proposal that describes what will be done during the internship.

Different types of Internships
There are three types of interns inside Fox-IT. The first is what I would call a standard internship, which involves working inside our dedicated intern room, focusing on the research and producing results. The second type is external or very short internships. These internships are done externally without the student coming to Fox-IT every day. I’m personally not a big fan of these internships, and they are rare. The third type of internship is MSS specific, as the intern is also tested for acceptance into the SOC excellence program, otherwise they can always be a standard intern. See Their research projects are enriched by the front line experience that they gain working in our SOC (Security Operations Center) on a part-time basis.

Over the years we have gotten interns from many different countries and educational institutes. Most are from inside the EU (such as myself), but also from other places such as Mexico, India or Jamaica. For these students or others to far away from Delft, we offer a temporary place to rent, we very originally call the ‘Fox House’.

The difference between Fox-IT and others
I frankly can only speak for how it is at MSS, and how we do things, but everyday is guaranteed to be different. New exploits needing to be analysed, new interesting incidents to investigate or new detection methods to develop are the norm. As a principle of Fox-IT, technical creativity is encouraged. Giving us the room for cutting edge innovation, such as Quantum Insert detection ( that allows us to make a difference for not only our customers but also the wider community. So if you want to participate in our continuous innovation, consider a Fox-IT internship.

As a side note, a substantial minority of the staff are international and many of our processes are in English. So I wouldn’t call Fox-IT your typical Dutch company. In short, Fox-IT offers students a friendly, technically competent and international environment to do their research, and progress their career.

Barry Weymes
Senior Security Expert at MSS

Finding the hidden attacker in your network

Imagine the following scenario: you are the CIO of an organization and receive a phone call from an external party, informing you that suspicious traffic has been observed between your company network and a remote server. The incident response turns up that an attacker has been present in your network for over 6 months, and has had a free reign in moving through all the end-points and data that it deemed interesting. Apparently, your up-to-date security measures did not detect the presence of this attacker.

This is a real-life scenario that we have encountered in many forms over the past years when helping clients in their incident response. Often, 0-day exploits and advanced malware are involved, that do not trigger existing security measures like anti-virus or an Intrusion Detection System. So how do you actually detect such (often advanced) attacks?

Due diligence for your IT infrastructure

One of the hardest things is that the attacks we are discussing here, are not detected by most traditional detection measures. Secondly, once an attacker has gained sufficient access, he will often be able to use existing user accounts to move further through your network. This type of legitimately looking behavior is even harder to detect or prevent against (your actual users still need to be able to work, right?).

A proven approach here is to investigate your IT infrastructure for traces of a breach, without having any indications of such a breach. Although this is much harder to do than when you have an actual indicator of an ongoing attack, you could perform a due diligence type of analysis where you look for traces of advanced attacks. What is essential in such an approach is to have the knowledge and experience present that go beyond your existing prevention and detection measures. Specifically, you are looking for a team of experienced incident responders and forensic analysts that know what types of traces and behavior they have to look for. In addition, the team should have access to the latest intelligence on past and current threats and modus operandi.

Fox-IT Compromise Assessment

Fox-IT’s Compromise Assessment service is used to thoroughly analyze an organization’s IT infrastructure for traces that might indicate a past or ongoing compromise of systems and/or data. Typically, the assessment involves the forensic analysis of a wide variety of data sources, being network traffic, system / application logs and end point behavior. The threats that are relevant to your organization will determine the scope and focus of the assessment.

The assessment itself consists of three parallel tracks:

  • Network forensics
  • Log file forensics
  • End-point forensics

Each track may require the deployment of some technology in the infrastructure under investigation, such as devices for network traffic recording and analysis (probes) and digital forensic analysis software. Each track consists of a combination of automated analysis and human expertise. By applying Fox-IT’s world-class threat intelligence, combined with the years of experience of our incident response and forensics team, we are able to add a unique layer of expertise on top of our automated analyses.

The focus is mostly on catching lateral movement of an attacker through the network, while also catching low-hanging fruit like malware infections or other less targeted attacks.

A typical compromise assessment will take between 5 and 7 weeks. The first few weeks are spent by deploying network probes and other data collectors that will record relevant data for a couple of weeks. This data, along with other relevant information (forensic disk images, log files, etc.), will then be analyzed by a team of Fox-IT experts. This usually takes around 2 to 3 weeks of full-time work, optionally executed on-site at the client. The Fox-IT experts will work closely with the client’s IT staff, to follow up on leads and indications of malicious activity that come up during the assessment.

Results and benefits

The main result of a compromise assessment is obviously an answer to the question whether traces were found of a past or ongoing breach. However, the benefits of performing a compromise assessment extend beyond just this one question. By gathering so much forensic information, analyzing it and discussing results with your IT staff, Fox-IT experts will get an insight into various aspects of your IT security. The final report will therefore also contain recommendations in the fields of general security, preventive, detective and responsive/readiness measures. The recommendations are structured according to the SANS Critical Security Controls.

A compromise assessment can also quite easily be extended by adding forensic readiness and/or security maturity assessments. That way, an organization can use the compromise assessment as a starting point in designing a new IT security strategy or in validating and strengthening an existing one.

Contact and more information

If you are interested in a compromise assessment and would like to further discuss the possibilities for your organization, please contact Kevin Jonkers via e-mail or by phone +31 (0) 15 284 79 99.

Do you have a clue?

Vind de verborgen aanvaller in uw netwerk

Stelt u zich eens voor: u krijgt als CIO een telefoontje van een externe partij dat er verdacht verkeer is gesignaleerd tussen uw bedrijfsnetwerk en een externe server. Naar aanleiding van de incident response blijkt tot uw grote schrik dat er al meer dan zes maanden een aanvaller aanwezig is in uw netwerk. Deze heeft al die tijd, ondanks de naar uw idee up to date beveiligingsmaatregelen, kunnen rondneuzen in uw end-points en data.

Een realistisch scenario, die wij de afgelopen jaren in allerlei verschijningsvormen zijn tegengekomen bij klanten die onze hulp nodig hadden bij hun incident response. Vaak zijn hier zero-day exploits en geavanceerde malware bij betrokken. Deze worden niet gedetecteerd door bestaande beveiligingsvoorzieningen, zoals antivirussoftware of Intrusion Detection Systems.

Hoe kunt u dergelijke (vaak geavanceerde) aanvallen dan wel opsporen? Dit kan via een analyse vergelijkbaar met een due diligence-onderzoek.

Due diligence voor uw IT-infrastructuur

Een van de lastigste aspecten van bovengenoemde aanvallen, is dat ze door de meeste traditionele detectievoorzieningen niet worden gevonden. Ook kan een aanvaller, als hij eenmaal toegang heeft tot uw netwerk, bestaande accounts gebruiken om verder binnen te dringen. Dit soort ogenschijnlijk geoorloofd gedrag is nóg lastiger te detecteren of te voorkomen (want de daadwerkelijke gebruikers moeten ook nog kunnen werken).

Een methode die zich inmiddels in de praktijk bewezen heeft, is het scannen van de IT-infrastructuur op sporen van een inbreuk zónder dat er aanwijzingen zijn dat er een heeft plaatsgevonden. Hoewel dit veel lastiger is dan wanneer er wel aanwijzingen zijn voor een lopende aanval, kunt u een analyse uitvoeren die vergelijkbaar is met een traditioneel due diligence-onderzoek. Hierbij wordt gezocht naar sporen van geavanceerde aanvallen.

Voor een dergelijke benadering moet u wel de beschikking hebben over specifieke kennis en ervaring van incidentafhandelingen en forensische analyses. U heeft experts nodig, die weten op wat voor sporen en gedragingen ze moeten letten en toegang hebben tot de nieuwste informatie over oude en actuele bedreigingen en werkwijzen. En daar komt Compromise Assessment door Fox-IT om de hoek kijken.

Compromise Assessment door Fox-IT

De Compromise Assessment dienstverlening van Fox-IT wordt gebruikt om de IT-infrastructuur van een organisatie grondig te scannen op sporen die kunnen duiden op oude of lopende aanvallen op systemen en/of gegevens. Het assessment bestaat doorgaans uit een forensische analyse van een breed scala aan gegevensbronnen, zoals netwerkverkeer, systeem- en/of applicatielogbestanden en end-points. De scope en de aandachtsgebieden voor het assessment zijn afhankelijk van de relevante dreigingen voor uw organisatie.

Forensische onderzoektrajecten

De evaluatie zelf bestaat uit drie parallelle forensische onderzoektrajecten:

  • onderzoek op opgenomen netwerkverkeer
  • onderzoek in logbestanden
  • onderzoek op end points

Het kan zijn dat er voor elk onderzoektraject een bepaalde technologie moet worden geïmplementeerd in de infrastructuur die wordt onderzocht, zoals hulpmiddelen voor het registreren en analyseren van netwerkverkeer en digitale forensische analysesoftware. Fox-IT past haar geavanceerde threat intelligence toe, in combinatie met jarenlange forensische en incident response ervaring. Op die manier worden geautomatiseerde analyses aangevuld met menselijke expertise.

De nadruk ligt vooral op het signaleren van ’lateral movement’ van een aanvaller op het netwerk, maar ook op het spotten van meer voor de hand liggende zaken zoals malware-infecties en andere, minder gerichte aanvallen.

Benodigde tijd Compromise Assessment

Gemiddeld duurt een Compromise Assessment vijf tot zeven weken:

  • Hulpmiddelen voor het scannen van het netwerk en andere gegevens slaan gedurende een paar weken relevante data op.
  • Fox-IT-experts analyseren vervolgens deze data en andere relevante gegevens (forensische schijfimages, logbestanden etc.). Deze analyse neemt meestal twee tot drie volledige werkweken in beslag en kan eventueel op locatie bij de klant worden uitgevoerd.
  • Oplevering technische rapportage en executive report

De experts van Fox-IT werken nauw samen met het IT-personeel van de klant, om zo direct te kunnen reageren op tekenen van verdachte activiteit.

Resultaten en voordelen

Het belangrijkste resultaat van een Compromise Assessment is natuurlijk het antwoord op de vraag of er sporen zijn gevonden van een oude of lopende aanval. Er zijn echter meer voordelen: door de verzameling van zoveel forensische informatie, plus de daarbij behorende analyse en overleg met uw IT-personeel, krijgt Fox-IT een breed inzicht in de diverse aspecten van uw IT-beveiliging. Het eindverslag zal daarom ook aanbevelingen op het gebied van algemene beveiliging en maatregelen voor het voorkomen, opsporen en afhandelen van incidenten bevatten. De aanbevelingen zijn opgebouwd conform de SANS Critical Security Controls

Forensic readiness en security maturity

Een Compromise Assessment kan ook vrij eenvoudig worden uitgebreid met een evaluatie van de ‘forensic readiness’ (forensische gereedheid) en/of een security maturity assessment. Op die manier kunt u de Compromise Assessment gebruiken als startpunt voor de ontwikkeling van een nieuwe IT-securitystrategie of voor het voortzetten en verbeteren van een bestaande strategie.

Meer informatie

Wilt u meer weten over een Compromise Assessment en de mogelijkheden voor uw organisatie?

Neem dan contact op met Kevin Jonkers, per e-mail via of telefonisch via 015 284 79 99.

How to become cyber resilient quickly and remain in full control

Running Cyber Security Operations is crucial but difficult

Successful and effective cyber security is not only about tools, but (increasingly) about the processes and people to operate those tools effectively. While organizations used to buy security tools and believed this would be sufficient, they increasingly realize that running the actual Cyber Security Operations (CSO) with the right people is necessary to benefit from those tools.

Designing, implementing and operating CSO is by no means easy. Especially the expertise (e.g. specialized security knowledge to make sense of many alerts) and processes (e.g. quick follow-up on high risk events) are often difficult to implement.

Many organizations want to build, improve or (partly) outsource their CSO because they realize it is a crucial part in becoming more secure. However, they struggle to find the right balance between in-house and outsourced operations, especially when it comes to controlling the full operational process. Also, many organizations do not know how to become sufficiently cyber resilient quickly during this transition process.

In addition, operating cost effective CSO is difficult for tasks requiring scale, such as:

  • 24/7 human monitoring
  • high expertise intelligence gathering
  • emergency response

Many organizations choose not to build those capabilities in-house, but to outsource them to a security partner.

Fox-IT has developed its hybrid approach to address the above mentioned challenges.


A hybrid approach makes Cyber Security Operations easy and secure from the start

With a hybrid approach to CSO, organizations can choose a mix of outsourcing tasks and performing tasks in-house. For example, an organization can choose to outsource all detection tasks, while keeping other functions (e.g. vulnerability management, incident response) in-house. This ensures that difficult tasks, that require significant build-up periods, are operational from the start, while tasks requiring local knowledge or physical proximity can still be performed in-house.

Another advantage of this approach is that an organization can gradually grow into the in-house operation of specific parts of security. For example, after having outsourced all detection tasks, all 1st line tasks can initially be performed in-house, followed by the 2nd and 3rd line if the initial step is successful. The security partner can support this transition by performing these tasks and provide specific training modules. This way, the organization optimally benefits from the security partner’s expertise.

Organizations that want a hybrid approach to CSO should realize that, even though parts of the operation are outsourced, this approach will require significant investment and resources. However, we believe those investments and resources are significantly smaller than when either outsourcing all security tasks (because several tasks could be performed more efficiently by employees with specific knowledge of the organizations’ situation and physical proximity) or performing them in-house (because of a lack of scale in certain tasks).


A hybrid approach to Cyber Security Operations typically takes four steps

The implementation of a hybrid approach to CSO is not easy. Care should be taken in planning and implementing this approach. In our experience, four distinct steps can be identified in a hybrid CSO implementation:

  1. An assessment of the current state of cyber security operations is performed. This includes identifying the existing technology, processes and people in place that perform security tasks. Also a target situation of security operations is defined, to guide the whole transition.
  1. The functional design of the hybrid CSO is developed. All cyber security operations tasks (e.g. vulnerability management, intelligence management, incident detection, etc.) are detailed on a technology, process and people level. That design is mapped on a project plan or roadmap for implementation with different phases.
  1. The technical design and implementation phase starts with the easy activities or quick wins to become more cyber resilient early in the project. Then, more complex phases can be implemented. Also, the capability building program (e.g. training) should start early to hand over tasks to the in-house team as soon as possible. During this phase strong project management with regular measurement of progress is crucial.
  1. The operations phase starts gradually for each implemented task. In this phase, continuous improvement is crucial to remain cyber resilient. Feedback from incidents, false positives and false negatives should be fed back to improve each part of the operation. Also, intelligence on new threats, vulnerabilities and protected interests should be used to improve operations.


Fox-IT can support your organization in developing a plan towards a Hybrid CSO or to guide you through the whole transition. If you have any questions regarding the hybrid approach to CSO, please contact us at

Large malvertising campaign targeting the Netherlands

At the Fox-IT SOC we see malvertising incidents on a daily basis, as blogged on before. Sadly malvertising has become a usual occurence, but the events we’ve been observing since Thursday the 11th of June stood out. An active malvertising campaign propagating via 2 major advertisement networks is targeting visitors only coming from the Netherlands, using the Angler Exploit Kit.

Currently the popular Dutch news website Telegraaf[.]nl is, indirectly, causing the most victims.


Since Friday we’ve seen the following two advertisement providers serving traffic from a specific third party:

  • AppNexus
  • Rubicon

The specific advertisements from these two networks were loaded for (at least) the following websites:


The third party responsible for the malicious redirects to the Angler Exploit Kit is known as otsmarketing[.]com and is located at 107[.]181[.]187[.]81. When this page is loaded a short-link of Google’s service is used for redirection. Due to the fact that this short-link service operates under HTTPS it will lose the referrer chain from the advertiser towards the exploit kit.

Because the otsmarketing[.]com domain is currently the chain connecting the advertisers with the exploit kit, we advice blocking the IP address at this time. Keep in mind however that these criminals will surely change this tactic as soon as its noticed. We have tried to contact the people behind otsmarketing[.]com but were not successful in doing so. We’re also doubting the legitimacy of this company as we didn’t see it being loaded via advertisements until Thursday last week, the first day we’ve seen this malvertising campaign in action.

Update 16-06-2015: After coordinating with the advertisers the malicious host was blocked and removed from their advertisement platforms.

Indicators of Compromise

The following IP and domain should be blocked in order to avoid the current campaign:

  • otsmarketing[.]com / 107[.]181[.]187[.]81

The Angler Exploit kit typically installs the Bedep Trojan, which installs additional malware. Bedep can typically be found by looking at consecutive POST requests to the following two websites:


We have yet to identify the final payload.

Yonathan Klijnsma & Maarten van Dantzig, Threat Intelligence Analysts at Fox-IT

Deep dive into QUANTUM INSERT

Summary and recommendations

QUANTUMINSERT (QI) is actually a relatively old technique. In order to exploit it, you will need a monitoring capabilities to leak information of observed TCP sessions and a host that can send spoofed packets. Your spoofed packet also needs to arrive faster than the original packet to be able to be successful.

Any nation state could perform QUANTUM attacks as long as the traffic passes through their country or possesses other capabilities to get the required TCP session data.

QUANTUMINSERT could be used for lateral movement within internal networks.

Detection is possible by looking for duplicate TCP packets but with different payload and other anomalies in TCP streams.

The usage of HTTPS in combination with HSTS can reduce the effectiveness of QI. Also using a content delivery network (CDN) that offers low latency can make it very difficult for the QI packet to win the race with the real server.

Deep dive into QUANTUM INSERT

The documents leaked by former National Security Agency (NSA) contractor Edward Snowden mention dozens of hard- and software attacks available to the NSA to gain and maintain access to target networks.

There has been some effort at recreating and open sourcing some of the hardware implants. Progress of this effort can be found at the NSA Playset[1]
website. Though various articles and blogs have been focussed on the attacks detailed in the leaked slides, little has actually been done on the detection side of things. We feel that this is important as with the publication of these documents, attacks like these could become more common.

Our focus for this article will be on performing and detecting one specific attack in the QUANTUMTHEORY[2] toolset called QUANTUMINSERT (QI). While this weakness in TCP has been known about for a long time, the NSA has allegedly deployed this attack successfully against targets..We will explain the attack, how it can be performed, and how you can detect it using Intrusion Detection Systems like Bro, Snort and Suricata. The code we used to test this attack is available on our GitHub page.

What is a QUANTUM INSERT attack

QUANTUMINSERT is described as a ‘HTML Redirection’ attack by injecting malicious content into a specific TCP session. A session is selected for injection based on ‘selectors’[3], such as a persistent tracking cookie that identifies a user for a longer period of time.

The injection is done by observing HTTP requests by means of eavesdropping on network traffic. When an interesting target is observed, another device, the shooter, is tipped to send a spoofed TCP packet. In order to craft and spoof this packet into the existing session, information about this session has to be known by the shooter.

All the information required by the shooter is available in the TCP packet containing the HTTP request:

  • Source & Destination IP address
  • Source & Destination port
  • Sequence & Acknowledge numbers

For the attack to succeed the packet injected by the shooter has to arrive at the target before the ‘real’ response of the webserver. By exploiting this speed difference or race condition, one can impersonate the webserver.

A video was posted online by The Intercept that shows the inner workings of QUANTUMHAND, which uses QUANTUMINSERT against targets visiting Facebook:

We made the following animation showing a more high level overview of this attack:

Who is able to perform these attacks

Anyone who can passively or actively monitor a network and send spoofed packets can perform QUANTUM-like attacks. The NSA is allegedly able to perform this attack on a large scale on the internet and with a high success rate, which of course not everyone can simply do. This is because it requires the capability to listen in on potentially high volumes of internet traffic, which requires substantial resources and a fast infrastructure. This means that internet service providers (ISP) can potentially also perform these attacks.

A nation state could perform QUANTUM-like attacks when traffic passes through their country. An example of this is the recent research on China’s Great Cannon[4] by CitizenLab that confirms this.

What are QUANTUMINSERTS used for

NSA’s QUANTUM attacks are possible against various protocols and for different purposes. For both offensive and defensive capabilities as the following table shows:

Attack Description


A man-on-the-side attack. Brief hijack of connection to redirect target to exploit server.


Capable of hijacking idle IRC bots and hijacking c2 communication from bots.


Enhances QIs effectiveness against proxies and other hard to reach targets


DNS injection/redirection of A records. Targets single hosts or chaching name servers


Exploits the computers of Facebook users


Denies access to a webpage by injecting/spoofing RST packets.


File download/upload disruption and corruption.


All of these programs attempt to race the response packet to the target before the response of the real server arrives.

NSA has QUANTUMINSERT capabilities since 2005. The first QUANTUM tool was QUANTUMSKY, realised in 2004. The most recent development, according to the slides was done in October of 2010.

Man-on-the-Side vs Man-in-the-Middle

The QUANTUM attacks described in the Snowden leaks are all man-on-the-side (MOTS) attacks, while China’s Great Cannon attack uses man-in-the-middle (MITM) capabilities. There is been some misinformation on the matter in write-ups.

The difference between the two can be observed by looking at the network traffic of the attacks[4]The Great Firewall of China (not to be confused with The Great Cannon), injects additional TCP reset (RST) packets, and the original real responses can be observed after these RST packets. This is a sign of a MOTS attack, rather than a MITM attack. The network traffic related to the Great Cannon showed only modified packets and no original responses. In other words: the original packets were replaced. This is a sign of a MITM attack, rather than a MOTS attack. The CitizenLab report describes this in great detail.

Monitor and shooter locations

The attack can be done against remote networks on the internet, but also inside internal networks for lateral movement purposes. The closer the monitor and shooters are to the target, the higher the success rate.

Similar attacks

There has been work on injecting packet into TCP sessions. Some tools that perform a similar attack to QUANTUMINSERT are:

  • The attack performed by Kevin Mitnick back in 1994 used the same principles as QUANTUMINSERT, though he predicted TCP sequence numbers rather than observing them[5].
  • Hunt, a tool released in 1999 was able to spoof and hijack connections.
  • TCP Session Hijacking by Cheese, an article released in 2009, describes the technique accompanied by source code showing how to do it[6].
  • AirPwn[7], a framework for 802.11 (wireless) packet injection.

How we performed a QUANTUMINSERT attack

We used three virtual machines (VM) to simulate the monitor, client and shooter, as described in the leaked slides. In this controlled environment it was relatively easy to outrace the server response and inject a HTTP response into the TCP session of the web browser.

The monitoring VM received a copy of all the client traffic and was configured to search for a specific pattern in the HTTP request. When a matching packet was found, the monitor service would notify the shooter about the current IPs, ports, sequence and ACK numbers of the session. The shooter would then send a spoofed TCP packet containing the right values for the session and a not so malicious HTTP response to prove the insert was successful.

The monitor is a simple Python script that can read Tcpdump or Tshark output for the required sequence numbers, ACK numbers, IP addresses, TCP ports and optionally HTTP cookie values.

The shooter is also written in Python using Scapy for crafting and sending the spoofed packets.

We then tested this code over the internet in a controlled environment. One of the harder parts was finding a service provider that permitted source IP spoofing close to our office.


Example inserted packet containing a HTTP 302 redirect response. The Content-Length of zero will cause the overlap of the original response to be ignored by the browser

The code to simulate the QI can be found on our GitHub repository:

Content of a QUANTUM INSERT payload

QUANTUMINSERT focuses on HTTP traffic and attempts to redirect the target to an exploit server. This means the packet will most likely contain a HTTP redirect or a HTML iframe to perform the redirect to an exploit server.It is also possible to exploit without redirection, using a browser vulnerability or malicious javascript.

While the QI can be done anywhere in a HTTP session, it is likely that the inject happens right after the HTTP GET requests that matches ‘selectors’ such as URL, source IP or Cookie header to identify and target specific users.

According to the slides, a QI is used for redirection to an exploit server but it can contain virtually any payload you want. For example, China’s Great Cannon inserted 3 TCP packets containing a malicious javascript to perform a denial of service (DDoS) attack on GitHub[8].

Detection of QUANTUM INSERT attacks

Among the leaked NSA documents was a slide from the Communications Security Establishment Canada describing how to detect QUANTUMINSERT attacks:

To clarify the above, the first content carrying packet is the first packet containing data received by the client from the server. If there are two packets received with the same sequence numbers but have a different payload, it is a possible QI attack.

Theoretically an insert can be done anywhere in the TCP session, for example in long lived HTTP/1.1 sessions. A redirect could also be performed that would have less than 10% difference with the real payload. For example by doing the QI on a similar domain name on a HTTP 302 redirect.

It is even possible to start ‘shooting’ before the client sends the HTTP request, resulting in a faster response than the real HTTP response. However, by doing so you will lose the ability to identify and target specific users. According to the leaked slides, NSA targeted clients with QUANTUMINSERT using selectors such as HTTP cookies.

So in practice we have to look for duplicate HTTP response packets with significant differences in their content.

In order to detect this using an IDS one would need to observe the network traffic between client and the internet.

Payload inconsistency

A client will receive duplicate TCP packets with the same sequence number but with a different payload. The first TCP packet will be the “inserted” one while the second is from the real server, but will be ignored by the client. Of course it could also be the other way around; if the QI failed because it lost the race with the real server response.


Example of duplicate sequence and ack numbers, but with different payload sizes.

Checking the first content carrying packet is probably the easiest way to detect a QI, but offers no guarantees, as an inject can be present later in the TCP session. Checking only the first content carry packet reduces the amount of false positives.

A retransmission with a different payload size will sometimes look like a QUANTUMINSERT, this can happen when a retransmission is cut short, for example during TCP window size changes.

TTL anomalies

The injected packets also show a difference in their Time To Live[9] (TTL) values. Because the QI packets are usually inserted closer to the target client, the TTL is relatively higher than that of the real responses, because they come from further away. While the initial TTL can be modified, it is difficult to exactly predict the correct TTL value.

Slight variations in TTL values are not unusual, due to route changes on the internet.

Other anomalies

Other anomalies can be seen if the spoofed packets are not carefully crafted. For example, the TCP Timestamp value is usually set if it was also set in the TCP SYN packet. However this could vary between operating systems.

Other values such as the Differentiated Services Code Point (DSCP) in the IP header can also be observed for anomalies.

Detection using IDS

We created a number of packet captures (pcaps) when performing the Quantum Insert attack, which can be found here:

This helped us with developing detection for a number of Intrusion Detection Systems and we hope others find these pcaps useful for further analysis and research.

While we have released Snort signatures in the past, we realised that this was not going to be enough to detect Quantum Insert. The Fox-IT Security Research Team successfully made detection for Quantum Insert and released this proof of concept code into the public domain on our GitHub:


We made custom patches to the Snort Stream pre-processor to be able to detect possible Quantum Inserts. We found this to be the most efficient way rather than creating our own pre-processor. When a possible QI is detected it will trigger an event and also try to log the payload of the other TCP packet that was inconsistent as extra data.

See the for more technical details:

We hope these patches will eventually find its way upstream.


We made a Bro policy to check for inconsistencies in the first content carrying packet. Keeping track of multiple packets would be better, if this could be done in the core functionality of Bro. We attempted to use the rexmit_inconsistency event, but this did not seem to work. Others have also reported this on the mailing lists[10], however it never got much attention. It should be feasible to improve Bro so that it can also keep track of older TCP segments, in order to detect QI like attacks. There’s even an official Bro ticket for this: BIT-1314[11].

See the for additional technical details:


We asked the lead developer of Suricata, Victor Julien, if he could verify Suricata’s coverage for QI by supplying him a pcap. Victor explained that Suricata has an event called ‘stream-event:reassembly_overlap_different_data’ that can be alerted on when triggered using a default signature. We received an additional signature that detects HTTP 302 responses in possible QI payloads.


Note that these detection methods are possibly not evasion proof, one could also easily spoof a FIN packet after the QI packet to close the session. This would stop tracking the TCP segments in most IDS systems. Later packets in this stream will not be matched with previous packets.

Other possibilities is to try to create a partial overlap of data, thus avoiding detection of duplicate sequence numbers.

Other work

The following blog post[12] describes how to perform QI containing Proof of Concept code to perform the attack:

HoneyBadger[13], is a comprehensive TCP stream analysis tool for detecting and recording TCP attacks written by David Stainton can most likely also detect this attack.

While writing this article a DoS attack on GitHub was going on and a analysis was posted by NETRESEC[8], we did not see duplicate packets in the screenshots that could indicate a QUANTUM (man on the side) attack. However, the difference in TTL values was noticeable.

The detection for this attack has been included in our Cyber Threat Management platform.



1. Nsaplayset website
2. Overview of QUATUMTHEORY
3. Selectors used by the NSA
4. Chinas Great Cannon
5. How Mitnick hacked Tsutomu Shimomura
6. TCP session hijacking by Cheese
7. Airpwn
8. Man on the side attack on GitHub.
9. Time To Live
10. Bro Mailing list
11. QI Bro ticket
12. Killing Schrodingers cat
13. HoneyBadger TCP stream analysis tool

Liveblog: Malvertising from Google advertisements via possibly compromised reseller

We are currently observing a large scale malvertising campaign originating from all the Google advertisement services resold from It appears as if if all of its advertisement & zone ID’s are currently redirecting to a domain, which in its turn is redirecting to the Nuclear Exploit Kit, indicating a possible compromise at this reseller of Google advertisement services. This Nuclear Exploit kit targets vulnerabilities in Adobe Flash, Oracle Java and Microsoft Silverlight software.

Fox-IT observed the first redirect to the malicious domain on April 7th 2015 on 15:41:42 (CEST/GMT +02:00). The Fox-IT SOC has detected a relatively large amount of infections and infection attempts from this exploit kit among our customers. We suspect that this malvertising campaign will be of a very large scale.

The domains for the exploit kit itself aren’t directly used for redirection; a secondary site is used as an intermediate. The domains and IP’s used for the exploit kit are constantly changing, to mitigate the threat for now we suggest blocking the website between the legitimate websites and the exploit kit. We have observed the following being in constant use (we will update if anything changes):

  • /

Domains observed for the Nuclear Exploit Kit:

  • /
  • /
  • (currently offline)

Though we have yet to identify the exact malware variant victims are currently being infected with via the exploit kit we have identified the command and control server used:

  • /

To limit damage we recommend the following steps

  • Block access to
  • Use an adblocker
  • Update Java, Silverlight and Flash to the latest versions

Google has been notified of the issue.

Update #1: Added image (see below) to illustrate the malvertising redirection chain (21:49 CEST/GMT +02:00)

Update #2: Though we have not received any official confirmation, we are currently no longer observing malicious redirects from the advertisement reseller (22:54 CEST/GMT +02:00)

Update #3: After analysis the payload has been identified as Pony Loader, malware able to steal credentials and install other types of malware. VirusTotal link with basic information: (18:27 CEST/GMT +02:00)

Keep an eye on this blog for updates on the situation.

The following image illustrates the malvertising chain from a website using Doubleclick to the Nuclear exploit kit (for a more thorough explanation of what malvertising is, please see: Malvertising: not all Java from is legitimate):
Malvertising via Doubleclick

CryptoPHP a week later: more than 23.000 sites affected

On November 20th we published our report on CryptoPHP. Since publishing we have, together with other parties, been busy dealing with the affected servers and taking down the CryptoPHP infrastructure.

Sinkhole statistics

With the help of the NCSC,, Shadowserver and Spamhaus we have been able to gather data about the scale of the operation ran by the CryptoPHP authors. Most C2 domains that were active at the time of publishing have been either sinkholed or taken down. From the sinkholed domains we’ve been able to gather statistics.

In total 23.693 unique IP addresses connected to the sinkholes. We are already seeing a decline in sinkhole connections, on the 22nd 20.305 connections were made, on the 23rd 18.994 and on the 24th it was already down to 16.786. These numbers are however not a clear indication, mostly because the servers connecting to our sinkholes were shared hosting with at least 1 or multiple backdoored websites. This means the actual affected websites will be higher. Unfortunately we are also unable to make statistics on whether the affected server is running WordPress, Joomla or Drupal. This information is encrypted using public key encryption as explained in the paper.

A geological map was generated from the sinkhole data, the image below gives an overview of the affected countries.

CryptoPHP Sinkhole Infection_Statistics

Updated information

Since publishing we’ve been keeping an eye on any new developments within CryptoPHP. On the 23rd most of the websites used to spread the backdoored plug-ins and themes went offline, unfortunately they were back up with a new setup a day later and are still active at the time of this publication.
A new version of the backdoor was pushed, although the version number wasn’t changed we did get a new filehash for the backdoor. The SHA1 hash for the file is ‘c4fe641e3410fb047004c9653c79124c32a66446’; the version number is still 1.0.
The updated hash was committed to the github repo with IOCs at:


We noticed that our advice in our paper wasn’t clear to everyone. Spamhaus received a lot of inquiries about what to do with affected servers or how to find them. For this reason we’ve added this section to explain this a bit better.


We have created two Python scripts to help administrators detect CryptoPHP:


Both scripts can be found on our GitHub repo: is for scanning the filesystem for the CryptoPHP backdoor files. It will find all “social*.png” files and determine if it’s malicious.
And script can scan a website to determine if the website is affected by CryptoPHP. This can be useful if you have multiple virtual hosts and don’t know which one is affected.


If CryptoPHP has been found we recommend the following steps:

  1. Remove the “include” of the backdoor. For example, find the script that contains: “<?php include(‘images/social.png’); ?>”. Note that this path can vary.
  2. Remove the backdoor (social*.png) itself by deleting it.
  3. Check your database to see if any extra administrator accounts were added and remove them
  4. Reset the credentials of your own CMS account and other administrators (they were most likely compromised)

The steps above should be sufficient to remove the impact CryptoPHP has had on your website. We do however recommend performing a complete reinstall of your CMS since the system integrity may have been compromised. An attacker may have gained system wide access for example.
For both security and legal reasons we would advise not to install this kind of pirated (nulled) content.

CryptoPHP: Analysis of a hidden threat inside popular content management systems


Update: We’ve published statistics on CryptoPHP and some advice: CryptoPHP a week later: more than 23.000 sites affected

CryptoPHP is a threat that uses backdoored Joomla, WordPress and Drupal themes and plug-ins to compromise webservers on a large scale. By publishing pirated themes and plug-ins free for anyone to use instead of having to pay for them, the CryptoPHP actor is social engineering site administrators into installing the included backdoor on their server.

After being installed on a webserver the backdoor has several options of being controlled which include command and control server communication, mail communication as well as manual control.

Operators of CryptoPHP currently abuse the backdoor for illegal search engine optimization, also known as Blackhat SEO. The backdoor is a well developed piece of code and dynamic in its use. The capabilities of the CryptoPHP backdoor include:

  • Integration into popular content management systems like WordPress, Drupal and Joomla
  • Public key encryption for communication between the compromised server and the command and control (C2) server
  • An extensive infrastructure in terms of C2 domains and IP’s
  • Backup mechanisms in place against C2 domain takedowns in the form of email communication
  • Manual control of the backdoor besides the C2 communication
  • Remote updating of the list of C2 servers
  • Ability to update itself

We’ve identified thousands of backdoored plug-ins and themes which contained 16 versions of CryptoPHP as of the 12th of November 2014. Their first ever version went live on the 25th of September 2013 which was version 0.1, they are currently on version 1.0a which was first released on the 12th of November 2014. We cannot determine the exact number of affected websites but we estimate that, at least a few thousand websites are compromised by CryptoPHP.

Read all the details in the whitepaper: CryptoPHP-Whitepaper-FoxSRT