« Suspicious Managed Code Hosting Process Suspicious Process Creation CallTrace »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Suspicious Process Access via Direct System Call

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

Suspicious Process Access via Direct System Call

edit

Identifies suspicious process access events from an unknown memory region. Endpoint security solutions usually hook userland Windows APIs in order to decide if the code that is being executed is malicious or not. It’s possible to bypass hooked functions by writing malicious functions that call syscalls directly.

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: Defense Evasion
  • Tactic: Execution
  • Resources: Investigation Guide
  • Data Source: Sysmon

Version: 316

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Suspicious Process Access via Direct System Call

Possible investigation steps

  • What did the Sysmon process-access event prove?
  • Focus: winlog.event_data.SourceImage, winlog.event_data.SourceProcessGUID, winlog.event_data.TargetImage, winlog.event_data.GrantedAccess, and winlog.event_data.CallTrace.
  • Implication: escalate when the call trace starts in UNKNOWN or unbacked memory before the Windows syscall layer and the source opens lsass.exe, a browser, or a security process with memory-read, memory-write, thread, duplicate-handle, or all-access rights; lower concern only when the same source-target-access pattern matches recognized EDR, anti-exploit, debugger, accessibility, anti-cheat, or browser instrumentation.
  • Which source process instance made the access?
  • Focus: recover the source process start on host.id using process.entity_id, or winlog.event_data.SourceProcessGUID plus process.pid and alert-time proximity as a weaker fallback; review process.executable, process.hash.sha256, PE metadata, and code signature. !{investigate{"description":"","label":"Events for the same source process on this host","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: hash, PE metadata, and signature fields are optional; if absent, keep disposition tied to source path, GUID/PID recovery, parent or command context, and target/access evidence rather than closing.
  • Implication: escalate when the source is unsigned, recently dropped, user-writable, renamed, or mismatched to PE metadata; lower concern only when identity, signer or hash, path, and recovery context fit the same recognized security, debugger, accessibility, anti-cheat, or instrumentation workflow.
  • Did launch and user context fit that workflow?
  • Focus: recovered process.command_line, parent executable/command line, alert user.id, and session context.
  • Hint: join process.Ext.authentication_id to winlog.event_data.TargetLogonId only when session origin changes severity; if absent, keep origin unresolved and rely on alert user plus recovered session context.
  • Implication: escalate when Office, browsers, script hosts, archive tools, LOLBins, or remote-interactive sessions launch the accessor; lower concern when parent, command line, account, and session type fit the same recognized low-level tool. If process/session fields cannot be recovered, treat the gap as unresolved, not benign.
  • Did the same source process create dumping, injection, or staging artifacts?
  • Focus: same-source child starts and file events where file.path shows dump output, temp staging, payload drops, or renamed executable content. !{investigate{"description":"","label":"Child process starts from the source process","providers":[[{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"File events for the source process","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: use the transform when process.entity_id is present; otherwise repeat the host.id plus process.pid alert-time fallback from source recovery.
  • Implication: escalate when the source writes dumps, stages payloads, or spawns tooling after access; missing process or file telemetry is unresolved, not benign.
  • Did the same source process communicate after access?
  • Focus: process-scoped DNS dns.question.name and connections to destination.ip.
  • Hint: correlate DNS to destination IP only after matching the same recovered process, host.id, and surrounding time window. !{investigate{"description":"","label":"Network and DNS events for the source process","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when the source reaches rare or misaligned destinations, connects directly to public IPs, or talks outbound after accessing a sensitive process; missing network telemetry is unresolved, not benign.
  • If local evidence remains suspicious or unresolved, is there related activity for the same user, host, or source binary?
  • Focus: related alerts for user.id, host.id, and recovered process.hash.sha256 when available, especially process-access, dump-file, injection, credential-access, or persistence alerts.
  • Hint: start with user-scoped alerts when the alert user is meaningful. !{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: use host-scoped alerts when the source runs as a service identity or user context is sparse. !{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 only when local source, target, access, identity, or follow-on evidence remains suspicious or unresolved; expand containment and credential scoping when related alerts show the same access pattern beyond one process.
  • Escalate unauthorized direct-syscall access to credential-bearing, browser, or security processes when source-target-access-call-trace, recovered identity, launch/session context, or follow-on evidence remain suspicious; close only when those categories bind to one recognized workflow with outside confirmation for any legitimacy gap; preserve and escalate mixed evidence or visibility gaps.

False positive analysis

  • Security agents, anti-exploit tools, debuggers, accessibility tools, anti-cheat systems, browser or PDF instrumentation, backup, and virtualization tools can perform low-level process access. Confirm source executable, signer or hash history, parent workflow, target cohort, access mask, call-trace shape, user/session context, recurrence, and quiet follow-on telemetry all align with one exact product workflow; require owner, inventory, vendor, or change evidence for legitimacy gaps. Recurrence is only corroboration: require the same stable source identity, parent/session context, target cohort, access pattern, and lack of dump or staging artifacts for the same host.id and user.id.
  • Build exceptions from the minimum confirmed pattern: recovered source executable or signer, recovered parent workflow, winlog.event_data.TargetImage, access-mask class, first-frame call-trace shape, and relevant host.id or user.id scope. Avoid exceptions on winlog.event_data.GrantedAccess, winlog.event_data.CallTrace, process name, or target image alone.

Response and remediation

  • If confirmed benign, reverse temporary containment and document the source identity, launch/session context, source-target-access-call-trace tuple, target cohort, and evidence that confirmed the product workflow. Create an exception only for the exact recurring pattern.
  • If suspicious but unconfirmed, preserve the alert record, Sysmon Event ID 10 details, source and target process GUIDs, call trace string, recovered process start, relevant authentication records, dump files, staged payloads, and network indicators before containment or cleanup.
  • Apply reversible containment first: heightened monitoring, temporary outbound restrictions, or response-tool policy on the affected host.id. Escalate to host isolation or process suspension only when the target sensitivity, access rights, identity evidence, or follow-on artifacts indicate likely dumping, injection, or credential theft.
  • If confirmed malicious, isolate the endpoint and suspend or terminate the recovered source process after recording its identity, command line, parent chain, source-target pair, access mask, call trace, staged files, and network indicators. If direct response is unavailable, hand off that evidence set to the team that can isolate the host or account.
  • If the target process held credentials, browser secrets, or security-product context, scope related users, sessions, tokens, and hosts before credential resets or broad process termination so evidence and blast radius are not lost.
  • Eradicate only the dump files, injectors, loaders, persistence artifacts, or staged payloads identified during the investigation, then remediate the launcher, delivery path, or exposed credential path that enabled the direct-syscall process access.
  • Post-incident hardening: retain Sysmon Event ID 10 plus supporting process, file, network, and Windows Security telemetry, and document direct NtOpenProcess, unhooking, or call-stack-spoofing variants observed in the case for future detection review.

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
 length(winlog.event_data.CallTrace) > 0 and

 /* Sysmon CallTrace starting with unknown memory module instead of ntdll which host Windows NT Syscalls */
 not winlog.event_data.CallTrace :
            ("?:\\WINDOWS\\SYSTEM32\\ntdll.dll*",
             "?:\\WINDOWS\\SysWOW64\\ntdll.dll*",
             "?:\\Windows\\System32\\sysfer.dll*",
             "?:\\Windows\\System32\\wow64cpu.dll*",
             "?:\\WINDOWS\\System32\\wow64win.dll*",
             "?:\\Windows\\System32\\win32u.dll*",
             "?:\\ProgramData\\Symantec\\Symantec Endpoint Protection\\*\\sysfer.dll*") and

 not winlog.event_data.TargetImage :
            ("?:\\Program Files (x86)\\Malwarebytes Anti-Exploit\\mbae-svc.exe",
             "?:\\Program Files\\Cisco\\AMP\\*\\sfc.exe",
             "?:\\Program Files (x86)\\Microsoft\\EdgeWebView\\Application\\*\\msedgewebview2.exe",
             "?:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\*\\AcroCEF.exe") and

 not (process.executable : ("?:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe",
                            "?:\\Program Files (x86)\\World of Warcraft\\_classic_\\WowClassic.exe") and
      not winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe")

Framework: MITRE ATT&CKTM

« Suspicious Managed Code Hosting Process Suspicious Process Creation CallTrace »