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)

Microsoft OOB Patch for Internet Explorer: Scripting Engine Memory Corruption Vulnerability

Published: 2018-12-19
Last Updated: 2018-12-19 19:16:50 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

Microsoft just published an out-of-band patch for Internet Explorer. It fixes a memory corruption vulnerability in the scripting engine. This vulnerabiliy is identified as CVE-2018-8653.

When successfully exploited, Internet Explorer could execute arbitrary code in the context of the current user. To exploit the vulnerability, the victim must just visit a malicious web page delivered through a phishing email or social engineering. 

Internet Explorer version 9, 10 & 11 are affected. For a detailed list of the affected systems, Microsoft published the details here:

Please install the provided patches as soon as possible!

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

0 comment(s) New VMWare Security Advisory: VMSA-2018-0031

Restricting PowerShell Capabilities with NetSh

Published: 2018-12-19
Last Updated: 2018-12-19 10:27:14 UTC
by Xavier Mertens (Version: 1)
2 comment(s)

The Christmas break is coming for most of us, let's take some time to share some tips to better protect our computers. The Microsoft Windows OS has plenty of tools that, when properly used, can reduce risks to be infected by a malware. As best practices, we must have antivirus enabled, we can deploy AppLocker to allow only authorized applications to be launched, we can restrict applications to be executed from locations like %APPDATA% or %TEMP% but they are tools that are much more difficult to restrict on a regular host like... Powershell! If you uninstall Powershell from a modern Windows version, you’ll simply miss nice features. That's why, in many cases, a simple uninstall is not possible. That’s also the reason why Powershell remains a nice first stage infection method:

  • It is installed by default
  • Its code is easy to obfuscate
  • It uses the complete Microsoft API to download files, execute them or perform injection or more low level operations.

Windows has a built-in firewall that provides interesting features. You can not only restrict traffic based at layer 3: from <ip>:<port> to <ip>:<port> but you can also restrict traffic based on application. Microsoft recommands to enable this firewall (and you receive continuous notifications when it's not).

Let’s create two rules. The first one allow Powershell to access our local subnet and the second one drops any traffic

C:\> netsh advfirewall firewall add rule name=“PS-Allow-LAN" dir=out \
     remoteip=localsubnet action=allow program="c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe" \
C:\> netsh advfirewall firewall add rule name=“PS-Deny-All" dir=out \
     action=block program="c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe" \

Of course, we can have multiple Powershell binaries spread across the file system. Let’s add the above rules for all of them:

C:\> for /R %f in (powershell*.exe) do (
netsh advfirewall firewall add rule name=“PS-Allow-LAN (%f)" dir=out remoteip=localsubnet action=allow program=“%f" enable=yes
netsh advfirewall firewall add rule name=“PS-Deny-All (%f)" dir=out action=block program=“%f" enable=yes

Note that this technique does not block nasty malware like the one which was reported by Didier in a recent diary[1]. In this case, a copy of Powershell was used with a random name. If you use a proxy to access Internet resources, it could also be a good idea to restrict access to its IP address.

Finally, Powershell (if run with enough privileges) can disable the local firewall:

Set-NetFirewallProfile -Profiel Domain,Public,Private -Enabled False

You can apply the same kind of control to other tools that should not access Internet resources.


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

2 comment(s)
ISC Stormcast For Wednesday, December 19th 2018


Diary Archives