It is no secret that the cybersecurity threat front has become increasingly sophisticated in recent years. Attacks are more complex and harder to detect, leaving organizations struggling to keep pace. In response to this challenge, two powerful tools have emerged: MITRE ATT&CK and Falco.
This blog explores how these tools can be used together to significantly enhance your security posture. We’ll explore how MITRE ATT&CK provides a comprehensive understanding of attacker tactics, techniques, and procedures (TTPs), while Falco leverages this knowledge to detect and respond to threats in real time.
Step 1: Collect all Necessary Details
Crafting effective Falco rules hinges on understanding your adversary. This initial step involves gathering crucial details and adopting the mindset of a cyberattacker. Here’s a breakdown of what this entails:
Consider the Attacker’s Perspective:
- What’s their goal? Are they after stealing data, disrupting operations, or installing malware? Understanding the attacker’s objective helps you pinpoint the specific ATT&CK techniques they might employ.
- What are the common entry points for attackers targeting my environment (e.g., unpatched systems, misconfigured containers)?
- How do they operate? Research common TTPs (Tactics, Techniques, and Procedures) associated with different attacker groups. MITRE ATT&CK https://attack.mitre.org/ serves as a valuable resource for this, offering a catalog of attacker behaviors across various platforms.
- What tools might they use? Familiarize yourself with the types of tools attackers use for specific techniques. This could involve researching exploit kits, malicious scripts, or specific system calls associated with certain attack methods.
Know Where to Look:
Once you understand the attacker’s perspective, you need to identify the system events and data points relevant to their potential actions. This involves:
- Identifying critical assets: Pinpoint the data, systems, and processes most attractive to attackers. This helps you focus your monitoring efforts on the most vulnerable areas.
- Understanding system calls: Falco relies on system calls, which are low-level interactions between programs and the operating system kernel. Researching system calls associated with suspicious activities allows you to craft rules that detect these actions.
- Logs and data sources: Identify your existing security logs and data sources that might contain valuable information about attacker behavior. This could include system logs, network traffic logs, or application logs.
Bring in Falco:
With this information gathered, Falco becomes your weapon of choice. By crafting Falco rules based on the attacker’s potential TTPs and the identified system calls or data points, you can monitor your environment for suspicious activity.
So, this step lays the groundwork for crafting precise Falco rules. By understanding the attacker’s perspective and knowing where to look for evidence of their actions, you can effectively translate that knowledge into actionable detection rules.
Step 2: Write the Falco Rule
Now that you have a strong understanding of the attacker’s perspective and your own environment, it’s time to craft the Falco rule itself. This is an iterative process, so be prepared to refine your rule over time.
Identify the MITRE Technique:
The first step is pinpointing the specific MITRE ATT&CK technique you want to detect. Refer to the ATT&CK matrix to identify relevant techniques based on your threat model and environment.
For example, let’s focus on the technique “Inhibit System Service” (T1490). This technique involves attackers disabling critical recovery services to hinder system restoration in case of a breach.
Understand the Technical Details:
Once you’ve identified the technique, delve deeper into the technical details. This involves understanding the specific actions attackers might take to achieve that technique.
The case of T1490 focuses on attackers disabling critical system services that aid in system recovery in case of a breach. Here’s a detailed breakdown:
- Impact: Disabling recovery services can significantly hinder incident response and system restoration efforts. A compromised system might be left unrecoverable.
- Tactics: Attackers employ various tactics to achieve T1490:
- Deleting service configuration files: Attackers might use tools like rm to remove files essential for service operation. These files could be configuration files, scripts, or binaries required for the service to function properly.
- Disabling services: Tools like systemctl (on Linux) or sc.exe (on Windows) allow attackers to stop or disable services altogether. This prevents the service from running, effectively disabling its recovery functionality.
- Modifying filesystem behavior: Commands like mkfs.ext4 with specific flags (e.g., -E nodiscard) can prevent automatic filesystem repairs during the boot process. This can hinder recovery attempts if the filesystem is corrupted.
- Remounting filesystems as read-only: Attackers might remount critical filesystems as read-only, preventing modifications. This can make it difficult to restore or repair the system if needed.
- Detection Challenges: Detecting T1490 can be challenging because some legitimate administrative tasks might overlap with malicious behavior. Careful rule crafting is required to avoid false positives.
Falco Rule with False Positive Controls
The provided Falco rule is a good starting point, but it’s crucial to minimize false positives (alerts triggered by legitimate activity). Here’s how we can refine the rule:
- Focus on suspicious user context: Include a condition like user.name != “root” to exclude actions performed by the root user, as these are often legitimate system administration tasks.
- Consider specific service names: Instead of broadly matching systemd-backlight*.service, target specific critical recovery services relevant to your environment. This reduces alerts from non-critical service manipulation.
- Refine command arguments: Tighten the conditions around proc.args to capture specific flags or patterns indicative of malicious intent. For example, instead of just chattr +i, look for chattr +i /path/to/recovery_file.
Falco Rule and System Call Filtering
Falco monitors system calls (actions the kernel takes) to detect suspicious activity. However, the ring buffer where Falco stores these calls has a limited capacity. When it overflows, Falco drops events, potentially missing malicious activity.
Here’s how to address this:
- Enable all system calls: By default, Falco doesn’t capture all system calls. Use the -A flag with the falco command to enable comprehensive monitoring. This ensures relevant calls for T1490 detection are captured.
- Prioritize relevant system calls: If enabling all calls isn’t feasible, prioritize calls related to file deletion, service manipulation, and filesystem modifications. Falco documentation provides guidance on enabling specific system calls.
Follow Falco Guidelines:
Falco provides a set of guidelines for writing effective rules. Here’s a breakdown of the key components using the provided example rule for “Inhibit System Service”:
- Enabled Field: This field allows you to enable or disable the rule as needed. Leaving it blank enables the rule by default.
- Output Field: This defines the message Falco sends when it detects suspicious activity. Aim for a clear and descriptive message including relevant details like process names, usernames, or container IDs.
- Priority: You can assign different priority levels to your rules. Critical rules like this example should have the highest priority (CRITICAL).
- Condition: This is the core of the rule, defining the specific events or behaviors Falco will monitor for. The example rule utilizes logical operators (or) to combine various conditions that might indicate attempts to disable recovery features. These conditions primarily focus on spawned processes (executables) and their arguments.
- Tags: Use tags to categorize your rules and improve searchability. Consider tags like “mitre_impact,” the specific technique (e.g., “inhibit_system_recovery”), and the ATT&CK Technique ID (T1490) for easy reference.
Putting it all Together: Building a Falco Rule for T1490
By combining the information above, we can craft a Falco rule to detect attempts to inhibit system recovery services:
rule: Disable recovery features
desc: Detects disabling system recovery features by deleting or disabling services and commands
condition: >
(spawned_process and proc.name = "rm" and proc.args contains "-rf") or # Detects deletion of files with rm -rf
(spawned_process and proc.name = "chattr" and proc.args contains "+i") or # Detects setting immutability attribute
(spawned_process and proc.name = "mkfs.ext4" and proc.args contains "-E nodiscard") or # Detects formatting with nodiscard flag
(spawned_process and proc.name = "mount" and proc.args contains "remount,ro") or # Detects remounting as read-only
(spawned_process and proc.name = "systemctl" and
(proc.args contains "disable systemd-backlight@.service" or # Disabling specific recovery services
proc.args contains "disable apport.service" or
proc.args contains "disable rescue.service" or
proc.args contains "disable emergency.service" or
proc.args contains "disable recovery-mode.service"))
and user.name != "root" # Exclude root user actions
enabled: true
output: "Disabling recovery features so that the system becomes non-recoverable in case of failure."
priority: CRITICAL
tags: [mitre_impact, inhibit_system_recovery, T1490]Remember:
- Start with a basic rule and gradually refine it to minimize false positives.
- Test your rules thoroughly in a non-production environment before deploying them.
- Consider using community-developed Falco rules for common ATT&CK techniques to save time and leverage existing expertise.
