Category Archives: Uncategorized

My Internship Experience at NVISO – by Thibaut Flochon

Hi! I’m Thibaut, a bachelor student in Information Technology at Hénallux. As a final-year student, I have had the opportunity to do my internship at NVISO for 4 months. Let me share this experience with you!


The year before my internship, I took part in the Cyber Security Challenge Belgium 2017 with some friends. Playing with Wireshark captures, trying to brute force passwords, analysing files, all are activities that really made me want to know more about the cyber security field. That’s why the following year, when the time had come to do my internship, I directly thought about cyber security and told myself “Why not do my internship in the company organising the annual competition? “ And here I was, intern at NVISO!


Quick! Let’s all look professional for the photo! 😀 (I’m sitting in the right side of the sofa, joined by 3 of my internship colleagues at our office.)

What did I do?

The goal of my internship was to create a cyber attack scenario within NVISO’s training infrastructure. With basically no knowledge about post-compromise attacks against a Windows domain, a great learning journey was waiting for me.

At first, I had a meeting with my internship mentor, Wouter, to talk a bit about the “what”, and “why” of my project. I could then start to gather some info on the “how”, in order to figure out possibilities and tools I could use to create that cyber attack scenario.

Once I found enough info and resources for my project, Wouter kindly guided me to the right employee to ask questions to, so that I could sort out what I found and keep the necessary, to be sure to create something useful for the company. Following that meeting, lunch time! After having grabbed a sandwich with other employees and interns, we ate our meal all together in the cafeteria, as is NVISO team’s habit.

As the weeks passed and through regular follow-ups and meetings, I was glad to see my project really move forward; the cyber attack scenario was almost finished.

Time flies! A few weeks later, it was already the end of my internship. I made a PowerPoint presentation presenting the finished scenario and the results of my internship!


I have had a great time during that internship; I learnt a lot about attacks against Windows domains, I improved my soft skills by explaining technical issues in an understandable way, and I laughed a lot with my colleagues! Until a next time!

Stalking a reporter – behind the scenes!

Around mid-October we got a call from a reporter working on an article covering online privacy and social media. Rather than writing about others, the reporter wanted to have his own story. So, he asked NVISO to research him on-line, and find out as much as possible about him! Of-course, after agreeing on some “ground rules” with the journalist, we were 100% up for it!

The ground rules that were put in place:

  • We would focus on mining only publicly available information, not make him a target of an attack.
  • We were not allowed to use social engineering tricks on him or his friends and family to get additional information.
  • In other words: we could use any information already available online, without actively asking for more.

The article that was recently published by the journalist can be found online (Dutch only, sorry!): For anyone interested in the “behind the scenes” on how we approached this – keep on reading!

Let’s hunt!

The team that stalks together…

We assembled a small group of volunteers and got to the task. We created a repository to collectively track our findings, as all bits of information would help the other researchers to move further on their own search, or validate information pieces gathered from different sources. The starting point was obvious: We had the journalists’ name, the email address he used to propose the experiment and a phone number on his signature. Plenty of information to start from!

The first step was to find his Facebook profile. We quickly found out that the reporter does not use the combination name + last name as the profile name, making it more difficult to track down the profile (assuming that he actually has a Facebook profile 😊). But as it often happens, some friends had mentioned his full name on publicly tagged Facebook pictures. We knew his face now! After that, identifying his own profile was possible by looking at metadata in the pictures, including the tagged friends. From there on we started building our file. The privacy settings for the profile were (unfortunately for us) quite restrictive… luckily for us that was not the case for all his friends!

Screen Shot 2017-11-14 at 14.57.36

Facebook showing profile picture after you’ve entered a wrong password

We found his personal email account by guessing and trying to login with the email account to Facebook. Facebook shows you your profile picture when you say that you forgot your password. That is how we could link his personal email with Facebook. We correctly guessed that he also used this email for other social media and apps, and used the same method to see of he had an account. From there onwards, figuring which other services he was using was easy. From there we could gather additional interests, routines, professional activities, social relations…

Of course, this kind of research leads to many false positives. In our case, someone with the same name happens to live close by to our reporter, and some of our data actually referred to that person. That is where crossing data from different sources comes in handy. It allows to discard some of the bits that don’t really match the puzzle.

During our investigations, we also discovered details on the ex-girlfriend of the journalist – her online activity proved to be an excellent source of information! Prolific Instagrammer, her account gave us a lot of info about travels they did together, pictures, friends… Why do we know she was his ex? They are not friends on Facebook anymore! We got no juicy stuff about the breakup, though.

With the parents name (which we found in a cached document on Google), we could find their house, pets, and social media accounts with additional clues… We could assemble a fairly decent family tree. We were also able to find his home address.

With these results we got back to our reporter. He was quite surprised by the things we found out without directly approaching him or his friends! He found particularly scary what we found out about his family and his ex-girlfriend.  He was surprised, though, not seeing his birthdate on our data list.

One step further … go phishing
After our initial investigations, we mutually agreed to take it one step further. 

So what did we do ? We created a fake Facebook profile to trick him or his friends into sharing additional information, contacting his parent or just some good, old phishing to get his credentials and access his email account. We opted for the last option.

We crafted an email based on his interests (which we already identified during the first part of the research). We sent him a link that sounded very relevant for him, so he would definitely try to check it it. And it worked, even though he knew he was going to be targeted by us in this time window. He clicked, and he was directed to a google authentication page. Google? Well, actually NVISO-owned, Google-looking. That is how we got his password.

Once we gain access to his account, we stopped the game. We called him and showed him we were in by sending a mail via his own private inbox to his work email. The challenge was completed. We left nicely, whiteout reading his emails.


Emailing from within the inbox of the reporter to the reporter (yes, this is a dummy screenshot!)

In a meeting afterwards, we explained him how he was phished. Up till then he had no clue how he had given us his credential! But we have to confess: still, we didn’t get his birthdate.

Most people aren’t too surprised anymore about the wealth of information available on each of us online. What is interesting, though, is how often we believe we are fine, just because we have our privacy settings nicely set and reviewed for all our accounts (as was the case with the journalists’ Facebook profile for example). That old account you forgot you had, the friends that tagged you, the university bulletin, a legal document or a nice note in memoriam of a loved one can give most valuable information to anyone who is interested.

Entering the active reconnaissance part, phishing once again proved a very reliable method to get additional details from a target – in our case, it even gave us full access to the journalists’ mailbox.

We are all on-line. Most of our life is these days, and that is not necessarily a bad thing. But it is important to remember that, despite all privacy and security rules we want to enforce, humans are still the weakest link. Understanding how we share information online and the impact it has on us and others is key in an increasingly digitalised world – we are happy to have contributed to the article & hope to have raised some awareness with the readers!


Developing complex Suricata rules with Lua – part 2

In part 1 we showed a Lua program to have Suricata detect PDF documents with obfuscated /JavaScript names. In this second part we provide some tips to streamline the development of such programs.

When it comes to developing Lua programs, Suricata is not the best development environment. The “write code & test”-cycle with Suricata can be quite tedious. One of the reasons is that it takes time. It can take 1 minute or more to start Suricata with the new rule, and have it process a test pcap file. And if there are errors in your Lua script, Suricata will not be of much help to identify and fix these errors.

Inspired by Emerging Threats Lua scripts, we adopted the following development method:

Test the script with a standalone Lua interpreter, and move to Suricata for the final tests.

This is one of the reasons why, in part 1, we put the logic of our test in function PDFCheckName which takes a string as input and is called by the match function. By doing this, we can also call (and test) the function from other functions with a standalone Lua interpreter as shown below:

function Test()
    print(PDFCheckName("testing !!!", true))
    print(PDFCheckName("testing /JavaScript and more /J#61vaScript !!!", true))
    print(PDFCheckName("testing /JavaScript and !!!", true))
    print(PDFCheckName("testing /J#61vaScript !!!", true))

This Test function calls PDFCheckName with different strings as input. We also added extra print statements to the function (see complete source code below), which are activated by the second argument of function PDFCheckName. This boolean argument, bVerbose, adds verbosity to our function when the argument is true.

We can load the Lua program in a Lua interpreter, and then call function Test. One way to do this is type command “lua -i PDFCheckName.lua”, and then type Test() at the Lua prompt. This can all be scripted in a single command like this:

echo Test() ¦ lua -i PDFCheckName.lua

With the following result:


This “code & run”-cycle is faster than using Suricata, and can be more verbose. Of course, you can also do this with an IDE like Eclipse.

We also added a function TestFile that reads a file (the PDFs we want to test), and then calls PDFCheckName with the content of the PDF file as the argument:


This produces the following output:


Being able to test a PDF file directly is also a big advantage, compared to having to create a PCAP file with a http request downloading the PDF file to test.


By using functions and a standalone Lua interpreter, we can significantly improve the development process of Lua programs for Suricata.


-- 2017/02/20

-- echo Test() | lua53.exe -i test.lua
-- echo TestFile() | lua53.exe -i test.lua javascript.pdf

tBlacklisted = {["/JavaScript"] = true}

function PDFCheckName(sInput, bVerbose)
    if bVerbose then
        print('sInput: ' .. sInput)
    for sMatchedName in sInput:gmatch("/[a-zA-Z0-9_#]+") do
        if bVerbose then
            print('sMatchedName: ' .. sMatchedName)
        if sMatchedName:find("#") then
            local sNormalizedName = sMatchedName:gsub("#[a-fA-F0-9][a-fA-F0-9]", function(hex) return string.char(tonumber(hex:sub(2), 16)) end)
            if bVerbose then
                print('sNormalizedName: ' .. sNormalizedName)
            if tBlacklisted[sNormalizedName] then
                if bVerbose then
                return 1
    if bVerbose then
        print('Not blacklisted!')
    return 0

function init(args)
    return {["http.response_body"] = tostring(true)}

function match(args)
    return PDFCheckName(tostring(args["http.response_body"]), false)

function Test()
    print(PDFCheckName("testing !!!", true))
    print(PDFCheckName("testing /JavaScript and more /J#61vaScript !!!", true))
    print(PDFCheckName("testing /JavaScript and !!!", true))
    print(PDFCheckName("testing /J#61vaScript !!!", true))

function TestFile()
    local file =[1])
    print(PDFCheckName(file:read("*all"), true))

Analyzing obfuscated scripts using nothing but a text editor

In this blog post, we will perform an analysis on some obfuscated scripts that we received. These files were already detected by automated scanners but as these are mainly malware droppers, we figured it could be interesting to do some manual analysis to determine where the actual malware is hosted.

The first sample we will investigate is a .wsf file. This type of file is a Windows script file and can contain various scripting languages. In this case, we’re dealing with an obfuscated VBScript.


Due to the obfuscation, it’s impossible to see on first sight what this script is trying to accomplish. We could run it in a virtual machine and dynamically monitor actions taken by the script such as network connections or processes started, but first we’d like to have an idea of the code.

Some script code structures that are interesting to look for are functions that execute commands, such as:

  • Execute
  • Eval
  • ExecuteGlobal
  • Exec

In the script above, we can identify some “eval” statements and “executeglobal”. When the script is started, it will first run “InItIalIZe()”, followed by “ExecGlOBal()”. Let’s take a look at the contents of the Initialize function.


The first statement assigns a large encoded string to a parameter. Not much we can do there. The second statement performs a split on the encoded string using “chr(EvAl(31080/740))”. If you calculate 31080/740 from the top of your head, you get 42. Unsurprisingly, using “chr()”, this is translated to “*”, which is used as the splitting character in the obfuscated string. Don’t panic.

In the next step, a loop runs through all the integers from the string above, translates them to characters and appends them to one large string. This string is then passed as the parameter to the “ExecuteGlobal” command.


We can piggyback on the deobfuscation that the malicious script is already performing by itself. Instead of letting it execute the deobfuscated code in the “ExecuteGlobal” command, we replace this command by something that will print the parameter to output. For Windows scripting, we can do this using “Wscript.echo”.


Using a command prompt and the “wscript” command, we can run the modified script. Our printing command shows us the decoded output in a pop-up window, which is too small to contain the entire code:


Copy pasting the entire text is not feasible either. Luckily, there’s an alternative: “cscript”. Using “csript file.wsf > deobfuscated.txt” we can print the deobfuscated string to a new file.

The result is similar to what we started with. We will follow the same approach again and replace the “execute” with a new printing statement and save the script as .vbs. Alternatively, we could surround the script with a “” and “// <![CDATA[
” tag and specify the scripting language in the “” tag. Then we could save and run the script as .wsf, similarly to the original script.


Now we get something that is actually readable. Nice! On first sight, we can see the script runs some persistence commands, including: writing the script to startup folders and adding some registry keys. This is interesting but these are not the juicy details we were looking for. We’ve added the persistence code below, along with the relevant parameters.


What follows is a loop that looks a lot more interesting. We can see that it makes a POST call using host and port parameters that are defined at the start of the script. The user-agent is set using pre-defined parameters as well (client & auth). This might allow the malware authors to determine what version of their malware is trying to communicate back to them. This is also a reason why user-agent string monitoring can be interesting for security analysts. Anomalies such as these can easily be detected.


Based on the result of this POST call, the script continues its execution through one of three functions. All of them make use of the function “D()”, that is defined a bit further in the code, presumably for deobfuscation of the POST response. The two quotes functions seem to be unused (for now).


If we want to further analyse this script, we need to have a response from the command and control server. The time to actually run the script has come!

Running the script

When executing the script and sniffing the traffic using Wireshark, we can see the POST call flying by, containing the user-agent set by the script. The response is another encoded string, prefixed with “s0”. We can use Wireshark’s “Export Objects” functionality to extract the response. If we go back to the script, we can see a case statement for this string. Looks like “Func0” will be executed on our newly obtained string! Time to let the script do the deobfuscation by replacing the execution command in “Func0” and pasting the obfuscated C&C response in our script! Note that we snipped most of the obfuscated string for the image below. Don’t forget to quit the loop or it’ll keep on running.


This final script we receive is not obfuscated at all. Looks like this malware is fingerprinting our computer. Adding an additional “echo” command would show us the information contained in the “ret” parameter. We can give you a small hint: it’s our computer and user name, OS, anti-virus,.. being sent through a POST call to the C&C. We have also observed this call in the traffic capture from before, so we could export the contents through Wireshark as well. There’s a sample of the AV fingerprinting code below.


Unfortunately, we won’t be able to figure out what the other functions (Func1 & Func2) do, since the command and control server did not send us any other command. Some possible causes could be that it decided our system is not interesting based on the information it received or it might just have been in an information gathering phase. If you want more information on this malware, look for Houdini!

Maldoc: It’s not all VBA these days

Since late 2014 we witness a resurgence of campaigns spamming malicious Office documents with VBA macros. Sometimes however, we also see malicious Office documents exploiting relatively recent vulnerabilities.

In this blog post we look at a malicious MS Office document that uses an exploit instead of VBA.

The sample we received is 65495b359097c8fdce7fe30513b7c637. It exploits vulnerability CVE-2015-2545 which allows remote attackers to execute arbitrary code via a crafted EPS image, aka “Microsoft Office Malformed EPS File Vulnerability”. In this blog post we want to focus on extracting the payload.

A more detailed explanation on the exploit itself can be found here (pdf).


The sample we received is a .docx file, with we can confirm it doesn’t contain VBA code:


With (remember that the MS Office 2007+ file format uses ZIP as a container) we can see what’s inside the document:

Screen Shot 2017-02-06 at 11.03.02.png

Looking at the extensions, we see that most files are XML files. There’s also a .gif and .eps file. The .eps file is unusual. Let’s check the start of each file to see if the extensions can be trusted:


This confirms the extensions we see: 12 XML files, a GIF file and an EPS files. As we know are exploits for EPS, we took a look at this file first:


The file contains a large amount of lines like above, so let’s get some stats first:

Screen Shot 2017-02-06 at 11.52.35.png gives us all kinds of statistics about the content of the file. First of all, it’s a large file for MS Office documents (10MB). And it’s a pure text file (it only contains printable characters (96%) and whitespace (4%)).

There is a large amount of bytes that are hexadecimal characters (66%) and BASE64 characters (93%). Since the hexadecimal character set is a subset of the BASE64 character set, we need more info to determine if the file contains hexadecimal strings or BASE64 strings. But it very likely contains some, as there are parts of the file (buckets) that contain only hexadecimal/BASE64 characters (10240 100%). is a tool to search for BASE64 strings (and other encodings like hexadecimal). We will use it to search for a payload in the EPS file. Since the file is large, we can expect to have a lot of hits. So let’s set a minimum sequence length of 1000:


There are 4 large sequences of BASE64 characters in the document. But as the start of each sequence (field Encoded) contains only hexadecimal characters, it’s necessary to check for hexadecimal encoding too:


With this output, it’s clear that the EPS file contains 4 large hexadecimal strings.

Near the start of the decoded string 2 and 4, we can see characters MZ: this could indicate a PE file. So let’s check:

Screen Shot 2017-02-06 at 12.19.55.png

This certainly looks like a PE file. Let’s pipe it through (we need to skip the first 8 bytes: UUUUffff):


This tells us that it is definitively a PE file. With more details from pecheck’s output, we can say it’s a 64-bit DLL. It has a small overlay:


Since this overlay is actually just 8 bytes (UUUUffff), it’s not an overlay, but a “sentinel” like at the start of the hexadecimal sequence. So let’s remove this:


We did submit this DLL to VirusTotal: 30ec672cfcde4ea6fd3b5b14d6201c43.

It has some interesting strings:


Like the string of the PDB file: GetDownLoader. And a PowerShell command to download and execute an .exe (the URL is readable).

Also notice that the string “This program can not be run in DOS mode.” appears twice. This is a strong indication that this DLL contains another PE file.

Let’s search for it. By using the –cut operator to search for another instance of string MZ, we can cut-out the embedded PE file:


We also submitted this file to VirusTotal: 2938d6eda6cd941e59df3dd54bf8dad8. It is a 32-bit EXE file.

The hexadecimal string with Id 4 found with base64dump also contains a PE file. It is a 32-bit DLL (ce95faf23621a0a705b796c19d9fec44), containing the same 32-bit EXE as the 64-bit DLL:  2938d6eda6cd941e59df3dd54bf8dad8.


With a steady flow of VBA maldocs for over more than 2 years, one would almost forget that Office maldocs with exploits are found in-the-wild too. If you just look for VBA macros in documents you receive, you will miss these exploits.

In this sample, detecting a payload was not too difficult: we found an unusual file (large .eps file) with long hexadecimal strings that decode to PE-files. It’s not always that easy, especially if we are dealing with binary MS Office files (like .doc).

In this post we focus on a static analysis method to extract the payload. When performing analysis on this file yourself, be aware that this maldoc also contains shellcode (strings 1 and 3 found by base64dump) and an exploit to break out of the sandbox (protected view).

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!

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.