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
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27621
PUBLISHED: 2020-10-22
The FileImporter extension in MediaWiki through 1.35.0 was not properly attributing various user actions to a specific user's IP address. Instead, for various actions, it would report the IP address of an internal Wikimedia Foundation server by omitting X-Forwarded-For data. This resulted in an inab...
CVE-2020-27620
PUBLISHED: 2020-10-22
The Cosmos Skin for MediaWiki through 1.35.0 has stored XSS because MediaWiki messages were not being properly escaped. This is related to wfMessage and Html::rawElement, as demonstrated by CosmosSocialProfile::getUserGroups.
CVE-2020-27619
PUBLISHED: 2020-10-22
In Python 3 through 3.9.0, the Lib/test/multibytecodec_support.py CJK codec tests call eval() on content retrieved via HTTP.
CVE-2020-17454
PUBLISHED: 2020-10-21
WSO2 API Manager 3.1.0 and earlier has reflected XSS on the "publisher" component's admin interface. More precisely, it is possible to inject an XSS payload into the owner POST parameter, which does not filter user inputs. By putting an XSS payload in place of a valid Owner Name, a modal b...
CVE-2020-24421
PUBLISHED: 2020-10-21
Adobe InDesign version 15.1.2 (and earlier) is affected by a memory corruption vulnerability due to insecure handling of a malicious .indd file, potentially resulting in arbitrary code execution in the context of the current user. User interaction is required to exploit this vulnerability.