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:
- A basic file integrity check, although this doesn’t tell us what changed.
- A command output check which echoes the contents of the file
- 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.
- 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):
- 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):
<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.
[ 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.