Simple Malware Discovery Measures

If we really want to take virus protection seriously, we’d get involved with reporting undetected viruses to anti-virus product vendors. Malware developers thrive because very few people investigate virus alerts.

A typical web-based virus attack scenario consists of multiple components. A person may willingly install software (a Trojan horse) and that software may download additional malicious components. Alternately, a user may inadvertently install software, be the victim of a drive-by download, when visiting a web site. This software also downloads additional malicious components. It is almost always the case that one or more of these components is already detected as malicious. The malicious person needs at least one of these measures to be successful. The malicious person can be detected if at least one of these measures is detected. At least one measure is often detected.

Unfortunately, it is generally thought that if anti-virus software has detected a threat, then it is sufficiently addressed. Thus enables the malicious person to try as many threats as they wish.

  • Undetected threats work.
  • Detected threats are ignored.

If enough people follow up on enough of these detected threats, then submit samples to anti-virus vendors and report malicious sites found, we can make malware development less profitable and less attractive.

There’s a mystique to finding malicious files, a belief that you need special skills. That’s not true. There’s a belief that it is the job of the anti-virus vendor to both find the malicious files and to develop protection. How is the vendor supposed to find the files?

Abandon those misconceptions. You can be informed about various attacks before you read about them, if you just look.

MalwareSigs Helping Network Analysts Detect Malware

Redline is Mandiant’s free tool for investigating hosts for signs of malicious activity through memory and file analysis, and subsequently developing a threat assessment profile.

Malware wants persistence, so review Windows registry locations that malware may use to ensure it gets run. That would include the usual Autoruns locations, such as:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

There are also less frequently investigated registry entries, such as:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

can be a malicious payload.

Parse user hives, not only the current user.

Identify suspicious keys in Registry Hives, such as long entries and anything that would point to signs of malware presence/persistence.

Eric Zimmerman’s Registry Explorer can make malware review simple. Set the filter for keys over a certain size. There are a few normal windows keys that are large, but your results will be very small if you set the filter to 1024.

get-childitem registry::hkcu\Software\Microsoft\Windows\CurrentVersion
-recurse | get-item | select property

Pipe that to a text file and you’ll get a recursive list of every value in
the currentversion area. Delete everything back to HKCU (or replace it with
HKLM) to get a full dump. One caveat is that it will pair everything in the
output file to the same brackets if you redirect (>) it, but the large, typically base64 code that malware stores will stick out. You can also do this with offline hives.

From the registry dump, a Python script can read the lines of a text file. Something like

list = []
a = open("pathtofile.txt").read().split("\n")
for item in a:

and then just do a for item in list, length of item check. But the main
part can be done by PowerShell (and could probably done at scale in an
enterprise, now that I think about it).

A Complementary Measure: OTL by OldTimer
OTL by OldTimer presents system information, processes, modules, services, drivers, Internet Explorer extensions, Firefox extensions, browser helper objects (BHO), run keys and recently modified files. Your task is to find the anomalous entries and files and forward them to your vendor for review.

An even simpler measure: What’s new in System32? Sort by Date Modified, and see what’s at the top (or bottom) of the list. This is will miss a lot of malware, but will discover suspicious files with very little training. The scenario is: your antivirus found something, but did it find everything? By looking for a dll (or exe) file with a recent (perhaps today’s) date, you have located a suspicious file. Similarly, find what’s new in the Hidden Files areas (user’s temporary files, C:\Windows\Downloaded Program Files).

Another Simple Measure: Madiant Red Curtain.
MRC examines executable files (not only .exe and .dll files, but many more) looking at entropy (randomness), indications of packing, compiler and packing signatures, the presence of digital signatures, and other characteristics to generate a threat “score.”  Sort the result by “Score” and review the files with a high score. Use the built-in Help feature for an explanation of what MRC found.

Another Simple Measure: Windows File Analyzer
The Windows PreFetch Folder contains information about programs that have been running. If malicious software has been installed, it is probably listed in the Windows\PreFetch folder. This narrows the number of suspected programs considerably.

Damballa Failsafe is a purpose-built, specialized threat protection solution, which hunts for these hidden threats utilizing an array of patent-pending technologies.

PowerShell ♥ the Blue Team describes PowerShell features for detecting malware.


3 Responses to Simple Malware Discovery Measures

  1. […] Follow up when exploit of a vulnerability is detected in order to learn of undetected exploits. See A Simple Measure for an easy follow up […]

  2. […] software did not detect. Consider sending information to your anti-virus vendor; see “A Simple Measure“. Since you have just seen an example of undetected malware, it would be unreasonable to […]

  3. […] values of current files. Inspect the files that do not match the “known good” list. See Simple Malware Discovery Measures for additional […]