System Service Discovery
System service discovery identifies installed or running services that reveal a host's purpose, defenses, or possible follow-on targets.
What it means
System service discovery identifies installed or running services that reveal a host's purpose, defenses, or possible follow-on targets. Enumeration is useful to both administrators and attackers.
An investigation example
A newly created process queries service information immediately after an unusual remote login to a workstation.
Evidence to examine
Connect service queries to process ancestry, login provenance, and the actions that follow enumeration.
A common analytical pitfall
An ordinary service listing is not intrinsically malicious; the sequence and responsible identity matter.
Response considerations
Investigate the access chain and subsequent actions, using approved administrative activity as context rather than a blanket exclusion.
Installed services reveal function and dependencies
Service discovery on a host identifies configured or running service components. The result may reveal business applications, security tooling, management agents, and possible follow-on targets. This differs from remotely probing network ports: a service can be installed without currently listening on a reachable interface. Keep host configuration and observed network behavior distinct.
Routine support and inventory processes often query service state. Evaluate the requesting process, account, timing, and expected purpose. A service name or description can be misleading, so examine executable paths, configuration, and ownership where relevant. A familiar display name alone does not establish that the underlying binary is trustworthy.
A fictional pre-change sequence
An academy's endpoint events show an unfamiliar process listing services, then attempting to stop a protective component. Analysts correlate the enumeration with the later control event and compare it with authorized maintenance. The attempted stop is important context, but the listing itself should still be described accurately as discovery.
A later collection may show a different service state because components start, stop, or update over time. Preserve event timing and configuration history where available. If telemetry records only the query process, avoid claiming that every service entry was successfully returned or examined. State the coverage of the evidence.
Compare host and network views
Use a fictional service list and a network connection table. Identify a configured service that is not listening and a listener whose product identity needs more investigation. Explain why the two views answer different questions. Then add a service-stop attempt and write a bounded sequence of observations.
This approach helps responders distinguish discovery, attempted interference, and actual loss of function. A stopped process may restart automatically, while a running service may still be unhealthy. Verify business behavior after any recovery action instead of treating the service-status label as complete proof of restoration.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
MITRE ATT&CK T1007: System Service Discovery