Mimikatz Memssp Log File Detected
Identifies the default Mimikatz MemSSP credential log file, mimilsa.log. This file is created after the misc::memssp module injects a malicious Security Support Provider into LSASS and can contain credentials from subsequent logons to the host.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/08/31"
3integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
4maturity = "production"
5updated_date = "2026/05/06"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the default Mimikatz MemSSP credential log file, mimilsa.log. This file is created after the misc::memssp
11module injects a malicious Security Support Provider into LSASS and can contain credentials from subsequent logons to
12the host.
13"""
14from = "now-9m"
15index = [
16 "winlogbeat-*",
17 "logs-endpoint.events.file-*",
18 "logs-windows.sysmon_operational-*",
19 "endgame-*",
20 "logs-sentinel_one_cloud_funnel.*",
21 "logs-m365_defender.event-*",
22 "logs-crowdstrike.fdr*",
23]
24language = "eql"
25license = "Elastic License v2"
26name = "Mimikatz Memssp Log File Detected"
27references = ["https://www.elastic.co/security-labs/detect-credential-access"]
28risk_score = 73
29rule_id = "ebb200e8-adf0-43f8-a0bb-4ee5b5d852c6"
30severity = "high"
31tags = [
32 "Domain: Endpoint",
33 "OS: Windows",
34 "Use Case: Threat Detection",
35 "Tactic: Credential Access",
36 "Resources: Investigation Guide",
37 "Data Source: Elastic Endgame",
38 "Data Source: Elastic Defend",
39 "Data Source: Sysmon",
40 "Data Source: SentinelOne",
41 "Data Source: Microsoft Defender XDR",
42 "Data Source: Crowdstrike",
43]
44timestamp_override = "event.ingested"
45type = "eql"
46
47query = '''
48file where host.os.type == "windows" and file.name : "mimilsa.log" and process.name : "lsass.exe"
49'''
50
51note = """## Triage and analysis
52
53### Investigating Mimikatz Memssp Log File Detected
54
55#### Possible investigation steps
56
57- Is the alert-local event the default MemSSP credential log?
58 - Focus: `file.name`, `file.path`, `file.size`, `process.name`, and `process.executable`.
59 - Implication: escalate when "lsass.exe" creates "mimilsa.log", especially at "C:\\Windows\\System32\\mimilsa.log" or a staging path; lower suspicion only when the same host, path, and process evidence align with an authorized red-team, responder, malware-analysis, or isolated lab run.
60
61- Was the log handled like credential material after creation?
62 - Focus: file events on the same `host.id` around `file.path`, including `file.Ext.original.path`, `file.extension`, and the acting `process.executable`.
63 - Implication: escalate when "mimilsa.log" is copied, renamed, archived, deleted, or paired with DLL/archive artifacts such as "mimilib.dll"; absence of follow-on file handling does not clear the alert because the log creation itself can mean credential capture.
64 - Hint: pivot first on the exact `file.path` and rename source path, then on companion "mimilib.dll" file events on the same host. $investigate_2
65
66- Which process activity likely enabled MemSSP before LSASS wrote the log?
67 - Focus: process starts on the same `host.id`: `process.command_line`, `process.executable`, `process.parent.executable`, `process.code_signature.trusted`, and `process.Ext.token.integrity_level_name`.
68 - Implication: escalate when "misc::memssp", Mimikatz/Invoke-Mimikatz, "mimilib.dll", PowerShell, rundll32, regsvr32, unsigned helpers, or high-integrity/system tooling appear before the write; a clean process search narrows the launcher only if collection covers that window.
69 - Hint: search backward from alert `@timestamp` for process starts containing "memssp", "mimikatz", "mimilib", or script/LOLBIN launchers on the same `host.id`.
70
71- Which accounts may have been exposed after the log appeared?
72 - Why: MemSSP records credentials from successful authentications after injection, so exposure depends on who logged on or unlocked the host after the write.
73 - Focus: if Windows Security authentication logs are available, correlate same-`host.id` events after `@timestamp` with `winlog.event_id`, `winlog.event_data.TargetUserName`, `winlog.logon.type`, `source.ip`, and `winlog.event_data.AuthenticationPackageName`. $investigate_3
74 - Implication: escalate when privileged, service, machine, remote, or unexpected NTLM logons appear after creation; if policy permits secure collection, accounts visible in "mimilsa.log" are direct exposure evidence. Missing Windows Security telemetry or uncollected log content is unresolved, not benign.
75
76- Does the host show default in-memory MemSSP only, or a persistent SSP setup?
77 - Why: persistent SSP changes survive a single process-memory event and widen eradication scope beyond the observed log file.
78 - Focus: companion DLL file events (`file.path`, `file.extension`) and, when registry telemetry is available, LSA Security Packages changes in `registry.path` and `registry.data.strings`.
79 - Implication: escalate persistence scope when "mimilib.dll" or an unfamiliar SSP DLL is placed for loading, or when LSA Security Packages registry data names it; if registry telemetry is unavailable, persistence is unresolved and must not be used to close.
80
81- If local evidence is suspicious or unresolved, what related alert activity changes scope?
82 - Focus: related alerts for the same `host.id` in the last 48 hours covering delivery, privilege escalation, LSASS access, persistence, lateral movement, or additional credential access. $investigate_1
83 - Hint: use the `user.id` alert pivot only when a non-SYSTEM account from process or authentication evidence becomes part of scope. $investigate_0
84 - Implication: broaden response when related alerts explain precursor access or follow-on use of captured credentials; keep scope local only when artifact, lineage, exposure, and persistence evidence remain bounded and no contradictory alerts appear.
85
86- Escalate when alert-local artifact, file handling, enabling process, credential exposure, persistence, or related alerts point to hostile MemSSP use; close only when telemetry and outside confirmation align with one authorized lab, red-team, or responder workflow; preserve and escalate when evidence is mixed, missing, or credential exposure cannot be scoped.
87
88### False positive analysis
89
90- Normal Windows operation should not create "mimilsa.log". Authorized red-team, responder, malware-analysis, or isolated lab validation is the narrow benign path. Confirm by verifying alert-local `file.path`/`process.executable`, enabling `process.command_line`/`process.parent.executable`, file handling, asset identity, and any credential-exposure evidence all align with the same case; if any dimension contradicts it, do not close as benign.
91- If exercise or case records are unavailable, do not exception a first occurrence; require a previously confirmed exercise or responder case plus the same stable pattern (`host.id`, `file.path`, `process.executable`, enabling `process.command_line`, and file-handling behavior) across prior alerts. Avoid exceptions on `file.name`, `process.name`, or host alone.
92
93### Response and remediation
94
95- If confirmed benign, reverse containment and document the exact exercise or responder case with `host.id`, `file.path`, `process.executable`, enabling command/parent, and file-handling evidence. Create an exception only for the recurring same pattern.
96- If suspicious but unconfirmed, preserve evidence before containment: export the alert, surrounding process/file events, related alerts, any available authentication events, and securely collect "mimilsa.log" as credential material if policy permits. Capture volatile LSASS state or memory through approved IR tooling before rebooting because restart can remove in-memory evidence.
97- Then apply reversible containment based on scope: restrict network access for the affected `host.id`, heighten monitoring, and scrutinize accounts identified in "mimilsa.log" or post-write logons. Avoid deleting the log, terminating suspected tooling, or rebooting until preservation is complete.
98- If confirmed malicious, isolate or rebuild the host as host criticality allows; remove "mimilsa.log", companion DLLs, archives, and any persistent SSP configuration discovered; terminate tooling only after evidence capture; then reboot or rebuild to clear injected SSP state.
99- Reset or rotate credentials for privileged, service, machine, and lateral-movement-relevant accounts shown in the log content or post-write authentication evidence; review related hosts/accounts before broad resets when exposure is uncertain.
100- Post-incident hardening: reduce interactive logons to high-value hosts, restrict debug and LSASS access, review LSA protection and allowed SSP configuration where compatible, monitor for "mimilsa.log" and "mimilib.dll", and document telemetry gaps that limited credential-exposure or persistence scoping.
101"""
102
103setup = """## Setup
104
105This 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.
106
107Setup instructions: https://ela.st/install-elastic-defend
108
109### Additional data sources
110
111This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
112
113- [CrowdStrike](https://ela.st/crowdstrike-integration)
114- [Microsoft Defender XDR](https://ela.st/m365-defender)
115- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
116- [Sysmon Event ID 11 - File Create](https://ela.st/sysmon-event-11-setup)
117"""
118
119[rule.investigation_fields]
120field_names = [
121 "@timestamp",
122 "host.name",
123 "host.id",
124 "user.id",
125 "process.entity_id",
126 "process.executable",
127 "process.command_line",
128 "process.parent.executable",
129 "process.parent.command_line",
130 "process.code_signature.trusted",
131 "process.Ext.token.integrity_level_name",
132 "file.path",
133 "file.Ext.original.path",
134 "file.name",
135 "file.size",
136]
137
138[[transform.investigate]]
139label = "Alerts associated with the user"
140description = ""
141providers = [
142 [
143 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
144 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
145 ]
146]
147relativeFrom = "now-48h/h"
148relativeTo = "now"
149
150[[transform.investigate]]
151label = "Alerts associated with the host"
152description = ""
153providers = [
154 [
155 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
156 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
157 ]
158]
159relativeFrom = "now-48h/h"
160relativeTo = "now"
161
162[[transform.investigate]]
163label = "MemSSP log and companion file events"
164description = ""
165providers = [
166 [
167 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
168 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
169 { excluded = false, field = "file.path", queryType = "phrase", value = "{{file.path}}", valueType = "string" }
170 ],
171 [
172 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
173 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
174 { excluded = false, field = "file.Ext.original.path", queryType = "phrase", value = "{{file.path}}", valueType = "string" }
175 ],
176 [
177 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
178 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
179 { excluded = false, field = "file.name", queryType = "phrase", value = "mimilib.dll", valueType = "string" }
180 ]
181]
182relativeFrom = "now-1h"
183relativeTo = "now"
184
185[[transform.investigate]]
186label = "Authentication events after MemSSP log creation"
187description = ""
188providers = [
189 [
190 { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
191 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
192 ],
193 [
194 { excluded = false, field = "event.code", queryType = "phrase", value = "4776", valueType = "string" },
195 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
196 ]
197]
198relativeFrom = "now-24h"
199relativeTo = "now"
200
201
202[[rule.threat]]
203framework = "MITRE ATT&CK"
204
205[[rule.threat.technique]]
206id = "T1003"
207name = "OS Credential Dumping"
208reference = "https://attack.mitre.org/techniques/T1003/"
209
210[[rule.threat.technique]]
211id = "T1556"
212name = "Modify Authentication Process"
213reference = "https://attack.mitre.org/techniques/T1556/"
214
215[rule.threat.tactic]
216id = "TA0006"
217name = "Credential Access"
218reference = "https://attack.mitre.org/tactics/TA0006/"
219
220[[rule.threat]]
221framework = "MITRE ATT&CK"
222
223[[rule.threat.technique]]
224id = "T1547"
225name = "Boot or Logon Autostart Execution"
226reference = "https://attack.mitre.org/techniques/T1547/"
227
228[[rule.threat.technique.subtechnique]]
229id = "T1547.005"
230name = "Security Support Provider"
231reference = "https://attack.mitre.org/techniques/T1547/005/"
232
233[rule.threat.tactic]
234id = "TA0003"
235name = "Persistence"
236reference = "https://attack.mitre.org/tactics/TA0003/"
Triage and analysis
Investigating Mimikatz Memssp Log File Detected
Possible investigation steps
-
Is the alert-local event the default MemSSP credential log?
- Focus:
file.name,file.path,file.size,process.name, andprocess.executable. - Implication: escalate when "lsass.exe" creates "mimilsa.log", especially at "C:\Windows\System32\mimilsa.log" or a staging path; lower suspicion only when the same host, path, and process evidence align with an authorized red-team, responder, malware-analysis, or isolated lab run.
- Focus:
-
Was the log handled like credential material after creation?
- Focus: file events on the same
host.idaroundfile.path, includingfile.Ext.original.path,file.extension, and the actingprocess.executable. - Implication: escalate when "mimilsa.log" is copied, renamed, archived, deleted, or paired with DLL/archive artifacts such as "mimilib.dll"; absence of follow-on file handling does not clear the alert because the log creation itself can mean credential capture.
- Hint: pivot first on the exact
file.pathand rename source path, then on companion "mimilib.dll" file events on the same host. $investigate_2
- Focus: file events on the same
-
Which process activity likely enabled MemSSP before LSASS wrote the log?
- Focus: process starts on the same
host.id:process.command_line,process.executable,process.parent.executable,process.code_signature.trusted, andprocess.Ext.token.integrity_level_name. - Implication: escalate when "misc::memssp", Mimikatz/Invoke-Mimikatz, "mimilib.dll", PowerShell, rundll32, regsvr32, unsigned helpers, or high-integrity/system tooling appear before the write; a clean process search narrows the launcher only if collection covers that window.
- Hint: search backward from alert
@timestampfor process starts containing "memssp", "mimikatz", "mimilib", or script/LOLBIN launchers on the samehost.id.
- Focus: process starts on the same
-
Which accounts may have been exposed after the log appeared?
- Why: MemSSP records credentials from successful authentications after injection, so exposure depends on who logged on or unlocked the host after the write.
- Focus: if Windows Security authentication logs are available, correlate same-
host.idevents after@timestampwithwinlog.event_id,winlog.event_data.TargetUserName,winlog.logon.type,source.ip, andwinlog.event_data.AuthenticationPackageName. $investigate_3 - Implication: escalate when privileged, service, machine, remote, or unexpected NTLM logons appear after creation; if policy permits secure collection, accounts visible in "mimilsa.log" are direct exposure evidence. Missing Windows Security telemetry or uncollected log content is unresolved, not benign.
-
Does the host show default in-memory MemSSP only, or a persistent SSP setup?
- Why: persistent SSP changes survive a single process-memory event and widen eradication scope beyond the observed log file.
- Focus: companion DLL file events (
file.path,file.extension) and, when registry telemetry is available, LSA Security Packages changes inregistry.pathandregistry.data.strings. - Implication: escalate persistence scope when "mimilib.dll" or an unfamiliar SSP DLL is placed for loading, or when LSA Security Packages registry data names it; if registry telemetry is unavailable, persistence is unresolved and must not be used to close.
-
If local evidence is suspicious or unresolved, what related alert activity changes scope?
- Focus: related alerts for the same
host.idin the last 48 hours covering delivery, privilege escalation, LSASS access, persistence, lateral movement, or additional credential access. $investigate_1 - Hint: use the
user.idalert pivot only when a non-SYSTEM account from process or authentication evidence becomes part of scope. $investigate_0 - Implication: broaden response when related alerts explain precursor access or follow-on use of captured credentials; keep scope local only when artifact, lineage, exposure, and persistence evidence remain bounded and no contradictory alerts appear.
- Focus: related alerts for the same
-
Escalate when alert-local artifact, file handling, enabling process, credential exposure, persistence, or related alerts point to hostile MemSSP use; close only when telemetry and outside confirmation align with one authorized lab, red-team, or responder workflow; preserve and escalate when evidence is mixed, missing, or credential exposure cannot be scoped.
False positive analysis
- Normal Windows operation should not create "mimilsa.log". Authorized red-team, responder, malware-analysis, or isolated lab validation is the narrow benign path. Confirm by verifying alert-local
file.path/process.executable, enablingprocess.command_line/process.parent.executable, file handling, asset identity, and any credential-exposure evidence all align with the same case; if any dimension contradicts it, do not close as benign. - If exercise or case records are unavailable, do not exception a first occurrence; require a previously confirmed exercise or responder case plus the same stable pattern (
host.id,file.path,process.executable, enablingprocess.command_line, and file-handling behavior) across prior alerts. Avoid exceptions onfile.name,process.name, or host alone.
Response and remediation
- If confirmed benign, reverse containment and document the exact exercise or responder case with
host.id,file.path,process.executable, enabling command/parent, and file-handling evidence. Create an exception only for the recurring same pattern. - If suspicious but unconfirmed, preserve evidence before containment: export the alert, surrounding process/file events, related alerts, any available authentication events, and securely collect "mimilsa.log" as credential material if policy permits. Capture volatile LSASS state or memory through approved IR tooling before rebooting because restart can remove in-memory evidence.
- Then apply reversible containment based on scope: restrict network access for the affected
host.id, heighten monitoring, and scrutinize accounts identified in "mimilsa.log" or post-write logons. Avoid deleting the log, terminating suspected tooling, or rebooting until preservation is complete. - If confirmed malicious, isolate or rebuild the host as host criticality allows; remove "mimilsa.log", companion DLLs, archives, and any persistent SSP configuration discovered; terminate tooling only after evidence capture; then reboot or rebuild to clear injected SSP state.
- Reset or rotate credentials for privileged, service, machine, and lateral-movement-relevant accounts shown in the log content or post-write authentication evidence; review related hosts/accounts before broad resets when exposure is uncertain.
- Post-incident hardening: reduce interactive logons to high-value hosts, restrict debug and LSASS access, review LSA protection and allowed SSP configuration where compatible, monitor for "mimilsa.log" and "mimilib.dll", and document telemetry gaps that limited credential-exposure or persistence scoping.
References
Related rules
- Microsoft IIS Service Account Password Dumped
- NTDS Dump via Wbadmin
- Potential Veeam Credential Access Command
- Searching for Saved Credentials via VaultCmd
- Symbolic Link to Shadow Copy Created