Category Archives: cyber threats

Hack Our Train

This year, in an effort to raise awareness about IoT security, we launched the Hack Our Train challenge. For over three weeks, a model train tirelessly chugged on its tracks inside our IoT village at Co.Station Brussels and then once more for two days at BruCON 2017. We provided it with an emergency brake system powered by IoT technologies and challenged people to hack it and stop the train! With every successful hack, the train stopped, creating a service disruption. A live-stream allowed hackers to monitor the effects of their attacks.

The Hack Our Train challenge was actually composed of two parts: a local one, situated close to the IoT village and then its online counterpart. The local challenge did not require any specific technical skills. It invited people to try and break the pin of the controller that activates the emergency brake mechanism. Check out this video of people having fun with the controller:

But, the online part is where things became really interesting! Over the course of the challenge, only a handful of people succeeded in figuring it out and remotely stopped the train… In this post, we’ll provide a walk-through of the challenge and focus on some of the vulnerabilities featured in it and, more importantly, on ways to fix them.

Hunt for the firmware

On the challenge website, we provided aspiring hackers with the following scenario: Bob, one of the IoT village’s railroad technicians, recently had to update the¬†emergency brake panels. Unfortunately Bob left his USB flash drive laying around and Eve found it and made its content available online!

The first step is to analyze the USB’s contents. It is a zip archive containing two files: firmware.enc, which conveniently hints to the encrypted firmware and a binary file called firmware_updater. The firmware updater is used to decrypt the firmware and then upload it to the control panel via a serial connection.

If we execute it on a Linux machine, the firmware_updater asks us for a pin before decrypting the firmware. People who braved the challenge came up with all sorts of clever ways of cracking the firmware_updater binary and forcing it to decrypt the firmware.

For now, we will resist the temptation of breaking out our dissassemblers and debuggers and we will just look at the strings inside the updater. There are some really interesting parts:

strings1

strings2

If we think this out (of course, dissassembling would make this much easier), the firmware seems to be encrypted using AES. To perform the decryption ourselves, we would need the key and the initialization vector (IV). Luckily, these are hard-coded into the firmware (see image above).

So, we just need to turn those into their hexadecimal counterparts and we are set:

bash openssl enc -aes-128-cbc -d -in firmware.enc -out firmware
-iv 766563353667647639396e6e73647161 -K 686f746b3138313965663132676a7671

Vulnerability: use of hardcoded cryptographic keys.

Fix: if possible, avoid using schemes that require hardcoded keys. If using a hardcoded key is unavoidable, there are techniques that can be employed to make the key harder to recover. Ideally, decryption should be performed directly on the embedded device, which avoids the need to expose the key in the firmware updater.

One last word on the update procedure we just cracked: now that we have the keys, no one can stop us from modifying the decrypted firmware to add or remove some functionalities, encrypting it again and uploading it to the device. The emergency controller would have no means of knowing if the firmware has been tampered with.

Vulnerability: firmware not digitally signed.

Fix: Digitally sign the firmware so that the embedded device can verify its authenticity.

Inside the firmware

Phew, we have the firmware, now comes the hard part: we have to reverse engineer it and find a way of remotely trigger the emergency brake mechanism.

Using the file command on the firmware reveals it is in fact a Java archive. This is really good news: using a Java decompiler, we can easily recover the source code.

Vulnerability: code is easy to reverse engineer. Attackers have easy access to the internal workings of the application, which makes it easier for them to find exploits.

Fix: use a code obfuscation tool – there are many available online, both free and commercial. Once you have used the tool on your code, test your application to make sure that it is still functioning correctly. Remember that obfuscation is not a silver bullet but it can drastically increase the effort required for an attacker to break the system.

Before looking at the code, let’s try running the firmware. We are greeted with a status page containing a button to initiate an emergency brake, but we need a pin.

screen1screen2

A quick look inside the source code reveals that it is simply “1234”. We have managed to unlock the button. Spoiler: it doesn’t work!

Vulnerability: use of hardcoded passwords.
In our scenario, the password was of no immediate use. Still, this would be harmful if we ever had access to a real emergency brake controller.

Fix: if the password must be stored inside the application, it should at least be stored using a strong one-way hash function. Before hashing, the password should be combined with a unique, cryptographically strong salt value.

In order to understand what is going on, we can simply look at the debug messages conveniently left behind in the console. Seems like the protocol used is MQTT and for some reason, we receive an authentication failure error when we try to perform an emergency brake.

Vulnerability: leftover debug messages containing useful information.

Fix: scan your code for forgotten prints (system.outs in our case) and remove them before release, or disable them at runtime.

Look below the hood

Before going further, let’s take a step back and have a closer look at the architecture of our system. This step was of course not needed to solve the challenge but we thought it complements nicely to this walk-through!

As we just discovered by looking at the source code, communication is based on the MQTT protocol, often found among IoT applications. MQTT works on top of TCP/IP and defines two kinds of entities: Subscribers and Publishers. Publishers send messages on communication channels called Topics. Subscribers can register and read messages on specific Topics. These messages are relayed with the help of a server (also called a Broker).

circuit

This is a look below the hood of the mountain (this was our beta setup, our final circuit was much cleaner!). Two elements steal the show: an Arduino and a Raspberry Pi. The Arduino is the muscle: it controls the transistor that stops the train. The Pi is the brains: when it receives an emergency brake message, it orders the Arduino to stop the train.

Both the emergency brake controller (where the firmware runs – it is not shown in the picture) and the Raspberry Pi (shown in the picture) are connected to the internet. They communicate with the MQTT Broker to exchange MQTT messages. The Pi publishes messages concerning the train’s speed but it is also subscribed to a topic waiting for emergency brake messages. The controller displays the train’s current speed and, when the emergency brake is activated, it publishes an emergency brake message that the Broker relays to the Pi.

Of course, not anyone can send an emergency brake message to the server. In our infrastructure, authentication is based on JWT tokens. These are issued by the server relaying the MQTT messages and they are signed using the server’s private key. When¬† clients try to authenticate using one of those tokens, the server can verify their authenticity using its public key.

To clear all this up, we have created an overview of the MQTT communications going on in the images below:

speed

brake

Tokens, tokens everywhere…

Back the authentication problem. Digging into the source code confirms that authentication is JWT token based. Maybe there is something wrong with the token? Another file inside the JAR that immediately draws our attention is notes.txt. A quick look reveals some notes of a developer that was worried about his JWT token expiring. We can easily verify the creation date of the token here. Seems like out token is really old and as we don’t have the authentication server’s private key, we cannot create a new one.

Vulnerability: old and unused left behind files containing sensitive information.

Fix: before publishing your product, make sure to remove every non-essential ressource.

Knowing how the authentication works, it is time to turn to our favorite search engine for more intelligence. Let’s try jwt token vulnerability. The top result states “Critical vulnerabilities in JSON Web Token libraries“: perfect!

The author does a great job of explaining the vulnerability and how it can be exploited, so we leave you in his hands. For the purposes of this post, the idea is that if we create a forged token using the authentication server’s public key as a HMAC secret key, we can fool the server into verifying it using HMAC instead of RSA, which results in the server accepting our token.

Attack!

Having identified the vulnerability, it is time to perform our attack. For that, we need the server’s public certificate, which is kindly included in the JAR as well. As mentioned in the notes file, it has been converted to a format compatible with Java but the server is more likely using it in PEM format.

Luckily, converting it back is easy:

keytool -importkeystore -srckeystore hot.ks -destkeystore temp.p12
-srcstoretype jks -deststoretype pkcs12

openssl pkcs12 -in temp.p12 -out public.pem

Next, we have to create our malicious token. You can do this in the language of your choice. We used the jwt-simple node.js module.

With the malicious token crafted, we can finally perform the attack. The easiest way is to reuse the code included in the testMQTT.java file, conveniently forgotten inside the JAR. We just have to replace the token found in the code, compile the code and execute it from the terminal.

The select few who made it this far in the challenge saw the train stop on the live-stream and received the flag!

Vulnerability: using components with known vulnerabilities.

Fix: apply upgrades to components as they become available. For critical components (for example, those used for authentication), monitor security news outlets (databases, mailing lists etc.) and act upon new information to keep your project up to date.

Lessons learned

Our challenge involved a toy train but the IoT vulnerabilities demonstrated inside are the real deal. We added each one of them to the IoT challenge because we have come across them in the real world.

On a final note, we would like to congratulate those who were able to hack our train and we sincerely hope that all of you enjoyed this challenge!

KRACKing WPA2

A new vulnerability in the WPA2 protocol was discovered by¬†Mathy¬†Vanhoef¬†(researcher at KU Leuven) and published yesterday. The vulnerability – dubbed¬† “KRACK” – enables an attacker to intercept WPA2 encrypted network traffic between a client device (e.g. mobile or laptop) and a router. Depending on the network configuration¬†it is even possible¬†for an attacker to alter or inject data.¬†Since the vulnerability lies in the WPA2 protocol, most platforms are susceptible to the attack. However, the impact is even higher on Android 6.0+ and Linux devices due to their specific implementation of WPA2.

The original publication can be found at https://www.krackattacks.com, with full details, a demonstration of the attack, and recommendations.

How does it work?

The KRACK vulnerability can be exploited by using Key Reinstallation AttaCKs. When a device wants to connect to a wireless access point, the WPA2 protocol will use a 4-way handshake. Part of this handshake consists of an acknowledgment that is sent from the client device to the wireless access point to ensure the client has successfully received the signed key. However, until the wireless access point has received the acknowledgment, it will continuously retransmit the signed key. If the attacker is able to block the acknowledgement from being sent to the wireless access point, the attacker is able to record and replay the signed key, which ensures the reinstallation of an already used key on the client’s device. As soon as the key is installed, it will be used to encrypt the network traffic between the client and the wireless access point. Since the attacker knows the keystream, he is able to decrypt the network traffic.

Since this attack exploits a vulnerability in the four-way handshake, all WPA versions are vulnerable.

Are all devices vulnerable?

Since this vulnerability is found in the WPA2 protocol, all platforms, such as Windows, Linux, MacOs, iOs, OpenBSD and Android can be targeted. Linux and Android 6.0+ devices are especially vulnerable, because the WiFi client will clear the encryption key from memory after installation. If the Android device is told to reinstall they key, the cleared out key will be installed, which is actually an all-zero key. This makes it trivial for an attacker to intercept and inject or alter data sent by these devices.

Does this mean that we need to stop using WPA2?

Although an attacker is able to intercept traffic and in some cases traffic can be altered or injected, this attack can only be performed when the attacker is in close proximity of the client’s device and wireless access point.

If the attacker has successfully exploited this vulnerability, traffic over TLS, such as HTTPS or VPN traffic, will not be accessible to the attacker.

What should we do? 

When this vulnerability was discovered, it was first disclosed to various vendors. Many vendors (e.g. Microsoft, Cisco) have already released patches for this issue. Install the available patches on all your devices or contact your vendors to see if a patch is available. A list with all patches per vendor can be found on https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519.

Furthermore, it is strongly advised to only use encrypted connections, such as HTTPS or a VPN connection, when sensitive content is transmitted over WiFi networks.

Additionally, watch out for rogue access point in your surroundings, office buildings.

More information? 

NVISO‚ÄĮanalysts¬†are still working on additional research and will update this blogpost with any results.

Should¬†you¬†require¬†additional¬†support,¬†please¬†don’t¬†hesitate¬†to¬†contact¬†our¬†24/7 hotline on +32 (0) 588 43 80¬†or csirt@nviso.be.

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

YARA rules for CCleaner 5.33

First reported by Talos and Morphisec, the compromise of CCleaner version 5.33 is still making news.

At NVISO Labs, we created YARA detection rules as soon as the news broke, and distributed these rules to our clients subscribed to our NVISO Security Advisories. In a later blog post, we will explain in detail how to create such YARA rules, so that you can do the same for your organization.

Here are the YARA rules we created:

// YARA rules compromised CCleaner
// NVISO 2017/09/18
// http://blog.talosintelligence.com/2017/09/avast-distributes-malware.html

import "hash"

rule ccleaner_compromised_installer {
	condition:
		filesize == 9791816 and hash.sha256(0, filesize) == "1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff"
}

rule ccleaner_compromised_application {
	condition:
		filesize == 7781592 and hash.sha256(0, filesize) == "36b36ee9515e0a60629d2c722b006b33e543dce1c8c2611053e0651a0bfdb2e9" or
		filesize == 7680216 and hash.sha256(0, filesize) == "6f7840c77f99049d788155c1351e1560b62b8ad18ad0e9adda8218b9f432f0a9"
}

rule ccleaner_compromised_pdb {
	strings:
		$a = "s:\\workspace\\ccleaner\\branches\\v5.33\\bin\\CCleaner\\Release\\CCleaner.pdb" 
		$b = "s:\\workspace\\ccleaner\\branches\\v5.33\\bin\\CCleaner\\ReleaseTV\\CCleaner.pdb" 
	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and ($a or $b)
}

You can scan the C: drive of a computer with YARA like this:

yara64.exe -r ccleaner.yara C:\

And there are also many other scanning tools that include the YARA engine, like ClamAV.

Hunting

The first 2 rules we created are hash based, but the third rule (ccleaner_compromised_pdb) is based on a particular string found in CCleaner’s 32-bit executables. This string is the full path of the Program Database (PDB) file, a debug file created by default by Visual Studio and referenced in compiled executables.

With this rule, we were able to identify 235 files on VirusTotal. Most of these are actually container files (like ZIP files): CCleaner is a popular application, and is distributed through various channels other than Piriform’s website. We saw examples of portable application packages distributing this compromised version of CCleaner (like LiberKey) and also RAR files with pirated versions of CCleaner.

23 files were actual executables, and were all compromised versions of the 32-bit executable of CCleaner version 5.33, except one. Most of these files did not have a (valid) signature: they were modified versions, e.g. cracked and infected with other malware.

Only one executable detected by our ccleaner_compromised_pdb rule was not infected: an executable with SHA256 hash c48b9db429e5f0284481b4611bb5b69fb6d5f9ce0d23dcc4e4bf63d97b883fb2. It turns out to be a 32-bit executable of CCleaner version 5.33, digitally signed on 14/09/2017, e.g. after Talos informed Avast/Piriform. The build number was increased with one (6163 instead of 6162). This executable was signed with the same certificate that was used for the compromised version 5.33 (thumbprint f4bda9efa31ef4a8fa3b6bb0be13862d7b8ed9b0), and also for follow-up version 5.34. Yesterday (20/9/2017), Piriform finally released a new version (5.35) signed with a new digital certificate obtained yesterday.

At this moment, we are uncertain about the origins and purpose of this particular executable (c48b9db429e5f0284481b4611bb5b69fb6d5f9ce0d23dcc4e4bf63d97b883fb2).

Are you infected?

Our rules allow you to detect compromised CCleaner executables in your environment, but this does not imply that the machines identified by these rules were infected.

Our analysis shows that the compromised CCleaner installer (version 5.33) will install 32-bit and 64-bit versions of the CCleaner executables on a Windows 64-bit machine, and only the 32-bit version on a Windows 32-bit machine.

The shortcuts (like Start and Desktop shortcuts) deployed during the install on Windows 64-bit machines will point to the 64-bit executable, hence normal usage on a Windows 64-bit machine will execute 64-bit CCleaner.

Only the 32-bit executable of CCleaner is compromised.

It is therefore perfectly possible that compromised 32-bit executables of CCleaner are detected on Windows 64-bit machines with the YARA rules we provided, but that this compromised version was never executed.

If the compromised 32-bit executable runs successfully, it will create the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Piriform\Agomo

Two values will be found for this key: MUID and TCID

Conclusion

We recommend that you check for the presence of this registry key, should our YARA rules detect compromised CCleaner installations on your machines.

Compromised machines should be reinstalled after a DFIR investigation.

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

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.

Hunting malware with metadata

A while ago Michel wrote a blog post Tracking threat actors through .LNK files.

In this post, we want to illustrate how VirusTotal (retro) hunting can be leveraged to extract malware samples and metadata linked to a single threat actor. We use the power of YARA rules to pinpoint the metadata we are looking for.

With some of the metadata extracted from the .LNK file we wrote about in our previous blog post (Volume ID and MAC address), we’re going to search on VirusTotal for samples with that metadata. It is clear from the MAC address 00:0C:29:5A:39:04 that the threat actor used a virtual machine to build malware: 00:0C:29 is an OUI owned by VMware. We wonder if the same VM was used to create other samples.
With a VirusTotal Intelligence subscription, one can search through the VirusTotal sample database, for example with YARA rules. We use the following YARA rule for the metadata:

rule MALDOC_LNK {
strings:
$BirthObjectId = {C2 CC 13 98 18 B9 E2 41 82 40 54 A8 AD E2 0A 9A}
$MACAddress = {00 0C 29 5A 39 04}
condition:
all of them
}

VTI supports hunting and retro-hunting with YARA rules. With hunting, you will be informed each time your YARA rules triggers on the VT servers each time a newly submitted sample matching your rule. With retro-hunting, YARA rules are used to scan through 75TB of samples in the VT database. This correspond more or less to the set of samples submitted in the last three months.
Here is the result from a retro-hunt using YARA rule MALDOC_LNK:

Next step is to download and analyse all these samples. Since we did not include a file type condition in our YARA rule, we get different types of files: Word .doc files, .lnk files, raw OLE streams containing .lnk files, and MIME files (e-mails with Word documents as attachment).
With this command we search for strings containing ‚Äúhttp‚ÄĚ in the samples:

So we see that the same virtual machine has been used to created several samples. Here we extract the commands launched via the .lnk file:

There are 2 types of commands: downloading one executable; and downloading one executable and a decoy document.

The metadata from the OLE files reveals that the virtual machine has been used for a couple of weeks:

Conclusion

With metadata and VirusTotal, it is possible to identify samples created by the same actor over a period of 3 months. These samples can provide new metadata and IOCs.

Mitigation strategies against cyber threats

So it’s been a good 2 months since we have been in business! We thought we‚Äôd to take some time to reflect on¬†these two months, in which we’ve seen quite some interesting security news including the well-known Mandiant report on APT1 and the widespread Java chaos.


Last week, ENISA published a “Flash Note” on Cyber Attacks, urging organizations to take precautions to prevent cyber attacks. In order to protect against cyber threats, they provide the following recommendations:

  • Protect targets to avoid weaknesses being exploited by adversaries: prevention should be the primary defence against attacks.
  • Consider the use of more secure communication channels than e-mail in order to protect users from spoofing and phishing attacks.
  • Proactively reduce your attack surface by reducing the complexity of software installed on user devices and reducing the permissions of users to access other devices, services and applications by applying the principle of least privilege.
While we believe these are good recommendations, we are also convinced that it is often not easy for organizations to practically implement this type of recommendations. 

An interesting, more practical perspective on defending against cyber threats is provided by Australia’s DSD (Defence Signals Directorate). In the same spirit of the “SANS Top 20 Critical Controls“, the DSD has summarized a¬†top 35 of mitigation strategies to protect¬†against cyber threats¬†– a¬†ranking based on DSD’s analysis of reported security incidents and vulnerabilities discovered on Australia’s government networks.

That top 35 is of course just another large list of security controls that should be implemented. Interestingly enough however, the DSD noticed that 85% of all cyber threats can be mitigated by only implementing the top 4 of these 35 strategies. This top 4 boils down to the following controls:

Let’s face it:¬†with malware developing at the pace it currently does, it is unrealistic to expect that antivirus¬†solutions will offer in-depth protection against every single malware infection. They are a good and necessary first step,¬†detecting older and known malware, but the most effective method is not trying to detect malware: it is to¬†allow only known, valid programs to run.

While application whitelisting clearly is the “way to go” with regards to security, it’s often not an easy choice for various reasons (“Damn you IT, this is not workable!”, “We are a company with an open culture, we don’t lock down our desktops”, “We trust our employees”,…). If you ever manage to convince your organization to consider application whitelisting, another daunting challenge awaits the IT administrator: creating and managing the application white list.

Now, establishing what ‚Äėvalid‚Äô applications are for your environment is no easy task. Next to the usual client-side applications such as PDF readers and other office software, the list of approved software will also include¬†applications specific to your environment. So how do you about creating / managing this type of whitelist? Here’s a couple of ideas:

  • To create your initial white list, a good idea would be to use a normal employee workstation and list all of the installed applications. In a reasonably static environment, this could be a good approach, seeing as normal employees wouldn’t be able to install new applications themselves anyhow.
  • A less “strict” approach would be the use of “software signing”. You could protect your environment by only allowing software signed by trusted developers / vendors to be installed.

If you cannot implement application whitelisting in a “blocking” mode, consider configuring it to only monitor (not block) applications that are not on the white list. This will provide you with additional insights on the software running in your environment, without further restricting your employee workstations.


When it comes down to tooling, there’s several commercial solutions available.¬†For typical large Windows environments, a good solution is AppLocker which further builds on the older “Software Restriction Policies”.

This is where it all starts. We are still seeing too many organizations that lag behind when it comes to the roll-out of security patches for operating systems and server software. 

During the majority of our security assessments and penetration tests, we are frightened by the number of hosts that are missing 6-months old critical security patches. Unfortunately, any one of these critical risks is usually enough to compromise an entire Windows domain.

In order to keep abreast of new security vulnerabilities, organizations should set up an effective patch management process. I’m sure most of you have this type of process, so let’s take a closer look and see whether your process includes:

  • A security patch assessment that verifies to what extent security patches are applicable to the organization and what the actual impact is;
  • A release cycle for security patches that includes proper testing and a controlled release;
  • An emergency process for urgent and critical patches (based on the criticality of the patch, you should consider what the biggest risk is: following the process and increasing your exposure window or immediately applying the patch and risking availability issues?);
  • An overview of all systems and their configuration to ensure all concerned systems are patched;
  • A process for temporary workarounds;
  • A system that provides metrics and monitors the effectiveness of the process itself.
Server-side vulnerabilities usually receive the most attention from organizations, even though patching client¬†applications deserves just as much focus. Using security’s weakest link (humans), attackers often use a combination¬†of trickery (e.g. spear phishing) to exploit vulnerabilities in client applications.

Just consider the following vulnerabilities for JRE (the Java Runtime Environment):


Java Runtime Environment (JRE) vulnerability overview

These vulnerabilities often remain “hidden”, as your typical network vulnerability scanners (e.g. Qualys, NeXpose, Nessus,…) will not pick them up by default.

There’s a couple of ways of identifying what software is running on your client machines:

Network scanners can usually be configured to actually authenticate to hosts in your environment and detect vulnerabilities in the installed client software.¬†Although this type of configuration works well and provides you with the required information, it is something that should be implemented and monitored very carefully.¬†After all, you are providing an automated vulnerability scanner with (administrative) credentials to your client machines.¬†I’m sure most of you had some incidents in the past where a vulnerability scanner did some things you didn’t expect (e.g. use an “unsafe check” that takes down a vulnerable server). Now imagine the havoc a scanner could cause when he has administrative privileges to 90% of your network.

Install “application monitoring” software on your client machines. An alternative to the above approach is to install a small monitoring tool on your client machines that sends information on installed software to a central server. You can then centrally track the different software versions in your network. A possible pitfall here could be privacy issues that would prevent you from installing this type of “monitoring software” on your employee machines, so it’s something to first check with your legal department.

Once a system has been compromised (in any way possible), an attacker will attempt to further escalate his privileges both on the system and inside the victim network. To minimize and to track administrative privileges will help you contain malware infections and compromises (which will eventually occur in any environment).

As a good example of this, many IT organizations have an abundance of administrative privileges attributed to IT staff (e.g. the majority of IT staff has domain administrator privileges). It is understandable that “the business needs to keep running”, but there’s a couple of ways to improve the situation without “crippling” system administrators:

  • Provide system administrators with two accounts: one for normal daily usage and one that can be used for administrative tasks.
  • Review administrative accounts and apply the least privilege principle, i.e. system administrators often require elevated privileges, but not “Domain Administrator”.¬†
  • Review application accounts and apply the least privilege principle, i.e. do not let your applications run with SYSTEM privileges.
  • Implement and enforce a proper IAM process for administrative accounts that will monitor the spread and usage of administrative accounts.

Conclusion?
Over the years, a number of organizations invested time in creating “security control lists” to assist organization’s in minimizing their exposure to cyber threats. While most of these are good, we believe Australia’s DSD does a very good job in defining 4 concrete and clear mitigation strategies that can be applied to most organizations.

It’s clear that all of these controls deserve a dedicated blog post that provides additional insights in how they could be implemented. We do hope that this post has given you some food for thought and we‚Äôll make sure to regularly provide you with more insights.¬†

If you’re interested in more NVISO updates and info on how we can help you, please visit www.nviso.be.

References:
Mandiant APT1 report