Loading

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.

Rule type: eql
Rule indices:

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

Rule Severity: high
Risk Score: 73
Runs every:
Searches indices from: now-9m
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

This rule requires Sysmon telemetry to be enabled and ingested.

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

  • 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_2
    • 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_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, 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_4
    • 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_0
    • 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
    • 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.

  • 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.
  • 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.
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&CK