Detecting compromises with File Integrity checks (Part 2)

In our last post, we talked about how you can use our File Integrity Monitoring policy templates to monitor setuid files on your system. There are 5 other categories of files that are particularly deeply tied to system security, likely to be modified in an attack, or both.  Let’s take a look at each group.

Boot. Setuid programs are not the only files whose modification might indicate a system compromise.  After an attacker breaks in and reaches root level by some method, they need to make sure they can get back in again later.  They can’t depend on the same exploit they used to get in in the first place; the administrator may patch that in the near future.  In fact, the attacker might patch it herself to block other attackers from getting in the same way.

What they’ll commonly do is open up some kind of back door that will work even when the original vulnerability is patched or the system is rebooted.  That means they need to change at least one of the files involved in booting the system to start up some program that will let them in later.  If we watch all the files involved in booting the machine, we’ll get alerted if any of them are modified, and that gives us a chance to investigate and see if we do have a break in.

cron. There’s another way that the attacker can open up a backdoor for themselves in the future; by scheduling “cron” or “at” jobs.  Both provide support for running a series of commands at some point in the future; cron jobs run regularly (such as “every hour”) and at jobs are run once (such as “3pm tomorrow”).  These commands could include starting up a daemon or making an outbound connection to a machine under the attacker’s control, both with the goal of  accepting new commands from the attacker.

Kernel. The Linux kernel and its modules also need to be monitored.  Neither have any restrictions on what actions they can take when loaded; a malicious kernel module can read any file, open up a port for commands, hide the existence of files and processes, and lie to any application about the state of the system.  If there’s any chance that a kernel or module has been modified or added, the system can no longer be trusted to return accurate information.

While kernel level attacks are less common, the severe difficulty of performing forensics on the problem and cleaning up the system gives more than enough motivation to keep a close eye out for any changes or additions.

Identity. We talked earlier about setuid programs (such as “passwd” and “su”) and how they’re of particular interest to attackers wanting to raise their privileges to that of the root user.  In addition to those we also want to keep an eye on any other programs involved in identity management – programs that manage who you are and what rights you have.  While some of the programs in this category have the setuid flag turned on and therefore fall in both groups, some do not (such as /bin/login and /sbin/mingetty).  Like the other programs we’ve mentioned above, a change in one of these files may point to a compromise.

Security. The final category is programs related to system and package security.  Package security includes the package installation and upgrade programs such as yum and rpm; modified versions of these tools could hide malicious packages that have been installed.  System security includes the configuration files for both TCP wrappers (a firewall approach built into some applications) and Selinux (an enhanced security tool that blocks operations that an application shouldn’t be making, such as the “dir” program trying to listen on a network port).

For all 5 categories, we include both the executables we’ve mentioned (such as the “sudo” program that runs programs as another user) as well as their core configuration files (for sudo, both the /etc/sudoers file and the /etc/sudoers.d directory that also holds configuration file snippets).  An attacker doesn’t necessarily need to change the sensitive executable to get additional privileges; adding the right line to /etc/sudoers can give her root privilege from a command line session, so we monitor both.

All 5 categories are covered in a single FIM Policy Template called “Monitor Privilege Escalation (Linux) v1”.

Will these catch all attacks?

Sadly, no.  With these File Integrity Monitoring policies, we’ll catch attacks that actually modify one of these critical files on disk.  If the attack only exploits a running copy of one of these programs but never changes anything on disk, File Integrity Monitoring won’t catch the attack.

The good news is that there’s a reasonably good chance that the attacker will have to modify files in at least one of the 6 categories as part of 1) the initial break in, 2) the process of getting root privileges, or 3) putting in a backdoor to guarantee future access.  The common goal of getting back in later all but requires modification to files in one of these categories.

These FIM templates are designed to provide ready-to-run checks for especially sensitive files.  We encourage you to customize them for your own needs and cloud servers.  You’re welcome to make changes to the imported template or create a new FIM policy to monitor additional files you consider critical.

Additional information

Quick intro if you’ve used File Integrity Monitoring tools from another vendor
Basic concepts of FIM



Stay up to date

Get the latest news and tips on protecting critical business assets.

Related Posts