« Potential Remote Desktop Tunneling Detected Remote File Download via Script Interpreter »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.20

Potential REMCOS Trojan Execution

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

Potential REMCOS Trojan Execution

edit

Identifies known file and registry traces of the REMCOS Remote Access Trojan, including log files, persistence values, and cleanup artifacts. Adversaries use Remcos to maintain persistent remote access to compromised hosts.

Rule type: eql

Rule indices:

  • endgame-*
  • logs-endpoint.events.registry-*
  • logs-endpoint.events.file-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • 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: Command and Control
  • Resources: Investigation Guide
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Data Source: SentinelOne
  • Data Source: Microsoft Defender for Endpoint

Version: 2

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential REMCOS Trojan Execution

Possible investigation steps

  • Which Remcos-related artifact family matched, and does it indicate install, persistence, or cleanup evidence?
  • Focus: event.category plus the matched file.path, registry.path, registry.value, registry.data.strings, and whether the trace’s user profile or hive scope matches user.id.
  • Implication: "logs.dat" indicates active or recent keystroke/clipboard logging; a Run-key or licence registry path indicates persistence is set; a temp-file deletion indicates installer cleanup. The artifact’s user profile or hive scope identifies which account is compromised.
  • Which process or user touched the Remcos trace, and does that writer fit detonation, remediation, or malware execution?
  • Focus: the recovered writer identity and launch context, especially process.executable, process.code_signature.subject_name, process.parent.executable, and user.id.
  • Hint: if the source event lacks process identity, recover the writer via process.entity_id or process.pid plus a tight time window on the same host.id.
  • Implication: if the writer is an unknown binary on a non-lab host, treat it as the Remcos payload or its installer. If the writer is a known sandbox, detonation engine, or IR cleanup tool on a designated lab host, the trace is expected.
  • What payload or persistence target do adjacent file and registry events resolve to?
  • Focus: file and registry events on the same host.id: file.path, file.Ext.original.path, registry.path, registry.data.strings, and any payload or autorun target tied to process.entity_id.
  • Implication: a surviving Run-key target, startup copy, or staged binary under %APPDATA% or %TEMP% confirms the infection has active persistence and the payload is still present. Bounded removal of those artifacts without a surviving payload indicates cleanup is underway but verify that ALL persistence mechanisms are gone, not just the ones visible in the alert.
  • Is there active outbound C2 or proxy traffic on this host?
  • Focus: host-scoped network events around the alert time, checking dns.question.name, dns.resolved_ip, destination.ip, destination.port for connections to rare public destinations, direct-IP egress, dynamic-DNS infrastructure, or unusual ports consistent with Remcos controller or SOCKS proxy use.
  • Implication: active C2 traffic confirms the infection is live and requires immediate containment; absence of C2 traffic may indicate the payload was already removed or has not yet activated. Missing network telemetry is unresolved, not benign.
  • If the local evidence stays suspicious, does this host or user show related alerts that explain precursor compromise or follow-on access?
  • Focus: related alerts for the same host.id and user.id in the last 48 hours to identify delivery, persistence, credential, command-and-control, or lateral-movement activity.
  • !{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"}}
  • !{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 when the host or user shows delivery, credential theft, or follow-on remote-access alerts after the artifact; keep the case narrower when related activity is absent or resolves to one detonation or remediation workflow.
  • Escalate when the artifact, writer, persistence status, C2 activity, or alert scope align with active Remcos execution; close only when all evidence fits a recognized detonation or remediation workflow; if mixed or incomplete, preserve and escalate.

False positive analysis

  • Malware-analysis or detonation hosts can legitimately create Remcos traces. Confirm it when the writer identity, host.id, and any network activity all stay inside a known lab or sandbox environment. If lab records are unavailable, require the same writer and host.id to recur across prior alerts.
  • Incident-response cleanup can remove Remcos artifacts. Confirm it when the writer matches a known cleanup tool, surrounding events show bounded removal, and no new C2 or lateral-movement activity follows.

Response and remediation

  • If confirmed benign, reverse any temporary containment and document the confirmed writer, host.id, and artifact family that justified the closure. Create an exception only if that same workflow recurs consistently across prior alerts from this rule.
  • If suspicious but unconfirmed, preserve the matched file.path or registry.path, registry.data.strings, recovered process.entity_id, writer executable and parent context. Apply the least disruptive reversible containment that matches the findings, starting with outbound restrictions on confirmed destinations and using host isolation only when active command-and-control or lateral movement is still plausible for that asset. Avoid destructive cleanup until scope is clearer.
  • If confirmed malicious, use endpoint response to isolate the host after weighing host criticality and record the process.entity_id, command line, parent chain, and trace paths. If direct endpoint response is unavailable, escalate with that evidence set to the team that can contain the host and implicated accounts.
  • Before eradicating or reimaging, review other hosts and users for the same writer identity, artifact family, or C2 destinations so scoping is complete. For confirmed infections, consider reimaging over manual cleanup — Remcos can establish multiple persistence mechanisms and manual eradication risks missing one. If reimaging is not feasible, eradicate all identified Remcos artifacts including Run keys, licence-related registry paths, staged binaries, "logs.dat", and linked temp artifacts, then verify no alternate persistence survives.
  • Post-incident hardening: review how the payload reached the host, restrict user-writable persistence paths where practical, and retain registry and network telemetry for Remcos-related activity.

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
any where host.os.type == "windows" and
(
 (event.category == "file" and event.type == "deletion" and file.path like "?:\\Users\\*\\AppData\\Local\\Temp\\TH????.tmp") or

 (event.category == "file" and file.path : "?:\\Users\\*\\AppData\\Roaming\\remcos\\logs.dat") or

 (event.category == "registry" and
  registry.value : ("Remcos", "Rmc-??????", "licence") and
  registry.path : (
      "*\\Windows\\CurrentVersion\\Run\\Remcos",
      "*\\Windows\\CurrentVersion\\Run\\Rmc-??????",
      "*\\SOFTWARE\\Remcos-*\\licence",
      "*\\Software\\Rmc-??????\\licence"
  )
 )
)

Framework: MITRE ATT&CKTM

« Potential Remote Desktop Tunneling Detected Remote File Download via Script Interpreter »