Decoding malware via simple statistical analysis

Intro

Analyzing malware often requires code reverse engineering which can scare people away from malware analysis.

Executables are often encoded to avoid detection. For example, many malicious Word documents have an embedded executable payload that is base64 encoded (or some other encoding). To understand the encoding, and be able to decode the payload for further analysis, reversing of the macro code is often performed.

But code reversing is not the only possible solution. Here we will describe a statistical analysis method that can be applied to certain malware families, such as the Hancitor malicious documents. We will present this method step by step.

Examples

First we start with a Windows executable (PE file) that is BASE64 encoded. In BASE64 encoding, 64 different characters are used to encode bytes. 64 is 6 bits, hence there is an overhead when encoding in BASE64, as encoding one byte (8 bits) will require 2 BASE64 characters (6 bits + 2 bits).

With byte-stats.py, we can generate statistics for the different byte values found in a file. When we use this to analyze our BASE64 encoded executable, we get this output:

20170818-121549

In the screenshot above see that we have 64 different byte values, and that 100% of the byte values are BASE64 characters. This is a strong indication that the data in file base64.txt is indeed BASE64 encoded.

Using the option -r of byte-stats.py, we are presented with an overview of the ranges of byte values found in the file:

20170818-121603

The identified ranges /0123456789, ABCDEFGHIJKLMNOPQRSTUVWXYZ and abcdefghijklmnopqrstuvwxyz (and single charcter +) confirm that this is indeed BASE64 data. Padded BASE64 data would include one or two padding characters at the end (the padding character is =).

Decoding this file with base64dump.py (a BASE64 decoding tool), confirms that it is a PE file (cfr. MZ header) that is BASE64 encoded.

20170818-121639

Now, sometimes the encoding is a bit more complex than just BASE64 encoding.

Let’s take a look at another sample:

20170818-134020.png

The range of lowercase letters, for example, starts with d (in stead of a) and ends with } (in stead of z). We observer a similar change for the other ranges.

It looks like all BASE64 characters have been shifted 3 positions to the right.

We can test this hypothesis by subtracting 3 from every byte value (that’s shifting 3 positions to the left) and analyzing the result. To subtract 3 from every byte, we use program translate.py. translate.py takes a file as input and an arithmetic operation: operation “byte – 3” will subtract 3 from every byte value.

This is the result we get when we perform a statistical analysis of the byte values shifted 3 positions to the left:

20170818-140557

In the screenshot above we see 64 unique bytes and all bytes are BASE64 characters. When we try to decode this with base64dump, we can indeed recover the executable:

20170818-141640

Let’s move on to another example. Malicious documents that deliver Hancitor malware use an encoding that is a bit more complex:

20170818-141220

This time, we have 68 unique byte values, and the ranges are shifted by 3 positions when we look at the left of a range, but they appear to be shifted by 4 positions when we look at the right of a range.

How can this be explained?

One hypothesis, is that the malware is encoded by shifting some of the bytes with 3 positions, and the other bytes with 4 positions. A simple method is to alternate this shift: the first byte is shifted by 3 positions, the second by 4 positions, the third again by 3 positions, the fourth by 4 positions, and so on …

Let’s try out this hypothesis, by using translate.py to shift by 3 or 4 positions depending on the position:

20170818-142338

Variable position is an integer that gives the position of the byte (starts with 0), and position % 2 is the remainder of dividing position by 2. Expression position % 2 == 0 is True for even positions, and False for uneven positions. IFF is the IF Function: if argument 1 is true, it returns argument 2, otherwise it returns argument 3. This is how we can shift our input alternating with 3 and 4.

But as you can see, the result is certainly not BASE64, so our hypothesis is wrong.

Let’s try with shifting by 4 and 3 (instead of 3 and 4):

20170818-142729

This time we get the ranges for BASE64.

Testing with base64dump.py confirms our hypothesis:

20170818-142903

Conclusion

Malware authors use encoding schemes that can be reverse engineered by statistical analysis and testing simple hypotheses. Sometimes a bit of trial and error is needed, but these encoding schemes can be simple enough to decode without having to perform reverse engineering of code.

Don’t be lazy with P4ssw0rd$

Three challenges to making passwords user-friendly

Following the interview of Bill Burr, author of NIST’s 2003 paper on Electronic Authentication, in which he announced that he regrets much of what he wrote, we stop and think.

Why was the standard putting users at risk? Paraphrasing History: “Tout pour le peuple; rien par le peuple”. Perfectly correct from a theoretical point of view, the standard failed to acknowledge that users are indeed people, and when asked to follow too complex rules they will find “tricks” to help themselves to remember their current nightmarish password. Of course, said tricks are fairly easy to guess by any decent hacker, let alone an educated computer.

Nothing new here, the user is often and unfairly considered as the problem. But since there is no easy way to fix the user, it is up to us, as security and IT professionals, to design and build our systems to make them more resilient to human mistakes, and maybe some laziness.

Screen Shot 2017-08-28 at 09.36.42

Difficult for you, easy for a computer : passwords haven’t been what they should.

 

Ah, those funny stories on predictable passwords

The problem with the previous standard wasn’t that it was advising people to make easy to crack passwords, but that too complex rules steered users towards the path of least resistance: very complex and very predictable passwords.

I remember working in a team where, by knowing how long one of your colleagues had been around, you could easily guess their password, applying the simple rule of Company_nn, where nn was the number of the rotation of the password.

So, what now ?
Three challenges to making passwords user friendly

The new NIST 800-63 special publication, and previous publications such as GCHQ’s NSCS guidance, turns the approach upside down: make your password policy user friendly and you’ll get better security. A simple idea: put the burden as much as possible on the verifier, not the user. With one dream: create security that works no matter what the people do. Is it all that easy ? Let’s look at three recurrent challenges we’ve encountered at our clients:

1. Make it hard to guess with blacklist check

What is this about?
Forget complexity and just make sure you don’t use a word from the dictionary, a known first or last name, or a commonly used password (based on public lists of breached passwords). Now, this is easier than done.

Why is it a challenge?
While quality password blacklists can be found online, neither the blacklist validation mechanism nor the integration with frequently updated blacklists is proposed in most systems and applications on the market. Azure AD, for example, has offered this functionality for only a year, and its scope remains limited. And then, most organizations use a local AD. Or something else that doesn’t have such a native password validation check.

So what ?
There are workarounds of course, but they’re not always robust and imply manual maintenance of a blacklist – an effort many organizations are reluctant to commit to. It will be interesting to see how the market catches up on this one. Until then, well, most system admin prefer to keep some complexity requirements on.

2. Make it easy to remember by promoting the use of passphrases

What is this about?
Lengthy passwords, such as passphrases, are much more likely to integrate human randomness: easy to remember, yet almost impossible for an automated system to make sense of when properly done. As usual, xkcd got it right.

Why is it a challenge ?
While passphrases are a simplification on paper, especially if complexity requirements are dropped, they’re also a new paradigm for most end-user. Let’s face it: 24 characters password sound scary and users are clearly reluctant to commit to this. We’ve tested this on a few friends: after some enthusiastic explanation from our part, they agreed to switch.
For the first few days, our names were accompanied with words that weren’t exactly kind. After a week, the cursing had disappeared and they got used to typing long passwords, often several times to get it right. With locked out increasingly replaced by password throttling, frustration was luckily enough not turned into user being locked out.
But only a few passwords were changed: replacing all passwords in use meant inventing tens of completely new password, based on a completely new reasoning.

So what ?
This tells us that Awareness and communication is needed to make mentality evolve. Maybe re-using some of the good Belgian material of our friends at safeonweb.be. Even like that, you may wish to focus your effort on one specific password – typically, their Windows password.
But this also tells us that users should only have to remember 4 or 5 passwords: the rest should be in a password vault. Here too, it’s about changing users habit. And again, this works fine until you want to connect from another device than the one hosting the vault. Who said Cloud? But that’s another debate.

3. If it’s still a secret, why change it?

What is this about ?
NIST has gone bold on the advice: only change password if you think (or know) it’s compromised. Don’t have them recurrently expire, this is exactly how passwords become predictable. Of course, this only works if other NIST recommendations are implemented, especially increased length and blacklist check.

What’s the challenge ?
It’s like Perfect Information of consumers in economics: in theory, we should all know everything. But look around and you’ll see it may take months or years to find out your users’ passwords were stolen – not to mention they might have been using that password all over the internet.

So what ?
The best friend of “no expiration” is “second factor”, making sure the memorized secret alone won’t let them in. Of course, with cost of these things and their inherent complexity, you’ll probably select risk-based on which layers and Apps you want to implement it – or even better, go for a common authentication portal that supports adaptive authentication.

What does this all tell us, then ?

That the world is moving to user-friendly security, at last. And the best part is: it’s doing it because old security didn’t work. But it also tells us that these things will be complex to implement, because systems are not ready, implementation will prove complex, and users have to unlearn what we’ve spent the last 20 years pushing into their brains.

This is essentially what our colleague Benoit said on TV a few weeks ago, in case you missed it, you can watch it here.

4B912252

 

NVISO at DEF CON 25

Staying up to date with the latest hot topics in Security is a requirement for any Security Consultant. Going to conferences is a great way of doing this, as it also gives you the opportunity to speak to peers and get a good view into what the security industry and the researchers are up to.

This year, we sent a small delegation to DEF CON, which is one of the most known Security Conferences in the world. We think everyone should go there at least once in their careers, so this year we sent Michiel, Cédric, Jonas and Jeroen to get their geek-on in Las Vegas!

From left to right: Cédric, Michiel, Jonas and Jeroen ready for their first DEF CON!
Ready to turn off your phones and laptops…

The conference was held at Caesar’s Palace’s conference center, right in the middle of the famous strip. There were four parallel tracks for talks and a lot of different villages and demos throughout the entire conference. We know that What happens in Vegas, Stays in Vegas, but some of these talks were just too good not to share!

Internet of Things (IoT)

There was a large focus on IoT this year, which was great news for us, as we’re actively evolving our IoT skillset. Cédric, our resident IoT wizard, has been running around from talk to talk.

A further update on the IoT track will be provided by Cédric once he is back from holidays 🙂

Mobile

The amount of talks on Android / iOS was fairly limited, but there were definitely some talks that stood out. Bashan Avi gave a talk on Android Packers. The presentation is very thorough and tells the story of how they used a few of the most popular packers to devise an algorithm for detecting and unpacking variations of the same concept. Their approach is very well explained and could be really interesting for our own APKScan service.

Screen Shot 2017-08-03 at 07.46.16

A typical flow of Android Packers (source)

On Sunday, Stephan Huber and Siegfried Rasthofer presented a talk on their evaluation of 9 popular password managers for Android. Their goal was to extract as much sensitive information as possible on a non-rooted device. Even though you would expect password managers to put some effort into securing their application, it turns out this is rarely the case. The following slide gives a good overview of their results, but be sure to check out the entire paper for more information.

Screen Shot 2017-08-03 at 07.53.18.png

The results of Stephan Huber and Siegfried Rasthofer’s research on Android Password Managers (source)

Biohacking

One of the most interesting talks for us was given by John Sotos (MD). While almost all talks focus on very technical subjects, John gave an introduction on the Cancer Moonshot Project and how creating a gene-altering virus targeted at specific DNA traits is inevitable. This is of course great from a Cancer-treatment point of view, but what if someone would alter the virus to attack different genes? Maybe an extremist vegetarian could make the entire world allergic to meat, or maybe a specific race could be made infertile… In his talk, John explains what could go wrong (and he is very creative!) and how important it is to find a defense against these kinds of viruses even before they actually exist.

Villages

Crypto Village

One of our biggest projects within NVISO Labs consists out of building an out-of-band network monitoring device. In the most recent years we’ve seen a lot of the web shift to HTTPS.

 

While this is definitely a good thing in terms of security, it does limit the possibilities of monitoring network traffic. Malware authors know this as well, and are starting to increasingly adopt TLS/HTTPS in their CnC communications (e.g. the Dridex family). In the crypto village, Lee Brotherston demonstrated various techniques to fingerprint TLS connections and even showed a working PoC. This could allow us to create fingerprints for various malware communications and detect them on the network. More information can be found on Lee’s GitHub page.

Car Hacking Village

When we were looking through the villages available at DEF CON this year, the newest car hacking village immediately caught our attention. In the room were several cars with laptops hooked to the dashboards and people trying to completely take over the controls. In the middle of the room was a brand new Dodge Viper of which the steering controls got reprogrammed to control a video game instead of the actual car. Some of our colleagues even got the chance to test drive it! Although with mixed results …

DF8gzSOV0AADxw4

Jonas learning how to drive a sports car (and not doing a great job 😜).

Packet Hacking Village

The Packet Hacking Village (PHV) is one of the biggest, if not the biggest, village in DEF CON. It’s also the place where Jonas spent a lot of his time, meticulously following talks and taking notes. Different talks could be linked to various steps of the cyber kill chain and were interesting to consider for red teaming assessments or as part of the blue team protecting against these attacks.

One of the presentations that stilled our offensive hunger was given by Gabriel Ryan and discussed wireless post-exploitation techniques. One of the attacks allows to steal AD credentials through a wireless attack using a ‘hostile portal’ that redirects a victim’s HTTP traffic to SMB on the attacker’s machine. This, and his other attacks were facilitated by his own eaphammer tool.

Our blue side was satisfied as well with a talk on Fooling the Hound, which attempts to thwart attackers making use of the BloodHound tool, aimed at visualizing the relationships within an AD environment. His deceptions include fake high-privilege credentials, which increase the shortest path towards a high-value asset. The resulting BloodHound graph showed a greatly increased number of nodes and edges, thereby complicating an attacker’s lateral movements!

Meetup with the CSCBE winners

As you may know, the winners of NVISO’s Cyber Security Challenge 2017 received tickets to DEF CON which was an excellent opportunity to have a little Vegas CSC reunion!

DGAQxY8UIAAenHH

Return to sender

All good things come to and end, and so did the DEF CON conference. We had a really great time in Las Vegas, and everyone made it home safely without losing too much money at the poker table ;-).

Screen Shot 2017-08-03 at 08.15.23

Who is watching your home surveillance systems?

This morning, I heard on the radio that dozens of Belgian families were being watched through their own home surveillance system in Belgium. Nothing new here, as we already know for years that sites exist through which you can watch camera footage of unknowing victims, and this problem is not just limited to Belgium of course.

Now, looking at this from an IT security perspective, it would be easy to say “it’s their own fault, they should have changed their default passwords!” or “it’s their own fault, why would you make your surveillance system internet accessible?”. The reality is that most users don’t see an issue with connecting their home surveillance system to the internet – especially not if it’s fully supported by the vendor! In the end, it’s reasonable for the user to expect from the vendor that the surveillance system is installed in a secure way.

shodan

A quick search on Shodan – a search engine for connected devices – shows thousands of publicly exposed surveillance systems all over the world.

A few weeks ago, one of our colleagues had a specialized firm install security cameras around the house. Our colleague had to move heaven and earth to explain that the video controller should not be directly connected to the internet but that it should be connected to the internal network which is firewalled. As you can see, most people would have no notion of this and would be happy to see the video footage everywhere they go from an app on their smartphone without any type of authentication.

Now, how to avoid your home surveillance system from being viewed by anyone in the world? Well there are several things you can do here, varying in terms of technical difficulty (non-exhaustive list).

  1. Password-protect all your connected devices, and remove anonymous access.
  2. Change the default password on all your connected devices. This will prevent that these devices can be accessed by anyone on the internet using default credentials, such as username and password both being “admin” or “demo”.
  3. Keep your camera software up to date. As with all electronic devices running software is the case, camera systems could contain bugs that allow unauthorized individuals to take control of and view your images. When bugs in cameras are identified, usually (unfortunately not always), the vendors release patches to fix these bugs.
  4. Connect wireless cameras to a secured wireless network. If you use wireless cameras, it is important to connect them to a secure (WPA2) wireless network. This will prevent anyone in the vicinity of your network to eavesdrop on and intercept the communication.

Last but not least, more and more vendors are allowing end users to connect their devices to the cloud and have them view the images through a secured online portal. Moving forward this looks to be a good solution for private homes as with this solution it is not needed to make your cameras internet accessible but in the same time you would be able to view your live feeds from anywhere. In this case, the security of the solution also depends on the security of the vendor cloud environment.

We are currently performing research on the security of home surveillance systems and will post updates on this soon, so stay tuned!

unnamed 2

Our team is researching common security errors in IoT devices as we speak

Recovering custom hashes for the Petya/Notpetya malware

During our malware analysis, we often come across samples that contain (custom) hashes in stead of cleartext. Hashing is done in an effort to bypass detection and hinder malware analysts. There are tools to recover cleartext from known hashing methods (like John the Ripper and hashcat). But for custom hashing methods, you’ll have to write some code. In this blog post, we illustrate a method to recover the custom hashes of a non-croptygraphic hashing method used by malware to obfuscate its behavior.

The Petya/Notpetya malware contains code to check which processes are running on a victim machine, and change its behavior accordingly. Microsoft has explained this in detail, with the custom hashing function and hash values to identify processes, however without reporting the process names the malware looks for.

At NVISO, we like to share knowledge and this blog post is no different. We will explain you how we recovered the process names, so that you can use this method in your own malware analysis endeavors.

The names of the processes are not hardcoded in the malware code, but a custom hash function is used to identify the processes of interest:

The custom hash function clears bits in variable v10 if process names that match custom hash values 0x2E214B44, 0x6403527E and 0x651B3005 are found.

A (cryptographic) hash function is not reversible, so we will need to figure out another way to match these hashes with actual process names. Cracking hashes is done with dictionary and brute force attacks: a trial and error method where the hash function is used with input values from the dictionary/brute-force generator until a matching hash is found. Remark that this custom hash function is not a cryptographic hash function and that the hash value is 4 bytes long, so many collisions will be found when brute forcing.

We suspected that the process names of interest are security related: antivirus software, firewalls, … Meterpreter has a killav function that contains a list of process names of security software.  We used this list in our dictionary attack.

Next step is to write a program to perform the attack. Because execution speed could be crucial, we wrote it in C. We took the decompiled custom hash function source code and modified it a bit to be compiled with Visual Studio:

void ConfigCheckProcesses(_TCHAR* processname)
{
unsigned int v0; // ebx@3
unsigned int v1; // kr00_4@3
unsigned int v2; // edx@4
unsigned int v3; // esi@5
char *v4; // ecx@6
char v5; // al@6
int v9; // [esp+230h] [ebp-8h]@3
int v10; // [esp+234h] [ebp-4h]@1

v10 = -1;
v9 = 0x12345678;
v0 = 0;
v1 = _tcslen(processname);
do
{
v2 = 0;
if (v1)
{
v3 = v0;
do
{
v4 = (char *)&v9 + (v3 & 3);
v5 = (*v4 ^ LOBYTE(processname[v2++])) - 1;
++v3;
*v4 = v5;
} while (v2 < v1);
}
++v0;
} while (v0 < 3);
if (v9 == 0x2E214B44)
{
_tprintf_s(TEXT("0x2E214B44: %s\n"), processname);
}
else if (v9 == 0x6403527E)
{
_tprintf_s(TEXT("0x6403527E: %s\n"), processname);
}
else if (v9 == 0x651B3005)
{
_tprintf_s(TEXT("0x651B3005: %s\n"), processname);
}
}

While performing a dictionary attack with our customized hash function and Meterpreter’s list as dictionary, we recovered one hash: 0x2E214B44 is avp.exe (Kaspersky). When we searched Twitter for avp.exe, we found one interesting tweet. We looked at this person other tweets to see if they had recovered the other hashes, unfortunately they did not.

So the next step was to perform a brute-force attack. We generated process names with characters a-z, A-Z (the custom hash function is case sensitive), 0-9 and . – _ and assumed the extension would be .exe.
Here is the result:

Hash 0x651B3005 is NS.exe (Norton Security). That left us with hash 0x6403527E to recover. Since these two hashes are used to clear the same bit, we assumed that the processes might somehow be related. Googling for process names related to NS.exe, we came upon different process names for Norton and Symantec software. A short dictionary attack with these names revealed that 0x6403527E is ccSvcHst.exe (Symantec).

Conclusion

When you have a decompiler available to recover the source code of custom hash functions, one can quickly transform that source code in a working program to perform dictionary attacks and (small) brute force attacks. Larger brute force attacks will require more complex code to speed up the recovery process: multi-threaded code or code that uses GPUs.

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 cert@nviso.be

If you are interested in receiving our advisories via our mailing list, you can subscribe by sending us an e-mail to cert@nviso.be.

A word from our interns Aras, Gaetan and Wouter!

During the first half of 2017 we had the pleasure of working with three bright interns assisting us on various projects ranging from developing an interactive training platform to creating challenges for the Cyber Security Challenge to working on improving our own IT environment.

We asked them to let us know what they thought of their time spent here. Below is the feedback we received!

Interns_Q1_Q2_2017

Posing in front of our beloved blue bird with a great smile! 😊

Gaëtan:
During my internship at NVISO, I assisted the company into deploying and assessing new components in the IT environment. Due to NVISO’s sector of operation, a large emphasis was placed on the security of this environment both in the cloud and on the workstations used to access the services and resources. The aim of this migration was to provide a more unified set of services with increased productivity features while maintaining a strong, secure and controlled environment.

Overall it was a pleasure to work at NVISO during my internship. Working with such a dynamic team was a pleasure, and the overall ambiance and working with like-minded people was a delight.

Aras:
Personally I am proud on doing my internship at NVISO and also with his team that had respect, experience and fun.
During my internship I did two different projects:
1 – creation of the IoT village for the Cyber Security Challenge
2 – Working with open source information databases on connected devices, such as Shodan.

Thank you again guys to all great moment and your patience,

Wouter – Howest:
During my internship I worked on building the back end for an interactive training infrastructure. This infrastructure will help NVISO in improving its trainings, demonstrations and workshops. Building this infrastructure would not have been possible without the support of the NVISO team. I really enjoyed working at NVISO during my internship. The working atmosphere and colleagues are really top notch.

We would like to take this opportunity to thank you all for your commitment and enthusiasm you all brought into the workplace! Hope to see you again soon 🐀!

The entire NVISO team.