Potential Suspicious File Edit
This rule monitors for the potential edit of a suspicious file. In Linux, when editing a file through an editor, a temporary .swp file is created. By monitoring for the creation of this .swp file, we can detect potential file edits of suspicious files. The execution of this rule is not a clear sign of the file being edited, as just opening the file through an editor will trigger this event. Attackers may alter any of the files added in this rule to establish persistence, escalate privileges or perform reconnaisance on the system.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2023/07/25"
3integration = ["endpoint", "sentinel_one_cloud_funnel"]
4maturity = "production"
5updated_date = "2025/03/20"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule monitors for the potential edit of a suspicious file. In Linux, when editing a file through an editor, a
11temporary .swp file is created. By monitoring for the creation of this .swp file, we can detect potential file edits of
12suspicious files. The execution of this rule is not a clear sign of the file being edited, as just opening the file
13through an editor will trigger this event. Attackers may alter any of the files added in this rule to establish
14persistence, escalate privileges or perform reconnaisance on the system.
15"""
16from = "now-9m"
17index = ["endgame-*", "logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*"]
18language = "eql"
19license = "Elastic License v2"
20max_signals = 1
21name = "Potential Suspicious File Edit"
22note = """## Triage and analysis
23
24> **Disclaimer**:
25> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
26
27### Investigating Potential Suspicious File Edit
28
29In Linux environments, text editors create temporary swap files (.swp) during file editing. Adversaries exploit this by editing critical system files to maintain persistence or escalate privileges. The detection rule identifies the creation of .swp files in sensitive directories, signaling potential unauthorized file edits, thus alerting analysts to investigate further.
30
31### Possible investigation steps
32
33- Review the alert details to identify the specific file path and name of the .swp file that triggered the alert, focusing on the directories and files listed in the query.
34- Check the system logs and recent user activity to determine if there was any legitimate reason for editing the file, such as a scheduled maintenance or update.
35- Investigate the user account associated with the file creation event to verify if the user has the necessary permissions and if their activity aligns with their role.
36- Examine the contents of the original file (if accessible) and compare it with known baselines or backups to identify any unauthorized changes or anomalies.
37- Look for other suspicious activities on the host, such as unusual login attempts, privilege escalation events, or the presence of other temporary files in sensitive directories.
38- Assess the system for signs of persistence mechanisms or privilege escalation attempts, especially if the .swp file is associated with critical system files like /etc/shadow or /etc/passwd.
39
40### False positive analysis
41
42- Editing non-sensitive files in monitored directories can trigger alerts. Users can create exceptions for specific directories or files that are frequently edited by authorized personnel.
43- System administrators performing routine maintenance or updates may inadvertently create .swp files in sensitive directories. Implementing a whitelist for known maintenance activities can reduce false positives.
44- Automated scripts or applications that open files in monitored directories for legitimate purposes can cause alerts. Identifying and excluding these processes from monitoring can help manage false positives.
45- Developers working on configuration files in their home directories might trigger alerts. Excluding specific user directories or known development environments can mitigate these occurrences.
46- Regular system updates or package installations might create temporary .swp files. Monitoring these activities and correlating them with update schedules can help distinguish between legitimate and suspicious activities.
47
48### Response and remediation
49
50- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
51- Terminate any suspicious processes associated with the creation of the .swp files in sensitive directories to halt any ongoing malicious activity.
52- Restore the affected files from a known good backup to ensure system integrity and remove any unauthorized changes.
53- Conduct a thorough review of user accounts and permissions, especially those with elevated privileges, to identify and revoke any unauthorized access.
54- Implement additional monitoring on the affected system and similar environments to detect any further attempts to edit critical files.
55- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
56- Review and update system hardening measures, such as file permissions and access controls, to prevent similar incidents in the future."""
57risk_score = 21
58rule_id = "3728c08d-9b70-456b-b6b8-007c7d246128"
59severity = "low"
60tags = [
61 "Domain: Endpoint",
62 "OS: Linux",
63 "Use Case: Threat Detection",
64 "Tactic: Persistence",
65 "Tactic: Privilege Escalation",
66 "Data Source: Elastic Endgame",
67 "Data Source: Elastic Defend",
68 "Data Source: SentinelOne",
69 "Resources: Investigation Guide",
70]
71timestamp_override = "event.ingested"
72type = "eql"
73
74query = '''
75file where host.os.type == "linux" and event.action in ("creation", "file_create_event") and file.extension == "swp" and
76file.path : (
77 /* common interesting files and locations */
78 "/etc/.shadow.swp", "/etc/.shadow-.swp", "/etc/.shadow~.swp", "/etc/.gshadow.swp", "/etc/.gshadow-.swp",
79 "/etc/.passwd.swp", "/etc/.pwd.db.swp", "/etc/.master.passwd.swp", "/etc/.spwd.db.swp", "/etc/security/.opasswd.swp",
80 "/etc/.environment.swp", "/etc/.profile.swp", "/etc/sudoers.d/.*.swp", "/etc/ld.so.conf.d/.*.swp",
81 "/etc/init.d/.*.swp", "/etc/.rc.local.swp", "/etc/rc*.d/.*.swp", "/dev/shm/.*.swp", "/etc/update-motd.d/.*.swp",
82 "/usr/lib/update-notifier/.*.swp",
83
84 /* service, timer, want, socket and lock files */
85 "/etc/systemd/system/.*.swp", "/usr/local/lib/systemd/system/.*.swp", "/lib/systemd/system/.*.swp",
86 "/usr/lib/systemd/system/.*.swp","/home/*/.config/systemd/user/.*.swp", "/run/.*.swp", "/var/run/.*.swp/",
87
88 /* profile and shell configuration files */
89 "/home/*.profile.swp", "/home/*.bash_profile.swp", "/home/*.bash_login.swp", "/home/*.bashrc.swp", "/home/*.bash_logout.swp",
90 "/home/*.zshrc.swp", "/home/*.zlogin.swp", "/home/*.tcshrc.swp", "/home/*.kshrc.swp", "/home/*.config.fish.swp",
91 "/root/*.profile.swp", "/root/*.bash_profile.swp", "/root/*.bash_login.swp", "/root/*.bashrc.swp", "/root/*.bash_logout.swp",
92 "/root/*.zshrc.swp", "/root/*.zlogin.swp", "/root/*.tcshrc.swp", "/root/*.kshrc.swp", "/root/*.config.fish.swp"
93)
94'''
95
96
97[[rule.threat]]
98framework = "MITRE ATT&CK"
99[[rule.threat.technique]]
100id = "T1037"
101name = "Boot or Logon Initialization Scripts"
102reference = "https://attack.mitre.org/techniques/T1037/"
103[[rule.threat.technique.subtechnique]]
104id = "T1037.004"
105name = "RC Scripts"
106reference = "https://attack.mitre.org/techniques/T1037/004/"
107
108
109[[rule.threat.technique]]
110id = "T1543"
111name = "Create or Modify System Process"
112reference = "https://attack.mitre.org/techniques/T1543/"
113[[rule.threat.technique.subtechnique]]
114id = "T1543.002"
115name = "Systemd Service"
116reference = "https://attack.mitre.org/techniques/T1543/002/"
117
118
119[[rule.threat.technique]]
120id = "T1574"
121name = "Hijack Execution Flow"
122reference = "https://attack.mitre.org/techniques/T1574/"
123[[rule.threat.technique.subtechnique]]
124id = "T1574.006"
125name = "Dynamic Linker Hijacking"
126reference = "https://attack.mitre.org/techniques/T1574/006/"
127
128
129
130[rule.threat.tactic]
131id = "TA0003"
132name = "Persistence"
133reference = "https://attack.mitre.org/tactics/TA0003/"
134[[rule.threat]]
135framework = "MITRE ATT&CK"
136[[rule.threat.technique]]
137id = "T1548"
138name = "Abuse Elevation Control Mechanism"
139reference = "https://attack.mitre.org/techniques/T1548/"
140[[rule.threat.technique.subtechnique]]
141id = "T1548.003"
142name = "Sudo and Sudo Caching"
143reference = "https://attack.mitre.org/techniques/T1548/003/"
144
145
146
147[rule.threat.tactic]
148id = "TA0004"
149name = "Privilege Escalation"
150reference = "https://attack.mitre.org/tactics/TA0004/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating Potential Suspicious File Edit
In Linux environments, text editors create temporary swap files (.swp) during file editing. Adversaries exploit this by editing critical system files to maintain persistence or escalate privileges. The detection rule identifies the creation of .swp files in sensitive directories, signaling potential unauthorized file edits, thus alerting analysts to investigate further.
Possible investigation steps
- Review the alert details to identify the specific file path and name of the .swp file that triggered the alert, focusing on the directories and files listed in the query.
- Check the system logs and recent user activity to determine if there was any legitimate reason for editing the file, such as a scheduled maintenance or update.
- Investigate the user account associated with the file creation event to verify if the user has the necessary permissions and if their activity aligns with their role.
- Examine the contents of the original file (if accessible) and compare it with known baselines or backups to identify any unauthorized changes or anomalies.
- Look for other suspicious activities on the host, such as unusual login attempts, privilege escalation events, or the presence of other temporary files in sensitive directories.
- Assess the system for signs of persistence mechanisms or privilege escalation attempts, especially if the .swp file is associated with critical system files like /etc/shadow or /etc/passwd.
False positive analysis
- Editing non-sensitive files in monitored directories can trigger alerts. Users can create exceptions for specific directories or files that are frequently edited by authorized personnel.
- System administrators performing routine maintenance or updates may inadvertently create .swp files in sensitive directories. Implementing a whitelist for known maintenance activities can reduce false positives.
- Automated scripts or applications that open files in monitored directories for legitimate purposes can cause alerts. Identifying and excluding these processes from monitoring can help manage false positives.
- Developers working on configuration files in their home directories might trigger alerts. Excluding specific user directories or known development environments can mitigate these occurrences.
- Regular system updates or package installations might create temporary .swp files. Monitoring these activities and correlating them with update schedules can help distinguish between legitimate and suspicious activities.
Response and remediation
- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
- Terminate any suspicious processes associated with the creation of the .swp files in sensitive directories to halt any ongoing malicious activity.
- Restore the affected files from a known good backup to ensure system integrity and remove any unauthorized changes.
- Conduct a thorough review of user accounts and permissions, especially those with elevated privileges, to identify and revoke any unauthorized access.
- Implement additional monitoring on the affected system and similar environments to detect any further attempts to edit critical files.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
- Review and update system hardening measures, such as file permissions and access controls, to prevent similar incidents in the future.
Related rules
- D-Bus Service Created
- Kernel Load or Unload via Kexec Detected
- Process Capability Set via setcap Utility
- Unusual D-Bus Daemon Child Process
- Boot File Copy