« Access to a Sensitive LDAP Attribute Suspicious Module Loaded by LSASS »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Suspicious LSASS Access via MalSecLogon

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Suspicious LSASS Access via MalSecLogon

edit

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.

Rule type: eql

Rule indices:

  • winlogbeat-*
  • logs-windows.sysmon_operational-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Data Source: Sysmon
  • Resources: Investigation Guide

Version: 312

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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, and host.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.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{"description":"","label":"Process events for the recovered seclogon source process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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.
  • 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.
  • 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, and user.id; if parent or ancestry fields are absent, stay scoped to host.id plus process.entity_id and 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.
  • 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.id plus recovered process.entity_id, checking process.command_line, process.executable, file.path, and file.name. !{investigate{"description":"","label":"Process and file events for the recovered process context","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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, and user.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.
  • 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.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{"description":"","label":"Authentication events for the same user on the host","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserSid","queryType":"phrase","value":"{{user.id}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}}
  • 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.
  • 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.id in the last 48 hours, especially credential-access, lateral-movement, privilege-escalation, archive, or suspicious authentication findings. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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.
  • 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 on process.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.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.
  • 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.

Setup

edit

Setup

This rule requires Sysmon telemetry to be enabled and ingested.

Setup instructions: https://ela.st/sysmon-event-10-setup

Rule query

edit
process where host.os.type == "windows" and event.code == "10" and
  winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and

   /* seclogon service accessing lsass */
  winlog.event_data.CallTrace : "*seclogon.dll*" and process.name : "svchost.exe" and

   /* PROCESS_CREATE_PROCESS & PROCESS_DUP_HANDLE & PROCESS_QUERY_INFORMATION & PROCESS_QUERY_LIMITED_INFORMATION */
  winlog.event_data.GrantedAccess == "0x14c0"

Framework: MITRE ATT&CKTM

« Access to a Sensitive LDAP Attribute Suspicious Module Loaded by LSASS »