3WoO Day 6: Learning From Malware Part II–The Rules

Yesterday, I blogged about some annoying malware. The point was to learn some of the techniques that this general class of malware uses, so we could write some OSSEC rules to detect it. If you haven’t already read that post, go back and read it so you’ll understand this one.

One indicator of malware is that it changes the hosts file and redirects sites to localhost. There are three different ways we can detect this with OSSEC:

  1. A basic file integrity check, although this doesn’t tell us what changed.
  2. A command output check which echoes the contents of the file
  3. A compliance check

File integrity checks are pretty simple. All you have to do is tell OSSEC to monitor the file. Let’s focus on the command output and compliance checks.

  1. Command output. Unfortunately, the report_changes option is not available for Windows right now. To get the content of the file into OSSEC, we’ll simply use the built-in Windows type command to achieve our objective. Put this in your ossec.conf on the agent (watch for wrapping):
  2. <localfile>
    <log_format>full_command</log_format>
    <command>%COMSPEC% /C type %WINDIR%\system32\drivers\etc\hosts | %WINDIR%\system32\findstr.exe /BVC:”#”</command> <alias>Windows Hosts File</alias>
    </localfile>

    Now, just add a rule like this so you’ll get the diff:

    <rule id=”100027″ level=”7″>
    <if_sid>530</if_sid>
    <match>ossec: output: ‘Windows Hosts File'</match>
    <check_diff />
    <description>Windows Hosts File Changed</description>
    </rule>

    At this point in time, there is a bug in OSSEC, which means that the diff of the file will not be in the email, but it should be in the original alert in alerts.log.

  3. Compliance checks. Compliance checks are part of the rootcheck functionality of OSSEC and are run right after the syscheck (file integrity) scans. They allow you to look within files, registry keys and processes for certain values, and alert on them. For this example, we want to know if there are any entries other than the expected localhost entry. Simply add this to your etc/shared/win_malware_rcl.txt file (watch for wrapping):

[ Site Redirected to localhost] [any] []

f:%WINDIR%\System32\Drivers\etc\HOSTS -> r:^127.0.0.1 && !%WINDIR%\System32\Drivers\etc\HOSTS -> r:^127.0.0.1\s+localhost;

Referring back to the original post, it would not be difficult to take the other examples and make them into general purpose checks. One word of caution: there is currently no local_win_malware_rcl.txt capability, so be sure to back up your changes; otherwise, they will be overwritten when you next upgrade.

What other examples from malware can you think of that would make for good rules? I would be happy to hear about your experiences in the comments.

Tagged with:
0 comments on “3WoO Day 6: Learning From Malware Part II–The Rules
1 Pings/Trackbacks for "3WoO Day 6: Learning From Malware Part II–The Rules"
  1. […] you can see, these are behavioral observations. In part II, we’ll take these observations and make them actionable within OSSEC. Stay […]

Leave a Reply

Your email address will not be published. Required fields are marked *

*