#cryptowalltracker

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.