Author Archives: sasjareynaert

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:


To Petya or not to Petya

On June 27, 2017, we were informed via several channels that attackers launched a new type of ransomware. This cyber-attack affects companies across Europe and the US. The attack has some similarities with a previous attack known as “Wannacry”, but it has some distinct features.

The advisory below has been sent out to all our clients on the night of the attack.

The goal of the attack remains the same: Hijacking the system by encrypting files (and the Master Boot Record, rendering the system unusable) and asking for a ransom.

Update: Although the attack is qualified as a ransomware attack, the infected systems are hijacked by encrypting files and the Master Boot Record in exchange for a ransom, the goal of the attack does not seem to be making money, but to destroy as many systems as possible. This due to the fact that the attack itself was sophisticated, but the way the ransom needs to be paid ( 1 bitcoin address for all infections and 1 e-mail address to send a proof of transaction to) is more amateuristic.

Short Description

During our first analysis, we noticed that this attack is using several techniques to spread. When executed, it starts to encrypt files on the local system and attempts to spread across the internal network. The initial attack vectors that are used are under investigation, however; external resources identified and confirmed that the ransomware includes the following exploits:

  • A modified EternalBlue exploit (SMB), also used by WannaCry;
  • The EternalRomance exploit (SMB) – a remote code execution exploit targeting Windows XP to Windows 2008 systems over TCP port 445 (Note: patched with MS17-010);
  • An attack against the update mechanism of a third-party Ukrainian software product called MeDoc.

In comparison with “Wannacry” this could have a greater impact on corporate networks because once an internal host is infected, the ransomware will attempt to further infect internal systems via common Windows administration services (thus possibly also affecting patched systems as a second stage in the attack). As usual with ransomware, the attack is not targeted and is attempting to affect as many systems as possible.

How does the ransomware spread once the initial infection has taken place?
We can confirm that the ransomware is using WMI (Windows Management Instrumentation) and PSEXEC to infect other internal systems once the initial infection has taken place. The sample we analyzed has PSEXEC version 1.98 embedded and uses the Windows API function and ARP scanning to get a list of remote IP addresses of all TCP connections on the infected machine. All addresses it identifies it will then also attempt to infect (using the aforementioned PSEXEC & WMI).

Using WMI & PSEXEC, the ransomware can “ride” on the available user context (e.g. if the ransomware is executed with domain administrator credentials it will be able to affect the entire domain, regardless of patch levels). Provided the malware has the necessary rights, it will drop and execute a password extractor tool based on Mimikatz (stored in resources 1 (32-bit) and 2 (64-bit)) and leverage the extracted credentials for lateral movement with PSEXEC and WMI.

Encryption techniques

Multiple encryption techniques are being used based on the user privilege it has during execution:

  • When executed with administrative rights, the ransomware will encrypt the entire disk and will overwrite the (MBR) Master Boot Record.
  • If the ransomware has normal user privileges it will locate specific file types and will start to encrypt these files on the local system.

After a period of time (1 hour), a scheduled task will force the infected client to restart, thereby presenting the victim with a ransom screen including a bitcoin address together with a string of text as well as the email address to contact the authors when the payment was executed.

Is there a killswitch?

There are currently a few pointers that the ransomware could be halted by by creating a DLL file with a specific name in the C:\Windows. We are currently further investigating this.

Update: Yes! Our analysts found out that the presence of the file c:\windows\perfc will stop the malware from executing. This has been confirmed by Kaspersky and Microsoft.

Detection mechanisms

As opposed to WannaCry, this ransomware is not using command and control channels to communicate to the attacker environment (and thus no random domain names that could be used as kill switches). The detection of infected hosts cannot be done via monitoring outgoing connections because the ransomware does not appear to perform any outbound connectivity.

Detection should be mainly focused on internal monitoring (e.g internal firewall) and looking into the abnormal management traffic that is started via PSEXEC or WMI sessions (e.g. the use of PSEXEC creates a PSEXEC service as an artefact on target systems).

How to defend against this ransomware

In order to defend against this ransomware the following are key recommendations to keep into account:

  • Ensure Microsoft’s patch (MS17-010) is rolled out throughout your organisation (also in the internal network) to prevent the spread of the malware using the SMB exploit;
  • Ensure Windows SMB services (typically TCP port 445) are not directly exposed to the Internet;
  • Review and monitor the internal network on anomalies in management traffic that starts via PSEXEC and WMI;
  • Review internal hosts for the creation of scheduled tasks or the PSEXEC service;
  • Implement network segmentation and restrict access between systems on the internal network. In larger corporate networks, management traffic is only allowed via a dedicated out-of-band network.
  • Upon infection: isolate any infected hosts from the network;
  • Continue end-user awareness to prevent possible initial compromise through phishing (not confirmed);
  • Implement mail sandboxing solutions to block incoming malicious mail attachments.

More information?
More technical blog posts will be released here in the coming days!

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 to

A practical guide to RFID badge copying

During red teaming assignments we are sporadically asked to attempt to gain access to certain physical “flags”. These flags could be the inside of a server room, or the workstation of a member of the management team.

Aside from these red teaming assignments, in most organisations, access badges are often the single factor of security that stands between us and the inside of a building, a server room or an office. There are many different RFID card reading systems on the market. Unfortunately, the security they provide is often lacking. With this blog post we want to demonstrate how easy it is to bypass the card reader security mechanism when it is insufficiently secured.

Specialised hardware is required to clone existing RFID cards, this hardware can easily be obtained and is relatively inexpensive. For this case study, we use the Proxmark3, which is a device developed by Jonathan Westhues that allows sniffing, reading and cloning of RFID (Radio Frequency Identification) tags.

DISCLAIMER: This blog post, and by extent any other blog post written by NVISO LABS, are intended for educational purposes only. It is not intended and should not be used for the illegitimate cloning of RFID badges without prior permission.


Cloning and abusing the card

Below we’ll provide a step by step example on how to clone an HID global RFID card. Note that the Proxmark3 is able to copy many different types of cards.

We have two types of antennas that we can connect to our Proxmark3: a low frequency one and a high frequency one. The low frequency card, operating at 125kHz and 134kHz, can communicate with e.g. HID Prox II, HITAG, and EM4100 tags. The high frequency card, operating at 13.56Mhz, can communicate with e.g. Mifare Classic/Ultralight and iClass tags.

After starting up the proxmark3 interface, we can run the“hw tune”command to see if any card is detected. Currently the LF antenna is connected to the Proxmark3 and at this point there is no card in the presence of our LF antenna.


When repeating the “hw tune” command, this time with the card within reach of our antenna, we see a clear difference in voltage in comparison with the previous screenshot. This indicates we are dealing with a low frequency card.


Our next step is finding the type of card we have. Using the “lf search” command we can scan the card. Before executing this command, make sure the card is already on the antenna. If not, the search command will return errors.


The proxmark3 confirms we are working with a HID global RFID card and we discover its ID: 07848XXXX (redacted). Now we need to use the according command to clone the card.

Using the Proxmark3 help function for the HID cards, we see we can use the clone function.


The T55x7 you see in the output above, is a type of card that is extremely versatile and supports multiple encoding formats of the majority of 125 Khz RFID tag transponders. We can thus use this type of card to emulate our HID card.


After executing the command above, including the HID Prox TAG ID identified in the previous steps, we have successfully cloned our card.

That’s all it takes!  Check the video below for proof.

On a final note, when your office building is protected by such an insecure card reading system, often the only solution to fix this vulnerability is to replace the card reading infrastructure and all access badges. Needless to say this will have a significant impact on your organisation.

The following recommendations can be made to improve the security:

  • Use of encryption to ensure that the ID is not sent in clear text. Think of challenge response authentication;
  • Use of contactless smart cards which have encryption, mutual authentication and message replay protection incorporated.

Additionally, it is known that attackers try to covertly copy your RFID cards, for example during a trip on the metro. You can try using an RFID protected sleeve/wallet, but research has shown that not all of them are effective at preventing covert copying. Be sure to test yours out and share your findings!