What is File Integrity Monitoring (FIM)?

What is file integrity monitoring?

File Integrity Monitoring (FIM) is a security measure that checks and compares files against a known baseline to detect any changes. The baseline is a snapshot of your files in their original, unaltered state. FIM detects alterations in file content, permissions, or ownership and alerts the system or administrator of these changes.

FIM plays a significant role in website security for several reasons.

Firstly, it functions as an early detection system. If a hacker gains access to your website and modifies files, or if malware alters your site’s code, FIM will flag these changes. This allows for rapid response and minimizes potential damage.

Secondly, FIM is a valuable tool for troubleshooting website functionality issues. Changes to code, even minor ones, can disrupt your website. FIM can identify these changes, making it easier to rectify issues and restore website functionality quickly.

Thirdly, FIM can help your website maintain compliance with industry standards and regulations. For example, the Payment Card Industry Data Security Standard (PCI DSS) requires continuous file integrity monitoring. Maintaining compliance is crucial for businesses that handle sensitive data, and FIM is an essential tool in this regard.

File integrity monitoring is a crucial piece of Sucuri’s server side scanner. We rely on it when we are responding to incidents for our clients, particularly when we are looking for new, undetected malware samples.

What is server side scanning?

When it comes to the ABCs of website security server side scans and file integrity monitoring are the “A” and “B”. In fact, a server side scanner is one of the most crucial tools in a website’s arsenal.

Server side scanners handle tasks like issuing security warnings and alerts to webmasters, notifying them that they have been compromised, and assisting our analysts in detecting new and emerging variants of malware.

Remote scanner vs. server side scanner

Not all malware displays outwardly in a website environment. Our remote website scanner SiteCheck tool (free for anybody to use) is responsible for flagging outward facing (usually JavaScript or database) malware that appears in the source code. On the other hand, our server side scanner is responsible for alerting webmasters about backend, PHP malware.

If you’ve ever faced a website compromise and our SiteCheck tool shows that your website is totally clean there’s a good chance that the payload is in the PHP files. As a remote scanner SiteCheck simply cannot see that compromise.

All Sucuri clients have server side scans included in their security plans with us. When this service is enabled if a website is compromised you should receive a security alert for any known malware. If the server side scanner is not enabled, the user would only find out about a compromise after the fact – once their website starts exhibiting symptoms of the compromise (malicious redirect, stolen credit card details in e-commerce environments, etc). Definitely get this configured when you are setting up your Sucuri plan.

Put on your Sherlock hat and grab your monocle, folks, because we’re going to take a look at some real world examples of investigating compromised websites!

Examples of skimmers hiding on website servers

Attackers often target the Magento ecommerce CMS platform. Since it’s an ecommerce platform, all Magento websites handle credit card and payment information in some capacity, so any attackers looking to steal credit card numbers are going to be trying to compromise these environments.

Example 1 – Magento credit card skimmer hiding on the server

Some time ago, a client of ours was reporting compromised credit card details on their Magento website. However, our initial scans showed everything was clean. So we knew that this must be some new malware that was as-of-yet undetectable. Parsing through the server side scanner logs, we found the following entry:

The size of a particular file had changed substantially in size. But why?

Once we inspect the file and compare it to a fresh copy of the file from the Magento repository we can see that a credit card swiper was added to the file once the attackers compromised the environment:

The swiper takes the information like the credit card number and expiration date and spirits it away to a malicious exfiltration IP address (big ups to DiffChecker for their very useful tool that I use almost daily!)

Example 2 – Backdoor hiding on the server

Let’s take another example – this time with a more subtle size change:

In this case a backdoor was added to the ./downloader/index.php file in this environment. Astute readers will also notice that ccard.js and other files pictured had a lot of code added to it as well, and yes, there was a swiper there too!

Both of these first two examples were not yet detectable by our automated tools or monitoring: The attacks were brand new malicious samples with no signature written yet.

Remember, there are people whose full time job it is to compromise websites and sell stolen credit card details on the dark web. They have a vested interest in regularly writing new malware that evades detection.

As analysts, it’s our job to find the new malware and then ensure our monitoring tools are able to see it. Once the tools can detect it any other clients affected by the same type of malicious code can be alerted.

Even small, subtle changes are logged in the server side scanner. It’s an absolutely crucial component of our security product and amazingly useful when working on investigations like the type above.

Example 3 – Credit card stealer and backdoors hiding on the server

Here’s another clue that we need to do some digging:

Here, you can see that we performed a cleanup of a client’s website and removed two backdoors.

However, attackers do not place backdoors without connection to anything else: They do so with the express intent of delivering their malicious payload. This could be for any number of reasons from stealing credit card numbers, delivering spam or redirecting the visitors to malware websites, or phishing for credentials.

In the above example, we can see that on the same day that those backdoors were added a functions.php file was also modified:

Let’s take a look at this file, shall we?

There’s the credit card swiper!

By cross-referencing the modified dates of the backdoors with the modified dates of other files around the same time we can find new payloads that the attackers have written. Sometimes these are obfuscated with things like concatenation and other techniques to avoid detection. Other times, they are sitting out in the open like the above example.

Example 4 – Credit card swiper on the server

One more, while we’re at it:

In this case the scan itself did catch some malware but that doesn’t tell the whole story. In the same way that a backdoor indicates the presence of a malicious payload the existence of some malware can indicate the presence of more.

On a closer look at this example we actually find a credit card swiper placed into the environment as well.

More investigation is always necessary to ensure that we haven’t missed anything. Sometimes we have signatures written for some of the malicious files but not others, so when performing an investigation it’s always good practice to be as thorough as possible.

Why are FIM and server side scanners important?

File integrity monitoring and server side scanners are indispensable tools for both monitoring and remediation processes. It can both directly find compromises as well as provide webmasters and researchers with the information needed to discover others.

In addition to that, Sucuri founder Daniel Cid also wrote a very helpful extension for VPS hosting environments that runs on the server itself (rather than from within the website files) called OSSECHIDS which, among many other features, includes robust file integrity monitoring.

If you’re a Sucuri client already and haven’t yet set up this monitoring service please see this article for some helpful steps.

Unsure how to get it configured? That’s ok! Just submit a ticket with our product support team and we’re happy to help you get it set up.