I recently reported the availability of a new version of MANDIANT First Response. The program looked interesting to me, so I promised to take a closer look. Now, here are the results.
After downloading version 1.1 of MANDIANT First Response from c|net, I started the installation. On the first run, the requirements were not met (intentionally!) and the installer complained about the missing .NET 2.0 runtime. The error message was clear and helpful, as the installer directed me to Microsoft's download site.
Several megabytes and a reboot later .NET 2.0 runtime was installed. Now the installation of First Response went flawlessly. First a registration dialogue appears.
MANDIANT First Response is a client-server application. The part visible to the user is the client, named First Response Command Console. Upon its first run it prompts the user for a master password.
This password will be used to secure communications between client and server as well as potentially sensitive data stored on disk.
Your next task will be to deploy the server part, named the agent. For this just click on the Deploy button and select a directory to store the agent files in. No software gets installed at this stage, so you could store the files even on a removable media.
You could either use the agent locally or copy it to a remote machine. You could also choose to run the agent from the command line or to install it as a windows service. Please see the online manual for a list of command line options and service installation parameters.
I decided to run the agent locally ("-d") from the command line: fragent -d -bind:127.0.0.1 For my tests I didn't want to expose the agent to the network, so I bound it to localhost only. By default it will listen on any local address.
Now that the agent was running and waiting for connections, I added "localhost" as a new host and started an audit. I could see the connection request followed by several commands fly past in the agent's command window.
With a double click on the host entry all performed audits become available for review. The results are split among several sections, accessible through register tabs. System provides some basic information about the audited system: Hostname, Windows version, memory, CPU type and speed among them.
Processes lists the processes visible to the agent with their PID, start time and some more. The next tab displays open Ports and maps them to a process. Selected Registry keys appear on their own tab. First Response also queries Event Logs and consolidates their contents. Services are listed with their PID, service account and some other information known from the service control applet. Tasks lists all commands scheduled for later or periodic execution through the "at" command or the Scheduler service. The next tab enumerates the Files found on the target system along with their MAC times. Whenever an audit subroutine encounters a problem, this will be reported on the Issues tab.
The examiner may change the sort order of any of the lists provided. Entries can be flagged in one out of six colors.
On the last tab all flagged entries can be compiled into a Report. The report then can be saved in HTML format.
I noticed that a custom event log I use for testing purposes was not captured. First Response seems to stick with the default triple of Application, Security and System logs.
I was curious about how First Response enumerates the list of processes. So I launched a malicious process (in fact it was just an instance of notepad) and hid it from the Windows API with an elder version of the FU rootkit. FU hides a process by unlinking its EPROCESS control structure from a list. I was slightly disappointed to see my "malicious" program missing from the next audit report.
I conclude that MANDIANT First Response relies on the Windows API. This could limit its use depending on the kind of attacks you're expecting to detect and analyze. Nevertheless it is a clean and easy to use tool.
