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!

Decompiling py2exe Executables

We had to decompile an executable (.exe) generated with py2exe for Python 3.

py2exe takes a Python program and generates a Windows executable. This .exe file contains the Python bytecode of the program, a Python interpreter and all the necessary modules. The bytecode is stored as a resource inside the .exe file.

unpy2exe will extract the Python bytecode as a pyc file from the .exe file, which can then be decompiled with uncompyle6. Unfortunately, unpy2exe does not support files generated with py2exe for Python 3.

We release our program decompile-py2exe to handle py2exe Python 3 executables. It is simple to use:


decompile-py2exe takes an executable as argument, extracts the Python bytecode and decompiles it with uncompyle6, all in one step. The executable can also be passed via stdin or inside a (password protected) ZIP file. Be sure to use Python 3 to run decompile-py2exe.


PDF Analysis: Back To Basics

When you receive a suspicious PDF these days, it could be just a scam without malicious code. Let’s see how to analyze such samples with PDF Tools.

As always, we first take a look with pdfid:


There’s nothing special to see, but we have to check the content of the Stream Objects (/ObjStm):


Still nothing special to see. This could be a malicious PDF document with a pure binary exploit (e.g. without using JavaScript), but nowadays, it’s more likely that we received a PDF containing links to a malicious website, like a phishing website.

To check for URLs, use option search (-s) to search for the string uri (the search option is not case sensitive):


And indeed we find objects with URIs. These are links tied to a rectangle, thus a zone that must be clicked by the user to “activate” the URL: Adobe Reader will display a warning, and after user acceptance, the default browser will be launched to visit the given URL.

pdf-parser also has an option to select key-value pairs from dictionaries of PDF objects: option -k. This is useful to generate a quick overview. This option is case sensitive, and the full keyname must be provided:


When we open the PDF document with Adobe Reader, we get visual confirmation that it is a phishing PDF:


And this is the phishing website:


Conclusion: if pdfid reports nothing suspicious, before looking for binary exploits (for example with pdf-parser’s YARA support), search first for URIs with pdf-parser.

A 30-minute sweep of Industrial Control Systems in Belgium

TLDR; We found several ICS systems in Belgium that were exposed to the internet without requiring any authentication. Screenshots below.

Update 19/12: We’ve also had some coverage in the media about this research. ‘De Standaard‘ did an article about it and so did ‘Datanews’ (in Dutch and in French).

Industrial Control Systems (ICS) is the general term for electronic control systems used in industrial production. The term encompasses everything from supervisory control and data acquisition (SCADA) to Programmable Logic Controllers (PLC) – often found in industrial and critical infrastructures.

These systems were once state-of-the-art controllers for heavy industry, but nowadays they are included in many HVAC (Heating, Ventilation and Air Conditioning), home automation and even industrial livestock feeding systems. These systems are installed in many corporations – big and small – but also at home.

ICS Security

ICS Security has been a big issue since Stuxnet[1]. Stuxnet was one of the first – and very advanced – malware specifically targeting ICS appliances. Since then, we’ve seen a steady flow of ICS targeted malware, simple and advanced alike[2]. One of the reasons ICS is being heavily targeted, is because of the criticality of the appliances that it controls, but also because most ICS systems have not been designed for security. To make matters worse, many ICS installations are poorly incorporated into existing networks. Today, still many ICS appliances are connected to the internet without any proper authentication. This means that actors with bad intentions could gain access to these critical systems with little to no effort.

Since NVISO is a Belgian company (and thus most of our clients are Belgian or have a Belgian office), we decided to take a quick peek into the security of Belgian ICS systems.

“How many of those systems would we be able to find in Belgium with little effort”, we thought…


In comes Shodan[3]. Shodan is the first search engine for internet-connected devices. It allows you to easily search throughout the internet for specific appliances and protocols. We only used Shodan in throughout this research and have only used simple search syntax.


30 minutes later

Using our knowledge about ICS systems (some vendors, some protocols), we started investigating the Belgian internet-space. The results were worrisome. Within only 30 minutes, we managed to find at least 9 instances of Belgian ICS systems that were connected to the open internet, without requiring authentication. We found heating systems, ventilation systems, building control systems, delivery acceptance systems, home automation systems, camera systems and even an automatic feeding system of a farm.

Next to these ICS systems, we also found a big volume of Belgian Point-of-Sale (PoS) systems. Luckily, almost no Belgian PoS is equipped with a card reader – and thus no credit card details would be retrieved upon compromise – but there’s still a risk here concerning customer’s data. Next to that it could be used as an entry point into the corporate network. Probably not a good idea to have those directly connected to the internet.

All the ICS systems that we found using Shodan, used a VNC server for remote access. TCP/5900 was in open state and authentication was disabled. We have stopped seen these horrible things in corporate environments, but apparently they still exist in the ICS world…


If your ICS system needs to be remotely controlled, we would recommend to use a secure connection towards it (VPN, white listing IP’s, etc.) and enforcing a decent authentication (long and complex password/passphrase, no anonymous login). Since many ICS systems still don’t give you decent authentication out-of-the-box, make sure to put it behind a managed network and enforce decent authentication (and logging!), e.g. by using a jump server.

We will contact all identified companies with our findings and will offer them help with any potential remediation. In Belgium, this sort of ‘notification’ is still in a gray zone, legally speaking. Luckily, the Centre for Cybersecurity Belgium (CCB) is looking into proposing a ‘responsible disclosure’ law[4].

Raise Awareness

With this 30-minute research, we wanted to raise awareness about the criticality of ICS and other internet-attached systems and their lack of security. While companies are slowly but steadily investing more and more into information security, they often overlook ICS systems. Next to the end-user responsibility, we want to stress that a part of the responsibility is to be shared with the vendors and installation companies. We often see that they make no effort to secure these systems or offer no guidelines towards secure installation.

The loot

Disclaimer: We have removed all Personal Identifying Information from the screenshots below. We have not accessed any system; the screenshots were taken by Shodan. All screenshots listed below have been identified as originating from a system located in Belgium.



The interface of a Tolsma storage technology climate control system


The logon screen of a PoS system. While this system requires authentication, these versions of windows embedded often contain multiple vulnerabilities and should not be exposed unfiltered to the internet.


The interface of a building heater system.


The interface of a camera module for the Tolsma Storage Technology appliance.


Again, an interface of a building heater system.


The interface of an intercom system.


The interface of a home automation system.


The interface of a feeding machine for livestock.


The interface of a Tritone Automatic Feeding System.

[1] https://www.wired.com/2014/11/countdown-to-zero-day-stuxnet/

[2] https://www.fireeye.com/blog/threat-research/2016/06/irongate_ics_malware.html

[3] https://www.shodan.io

[4] http://datanews.knack.be/ict/nieuws/ethisch-hacken-bijna-legaal-in-belgie-want-alles-zit-vol-lekken/article-normal-787153.html

Analyzing an Office Maldoc with a VBA Emulator

Today we were informed of another maldoc sample. After a quick look, we were convinced that this sample would be a good candidate for Philippe Lagadec’s VBA emulator ViperMonkey.

The maldoc in a nutshell: when the spreadsheet is opened, the VBA code builds a long JScript script and then executes it. This script contains base64 code for an executable (ransomware Petya GoldenEye version), which is written to disk and executed. The building of the script is done with heavily obfuscated VBA code, so we thought it would be a good idea to try ViperMonkey. ViperMonkey is a free, open-source VBA emulator engine written in Python. You can use it to emulate VBA code on different platforms without MS Office.

Taking a look with oledump.py at this sample (md5 b231884cf0e4f33d84912e7a452d3a10), we see it contains a large VBA macro stream:



Here is the end of the VBA code:


Let’s analyze this with ViperMonkey:

vmonkey.py sample.vir

Since there are a lot of VBA statements, it will take ViperMonkey some time (couple of minutes) to parse this:


In the end we get this result:


ViperMonkey doesn’t identify any suspicious actions, but we see that the ActiveX object to be created is “MSScriptControl.ScriptControl”. This string was obfuscated with Chr concatenations, and ViperMonkey was able to parse it. To parse all obfuscated expressions like this, we provide option -e to ViperMonkey:

vmonkey.py -e sample.vir



We this information, we can understand what subroutine Workbook_Open does: it executes a JScript script stored in variable LQ3.

How to we get the value of LQ3? We can set ViperMonkey’s log level to debug, and log the emulation of all statements. This will produce a lot of output, so it’s beter to redirect this to file.

vmonkey.py -l debug sample.vir > output.log 2> debug.log

Searching for the last occurrence of string “setting LQ3” in debug.log, we find the JScript script:


This script decodes a BASE64 payload, writes it to disk and then executes it: it’s a new variant of Petya ransomware, GoldenEye.



I was handed an interesting PDF document. It doesn’t contain malicious code, yet it generates network traffic. Let me explain how this is achieved.

Creating a PDF that makes a HTTP(S) connection to a website is easy. There’s no need to use an exploit, not even JavaScript. You just have to use a URI object:


On its own, this object will do nothing. An action is needed to have this URI requested. If you want this URI to be requested when the PDF document is opened, you could add an /OpenAction:


Adobe Reader will not let this connection happen silently. The user will be prompted before the TCP connection (to subdomain.nviso.be in our example) is established:


But even before the user clicks one of the buttons, Adobe Reader will do a DNS request for this domain (nviso.be):


If the domain does not resolve to an IP address, Adobe Reader will do another DNS request for the subdomain (subdomain.nxdomains.be in this example, where nxdomains.be does not resolve to an IP address):


In this case, the warning presented to the user is slightly different:


This type of PDF document can be used to track users: when the document is opened, a DNS request is performed. If the request is a FQDN unique to the PDF document, then such a DNS request logged by the DNS server is a sure indicator that the PDF document has been opened. Remark that this DNS request will have a source IP address from a DNS server, not from the user’s machine.

If the user allows a connection to be made, then a TCP connection will be established between the user’s machine and the web server.

In a corporate environment with HTTP(S) proxies, the DNS requests can be prevented from going to the Internet.