discovery_remote_system_discovery_commands_windows.toml

[metadata]
creation_date = "2020/12/04"
maturity = "production"
updated_date = "2022/04/21"

[rule]
author = ["Elastic"]
description = "Discovery of remote system information using built-in commands, which may be used to mover laterally."
from = "now-9m"
index = ["logs-endpoint.events.*", "winlogbeat-*", "logs-windows.*"]
language = "eql"
license = "Elastic License v2"
name = "Remote System Discovery Commands"
note = """## Triage and analysis

### Investigating Remote System Discovery Commands

After a successful initial compromise, attackers may try to gain situational awareness of the environment to plan their
next steps. This can happen by running commands to enumerate network resources, users, connections, files, and security
software installed.

This rule looks for the execution of the `arp` or `nbstat` utilities to enumerate remote systems in the environment,
which is useful for attackers to identify lateral movement targets.

#### Possible investigation steps

- Investigate the process execution chain (parent process tree).
- Identify the user account that performed the action and whether it usually performs this kind of action.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Investigate abnormal behaviors done using the account, such as commands executed, startup folder modifications, and
network connections.

### False positive analysis

- Discovery activities themselves are not inherently malicious if occurring in isolation. As long as the analyst did not
identify any suspicious activity related to the user or host, such alerts can be dismissed.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Quarantine the involved host to prevent further post-compromise behavior.
- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).
- Determine the initial infection vector.

## Config

If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, events will not define `event.ingested` and default fallback for EQL rules was not added until 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.
"""
risk_score = 21
rule_id = "0635c542-1b96-4335-9b47-126582d2c19a"
severity = "low"
tags = ["Elastic", "Host", "Windows", "Threat Detection", "Discovery"]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where event.type in ("start", "process_started") and
  (process.name : "nbtstat.exe" and process.args : ("-n", "-s")) or
  (process.name : "arp.exe" and process.args : "-a")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1016"
name = "System Network Configuration Discovery"
reference = "https://attack.mitre.org/techniques/T1016/"

[[rule.threat.technique]]
id = "T1018"
name = "Remote System Discovery"
reference = "https://attack.mitre.org/techniques/T1018/"


[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"