Building My SIEM Homelab Part 4: Advanced FIM Forensic Analysis

From Alerts to Intelligence: Professional Incident Analysis

After mastering centralized FIM configuration and noise reduction in Part 3, I reached the point where my SIEM was generating consistent, high-quality alerts. But raw alerts aren't enough—professional security operations require the ability to translate technical data into actionable intelligence.

In this phase, I focused on developing forensic analysis skills by conducting a comprehensive investigation of a File Integrity Monitoring alert. This is the work that happens in a real Security Operations Center (SOC): taking Rule ID 550 alerts and answering the critical questions that drive incident response.

The Professional Forensic Framework

Every security incident investigation follows a structured methodology. For FIM events, I use a four-question framework that transforms raw JSON data into investigative conclusions:

1. WHAT happened? (File, time, change type)
2. WHO made the change? (User attribution, privileges)
3. HOW was it changed? (Content diff, modification method)
4. WHY does it matter? (Compliance, risk, business impact)

This framework ensures comprehensive analysis and supports compliance requirements for regulated industries.

The Alert: Rule ID 550 - Integrity Checksum Changed

I triggered a test alert by modifying my monitored file:

echo "FIM test via Manager group policy - FINAL CHECK." | sudo tee -a /opt/test_monitoring/secret_file.txt

The Wazuh dashboard immediately generated a Level 7 alert. Let me walk through the complete forensic analysis of this event.

1. The WHAT: Event Context and Timeline

The first step in any investigation is establishing what actually happened—the basic facts of the incident.

Alert Metadata

Forensic Interpretation

Event Nature: This was a file modification event, not a creation or deletion. The file already existed and its content was altered.

Detection Speed: The "mode": "realtime" confirms the change was detected immediately via inotify, not during a scheduled scan. In a real incident, this means we have near-instant awareness—critical for rapid response.

Integrity Compromise: All five tracked attributes changed (size, modification time, and all three hash types). This definitively proves the file content was modified, not just metadata like permissions.

Attack Timeline: The precise timestamp 2025-11-19T07:31:33.125Z establishes when the compromise occurred. In an investigation, this would be correlated with:

• Authentication logs (who was logged in?)
• Network traffic (any suspicious connections?)
• Process execution logs (what commands were run?)

Hash Verification

The alert includes complete before/after hash values:

{
  "md5_before": "f36b77f9e72d9d9a9fa9e0594fd57c9a",
  "md5_after": "b72c822b94ed1a5ed3b3f18f1ec7f260",
  "sha256_before": "36b23ee3e7634b982a444748c9310789d12cd7b144aec90695f60bbcf6b5154d",
  "sha256_after": "8cddb4f96d466527547100b698cd31a388e7c1b15ab492e72c215961b7bc2132"
}

Why This Matters: In incident response, these hashes allow me to:

• Submit to VirusTotal for malware analysis
• Search threat intelligence databases
• Reconstruct the exact file state before modification
• Verify file integrity if backups exist

2. The WHO: User Attribution and Privilege Context

The most critical forensic question in any security incident is: Who performed this action?

This is where whodata becomes invaluable. Without it, I'd only know "a file changed." With it, I have complete user context.

User Attribution Data

Forensic Interpretation

Critical Finding: The file was modified by the root user (UID 0), the highest privileged account on the system.

Why This Matters in Real Incidents:

In a production environment, seeing "uname_after": "root" immediately raises the alert priority. Root modifications could indicate:

1. Legitimate Administrative Activity (expected, low concern)
2. Privilege Escalation Attack (attacker gained root access)
3. Compromised Administrator Account (credentials stolen/phished)
4. Malicious Insider (authorized user acting maliciously)

The Sudo Factor: In my test, I used sudo in the command, which is why the alert shows root rather than kali. This is forensically accurate—the file modification was performed with root privileges, even though the original user was kali.

In incident response, this distinction is crucial:

• If a standard user account shows root modifications, investigate sudo usage
• Check /var/log/auth.log for sudo commands
• Verify if the user is authorized to use sudo
• Determine if the sudo usage was legitimate or suspicious

Investigative Follow-Up Questions

If this were a real security incident, I would immediately ask:

1. Was this user supposed to be root? Check authorization policies
2. What process made the change? Correlate with process logs
3. Where did the user authenticate from? Check SSH/login logs
4. What else did this user modify? Query all FIM events for this user
5. Is the root account compromised? Initiate incident response procedures

3. The HOW: Content Modification Analysis

Understanding how the file was changed provides critical context about attacker techniques and intent.

Content Diff Data

{
  "diff": "2a3\n> FIM test via Manager group policy - FINAL CHECK.\n"
}

Understanding Unix Diff Format

The diff field uses standard Unix diff notation:

• 2a3 means: After line 2, add line 3
• > indicates content added (as opposed to < for deleted)
• The exact text added: "FIM test via Manager group policy - FINAL CHECK."

Forensic Interpretation

Modification Type: This was an append operation—content was added to the end of the file, not inserted in the middle or replacing existing content.

Attack Pattern Recognition: The modification pattern provides clues about attacker behavior:

In my test case, appending text to a custom file in /opt/ is benign. But if I saw this pattern in /etc/passwd, /etc/sudoers, or /etc/ssh/sshd_config, it would indicate a serious compromise.

File Size Analysis

{
  "size_before": "91",
  "size_after": "140"
}

The file grew by exactly 49 bytes (140 - 91), which corresponds to the length of the added text plus the newline character. This consistency confirms the diff data is accurate and complete.

Red Flag Scenarios:

• Large size changes in system binaries → potential malware injection
• Unexpected size reductions → data exfiltration or log tampering
• Minimal size changes in critical configs → subtle persistence mechanism

Modification Time Correlation

{
  "mtime_before": "2025-11-18T05:49:44",
  "mtime_after": "2025-11-19T07:31:33"
}

The file was last modified almost 26 hours earlier. In a real investigation, this timeline helps establish:

• How long the system was in a known-good state
• Whether this is part of a series of modifications
• If the change correlates with specific user activity or scheduled tasks

4. The WHY: Compliance, Risk, and Business Impact

The final step in forensic analysis is translating technical findings into business context. This is what executives and compliance teams care about.

MITRE ATT&CK Framework Mapping

{
  "mitre": {
    "technique": ["Stored Data Manipulation"],
    "id": ["T1565.001"],
    "tactic": ["Impact"]
  }
}

Framework Context: Wazuh automatically maps the FIM event to the MITRE ATT&CK framework, providing standardized threat context.

Technique T1565.001 - Stored Data Manipulation:

• Tactic: Impact (final stage of attack lifecycle)
• Description: Adversaries manipulate stored data to achieve their objectives
• Real-World Examples:
  • Modifying database records
  • Altering financial transaction logs
  • Tampering with audit trails
  • Changing system configurations

Investigative Value: This mapping tells me the attacker has reached the Impact stage—they're no longer just exploring or establishing persistence, they're actively manipulating data to achieve their goals. This is late-stage compromise requiring immediate containment.

Compliance and Regulatory Mapping

The alert includes automatic compliance framework mapping:

Why This Matters:

For organizations in regulated industries, these mappings provide:

1. Audit Evidence: Demonstrates compliance with monitoring requirements
2. Incident Reporting: Determines if breach notification is required
3. Risk Assessment: Quantifies potential regulatory penalties
4. Documentation Requirements: Guides what must be logged for auditors

Real-World Scenario: If this were a modification to a file containing protected health information (PHI) or payment card data (PCI), this single alert could trigger:

• Mandatory breach notification to regulators
• Forensic investigation by incident response team
• Potential fines for inadequate security controls
• Customer notification requirements

Alert Severity and SOC Response

{
  "level": 7,
  "description": "Integrity checksum changed."
}

Alert Level 7: In Wazuh's severity scale (0-15), Level 7 represents a high-priority alert that typically triggers:

• Immediate SOC analyst review
• Potential escalation to incident response team
• Automated ticketing in case management system
• Correlation with other security events

Response Priority Matrix:

Complete Forensic Summary: The Investigation Report

Based on the four-part analysis, here's how I would document this incident in a professional SOC environment:

INCIDENT SUMMARY

Alert ID: 1763537493.89810

Rule ID: 550 - Integrity Checksum Changed

Severity: Level 7 (High)

Detection Time: 2025-11-19 07:31:33 UTC

Detection Method: Real-time File Integrity Monitoring

WHAT HAPPENED: File /opt/test_monitoring/secret_file.txt was modified at 07:31:33 UTC. All integrity checksums changed, confirming content alteration. Detection occurred in real-time via inotify.

WHO WAS RESPONSIBLE: Modification performed by root user (UID 0) with root group privileges (GID 0). This represents highest privilege level on system.

HOW WAS IT MODIFIED: Content append operation added 49 bytes. Diff analysis shows text "FIM test via Manager group policy - FINAL CHECK." added after line 2. No existing content removed or replaced.

RISK ASSESSMENT:

• MITRE ATT&CK: T1565.001 (Stored Data Manipulation - Impact tactic)
• Compliance: PCI DSS 11.5, HIPAA 164.312.c.1, NIST SI.7
• Business Impact: File integrity compromise by privileged account

RECOMMENDED ACTIONS:

1. Verify root account authorization and recent activity
2. Review authentication logs for suspicious root access
3. Correlate with other security events in timeframe
4. Determine if change was authorized administrative activity
5. If unauthorized, initiate incident response procedures

INVESTIGATION STATUS: [Closed - Authorized Test] / [Open - Under Investigation]

Conclusion

Mastering FIM forensic analysis completes the operational maturity of my SIEM homelab. I can now:

• Deploy detection capabilities at scale
• Reduce noise without losing coverage
• Investigate alerts with professional methodology
• Document findings for compliance and incident response
• Translate technical events into business impact

This is the progression from building a tool to operating a security monitoring capability.