Description of Threat Management Center
The TMC is comprised of several components in an integrated system:





Master Server
Processing Nodes
REcon
Digital DNA
Reporting System
Master Server
TMC is controlled by the Master Server. The Master Server has the following functions:




TMC user interface – how the user operates TMC and gets its output
Binary feed mechanism – the method to present binaries to TMC for processing
Schedules and monitors jobs running on the Processing Nodes
Houses the TMC database and interface to the database
Processing Nodes
The Processing Nodes are a bank of inexpensive computers that will execute the binaries being
evaluated. The Processing Nodes perform automated runtime analysis of each binary submitted to it by
the Master Server. Each processing node is equipped with the REcon and Digital DNA (DDNA) software.
(See below for descriptions of REcon and DDNA.)
The TMC is scalable to process any number of binaries required. Each Processing Node is capable of
processing between 500 and 1,500 binaries per day with the controlling factor being how long each
binary is executed. The number of Processing Nodes required is determined by the maximum number
of binaries to be analyzed per day.
REcon
REcon provides the execution environment for the binaries under test. The binary runs inside of REcon
which runs inside of a VMware virtual machine on a Processing Node. REcon’s functions include:



Runtime tracer
Flypaper
Journal file
Runtime Tracer. REcon records all runtime behaviors of an executing binary system wide including
usermode and kernelmode execution. It captures control and data flow at a single step resolution. Data
sampling captures the contents of registers, the stack, and target buffers of de-referenceable pointers.
Symbols are resolved for all known API calls and are combined with argument sampling. REcon follows
multiple processes and traces parent/child process execution. It can also follow a process by injecting a
DLL into another process.
REcon operates at a very low level within the system, layering itself directly above the Hardware
Abstraction Layer (HAL) and underneath the Windows kernel to provide complete control over the
operating environment while at the same time maintaining performance levels to trace software in real
time. It is not bound by dependency on the Windows userland Debugging API, and therefore is not
thwarted by malware anti-debugging tricks. The target software is not modified in any way: No
breakpoints are injected; No thread context is changed; No debugger is attached. Tracing is performed
completely external to the process operating environment.
Flypaper: Flypaper is a technology within REcon that blocks programs from exiting memory by blocking
all attempts to exit a process, end a thread or delete memory. This causes all components used by the
binary or malware to remain present in physical memory. Therefore, when a memory snapshot is taken
for analysis by Digital DNA, all malware components such as the dropper will be present in memory and
available for analysis. Flypaper can optionally be configured to prevent TCP/IP communication using the
standard Windows™ stack.
Journal File: All runtime behaviors and dataflow of executing binaries are recorded in the Journal File.
The Journal File contains the low level raw data used for reporting of binary behaviors. Optionally, the
user can import the Journal File into HBGary Responder Professional for deeper dive analysis. (See
Responder Professional section below.)
REcon has a feature to "Step Over System Calls" which prevents REcon from logging control flow of
commonly used system libraries, thereby saving space in the Journal File and usually this data is not
required for the analysis.
Roughly speaking, the Journal File logs approximately 40 MB of data for a binary executing for 2
minutes. This data can be immediately deleted after the report is generated or saved based on user
configuration rules.
Digital DNA
DDNA examines the low level behaviors of binaries under test and gives each a threat severity score.
There will be a DDNA score for the original binary plus any child processes spawned off during
execution. Associated with each DDNA score will be a DDNA Sequence which enumerates a set of
Behavioral Traits and a weight for each trait. The Behavioral Traits provide automated metadata
describing each binary.
The starting point for DDNA analysis is a physical memory image. After the binary has executed for a set
time within REcon within the virtual machine, the VM is automatically suspended and imaged in the
form of a VMware .vmem file. The DDNA module analyzes the raw physical memory image and
reconstructs the entire operating system and all digital objects contained within it. The binary under
test and its child processes are extracted and analyzed. Results go into the database and report.
Reporting System
The TMC Reporting System gives high level behavioral information as described below:



Digital DNA results showing the binary and its child processes, DDNA threat severity scores,
DDNA sequence, and Behavioral Traits.
High level runtime behaviors such as
o Network activity
o Registry key changes
o Filesystem activity
o Processes launched or killed
o Suspicious runtime behaviors such as process and DLL injection activity
Optional. Use HBGary Responder Professional to review and analyze all low level data.
HBGary Responder Professional
Responder Pro is a tool for cyber security professionals that combines physical memory forensics and
static and dynamic binary reverse engineering into an integrated platform. It helps skilled analysts to
get work done faster. It allows lower skilled engineers to do meaningful work where they would
otherwise struggle with other conventional tools.
TMC does automated, scalable triage binary analysis and reporting. Responder Pro is used for deeper
dive analysis by an engineer. The same memory analysis, DDNA and REcon features of TMC exist within
Responder Pro, albeit packaged for a single user via its user interface or a command line utility.
Responder Pro has many features that allow the engineer to go beyond the information generated by
TMC.
A use case for Responder Pro is to import the low level Journal File created by REcon within TMC or to
reproduce the Journal File by using the standalone version of REcon. Responder Pro has the capability
to view, search and parse the low level runtime data. Below is a screenshot of the Track Control of an
imported Journal File. The user can see binary activity by activity type and timeline. By selecting an
activity type and time slice the user can see the corresponding low level data and a control flow graph.
Think of it as a binary “playback” feature.
Control Flow Graph
Track Control by Timeline
Responder reconstructs and organizes all digital
objects found in the memory image. The screenshot
to the right shows digital objects such as modules,
open files, open network sockets, open registry keys,
documents and messages, internet history, keys and
passwords, processes and drivers. Not shown in the
graphic is more information. Within processes and
drivers the user can drill down to see all executables
and within each executable see lower level
information such as stings, symbols, memory map,
threads, assembly code deadlisting, etc. Associated
with each digital object is a corresponding detail
panel. There are also panels for the interrupt
descriptor table (IDT) and system service descriptor
table (SSDT).
Digital Objects Tree View
The screenshot below shows the Binary View. The blue bars along the left side of the view indicate
code coverage. Code coverage refers to a block of code with runtime data available from a REcon™
generated Journal File. Clicking the runtime data (indicated by blue bar), opens the Samples window on
the right. This illustrates how the user can work with both static disassembly and dataflow data
acquired during runtime.
Binary View showing code coverage and dataflow tracing
Responder Pro has many more features not described in this document.