How to monitor running processes with OSSEC

In this post I am going to explain what are the steps to use OSSEC agents to monitor system processes, and alert when an important one is not running. This method should work both for Windows and Unix like Operating Systems. In my lab I've deployed the agent on a Windows Server 2012.

1.-Accepting remote commands

First step is to configure the agent logcollector option to accept remote commands from the manager. That can be done editing "internal_options.conf" file (usually located at "C:\Program Files(x86)\ossec-agent\internal_options.conf") and setting the variable logcollector.remote_commands to 1.

# Logcollector - If it should accept remote commands from the manager
logcollector.remote_commands=1 

Once we have save this change, we just need to restart the agent for it to be applied.

2.- Specifying the command to list running processes

This is a configuration that can be done both at the agent or at the manager (using the shared directory). It only depends on how many agents you want this command to be used. In my case I decided to edit "/var/ossec/etc/shared/agent.conf" configuration file, and have these settings pushed to my windows agents.

<agent_config os="windows">
    <localfile>
        <log_format>full_command</log_format>
        <command>tasklist</command>
        <frequency>60</frequency>
    </localfile>
</agent_config> 

The command I used to list processes in Windows like Operating Systems is "tasklist". There are other options like using wmic, but this one looked good enough to me. For Unix systems you might want to use "ps".
On the other hand, notice that under log_format I choiced "full_command". This is because I want my OSSEC rules to be able to parse the whole command output, instead of parsing the output one line at a time.
At last, the frequency defines how often, in seconds, will this command be run. Feel free to adjust this setting to whatever makes more sense in your environment, keeping in mind the added load that can be generated in the system by running commands too often.

3.- Creating local rules

In this step we edit our "/var/ossec/rules/local_rules.xml" file to add rules that will trigger an alert if our critical process is not running. For the purpose of this example I will use "wordpad.exe" but, of course, it could be any other name.

<rule id="100050" level="7">
  <if_sid>530</if_sid>
  <match>^ossec: output: 'tasklist'</match>
  <description>Critical process not found.</description>
  <group>process_monitor,</group>
</rule>
<rule id="100051" level="0">
  <if_sid>100050</if_sid>
  <match>wordpad.exe</match>
  <description>Processes running as expected</description>
  <group>process_monitor,</group>
</rule>

The first rule (id "100050") will trigger a level "7" alert every time tasklist command is executed, unless (as defined in rule "100051") the output matches the string "wordpad.exe". If this is the case the alert level is set to "0", meaning that that no alert would be triggered.
Now we just need to save these changes and restart the manager for them to be applied. We can do that running "ossec-control restart" command.

4.- Testing our configuration

In order to test the configuration it is good to enable OSSEC "logall" option, so we can see the output of tasklist in archives.log everytime it is executed. See below an example (I cut some lines for brevity).

2015 Aug 07 18:38:03 (vpc-agent-windows) 10.0.0.124->tasklist ossec: output: 'tasklist':
Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
System Idle Process              0 Services                   0          4 K
System                           4 Services                   0        284 K
smss.exe                       328 Services                   0      1,060 K
csrss.exe                      484 Services                   0      3,584 K
...
...
...
notepad.exe                   1596 RDP-Tcp#37                 2     14,500 K
win32ui.exe                    828 RDP-Tcp#37                 2      6,088 K
ossec-agent.exe               3060 Services                   0      5,576 K
notepad.exe                   2276 RDP-Tcp#37                 2     12,076 K
wordpad.exe                    368 RDP-Tcp#37                 2     27,780 K
cmd.exe                        780 Services                   0      2,692 K
conhost.exe                   1304 Services                   0      3,044 K
tasklist.exe                  1692 Services                   0      5,668 K

And, once wordpad.exe process is stopped. An alert like this is triggered as expected. We can see it in "/var/ossec/logs/alerts/alerts.log" file.

** Alert 1438997816.32112781: mail  - local,syslog,process_monitor,
2015 Aug 07 18:36:56 (vpc-agent-windows) 10.0.0.124->tasklist
Rule: 100050 (level 7) -> 'Critical process not found.'
ossec: output: 'tasklist':
Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
System Idle Process              0 Services                   0          4 K
System                           4 Services                   0        284 K
smss.exe                       328 Services                   0      1,060 K
csrss.exe                      484 Services                   0      3,584 K
...
...

Of course, using email alert option and the above configuration, you can automatically be notified if one of your critical processes stopped running.
And that is all. I hope you enjoyed the tutorial and found it useful.

Threat Intelligence with Open Source Tools - Cornerstones of Trust 2014

Cornerstones of Trust 2014: http://cornerstonesoftrust.com.
Presenters: Jaime Blasco (@jaimeblascob) and Santiago Bassett (@santiagobassett).  Thank you Jaime.

Threat Intelligence has become increasingly important as the number and severity of threats is growing continuously. We live in an era where our prevention technologies are not enough anymore, antivirus products fail to detect new or sophisticated pieces of malware, our firewalls and perimeter defenses are easily bypassed and the attacker’s techniques are growing in complexity. In this new landscape, sharing threat intelligence has become a key component to mitigate cyber-attacks.

In this session we will define what Threat Intelligence is and discuss how to collect and integrate threat intelligence from public sources. In addition, we’ll demonstrate how to build your own Threat Intelligence data using Open Source tools such as sandboxes, honeypots, sinkholes and other publicly available tools.

The industry’s reticence to share information about attack vectors gives the adversary a huge advantage. Using Threat Intelligence we can reduce this advantage and enable preventative response. We will guide you through the different standards (OpenIOC, STIX, MAEC, OTX, IODEF…) to describe and share cyber intelligence, as well as Open Source Frameworks such as CIF (Collective Intelligence Framework) that allows you to combine different threat sources.

One of the biggest problems with Threat Intelligence is finding out how to take advantage of the data you have to actually improve the detection/prevention capabilities in your environment. We will describe how to leverage Threat Intelligence to detect threats and provide defenses, and we will focus on how to use Open Source Tools (Suricata, OSSIM, OSSEC, Bro, Yara…) to get the most of your Threat Intelligence.

OSSEC CON 2014 - Malware Detection with OSSEC

Happy to share my presentation from the OSSEC CON, which took place on September 16th in Cork, Ireland. Here you can find a brief explanation of different malware collection and analysis techniques, as well as a good example of how to use some IOCs to create a rootcheck signature.

And, for those interested, here is the video as well:

Updated OSSEC debian packages

Just published new versions ossec-hids_2.8-2 and ossec-hids-agent_2.8-2, for the different Debian distributions. Those can be found here: http://ossec.alienvault.com/repos/apt/debian/pool/main/o/

Here are the changelogs:

 ossec-hids (2.8-2) stable; urgency=low  
  * Fixed Makefile to use ossec-hids-debian.init instead of ossec-hids.init (fixes LSB headers warning).  
  * Fixed CVE-2014-5284. Patch included.  
  * Included debconf and templates for initial package configuration (email_to, email_from and smtp).  

 ossec-hids-agent (2.8-2) stable; urgency=low  
  * Fixed Makefile to use ossec-hids-debian.init instead of ossec-hids.init (fixes LSB headers warning).  
  * Fixed CVE-2014-5284. Patch included.  
  * Included debconf and templates for initial package configuration (server_ip).  

And the link to the github repo: https://github.com/santiago-bassett/ossec-debian.git

I also took the opportunity to update generate_ossec.sh script, which now accepts a few different arguments:

 santiago@debian-package:~# ./generate_ossec.sh -h  
 USAGE: Command line arguments available:  
 -h | --help Displays this help.  
 -u | --update Updates chroot environments.  
 -b | --build Builds debian packages.  
 -s | --sync Synchronizes with the debian repository.  

Files to create OSSEC HIDS Debian packages

Just published, in Github, the files I used to create OSSEC-HIDS version 2.8 debian packages, the ones included both in ossec.net website and in AlienVault repository. 

https://github.com/santiago-bassett/ossec-debian

You can find these packages at: http://www.ossec.net/?page_id=19

or directly at: http://ossec.alienvault.com/repos/apt/debian/pool/main/o/

There are two different packages that can be built with these files:

• ossec-hids: Package that includes both the server and the agent.
• ossec-hids-agent: Package that includes just the agent.

Each one of the subdirectories includes:

• Makefile
• Debian control files: changelog, compat, control, copyright, lintian-overrides, postinst, postrm, preinst, rules

Additionally a script, generate_ossec.sh, is included to generate the Debian packages for Jessie, Sid and Wheezy Debian distributions, both for i386 and amd64 architectures. This script uses Pbuilder to build the packages, and uploads those to an APT repository, setup with Reprepro.

For more details on how to create Debian Packages and an APT repository you can check my post at:

http://santi-bassett.blogspot.com/2014/07/setting-up-apt-repository-with-reprepro.html

Please don't hesitate to contribute (preferably via pull requests) to improve these packages.