Mofang: A politically motivated information stealing adversary

mofang_cover_imageMofang (模仿, Mófa ̌ng, to imitate) is a threat actor that almost certainly operates out of China and is probably government-affiliated. It is highly likely that Mofang’s targets are selected based on involvement with investments, or technological advances that could be perceived as a threat to the Chinese sphere of influence. This is most clearly the case in a campaign focusing on government and critical infrastructure of Myanmar that is described in this report. Chances are about even, though, that Mofang is a relevant threat actor to any organization that invests in Myanmar or is otherwise politically involved. In addition to the campaign in Myanmar, Mofang has been observed to attack targets across multiple sectors (government, military, critical infrastructure and the automotive and weapon industries) in multiple countries.

The following countries have, in the above named sectors, been affected, although Fox-IT suspects there to be more: India, Germany, United States, Canada, Singapore, South Korea.

mofang_targetedcountries_image

Despite its diverse set of targets Mofang is probably one group. This is based on the fact that its tools (ShimRat and ShimRatReporter) are not widely used, and that campaigns are not usually observed in parallel. Technically, the group uses distinct tools that date back to at least February 2012: ShimRat and ShimRatReporter. The mofang group does not use exploits to infect targets, they rely on social engineering and their attacks are carried out in three stages:

  1. Compromise for reconnaissance, aiming to extract key information about the target infrastructure.
  2. Faux infrastructure setup, designed to avoid attracting attention.
  3. The main compromise, to carry out actions on the objective.

The name ShimRat is based on how its persistence is build up. It uses the so-called shims in Windows to become persistent. Shims are simply hot patching processes on the fly, to ensure backward compatibility of software on the Microsoft Windows platform.

As far as known, the only exploits the Mofang group uses are privilege elevation exploits built into their own malware. The vulnerabilities that were being exploited were already known about at the time of use. The full report contains contextual as well as technical information about the group and its activities. These can be used, for example, for threat assessments, compromise assessments, incident response and forensics activities.

Download ‘Mofang – a politically motivated information stealing adversary’

Large malvertising campaign hits popular Dutch websites

On Sunday April 10th the Fox-IT Security Operations Center (SOC) started to see an increase of exploit kit related incidents. The incidents originated from a large malvertising campaign hitting the Netherlands. The list of affected websites spreads across most of the popular Dutch websites. In total we’ve now seen at least 288 websites being affected. To give an impression of the impact, the list of affected websites includes:

  • nu.nl
  • marktplaats.nl
  • sbs6.nl
  • rtlnieuws.nl
  • rtlz.nl
  • startpagina.nl
  • buienradar.nl
  • kieskeurig.nl
  • veronicamagazine.nl
  • iculture.nl
  • panorama.nl

Note: Malvertising is caused by malicious content providers in the advertisement ecosystem, and not caused by the affected websites themselves (f.e those listed above).

We’ve been in contact with the affected advertisement provider who responded quickly to the incident and has filtered the listed IOCs in their advertisement platform. They will be tracking down the affected content provider as this issue has not been fully resolved, it has simply been filtered for now. More information on malvertising can be found here: [ Malvertising: Not all Java from java.com is legitimate ].

Details of the exploit kit redirect

The malvertising is occurring through an advertisement platform which is actively used on the above mentioned websites. From the websites, external scripts are loaded which in turn redirect further towards the exploit kit. We’ve observed the Angler Exploit Kit being active on these redirects during this campaign. We have not seen any successful infections at our customer yet.

One of the redirects towards the Angler exploit kit as observed by our monitoring platform:

protact-fox-it-com-angler-malvertising

Indicators of Compromise (IOCs)

The following two domains have been observed to redirect the users from the affected websites towards the exploit kits. Blocking these two domains will aid in stopping the redirects for now:

  • traffic-systems.biz (188.138.69.136)
  • medtronic.pw (188.138.68.191)

Website of security certification provider spreading ransomware

Since Monday the 21st of March the Fox-IT Security Operations Center (SOC) has been observing malicious redirects towards the Angler exploit kit coming from the security certification provider known as the EC-COUNCIL. As of writing this blog article on the Thursday the 24th of March the redirect is still present on the EC-COUNCIL iClass website for CEH certification located at iclass[dot]eccouncil[dot]org. We have reached out and notified the EC-COUNCIL but no corrective action has been taken yet.

Update 25-4-2016: EC-COUNCIL put out a publication regarding the malicious redirect. They’ve cleaned up and removed the malicious redirect, the publication was made on their Facebook page and linked to on their Twitter account.

Exploit kit details: Angler exploit kit

We first observed the redirect on Monday around 3pm GMT but we suspect it might have been there for a longer period of time. The redirect occurs only when specific conditions are met, these conditions are:

  • The visitor has to have Microsoft Internet Explorer as a browser (or at least the user-agent has to represent Internet Explorer)
  • The visitor comes from a search engine like Google or Bing
  • The visitor’s IP address is not blacklisted or belonging to a blocked geolocation. The inject avoids certain countries (possibly tied to a bad ‘ROI’ for the criminals running the ransomware that is being dropped)

Once a visitor meets all these requirements a redirect is embedded at the bottom of the page as seen in this screenshot:
EC-COUNCIL iClass Angler exploit kit injected script

Through this embedding the client is redirected a couple of times to avoid/frustrate/stop manual analysis and some automated systems. Once the user has jumped through all the redirects he/she ends up on the Angler exploit kit landing page from which the browser, flashplayer plugin or silverlight plugin will be exploited. The Angler exploit kit first starts the ‘Bedep’ loader on an exploited victim machine which will download the final payload.

The way the redirect occurs on the EC-COUNCIL website is through PHP code on the webserver which is injecting the redirect into the webpage. A vulnerability in the EC-COUNCIL website is most likely exploited as it runs the very popular WordPress CMS which has been a target through vulnerable plug-ins for years.

Payload details: TeslaCrypt

This specific campaign instance of the Angler exploit kit drops ‘TeslaCrypt’ on the exploited victim’s machine. TeslaCrypt is a piece of ransomware which takes a victim’s files hostage with the use of encryption. Once the victim’s files have been successfully encrypted a ransom note is presented to instruct the victim on ways to recover files:

TeslaCrypt 4.0 ransom notes

TeslaCrypt requires the victim to pay around 1.5 BTC to get their files back; this equals to approximately 622$ at the current conversion rate.

Indicators of Compromise (IOCs)

Bedep C&C servers:

  • 89.163.240.118 / kjnoa9sdi3mrlsdnfi[.]com
  • 85.25.41.95 / moregoodstafsforus[.]com
  • 89.163.241.90 / jimmymorisonguitars[.]com
  • 162.244.32.121 / bookersmartest[.]xyz

TeslaCrypt C&C servers:

  • 50.87.127.96 / mkis[.]org
  • 213.186.33.104 / tradinbow[.]com

The state of Ransomware in 2015

Introduction

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

History

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.

Overview

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

pspimage

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

dwg

pdb        c

cpp         hhpp

class       cs

dtd         fla

java        lua

m            pl

py           pas

jpe         jpg

jpeg

3g2         3gp

asf          asx

avi          flv

m4v       mov

mp4       mpg

rm          srt

swf         vob

vmw      mp3

wav        flac

Bak

back

 

Ransomware analysis: CTB-Locker

History

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).

Overview

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

wps

 

kdc         nef

raw

cpp         c

php        js

cs            pas

bas         pl

py

3fr          dds

jpe         jpeg

jpg          cr2

rw2        psd ai             dd

rwl          dxf

dxg         arw

cdr          crw

eps         dcr

dng        indd

mrw       nrw

srw         ims

rgx

 

 

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

config

 

Ransomware analysis: TorrentLocker

History

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

Overview

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

xlw

 

 

 

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

py

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

sxd

 

al             bik

cpi          mpg

ycbcra

7z            accdb

accde    accdr

accdt     adb

apj          awg

backup               backupdb

bak         bdb

bgt         bkp

bpw       cdx

cer          cls

crt           csl

dac         db

db-journal

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

moneywell

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

sas7bdat

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.

 

Conclusions

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

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.

Details

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:

  • telegraaf.nl
  • theguardian.co.uk
  • huffingtonpost.com
  • lemonde.fr

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 goo.gl 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:

  • earthtools.org/timezone/0/0
  • ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d.xml

We have yet to identify the final payload.

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

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, Abuse.ch, 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:
https://www.github.com/fox-it/cryptophp/

Advice

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.

Detection

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

  1. check_url.py
  2. check_filesystem.py

Both scripts can be found on our GitHub repo: https://www.github.com/fox-it/cryptophp/scripts/
check_filesystem.py is for scanning the filesystem for the CryptoPHP backdoor files. It will find all “social*.png” files and determine if it’s malicious.
And check_url.py 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.

Removal

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.

Malvertising: Not all Java from java.com is legitimate

Isn’t it ironic getting a Java exploit via java.com, the primary source for one of the most common used browser plugins? Current malvertising campaigns are able to do this. This blog post details a relatively new trend: real-time advertisement bidding platforms being infiltrated by cyber criminals spreading malware.

Malvertising

 

Conclusion

Malvertising has changed over the years starting with exploitation of weak advertisement management panels and has now evolved into pretending to be a legit third party advertiser with social engineering. The current malvertising techniques are quite deceptive and most of the times only noticeable at the client side.

Combating this malvertising technique is hard due to the large layered setup of the bidding platforms currently in place. It can be a malicious advertiser 3 layers down in the chain but it can also be on the 1st level. Trust is the current system many advertisers use but it seems to be insufficient for today’s malvertising campaigns and techniques, a new system needs to be implemented in order to combat them.

Findings in network monitoring

Over the last week, from Tuesday august 19th until Friday august 22nd, the Security Operations Center of Fox-IT’s ProtACT service observed multiple high-profile websites redirecting their visitors to malware. These websites have not been compromised themselves, but are the victim of malvertising. This means an advertisement provider, providing its services to a small part of a website, serves malicious advertisement aimed at infecting visitors with malware.

While monitoring network traffic to and from workstations we observed a higher than usual amount of infections. When investigating these incidents in depth we noticed that they were infected with advertisements served via high-profile websites. During this period at least the following websites were observed redirecting and/or serving malicious advertisements to their visitors:

  • Java.com
  • Deviantart.com
  • TMZ.com
  • Photobucket.com
  • IBTimes.com
  • eBay.ie
  • Kapaza.be
  • TVgids.nl

The advertisement in this case included the Angler exploit kit. Upon landing on this exploit kit a few checks were done to confirm whether the user is running a vulnerable version of either Java, Flash or Silverlight. If the user was deemed vulnerable the exploit kit would embed an exploit initiating a download of a malicious payload, in this campaign it was the Asprox malware. This whole process of malvertising towards an exploit kit is also visualized in the image at the top of this post.
Please note, a visitor does not need to click on the malicious advertisements in order to get infected. This all happens silently in the background as the ad is loaded by the user’s browser.

One aspect of advertisement networks that makes tracking these threats really complicated is ‘retargetting’. Retargetting is the process of one or multiple ad and content providers leaving tracking data, cookies or other files, so the next time an advertiser can deliver different advertisement as was shown the previous time. A website that rents advertisement space can sometimes show retargetted advertisement without knowing. The way it works is that a user with an interesting set of tracking cookies and other metadata for a certain adprovider is retargetted from the original advertisement content on the website to the modified or personalized data. We have seen examples where the website that helped with the ad redirect to infect a user had no idea it was helping the delivery of certain content for a certain adprovider.

While half the world is already familiar with exploitation of browser plugins, keep in mind drive-by and water-hole attacks are not solely focusing on the common browsers. A couple of months ago we also noticed advertisement loaded by the ‘Skype’-application was also serving malicious content.

In both cases Fox-IT contacted the affected advertiser, AppNexus in these cases, to quickly stop the malvertising.

The problem

The biggest problem with these malicious advertisements is that separating good from bad is a difficult process in the world of online advertising. With specific schemes such as real-time bidding, bad advertisements can remain hidden for extended periods of time. The Dutch website tweakers.net has recently published a detailed article about the problem here.

AppNexus as an example for this case, is one of the companies providing real-time bidding on advertisements and is used by many of the top ranking websites.

What is real-time bidding?

Real-time bidding is a process many advertisers have to serve ads. When a user visits a website, for example deviantart.com, this triggers a bidding request among the affiliates of the advertiser who will get to see meta-data about the visiting user. This metadata can include: geographical location, browser type, and web browsing history. The affiliates in their turn then automatically bid on this impression. The highest bidding advertisers gets to display their ad. In the case of this malvertising campaign the malicious advertisers were the highest bidders. For more details please see http://en.wikipedia.org/wiki/Real-time_bidding.

The Payload

The aim of the exploit kit is to execute a malicious file on the visitor’s computer to infect them. The Angler exploitkit has been observed to deliver different payloads in the last few days. Although the dropped malware can vary, Fox-IT has only seen the Asprox malware being spread with this campaign.

Update (August 27th): It was pointed out by Kimberly on twitter that it was in fact Rerdom that was distributed which we mistook for Asprox (https://twitter.com/StopMalvertisin/status/504652910429360129). Although, Asprox and Rerdrom do have a close relationship and affiliate with each other. More about the Asprox ecosystem can be read here on the StopMalvertising website: [ Urgent eviction notification – A deeper dive into the Asprox Ecosystem ].

Asprox is a notorious spam botnet which has upped its game over these past few months by using the infected machines to perform advertisement clicking fraud. Since this move the actors behind this botnet have started spreading Asprox on a much larger scale, at first via e-mail attachments and now by employing various exploit kits. Statistics provided by FireEye provided back in May 2014 shows big fluctuations in the botnet size and botnet activity:

FireEye Asprox tracking
(Source: http://www.fireeye.com/blog/technical/malware-research/2014/06/a-not-so-civic-duty-asprox-botnet-campaign-spreads-court-dates-and-malware.html)

In 2013 Trendmicro also published a paper about Asprox which explained the variety of functionality of the botnet. While Asprox is known as a spam botnet to most the spam is only 1 component of a modular botnet called Asprox. Asprox has gone through many changes and modifications which includes spam modules, website scanning modules and even credential stealing modules. This history and current events show Asprox is still actively being developed and used.

Indicators of compromise

These IOC’s relate to the malvertising campaign on the high-ranked websites specifically. The advertisement content first redirects to: ads.femmotion.com (204.45.251.105) which will give redirects towards the exploit kit.

The exploit kit:

Domains that were observed:

  • thegloriousdead.com (on port 37702)
  • taggingapp.com (on port 37702)

PassiveDNS logging shows 3 IP’s having been associated with these domains:

  • 198.27.88.157
  • 94.23.252.38
  • 178.32.21.248

All the exploit kit hosts were observed using port 37702. Running exploit kits on high ports at best prevents certain network tools from logging the HTTP connections, as these are typically configured to monitor only HTTP ports. It does mean this exploit kit is blocked on a lot of corporate networks as they do not allow for browsing outside the normal HTTP ports, port 80 (or proxy ports) and 443 for SSL.

The ‘Asprox’ malware:

Since this botnet makes use of a fast flux technique the domain names make for better indicators of compromise than IP’s:

  • from-gunergs.ru
  • oak-tureght.ru
  • nationwidedownload.com

The following MD5 hash was seen for the dropped payload:

  • Crypted payload: 554c5dbb12e3fd382ce16e5bb34a17c2
  • Decrypted payload: 5304bc5b9454e6bc5a0ba2bff0eba605

Advice

There is no silver bullet to protect yourself from malvertising. At a minimum:

  • Enable click-to-play in your browser. This prevents 3rd party plugins from executing automatically.
  • Keep all plugins running in the browser up-to-date using tools like Secunia PSI.
  • Consider turning off unneeded plugins if you don’t use them. For example, Java can be installed without the web-plugin component lowering the risk of exploitation and infection.

Usage of Adblockers

In cases of malvertising on websites ad blockers are usually effective in blocking redirects.
However, on the case of Skype on May 15th it would have been insufficient. Most adblockers are part of the Browsers as an add-on, incapable of filtering for other applications. Skype makes use of Adobe Flash to display certain advertisements, this happens to be a plugin which the Angler can exploit.

Fox-IT Security Research Team

Not quite the average exploit kit: Zuponcic

A couple of weeks ago at the FOX-IT SOC, we noticed Zuponcic attempting to infect one of our clients protected networks. The incident was caused by a person visiting the website of Suriname’s Ministry of Finance, minfin.sr.

This post connects three recent developments in the realm of malware infections: .htaccess server compromise, the Zuponcic exploit kit and the Ponmocup botnet. It seems that the defacto standard of exploit kits is getting competition. Understanding how this exploit kit works will give you a better chance of defending against it and for identifying the .htaccess compromise on your server.

Looking back at clients that have been affected by Zuponcic there had been a significant increase in compromised websites serving this kit starting June 2012, including some relatively big Dutch websites along the way, such as iphoneabonnementen.nl and tboek.nl.
This is interesting as websites hosting this kit have to be compromised due to the nature of the redirects. It seems the trend of using compromised website to attack users continues. As a sidenote, Zuponcic is not the actual name of this exploit kit, its real name is unknown. The first website it was found redirecting on was zuponcic.com, this is where the name came from.

Analysis of the attack

The way in which someone has to land on a compromised website for Zuponcic to become active is very carefully crafted and the redirection process is dependent on multiple conditions. This process is started via an .htaccess file which is placed in every (sub)folder of the compromised host. This file makes sure the referrer is either a search engine, webmail or social media website and that crawlers are not affected by checking for known IP’s and user-agents. A sample of this .htaccess file on a compromised server:

htaccess_referer_check

If all of these conditions are met, the victim is redirected to the Zuponcic landing page via one of the 60 redirection patterns a single .htaccess file has to offer. These redirect patterns try to follow the ones seen in legitimate advertise networks. They imitate urls seen for OpenX, Google Ads and a lot of others, this to mask its true redirect purpose. In the htaccess the section of the fake advertisement URL redirects looks like this:

htaccess_fake_redirects

Mapping this whole redirection scheme in a flowchart looks like this:

zuponcic_redirect_flowAfter the redirection process, Zuponcic carefully attempts to infect the victim, this type of attack is dependent on the victims setup. The flow for the attack looks like this:

zuponcic_attack_flow

Zuponcic only targets Java on the clients from what we have seen. Besides Java exploits, Zuponcic also tries to social engineer the user. When a victim does not have Java enabled or the browser used is not Internet Explorer, a ZIP file is presented. This file has to manually be downloaded and executed by the victim. To make the download seem appealing, a form of social engineering is used by having the name of the ZIP file consist of two random triggers words in combination with the keyword(s) used in the search engine.

zuponcic_zip_bing_keyword

The attack initiated when a victim uses Internet Explorer 8, originally described on Malwageddon’s blog, used a signed Java Applet to perform a drive-by.

The Java applet is signed with a valid certificate which is most likely stolen. During the Zuponcic campaign three of these certificates have been spotted. The two certificates originally used belonged to Triton IT d.o.o (UserTrust) and R.P. InfoSystems (VeriSign). After both of these had expired the switch was made to the certificate owned by “Kurz Instruments, Inc.” (GlobalSign), and is currently still being used:

Kurz Instruments Inc Certificate

We have seen the following 3 certificates being used on the different Java exploits used by Zuponcic:

  • Subject: Kurz Instruments, Inc.
  • Fingerprint: 8A:DC:2D:8B:B5:3C:DC:93:C9:80:C4:F6:C0:80:59:73:8B:88:19:16
  • Issuer: GlobalSign
  • Subject: R P Infosystems Pvt Ltd
  • Fingerprint: BB:48:74:0F:01:E6:7F:EE:A6:06:96:4B:D5:81:A7:30:BF:D0:54:D7
  • Issuer: VeriSign
  • Subject: iLoq Oy
  • Fingerprint: 76:90:09:5B:C3:FC:9F:9D:74:98:56:F6:E1:DD:22:C0:89:44:F7:F9
  • Issuer: VeriSign

If a victim uses Internet Explorer 10, a JAR file is sent to at that person to be downloaded. The JAR, named with the same pattern as the ZIP file, contains the embedded payload. The payload is again RC4 encrypted. Interestingly enough the key is based on the hash of the victims IP. A snippet of this can be seen in the deobfuscated Java lines below:

IE10_jar

For all instances the payload is the same: Ponmocup. Hashes for the two signed Java exploits seen being used:

  • 8d7028a0a0bf1e98fe90b5c3abb19059  (IE10.jar)
  • caa4cbe00c30458198a05a0cddddc1cd  (IE8.jar)

Hashes for samples we have seen (they are repackaged almost every time so this list will keep growing):

  • eb958d6e68cc635df16ade31227f0608  (bar__installer.exe)
  • bf1bd2fe9531224b619603cdaa575d61  (clickme__go.exe)
  • 9fd575356db4dc48a7c9f99de4fc358d  (daily_tool_.exe)
  • 7b9f5ba2ef5a6b94a4380be66e08e33f  (fixer__setup.exe)
  • aafa234b5db771d8df18c0f6719f264e  (folder__auto.exe)
  • 4888fafc13ad367954d96c0d913c316e  (full_setup_.exe)
  • 207c4ffd729c946ce261da6143c633fb  (instant_runme_.exe)
  • 6377d0a5bb8d183e8c3769016967f9fc  (internet__auto.exe)
  • c9e180a512f226a4c9da30c11498bfcd  (internet_setup_.exe)
  • 2f30863d70dbfb119c4b7185f5f7023a  (now_run_.exe)
  • 0dce01b2e5b566fc23da6f5a42d4ab8c  (private_www_relisound.exe)
  • 78cf24f2f6beeb9e4b2cb051073af066  (pure__run.exe)
  • f5835ab4ed47f1525a8da75e5134d452  (total_relisound_www.exe)
  • 244100de819e9943a1b76098a1f4d67a  (video_install_.exe)
  • 0f6280fce950601aca118be6312e0bfd  (viewer_relisound_www.exe)
  • 50d8bf638bd60c81de1790c2e0725a98  (windows__auto.exe)

Conclusion

The .htaccess compromise, Zuponcic and Ponmocup campaign have all been described seperately, but a connection has never been made between the three. From what we have seen it seems Ponmocup is behind this exploit kit as the only files ever seen being dropped from this are Ponmocup payloads. If you want to know more about Ponmocup, Tom Ueltschi has been investigating this botnet for a while now, read about it on his blog.

The amount of websites seen redirecting to this exploit kit is not as big as some of the others out there but what stands out are the ranking of these sites. They all have a lot of traffic and appear as the first domains for many frequently used search queries. This correlates with their method of redirecting for users only coming from the search engines.

Maarten van Dantzig, Yonathan Klijnsma & Barry Weymes, Security Specialists at Fox-IT

Large botnet cause of recent Tor network overload

Recently, Roger Dingledine described a sudden increase in Tor users on the Tor Talk mailinglist. To date there has been a large amount of speculation as to why this may have happened. A large number of articles seem to suggest this to be the result of the recent global espionage events, the evasion of the Pirate Bay blockades using the PirateBrowser or the Syrian civil war.

At the time of writing, the amount of Tor clients actually appears to have more than quintupled already. The graph shows no signs of a decline in growth, as seen below:

Tor Metrics

An alternative recurring explanation is the increased usage of botnets using Tor, based on the assertion that the increase appears to consist of mostly new users to Tor that apparently are not doing much given the limited impact on Tor exit performance. In recent days, we have indeed found evidence which suggests that a specific and rather unknown botnet is responsible for the majority of the sudden uptick in Tor users. A recent detection name that has been used in relation to this botnet is “Mevade.A”, but older references suggest the name “Sefnit”, which dates back to at least 2009 and also included Tor connectivity. We have found various references that the malware is internally known as SBC to its operators.

SBC Panel

Previously, the botnet communicated mainly using HTTP as well as alternative communication methods. More recently and coinciding with the uptick in Tor users, the botnet switched to Tor as its method of communication for its command and control channel. The botnet appears to be massive in size as well as very widespread. Even prior to the switch to Tor, it consisted of tens of thousands of confirmed infections within a limited amount of networks. When these numbers are extrapolated on a per country and global scale, these are definitely in the same ballpark as the Tor user increase.

Thus one important thing to note is that this was an already existing botnet of massive scale, even prior to the conversion to using Tor and .onion as command and control channel.

As pointed out in the Tor weekly news, the version of Tor that is used by the new Tor clients must be 0.2.3.x, due to the fact that they do not use the new Tor handshake method. Based on the code we can confirm that the version of Tor that is used is 0.2.3.25.

Tor Module Analysis

The malware uses command and control connectivity via Tor .onion links using HTTP. While some bots continue to operate using the standard HTTP connectivity, some versions of the malware use a peer-to-peer network to communicate (KAD based).

Typically, it is fairly clear what the purpose of malware is, such as banking, clickfraud, ransomware or fake anti-virus malware. In this case however it is a bit more difficult. It is possible that the purpose of this malware network is to load additional malware onto the system and that the infected systems are for sale. We have however no compelling evidence that this is true, so this assumption is merely based on a combination of small hints. It does however originate from a Russian spoken region, and is likely motivated by direct or indirect financial related crime.

This specific version of the malware, which includes the Tor functionality, will install itself in:

%SYSTEM%\config\systemprofile\Local Settings\Application Data\Windows Internet Name System\wins.exe

Additionally, it will install a Tor component in:

%PROGRAMFILES%\Tor\Tor.exe

A live copy for researchers of the malware can be found at:

hxxp://olivasonny .no-ip .biz /attachments/tc.c1

This location is regularly updated with new versions.

Related md5 hashes:

2eee286587f76a09f34f345fd4e00113 (August 2013)
c11c83a7d9e7fa0efaf90cebd49fbd0b (September 2013)

Related md5 hashes from non-Tor version:

4841b5508e43d1797f31b6cdb83956a3 (December 2012)
4773a00879134a9365e127e2989f4844 (January 2013)
9fcddc45ae35d5cdc06e8666d249d250 (February 2013)
b939f6ef3bd292996f97aa5786757870 (March 2013)
47c8b85a4c82ed71487deab68de196ba (March 2013)
3e6eb9f8d81161db44b4c4b17763c46a (April 2013)
a0343241bf53576d18e9c1329e6a5e7e (April 2013)

Thank you to our partners for the help in investigating this threat.

ProtACT Team & InTELL Team

DNS takeover redirects thousands of websites to malware

Starting on Mon, 5 august 2013, 06:57:30 Fox-IT’s monitoring service detected a redirect occurring initially on conrad.nl but later on many other websites. The way the site was compromised means thousands of websites are redirecting, in total 3 web hosters seem to have been affected by the DNS server compromise:

  • Digitalus
  • VDX
  • Webstekker

All sites using the DNS servers from these companies will have been affected. The official response given by Digitalus was that someone modified the DRS from SIDN with external name servers. This means that any DNS requests made to them would end up at the malicious DNS servers. The only problem now is that the DNS zones have a TTL (Time to live) of 24 hours. This means that most ISP would have this incorrect data in their caches for at least this length of time. After being contacted they fixed the issue and most public name servers now respond with the correct data. How the intruders got access to the DRS remains unknown until Digitalus or SIDN disclose more information, they are is still investigating the issue (source).

Every website that was being requested responded with a blank “Under construction” page with an iframe on it. The iframe was a host running the Blackhole Exploit Kit. While initially we assumed conrad.nl was compromised we found out that the DNS servers were giving back responses with the same IP every time: 178.33.22.5

The nameserver responses for conrad.nl as an example:

;; ANSWER SECTION:
conrad.nl.        300        IN        NS ns1.dn-s.nl.
conrad.nl.        300        IN        NS ns2.dn-s.nl.
;; ADDITIONAL SECTION:
ns1.dn-s.nl.        7200        IN        A 85.158.251.251
ns2.dn-s.nl.        7200        IN        A 83.96.142.70

Analysis of the attack

When vising the page on IP 178.33.22.5 the following response was given:

Malicious iframe

The host cona.com at the time was responding with 199.233.237.211. This hosted the exploit kit named Blackhole. The kit targetted the client with a PDF exploit (3/45 on VT) and a Java exploit (3/46 on VT).
Looking at URL data it looks as follows:

"GET http://www.conrad.nl/ HTTP/1.1" - - "-" "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0"
"GET http://cona.com/removal/stops-followed-forces.php HTTP/1.1" - - "http://www.conrad.nl/" "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0"
"GET http://cona.com/removal/stops-followed-forces.php?xsbmHaOUDWN=RcezQhYNSbrYT&BOZRScKNhz=QoMIfWkfOPj HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_32"
"GET http://cona.com/removal/stops-followed-forces.php?If=3030562f53&We=2i2j55302f2h322g2e52&i=2d&FE=V&ma=p HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_32"
"GET http://www.champagnekopen.nl/wp-content/uploads/2013/07/tr2.jpg HTTP/1.1" - - "-" "Internet"

The first request is to conrad.nl which responded with the malicious IP. This is followed by a request to the Blackhole exploit kit landing page via the initial iframe. After the script on the landing page is executed it does a request to (in this example) retrieve a JAR file to exploit the vulnerable java version. When the Java has been exploit it does a final request to the exploit kit retrieving the initial payload. Moments after downloading this the initial payload downloads a secondary payload which contains the Tor powered malware, note the sudden change of useragent to “Internet”.

The malware dropped communicates using the Tor network to various command and control servers, hashes for the files seen being dropped by the exploit kit:
d758fd8cfb80a458a43770037ec82aac
1af107152eda9cc870c639a5b1c3c466

The initial binary dropped from the exploit kit contacts the following two domains to download a 2nd stage payload:

http://champagnekopen.nl/wp-content/uploads/2013/07/tr2.jpg
http://panningendeavor.net/tr2.jpg

Cleanup

The old instructions previously stated in this post might not work for updated versions of the malware, we are advising  HitmanPro.Kickstart to clean up your PC.

Lennart Haagsma & Yonathan Klijnsma, Security Specialists at Fox-IT