Which Windows Files Should be Monitored by HIDS?

Question

I highlighted my question below. Here is some background.

It's easy to find data showing the most commonly trojaned/modified Linux binaries and config files. ps, ls, find, kill, lsof, passwd, shadow, syslog.conf, etc. are all frequently changed after a system has been compromised. It's also easy to monitor utmp and wtmp to be alerted when a user logs onto a Linux system or when someone reboots the system.

Windows seems to be much more of a black box and more difficult in general to monitor. Part of this is due to the registry and lack of plain-text configuration files while part of it seems due to the closed-source, undocumented nature of Windows. And when I say, 'monitor' I mean know in real time that a file has changed through alerting (not logging). Send me an alert via sms, email, etc when X executable changes or when the local SAM file changes or when a virus reboots the system to install an infected MBR. And really, integrity monitoring is easy, the difficult part is knowing what files on Windows should be monitored. We can't monitor and alert on all files.

Is there an official list of commonly trojaned/modified Windows files that should be monitored by a HIDS?

Answer 1

A reasonable approach here might be to see what existing HIDS products do in this regard. If we take OSSEC as an example, per the book on their site has a long list of both files and registry keys that are monitored for changes (P84 in the linked PDF)

In general windows system files are mostly in c:\windows, so a lot of files to be monitored will be in that location.

Answer 2

This removal guide from Norton has a lot of good information on registry keys and files most commonly targeted. For sure anything in the start-up folder. https://us.norton.com/support/premium_services/malware_removal_guide.pdf

See page 18-19, for instance.

Answer 3

Short answer is, start with the core Windows locations then build up more folders with exclusions over time.

On a Windows system, file integrity monitoring should be applied to at least the Program Files, Program Files (x86), System 32 and SysWOW64 (operating system files, exe, driver, and DLL files). Applying FIM to the Windows System Drive C:\Windows is also a legitimate approach but as ever, the broader the reach of the monitoring net, the more false positives that will need to be managed.

To this end, it will be necessary to then exclude any files that are known and expected to change regularly, such as live log and database files, for example, C:\Windows\Logs. This ensures that the ‘noise’ from regular activity is removed and therefore providing focus on irregular, unexpected changes.

A good Windows FIM tool will allow filters to be applied by file type/extension or through pattern matches based on regular expressions to fully/partially match a file/folder name, both for inclusion and exclusion of files for monitoring.

Likewise for the Registry – the registry comprises millions of values, many of which change frequently during regular operation of the Windows server. Similarly ‘fine-grain’ inclusion/exclusion configuration for registry file integrity monitoring is essential in order to provide a low maintenance but forensically precise FIM solution.