OpenSSL ‘heartbleed’ bug live blog

heartbleedA bug has been identified in OpenSSL, all details can be found at 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 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

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 script against we were presented with this (censored) output. It shows clearly that the ‘heartbleed bug’ has serious consequences.

heartbleed example




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)

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:

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:


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

Oracle getting serious about Java

Recently, Oracle released new a version of Java with a difference. Java/1.7.0_13 is the latest version. Its increased the default security from ‘Medium’ to ‘High’, which restricts execution of unsigned applets. It also introduced a new warning to people executing Java code which checks if Java is using the latest version. You might notice the process jusched.exe running on your Windows PC to do this check. The conclusion here is that Oracle is getting serious about keeping its users up to date.


The above notice will give the users three choices: Update, Block or Continue. ‘Update’ will stop the execution and bring the user to the Java website to download the latest and safest version. ‘Block’ will not allow Java from being executed now and in future. By pressing ‘Block’ the user  Pressing ‘Later’ button the java code will be executed.


Why this updating matters? It matters because these days the majority of machines exploited are because of Java vulnerabilities. Exploit kits used to deliver a malicious payload to a victims computer are the form of a jar file (Java Archive). This usually happens when the victim visits a compromised website or opens a malicious email. A typical exploit kit has some malicious JavaScript that will test for vulnerable Java versions (amongst other things). Once the script has found the vulnerable version, it will automatically try to execute a malicious jar file to gain control of the machine. Some examples of successful exploitation that we have seen at the SOC recently:

  • hxxp:// Java/1.6.0_14
  • hxxp://  Java/1.6.0_20
  • hxxp:// /WtfWQjU.jar Java/1.6.0_37
  • hxxp:// Java/1.6.0_38
  • hxxp:// Java/1.7.0_06


Above shows part of a web interface for a botnet that has over 17500 successfully exploited systems using this blackhole exploit kit, we can see that over 78% of the systems was compromised by a Java exploit. This percentage is common and similar in other exploit kits, showing that Java continues to be the most commonly attacked application.

It would seem that users, don’t update software regularly and this is why the recent move by Oracle is important. Hopefully, this will stop the bad guys (continuously) taking advantage of that fact.

In the wild, we have seen the all types of old Java virtual machines getting compromised, anyone with these versions are obviously vulnerable. It is highly recommended that you either disable/uninstall Java or if you must use it make sure it is always up to date. Oracle’s increased focus on security stems from the need for better security in the software we use everyday, if this doesn’t happen maybe users and organisations will simply not accept it because it is too risky to have installed anymore.

Barry Weymes et al, Security Analyst at the Fox-IT Security Operations Center.

Demystifying Pobelka

A technical intelligence report on the Pobelka botnet operation. January 11, 2013

This technical report describes the Pobelka botnet and puts it in the context of global malware operations. Fox-IT’s InTELL unit provides reports like this on a continuous basis to customers in the financial sector so they know who’s targeting their online banking systems and can prepare countermeasures. This report is classified as public.

Key takeaways of the report are:

  • The initial Dutch report on Pobelka by Surfright and Digital Investigation presents a good view on the Pobelka botnet. The report you are reading contains additional technical details on the botnet and answers some of the questions left by the original report.
  • This report provides a broader context in the ecosystem of botnets, Trojans, exploit kits, and the markets where infected computers are traded.
  • This report details the identity of the people running the Pobelka botnet as well as a description of the origin of the botnet and the common methods of communication used.
  • The Pobelka botnet is one of many botnets active in the Netherlands. Unfortunately it’s not an exceptionally large or influential botnet but rather an average sized one.
  • The Pobelka botnet is just one of the many examples of how a single individual was able to attack Internet users for over a year without much resistance. This is a global issue.
  • The ease at which cybercrime services are available to criminals, makes it trivial for anyone to start in this business. The potential gains for the criminals are large, with little to no chance of successful prosecution.

The author of the report is Michael Sandee, Principal Security Analyst at Fox-IT and the Fox-IT InTELL team.

The intended audience for this report is technically savvy and familiar with botnet analysis and online banking security.

You can download a copy of the report here.