How to find malware samples

In my previous post, I discussed how sandboxes analyze malware samples. But where do cybersecurity companies find malware samples to analyze? How do they stay up to date with the latest malware versions, and how do they do it with minimal delay? Can they even get ahead of the malware authors?

Let’s find out.

Finding samples

The primary source for most companies is VirusTotal. VT is owned by Google and is the largest platform of its kind, making it the obvious first choice. It aggregates files from various sources, such as:

• manual user submissions
• antivirus and corporate EDR¹ submissions²
• reciprocal data sharing with other security feeds
• submissions from Google’s web crawlers and other services²

These files are all aggregated and provided as a live feed that companies can ingest and analyze, making VT the starting point for sourcing samples at scale and finding malware.

In addition to VT, companies use other feeds such as MalwareBazaar (by abuse.ch), MWDB (by CERT.pl), and many others. As a general rule, they try to ingest as many samples as they can, although in most cases VT provides enough to saturate capacity.

In fact, VT provides so many samples every day that many companies simply don’t have enough hardware to process everything and have to actively filter most out, but with appropriate filters and a decent hardware fleet, they can still do reasonably well.³

Too many samples to analyze, too little compute

VT doesn’t just include malicious binaries to analyze - it includes everything that’s submitted, including almost all publicly available software for every platform there is (with its libraries, various builds and versions, and so on), which adds a lot of noise that needs to be filtered out. So how do you actually filter the noise out? How do you actively search for malicious samples?

One way is with YARA rules, which are essentially regex searches on binary files with extra steps and features. For example:

import "pe"

rule WindowsBinaries {
    meta:
        description = "Finds Windows binaries"
    
    condition:
        // Portable Executable (PE) is the Windows format for binaries
        pe.is_pe
}

This rule would filter the feed for Windows binaries only. But it could still be quite noisy, so it’s possible to further narrow down the search:

import "math"
import "pe"

rule ObfuscatedWindowsBinaries {
    meta:
        description = "Finds Windows binaries that are likely to be obfuscated (high entropy)"
    
    condition:
        pe.is_pe and math.entropy(0, filesize) > 7.0
}

This rule would filter for Windows binaries whose entropy is high enough to signal potential obfuscation. But it could still have a relatively high rate of false positives, so it’s possible to further narrow it down:

import "pe"

rule SomeMalwareFamily {
    meta:
        description = "Finds malware of the family SomeMalwareFamily"

    strings:
        // Match a human-readable string
        $bad_url  = "bad-domain.com"

        // Match a literal byte sequence in the binary
        // "??" is a wildcard allowing any byte
        $bad_code = { DE ?? ?? ?? ?? AD BE EF C0 ?? ?? ?? ?? FF EE AA AA }

    condition:
        pe.is_pe

        // Find a specific bad domain, or a unique chunk of code
        and ($bad_url or $bad_code)
}

(See a real example here.)

This rule would filter for Windows binaries which contain either the bad domain or the bad chunk of code, functioning as a heuristic for a specific malware family. Another example would be to look for malicious Microsoft Office documents containing macros that run malware downloaders, and so on.

In addition to that, a bunch of other common sense filtering is done, such as:

• deduplication
• prevalence (ignoring samples that are too widespread and thus unlikely to be malicious)
• excluding binaries with valid signatures from reputable vendors

Real rules can get more generic or more specific, but that’s the basic idea. Aggregating dozens or even hundreds of these rules and filters removes most noise, yielding a workable amount of samples to detonate inside a sandbox and surgically analyze.

Active hunting

Passive ingestion is generally the primary source of samples, which means that they first go through an entire pipeline, e.g. user’s machine → antivirus scanner → VirusTotal → your sandbox. This creates latency and potential lack of visibility, so companies also actively hunt for samples.

Here are some ways:

• letting malware run in the sandbox and intercepting file downloads
• providing email filtering services to other companies and analyzing incoming attachments
• setting up honeypots of various types, like email inboxes to receive spam with malicious attachments, or open vulnerable hosts
• tracking malware infrastructure and directly exploring it or polling it for new builds

Note that malware programmers are not always the distributors, which results in interesting technical choices for hosting infrastructure. That is to say, group A writes the malware (often in a modular way that allows selling malware “DLCs”, if you will), and group B buys it, configures it, hosts and distributes it, and profits from the infections.

Some malware could then support several add-on features as downloadable DLLs, but only download a few of them based on what the client had paid for. If these DLLs are hosted on predictable infrastructure, companies sometimes actively explore it and fetch them for further analysis.⁴

That’s it for this post. In the next posts in the series, I’ll continue digging into further sandbox analysis details and other security related topics, so stay tuned.