Suspicious LSASS Access via MalSecLogon
Identifies suspicious access to LSASS handle from a call trace pointing to seclogon.dll and with a suspicious access rights value. This may indicate an attempt to leak an LSASS handle via abusing the Secondary Logon service in preparation for credential access.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2022/06/29"
3integration = ["windows"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies suspicious access to LSASS handle from a call trace pointing to seclogon.dll and with a suspicious access
11rights value. This may indicate an attempt to leak an LSASS handle via abusing the Secondary Logon service in
12preparation for credential access.
13"""
14from = "now-9m"
15index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
16language = "eql"
17license = "Elastic License v2"
18name = "Suspicious LSASS Access via MalSecLogon"
19references = ["https://splintercod3.blogspot.com/p/the-hidden-side-of-seclogon-part-3.html"]
20risk_score = 73
21rule_id = "7ba58110-ae13-439b-8192-357b0fcfa9d7"
22severity = "high"
23tags = [
24 "Domain: Endpoint",
25 "OS: Windows",
26 "Use Case: Threat Detection",
27 "Tactic: Credential Access",
28 "Data Source: Sysmon",
29 "Resources: Investigation Guide",
30 "Noise: Low",
31 "Performance: Normal",
32 "Rule Type: Event Correlation (EQL)",
33 "Platform: Windows",
34]
35timestamp_override = "event.ingested"
36type = "eql"
37
38query = '''
39process where host.os.type == "windows" and event.code == "10" and
40 winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and
41
42 /* seclogon service accessing lsass */
43 winlog.event_data.CallTrace : "*seclogon.dll*" and process.name : "svchost.exe" and
44
45 /* PROCESS_CREATE_PROCESS & PROCESS_DUP_HANDLE & PROCESS_QUERY_INFORMATION & PROCESS_QUERY_LIMITED_INFORMATION */
46 winlog.event_data.GrantedAccess == "0x14c0"
47'''
48
49note = """## Triage and analysis
50
51### Investigating Suspicious LSASS Access via MalSecLogon
52
53#### Possible investigation steps
54
55- Does the alert show the MalSecLogon handle-leak pattern rather than generic LSASS access?
56 - Why: the alert-local target, call trace, and access mask distinguish seclogon-mediated LSASS handle leakage from ordinary LSASS access; they do not prove a dump was written.
57 - Focus: `winlog.event_data.TargetImage`, `winlog.event_data.CallTrace`, `winlog.event_data.GrantedAccess`, `winlog.event_data.SourceImage`, `winlog.event_data.SourceProcessGUID`, `@timestamp`, and `host.id`.
58 - Implication: escalate when the tuple is LSASS target + "seclogon.dll" call trace + "0x14c0" access from the seclogon-hosting "svchost.exe"; lower suspicion only when that exact tuple and service context match a recognized security product or authorized test on the same host.
59
60- Which seclogon source process and surrounding initiator candidates can you recover?
61 - Focus: use `winlog.event_data.SourceProcessGUID` and `winlog.event_data.SourceImage` to recover the seclogon-hosting process, then use `host.id` and `process.entity_id` to review surrounding process starts with `process.executable` and `process.command_line`. $investigate_2
62 - Hint: `winlog.event_data.SourceProcessGUID` identifies the service host that touched LSASS, not automatically the original RPC caller; if endpoint process start details are sparse, keep the conclusion at service-host level instead of assigning a caller.
63 - Implication: escalate when the surrounding window shows MalSeclogon-like tooling, shells, script hosts, dump utilities, or newly started binaries that explain why seclogon touched LSASS; unresolved initiator recovery does not clear the alert.
64
65- Does the recovered lineage and session context fit a recognized Secondary Logon workflow?
66 - Focus: process context for the recovered service host or initiator candidates: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `user.id`; if parent or ancestry fields are absent, stay scoped to `host.id` plus `process.entity_id` and the tight alert window.
67 - Implication: escalate when the chain starts from phishing, scripting, remote-admin, dump tooling, or a user context inconsistent with the asset role; treat recognized security-product or authorized-test lineage as lower suspicion, but continue to artifact and authentication checks before closure.
68
69- Do process or file artifacts show dump preparation after the handle access?
70 - Why: the alert proves seclogon-hosted handle access, not dump completion; process and file artifacts show whether the activity advanced toward credential dumping.
71 - Focus: endpoint process and file events scoped by `host.id` plus recovered `process.entity_id`, checking `process.command_line`, `process.executable`, `file.path`, and `file.name`. $investigate_3
72 - Hint: look for LSASS clone or dump-helper command lines, dump-like files, encrypted or renamed dump output, or rapid child creation around the handle event; missing endpoint file telemetry is unresolved, not benign.
73 - Implication: escalate when the timeline shows dump output, clone or dump helpers, suspicious child creation, or staged files tied to the recovered process context; absence of artifacts lowers urgency only when file coverage is present and the process context is otherwise recognized.
74
75- Does the user and host context make this access especially high impact?
76 - Focus: `host.name`, `user.id`, `user.name`, and `user.domain`, plus asset inventory or alert enrichment for domain controller, jump host, credential vault, or tier-0 administration roles when available.
77 - Implication: escalate faster when the host or account can expose privileged credentials; ordinary workstation context lowers scope, not suspicion, unless the alert-local tuple and recovered workflow are also recognized.
78
79- Do follow-on authentication events suggest the leaked handle was used to pivot?
80 - Why: MalSecLogon handle leakage is usually a precursor to dumping or token abuse, so later credential use can be more decisive than the access event alone.
81 - Focus: Windows Security events for the same `host.id` and initial `user.id` pivot, especially `winlog.event_id`, `winlog.logon.type`, `winlog.event_data.TargetLogonId`, `winlog.event_data.SubjectLogonId`, and `source.ip`. $investigate_4
82 - Hint: if `process.Ext.authentication_id` is available, match it to `winlog.event_data.TargetLogonId` for 4624 session creation and search `winlog.event_data.SubjectLogonId` separately for 4648 explicit-credential use; read `winlog.event_data.TargetUserSid` as the authenticated account and `winlog.event_data.SubjectUserSid` as the initiator when they differ. Missing authentication telemetry is unresolved, not benign.
83 - Implication: escalate when later events show NewCredentials logon type 9, explicit-credential use, or unexpected remote logons after the LSASS access; do not close solely because no follow-on authentication telemetry was ingested.
84
85- If the local evidence remains suspicious or unresolved, do related alerts for this user or host show broader credential abuse?
86 - Focus: related alerts for the same `user.id` in the last 48 hours, especially credential-access, lateral-movement, privilege-escalation, archive, or suspicious authentication findings. $investigate_0
87 - Hint: compare related alerts for the same `host.id` only after local evidence is suspicious or unresolved, to decide whether this is confined to one asset or part of a broader credential-theft chain. $investigate_1
88 - Implication: broaden scope when the same user or host also shows dumping, token abuse, remote-admin, or suspicious authentication alerts that support the local findings; keep the case local when related alerts are absent or clearly separate from the LSASS-handle activity.
89
90- Escalate when the alert-local tuple, recovered process context, artifacts, privileged scope, or follow-on credential use support unauthorized handle leakage; close only when the exact tuple and recovered workflow align with recognized security tooling or authorized testing; preserve and escalate when evidence is mixed or missing.
91
92### False positive analysis
93
94- Seclogon-mediated LSASS handle access with "0x14c0" is an operational anti-pattern outside credential-protection products, EDR diagnostics, and authorized IR or red-team testing. Confirm a benign workflow only when the alert-local tuple, seclogon service context, recovered process identity, `user.id`, `host.id`, and absence of dump artifacts or credential-use follow-on all align. When telemetry cannot prove legitimacy, require confirmation for that exact activity from the security product owner, IR lead, or test plan.
95- Before creating an exception, verify prior alerts from this rule show the same `winlog.event_data.SourceImage`, `winlog.event_data.CallTrace`, `winlog.event_data.GrantedAccess`, recovered workflow identity, `user.id`, `host.id`, and benign follow-on pattern. Avoid exceptions on `process.name`, "svchost.exe", seclogon, or the access mask alone.
96
97### Response and remediation
98
99- If confirmed benign, reverse temporary containment and record the exact alert-local tuple, service context, recovered workflow identity, host/user scope, and benign follow-on evidence. Create an exception only for that stable pattern after recurrence or explicit product/test confirmation.
100- If suspicious but unconfirmed, preserve the alert document, source service GUID/image, recovered process starts, command lines, authentication records, volatile handle/service state when feasible, and any `file.path` dump artifacts before containment. Apply reversible containment first, such as suspending the recovered non-system tool, restricting outbound administrative access, or temporarily limiting the affected `user.id` while scope is unresolved.
101- If confirmed malicious, isolate the affected host and contain accounts only after preserving the seclogon context, recovered initiator candidates, dump artifacts, and follow-on authentication evidence. If immediate isolation is unavailable, escalate with that evidence set to the team that can act.
102- For privileged hosts or accounts, activate credential-compromise response and rotate exposed credentials according to host role and account tier. Do not assume enterprise-wide compromise without dump or credential-use evidence, but treat confirmed LSASS dump artifacts on tier-0 assets as urgent.
103- Eradicate only the tools, scripts, dump files, XOR-protected dumps, staged files, persistence, and entry-path artifacts found during the investigation, then remediate the access path that allowed the Secondary Logon abuse.
104- After containment, reduce recurrence risk by reviewing local administrator and debug-privilege exposure, LSASS protection such as RunAsPPL or Credential Guard where supported, and Secondary Logon service necessity on critical servers.
105"""
106
107setup = """## Setup
108
109This rule requires Sysmon telemetry to be enabled and ingested.
110
111Setup instructions: https://ela.st/sysmon-event-10-setup
112"""
113
114[rule.investigation_fields]
115field_names = [
116 "@timestamp",
117 "host.name",
118 "host.id",
119 "user.name",
120 "user.id",
121 "process.entity_id",
122 "process.executable",
123 "process.command_line",
124 "process.parent.executable",
125 "process.parent.command_line",
126 "winlog.event_data.SourceProcessGUID",
127 "winlog.event_data.SourceImage",
128 "winlog.event_data.TargetImage",
129 "winlog.event_data.GrantedAccess",
130 "winlog.event_data.CallTrace",
131]
132
133[[transform.investigate]]
134label = "Alerts associated with the user"
135description = ""
136providers = [
137 [
138 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
139 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
140 ]
141]
142relativeFrom = "now-48h/h"
143relativeTo = "now"
144
145[[transform.investigate]]
146label = "Alerts associated with the host"
147description = ""
148providers = [
149 [
150 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
151 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
152 ]
153]
154relativeFrom = "now-48h/h"
155relativeTo = "now"
156
157[[transform.investigate]]
158label = "Process events for the recovered seclogon source process"
159description = ""
160providers = [
161 [
162 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
163 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
164 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
165 ]
166]
167relativeFrom = "now-1h"
168relativeTo = "now"
169
170[[transform.investigate]]
171label = "Process and file events for the recovered process context"
172description = ""
173providers = [
174 [
175 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
176 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
177 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
178 ],
179 [
180 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
181 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
182 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
183 ]
184]
185relativeFrom = "now-1h"
186relativeTo = "now"
187
188[[transform.investigate]]
189label = "Authentication events for the same user on the host"
190description = ""
191providers = [
192 [
193 { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
194 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
195 { excluded = false, field = "winlog.event_data.TargetUserSid", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
196 ],
197 [
198 { excluded = false, field = "event.code", queryType = "phrase", value = "4648", valueType = "string" },
199 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
200 { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
201 ]
202]
203relativeFrom = "now-24h"
204relativeTo = "now"
205
206[[rule.threat]]
207framework = "MITRE ATT&CK"
208[[rule.threat.technique]]
209id = "T1003"
210name = "OS Credential Dumping"
211reference = "https://attack.mitre.org/techniques/T1003/"
212[[rule.threat.technique.subtechnique]]
213id = "T1003.001"
214name = "LSASS Memory"
215reference = "https://attack.mitre.org/techniques/T1003/001/"
216
217[rule.threat.tactic]
218id = "TA0006"
219name = "Credential Access"
220reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Investigating Suspicious LSASS Access via MalSecLogon
Possible investigation steps
-
Does the alert show the MalSecLogon handle-leak pattern rather than generic LSASS access?
- Why: the alert-local target, call trace, and access mask distinguish seclogon-mediated LSASS handle leakage from ordinary LSASS access; they do not prove a dump was written.
- Focus:
winlog.event_data.TargetImage,winlog.event_data.CallTrace,winlog.event_data.GrantedAccess,winlog.event_data.SourceImage,winlog.event_data.SourceProcessGUID,@timestamp, andhost.id. - Implication: escalate when the tuple is LSASS target + "seclogon.dll" call trace + "0x14c0" access from the seclogon-hosting "svchost.exe"; lower suspicion only when that exact tuple and service context match a recognized security product or authorized test on the same host.
-
Which seclogon source process and surrounding initiator candidates can you recover?
- Focus: use
winlog.event_data.SourceProcessGUIDandwinlog.event_data.SourceImageto recover the seclogon-hosting process, then usehost.idandprocess.entity_idto review surrounding process starts withprocess.executableandprocess.command_line. $investigate_2 - Hint:
winlog.event_data.SourceProcessGUIDidentifies the service host that touched LSASS, not automatically the original RPC caller; if endpoint process start details are sparse, keep the conclusion at service-host level instead of assigning a caller. - Implication: escalate when the surrounding window shows MalSeclogon-like tooling, shells, script hosts, dump utilities, or newly started binaries that explain why seclogon touched LSASS; unresolved initiator recovery does not clear the alert.
- Focus: use
-
Does the recovered lineage and session context fit a recognized Secondary Logon workflow?
- Focus: process context for the recovered service host or initiator candidates:
process.command_line,process.parent.executable,process.parent.command_line,process.Ext.ancestry, anduser.id; if parent or ancestry fields are absent, stay scoped tohost.idplusprocess.entity_idand the tight alert window. - Implication: escalate when the chain starts from phishing, scripting, remote-admin, dump tooling, or a user context inconsistent with the asset role; treat recognized security-product or authorized-test lineage as lower suspicion, but continue to artifact and authentication checks before closure.
- Focus: process context for the recovered service host or initiator candidates:
-
Do process or file artifacts show dump preparation after the handle access?
- Why: the alert proves seclogon-hosted handle access, not dump completion; process and file artifacts show whether the activity advanced toward credential dumping.
- Focus: endpoint process and file events scoped by
host.idplus recoveredprocess.entity_id, checkingprocess.command_line,process.executable,file.path, andfile.name. $investigate_3 - Hint: look for LSASS clone or dump-helper command lines, dump-like files, encrypted or renamed dump output, or rapid child creation around the handle event; missing endpoint file telemetry is unresolved, not benign.
- Implication: escalate when the timeline shows dump output, clone or dump helpers, suspicious child creation, or staged files tied to the recovered process context; absence of artifacts lowers urgency only when file coverage is present and the process context is otherwise recognized.
-
Does the user and host context make this access especially high impact?
- Focus:
host.name,user.id,user.name, anduser.domain, plus asset inventory or alert enrichment for domain controller, jump host, credential vault, or tier-0 administration roles when available. - Implication: escalate faster when the host or account can expose privileged credentials; ordinary workstation context lowers scope, not suspicion, unless the alert-local tuple and recovered workflow are also recognized.
- Focus:
-
Do follow-on authentication events suggest the leaked handle was used to pivot?
- Why: MalSecLogon handle leakage is usually a precursor to dumping or token abuse, so later credential use can be more decisive than the access event alone.
- Focus: Windows Security events for the same
host.idand initialuser.idpivot, especiallywinlog.event_id,winlog.logon.type,winlog.event_data.TargetLogonId,winlog.event_data.SubjectLogonId, andsource.ip. $investigate_4 - Hint: if
process.Ext.authentication_idis available, match it towinlog.event_data.TargetLogonIdfor 4624 session creation and searchwinlog.event_data.SubjectLogonIdseparately for 4648 explicit-credential use; readwinlog.event_data.TargetUserSidas the authenticated account andwinlog.event_data.SubjectUserSidas the initiator when they differ. Missing authentication telemetry is unresolved, not benign. - Implication: escalate when later events show NewCredentials logon type 9, explicit-credential use, or unexpected remote logons after the LSASS access; do not close solely because no follow-on authentication telemetry was ingested.
-
If the local evidence remains suspicious or unresolved, do related alerts for this user or host show broader credential abuse?
- Focus: related alerts for the same
user.idin the last 48 hours, especially credential-access, lateral-movement, privilege-escalation, archive, or suspicious authentication findings. $investigate_0 - Hint: compare related alerts for the same
host.idonly after local evidence is suspicious or unresolved, to decide whether this is confined to one asset or part of a broader credential-theft chain. $investigate_1 - Implication: broaden scope when the same user or host also shows dumping, token abuse, remote-admin, or suspicious authentication alerts that support the local findings; keep the case local when related alerts are absent or clearly separate from the LSASS-handle activity.
- Focus: related alerts for the same
-
Escalate when the alert-local tuple, recovered process context, artifacts, privileged scope, or follow-on credential use support unauthorized handle leakage; close only when the exact tuple and recovered workflow align with recognized security tooling or authorized testing; preserve and escalate when evidence is mixed or missing.
False positive analysis
- Seclogon-mediated LSASS handle access with "0x14c0" is an operational anti-pattern outside credential-protection products, EDR diagnostics, and authorized IR or red-team testing. Confirm a benign workflow only when the alert-local tuple, seclogon service context, recovered process identity,
user.id,host.id, and absence of dump artifacts or credential-use follow-on all align. When telemetry cannot prove legitimacy, require confirmation for that exact activity from the security product owner, IR lead, or test plan. - Before creating an exception, verify prior alerts from this rule show the same
winlog.event_data.SourceImage,winlog.event_data.CallTrace,winlog.event_data.GrantedAccess, recovered workflow identity,user.id,host.id, and benign follow-on pattern. Avoid exceptions onprocess.name, "svchost.exe", seclogon, or the access mask alone.
Response and remediation
- If confirmed benign, reverse temporary containment and record the exact alert-local tuple, service context, recovered workflow identity, host/user scope, and benign follow-on evidence. Create an exception only for that stable pattern after recurrence or explicit product/test confirmation.
- If suspicious but unconfirmed, preserve the alert document, source service GUID/image, recovered process starts, command lines, authentication records, volatile handle/service state when feasible, and any
file.pathdump artifacts before containment. Apply reversible containment first, such as suspending the recovered non-system tool, restricting outbound administrative access, or temporarily limiting the affecteduser.idwhile scope is unresolved. - If confirmed malicious, isolate the affected host and contain accounts only after preserving the seclogon context, recovered initiator candidates, dump artifacts, and follow-on authentication evidence. If immediate isolation is unavailable, escalate with that evidence set to the team that can act.
- For privileged hosts or accounts, activate credential-compromise response and rotate exposed credentials according to host role and account tier. Do not assume enterprise-wide compromise without dump or credential-use evidence, but treat confirmed LSASS dump artifacts on tier-0 assets as urgent.
- Eradicate only the tools, scripts, dump files, XOR-protected dumps, staged files, persistence, and entry-path artifacts found during the investigation, then remediate the access path that allowed the Secondary Logon abuse.
- After containment, reduce recurrence risk by reviewing local administrator and debug-privilege exposure, LSASS protection such as RunAsPPL or Credential Guard where supported, and Secondary Logon service necessity on critical servers.
References
Related rules
- Creation or Modification of Domain Backup DPAPI private key
- Full User-Mode Dumps Enabled System-Wide
- NTDS Dump via Wbadmin
- Potential Credential Access via DuplicateHandle in LSASS
- Potential Credential Access via LSASS Memory Dump