Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
5/15/2015
12:05 PM
John Bambenek
John Bambenek
Partner Perspectives
Connect Directly
Twitter
RSS
50%
50%

Drinking from the Malware Fire Hose

Take a staged approach to processing malware in bulk so that scarce and time-limited resources can be prioritized for only those threats that truly require them.

This past Thursday, Virustotal, a free service that analyzes suspicious files and URLs, said it detected almost 400,000 unique malware instances on that day alone. Keep in mind that number doesn’t include malware that wasn’t sent to Virustotal, or malware that isn’t detected by antivirus engines. The number of truly unique malware families is, of course, lower but each of these samples may have unique configuration items that could be useful for threat intelligence. That leaves a lot of malware to process and not a lot of time or resources -- reverse engineering and sandboxing isn’t cost effective when dealing with this quantity of samples.

The bad news: We’re doomed. The good news: Job security for infosec professionals is unlimited.

The key to dealing with a problem of this scale is taking a staged approach to processing malware in bulk so that scarce resources (reverse engineers) and time-limited resources (sandboxes) can be prioritized for only those threats that cannot be processed other ways.

There are generally three ways to process malware for intelligence: reverse engineering, sandboxing, and static analysis. Reverse engineering, the most expensive and time consuming method, involves a trained analyst going through the code and manually stepping through functions to gain understanding.

Sandboxing is a time-limited process in which malware is sent to a virtual machine to run so the behavior can be observed. Usually it takes some time for each sample to run, and there are many anti-sandboxing techniques that can be used by malware to make this more difficult.

Static analysis is where a sample is run through a static tool that pulls out artifacts from the malware such as its configurations. Of the three, this method is the fastest, but it only works for known threats where a tool can be crafted to pull those pieces of interest out. It also requires ongoing monitoring and maintenance since malware authors can relatively easily change obfuscation or configuration formats to defeat it.

To get an idea of the time-saving involved with static analysis, I currently process almost 200,000 malware samples daily; it takes about three to four hours with an AWS image. With 10 images, I could process a year worth of malware in about a week.

Get Ahead of the Problem

The key to processing malware at the scale needed is getting research to the point where ongoing processing can be fully automated. The good news is there are already tools to help jump start this for commodity threats.

We also need to overcome the problem of sufficiency (where someone analyzes a threat to come up with a block rule and moves on). The reality is that many different actors use the same tools, and there is valuable intelligence that can be gleaned from each specific attempt.

For example, we recently published a list of AlienSpy configs in the Fidelis Threat Advisory on AlienSpy. The obviously useful indicators are hostnames and ports, which can be fed into firewalls and other security devices quickly. However, the fourth field also includes a free form text field that the specific attacker uses called “Campaign ID.” The top item lists “Henry Targets” for this value, which stands out as unique compared to other campaigns. It would be an item that would be interesting to pivot off of to find related malware. Mutexes, registry keys, and filenames can also provide useful info to correlate malware and actors.

Not every threat can be processed this way, but every piece of malware beacons somewhere, even if it is to get to the next stage of malware in the chain or to self-update its configuration. Driving malware processing to the lowest possible level of effort allows for spending scarce resources on those threats that require additional attention.

The solution is to automate everything you can, take a hybrid approach such as sandboxing for everything else, and manually process only what you must. This way you can start to drink from the malware fire hose without drowning and still derive useful intelligence from it.

John Bambenek is a Senior Threat Researcher at Fidelis Cybersecurity. His areas of specialty include digital forensics, global cybercrime investigation, and threat intelligence. He has developed open source feeds of threat intelligence data and works with law enforcement ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
MoviePass Leaves Credit Card Numbers, Personal Data Exposed Online
Kelly Sheridan, Staff Editor, Dark Reading,  8/21/2019
New FISMA Report Shows Progress, Gaps in Federal Cybersecurity
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/21/2019
Aviation Faces Increasing Cybersecurity Scrutiny
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/22/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-15513
PUBLISHED: 2019-08-23
An issue was discovered in OpenWrt libuci (aka Library for the Unified Configuration Interface) as used on Motorola CX2L MWR04L 1.01 and C1 MWR03 1.01 devices. /tmp/.uci/network locking is mishandled after reception of a long SetWanSettings command, leading to a device hang.
CVE-2019-15504
PUBLISHED: 2019-08-23
drivers/net/wireless/rsi/rsi_91x_usb.c in the Linux kernel through 5.2.9 has a Double Free via crafted USB device traffic (which may be remote via usbip or usbredir).
CVE-2019-15505
PUBLISHED: 2019-08-23
drivers/media/usb/dvb-usb/technisat-usb2.c in the Linux kernel through 5.2.9 has an out-of-bounds read via crafted USB device traffic (which may be remote via usbip or usbredir).
CVE-2019-15507
PUBLISHED: 2019-08-23
In Octopus Deploy versions 2018.8.4 to 2019.7.6, when a web request proxy is configured, an authenticated user (in certain limited special-characters circumstances) could trigger a deployment that writes the web request proxy password to the deployment log in cleartext. This is fixed in 2019.7.7. Th...
CVE-2019-15508
PUBLISHED: 2019-08-23
In Octopus Tentacle versions 3.0.8 to 5.0.0, when a web request proxy is configured, an authenticated user (in certain limited OctopusPrintVariables circumstances) could trigger a deployment that writes the web request proxy password to the deployment log in cleartext. This is fixed in 5.0.1. The fi...