Friday, November 17, 2017

6 New Hybrid Analysis Features You should Know About

It is a pleasure to see an active community of researchers, incident responders and regulars uploading samples, gathering reports, making comments, etc. at our free malware analysis service on For example, take a look at a recent snapshot of our statistics page:

The number of behavior indicators, YARA rules and total analyses is a metric that is constantly growing. While we have been working on various aspects of the system in house (e.g. distributed multi-node setups, improved deployment procedures, etc.) it has been long overdue to introduce everyone to some of the latest capabilities. In this blogpost, we want to showcase a few.

No. 1: Console output

One of the things we added is a console output. Let's take Pafish as example, which is a popular benchmark tool that implements common virtual environment detection techniques known to be used by malware:

Source: HA report

The red circles highlight the "console" icon which indicates that some standard console output has been logged for a specific process. To view the details, click on the process name itself and move to the "Console Output" tab:

The "Console Output" tab:

versus the original console output (see Screenshots section):

The new logging capability adds better visibility into console applications and is fully processed as part of the report generation stage.

No. 2: Advanced search 

Another feature that is often overlooked is the advanced search form, which can be navigated to by clicking the search input field:

The advanced search form allows combining a variety of search terms and track down interesting samples. For example:

  • Filetype Tag (e.g. "PE")
  • Verdict (e.g. "Malicious")
  • Hashtag (e.g. "#Cerber")
  • Connected IP/Domain, etc.

An example:

Click "Search Database" and perform the above search in a short period of time:

Combined with behavior indicators, some very interesting search queries can be implemented.

No. 3: Similar samples

Under the hood we have been working on clustering and classifying samples based on their behavior and other attributes. Here is an interactive diagram that we use in one of our test labs:

This feature is implemented using either the advanced search (see above), but is also embedded into the UI. If you are a heavy user of Hybrid Analysis you might have noticed a new label appearing for some analysis results in the submissions/search result page(s):

The button only appears if there is actually an associated cluster. Just click the button and perform the search to track malware campaigns and families! More information on this capability and its utilization via the free API is available in the following KB article: How to gather network connections of a specific malware campaign

No. 4: Custom detonation

Typically, you will submit files using the default analysis option - but there is more. If you click on the "Analysis Options" an entire form with a variety of additional options will drop down:

On the new form, you can provide e.g. a so called "action script" (to perform various actions during the runtime phase), a document password, set the environment to a specific date/time, route traffic via the TOR network for added anonymization, etc. Just hover your mouse over one of the info icons (right side) to get a better description:

Note: the on premise version of the sandbox allows various customizations (e.g. the ability to use your own action scripts).

No. 5: Registry and API calls filtering

One minor usability feature that we think is worth mentioning is the filtering mechanism that we added. It allows displaying subsets of the traced registry events and API calls. Here is an example on how registry related events can be filtered by the type of operation, registry pathway and status of the registry operation:

An example of displaying only failed registry operations:

No. 6: Context menu

As a last highlight, we would like to bring your attention to the new context menu that shows up when performing a right-click on a row in the submission / search result page:

This can be most useful, if you want to automate tasks such as:
  • Searching the DB for a specific IP connection / DNS query
  • Searching the DB for a specific #tag attributed to a report
  • Downloading the related sample (if shared)
  • Open up a report in a new tab (most useful when researching various samples)


Here at Hybrid Analysis we are constantly improving the webservice based on the community feedback. Don't hold your breath, but more is coming soon! Feel free to follow our Twitter account for more frequent updates on what is going on.

Wednesday, February 15, 2017

VxStream Sandbox - Effective Incident Response

Nearly all breaches and/or intrusions that occurred in the last years involved malware pieces and different threat actors using custom tools and/or popular toolkits as a part of the intrusion/breach.

How does Incident Response work?

The following diagram (taken from the “SANS Institute”) outlines a typical workflow and best practice:

This is a very high-level perspective. In this blog post, we will focus on one of the most important step: analysis of the artifacts found during the evidence collection process.
From an Incident response perspective, it is important to collect information such as:
  • Network Information:
    • IPs, Domains
    • HTTP related payloads
    • Special artifacts (e.g. PDB pathways)
  • Files:
    • Different office documents (DOC, XLS, even PUB)
    • PE files (COM, DLL, PIF, etc.)
    • JS/JSE/VBS, etc.
VxStream Sandbox has always been designed with Incident Response in mind. That is, extracting as many indicators (e.g. IPs/URLs from memory) and highlighting relevant data to make the life of an analyst during an incident efficient and time effective. In the following, we will show some real-world examples of analysis results directly connected with using VxStream Sandbox as the preferred automated malware analysis solution.

Keybase Delivered via Excel Sheet

Office files are a common method for attackers to deliver malware to corporations. The file we will demonstrate is often distributed via SPAM campaigns or exploit kits. These droppers deliver the final payload using social engineering tricks and:
  • Malicious macros (often highly obfuscated)
  • Embedded files (e.g. with changed icons to camouflage the file type)
  • other tricks
We published an article in the SANS ISC InfoSec Forum about a malicious campaign spotted on our public webservice at This is a real example of how VxStream Sandbox can help Incident Response analysts advance their investigation by automatically analyzing the malicious files found during the forensic process. One report is generated in about 8 minutes.

Malicious office file
Malicious office file

As we can see, a typical social engineering technique is used to convince the user to enable and execute the macro, once the content is enabled. So what happens if we execute the macro? Here is the monitored execution of the excel process on a Windows system:

Hybrid Analysis
Hybrid Analysis
Most of the output seems pretty self-explanatory, but there are a few tricky aspects:
  • the embedded macro starts a hidden instance of PowerShell.exe (via cmd.exe) which downloads a file (mi.exe) from a remote server (, storing it in the %TEMP% folder as pu457.exe.
  • the downloaded binary is associated with the "open" verb for the mscfile type in the shell. This is effectively a UAC bypass, as Enigma0x3 has demonstrated.
  • the "PING -n 15" callout is a minor delay (as the 15 ICMP echo request will be issued once a second, roundabout), most likely to give the event viewer a bit more time and properly trigger the bypass

Should you want to inspect the network related activity (e.g. the file download), the 'Network Analysis' section of the report is quite useful:

Any dropped/generated/extracted file during the full runtime and static analysis will appear in the 'Extracted Files' area of the report. VxStream Sandbox automatically applies YARA rules and collects other meta-data (e.g. hash lookups at Metadefender or VirusTotal) and/or inspects PE files more deeply, etc. in order to demonstrate more context and indicators for the analyst:

Additional Context

In terms of Incident Response one often needs to put the artifact into context (i.e. "how worry do I have to be?"), in order to determine an appropriate response. The 'Incident Response' section of the report (at the very top) is one attempt to categorize the various generic behavior indicators into capabilities (e.g. "Remote Access") and broad characteristics (e.g. "Credential Stealer"). It is a very high-level summary and still a work in progress.

One of the more unknown features of VxStream Sandbox is the capability to find similar reports based on the behavioral indicators that triggered. Effectively it allows you to quickly locate files that show other, similar characteristics (e.g. "The analysis extracted a known ransomware file").

Find Similar Reports Based on Specific Behavior

As previously mentioned, it can be quite useful to "hunt" similar samples based on a specific behavior that was extracted. For example, take this relatively new indicator that is part of the ~460 indicators in VxStream Sandbox:

It is an analysis evasion technique, as sending an ICMP echo request 250 times will effectively delay execution by at least 250 seconds, as each iteration is delayed by ping.exe.

Searching for the indicator ID "target-45" (hover an indicator to see its ID in the HREF):

Using this advanced search (which is available to any registered free user, by the way) makes it easy to hunt similar samples and the search results also confirm that it is a common technique used frequently these days.

Automatic Deobfuscation

Recently, we have been seeing more and more obfuscated PowerShell command-line invocations using various obfuscation techniques. For example, a very popular method is to pass the actual command line in a Base64 encoded format (but there is also way more complex methods involving variables, etc. that we will not cover in this blogpost):

In an incident response investigation, one of the key things is the "resolution time”. That is why we also try to implement the static resolution of simple tricks like Base64 encoding (see above). In this specific case, the report will print an "Additional Context" field highlighting the deobfuscated command line:

It is these things that save time for an analyst during an investigation --- it is the reason we refer to VxStream Sandbox as Effective Incident Response. Note: this article is a summary of a talk Marc (@Seifreed) held at the Hakron conference.

Follow Payload Security on Twitter to learn about new features, interesting samples and other news all around VxStream Sandbox:

About the author: Marc Rivero López has spent a good portion of his life working with Incident Response (IR) teams inside large financial institutions in Europe, as well as being appointed as a Principal Consultant EMEA for Foundstone consulting services on investigations related to intrusions and malware infections. This blog will be the new home of Marc, who is now the head of research at Payload Security.

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:

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:


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 or follow us on Twitter at

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

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:


Other URLs:


Sunday, July 3, 2016

Financial malware delivered via embedded JSE

Just a few days ago our research lead came accross an interesting office file. Instead of the common macro malware everyone sees today (which is as old as the 90's, albeit still successful), the sample we were looking at was using an interesting way to bypass automated detection: the Office file contained an additional embedded file, which needs to be launched "manually" (double-click) and at first sight of the icon seemed to be an Excel sheet.

As the "follow the instructions" type of prompts are usually a dead give-away for malware (amazing that these things still work), we decided to take take a deeper look and see if we might possibly learn a lesson and improve our own automated malware analysis system. What made the file even more interesting is that it was bypassing all major sandbox vendors (including our own, to be fair) and had a very low AV detection rate. Nevertheless, it did have AV detection, which - by the way - is a strong statement in our opinion and underlines that leading AV technology is still very important, at the very minimum as an initial filtering mechanism.

... but enough of the ramblings, let's get down to the nitty-gritty. ;-)


Initial Assessment


As a first (manual) step, we took a brief look at the Word file structure.

The embedded 'oleObject1.bin' file is the 'Excel file' that one can observe when opening the Word file (see first screenshot of this blogpost). Let's take a brief look at it:

... aha! The file contains a Javascript Encoded (.jse) file reference. You can either drag & drop the embedded 'Excel sheet' from the Office file or take a closer look at the binary contents to find the encoded javascript.

Obviously, the embedded JSE is very difficult to parse statically and does a good job at hiding IOCs. The random dictionairy comment (see the "/* */" in the above image that encapsulate a large chunk of white noise, most likely to create an acceptable valid vs. junk character ratio to bypass heuristic AV thresholds).


Improved Sandbox Results


Let's skip forward two days and take a look at our optimized VxStream Sandbox report for the file. As of v4.4.0, we successfully extract embedded .jse/.vbe files from Office files and execute them on the target system as well as decode them automatically and try to extract IOCs from the decoded (and partially deobfuscated) version of the script(s). Here are the results:

Launching the embedded JSE on the Windows guest

Decoded JSE available for D/L

 Taking a peek into the decoded JSE

Extracting the IOC from the "IP address" Behavior Indicator




The file we reviewed in this blogpost demonstrates that malware groups are very agile and remain 'creative' at bypassing security systems, especially automated sandbox systems. This underlines the importance of having an agile sandbox framework to quickly adapt to new techniques, but also shows that awareness of sandbox systems is growing. In this specific case, a clever mix of social engineering tricks (the fake 'Excel sheet' icon), added white noise (the legitimate string data) and an uncommon trigger (human interaction required to double-click the embedded file; no usage of macros) as well as the more hideous JSE was observed. It is a prime example to show that it is not enough to simply execute a file in a sandbox environment. Instead, at the very minimum, a carefully crafted mixture of static and dynamic analysis techniques is necessary to stay on par with latest malware evolution. A broad term we defined at Payload Security for the combination of static and dynamic analysis techniques is Hybrid Analysis.

(1) VxStream Sandbox Report:
(2) Dropped Gozi Report:



We were made aware of the following excellent blogpost  that outlines a quite similar attack, but instead of using an embedded JSE camouflaged as an Excel sheet, a batch file launching Powershell with a Base64 encoded "dropper commandline" was observed. We filled our coffee cups and made a small night session to accomodate for any kind of embedded file type. Here are some impressions:

 Targetted Powershell Attack

 Improved VxStream Sandbox Report