Basic Security Concept: FIM (File Integrity Monitoring)

What’s up Medium reader? Glad you are here. Lets not waste any time. Today I will be writing something a little different than my usual — although not too far off topic. I often find myself thinking during offensive security engagements “man, there are such simple security concepts that go overlooked, unknown, or maybe are just misunderstood that would help network defenders!” One of those concepts is “FIM”, or “File Integrity Monitoring”. This is a type of monitoring that specifically is looking for file (or directory) changes on an operating system. While it cannot be scaled to every file and directory on an OS given the extremely dynamic nature of computing — there are certainly some great use cases for this defensive technique. It’s important to understand that this isn’t something new that I am discussing, but in a world of new and shiny defensive tools using things like LLMs, heuristic detections, behavioral analytics, live threat feeds of global IOCs, and more… the basics seem to be left behind.

Threat actors are not stumped by this technique… ok? I’m not framing this technique as a silver bullet. In fact, it’s probably around the time that “fileless malware” skyrocketed that this concept really lost it’s drive in the community. BUT guess what? I personally will tell you I have dropped web shells directly into publicly accessible web directories or modified web application files several times without raising alarms in the post-“fileless malware” era. THAT means this technique would still be beneficial to the many many clients I have worked with over the years where the above was possible and I am sure that means that they are not alone.

In this blog post, I am going to focus on two attacks specifically that will serve as prime use cases for FIM…

1. Dropping a Web Shell: This is when an attacker finds a way to get a “web shell” written to a directory within a web application where they are able to access it. The web shell is a file that allows the attacker to execute operating system level commands once they access it and the web server executes it.
2. Script Injection: This is when an attacker modifies an existing file in a web application to achieve some malicious outcome. More specifically, something like writing some malicious JavaScript into an existing HTML page.

After showing each attack, we will see how the concept of File Integrity Monitoring could alert an admin/SOC analyst to each — at least in a basic way that helps prove the point.

1. Dropping a Web Shell

In order for an attacker to get a web shell onto their target web server, they generally will need to abuse a poorly configured upload feature or maybe exploit some other vulnerability that allows for this outcome. We can skip the hypotheticals for that portion and move right to the “an attacker found a way to drop a web shell — what now” part! For this we will use a demo IIS server.

Note the “physical path”. This is where the IIS application is running from. (D:\IISoBad\)

If we (from our “IIS Admin” view) look at the “physical path” from the 403 error we can check out some of the files and folders that make up the application.

Now, if the attacker managed to get a web shell (called “cmd.aspx” in this example) into the “wwwroot” directory, lets see their “attacker view”…

We can see the attacker is now able to run the Windows “cmd.exe” executable and pass the command (“/c”) “net user” to it.

This is where an attacker has a “foothold” and can continue to enumerate the server and potentially other hosts on the same PRIVATE network (internal network) to escalate privileges or move laterally. That is beyond the scope of this blog however. The point is — attacker has dropped a malicious file — the IIS admin can now see the following:

Again — this is a simple example. The file really sticks out given the lack of other files and the placement (directly in the web root). However — you can probably imagine how a less obvious filename, combined with a much much larger web application might allow for this file to go unnoticed for a period of time. So the question becomes — what directories do we expect NOT to change very frequently? Those are the prime examples of directories that should undergo this type of monitoring. The web root directory of a production web application, with no scheduled maintenance would be a more specific example of a directory that might be ideal to start with like seen here.

The other question might be — other than continuing to monitor the directory endlessly via the command line or Windows Explorer, how can the IIS admin monitor a directory for changes? I am almost positive without Googling this question myself right now that there will be a million answers. But the point here is to demonstrate the concepts, not to tell you exactly what to do or what path forward is the best for your specific situation. So let’s use a simple PowerShell script. The screenshot below shows PowerShell ISE (the native PowerShell IDE in Windows) running our simple monitoring script which will print out “DIRECTORY CHANGE DETECTED” along with some details to the PowerShell console if a change is detected in the directory. It will loop through this process every 5 seconds.

Now we add the “test.txt” file and wait a few seconds…

Well there you have it. A script that will detect a directory change. It’s only monitoring 1 directory…. and it’s only printing to the console when a change is detected… but it proves the concept. We will make something slightly more useful for the notification portion of this script later in the blog. For now, lets jump in to our 2nd attack.

2. Script Injection

I have used this technique for 2 main use cases:

1. Obtain credentials for an application I couldn’t find unauthenticated vulnerabilities in and/or that I couldn’t crack/access the hashed/encrypted credentials from the database associated with the application. However I have local admin (or at lest meaningful write access) to the web server hosting the application.
2. Obtain SSO credentials when I have local admin (or at least meaningful write access) on a server that is hosting a web application that supports SSO application logons.

Essentially what I will do here is simply inject a JavaScript based keylogger into the login page(s) of any web applications I can. If the application supports SSO (and doesn’t redirect to a different page before accepting the creds), there is room for SSO cred theft. Otherwise, perhaps the application is disconnected from AD auth or SSO methods and you really want to get in as an authenticated user to access something specific to the applications authenticated user interface. A really cool application I couldn’t get into once I finally was able to get into using this method — it was a “Prison Management System” where users had crazy strong passwords and the application seemed very well secured. It was only LAN-facing and running on a Windows server. I had however compromised the Windows server by using a domain account (that I also compromised during the assessment), that had write access to the prison management systems web application root directory.

There are a million GitHub pages that contain cool JS keyloggers and such… but to avoid making this blog way longer than needed, I am going to avoid creating a login page and the basic infrastructure to prove that keyloggers work. Instead — I want the point to be “I had to change a file to include malicious content”…

Have you ever downloaded a file and notice the hosting site say something about a file hash? “… blah blah, to confirm the file is legit you can do an integrity check and make sure the hash of the file in question matches the expected file hash” … ? Well this is essentially providing you with a way of conducting a check on the file to make sure it is in-tact and not modified. So let’s go ahead an show an example of how something like this might work in PowerShell. Again — we go back to the /wwwroot/ directory and run the following one-liner:

ls | Get-FileHash -Algorithm SHA256

This will give us the “SHA256” file hash for every file in the /wwwroot/ directory…

Lets look at a more specific example… how about that test.txt file we created earlier to trigger a “DIRECTORY CHANGE DETECTED” alert? Lets see what the SHA256 file hash for that is…

Now, let’s make a subtle change… literally just “1”” added to the test.txt file…

After we save it, we check the hash again…

We can see how a subtle change to the file results in a not-so-subtle change to the result SHA256 hash.

So, what does this mean for monitoring and alerting on file changes? Well again …. if we never expect “test.txt” to change (or a login.html page, or a passwordReset.php page, or whatever….) then ANY change should be considered suspicious at a minimum.

fim2Slack — A PoC Solution

Ok so now we know how to monitor for DIRECTORY CHANGES and FILE CHANGES… we simply haven’t put together a solution that allows for this type of monitoring to occur without a human sitting and watching the console. If a tree falls in the forest and nobody is there to hear it… does it make a noise?

I tweaked some of the code shown earlier in the blog and now it does the following….

• Monitors the web root directory for any changes
• Monitors files in the web root directory for any changes
• Should any of the above be detected, PowerShell will use the Slack API to send us a Slack “Direct Message” letting us know of the possible threat.

This simple concept can be seen working in the screenshot below after adding and deleting a “New Text Document(2).txt” file from a directory being monitored with the script:

These messages were sent directly to my cell phone (via Slack mobile application) which would be nice for folks who want to watch for changes while away from their PC. The first indicates a new file called “New Text Document(2).txt was created. The next message shows the file was deleted.

The code used can be downloaded from my GitHub (here). Please improve it or make it something cool if you could benefit from it in some way. I am no way considering this to be an actual FIM tool “as-is”… it lacks scalability, has several bugs still as of the time of this blog post, and doesn’t account for a bunch of things… one example being if the “last modified” value of a directory within the web root directory changed. Perhaps there is a directory you would expect to change frequently… this script doesn't account for any “allow-listing” or anything. It’s all possible, with not too much more work, but it wasn’t the point of this blog so here we are :). While it is possible I will improve/fix it, it is unlikely!

Final Thoughts

Security is only effective in layers. The concept of FIM is only touching on a single layer. There are certainly applications which are much more dynamic and therefore are less effectively monitored this way. Fileless malware doesn’t even flinch in the context of FIM. But understanding defense concepts can help reinforce the “bigger picture” in terms of what options exist for protecting your assets and what to look out for! Hopefully I can touch on other “Basic Security Concepts” in the future… I seem to be bad at blogging consistently 😂 so no promises!

All for now!

-N0ur5