Showing posts with label evasive techniques. Show all posts
Showing posts with label evasive techniques. Show all posts

Tuesday, December 20, 2016

Introducing A Unique Script Logging Engine

One advantage of being an exposed software vendor (we operate a popular free public malware analysis service) is that we constantly get challenged with latest malware samples and have a vivid feedback loop. IT-Security professionals and researchers from all around the world upload what they get in touch with at a daily basis. As we are quite dedicated about what we do here at Payload Security, we monitor the webservice closely and enjoy in doing so.

We have been observing that during the past months usage script languages as an entrypoint stage has been growing quite popular among cybercriminals. Often, it is not a single-layer approach, but the actual malicious script is downloaded by a "pre-stage" VBA script or other intermediate stages. That is, we have been seeing multi-layered dropper scripts. In general, one could say that mixing all kind of script formats, including javascript, powershell, vbs, wrappers (wsf/hta), encoded formats (jse, vbe) and other variants has become a standard toolset of the delivery process. Taking a look at the statistics page of the webservice underlines the growing popularity of using scripts (and not even counting AutoIT compiled to PEs, etc.):


A brief look around quickly revealed that other AV vendors have noticed scripts being a popular vehical to deliver trojans, ransomware, RATs, etc. As most of these scripts are not sandbox environment aware, it is our personal speculation that the current increase in complexity of malware delivery has mostly been implemented to bypass endpoint protection solutions, which often also rely on parsing the input file and the commandline pre-execution. Nevertheless, there is sandbox evasive mechanisms built into scripts that are interesting to investigate, as well.

In order to better understand malicious script activity, we have implemented a generic script logging engine (hint: we are still thinking of a fancy/fluffy marketing name) that is quite powerful and intercepts various external script calls (JS/VBS/VBA). It is a technology that we are still building upon, which has been turned on at the public webservice for a few weeks now. As we are quite excited about it already, we decided to push forward the news with this blogpost.

Multi-Layered Cerber Delivery


The new Cerber variant we will be looking at right now uses a typical social engineering technique to try to lure receivers into enabling macros and execute the payload:



In general, reports of VxStream Sandbox always contain a variety of indicators that allow quick assessment of macro codes and whether or not they are most likely malicious (e.g. detecting obfuscation, suspicious keywords, auto-execute functionality, etc.):




In general the macro indicators are not useful beyond determining general malicious intentions. This is where the new script logging engine comes into play, which adds some forensic flavor and allows extracting more artifacts. In order to access the script engine output, one must go to the 'Hybrid Analysis' process details section and click on a process that has the "Logged Script Calls" cog icon next to it:


In this specific case, clicking on the process will take you directly to the "Script calls" tab:


As we can see, the obfuscated VBA code is actually unwrapping a piece of javascript, which in turn is downloading (and verifying) the next stage, which ends up being a PE file encrypting the machine:



As this is happening within the VBA engine, neither classic API call monitoring nor instruction based tracing (as implemented by some "next generation" solutions) will easily yield this depth and clarity.

Link to the report: https://www.vxstream-sandbox.com/sample/3004c162dc360c97aefc7828ca175e65583b972c9a7444d4f0e05d7bc4dc71f9?environmentId=100

Another beautiful example of the new script engine is the following Nemucod trojan delivering a malicious javascript as a Windows Script File (WSF). It is deeply layered involving multiple stages, including WScript.Shell and PHP code, as can be seen quite nicely by the process tree and the "Script calls" tab:




Link to the report: https://www.vxstream-sandbox.com/sample/b9618fd0f7dcfc47ea725c817abee20fde0298ee64783565766b38b53d5a0869?environmentId=100

Conclusion

As discussed, we believe there is a trend towards mainstream malware using more complex delivery methods that involve multi-layered scripts. For us at Payload Security one answer to the ever-changing IT-security threat landscape is to try out novel ideas, not being "scared" of field tests with in-the-wild malware, being transparent about technology (we do not believe in security through obscurity) while keeping a focus on implementing solid solutions that bring business value to the end user.

Did we get your interest? Try out the new script logging engine at https://www.hybrid-analysis.com/ or follow us on Twitter at https://twitter.com/payloadsecurity

Thursday, October 27, 2016

On Dridex and a new "Zero-Day-Distribution" method


The banking trojan Dridex (also known as Cridex, Feodo, Geodo, etc.) has been distributed in the past via malicious documents containing macros sent by E-Mail. Just yesterday we discovered a new distribution method that is undetected by the various Sandbox solutions we have access to and all AV engines. We were able to happily share and send those infected files via Skype, Gmail and other platforms. So while Dridex itself isn't new, the distribution method definitely is --- and it will be very successful looking at current 0% detection ratio. In a sense, it is a "zero-day-distribution" method so we decided to use that term. ;-)


In this blogpost we will analyze a sample file, demonstrate the distribution method and cover some context, finishing up with a link to the updated VxStream Sandbox report at hybrid-analysis.com, as our engine is able to detect and execute the dropper code as of now.

At Payload Security malware analysis and working together with the IT-Security community is our passion, which is why we try to be as reactive and response as possible to new evasion techniques. As a reminder of latest additions to VxStream Sandbox, here are a few pointers:
... but let's get down to the nitty gritty of this Dridex campaign.

Initial Manual Assessment

In this example, we will be taking a look at "remittance advice 58.docx" (SHA256: da82eaeba71eeb95d643b0343b2c095d72b686314cd340631aa8d9fe08a74714).


As has been a recent trend we see for targetted attacks (more on that later), this malicious Office file does not contain any macros (or exploits, actually) to execute the payload:


Instead, the document contains an embedded file, which can be extracted from the "oleObject1.bin" file in the "embeddings" folder. In this case, as it is a Word file, the relative pathway would be word/embeddings/oleObject1.bin. Let's take a look:


As a quick initial assessment of the file, let's take a look at some of the strings we can find:


We quickly detect the following key information:
  • a "Windows Shortcut" (.LNK) file seems to be embedded
  • a reference to the Windows command prompt
Taking a deeper look we quickly see the actual "dropper" code, which is a powershell command:


A more readable format:


What it does:
  • requests a PHP file from a remote server
  • downloads the PHP file (which is actually a PE file) and renames it to "calc.exe" (probably in hope of being a bit less suspicious)
  • executes the downloaded file
The downloaded file is Dridex. Using Windows Shortcut (.LNK) files as an "under-the-radar" distribution method is actually not that new for the group behind Dridex, as they have used that exact method as part of an E-Mail attachment. So in a sense this is just a new variation, albeit it is quite nested and obviously successful looking at the detection rates.

If you wanted to confirm that the file is Dridex, you could e.g. check the ET PRO rules, which are integrated into all VxStream Sandbox reports, if you have the appropriate license:

Dridex identified by ET PRO Rules
Dridex identified by ET PRO Rules

A normal execution of Dridex will download an encrypted DLL and after some security checks, the configuration file.

Why "Common" Dynamic Analysis Fails

Simply opening the document will cause nothing to happen initially. Instead, the embedded file has to be double-clicked. This is the first "hurdle" that most Sandbox systems will have difficulties with.


After double-clicking the file - on a default configured system - an additional prompt will have to be passed:


... only if we click "Open" on that prompt, the actual LNK file and consequently the Command Prompt -> Powershell execution chain will trigger and download Dridex.

Why is it a targetted attack?

The server(s) hosting Dridex seem to be denying access based on the geolocation. This can either be a temporary countermeasure while testing sandbox detection ratios or it can be a hint at a targetted attack for a specific region. We were only able to download the sample if the source IP was located in the region highlighted in green:


All other countries were denied downloading the sample in our case.

How does VxStream Sandbox perform? 

Obviously, we wouldn't be writing this blogpost if VxStream Sandbox would be performing poorly. ;-) To be fair, as we discovered the first files just yesterday, our engine was not parsing the embedded .LNK file properly, as we had been focusing on embedded executables, Powershell, VBScript, Javascript and some other file types. Nevertheless, as the sandbox has technology included that can deal with these kind of attacks in principle, it was an easy task to add support for the new missing file type. After updating the live systems (in less than 24h, noted), we successfully flag the file as malicious *without* the help of any AV detection. Here is a few example screenshots:


Link to report: https://www.hybrid-analysis.com/sample/da82eaeba71eeb95d643b0343b2c095d72b686314cd340631aa8d9fe08a74714?environmentId=100

Hunting more samples

This was actually quite interesting. Based on the embedded file "absolute pathway" that is included in the Word documents, were able to discover additional files that reach back to May/June on our public webservice:


Final Words

In this blogpost we demonstrates a brand new Dridex distribution method, outlined some initial assessment and demonstrated how important "state of the art" security solutions and vendor responsiveness is, as the groups behind malware are very creative, especially considering the money business that ransomware, banking trojans, etc. has become. Stay safe and we hope you enjoyed the read.


Other SHA256s:

bc17109629c455e6bbcf25d313f3c79234a2facf7691bef3df26cc2537071809
96d43a519e857663a78eff84b56bbb0343c7c6fb4b5814c0fd7a302abc74bd79
06eab8037525ba0ac8dc62512a149aea3786c33cd6e7d08b9c5b175777c31da3
1382a68b7a9b0f20670162d8cd8dc91ad27c556ec166a351910cfffeda1f9353
da82eaeba71eeb95d643b0343b2c095d72b686314cd340631aa8d9fe08a74714

Other URLs:

meow://4thkantonind.top/egypt/hashish/afghankush.php
meow://47matroskin.top/nazareth/animals/listen.php
meow://17uhrtreuhand.top/nazareth/animals/listen.php
meow://37virginiaslim.top/nazareth/animals/listen.php
meow://17uhrtreuhand.top/nazareth/animals/listen.php

Thursday, May 7, 2015

Staying up-to-date with Malware Sandbox Detection: About Tinba, Human Behavior and Harddisc Cylinders

Just yesterday F-Secure made a blogpost about a new sample of Tinba that implements a new combinational evasion technique of sandbox systems, which on the one hand checks for human interaction indicators based on mouse movement (using GetCursorPos) and switching active foreground windows (using GetForeGroundWindow), as well as the disc size. Theoretically, all of these sandbox detection techniques are old cake and e.g. part of the 'Pafish' benchmark tool that implements typical evasion techniques:

Disc size check in Pafish (reference)

The new technique implemented by the Tinba sample that F-Secure posted about is that it checks the disc size not in a typical way. It uses the 'IOCTL_DISK_GET_DRIVE_GEOMETRY_EX' control code and counting the number of cylinders, which is a nice low-key way of determining the actual disc size. The structure returned by NtDeviceIoControl using the control code mentioned earlier eventually results in this data structure:


If we can intercept calls to NtDeviceIoControl and spoof the number of Cylinders accordingly, it is possible to make any disc size appear to have an arbitrary size.

As outlined in our noticed blogpost 'Benchmarking some popular public malware analysis services regarding their "Anti-VM" technology' that we posted about in February it is part of our daily job to try to stay up-to-date with sandbox evasive technologies. So that is what we did here.

As VxStream Sandbox runs by default with some 'action scripts' that simulate user behavior the first part of Tinba's sandbox detection was passed to begin with. As we already implement a variety of spoofing techniques it was easy to extend the current engine. Re-running the sample had the desired result: the checks were passed and Tinba starting showing a lot more behavior.

Report of Tinba with the latest VxStream Anti-VM Detection Technology

Additionally, we created a new behavior signature called 'Queries disc information (often used to evade virtual machines)' in order to generically detect this kind of behavior on any sample analyzed in the future.

Report URL: https://www.hybrid-analysis.com/sample/476fc456c66cbec138e3dab72a0f0e54f203dbf27ce88736b1893b668bce63c4?environmentId=1