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.

Malicious PowerPoint Documents Abusing Mouse Over Actions

A new type of malicious MS Office document has appeared: a PowerPoint document that executes a PowerShell command by hovering over a link with the mouse cursor (this attack does not involve VBA macros).

In this blogpost, we will show how to analyze such documents with free, open-source tools.

As usual in attacks involving malicious MS Office document, the document is delivered via email to the victims.
(MD5 DD8CA064682CCCCD133FFE486E0BC77C)

Using emldump.py (a tool to analyze MIME files), we can analyze the email received by the user:

pp-01

The output indicates that the mail attachment is located in part 5. We select part 5, and perform an HEX/ASCII dump of the first 100 bytes to get an idea which type of file we are dealing with:

pp-02

A file starting with PK is most likely a ZIP file. So let’s dump this file and pipe into zipdump.py (a tool to analyze ZIP files):

pp-03

It is indeed a ZIP file. Judging from the filenames in the ZIP file, we can assume it is a PowerPoint file: .pptx or .ppsx.

Using zipdump and option -E (the -E option provides extra information on the type of the contained files), we can get an idea what type of files are contained in this PowerPoint files by looking at the headers and counting how many files have the same header:

pp-04

So the ZIP files (.pptx or .ppsx) contains 1 JPEG file (JFIF), 11 empty files and 36 XML files.

As said at the beginning, malware authors can abuse the mouseover feature of PowerPoint to launch commands. This can be done with an URL using the ppaction:// protocol to launch a PowerShell command.

To identify if this document abuses this feature, we can use YARA. We defined 2 simple YARA rules to search for the strings “ppaction” and “powershell”:

rule ppaction {
strings:
$a = "ppaction" nocase
condition:
$a
}</p>
<p style="text-align: justify;">rule powershell {
strings:
$a = "powershell" nocase
condition:
$a
}

We use zipdump.py to apply the YARA rules on each file contained in the ZIP file:

pp-05

As shown in the screenshot above, file 19 (ppt/slides/slide1.xml, that’s the first slide of the presentation) contains the string ppaction string, file 21 (ppt/slides/_rels/slide1.xml.rels) contains the string powershell.

Let’s take a look at file 19:

pp-06

We can see that it contains a a:linkMouseOver element with an action to launch a program (ppaction://program). So this document will launch a program when the user hovers with his mouse over a link. Clicking is not required, as is explained here.

The program to be executed can be found with id rId2, but we already suspect that the program is Powershell and is defined in file 21. So let’s take a look:

pp-07

Indeed, as shown in the screenshot above, we have a Target=”powershell… command with Id=”rId2″. Let’s extract and decode this command. First we use re-search.py to extract Target values with a regular expression:

pp-08

This gives us the URL-encoded PowerShell command (and a second Target value, a name for an .xml file, which is not important for this analysis). With translate.py and a bit of Python code, we can use module urllib to decode the URL:

pp-09

Now we can clearly recognize the PowerShell command: it will download and execute a file. The URL is not completely clear yet. It is constructed by concatenating (+) strings and bytes cast to characters ([char] 0x2F) in PowerShell. Byte 0x2F is the ASCII value of the forward slash (/), so let’s use sed to replace this byte cast by the actual character:

pp-10

And we can now “perform the string concatenation” by removing ‘+’ using sed again:

pp-11

We can now clearly see from which URL the file is downloaded, that it is written in the temporary folder with .jse extension and then executed.

To extract the URL, we can use re-search.py again:

pp-12

A .jse file is an encoded JavaScript file. It’s the same encoding as for VBE (encoded VBScript), and can be decoded using this tool.

Conclusion

It’s rather easy to detect potentially malicious PowerPoint files that abuse this feature by looking for string ppaction (this string can be obfuscated). The string powershell is also a good candidate to search for, but note that other programs than PowerShell can be used to perform a malicious action.

Update

We produced a video demonstrating a proof-of-concept PowerPoint document that abuses mouse over actions (we will not release this PoC). This video shows the alerts produced by Microsoft PowerPoint, and also illustrates what happens with documents with a mark-of-web (documents downloaded from the Internet or saved from email attachments).

Sources:
‚ÄúZusy‚ÄĚ PowerPoint Malware Spreads Without Needing Macros:¬†https://sentinelone.com/blogs/zusy-powerpoint-malware-spreads-without-needing-macros/
Tools used: https://blog.didierstevens.com/didier-stevens-suite/
a:hlinkMouseOver: http://www.datypic.com/sc/ooxml/e-a_hlinkMouseOver-1.html
shp-hyperlink: http://python-pptx.readthedocs.io/en/latest/dev/analysis/shp-hyperlink.html
Sed: https://en.wikipedia.org/wiki/Sed

MoveBot: Battling inactivity one micro-exercise at a time

Many of our NVISO¬†colleagues are very active during their free time.¬†We have colleagues who go mountain-biking, rock climbing, swimming, running, … The problem is that during the day, they often sit at their desk for four hours straight, grab some lunch, and go back to their desk to sit and work at their computers. To make everyone just a little bit more active during the day, we created MoveBot.

MoveBot is a Slack bot that posts messages to our Slack channel twice a day. For example, just this morning, I got the following notification:

Screen Shot 2017-04-14 at 14.45.50

After having done the exercise, I clicked the “I did it” button, and MoveBot congratulated me:

Screen Shot 2017-04-14 at 14.47.20

Of course, a concept like this doesn’t work without some gamification, so every time someone¬†completes an exercise, they¬†get some points. At the end of the month, we give out a little prize to the most active members. You may think that this encourages cheating, but that’s why we had everyone sign a mock contract where they promise to try to live healthy and never ever ever lie to MoveBot ;).

We also use our MoveBot to do some team-building. For example, our set of “exercises” also includes “go get lunch for a colleague” or “during lunch, take a walk around the block with a colleague”.

Sharing is caring, so we’ve pushed the basic code behind our MoveBot¬†to GitHub. Keep in mind that this was a quick project (and my first ever Flask/SQLAlchemy application) so the code isn’t that great, but it does what it’s supposed to do :).

 

Critical Samba vulnerability CVE-2017-7494 – Impact on Belgium

The Samba Team disclosed vulnerability CVE-2017-7494: Remote code execution from a writable share.

HD Moore reported that the vulnerability is simple to exploit: on an open, writable SMB share, a shared library has to be uploaded which can then be easily executed on that server. The Samba Team has released patches and new versions (the vulnerability was introduced in version 3.5.0).

As a Brussels-based company, we are interested to understand what traction this vulnerability can get in the Internet landscape in Belgium. We took our question to Shodan.

  • In Belgium, there are (at the time of writing) 628 Samba servers running with a public IP address scanned by Shodan.
  • 370 of those servers require no authentication.
  • 301 of those servers share disks.
  • 266 of those servers use a vulnerable Samba version (we found no reported versions that include the fix).
  • And finally, 77 of those servers share a disk with read-only property explicitly set to false.

Breaking these down by OS, Shodan reports:

  • 38 Unix servers,
  • 30 Windows 6.1 servers and
  • 9 QTS servers (QNAS OS).

Several of the servers reporting as Windows 6.1 OS look to be honey pots.

If we filter these remaining servers for NAS devices (by looking at the comment of the IPC$ share), we end up with 33 servers.

All in all, a small set of potentially vulnerable devices. This analysis is solely based on Shodan data, we did not execute any scans ourselves.

Post created by:
Didier Stevens
Senior malware analyst @ NVISO

Using binsnitch.py to detect files touched by malware

Yesterday, we released binsnitch.py Рa tool you can use to detect unwanted changes to the file sytem. The tool and documentation is available here: https://github.com/NVISO-BE/binsnitch.

Binsnitch can be used to detect silent (unwanted) changes to files on your system. It will scan a given directory recursively for files and keep track of any changes it detects, based on the SHA256 hash of the file. You have the option to either track executable files (based on a static list available in the source code), or all files.

Binsnitch.py can be used for a variety of use cases, including:

  • Use binsnitch.py to create¬†a baseline of trusted files for a workstation (golden image) and use it again later on to automatically generate a list of all modifications made to that system (for example caused by rogue executables installed by users, or dropped malware files). The baseline could also be used for other detection purposes later on (e.g., in a whitelist);
  • Use binsnitch.py to automatically generate hashes of executables (or all files if you are feeling adventurous) in a certain directory (and its subdirectories);
  • Use binsnitch.py during live malware analysis to carefully track which files are touched by malware (this is the topic¬†of this blog post).

In this blog post, we will use binsnitch.py during the analysis of a malware sample (VirusTotal link:
https://virustotal.com/en/file/adb63fa734946d7a7bb7d61c88c133b58a6390a1e1cb045358bfea04f1639d3a/analysis/)

A summary of options available at the time of writing in binsnitchy.py:

usage: binsnitch.py [-h] [-v] [-s] [-a] [-n] [-b] [-w] dir

positional arguments:
  dir               the directory to monitor

optional arguments:
  -h, --help        show this help message and exit
  -v, --verbose     increase output verbosity
  -s, --singlepass  do a single pass over all files
  -a, --all         keep track of all files, not only executables
  -n, --new         alert on new files too, not only on modified files
  -b, --baseline    do not generate alerts (useful to create baseline)
  -w, --wipe        start with a clean db.json and alerts.log file

We are going to use binsnitch.py to detect which files are created or modified by the sample. We start our analysis by creating a “baseline” of all the executable files in the system. We will then execute the malware and run binsnitch.py again to detect changes to disk.

Creating the baseline

Capture.PNG

Command to create the baseline of our entire system.

We only need a single pass of the file system to generate the clean baseline of our system (using the “-s” option). In addition, we are not interested in generating any alerts yet (again: we are merely generating a baseline here!), hence the “-b” option (baseline). Finally, we run with the “-w” argument to start with a clean database file.

After launching the command, binsnitch.py will start hashing¬†all the executable files it discovers, and write the results to a folder called binsnitch_data. This can take a while, especially if you scan an¬†entire drive¬†(“C:/” in this case).

Capture.PNG

Baseline creation in progress … time to fetch some cheese in the meantime! ūüźÄ ūüßÄ

After the command has completed, we check the alerts file in “binsnitch_data/alerts.log”. As we ran with the “-b” command to generate a baseline, we don’t expect to see alerts:

Capture 2.PNG

Baseline successfully created! No alerts in the file, as we expected.

Looks good! The baseline was created in 7 minutes.

We are now ready to launch our malware and let it do its thing (of-course, we do this step in a fully isolated sandbox environment).

Running the malware sample and analyzing changes

Next, we run the malware sample. After that, we canrun binsnitch.py again to check which executable files have been created (or modified):

Capture.PNG

Scanning our system again to detect changes to disk performed by the sample.

We again use the “-s” flag to do a single pass of all executable files on the “C:/” drive. In addition, we also provide the “-n” flag: this ensures we are not only alerted on modified executable files, but also on new files that might have been created¬†since the creation of the baseline. Don’t run using the “-w” flag this time, as this would wipe¬†the baseline results. Optionally, you could also add the “-a” flag, which would track ALL files (not only executable files). If you do so, make sure your baseline is also created using the “-a” flag (otherwise, you will be facing a ton of alerts in the next step!).

Running the¬†command above will again take a few minutes (in our example, it took 2 minutes to rescan the entire “C:/” drive for changes). The resulting alerts file (“binsnitch_data/alerts.log”) looks as following:

Capture.PNG

Bingo! We can clearly spot suspicious behaviour now observing the alerts.log file. ūüĒ•

A few observations based on the above:

  • The malware file itself was detected in “C:/malware”. This is normal of-course, since the malware file itself was not present in our baseline! However, we had to copy it in order to run it;
  • A bunch of new files are detected in the “C:/Program Files(x86)/” folder;
  • More suspicious though are the new executable files created in “C:/Users/admin/AppData/Local/Temp” and the startup folder.

The SHA256 hash of the newly created startup item is readily available in the alerts.log file: 8b030f151c855e24748a08c234cfd518d2bae6ac6075b544d775f93c4c0af2f3

Doing a quick VirusTotal search for this hash results in a clear “hit” confirming our suspicion that this sample is malicious (see below). The filename on VirusTotal also matches the filename of the executable created in the C:/Users/admin/AppData/Local/Temp folder (“A Bastard’s Tale.exe”).

Screen Shot 2017-05-17 at 00.28.05.png

VirusTotal confirms that the dropped file is malicious.

You can also dive deeper into the details of the scan by opening “binsnitch_data/data.json” (warning, this file can grow¬†huge over time, especially when using the “-a” option!):

Capture.PNG

Details on the scanned files. In case a file is modified over time, the different hashes per file will be tracked here, too.

From here on, you would continue your investigation into the behaviour of the sample (network, services, memory, etc.) but this is outside the scope of this blog post.

We hope you find binsnitch.py useful during your own investigations and let us know on github if you have any suggestions for improvements, or if you want to contribute yourself!

Squeak out! ūüźĀ

Daan

Wcry ransomware – Additional analysis

Introduction
Since May 12, a large number of organisations has fallen victim to the “wcry” (or “Wanacry”) ransomware, which abuses the SMB exploits / vulnerabilities that were famously released in the Shadow Brokers data dump in April 2017. Our aim in this short blog post is not to repeat existing information, but communicate some additional information that was derived¬†by our NVISO CERT.

Note that our analysis is still ongoing and we will update our post with additional information, our CERT team is advising NVISO’s customers as we speak. Should you have any questions or require emergency support, please don’t hesitate to contact our 24/7 hotline on +32 (0)2 588 43 80 or incidents@nviso.be.

In short, the ransomware appears to initially enter the environment by traditional phishing (or via systems exposing SMB to the Internet), after which it leverages aforementioned SMB RCE (Remote Code Execution) vulnerabilities¬†(MS17-010) to spread in the network like wildfire. The combination of “standard” ransomware with a recent remote code execution exploit make for a very effective attack, which is¬†evidenced by the¬†impact it has caused on a global scale.

On 13 May, it was reported that wcry, before starting its encryption process, attempts to connect to a seemingly random domain name (www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com) (EDIT: On May 15th, a second kill-switch domain was found in a new sample: www[.]ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com).

If these¬†domains can be contacted, the malware stops its operations. This is most likely a kill-switch that was built in, but not effectively used, as the domain name had not been registered by the attackers. It has been registered by security researches in the meantime, hindering the ransomware’s advance. Note that the kill-switch is not proxy aware and is thus ineffective in environments where a proxy is used to access the Internet (NVISO’s analyst Didier Stevens published a quick-post on the killswitch here).

For additional background information, the following articles & blog post provide a good description of the observed wcry activity:

The main recommendations to prevent / limit the impact of wcry:

  • 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;
  • If you cannot install the patch timely, TearSt0pper (developed by Rendition InfoSec) can be deployed to prevent the encryption from taking place;
  • Ensure Windows SMB services (typically TCP port 445) are not directly exposed to the Internet;
  • Implement network segmentation between different trust zones in the network;
  • Ensure recent back-ups are available offline and can be easily restored;
  • Upon infection: isolate any infected¬†hosts from the network;
  • Continue end-user awareness to prevent the initial compromise through phishing;
  • Implement mail sandboxing solutions to block incoming malicious mail attachments.

Additional analysis
Throughout the weekend, our analysts further investigated the attack, noticing only 2 known variants of the “wcry” ransomware were uploaded from Belgium on VirusTotal. Given the global scale of the attack, this is a surprisingly low number of hits.

From an analyst perspective, the malware does not take big efforts to obfuscate itself and a simple static analysis (e.g. looking for strings) comes up with a large number of strings that could be used in YARA rules:

  • The ransomware manual language files that are dropped: (*.wnry)
  • It uses icacls to change permissions, using the following hard-coded command: “icacls . /grant Everyone:F /T /C /Q
  • Unicode string in the executable “WanaCrypt0r”
  • The ransomware¬†creates a¬†Windows registry value to ensure persistence (survival upon reboot). We observed different variants of this behaviour, 2 examples are below:

cmd.exe /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v obsbeuqp321″ /t REG_SZ /d “\”C:\WINDOWS\system32\tasksche.exe\”” /f

cmd.exe /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v “mzaiifkxcyb819” /t REG_SZ /d “\”C:\tasksche.exe\”” /f

Note the creation of the “taschsche.exe” executable, which is different from the normal “taschsche.exe” (part of Windows).

Update 1

As stated, on networks where a proxy is the only way to access the Internet (e.g. corporate networks), the killswitch will not work because the code is not proxy aware. This means that the malware will attempt to resolve the killswitch domain name with internal DNS, and if it receives a DNS reply with an IP address, it will proceed with an HTTP request. It will not connect to the proxy.

Corporations are configuring internal DNS with the killswitch domain name and an internal sinkhole as mitigation. This prevents the sample from activating, provided that the sinkhole server sends a reply.

The reply can be a 404, that will work too. It can even be a single character x send via the TCP connection, that is fine too. But something has to be replied, just opening the connection and closing it, without sending anything to the malware, will result in activation of the malware.

FYI: this was tested via dynamic analysis with sample 5ad4efd90dcde01d26cc6f32f7ce3ce0b4d4951d4b94a19aa097341aff2acaec and with our own custom code simulating the killswitch test in the malware.

Our analysis is still ongoing and we will update our post with additional information, as our CERT team is advising NVISO’s customers as we speak. Should you have any questions or require emergency support, please don’t hesitate to contact our 24/7 hotline on +32 (0)2 588 43 80 or incidents@nviso.be. We would be happy to help!

NVISO at Hack Belgium

Last week, a few of us attended the first edition of Hack Belgium. Describing what Hack Belgium is turns out to be a bit difficult: is it a conference? A hackaton? A hands-on workshop? A technology fair? A pitch? In my view, it’s all of those combined – and that made the event so interesting!

2017-05-04 16.55.56.jpg

9AM – Daan, Jeroen, Kris & Kurt¬†looking sharp at¬†Hack Belgium ( … and ready for some ‚ėēÔłŹ!).

Hack Belgium offers its attendees 14 crucial challenges¬†around topics that keep our world busy: from healthcare to mobility and building intelligent cities. Over the course of 3 days,¬†all attendees put their heads together to come up with a bright solution to these challenges. With the help¬†of more than 300 experts, it’s certainly a great experience and exercise in idea generation! The¬†objective is to pitch your idea on Saturday and to walk out of Hack Belgium with¬†a blueprint to start working on your project.

2017-05-05 12.19.15.jpg

Our CEO Kurt ready to escape reality ūüē∂.

OK, I have to confess Рwe did not stay until Saturday for our pitch, however we did have a lot of fun and interesting moments on Thursday and Friday! We worked on a concept for the media to bring news in a more balanced format, we did a workshop on designing connected projects, we attended an expert session on the state of Virtual Reality (VR) and Augmented Reality (AR), and we had fun playing around with IBM Watson and other upcoming technologies.

IMG_1220.JPG

Kris showing off his drawing skills ūüźĀ.

Pulling off this type of event at this scale takes a lot of preparation (and guts!) Рwe want to congratulate  the Hack Belgium staff and all the volunteers involved! You truly made this into an interesting & worthwhile event.

We hope to¬†be present for Hack Belgium 2018 and beyond (… and we will stay for the pitch, promise ūüźÄ!).

A few more impressions after the break!

IMG_1221.JPG

Proud to say we didn’t lose any fingers playing around with these beasts! ūüĖź

IMG_1223.JPG

Beep Boop Beep Boop

2017-05-05 15.43.58.jpg

Playing around with creative ways to design connected products during a workshop. My drawing skills are inferior to the one from Kris, so no close-up ūüėÉ!