Detect software discovery by watching for commands and tools that enumerate installed applications, services, packages, or version information across multiple hosts. A single query may be legitimate, but repeated enumeration, broad estate sweeps, or discovery immediately before privilege escalation is suspicious. Correlate with lateral movement and staging activity.
What software discovery activity looks like in telemetry
Software discovery is usually visible as enumeration, not as a single malicious command. Look for process execution that queries installed applications, services, package inventories, registry or filesystem locations that reveal software names and versions, especially when the same pattern repeats across multiple endpoints. Discovery becomes more meaningful when the same host also shows remote execution, credential access, or preparatory staging.
Context matters. A help desk tool or software inventory agent may legitimately enumerate endpoints, but attackers often blend discovery into normal administration by using built-in utilities, remote shells, or management tooling already trusted in the environment. The detection problem is less about one command and more about the combination of scope, repetition, timing, and follow-on behaviour.
How to separate routine inventory from suspicious discovery
Start by establishing the expected baseline for software inventory activity: which teams run it, from where, how often, and against which device groups. Then compare that baseline with estate-wide sweeps, unusual source hosts, and queries that hit many systems in a short window. Repeated discovery from a workstation, jump host, or newly active account is more suspicious than a scheduled scan from a known management platform.
Strong detections usually combine process, command line, network, and authentication context. A single host query may be harmless, but a burst of discovery across multiple hosts, followed by privileged logon attempts or unusual remote tasking, is a stronger indicator that the activity is part of an attack chain. That pattern is easier to interpret when you map it against MITRE ATT&CK Enterprise and compare it with the ATT&CK techniques tied to discovery and later movement.
For broader defender workflow, the activity also fits the control logic in NIST Cybersecurity Framework 2.0, because teams need detection logic that distinguishes normal administrative visibility from suspicious enumeration at scale.
Signals that make software discovery worth escalating
The most useful escalation signals are behavioural. Repeated enumeration across many hosts, discovery immediately before privilege escalation, and discovery followed by staging or lateral movement are the clearest warning signs. Discovery that targets software versions can also matter because it often precedes exploit selection, downgrade attempts, or validation of vulnerable targets.
Look for clusters of related activity rather than isolated events. If the same account or process later launches remote services, copies files to administrative shares, or starts querying adjacent systems, the discovery is likely being used to build an internal map for follow-on action. Discovery can be noisy in large environments, so the analytical value comes from correlation, not from any one log line.
When you want a tactical reference for this pattern, the MITRE ATT&CK Guide for Defenders is useful for translating raw discovery telemetry into ATT&CK-aligned detections and coverage work. For broader lifecycle visibility, the NHI Lifecycle Management Guide helps teams think about discovery as part of inventory, ownership, and governance rather than as a one-off hunt. The broader issue is also summarised in Top 10 NHI Issues, where visibility and discovery gaps are treated as a recurring security problem.
Risk and Threat Considerations
Software discovery becomes risky when it reveals where to pivot next. An attacker who can enumerate installed software at scale can identify vulnerable versions, find management tools, and pick hosts that are more likely to support privilege escalation or remote execution. The risk is not the enumeration itself, but the speed and breadth with which it can turn a foothold into a target map.
Failure mechanism: Defenders treat discovery as routine administration when the activity is actually broad, repeated, and correlated with later execution or movement. That lets an attacker quietly build an internal software inventory and select high-value or weakly defended systems for the next stage.
Impact: The environment becomes easier to profile for exploitation, lateral movement, and staging, which increases the chance of privilege escalation, faster spread, and more effective compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1082 — System Information Discovery | Software enumeration is a discovery technique that reveals installed software and system context. |
| Recommendation — Map enumeration telemetry to discovery techniques and alert when it precedes escalation or lateral movement. | ||
| NIST CSF 2.0 | DE.CM-01 — Anomalies and events are monitored to find cybersecurity events | Repeated enumeration across hosts is an anomaly that monitoring should surface and correlate. |
| Recommendation — Tune monitoring to flag repeated software discovery across multiple endpoints and adjacent attack steps. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Discovery detection depends on collecting process, command, and authentication evidence across hosts. |
| Recommendation — Centralize endpoint and authentication logs so discovery patterns can be correlated quickly. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Teams must review and correlate enumeration events to distinguish routine inventory from suspicious discovery. |
| Recommendation — Review audit records for repeated enumeration and related privilege or movement indicators. | ||
Practitioner Guidance
What to verify: Confirm which discovery sources are approved, then test whether the observed activity matches those sources in host scope, timing, and identity. If discovery is coming from an unexpected account or endpoint, treat that as more important than the exact command name.
Decision rule: If discovery is broad, repeated, and paired with remote execution, privilege escalation, or staging, escalate immediately as suspicious reconnaissance. If it is isolated and aligns with a known inventory or software management job, keep it as low priority but preserve the evidence for later correlation.
Practitioner takeaway: The best detections do not try to label every software query as malicious, they identify discovery that is expanding the attacker’s options across the estate.