Potential Ransomware Note File Dropped via SMB
Identifies an incoming SMB connection followed by the creation of a file with a name similar to ransomware note files. This may indicate a remote ransomware attack via the SMB protocol.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/05/02"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2026/05/03"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies an incoming SMB connection followed by the creation of a file with a name similar to ransomware note files.
11This may indicate a remote ransomware attack via the SMB protocol.
12"""
13from = "now-9m"
14index = ["logs-endpoint.events.file-*", "logs-endpoint.events.network-*"]
15language = "eql"
16license = "Elastic License v2"
17name = "Potential Ransomware Note File Dropped via SMB"
18risk_score = 73
19rule_id = "02bab13d-fb14-4d7c-b6fe-4a28874d37c5"
20severity = "high"
21tags = [
22 "Domain: Endpoint",
23 "OS: Windows",
24 "Use Case: Threat Detection",
25 "Tactic: Impact",
26 "Resources: Investigation Guide",
27 "Data Source: Elastic Defend",
28]
29timestamp_override = "event.ingested"
30type = "eql"
31
32query = '''
33sequence by host.id with maxspan=1s
34 [network where host.os.type == "windows" and
35 event.action == "connection_accepted" and destination.port == 445 and source.port >= 49152 and process.pid == 4 and
36 source.ip != "127.0.0.1" and source.ip != "::1" and
37 network.type == "ipv4" and not endswith(source.address, destination.address)]
38 [file where host.os.type == "windows" and event.action == "creation" and
39 process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-*") and file.extension : ("hta", "txt", "readme", "htm*") and
40 file.path : "C:\\Users\\*" and
41 /* ransom file name keywords */
42 file.name : ("*read*me*", "*lock*", "*@*", "*RECOVER*", "*decrypt*", "*restore*file*", "*FILES_BACK*", "*how*to*")] with runs=3
43'''
44
45note = """## Triage and analysis
46
47### Investigating Potential Ransomware Note File Dropped via SMB
48
49#### Possible investigation steps
50
51- What do the sequence member events show about the accepted SMB session and note-file burst?
52 - Why: this sequence can omit stage-specific values from the combined alert; disposition depends on recovered source events.
53 - Focus: Timeline member events: network-stage `source.ip`, then file-stage `user.id`, `file.path`, `file.name`, and `file.extension`.
54 - Implication: escalate when one remote source is followed within one second by repeated note-like creations under user-profile paths; lower concern only when recovered source, identity, names, and paths form one bounded, neutral file-copy pattern for validation.
55 - Hint: `process.pid` value "4" is target-side kernel SMB I/O, not the remote executable; use `user.name` only as a readable label for the file-stage identity.
56
57- Do recovered `source.ip` and writing identity match a stable SMB pattern for this host?
58 - Why: the target-side kernel process does not identify the remote operator; source and SMB identity carry attribution value.
59 - Focus: surrounding and historical SMB "connection_accepted" events for `host.id` and recovered `source.ip`, plus file-stage `user.id` and `user.name`. $investigate_0
60 - Implication: escalate when the source is new for this host, appears only in a short burst, or pairs with an unusual SMB identity; lower concern when the same source and identity recur as one bounded backup, migration, or maintenance pattern. Missing SMB history is unresolved, not benign.
61
62- Do created files indicate broad ransom-note staging rather than routine instructions?
63 - Focus: recovered `file.path`, `file.name`, `file.extension`, `file.size`, and `file.Ext.header_bytes`; repeated names across multiple "C:\\Users\\" profile paths.
64 - Implication: escalate when identical or near-identical note files land in multiple profiles, use ".hta" or HTML variants, or are small text/HTML artifacts meant for user visibility; lower concern when files stay in one bounded application or migration folder and match stable instruction-file naming for the same source.
65
66- Does same-window SMB file activity show broader destructive or staging behavior?
67 - Why: note drops often accompany remote rename, delete, or other drop activity that this rule does not capture directly.
68 - Focus: file events in the same SMB window: `event.action`, `file.path`, `file.extension`, `file.Ext.original.path`, and `file.Ext.original.extension`. $investigate_1
69 - Implication: escalate when the same window shows mass rename, delete, extension-change, or extra drop behavior in user or shared paths; lower concern when activity stays limited to the small note set with no follow-on churn.
70
71- If local SMB evidence remains suspicious or unresolved, does impact context stay local or show source fan-out?
72 - Why: ransomware may place notes apart from encryption or recovery inhibition, and SMB ransomware can fan out with valid accounts or admin shares.
73 - Focus: same-host impact alerts over 48 hours, then other SMB events keyed by recovered `source.ip` with matching note-like `file.name`, `file.path`, or impact `event.action`. $investigate_2
74 - Implication: escalate when the host shows rename, shadow-copy, backup-tamper, or destructive alerts, or when one source fans out to multiple hosts with matching note-drop or impact signals; keep the case local only when the source is confined to one bounded file-copy pattern. Missing cross-host SMB telemetry is unresolved, not benign.
75 - Hint: start with `source.ip` plus `destination.port` 445, then join returned hosts to note-like file creations by time.
76
77- What disposition do the recovered SMB source, identity, note pattern, file churn, and scope support?
78 - Escalate for remote note staging plus unexpected SMB identity, destructive file activity, recovery inhibition, or multi-host spread; close only for one stable bounded file-copy pattern with neutral names and no contradictory impact evidence; if purpose still depends on records, preserve artifacts until telemetry resolves it.
79
80### False positive analysis
81
82- Bulk backup, migration, or endpoint-management jobs can place repeated text or HTML instruction files over SMB. Confirm the same recovered `source.ip`, `user.id`, `user.name`, neutral `file.name` family, and bounded `file.path` recurs for this `host.id` without rename, delete, shadow-copy, backup-tamper, or cross-host note-drop spread. Change records can corroborate, not replace, telemetry alignment.
83- Case-driven incident response, legal-hold, or notification activity can write readme-style files remotely. Confirm recovered `source.ip`, `user.id`, `user.name`, `file.path`, and `file.extension` stay bounded to intended case or communication folders, use neutral notice/readme naming rather than decrypt, recover, lock, or payment language, and do not coincide with broader rename or delete activity from `process.pid` value "4". If case records are unavailable, require recurrence of the same source, identity, and path family without spread.
84- Before creating an exception, validate recurrence across prior alerts from this rule. Build the exception from the minimum pattern: recovered `source.ip`, `user.id` or `user.name`, representative `file.name`, bounded `file.path` family, and affected host cohort. Avoid exceptions on `file.name`, `host.id`, or `process.pid` alone.
85
86### Response and remediation
87
88- If confirmed benign, reverse temporary containment and record the confirmed `source.ip`, `user.id` or `user.name`, representative `file.name`, and bounded `file.path` pattern. Create an exception only after that same pattern recurs consistently across prior alerts from this rule.
89- If suspicious but unconfirmed, preserve the alert, Timeline member-event export, copies or hashes of representative note files, recovered source and user identifiers, surrounding file-action evidence, and same-host alert identifiers before containment. Apply reversible containment first, such as temporarily blocking SMB from the recovered source to the target or restricting the recovered user for SMB access. Use host isolation only if note drops continue, spread to additional hosts, or the target role can tolerate interruption.
90- If confirmed malicious, isolate the recovered source host when it is managed and the source, SMB identity, note-file pattern, and impact evidence confirm active ransomware behavior. If direct endpoint response is unavailable on the source, hand off the preserved artifacts to the team that can block the SMB path or contain the source system. Before deleting files, terminating processes, or restoring data, export the member events, related impact alerts, note files, and affected host list.
91- After confirmed malicious scoping identifies affected hosts and accounts, rotate or reset the SMB credentials that were used or exposed, review other hosts touched by the same recovered `source.ip`, then remove dropped notes and restore affected data from known-good backups.
92- Post-incident hardening: restrict unnecessary SMB administrative access, protect backup and shadow-copy workflows, retain endpoint network and file telemetry needed to reconstruct remote file activity, and record the confirmed benign workflow or malicious source-and-path pattern for future cases.
93"""
94
95setup = """## Setup
96
97This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
98
99Setup instructions: https://ela.st/install-elastic-defend
100"""
101
102[rule.investigation_fields]
103field_names = [
104 "@timestamp",
105 "host.id",
106 "host.name",
107 "process.pid",
108]
109
110[transform]
111
112[[transform.investigate]]
113label = "SMB connection events on the host"
114description = ""
115providers = [
116 [
117 { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
118 { excluded = false, field = "event.action", queryType = "phrase", value = "connection_accepted", valueType = "string" },
119 { excluded = false, field = "destination.port", queryType = "phrase", value = "445", valueType = "string" },
120 { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" },
121 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
122 ]
123]
124relativeFrom = "now-1h"
125relativeTo = "now"
126
127[[transform.investigate]]
128label = "File events for SMB server writes on this host"
129description = ""
130providers = [
131 [
132 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
133 { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" },
134 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
135 ]
136]
137relativeFrom = "now-1h"
138relativeTo = "now"
139
140[[transform.investigate]]
141label = "Alerts associated with the host"
142description = ""
143providers = [
144 [
145 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
146 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
147 ]
148]
149relativeFrom = "now-48h/h"
150relativeTo = "now"
151
152[[rule.threat]]
153framework = "MITRE ATT&CK"
154
155[[rule.threat.technique]]
156id = "T1485"
157name = "Data Destruction"
158reference = "https://attack.mitre.org/techniques/T1485/"
159
160[[rule.threat.technique]]
161id = "T1486"
162name = "Data Encrypted for Impact"
163reference = "https://attack.mitre.org/techniques/T1486/"
164
165[[rule.threat.technique]]
166id = "T1490"
167name = "Inhibit System Recovery"
168reference = "https://attack.mitre.org/techniques/T1490/"
169
170[rule.threat.tactic]
171id = "TA0040"
172name = "Impact"
173reference = "https://attack.mitre.org/tactics/TA0040/"
174
175[[rule.threat]]
176framework = "MITRE ATT&CK"
177
178[[rule.threat.technique]]
179id = "T1021"
180name = "Remote Services"
181reference = "https://attack.mitre.org/techniques/T1021/"
182
183[[rule.threat.technique.subtechnique]]
184id = "T1021.002"
185name = "SMB/Windows Admin Shares"
186reference = "https://attack.mitre.org/techniques/T1021/002/"
187
188[rule.threat.tactic]
189id = "TA0008"
190name = "Lateral Movement"
191reference = "https://attack.mitre.org/tactics/TA0008/"
Triage and analysis
Investigating Potential Ransomware Note File Dropped via SMB
Possible investigation steps
-
What do the sequence member events show about the accepted SMB session and note-file burst?
- Why: this sequence can omit stage-specific values from the combined alert; disposition depends on recovered source events.
- Focus: Timeline member events: network-stage
source.ip, then file-stageuser.id,file.path,file.name, andfile.extension. - Implication: escalate when one remote source is followed within one second by repeated note-like creations under user-profile paths; lower concern only when recovered source, identity, names, and paths form one bounded, neutral file-copy pattern for validation.
- Hint:
process.pidvalue "4" is target-side kernel SMB I/O, not the remote executable; useuser.nameonly as a readable label for the file-stage identity.
-
Do recovered
source.ipand writing identity match a stable SMB pattern for this host?- Why: the target-side kernel process does not identify the remote operator; source and SMB identity carry attribution value.
- Focus: surrounding and historical SMB "connection_accepted" events for
host.idand recoveredsource.ip, plus file-stageuser.idanduser.name. $investigate_0 - Implication: escalate when the source is new for this host, appears only in a short burst, or pairs with an unusual SMB identity; lower concern when the same source and identity recur as one bounded backup, migration, or maintenance pattern. Missing SMB history is unresolved, not benign.
-
Do created files indicate broad ransom-note staging rather than routine instructions?
- Focus: recovered
file.path,file.name,file.extension,file.size, andfile.Ext.header_bytes; repeated names across multiple "C:\Users" profile paths. - Implication: escalate when identical or near-identical note files land in multiple profiles, use ".hta" or HTML variants, or are small text/HTML artifacts meant for user visibility; lower concern when files stay in one bounded application or migration folder and match stable instruction-file naming for the same source.
- Focus: recovered
-
Does same-window SMB file activity show broader destructive or staging behavior?
- Why: note drops often accompany remote rename, delete, or other drop activity that this rule does not capture directly.
- Focus: file events in the same SMB window:
event.action,file.path,file.extension,file.Ext.original.path, andfile.Ext.original.extension. $investigate_1 - Implication: escalate when the same window shows mass rename, delete, extension-change, or extra drop behavior in user or shared paths; lower concern when activity stays limited to the small note set with no follow-on churn.
-
If local SMB evidence remains suspicious or unresolved, does impact context stay local or show source fan-out?
- Why: ransomware may place notes apart from encryption or recovery inhibition, and SMB ransomware can fan out with valid accounts or admin shares.
- Focus: same-host impact alerts over 48 hours, then other SMB events keyed by recovered
source.ipwith matching note-likefile.name,file.path, or impactevent.action. $investigate_2 - Implication: escalate when the host shows rename, shadow-copy, backup-tamper, or destructive alerts, or when one source fans out to multiple hosts with matching note-drop or impact signals; keep the case local only when the source is confined to one bounded file-copy pattern. Missing cross-host SMB telemetry is unresolved, not benign.
- Hint: start with
source.ipplusdestination.port445, then join returned hosts to note-like file creations by time.
-
What disposition do the recovered SMB source, identity, note pattern, file churn, and scope support?
- Escalate for remote note staging plus unexpected SMB identity, destructive file activity, recovery inhibition, or multi-host spread; close only for one stable bounded file-copy pattern with neutral names and no contradictory impact evidence; if purpose still depends on records, preserve artifacts until telemetry resolves it.
False positive analysis
- Bulk backup, migration, or endpoint-management jobs can place repeated text or HTML instruction files over SMB. Confirm the same recovered
source.ip,user.id,user.name, neutralfile.namefamily, and boundedfile.pathrecurs for thishost.idwithout rename, delete, shadow-copy, backup-tamper, or cross-host note-drop spread. Change records can corroborate, not replace, telemetry alignment. - Case-driven incident response, legal-hold, or notification activity can write readme-style files remotely. Confirm recovered
source.ip,user.id,user.name,file.path, andfile.extensionstay bounded to intended case or communication folders, use neutral notice/readme naming rather than decrypt, recover, lock, or payment language, and do not coincide with broader rename or delete activity fromprocess.pidvalue "4". If case records are unavailable, require recurrence of the same source, identity, and path family without spread. - Before creating an exception, validate recurrence across prior alerts from this rule. Build the exception from the minimum pattern: recovered
source.ip,user.idoruser.name, representativefile.name, boundedfile.pathfamily, and affected host cohort. Avoid exceptions onfile.name,host.id, orprocess.pidalone.
Response and remediation
- If confirmed benign, reverse temporary containment and record the confirmed
source.ip,user.idoruser.name, representativefile.name, and boundedfile.pathpattern. Create an exception only after that same pattern recurs consistently across prior alerts from this rule. - If suspicious but unconfirmed, preserve the alert, Timeline member-event export, copies or hashes of representative note files, recovered source and user identifiers, surrounding file-action evidence, and same-host alert identifiers before containment. Apply reversible containment first, such as temporarily blocking SMB from the recovered source to the target or restricting the recovered user for SMB access. Use host isolation only if note drops continue, spread to additional hosts, or the target role can tolerate interruption.
- If confirmed malicious, isolate the recovered source host when it is managed and the source, SMB identity, note-file pattern, and impact evidence confirm active ransomware behavior. If direct endpoint response is unavailable on the source, hand off the preserved artifacts to the team that can block the SMB path or contain the source system. Before deleting files, terminating processes, or restoring data, export the member events, related impact alerts, note files, and affected host list.
- After confirmed malicious scoping identifies affected hosts and accounts, rotate or reset the SMB credentials that were used or exposed, review other hosts touched by the same recovered
source.ip, then remove dropped notes and restore affected data from known-good backups. - Post-incident hardening: restrict unnecessary SMB administrative access, protect backup and shadow-copy workflows, retain endpoint network and file telemetry needed to reconstruct remote file activity, and record the confirmed benign workflow or malicious source-and-path pattern for future cases.
Related rules
- Potential System Tampering via File Modification
- Suspicious File Renamed via SMB
- Volume Shadow Copy Deleted or Resized via VssAdmin
- Volume Shadow Copy Deletion via PowerShell
- Volume Shadow Copy Deletion via WMIC