Introduction¶

What are host indicators?¶

Host indicators are things you can easily detect on a running host that has been infected with malware. For example if a piece of malware uses a specific mutex to prevent multiple instantiations, then we can detect that mutex and thus the malware on the system. Host features include:

Files (by existence, size, checksum or partial checksum)

Registry Keys and Values

Service control manager entries

Processes

running process with a particular name, or

with a particular module loaded, or

with particular memory contents

Other objects such as mutexes, named pipes and named shared memory

higrep is a tool to detect these features on running systems.

But isn’t that the job of AV software?¶

AV software is opaque. As a security admin, you can ask general questions of AV software, but you cannot use it to detect malware known only to you. Further, because you don’t know how the signature works, you have no particular way to build confidence that an AV detection is actually working properly, or how it is working. Our tool is designed to empower sysadmins to talk about and query and share features explicitly.

The point of the tool is just to detect the feature on the system – not to fix or remove it.

But isn’t that the job of an HIPS?¶

Yeah, maybe. But can you write your own rules? If you can write your own rules. We think the rules you can write for higrep are (or can be) more powerful than with a HIPS.

Deployment Use Cases¶

The tool can deployed as a persistent service (for sysadmins that plan ahead) and pull updates periodically and report continuiously. Updates and reporting can be via HTTP or via a shared folder.

In “fire fighter” mode sysadmins embed a signature file into the binary and run it once on all their systems. We designed the tool to require absolutely minimal infrastructure to deploy for this use case.

Implementation¶

The higrep executes a script file (which may be embedded as a resource in the executable) written in Javascript. Rather than manipulating the contents of a web page, this javascript can call a small set of functions (See Reference) to retrieve system information and determine is a particular rule is matched. The script is executed in the context of a Windows service running in the SYSTEM account.

Here is a complete example script file:

// Fetch updates via HTTP
settings.updater = "http://intranet.example.com/higrep/script.js";

// Report the results by generating a file in a shared directory
settings.reporter = "\\\\server\\security\\incoming\\higrep\\reports";

// Add a rule to malware that creates two files in SYSTEM32, evil.tmp and
// ~temp???.tmp where ??? is an arbitrary number.
rules.IncidentXYZ = function() {
  return EnumerateFiles(GetWindowsDirectory() + "\\SYSTEM32", function(file_info) {
    if (file_info.name.match(/\\~temp[\d].tmp$/i)) {
      return true;
    }
    if (file_info.name.match(/\\evil.tmp$/i)) {
      return true;
    }
  });
}

// This is a rule to look for a module named "evilbad" loaded in any process
// on the system
rules.IncidentPDQ = function() {
  return IterateProcesses(function(process) {
    var modules = ProcessLoadedModules(process.id);
    for (i in modules) {
      if (modules[i].match(/evilbad/i)) {
        return true;
      }
    }
  });
}

// This rule looks for a hypothetical malware sample using the default mutex
rules.FooBot = function() {
  return IsMutexHeld("IAmFooBot");
}

To get started, you can either install higrep as a service, or run it directly from the command line. On the command line, higrep prints the names of any rules that matched. For details see Usage.

> higrep --script myscript.js --install

> higrep --script myscript.js
IncidentPDQ

Host Indicator Grep v0.2 documentation

Introduction