Process Creation via Secondary Logon

ELASTIC detection rule by Elastic · Elastic License v2

Identifies process creation with alternate credentials. Adversaries may create a new process with a different token to escalate privileges and bypass access controls.

[metadata]
creation_date = "2022/08/30"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies process creation with alternate credentials. Adversaries may create a new process with a different token to
escalate privileges and bypass access controls.
"""
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Process Creation via Secondary Logon"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Process Creation via Secondary Logon

The Secondary Logon service in Windows allows users to run processes with different credentials, facilitating legitimate administrative tasks. However, adversaries can exploit this to escalate privileges by creating processes with alternate tokens, bypassing access controls. The detection rule identifies such abuse by monitoring successful logins via the Secondary Logon service and subsequent process creation, linking them through unique logon identifiers.

### Possible investigation steps

- Review the event logs for the specific TargetLogonId to identify the user account associated with the process creation and verify if the account is authorized to use alternate credentials.
- Examine the source IP address "::1" to confirm if the process creation originated from the local machine, which might indicate a local privilege escalation attempt.
- Investigate the process name "svchost.exe" to determine if it is being used legitimately or if it has been exploited for malicious purposes, such as running unauthorized services.
- Check the sequence of events within the 1-minute maxspan to identify any unusual or suspicious activities that occurred immediately before or after the process creation.
- Correlate the detected activity with other security alerts or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign.

### False positive analysis

- Legitimate administrative tasks using the Secondary Logon service can trigger alerts. To manage this, identify and whitelist specific administrative accounts or tasks that frequently use this service for legitimate purposes.
- Scheduled tasks or automated scripts that use alternate credentials for routine operations may cause false positives. Review and exclude these tasks by creating exceptions for known scripts or scheduled jobs.
- Internal IT support activities often involve using alternate credentials for troubleshooting or maintenance. Document and exclude these activities by maintaining a list of support personnel and their typical actions.
- Software updates or installations that require elevated privileges might be flagged. Monitor and exclude these processes by identifying and documenting the update mechanisms used within the organization.
- Development or testing environments where alternate credentials are used for testing purposes can generate alerts. Exclude these environments by setting up specific rules that recognize and ignore these non-production activities.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Terminate any suspicious processes identified as being created via the Secondary Logon service, especially those linked to the unique logon identifiers from the alert.
- Review and revoke any alternate credentials or tokens used in the suspicious process creation to prevent further misuse.
- Conduct a thorough examination of the affected system for additional signs of compromise, such as unauthorized user accounts or changes to system configurations.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach.
- Implement stricter access controls and monitoring on the Secondary Logon service to detect and prevent similar privilege escalation attempts in the future.
- Update and reinforce endpoint detection and response (EDR) solutions to enhance monitoring of process creation events and logon activities, ensuring they are aligned with the latest threat intelligence."""
references = ["https://attack.mitre.org/techniques/T1134/002/"]
risk_score = 47
rule_id = "42eeee3d-947f-46d3-a14d-7036b962c266"
setup = """## Setup

Audit Logon must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-logon
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by winlog.computer_name with maxspan=1m

[authentication where host.os.type == "windows" and event.action:"logged-in" and
 event.outcome == "success" and user.id : ("S-1-5-21-*", "S-1-12-1-*") and

 /* seclogon service */
 process.name == "svchost.exe" and
 winlog.event_data.LogonProcessName : "seclogo*" and source.ip == "::1" ] by winlog.event_data.TargetLogonId

[process where host.os.type == "windows" and event.type == "start"] by winlog.event_data.TargetLogonId
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1134"
name = "Access Token Manipulation"
reference = "https://attack.mitre.org/techniques/T1134/"
[[rule.threat.technique.subtechnique]]
id = "T1134.002"
name = "Create Process with Token"
reference = "https://attack.mitre.org/techniques/T1134/002/"

[[rule.threat.technique.subtechnique]]
id = "T1134.003"
name = "Make and Impersonate Token"
reference = "https://attack.mitre.org/techniques/T1134/003/"



[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

23c7a755-8070-4399-9917-0427cd1888cf

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion