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
RIP, 'IT Security'
Kevin Kurzawa, Senior Information Security Auditor,  11/13/2018
Understanding Evil Twin AP Attacks and How to Prevent Them
Ryan Orsi, Director of Product Management for Wi-Fi at WatchGuard Technologies,  11/14/2018
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
Fidelis Cybersecurity provides organizations with a robust, comprehensive portfolio of products, services, and expertise to combat today's sophisticated advanced threats and prevent data breaches. Our commercial enterprise and government customers around the globe can face advanced threats with confidence through use of our Network Defense and Forensics Services – delivered by an elite team of security professionals with decades of hands-on experience – and our award-winning Fidelis XPS™ Advanced Threat Defense Products, which provide visibility and control over the entire threat life cycle.
Featured Writers
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-19367
PUBLISHED: 2018-11-20
Portainer through 1.19.2 provides an API endpoint (/api/users/admin/check) to verify that the admin user is already created. This API endpoint will return 404 if admin was not created and 204 if it was already created. Attackers can set an admin password in the 404 case.
CVE-2018-19335
PUBLISHED: 2018-11-20
Google Monorail before 2018-06-07 has a Cross-Site Search (XS-Search) vulnerability because CSV downloads are affected by CSRF, and calculations of download times (for requests with a crafted groupby value) can be used to obtain sensitive information about the content of bug reports.
CVE-2018-19334
PUBLISHED: 2018-11-20
Google Monorail before 2018-05-04 has a Cross-Site Search (XS-Search) vulnerability because CSV downloads are affected by CSRF, and calculations of download times (for requests with an unsupported axis) can be used to obtain sensitive information about the content of bug reports.
CVE-2018-10099
PUBLISHED: 2018-11-20
Google Monorail before 2018-04-04 has a Cross-Site Search (XS-Search) vulnerability because CSV downloads are affected by CSRF, and calculations of download times (for requests with duplicated columns) can be used to obtain sensitive information about the content of bug reports.
CVE-2018-17906
PUBLISHED: 2018-11-19
Philips iSite and IntelliSpace PACS, iSite PACS, all versions, and IntelliSpace PACS, all versions. Default credentials and no authentication within third party software may allow an attacker to compromise a component of the system.