File Integrity Monitoring - Agentless Issues in Detecting Changes to Files

The Core Issue: Agentless FIM is for VM Posture, Not Real-Time Event Detection

This is the fundamental concept that is often misunderstood from the documentation. The agentless FIM capability is not a real-time or near-real-time event monitoring system like the traditional agent-based FIM.

• Agent-Based FIM (The Old Way): Uses the Log Analytics Agent or Azure Monitor Agent. This agent runs on the VM, hooks into the OS, and can detect file changes almost instantly. It generates an event at the time of the change.
• Agentless FIM (The New Way): This feature works by taking snapshots of your VM's disk at a point in time. It then analyzes that snapshot offline to check the state of the files you've specified. This process is designed for periodic configuration and posture assessment, not for event-driven security alerting.

The key takeaway: The agentless scan occurs once every 24 hours. It compares the current state of the file in the latest snapshot to the previous state from the snapshot 24 hours prior.

Why Your Changes Are Not Being Detected

Based on your description, the most likely reason you are not seeing any changes is due to the nature of how you are testing and the limitations of the snapshot comparison method.

Let's walk through a likely scenario:

1. Day 1, 3:00 AM: Defender for Cloud takes Snapshot A of your VM's disk. The file C:\test\myfile.txt exists and has a hash of abc.
2. Day 1, 10:00 AM: You log in and modify myfile.txt. Its hash is now def.
3. Day 1, 11:00 AM: You then delete myfile.txt.
4. Day 2, 3:00 AM: Defender for Cloud takes Snapshot B. It analyzes the disk and sees that myfile.txt does not exist.
5. The Comparison: The agentless engine compares Snapshot A to Snapshot B.
   • In Snapshot A, the file existed.
   • In Snapshot B, the file does not exist.
   • Result: The engine should generate a "File Deleted" change record. However, it never saw the "Modified" state. The modification happened and was then erased before the next snapshot was taken.

The most probable reasons for your issue are:

1. Transient Changes: If you add a file and then delete it between the 24-hour snapshot intervals, the agentless scanner will see no net change and will not generate an alert. It's blind to anything that doesn't persist from one snapshot to the next.
2. Initial Baseline Not Yet Established: When you first create a custom rule, the system needs to perform an initial scan to establish a "baseline" state for that file. If your changes were made before this initial baseline was successfully created, the system has nothing to compare against. It can sometimes take more than 24 hours for the very first scan of a new rule to complete and establish this baseline.
3. Scope and Configuration Issues:
   • Correct Subscription: Ensure the custom rule was created in the context of the correct subscription where the VM resides.
   • Pathing: Double-check the file paths in your custom rule for any typos. The paths are case-sensitive on Linux. Use wildcards (*) if you are unsure of the exact path. For example, instead of C:\Users\Admin\Desktop\test.txt, try C:\Users\*\Desktop\test.txt.

How to Test Reliably: To properly test an agentless FIM rule, you need to make a change and leave it there for at least 24-48 hours.

• Test 1 (Modification): Modify a file and do not touch it again. Wait for the next scan cycle.
• Test 2 (Addition): Add a new file to a monitored path and leave it there.
• Test 3 (Deletion): Delete a file that you know existed during the previous day's scan.

Can Agentless FIM Monitor Folders/Directories?

This is an excellent question, and the documentation is indeed not explicit on this point.

The answer is no, not directly in the way you might expect.

Agentless FIM is designed to monitor the integrity of specific, known files or a set of files defined by a pattern (using wildcards). It does not have a concept of "monitoring a directory for any change."

• You CAN use wildcards to monitor all files within a directory. For example, you can create a rule for the path C:\inetpub\wwwroot\*. This will monitor every file directly inside the wwwroot folder. If a file is added, deleted, or modified in that folder, it will be detected on the next scan.
• You CANNOT monitor the directory itself. The system will not alert you if the permissions on the wwwroot folder itself are changed.
• Recursive Monitoring: The documentation is unclear, but typically, FIM rules are not recursive by default. A rule for C:\inetpub\wwwroot\* will likely not monitor files in C:\inetpub\wwwroot\images\. To monitor subdirectories, you would need to use a recursive wildcard pattern like C:\inetpub\wwwroot\**\*. You should test this specifically, as support for recursive wildcards can vary.

Summary and Recommendations

1. The Problem is Likely Timing: Your custom rules are probably not firing because the changes you made were transient or happened before a stable baseline was established. Make a persistent change and wait 48 hours to confirm.
2. Think Posture, Not Events: Use agentless FIM to answer the question, "Is the configuration of my critical system files the same as it was yesterday?" Do not use it for real-time threat detection. For that, you still need agent-based solutions or EDR (like Defender for Endpoint).
3. Use Wildcards for Directories: To monitor a folder, create a custom file rule using a wildcard path (e.g., /etc/* or C:\Windows\System32\*). This will track the addition, deletion, and modification of files within that folder.
4. Verify RBAC and Scope: You've already checked the Key Vault RBAC, which is great. It's always worth double-checking that the Defender for Cloud plan is enabled on the subscription and that the VM is correctly onboarded and visible in the Defender for Cloud inventory.

Agentless FIM is a powerful tool for compliance and posture management, but understanding its snapshot-based nature is the key to using it effectively.