---
{
  "title": "Remote System Discovery",
  "summary": "Remote system discovery identifies other hosts reachable or known from an accessed environment.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1018"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1018: Remote System Discovery",
      "url": "https://attack.mitre.org/techniques/T1018"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Remote system discovery identifies other hosts reachable or known from an accessed environment. It differs from determining which services those hosts offer.


## An investigation example

Following an unexpected login, a workstation enumerates nearby hostnames and then attempts connections to selected machines.

## Evidence to examine

Connect host enumeration to network activity, authentication events, and the source process or management tool.

## A common analytical pitfall

An inventory agent can generate similar enumeration, so compare against its approved identity and schedule.

## Response considerations

Scope the affected source host and examine which discovered systems were actually contacted or accessed.


## Learning that a host exists is a separate step

Remote-system discovery identifies other systems known to or reachable from an environment. Information can come from network observations, directories, configuration, or active queries. Discovery does not automatically mean a service was exploited or a remote session succeeded. Keep the distinction between finding a target, attempting access, and obtaining access clear.

Expected administration can produce broad host discovery, especially through inventory and monitoring tools. Review source identity, process origin, target population, timing, and the role of the host initiating it. A workstation unexpectedly mapping many internal systems may deserve a different review from a scheduled inventory server doing its normal job.

## A fictional internal map

After an unusual login, an academy's workstation begins querying information about nearby systems. Later records show an attempted connection to a management server. Analysts correlate endpoint, directory, and network evidence, then compare the sequence with approved support work. The later attempt is important context, but it does not retroactively prove every discovery query was malicious.

Discovery coverage can be incomplete. Network segmentation, permissions, cached information, and naming conventions affect what a process can learn. A failed query may still reveal useful facts to an intruder, while a successful listing does not establish that the listed systems are currently reachable. Explain the actual response and its limits.

## Map the evidence stages

Draw a fictional sequence containing a host listing, a connection attempt, and an authentication result. Write a separate claim supported by each stage. Then identify the evidence required to state that a remote action executed successfully. This prevents a report from collapsing multiple distinct behaviors into an unsupported statement about lateral movement.

An inventory response may contain stale or decommissioned hosts. Verify current state before treating every returned name as an active target. The difference matters when estimating scope: information about a system, network reachability, and successful interaction are three separate forms of evidence with different collection requirements.

## Related concepts

- [[digital-forensics]]
- [[incident-timeline]]
- [[logs-and-telemetry]]
- [[command-and-scripting-interpreter]]