Using OSSEC Active-Response as a DFIR Framework

Published: 2018-12-19
Last Updated: 2018-12-20 07:48:42 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

In most of our networks, endpoints are often the weakest link because there are more difficult to control (example: laptops are travelling, used at home, etc).They can also be located in different locations even countries for biggest organizations. To better manage them, tools can be deployed to perform many different tasks:

  • Remote support (used by the helpdesk to gather information about the host and take remote control of the session to help the user)
  • Antivirus solutions (lookg legit)
  • HIDS solutions (for detection)
  • Security agents (for investigations)
  • ...

The multiplication of all those agents requires resources, a deployment process, maintenance and so on. Depending on your network size, specific tools can also be very expensive when the licensing model is based on IP addresses or endpoints. There are nice solutions to perform remote forensic actions on a host like Google Rapid Response[1], Mozzilla InvestiGator[2] or FastIR[3] but all of them require a specific plugin. Why not try to reduce the number of such agents and use the available features at the maximum? OSSEC[4] is a well-know HIDS solution that uses its own agent to be deployed on hosts to protect. Then, it can export logs to a central server, check for changes on file systems (via a 'File Integrity Monitoring' feature), search for rootkits and trojans. But it has also a feature called ‘Active-Response’. This feature is defined on the OSSEC website like:

"The Active Response feature within OSSEC can run applications on an agent or server in response to certain triggers. These triggers can be specific alerts, alert levels, or rule groups."

The classic usage provided by default with a fresh install of OSSEC is a protection against brute-force attacks. When such attack is detected, a script is launched via the agent on the targeted system to block the attacker. These actions are usually reactive to reduce the surface attack. Another example is the automatic generation of your own blocklist based on our DShield database (This was one of my first diaries published on the ISC website[5]).

But the Active-Response principle can also be used in a DFIR approach to gather evidences from a remote host when something suspicious has been detected! Active-Response can be configured to execute anything on the host. Why not prepare some scripts to perform the following actions:

  • To start a full-packet capture based on the attacker IP address
  • To take a memory image of the host
  • To list processes and open files on the host
  • To search for a file or execute a YARA scan

As an example, let’s take the case of a full packet capture. To configure a new Active-Response action, follow these steps:

Create a new command:


Create the new active-response:

  <rules_id>100100, 100200, 100300</rules_id>

How to read these XML blocks? When alerts 100100 or 100200 or 100300 are triggered, execute on the endpoint the script ’’ with the source IP address of the event in argument (which is the attacker’s IP address).

The script looks like:

[ "x${IP}" = "x" ] && exit 1
echo "`date` $0 $1 $2 $3 $4 $5" >> ${LOG_FILE}
/usr/sbin/tcpdump -i any -s 0 -G 600 -W 1 -w /var/tmp/tcpdump-$IP-%Y%m%d%H%M.pcap src host $IP or dst host $IP

This script will execute tcpdump for 10 mins and write packets in a unique file in /var/tmp.

Even better, OSSEC provides a management tool to manually start manually an Active-Response script on an endpoint:

# ./agent_control -b -f tcpdump-attacker -u 025

This command will capture all the traffic from/to the Google DNS for 10 mins on the agent ID 025.

This solution does not provide the flexibility of classic DFIR agents but, if you already deployed OSSEC, you have a nice way to collect information from a remote host!

[4] https:///

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant

0 comment(s)


Diary Archives