Browser Process Spawned from an Unusual Parent

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

Browser Process Spawned from an Unusual Parent

edit

Identifies instances where a browser is launched with remote debugging, headless automation, or minimal arguments from an unusual parent process. This may indicate an attempt to broker or tamper with a browser session for credential theft.

Rule type: eql

Rule indices:

  • endgame-*
  • logs-endpoint.events.process-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-system.security*
  • logs-windows.forwarded*
  • logs-windows.sysmon_operational-*
  • winlogbeat-*

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: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Windows Security Event Logs
  • Data Source: Microsoft Defender XDR
  • Data Source: Sysmon
  • Data Source: SentinelOne
  • Resources: Investigation Guide

Version: 4

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Browser Process Spawned from an Unusual Parent

Possible investigation steps

  • What browser-brokering path did the alert capture?
  • Focus: process.command_line, process.parent.executable, process.parent.command_line, and process.Ext.ancestry.
  • Implication: escalate with one corroborator when Chrome or Edge starts with high-risk arguments such as "--remote-debugging-port", "--user-data-dir", "--profile-directory", "--headless", offscreen window positioning, or bare browser execution from an unexplained shell, script host, Office app, archive tool, LOLBin, or remote-admin parent; lower suspicion only when a stable signed automation, RPA, support, or test-runner parent uses the same bounded debug or profile behavior for the same user-host cohort.
  • Is the browser and launcher identity consistent with a signed automation toolchain?
  • Focus: process.executable, process.code_signature.subject_name, process.code_signature.trusted, and process.parent.code_signature.subject_name.
  • Implication: escalate when the browser or launcher is unsigned, user-writable, mismatched to its product identity, or signed by an unexpected publisher; identity looks cleaner when Chrome or Edge and the launcher signer match the same recognized toolchain, but identity alone does not clear the browser-brokering behavior.
  • Does the user, host, and session context fit the launch?
  • Focus: user.id, user.name, host.id, process.Ext.session_info.logon_type, and process.Ext.authentication_id. !{investigate{"description":"","label":"Authentication events for the linked session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: if Windows Security logs are available, pivot process.Ext.authentication_id plus host.id to winlog.event_data.TargetLogonId for 4624 session origin, source.ip, and winlog.event_data.AuthenticationPackageName; search winlog.event_data.SubjectLogonId separately for 4648 explicit-credential context. Missing auth telemetry is unresolved, not benign.
  • Implication: escalate when the browser starts from a service, scheduled, remote, or explicit-credential session that does not match the user-host role; lower suspicion when the session, parent, and user-host cohort all fit the same recognized automation pattern.
  • Do network events show DevTools brokering or unexpected egress?
  • Focus: if network telemetry is available, review browser- and parent-scoped connection events on host.id for process.entity_id and process.parent.entity_id: source.ip, destination.ip, and destination.port. !{investigate{"description":"","label":"Network activity for browser and parent processes","providers":[[{"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":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: separately review DNS events for dns.question.name; DNS events do not carry connection-side source.ip or destination.ip. The linked transform includes browser and parent process.entity_id values to catch browser egress and parent-side DevTools client connections. Missing network telemetry is unresolved, not benign.
  • Implication: escalate when a parent or non-browser process connects over loopback to the browser debugging port, or when the browser reaches rare public destinations unrelated to the same automation pattern; lower suspicion when traffic stays inside recognized vendor, proxy, test, or local automation paths for that parent and command line.
  • Do file events show browser-store collection or staged output?
  • Focus: if file telemetry is available, review file events on host.id for process.entity_id and process.parent.entity_id: file.path and file.Ext.original.path, especially copied or renamed browser-store artifacts such as "Login Data", "Cookies", "Local State", or "LocalPrefs.json". !{investigate{"description":"","label":"File activity for browser and parent processes","providers":[[{"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.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: if entity IDs are unavailable, pivot with host.id, process IDs, and a tight alert window; absence of file telemetry does not close the alert.
  • Implication: escalate when the process writes copied browser databases, archives, exported tokens, or renamed outputs in user-writable paths; lower suspicion when file activity stays inside the recognized automation cache or download path and no browser-store artifacts are staged.
  • Is the same browser-brokering pattern present beyond this process?
  • Focus: if local evidence is suspicious or unresolved, review recent alerts for the same user.id and then the same host.id.
  • Hint: user-scoped related alerts: !{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: host-scoped related alerts: !{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: escalate scope when the same parent, command-line pattern, destination, or browser-store artifact repeats across hosts or users; recurrence of one exact automation pattern supports exception review but does not override contradictory telemetry.
  • What disposition does the evidence support?
  • Focus: behavior path, browser and launcher identity, session context, DevTools or egress evidence, browser-store artifacts, and scope.
  • Implication: escalate when an unexpected parent drives a browser debug interface, hidden automation, or profile targeting with suspicious session, network, file, or scope evidence; close only when alert-local process evidence and available session, network, file, and scope evidence all bind to one recognized automation, support, or test workflow; preserve and escalate when evidence is mixed or visibility is incomplete.

False positive analysis

  • Browser automation, QA, RPA, monitoring, enterprise management, remote-support, and security-testing workflows can legitimately launch Chrome or Edge with debug or headless behavior only when the signals converge: a stable signed launcher, bounded debug/profile arguments, the expected user.id and host.id cohort, and no parent-side DevTools client or browser-store staging outside that toolchain. When optional network or file telemetry is available, require it to fit the same workflow. For security testing, also confirm the activity is contained to the intended hosts and users.
  • Before creating an exception, validate that process.parent.executable, process.executable, process.code_signature.subject_name, process.command_line, user.id, and host.id recur across prior alerts from this rule. Avoid exceptions on process.name, browser install paths, or remote-debugging text alone because those match both benign automation and credential-theft launchers.

Response and remediation

  • If confirmed benign, reverse temporary containment and document the evidence that proved the workflow: browser and launcher identity, parent command line, user-host scope, and any corroborating destinations or file artifacts. Create an exception only after the same confirmed pattern recurs across prior alerts from this rule.
  • If suspicious but unconfirmed, export the alert, process tree, browser and parent command lines, relevant process.entity_id values, debugging port or profile arguments, and any collected file or network evidence before containment. Preserve copied browser stores, staged archives, dropped tools, and relevant browser-session state; apply reversible containment first, such as browser-session revocation, heightened monitoring on the affected user.id and host.id, or temporary destination controls.
  • If confirmed malicious, record volatile browser-session state and preserve staged artifacts before terminating the browser or parent. Then isolate the host through endpoint response or equivalent controls when the host role can tolerate interruption. Block confirmed malicious destinations and hashes for the parent launcher, staged tool, or tampered browser binary; reset exposed credentials and revoke sessions when browser-store or cookie-theft evidence is present.
  • After containment, scope related users and hosts for the same process.parent.executable, process.command_line, browser-store artifact, or confirmed destination pattern from network review. Remove only the unauthorized extensions, staged artifacts, or launcher components identified during investigation. Close the entry path by disabling the unauthorized launcher or restoring browser policy if it was changed.

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

Rule query

edit
process where host.os.type == "windows" and event.type == "start" and
  process.name : ("chrome.exe", "msedge.exe") and
  process.parent.executable != null and
  (
    process.command_line : (
            "\"C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe\"",
            "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\"",
            "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless --disable-logging --log-level=3 --v=0",
            "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless --log-level=3",
            "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless",
            "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --remote-debugging-port=922? --profile-directory=\"Default\"*",
            "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless --restore-last-session --remote-debugging-port=45452*"
    ) or
    (process.args : "--remote-debugging-port=922?" and process.args : "--window-position=-*,-*")
  ) and
  not process.parent.executable :
                         ("C:\\Windows\\explorer.exe",
                          "C:\\Program Files (x86)\\*.exe",
                          "C:\\Program Files\\*.exe",
                          "C:\\Windows\\System32\\rdpinit.exe",
                          "C:\\Windows\\System32\\sihost.exe",
                          "C:\\Windows\\System32\\RuntimeBroker.exe",
                          "C:\\Windows\\System32\\SECOCL64.exe")

Framework: MITRE ATT&CKTM