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.

Not quite the average exploit kit: Zuponcic

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

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

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

Analysis of the attack

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


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


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

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


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


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

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

Kurz Instruments Inc Certificate

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

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

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


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

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

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

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


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

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

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

Large botnet cause of recent Tor network overload

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

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

Tor Metrics

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

SBC Panel

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

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

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

Tor Module Analysis

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

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

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

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

Additionally, it will install a Tor component in:


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

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

This location is regularly updated with new versions.

Related md5 hashes:

2eee286587f76a09f34f345fd4e00113 (August 2013)
c11c83a7d9e7fa0efaf90cebd49fbd0b (September 2013)

Related md5 hashes from non-Tor version:

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

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

ProtACT Team & InTELL Team

DNS takeover redirects thousands of websites to malware

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

  • Digitalus
  • VDX
  • Webstekker

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

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

The nameserver responses for conrad.nl as an example:

conrad.nl.        300        IN        NS ns1.dn-s.nl.
conrad.nl.        300        IN        NS ns2.dn-s.nl.
ns1.dn-s.nl.        7200        IN        A
ns2.dn-s.nl.        7200        IN        A

Analysis of the attack

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

Malicious iframe

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

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

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

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

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




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

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

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

Seen in the wild: Updated Exploit Kits

In early March, after one of our network sensors flagged an incident at one of our customers, we noticed some traffic going to a rather suspicious .biz domain. When looking into the details of this domain, we found it to be registered to a guy named “Lukas Vask”.


When doing a reverse whois on just the email address, we found that Mister Vask owns 88 domains, 3 ‘.com’, 1 ‘.net’, 70 other gTLD’s and 14 ccTLD’s.
When reviewing the same data some days later we found that he bought another 78 domains.

A small sample list of unique domains used:


Alongside the above unique domains seen, we noticed a simple type of domain obfuscation. Using a combination of 3 to 5 words from the english dictionary with both the .org and .biz TLD’s are registered. Afterwards a letter is added to the end of the domains, which are just ascending letters of the alphabet and again the .org and .biz are also registered.

A small example list of the used words:

We’ve seen the following being used in the wild:



These pages are serving the Nice Pack exploit kit at this time.

Nice Pack Exploit Kit

Previous listings of the Nice Pack exploit kit have used Javascript with the old fashioned try and catch methods which are easily detected by IDS systems. For the new landing page of Nice Pack the creators took some time in figuring out how to sail free from the IDS detection by using even more obfuscated Javascript with no clear usage of known functions. Using a combination of these randomly named variables and functions makes these landing pages harder to detect.

Sample landing page:

Deobfuscated it looks like this:

The NicePack uses a combination of Adobe PDF and Java exploits to drop its malware.
The Java exploit targets CVE-2012-1723. The Adobe PDF exploit could not be determined as it seems the exploit kit is missing files, a 404 is returned when the malicious PDF should be served.

One way of determining if you’re dealing with a NicePack exploit kit domain is by doing a HTTP request on port 443, in the response you get will included a little hint.

Checksums malicious files NicePack:
3cf648103d7d9ed4185494979af10b2c https://www.virustotal.com/en/file/5e283a5ef0213d9c920e644fb74b2de96420926fda86f80b9cf192e7514e5555/analysis/1362477992/

Sweet Orange Exploit Kit

While taking a look at Mister Vask, we found another type of domain obfuscation used to spread the Sweet Orange exploit kit.
This DGA works similar to the alphabet one but in this case adds an asceding number at the end, we’ve seen the following being used:


The new URL syntax of Sweet Orange looks like this as seen in the wild:


Older versions of the Sweet Orange exploit kit used shorter links for the landing page.

The landing page in this version of Sweet Orange:

The deobfuscated script part:


This part embeds the malicious PDF file located at ‘./tUaZFs’. The PDF targets CVE-2010-0188.The above attempts to exploit java vulnerbilities by loading malicious JAR files which target specific Java versions.The Java archives we’ve seen target CVE-2012-1723 and CVE-2013-0431 .

While most exploit kits check Java and Adobe versions to determine the most suitable way to drop their malware, this one attempts everything anyway and discards any version checking.
The bruteforce approach it seems.

Checksums malicious files SweetOrange:
6292f68f7deb3d7bb946096b9ecd8f45 https://www.virustotal.com/en/file/62a0a8ca7c9c92e06314cdd01c75048addf455972d8e6cea98b1050c7667f6ab/analysis/1362477648/
b4a044835a6a1464c556042db484b977 https://www.virustotal.com/en/file/499e42c9869f3e5a87478afe6a5c17978eeaefde9530cca6b73e315d2d740304/analysis/1362477660/
7a7ce94c19fcc47e20068e3f51971b52 https://www.virustotal.com/en/file/93e54881d92c38bb8876c7cd8af0da83051ec469f6dd5119a2a3f40696852501/analysis/1362477670/


Getting back to the WHOIS information, it seems the domains for both exploit kits are being registered with the same credentials. Either a fake account or stolen identity is being used by multiple people or the same guys are behind SweetOrange and NicePack.. who knows.

Yonathan Klijnsma & Barry Weymes