Category Archives: cyber threats

Painless Cuckoo Sandbox Installation

TLDR: As part of our SANS SEC599 development efforts, we updated (fixed + added some new features) an existing Cuckoo Auto Install script by Buguroo Security to automate Cuckoo sandbox installation (& VM import). Download it from our Github here.

As a blue team member, you often have a need to analyze a piece of malware yourself. For example, if you discover a malware sample in your network and suspect it might be part of a targeted attack. There’s a few options in this case: you could reverse the sample or do some static analysis, but maybe you want to get a “quick” insight by running it in a sandbox… It is often not desirable to submit your samples to public, online malware analysis services, as this might tip off your adversaries. So… How to proceed?

In the SANS training SEC599 that we’ve co-developed at NVISO (“Defeating Advanced Adversaries – Implementing Kill Chain Defenses”), we decided we wanted to show students how analysis can be performed using Cuckoo sandbox, a popular open source automated malware analysis system (We do love Cuckoo!).

After re-deploying manually Cuckoo a number of times in different environments, I (Erik speaking here) figured there must be a better way… After doing some Google’ing, I found the CuckooAutoinstall script created by Buguroo Security!

An excellent effort indeed, but it hadn’t been updated for a while, so we decided to update this script to include some additional features and enabled it to run with the latest version of Ubuntu (16.04 LTS) and Cuckoo (2.0.5). You can find it on our GitHub repository.

Preparing your sandbox
Before we do a walk-through of this script, let’s pause a moment to consider what it takes to set up a malware analysis environment. The type of analysis performed by Cuckoo can be classified as dynamic analysis: the malware sample is executed in a controlled environment (a Virtual Machine) and its behavior is observed. As most malware targets the Windows operating system and/or the applications running on it, you will need to create a Windows VM for Cuckoo.

You will need to step out of your role as a blue team member to prepare this VM: this VM has to be as vulnerable as possible! To increase the chances of malware executing inside the VM, you will have to disable most of the protections and hardening you would implement on machines in your corporate network. For example, you will not install an anti-virus in this VM, disable UAC, don’t install patches,…

To properly analyze malicious Office documents, you will use an older, unpatched version of Microsoft Office and you will disable macro security: you want the macros to run as soon as the document is opened, without user interaction.

Take your hardening policies and guidelines, and then …, do the opposite! It will be fun (they said…)!

Using CuckooAutoinstall
Installing Cuckoo with CuckooAutoinstall is easy: prepare your VM and export it to the OVA format, update the script with your VM settings, and execute it as root. We will discuss how you can create Cuckoo analysis VMs in a follow-up blogpost!

It’s best that your Ubuntu OS is up-to-date before you launch the script, otherwise you might encounter errors when CuckooAutoinstall will install the necessary dependencies, like this error on Ubuntu:


Updating the script with your VM settings is easy, these are the parameters you can change:





Then execute the script as root. It will take about 15 minutes to execute, depending on your Internet speed and size of your VM. If you are interested in seeing the progress of the script step by step, use option –verbose.


When the script finishes execution, you want to see only green check-marks:


Testing your Cuckoo installation
To start Cuckoo, you execute the script created by CuckooAutoinstall for you:



Then you can use a web browser to navigate to port 8000 on the machine where you installed Cuckoo:


Submit a sample, and let it run:



After a minute, you’ll be able to view the report. Make sure you do this, because if you get the following message, your guest VM is not properly configured for Cuckoo:


The best way to fix issues with your guest VM, is to log on with the cuckoo user (credentials can be found & modified in the CuckooAutoinstall script), start VirtualBox and launch your VM from the “clean” snapshot.



Once you have troubleshooted your VM (for example, fix network issues), you take a snapshot and name this snapshot “clean” (and remove the previous “clean” snapshot). Then try to submit again (for each analysis, Cuckoo will launch your VM from the “clean” snapshot).

This will give you a report without errors:


Although installing Cuckoo can be difficult, the CuckooAutoinstall script will automate the installation and make it easy, provided you configured your guest VM properly. We plan to address the configuration of your guest VM in an upcoming blog post, but for now you can use Cuckoo’s recommendations.

It is possible to install Cuckoo (with CuckooAutoinstall) on Ubuntu running in a virtual environment. We have done this with AWS and VMware. There can be some limitations though, depending on your environment. For example, it could be possible that you can not configure more than one CPU for your Cuckoo guest VM. As there are malware samples that try to evade detection by checking the number of CPUs, this could be an issue, and you would be better off using a physical Cuckoo install.

Want to learn more? Please do join us at one of the upcoming SEC599 SANS classes, which was co-authored by NVISO’s experts!

About the authors
Didier Stevens is a malware expert working for NVISO. Didier is a SANS Internet Storm Center handler and Microsoft MVP, and has developed numerous popular tools to assist with malware analysis. You can find Didier on Twitter and LinkedIn.

Erik Van Buggenhout is a co-founder of NVISO with vast experience in penetration testing, red teaming and incident response. He is also a Certified Instructor for the SANS Institute, where he is the co-author of SEC599. You can find Erik on Twitter and LinkedIn.

Creating custom YARA rules

In a previous post, we created YARA rules to detect compromised CCleaner executables (YARA rules to detect compromised CCleaner executables). We will use this example as an opportunity to illustrate how the creation of these custom YARA rules was performed.

In its blog post, Talos shared 3 hashes as Indicators Of Compromise (IOCs):


Although not explicitly stated in the Talos report, these are SHA256 hashes. We can infer this from the length of the hexadecimal strings. A hexadecimal character represents 4 bits, hence  64 hexadecimal characters represent 256 bits.

Admittedly, YARA is not the best tool to scan files with hashes as IOCs. YARA is designed to use pattern matching to scan malware, and early versions of YARA did not even have the capability to use cryptographic hashes. In later versions, a hash module was introduced to provide this capability.

A simple rule to match files based on a SHA256 IOC can be implemented like this:

import "hash"</p>
<p style="text-align:justify;">rule simple_hash_rule {
hash.sha256(0, filesize) == "1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff"

Line 1 imports the hash module, which we need to calculate the SHA256 value of the content of a file.

The rule simple_hash_rule has just a condition (line 5): the SHA256 value of the content of the file is calculated with method call hash.sha256(0, filesize) and then compared to the IOC as a string. Remark that string comparison is case-sensitive, and that the cryptographic hash functions of the hash module return the hash values as lowercase hexadecimal strings. Hence, we have to provide the IOC hash as a lowercase string.

Using this simple rule to scan the C: drive of a Windows workstation in search of compromised CCleaner executables will take time: the YARA engine has to completely read each file on the disk to calculate its SHA256 value.

This can be optimized by writing a rule that will not hash files that can not possibly yield the hash we are looking for. One method to achieve this, is to first check the file size of a file and only calculate the SHA256 hash if the file size corresponds to the file size of the compromised executable.

This is what we did in this rule:

import "hash"</p>
<p style="text-align:justify;">rule ccleaner_compromised_installer {
filesize == 9791816 and hash.sha256(0, filesize) == "1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff"

In this rule, we first compare the filesize variable to 9791816 and then we calculate the hash. Because the and operator uses lazy evaluation, the right-side operand will only be evaluated if the left-side operator is true. With this, we achieve our goal: only if the filesize is right, will the SHA256 hash be calculated. This will speed up the scanning process by excluding files with the wrong file size.

There is one caveat though: Talos did not report the file sizes for the IOCs they published. However, we were able to obtain samples of the compromised CCleaner files, and that’s how we know the file sizes.

If you are not in a position to get a copy of the samples, you can still search the Internet for information on these samples like the file size. For example, this particular sample was analyzed by Hybrid Analysis, and the file size is mentioned in the report:

You can also find information for this sample on VirusTotal, but the analysis report does not mention the exact file size, just 9.34 MB.

This information can still be used to create a rule that is optimized for performance, by accepting a range of possible file size values, like this:

import "hash"</p>
<p style="text-align:justify;">rule filesize_and_hash {
filesize &amp;gt;= 9.33 * 1024 * 1024 and filesize &amp;lt;= 9.35 * 1024 * 1024 and hash.sha256(0, filesize) == "1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff"

This rule will first check if the file size is between 9.33MB and 9.35MB (1024 * 1024 is 1 MB) and if true, then calculate the hash.


Writing custom YARA rules is a skill that requires practice. If you want to become proficient at writing your own YARA rules, we recommend that you embrace all opportunities to write rules, and step by step make more complex rules.

About the author

Didier Stevens is a malware expert working for NVISO. Didier is a SANS Internet Storm Center handler and Microsoft MVP, and has developed numerous popular tools to assist with malware analysis. You can find Didier on Twitter and LinkedIn.


“We are happy to share our knowledge with the community and thus hope you enjoyed the content provided on this article! If you’re interested in receiving dedicated support to help you improve your cyber security capabilities, please don’t hesitate to have a look at the services NVISO offers! We can help you define a cyber security strategy / roadmap, but can also offer highly technical services such as security assessments, security monitoring, threat hunting & incident response ( Want to learn similar techniques? Have a look at the SEC599 SANS class, which was co-authored by NVISO’s experts! (”

Windows Credential Guard & Mimikatz

Here at NVISO, we are proud to have contributed to the new SANS course “SEC599: Defeating Advanced Adversaries – Implementing Kill Chain Defenses”.

This six-day training focuses on implementing effective security controls to prevent, detect and respond to cyber attacks.

One of the defenses covered in SEC599 is Credential Guard. Obtaining and using credentials and hashes from memory (for example with Mimikatz) is still a decisive tool in the arsenal of attackers, one that is not easy to defend against.
With Windows 10 and Windows Server 2016, Microsoft introduced a feature to mitigate attacks to obtain credentials and hashes: Credential Guard. With Credential Guard, secrets are stored in a hardened and isolated section of your computer, inaccessible from the normal operating system.

Credential Guard relies on a new technology introduced with Windows 10 and Windows Server 2016: Virtual Secure Mode (VSM). VSM is based on the virtualization features of modern CPUs to provide a separate memory space where secrets can be stored. This separate memory space is protected (via hardware) from read and write attempts from processes in the normal operating system’s memory space.

When Credential Guard is enabled, the Local Security Authority Subsystem Service (LSASS) consists of 2 processes: the normal LSA process and the isolated LSA process (which runs in VSM).

Credential Guard

SANS SEC599 day 4: Credential Guard

Tools that recover secrets from LSA, like Mimikatz, are not able to access the isolated LSA process. They cannot extract passwords or inject hashes for pass-the-hash attacks, for example. Hence, Credential Guard is an effective tool to protect credentials stored on Windows machines.

Despite Credential Guard, users with administrative access can still find ways to steal credentials entered on Windows machines. This can be done, for example, with Mimikatz own Security Support Provider. SSPs are packages that participate in the authentication of users: for example, installed SSPs will be called when a user logs on, and will receive the credentials of said user. Windows comes with several SSPs , and custom SSPs can be installed (of course, this requires administrative permissions).

Mimikatz memssp command (available since September 2014) installs a custom SSP in memory (so no DLL is written to disk), that will log all credentials it receives in a text file.

To achieve this, Mimikatz needs to be executed with administrative rights on the target machine and the debug privilege needs to be enabled to allow the LSA processes to be opened and patched:


Next, Mimikatz’s SSP is injected with the misc::memssp command:


Now the SSP is installed, Mimikatz can be closed. This SSP will remain in memory as long as Windows is not rebooted.

After a user has performed a log on, Mimikatz’s SSP log C:\Windows\System32\mimilsa.og file can be examined to retrieve the credentials processed by Mimikatz’s SSP:



Mimikatz can not extract credentials protected by Credential Guard, but it can intercept credentials entered in a Windows machine at log on time, for example. Although Credential Guard will protect credentials in isolated memory, credentials still need to be provided to a Windows machine (like for an interactive logon).

When these credentials are typed, they can still be intercepted and stolen, e.g. with a key logger or with with a custom SSP, as illustrated here. This is however only one of the steps in the attack chain, as this requires administrative rights, it is crucial to restrict and monitor administrative access to your Windows machines.

New year, new vulnerabilities: Spectre & Meltdown

Two new vulnerabilities “Spectre” and “Meltdown” were recently discovered, affecting millions of systems worldwide. Please find our security advisory below.

spectre                                                     meltdown 

Spectre and Meltdown are hardware vulnerabilities in the microprocessors (CPUs) that, when exploited, allow an attacker to read the content of memory he/she is not allowed to access. Some key things to know about these vulnerabilities:

  • Proof of concept code for Meltdown demonstrates that a low privilege user process can read all kernel memory from major operating systems on Intel CPUs;
  • Proof of concept code for Spectre demonstrates that a low privilege user process can read memory from other processes on all major operating systems on CPUs from all major vendors;
  • Spectre and Meltdown attacks can be used to break through security boundaries implemented by operating systems to steal confidential data, including passwords and secret keys;
  • Patches are already available for the mitigation of Meltdown;
  • Long-term solution will consist of redesigning the CPU infrastructure by the vendors.

How does it work?
Both vulnerabilities rely on exploiting side-effects of “out-of-order execution” and “speculative execution”.

  • Out-of-order execution is a performance feature of CPUs that allows for non-sequential execution of machine instructions. Instead of executing machine instructions step by step in the order specified by the program (like old fashioned CPUs do), CPUs nowadays speed up execution of programs by simultaneously executing several machine instructions of the program, but not necessarily in the order specified by the program (this is called out-of-order execution).
  • Speculative-execution takes this concept further, and executes instructions that may actually not have to be executed. The instructions are executed before it is known that they have to be executed (this is done to maximize the utilization of the CPU). The implication is that machine instructions are being executed that ultimately should not have been executed, for example because a conditional branch is taken. The results of these “unnecessary” machine instructions are discarded.

The Spectre and Meltdown vulnerabilities leverage these discarded results.

The Spectre vulnerability (CVE-2017-5715 and CVE-2017-5753) is actually a class of vulnerabilities in CPUs that implement speculative-execution, and more precisely branch-prediction (Meltdown is considered to be a particular case of Spectre). Branch-prediction is implemented by the CPU circuits that try to predict which branch of a conditional execution will be executed. The branch with the highest probability of execution is executed via out-of-order execution. Exploiting Spectre relies on the fact that the branch-prediction circuitry can be manipulated (by exploit code) to assign a higher probability on a chosen branch. Spectre exploits will search for branches that access memory that is outside of the security context of the running exploit (hence not allowed to be read), and then manipulate the branch-prediction algorithms to execute these branches out-of-order. But because the results of these instructions are discarded (the branches would not have been executed in a sequential execution), Spectre exploits have to use side-channels attacks to recover the discarded results. A side effect of out-of-order execution is that memory content is loaded into cache-lines. The side-channel attack relies on the timing of instructions to determine what data was loaded into the cache-lines: an instruction will execute faster if the data it requires is already in the cache-line.

The exploitation of the Meltdown vulnerability (CVE-2017-5754) relies on a privilege escalation vulnerability in Intel CPUs (this privilege escalation vulnerability exists in most Intel CPUs since 1995). An exploit for the Meltdown vulnerability will execute an instruction that causes a trap. Because of this trap, the results of instructions that were executed out-of-order are discarded. Next, the exploit will use an Intel privilege escalation vulnerability to access the results of the discarded instructions. In proof of concepts, the discarded instructions are used to read kernel memory. This should not be allowed by code running inside a user-land process, but this security decision is only taken after the out-of-order execution. Consequently, the combination of a trap and privilege escalation can be used to read memory that is normally not accessible to the code.

What is the impact?
Meltdown impacts workstations, laptops, servers (also cloud servers) running Linux, Windows or macOS.

Spectre impacts workstations, laptops, servers (also cloud servers), smartphones, tablets,… Virtually any device that runs on vulnerable CPUs from Intel, AMD and ARM.

What should we do?
At the time of writing this advisory, there are no patches available to mitigate the Spectre vulnerability.

Patches have been released for Windows, Linux and MacOS to mitigate the Meltdown vulnerability in Intel CPUs. These are patches for the kernel that implement Kernel Page-Table Isolation (KPTI, also known as KAISER). KPTI mitigates the Meltdown vulnerability by completely separating user-space and kernel-space page tables. Before this patch, user-space and kernel-space page tables were not separated for performance reasons. Reports exists that KPTI impacts performance, some speculating up to 30% loss in CPU performance.

We recommend to execute performance tests with these patches on high-load machines before deploying these patches in production.

NOTE: Microsoft published information that some anti-virus products are not compatible with their patches, and may cause a BSOD (Blue Screen Of Death). So before installing updates, check with your AV vendor first. (

Exploiting the Spectre and Meltdown vulnerabilities requires code execution on vulnerable CPUs. Until these vulnerabilities have been completely addressed, strict control of code execution (like application whitelisting) can help mitigate attacks for these vulnerabilities. Be aware that proof of concepts are already available for Spectre and Meltdown, written in JavaScript. Control of code execution must not only address binary executables, but also scripting.

Ultimately, the Spectre and Meltdown vulnerabilities have to be addressed by redesigning CPU architectures. As a typical CPU release cycle takes 18 months, this implies that it will take several years before new CPUs are produced and widely deployed.

Update 05/01/2018:

There are now 2 tools available to check Windows systems for these vulnerabilities. Microsoft has released a PowerShell script (SpeculationControl) and Alex Ionescu has released a Windows executable (SpecuCheck).

Here is the output of Get-SpeculationControlSettings on an unpatched machine:

Here is the output of Get-SpeculationControlSettings on an patched machine (Windows patches):

As you can see, mitigation for the Meltdown vulnerability (CVE-2017-5754) is present in the OS and activated, and (partial) mitigation of the Spectre vulnerability (CVE-2017-5715) is present in the OS but not activated. It can only be activated when a required firmware updated has been installed. You will need to get this firmware update from your OEM (provided they plan to release a firmware update for your machines).

Update 09/01/2018:

Microsoft did not release microcode updates (to update your CPU) with their monthly patches. You will have to do this with a firmware update from your OEM (several OEMs have already released new firmware). Red Hat did release a microcode update for CVE-2017-5715.

More information?
NVISO analysts are still working on additional research and will update this blogpost with any results.

Should you require additional support, please don’t hesitate to contact our 24/7 hotline on +32 (0)2 588 43 80 or

If you are interested in receiving our advisories via our mailing list, you can subscribe by sending us an e-mail at

Other references:


Hack Our Train

This year, in an effort to raise awareness about IoT security, we launched the Hack Our Train challenge. For over three weeks, a model train tirelessly chugged on its tracks inside our IoT village at Co.Station Brussels and then once more for two days at BruCON 2017. We provided it with an emergency brake system powered by IoT technologies and challenged people to hack it and stop the train! With every successful hack, the train stopped, creating a service disruption. A live-stream allowed hackers to monitor the effects of their attacks.

The Hack Our Train challenge was actually composed of two parts: a local one, situated close to the IoT village and then its online counterpart. The local challenge did not require any specific technical skills. It invited people to try and break the pin of the controller that activates the emergency brake mechanism. Check out this video of people having fun with the controller:

But, the online part is where things became really interesting! Over the course of the challenge, only a handful of people succeeded in figuring it out and remotely stopped the train… In this post, we’ll provide a walk-through of the challenge and focus on some of the vulnerabilities featured in it and, more importantly, on ways to fix them.

Hunt for the firmware

On the challenge website, we provided aspiring hackers with the following scenario: Bob, one of the IoT village’s railroad technicians, recently had to update the emergency brake panels. Unfortunately Bob left his USB flash drive laying around and Eve found it and made its content available online!

The first step is to analyze the USB’s contents. It is a zip archive containing two files: firmware.enc, which conveniently hints to the encrypted firmware and a binary file called firmware_updater. The firmware updater is used to decrypt the firmware and then upload it to the control panel via a serial connection.

If we execute it on a Linux machine, the firmware_updater asks us for a pin before decrypting the firmware. People who braved the challenge came up with all sorts of clever ways of cracking the firmware_updater binary and forcing it to decrypt the firmware.

For now, we will resist the temptation of breaking out our dissassemblers and debuggers and we will just look at the strings inside the updater. There are some really interesting parts:



If we think this out (of course, dissassembling would make this much easier), the firmware seems to be encrypted using AES. To perform the decryption ourselves, we would need the key and the initialization vector (IV). Luckily, these are hard-coded into the firmware (see image above).

So, we just need to turn those into their hexadecimal counterparts and we are set:

> openssl enc -aes-128-cbc -d -in firmware.enc -out firmware -iv 766563353667647639396e6e73647161 -K 686f746b3138313965663132676a7671

Vulnerability: use of hardcoded cryptographic keys.

Fix: if possible, avoid using schemes that require hardcoded keys. If using a hardcoded key is unavoidable, there are techniques that can be employed to make the key harder to recover. Ideally, decryption should be performed directly on the embedded device, which avoids the need to expose the key in the firmware updater.

One last word on the update procedure we just cracked: now that we have the keys, no one can stop us from modifying the decrypted firmware to add or remove some functionalities, encrypting it again and uploading it to the device. The emergency controller would have no means of knowing if the firmware has been tampered with.

Vulnerability: firmware not digitally signed.

Fix: Digitally sign the firmware so that the embedded device can verify its authenticity.

Inside the firmware

Phew, we have the firmware, now comes the hard part: we have to reverse engineer it and find a way of remotely trigger the emergency brake mechanism.

Using the file command on the firmware reveals it is in fact a Java archive. This is really good news: using a Java decompiler, we can easily recover the source code.

Vulnerability: code is easy to reverse engineer. Attackers have easy access to the internal workings of the application, which makes it easier for them to find exploits.

Fix: use a code obfuscation tool – there are many available online, both free and commercial. Once you have used the tool on your code, test your application to make sure that it is still functioning correctly. Remember that obfuscation is not a silver bullet but it can drastically increase the effort required for an attacker to break the system.

Before looking at the code, let’s try running the firmware. We are greeted with a status page containing a button to initiate an emergency brake, but we need a pin.


A quick look inside the source code reveals that it is simply “1234”. We have managed to unlock the button. Spoiler: it doesn’t work!

Vulnerability: use of hardcoded passwords.
In our scenario, the password was of no immediate use. Still, this would be harmful if we ever had access to a real emergency brake controller.

Fix: if the password must be stored inside the application, it should at least be stored using a strong one-way hash function. Before hashing, the password should be combined with a unique, cryptographically strong salt value.

In order to understand what is going on, we can simply look at the debug messages conveniently left behind in the console. Seems like the protocol used is MQTT and for some reason, we receive an authentication failure error when we try to perform an emergency brake.

Vulnerability: leftover debug messages containing useful information.

Fix: scan your code for forgotten prints (system.outs in our case) and remove them before release, or disable them at runtime.

Look below the hood

Before going further, let’s take a step back and have a closer look at the architecture of our system. This step was of course not needed to solve the challenge but we thought it complements nicely to this walk-through!

As we just discovered by looking at the source code, communication is based on the MQTT protocol, often found among IoT applications. MQTT works on top of TCP/IP and defines two kinds of entities: Subscribers and Publishers. Publishers send messages on communication channels called Topics. Subscribers can register and read messages on specific Topics. These messages are relayed with the help of a server (also called a Broker).


This is a look below the hood of the mountain (this was our beta setup, our final circuit was much cleaner!). Two elements steal the show: an Arduino and a Raspberry Pi. The Arduino is the muscle: it controls the transistor that stops the train. The Pi is the brains: when it receives an emergency brake message, it orders the Arduino to stop the train.

Both the emergency brake controller (where the firmware runs – it is not shown in the picture) and the Raspberry Pi (shown in the picture) are connected to the internet. They communicate with the MQTT Broker to exchange MQTT messages. The Pi publishes messages concerning the train’s speed but it is also subscribed to a topic waiting for emergency brake messages. The controller displays the train’s current speed and, when the emergency brake is activated, it publishes an emergency brake message that the Broker relays to the Pi.

Of course, not anyone can send an emergency brake message to the server. In our infrastructure, authentication is based on JWT tokens. These are issued by the server relaying the MQTT messages and they are signed using the server’s private key. When  clients try to authenticate using one of those tokens, the server can verify their authenticity using its public key.

To clear all this up, we have created an overview of the MQTT communications going on in the images below:



Tokens, tokens everywhere…

Back the authentication problem. Digging into the source code confirms that authentication is JWT token based. Maybe there is something wrong with the token? Another file inside the JAR that immediately draws our attention is notes.txt. A quick look reveals some notes of a developer that was worried about his JWT token expiring. We can easily verify the creation date of the token here. Seems like out token is really old and as we don’t have the authentication server’s private key, we cannot create a new one.

Vulnerability: old and unused left behind files containing sensitive information.

Fix: before publishing your product, make sure to remove every non-essential ressource.

Knowing how the authentication works, it is time to turn to our favorite search engine for more intelligence. Let’s try jwt token vulnerability. The top result states “Critical vulnerabilities in JSON Web Token libraries“: perfect!

The author does a great job of explaining the vulnerability and how it can be exploited, so we leave you in his hands. For the purposes of this post, the idea is that if we create a forged token using the authentication server’s public key as a HMAC secret key, we can fool the server into verifying it using HMAC instead of RSA, which results in the server accepting our token.


Having identified the vulnerability, it is time to perform our attack. For that, we need the server’s public certificate, which is kindly included in the JAR as well. As mentioned in the notes file, it has been converted to a format compatible with Java but the server is more likely using it in PEM format.

Luckily, converting it back is easy:

> keytool -importkeystore -srckeystore hot.ks -destkeystore temp.p12 -srcstoretype jks -deststoretype pkcs12
> openssl pkcs12 -in temp.p12 -out public.pem


Next, we have to create our malicious token. You can do this in the language of your choice. We used the jwt-simple node.js module.

With the malicious token crafted, we can finally perform the attack. The easiest way is to reuse the code included in the file, conveniently forgotten inside the JAR. We just have to replace the token found in the code, compile the code and execute it from the terminal.

The select few who made it this far in the challenge saw the train stop on the live-stream and received the flag!

Vulnerability: using components with known vulnerabilities.

Fix: apply upgrades to components as they become available. For critical components (for example, those used for authentication), monitor security news outlets (databases, mailing lists etc.) and act upon new information to keep your project up to date.

Lessons learned

Our challenge involved a toy train but the IoT vulnerabilities demonstrated inside are the real deal. We added each one of them to the IoT challenge because we have come across them in the real world.

On a final note, we would like to congratulate those who were able to hack our train and we sincerely hope that all of you enjoyed this challenge!


A new vulnerability in the WPA2 protocol was discovered by Mathy Vanhoef (researcher at KU Leuven) and published yesterday. The vulnerability – dubbed  “KRACK” – enables an attacker to intercept WPA2 encrypted network traffic between a client device (e.g. mobile or laptop) and a router. Depending on the network configuration it is even possible for an attacker to alter or inject data. Since the vulnerability lies in the WPA2 protocol, most platforms are susceptible to the attack. However, the impact is even higher on Android 6.0+ and Linux devices due to their specific implementation of WPA2.

The original publication can be found at, with full details, a demonstration of the attack, and recommendations.

How does it work?

The KRACK vulnerability can be exploited by using Key Reinstallation AttaCKs. When a device wants to connect to a wireless access point, the WPA2 protocol will use a 4-way handshake. Part of this handshake consists of an acknowledgment that is sent from the client device to the wireless access point to ensure the client has successfully received the signed key. However, until the wireless access point has received the acknowledgment, it will continuously retransmit the signed key. If the attacker is able to block the acknowledgement from being sent to the wireless access point, the attacker is able to record and replay the signed key, which ensures the reinstallation of an already used key on the client’s device. As soon as the key is installed, it will be used to encrypt the network traffic between the client and the wireless access point. Since the attacker knows the keystream, he is able to decrypt the network traffic.

Since this attack exploits a vulnerability in the four-way handshake, all WPA versions are vulnerable.

Are all devices vulnerable?

Since this vulnerability is found in the WPA2 protocol, all platforms, such as Windows, Linux, MacOs, iOs, OpenBSD and Android can be targeted. Linux and Android 6.0+ devices are especially vulnerable, because the WiFi client will clear the encryption key from memory after installation. If the Android device is told to reinstall they key, the cleared out key will be installed, which is actually an all-zero key. This makes it trivial for an attacker to intercept and inject or alter data sent by these devices.

Does this mean that we need to stop using WPA2?

Although an attacker is able to intercept traffic and in some cases traffic can be altered or injected, this attack can only be performed when the attacker is in close proximity of the client’s device and wireless access point.

If the attacker has successfully exploited this vulnerability, traffic over TLS, such as HTTPS or VPN traffic, will not be accessible to the attacker.

What should we do? 

When this vulnerability was discovered, it was first disclosed to various vendors. Many vendors (e.g. Microsoft, Cisco) have already released patches for this issue. Install the available patches on all your devices or contact your vendors to see if a patch is available. A list with all patches per vendor can be found on

Furthermore, it is strongly advised to only use encrypted connections, such as HTTPS or a VPN connection, when sensitive content is transmitted over WiFi networks.

Additionally, watch out for rogue access point in your surroundings, office buildings.

More information? 

NVISO analysts are still working on additional research and will update this blogpost with any results.

Should you require additional support, please don’t hesitate to contact our 24/7 hotline on +32 (0) 588 43 80 or

If you are interested in receiving our advisories via our mailing list, you can subscribe by sending us an e-mail at

YARA rules for CCleaner 5.33

First reported by Talos and Morphisec, the compromise of CCleaner version 5.33 is still making news.

At NVISO Labs, we created YARA detection rules as soon as the news broke, and distributed these rules to our clients subscribed to our NVISO Security Advisories. In a later blog post, we will explain in detail how to create such YARA rules, so that you can do the same for your organization.

Here are the YARA rules we created:

// YARA rules compromised CCleaner
// NVISO 2017/09/18

import "hash"

rule ccleaner_compromised_installer {
		filesize == 9791816 and hash.sha256(0, filesize) == "1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff"

rule ccleaner_compromised_application {
		filesize == 7781592 and hash.sha256(0, filesize) == "36b36ee9515e0a60629d2c722b006b33e543dce1c8c2611053e0651a0bfdb2e9" or
		filesize == 7680216 and hash.sha256(0, filesize) == "6f7840c77f99049d788155c1351e1560b62b8ad18ad0e9adda8218b9f432f0a9"

rule ccleaner_compromised_pdb {
		$a = "s:\\workspace\\ccleaner\\branches\\v5.33\\bin\\CCleaner\\Release\\CCleaner.pdb" 
		$b = "s:\\workspace\\ccleaner\\branches\\v5.33\\bin\\CCleaner\\ReleaseTV\\CCleaner.pdb" 
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and ($a or $b)

You can scan the C: drive of a computer with YARA like this:

yara64.exe -r ccleaner.yara C:\

And there are also many other scanning tools that include the YARA engine, like ClamAV.


The first 2 rules we created are hash based, but the third rule (ccleaner_compromised_pdb) is based on a particular string found in CCleaner’s 32-bit executables. This string is the full path of the Program Database (PDB) file, a debug file created by default by Visual Studio and referenced in compiled executables.

With this rule, we were able to identify 235 files on VirusTotal. Most of these are actually container files (like ZIP files): CCleaner is a popular application, and is distributed through various channels other than Piriform’s website. We saw examples of portable application packages distributing this compromised version of CCleaner (like LiberKey) and also RAR files with pirated versions of CCleaner.

23 files were actual executables, and were all compromised versions of the 32-bit executable of CCleaner version 5.33, except one. Most of these files did not have a (valid) signature: they were modified versions, e.g. cracked and infected with other malware.

Only one executable detected by our ccleaner_compromised_pdb rule was not infected: an executable with SHA256 hash c48b9db429e5f0284481b4611bb5b69fb6d5f9ce0d23dcc4e4bf63d97b883fb2. It turns out to be a 32-bit executable of CCleaner version 5.33, digitally signed on 14/09/2017, e.g. after Talos informed Avast/Piriform. The build number was increased with one (6163 instead of 6162). This executable was signed with the same certificate that was used for the compromised version 5.33 (thumbprint f4bda9efa31ef4a8fa3b6bb0be13862d7b8ed9b0), and also for follow-up version 5.34. Yesterday (20/9/2017), Piriform finally released a new version (5.35) signed with a new digital certificate obtained yesterday.

At this moment, we are uncertain about the origins and purpose of this particular executable (c48b9db429e5f0284481b4611bb5b69fb6d5f9ce0d23dcc4e4bf63d97b883fb2).

Are you infected?

Our rules allow you to detect compromised CCleaner executables in your environment, but this does not imply that the machines identified by these rules were infected.

Our analysis shows that the compromised CCleaner installer (version 5.33) will install 32-bit and 64-bit versions of the CCleaner executables on a Windows 64-bit machine, and only the 32-bit version on a Windows 32-bit machine.

The shortcuts (like Start and Desktop shortcuts) deployed during the install on Windows 64-bit machines will point to the 64-bit executable, hence normal usage on a Windows 64-bit machine will execute 64-bit CCleaner.

Only the 32-bit executable of CCleaner is compromised.

It is therefore perfectly possible that compromised 32-bit executables of CCleaner are detected on Windows 64-bit machines with the YARA rules we provided, but that this compromised version was never executed.

If the compromised 32-bit executable runs successfully, it will create the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Piriform\Agomo

Two values will be found for this key: MUID and TCID


We recommend that you check for the presence of this registry key, should our YARA rules detect compromised CCleaner installations on your machines.

Compromised machines should be reinstalled after a DFIR investigation.