Monthly Archives: August 2017

Decoding malware via simple statistical analysis


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.


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, 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:


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, we are presented with an overview of the ranges of byte values found in the file:


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 (a BASE64 decoding tool), confirms that it is a PE file (cfr. MZ header) that is BASE64 encoded.


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

Let’s take a look at another sample:


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 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:


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:


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


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 to shift by 3 or 4 positions depending on the position:


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):


This time we get the ranges for BASE64.

Testing with confirms our hypothesis:



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 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.




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 🙂


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)


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.


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 …


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!


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.


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