Author Archives: didiernviso

Painless Cuckoo Sandbox Installation

TLDR: As part of our SANS SEC599 development efforts, we updated (fixed + added some new features) an existing Cuckoo Auto Install script by Buguroo Security to automate Cuckoo sandbox installation (& VM import). Download it from our Github here.

Intro
As a blue team member, you often have a need to analyze a piece of malware yourself. For example, if you discover a malware sample in your network and suspect it might be part of a targeted attack. There’s a few options in this case: you could reverse the sample or do some static analysis, but maybe you want to get a “quick” insight by running it in a sandbox… It is often not desirable to submit your samples to public, online malware analysis services, as this might tip off your adversaries. So… How to proceed?

In the SANS training SEC599 that we’ve co-developed at NVISO (“Defeating Advanced Adversaries – Implementing Kill Chain Defenses”), we decided we wanted to show students how analysis can be performed using Cuckoo sandbox, a popular open source automated malware analysis system (We do love Cuckoo!).

After re-deploying manually Cuckoo a number of times in different environments, I (Erik speaking here) figured there must be a better way… After doing some Google’ing, I found the CuckooAutoinstall script created by Buguroo Security!

An excellent effort indeed, but it hadn’t been updated for a while, so we decided to update this script to include some additional features and enabled it to run with the latest version of Ubuntu (16.04 LTS) and Cuckoo (2.0.5). You can find it on our GitHub repository.

Preparing your sandbox
Before we do a walk-through of this script, let’s pause a moment to consider what it takes to set up a malware analysis environment. The type of analysis performed by Cuckoo can be classified as dynamic analysis: the malware sample is executed in a controlled environment (a Virtual Machine) and its behavior is observed. As most malware targets the Windows operating system and/or the applications running on it, you will need to create a Windows VM for Cuckoo.

You will need to step out of your role as a blue team member to prepare this VM: this VM has to be as vulnerable as possible! To increase the chances of malware executing inside the VM, you will have to disable most of the protections and hardening you would implement on machines in your corporate network. For example, you will not install an anti-virus in this VM, disable UAC, don’t install patches,…

To properly analyze malicious Office documents, you will use an older, unpatched version of Microsoft Office and you will disable macro security: you want the macros to run as soon as the document is opened, without user interaction.

Take your hardening policies and guidelines, and then …, do the opposite! It will be fun (they said…)!

Using CuckooAutoinstall
Installing Cuckoo with CuckooAutoinstall is easy: prepare your VM and export it to the OVA format, update the script with your VM settings, and execute it as root. We will discuss how you can create Cuckoo analysis VMs in a follow-up blogpost!

It’s best that your Ubuntu OS is up-to-date before you launch the script, otherwise you might encounter errors when CuckooAutoinstall will install the necessary dependencies, like this error on Ubuntu:

20180322-101734

Updating the script with your VM settings is easy, these are the parameters you can change:

CUCKOO_GUEST_IMAGE=”/tmp/W7-01.ova”

CUCKOO_GUEST_NAME=”vm”

CUCKOO_GUEST_IP=”192.168.87.15″

INTERNET_INT_NAME=”eth0″

Then execute the script as root. It will take about 15 minutes to execute, depending on your Internet speed and size of your VM. If you are interested in seeing the progress of the script step by step, use option –verbose.

20180322-110123

When the script finishes execution, you want to see only green check-marks:

20180322-110818

Testing your Cuckoo installation
To start Cuckoo, you execute the cuckoo-start.sh script created by CuckooAutoinstall for you:

20180322-111154

20180322-111236

Then you can use a web browser to navigate to port 8000 on the machine where you installed Cuckoo:

20180322-111315

Submit a sample, and let it run:

20180322-111539

20180322-111721

After a minute, you’ll be able to view the report. Make sure you do this, because if you get the following message, your guest VM is not properly configured for Cuckoo:

20180322-111733

The best way to fix issues with your guest VM, is to log on with the cuckoo user (credentials can be found & modified in the CuckooAutoinstall script), start VirtualBox and launch your VM from the “clean” snapshot.

20180322-111802

20180322-111842

Once you have troubleshooted your VM (for example, fix network issues), you take a snapshot and name this snapshot “clean” (and remove the previous “clean” snapshot). Then try to submit again (for each analysis, Cuckoo will launch your VM from the “clean” snapshot).

This will give you a report without errors:

20180322-112326.png

Conclusion
Although installing Cuckoo can be difficult, the CuckooAutoinstall script will automate the installation and make it easy, provided you configured your guest VM properly. We plan to address the configuration of your guest VM in an upcoming blog post, but for now you can use Cuckoo’s recommendations.

It is possible to install Cuckoo (with CuckooAutoinstall) on Ubuntu running in a virtual environment. We have done this with AWS and VMware. There can be some limitations though, depending on your environment. For example, it could be possible that you can not configure more than one CPU for your Cuckoo guest VM. As there are malware samples that try to evade detection by checking the number of CPUs, this could be an issue, and you would be better off using a physical Cuckoo install.

Want to learn more? Please do join us at one of the upcoming SEC599 SANS classes, which was co-authored by NVISO’s experts!

About the authors
Didier Stevens is a malware expert working for NVISO. Didier is a SANS Internet Storm Center handler and Microsoft MVP, and has developed numerous popular tools to assist with malware analysis. You can find Didier on Twitter and LinkedIn.

Erik Van Buggenhout is a co-founder of NVISO with vast experience in penetration testing, red teaming and incident response. He is also a Certified Instructor for the SANS Institute, where he is the co-author of SEC599. You can find Erik on Twitter and LinkedIn.

Creating custom YARA rules

In a previous post, we created YARA rules to detect compromised CCleaner executables (YARA rules to detect compromised CCleaner executables). We will use this example as an opportunity to illustrate how the creation of these custom YARA rules was performed.

In its blog post, Talos shared 3 hashes as Indicators Of Compromise (IOCs):

1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff
6f7840c77f99049d788155c1351e1560b62b8ad18ad0e9adda8218b9f432f0a9
36b36ee9515e0a60629d2c722b006b33e543dce1c8c2611053e0651a0bfdb2e9

Although not explicitly stated in the Talos report, these are SHA256 hashes. We can infer this from the length of the hexadecimal strings. A hexadecimal character represents 4 bits, hence  64 hexadecimal characters represent 256 bits.

Admittedly, YARA is not the best tool to scan files with hashes as IOCs. YARA is designed to use pattern matching to scan malware, and early versions of YARA did not even have the capability to use cryptographic hashes. In later versions, a hash module was introduced to provide this capability.

A simple rule to match files based on a SHA256 IOC can be implemented like this:

import "hash"</p>
<p style="text-align:justify;">rule simple_hash_rule {
condition:
hash.sha256(0, filesize) == "1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff"
}

Line 1 imports the hash module, which we need to calculate the SHA256 value of the content of a file.

The rule simple_hash_rule has just a condition (line 5): the SHA256 value of the content of the file is calculated with method call hash.sha256(0, filesize) and then compared to the IOC as a string. Remark that string comparison is case-sensitive, and that the cryptographic hash functions of the hash module return the hash values as lowercase hexadecimal strings. Hence, we have to provide the IOC hash as a lowercase string.

Using this simple rule to scan the C: drive of a Windows workstation in search of compromised CCleaner executables will take time: the YARA engine has to completely read each file on the disk to calculate its SHA256 value.

This can be optimized by writing a rule that will not hash files that can not possibly yield the hash we are looking for. One method to achieve this, is to first check the file size of a file and only calculate the SHA256 hash if the file size corresponds to the file size of the compromised executable.

This is what we did in this rule:

import "hash"</p>
<p style="text-align:justify;">rule ccleaner_compromised_installer {
condition:
filesize == 9791816 and hash.sha256(0, filesize) == "1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff"
}

In this rule, we first compare the filesize variable to 9791816 and then we calculate the hash. Because the and operator uses lazy evaluation, the right-side operand will only be evaluated if the left-side operator is true. With this, we achieve our goal: only if the filesize is right, will the SHA256 hash be calculated. This will speed up the scanning process by excluding files with the wrong file size.

There is one caveat though: Talos did not report the file sizes for the IOCs they published. However, we were able to obtain samples of the compromised CCleaner files, and that’s how we know the file sizes.

If you are not in a position to get a copy of the samples, you can still search the Internet for information on these samples like the file size. For example, this particular sample was analyzed by Hybrid Analysis, and the file size is mentioned in the report:

You can also find information for this sample on VirusTotal, but the analysis report does not mention the exact file size, just 9.34 MB.

This information can still be used to create a rule that is optimized for performance, by accepting a range of possible file size values, like this:

import "hash"</p>
<p style="text-align:justify;">rule filesize_and_hash {
condition:
filesize &amp;gt;= 9.33 * 1024 * 1024 and filesize &amp;lt;= 9.35 * 1024 * 1024 and hash.sha256(0, filesize) == "1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff"
}

This rule will first check if the file size is between 9.33MB and 9.35MB (1024 * 1024 is 1 MB) and if true, then calculate the hash.

Conclusion

Writing custom YARA rules is a skill that requires practice. If you want to become proficient at writing your own YARA rules, we recommend that you embrace all opportunities to write rules, and step by step make more complex rules.

About the author

Didier Stevens is a malware expert working for NVISO. Didier is a SANS Internet Storm Center handler and Microsoft MVP, and has developed numerous popular tools to assist with malware analysis. You can find Didier on Twitter and LinkedIn.

 

“We are happy to share our knowledge with the community and thus hope you enjoyed the content provided on this article! If you’re interested in receiving dedicated support to help you improve your cyber security capabilities, please don’t hesitate to have a look at the services NVISO offers! We can help you define a cyber security strategy / roadmap, but can also offer highly technical services such as security assessments, security monitoring, threat hunting & incident response (https://www.nviso.be). Want to learn similar techniques? Have a look at the SEC599 SANS class, which was co-authored by NVISO’s experts! (https://www.sans.org/course/defeating-advanced-adversaries-kill-chain-defenses)”

Windows Credential Guard & Mimikatz

Here at NVISO, we are proud to have contributed to the new SANS course “SEC599: Defeating Advanced Adversaries – Implementing Kill Chain Defenses”.

This six-day training focuses on implementing effective security controls to prevent, detect and respond to cyber attacks.

One of the defenses covered in SEC599 is Credential Guard. Obtaining and using credentials and hashes from memory (for example with Mimikatz) is still a decisive tool in the arsenal of attackers, one that is not easy to defend against.
With Windows 10 and Windows Server 2016, Microsoft introduced a feature to mitigate attacks to obtain credentials and hashes: Credential Guard. With Credential Guard, secrets are stored in a hardened and isolated section of your computer, inaccessible from the normal operating system.

Credential Guard relies on a new technology introduced with Windows 10 and Windows Server 2016: Virtual Secure Mode (VSM). VSM is based on the virtualization features of modern CPUs to provide a separate memory space where secrets can be stored. This separate memory space is protected (via hardware) from read and write attempts from processes in the normal operating system’s memory space.

When Credential Guard is enabled, the Local Security Authority Subsystem Service (LSASS) consists of 2 processes: the normal LSA process and the isolated LSA process (which runs in VSM).

Credential Guard

SANS SEC599 day 4: Credential Guard

Tools that recover secrets from LSA, like Mimikatz, are not able to access the isolated LSA process. They cannot extract passwords or inject hashes for pass-the-hash attacks, for example. Hence, Credential Guard is an effective tool to protect credentials stored on Windows machines.

Despite Credential Guard, users with administrative access can still find ways to steal credentials entered on Windows machines. This can be done, for example, with Mimikatz own Security Support Provider. SSPs are packages that participate in the authentication of users: for example, installed SSPs will be called when a user logs on, and will receive the credentials of said user. Windows comes with several SSPs , and custom SSPs can be installed (of course, this requires administrative permissions).

Mimikatz memssp command (available since September 2014) installs a custom SSP in memory (so no DLL is written to disk), that will log all credentials it receives in a text file.

To achieve this, Mimikatz needs to be executed with administrative rights on the target machine and the debug privilege needs to be enabled to allow the LSA processes to be opened and patched:

20180109-105338

Next, Mimikatz’s SSP is injected with the misc::memssp command:

20180109-105415

Now the SSP is installed, Mimikatz can be closed. This SSP will remain in memory as long as Windows is not rebooted.

After a user has performed a log on, Mimikatz’s SSP log C:\Windows\System32\mimilsa.og file can be examined to retrieve the credentials processed by Mimikatz’s SSP:

20180109-105508

Conclusion

Mimikatz can not extract credentials protected by Credential Guard, but it can intercept credentials entered in a Windows machine at log on time, for example. Although Credential Guard will protect credentials in isolated memory, credentials still need to be provided to a Windows machine (like for an interactive logon).

When these credentials are typed, they can still be intercepted and stolen, e.g. with a key logger or with with a custom SSP, as illustrated here. This is however only one of the steps in the attack chain, as this requires administrative rights, it is crucial to restrict and monitor administrative access to your Windows machines.

YARA DDE rules: DDE Command Execution observed in-the-wild

The MS Office DDE YARA rules that we published yesterday detected several malicious documents samples since 10/10/2017.

Remark: the malicious samples we mention were detected with our DDEAUTO rule (Office_DDEAUTO_field); as we feared, the second rule (Office_DDE_field) is generating some false positives and we will update it.

The first sample uses PowerShell to download an executable and run it. With zipdump.py and our YARA rules we can extract the command, and with sed command “s/<[^>]*>//g” we can remove the XML tags to reveal the command:

The second sample is using PowerShell with a second stage DLL (we were not able to recover the DLL):

As could be expected, we also observed many samples that are not truly malicious, but just the samples of persons experimenting with DDE code execution starting 10/10/2017. This could also be the case for the “DLL sample”.

Finally, we observed a malicious campaign spoofing emails from the U.S. Securities and Exchange Commission (SEC)’s EDGAR filing system with .docx attachments abusing DDE code execution.

This campaign used compromised government servers to serve a PowerShell second stage script:

Leveraging compromised government servers increases the success of such campaigns, because of the implied trust associated with government servers.

Talos published an extensive analysis for this campaign. We observed the same samples, and also a sample (email attachment) from the same campaign that uses pastebin to host the second stage:

Should you have to analyze the next stages, know that they are PowerShell scripts that have been compressed and BASE64 encoded. Here is one method to extract these scripts:

New IOCs:

  • bf38288956449bb120bae525b6632f0294d25593da8938bbe79849d6defed5cb
  • 316f0552684bd09310fc8a004991c9b7ac200fb2a9a0d34e59b8bbd30b6dc8ea

Detecting DDE in MS Office documents

Dynamic Data Exchange is an old Microsoft technology that can be (ab)used to execute code from within MS Office documents. Etienne Stalmans and Saif El-Sherei from Sensepost published a blog post in which they describe how to weaponize MS Office documents.

We wrote 2 YARA rules to detect this in Office Open XML files (like .docx):

Update 1: our YARA rules detected several malicious documents in-the-wild.

Update 2: we added rules for OLE files (like .doc) and updated our OOXML rules based on your feedback.

// YARA rules Office DDE
// NVISO 2017/10/10 - 2017/10/12
// https://sensepost.com/blog/2017/macro-less-code-exec-in-msword/
 
rule Office_DDEAUTO_field {
  strings:
    $a = /<w:fldChar\s+?w:fldCharType="begin"\/>.+?\b[Dd][Dd][Ee][Aa][Uu][Tt][Oo]\b.+?<w:fldChar\s+?w:fldCharType="end"\/>/
  condition:
    $a
}
 
rule Office_DDE_field {
  strings:
    $a = /<w:fldChar\s+?w:fldCharType="begin"\/>.+?\b[Dd][Dd][Ee]\b.+?<w:fldChar\s+?w:fldCharType="end"\/>/
  condition:
    $a
}

rule Office_OLE_DDEAUTO {
  strings:
    $a = /\x13\s*DDEAUTO\b[^\x14]+/ nocase
  condition:
    uint32be(0) == 0xD0CF11E0 and $a
}

rule Office_OLE_DDE {
  strings:
    $a = /\x13\s*DDE\b[^\x14]+/ nocase
  condition:
    uint32be(0) == 0xD0CF11E0 and $a
}

These rules can be used in combination with a tool like zipdump.py to scan XML files inside the ZIP container with the YARA engine:

The detection is based on regular expressions designed to detect fields containing the word DDEAUTO or DDE. By dumping the detected YARA strings with option –yarastringsraw, one can view the actual command:

Here is an example of the DDE rule firing:

You can also look for MS Office files containing DDE using this YARA rule in combination with ClamAV as described in this blog post.

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.

Active exploitation of Struts vulnerability S2-052 CVE-2017-9805

Yesterday night (06 September 2017 UTC) we observed active exploitation of Struts vulnerability S2-052 CVE-2017-9805 (announced a day earlier).

Here is the request we observed:

The POST request to /struts2-rest-showcase/orders/3 allowed us initially to detect this attempt.

The packet capture shows that this is a full exploit attempt for reconnaissance purposes: the payload is a /bin/sh command to execute a silent wget command to a compromised Russian website (it includes the name of the scanned site as query). The downloaded content is discarded.

The XML data used in this exploit attempt is slightly different from the Metasploit module for CVE-2017-9805: XML element ibuffer is represented as <ibuffer/> in this exploit attempt, while it is represented as <ibuffer></ibuffer> in the proposed Metasploit module. Both forms are functionally equivalent.

We did find an older version of this script that is used in this attack here. This shows how fast attackers attempt to abuse newly discovered vulnerabilities using (potentially unverified) exploits.

The source of this request is the same compromised Russian website, it is the first time we observe exploit attempts for CVE-2017-9805. We saw no other requests from this source since this attempt.

We would recommend everyone to keep an eye out for this type of behavior in their web server logs. As always, we won’t hesitate to share any additional observations we make. Should you observe suspicious behavior and would like to receive additional support, please don’t hesitate to get in touch with our experts!