How T1518 software discovery reveals what an intruder knows about your stack
Software discovery is often the quietest stage of an intrusion, and it is the one most likely to be mistaken for routine administration. ATT&CK T1518 Software Discovery sits under the Discovery tactic, TA0007, which MITRE defines as the point where "the adversary is trying to figure out your environment." In practice, an intruder who has already gained a foothold uses software inventory queries to learn which packages, agents, runtimes and management tools are present on a host, and in which versions. This page targets ATT&CK version 20.0, so detection mappings and sub-technique references should be checked against that release before you rely on them. For a SOC lead, the risk is that these queries look like ordinary work. Package managers, configuration management agents and asset inventory tools all enumerate installed software on a schedule, so a single listing rarely means much on its own. What the adversary gains is a map: which versions carry known weaknesses, which security agents are running, and which administrative tools could be reused for the next step. Your first decision is therefore about baselines, not single events. Confirm which inventory tools legitimately run on each platform class, which accounts and hosts are expected to run them, and at what cadence, so that deviations from that pattern stand out.
The practical check is to ask your platform team to document, for each operating system and hypervisor family in scope, the expected software inventory sources and their owners. Then confirm that the telemetry needed to see software enumeration is actually collected. Depending on your estate, that means process creation and command execution records, and application logs from package and asset tools, with retention long enough to compare a suspect host against its own history. Gaps in these sources are the most common reason discovery activity goes unseen. Where you cannot confirm a source is being collected, treat that as an open risk to record, and verify the position in your own environment rather than assuming vendor defaults cover it.
Which telemetry shows software discovery and which open-source tool collects it
This table maps the data components most often referenced for Discovery techniques (Process Creation, Command Execution, File Access and Application Log Content) to ESXi, IaaS, Linux and macOS, with the open-source collector that gathers each signal. Read each row as a starting point: the detection strategies for T1518 and its two sub-techniques must be confirmed against the ATT&CK 20.0 bundle before you build rules on them.
| Platform | Signal to look for | Open-source collector and role |
|---|---|---|
| Linux | Process Creation events that show package query or inventory commands run by unexpected users or parent processes | Auditd or Wazuh agent for execution records, with Velociraptor for hunts across hosts |
| Linux | Command Execution from interactive shells or scripts that enumerate installed software, including repeated queries in a short window | Wazuh agent command monitoring, Auditd execve rules, Sigma rules converted to the target SIEM |
| Linux | File Access to package manager databases and application directories by processes that do not normally read them | Auditd file watch rules and Wazuh file integrity monitoring, reviewed in Security Onion |
| macOS | Process Creation for application and package listing commands, often launched from user sessions or scripts | Wazuh agent or macOS unified logging forwarded to the SIEM, with Velociraptor artifacts for hunts |
| macOS | File Access to application bundles and receipt databases by non-administrative processes | Wazuh file integrity monitoring and Velociraptor file collection on suspected hosts |
| ESXi | Command Execution in the ESXi shell or remote CLI sessions that list installed VIBs or host software | Syslog forwarding to Wazuh or Security Onion, with host logs reviewed for shell and CLI activity |
| IaaS | Application Log Content showing instance-level software inventory calls or agent queries from unexpected identities | Cloud provider audit logs forwarded to Wazuh or Security Onion, with Velociraptor used on instances for host context |
| Network context (all platforms) | Network Traffic Content showing inventory or update checks to unexpected hosts, correlated with the source process | Zeek for protocol logs and Suricata for signatures, correlated with endpoint Process Creation events |
Detection ideas for software discovery that a SOC can tune
T1518 Software Discovery is hard to separate from routine IT operations, so each idea below pairs a behavior with the baseline and exclusions that make it usable. The cards share one principle: a query for software inventory is only suspicious relative to who normally asks, from where, and how often.
Burst of inventory queries per session
Count software inventory queries, such as package list reads or installed application enumeration, made by a single session or process within a short window. A burst from one session is the core signal for T1518 Software Discovery, because administrators and scanners usually run one inventory job, not dozens. Tune the window and the count against a baseline taken from normal hosts, and alert on hosts whose count sits far above their own history. Expect false positives from patch management agents, asset scanners and configuration management runs, so exclude those parent processes by name and by signed binary path.
Inventory activity from unusual accounts
Compare which accounts run software inventory commands against the accounts that normally do. Service accounts used by a backup or monitoring tool should run inventory at predictable times, so any interactive user or unfamiliar service account running it is worth a review. Build the baseline per host group, since a build server and a finance workstation have different norms. Confirm with your identity team which accounts are approved for inventory work, and record the owner of each service account so that alerts can be routed quickly.
Hypervisor management queries on ESXi
On ESXi hosts, watch for management-plane queries that list installed VIBs, installed packages or host software configuration, especially when issued from a session that is not a known management server. Hypervisor hosts change rarely, so the baseline is often small and the signal is clear. Confirm whether your logging captures these queries on each host, because coverage differs by deployment. Exclude the vCenter or lifecycle management tooling you run, and review any inventory query that arrives from a guest virtual machine network.
Cloud application log reads by IaaS identities
Watch for IaaS identities that read application logs, deployed application metadata or software images they do not normally touch. A workload identity that suddenly lists deployed software across projects or regions is a strong discovery indicator. Set thresholds on distinct resources read per identity per hour, and compare against the identity's role. Exclude observability agents, deployment pipelines and vulnerability scanners, and confirm which cloud audit logs your provider retains and for how long before you rely on this card.
How to validate that the software discovery detection fires
This sequence proves that the T1518 Software Discovery detections raise the alerts they are meant to raise, in a private cyber range, before any production reliance is placed on them. It produces a documented record of scope, coverage per sub-technique, alert timing and alert quality that the detection owner can review and rerun after every rule change.
Agree scope and rules of engagement
The detection owner, the SOC lead and the cyber range team agree in writing which hosts, platforms and accounts are in scope, which telemetry sources must be healthy, who may stop the exercise, and how results will be handled. Confirm that the range is isolated from production networks and that no production credentials are used. The step closes when a signed scope note exists and every participant has confirmed the stop conditions.
Confirm telemetry is flowing before testing
Before any emulation, the Wazuh or SIEM administrator confirms that the Process Creation, Command Execution and Application Log Content sources for the in-scope ESXi, IaaS, Linux and macOS hosts are reaching the platform, with correct timestamps and host identifiers. Gaps found here are fixed first, because an empty data source makes a passing test meaningless. The step closes with a dated list of sources and a check that each one returns recent events.
Select sub-techniques and map expected alerts
The detection owner reviews the current ATT&CK technique page for T1518 and its two sub-techniques against the ATT&CK version the detection targets, and records which detection strategies and analytics each rule claims to cover. For each selected sub-technique, the team writes the expected alert, its severity, the host groups it should fire on and the fields it should carry. The step closes with a test matrix that a reviewer can check line by line.
Run the emulation in an isolated range
The range team executes the agreed behavior for each selected sub-technique inside the isolated environment, following the written plan and recording the start and end time of each action in a shared log. The SOC observes without tipping off the detection rules beforehand, so that the results reflect what the rules actually see. The step closes when every planned action has a logged start and end time, and any unplanned activity is documented.
Confirm alerts in Wazuh or the chosen SIEM
The SOC analyst searches the alert queue and raw events in Wazuh or the chosen SIEM for each planned action, and marks each as detected, partially detected or missed. A detected result requires the expected rule to fire, on the expected host, with the expected fields populated. Missed actions are traced back to the missing telemetry, the rule logic or the parsing, so the cause is recorded. The step closes with a result per action and a short note on each miss.
Record time to alert and enrichment quality
For each detected action, the team calculates the interval between the logged action time and the time the alert appears in the platform, and notes whether the alert carries host, user, process and parent process context. The reviewer also checks whether the alert gives an analyst enough information to triage without pivoting to other tools. Confirm with the SIEM vendor or project documentation what ingestion delay is normal for each source, rather than assuming it. The step closes with a timing table and an enrichment rating per alert.
Document gaps and retest after tuning
The detection owner turns each missed or weak result into a tracked change, such as a new source, a corrected rule, a field mapping fix or a tuning decision, and assigns an owner to each. After the change, the same emulation is rerun in the range and the results are compared with the earlier record. The step closes when the validation report shows before and after results and the remaining accepted gaps are signed off by the risk owner.
Preventive controls that reduce software discovery exposure
Software discovery succeeds when an adversary can read installed-software inventories and the accounts that can run queries against them. The five ATT&CK mitigations below narrow what that discovery reveals, who can perform it, and whether the activity leaves a trace. Confirm each mapping against the ATT&CK 20.0 bundle before you cite it in an audit file.
Operating system configuration
Hardening the operating system determines which package managers, inventory utilities and software listing commands are available to ordinary users and service accounts. Remove or restrict tools that are not needed on production hosts, and standardize the configuration so unexpected utilities stand out. Check whether your baseline restricts read access to package databases and software manifests on Linux and macOS, and whether ESXi and IaaS images carry only the tooling operations requires. Confirm the M1028 mapping for T1518 in the ATT&CK 20.0 bundle.
Audit coverage of software queries
Auditing turns software discovery from invisible into reviewable. Enable logging for process execution and command activity on hosts where software listing tools are used, and retain it long enough for investigations to reach back to the first unexpected query. Auditing does not stop discovery, but it provides the evidence that confirms or rules out an intrusion. Verify that audit policy is applied to every host class, including hypervisors and container nodes, rather than only to servers that are already monitored.
User account management
Software discovery usually runs under whatever account the attacker already holds. Limiting standard users, removing shared administrative accounts and enforcing least privilege on package and inventory commands reduces how much software information any single identity can see. Review which groups can query installed packages, run configuration management tools or read application registries, and confirm that service accounts are scoped to their own workloads. Confirm the M1018 mapping for T1518 against the ATT&CK 20.0 bundle.
Disable or remove unneeded programs
Every installed application is a discovery target. Removing software that a host does not need shrinks the inventory an adversary can enumerate and reduces the number of vulnerable components they can match against. Build a per-role software list, uninstall or disable components outside it, and review drift on a schedule. Pay particular attention to developer tools, legacy runtimes and remote administration agents on servers. Confirm the M1042 mapping for T1518 in the ATT&CK 20.0 bundle.
Network segmentation of management paths
Segmentation limits which hosts an adversary can reach after gaining a foothold, so software inventories gathered from one system describe a smaller estate. Place hypervisor management, build servers and administrative consoles on segments that only authorized jump hosts can reach. Test whether a compromised workstation can query software on production hosts directly, and document the flows that must remain open. Confirm the M1030 mapping for T1518 against the ATT&CK 20.0 bundle.
Triage and response when a software discovery alert fires
Start by deciding whether the alert reflects an approved inventory job or an unexplained actor. For T1518 Software Discovery, the signal is an account or process querying installed packages, services or application inventories on an ESXi host, IaaS instance, Linux or macOS endpoint. Confirm the account first: is it a named administrator, a configuration management service account, or an identity that has no business reading package state? Then confirm the host or hypervisor, its role and owner, and whether a change ticket, scheduled patch or inventory scan covers the time window. Check the scan schedule and tooling owners directly rather than relying on the rule name, because software inventory is routine on many estates and the same commands are used by defenders.
Correlate the discovery event with what happened before and after it. Pull authentication records for the account and host (SSH or console logins on Linux and macOS, vSphere or ESXi login events, cloud identity sign-ins), and look for new sessions, unusual source addresses or failed attempts preceding the query. Then check network events for outbound connections from the same host, new listening services and any transfer of inventory output off the host. Escalate when the discovery activity follows an unexpected login, appears on a host with no inventory role, or is followed by credential access, persistence or configuration changes. Record the decision and its reasoning in the case notes so the escalation path can be audited later. When containment is needed, prefer steps that keep memory, process lists, shell history and log files intact. Restrict the account or network path, snapshot the virtual machine before any reboot, and isolate the host at the network layer instead of powering it off. On ESXi, confirm with the platform team how snapshots and logs are retained before acting. Once a single host is confirmed, pivot into Velociraptor hunts across the fleet to find the same account, command pattern or package-enumeration artifacts elsewhere. Scope those hunts to the approved host groups first, and expand only as evidence supports it. Confirm with your own runbook which steps need change approval during an active incident.
Rehearsing software discovery detection in a private cyber range
A Linux and macOS segment usually starts with a small range of workstations and servers that are instrumented with the same agent and log pipeline used in production. The blue team should own the topology diagram, the list of collected telemetry and the baseline of package and application inventory commands that administrators normally run. The red team, operating under written rules of engagement, then performs software inventory activity on a few hosts so that the team can measure what process creation and command execution records actually show.
- Range topology: Build a small segment with a Wazuh manager, at least one Linux endpoint and one macOS endpoint, and a log path to Security Onion or another open-source analytics stack.
- Injects: Schedule inventory activity on a subset of hosts at unannounced points, and vary the user context so the team sees both administrative and standard accounts.
- Detection quality: Good detection produces a correlated alert with the host, user, parent process and command context in one place, with few false positives from routine patch tooling.
- Triage and scoping: The analyst should confirm whether the activity matches a change window, then identify every other host where the same pattern appeared.
- Response: Good response contains the affected session, preserves relevant logs and records the decision for the after-action review.
Confirm with your own engineering team which inventory tools are approved on each platform, since that list determines what the range should simulate.
An ESXi and IaaS segment tests whether software discovery is visible on hypervisors and in cloud control planes, where the tooling and log sources differ from endpoints. The range should include a virtualization host, a management interface and a cloud account or sandbox project, each with audit logging enabled. Exercises focus on whether the team can see inventory requests against hypervisor and cloud resources and connect them to a specific identity.
- Range topology: Use a lab ESXi host with its management logs forwarded to the SIEM, plus a cloud sandbox account with control plane audit logs routed to the same platform.
- Injects: Have the red team query package and image inventory through an authorized administrative session, then repeat the activity through an API key that has narrower permissions.
- Detection quality: Good detection links the identity, source address and action in the audit trail, and it fires on the API path as well as the interactive shell path.
- Triage and scoping: The analyst should determine whether the identity is a service account, a contractor or an interactive administrator, and check whether the same key appears elsewhere.
- Response: Good response includes rotating or suspending the credential, reviewing recent changes, and confirming that audit logs were complete and not overwritten.
Confirm with each platform owner which audit events are emitted by default and which require configuration, because gaps here often matter more than the detection rule itself.
The SOC response segment evaluates the people and process across both environments. Rather than scoring the rule alone, the exercise observes how the analyst moves from alert to decision, and how well the handoff to incident response works. Scenarios should be run in both environments so the team compares findings, and the scoring sheet should be agreed before the exercise starts.
- Alert fidelity: Record whether alerts were raised, how many were false positives and whether the rule fired on the intended ATT&CK technique for T1518 and its sub-techniques.
- Time to triage: Measure the interval from alert to documented first assessment, and compare results against the target set during scoping rather than a fixed benchmark.
- Correct scoping: Check whether the analyst identified all affected hosts, accounts and cloud resources, and whether the scope was widened when new evidence appeared.
- Response actions: Assess containment, evidence preservation and communication to system owners, following the runbook the team uses.
- Debrief: Capture gaps in telemetry, rule logic and runbooks as tracked actions with owners and due dates.
Exercise timings and pass criteria are set during scoping with the client, and they should not be taken from generic guidance. Ask the team to confirm which thresholds apply to their environment before the exercise begins.
Questions detection engineers ask about T1518 software discovery
How do I baseline normal software inventory queries before alerting on T1518?
Start by recording which processes, accounts and hosts already run software inventory commands, such as package manager queries, asset agents and configuration management jobs. Most environments have a short list of recurring sources, and each one should be documented with its host group, schedule and owning team. Collect this over a representative period before enabling alerts, so the baseline reflects patch cycles, audits and month-end activity rather than a single quiet week. Confirm the baseline against your own change records, because the tooling and cadence differ widely between organizations. Keep the baseline in version-controlled documentation so reviewers can see when an exception was added and why.
How do I separate vulnerability scanners and asset tools from an adversary?
Scanners and asset tools are legitimate software discovery, so the distinguishing signals are identity, source, timing and breadth rather than the command alone. Match the originating account, service identity, parent process and source host against an approved list of scanner hosts and service accounts. Treat a known scanner that runs from an unexpected host, under an interactive user, or outside its maintenance window as a finding worth investigating. Compare the volume and sequence of enumeration with the scanner's documented behavior, and watch for enumeration followed by access to sensitive directories or credential stores. Validate these rules in your cyber range with both an approved scanner and a simulated manual inventory, so you can see where the two overlap.
Should I write separate detections for each T1518 sub-technique?
Yes, write separate detections, because the two sub-techniques expose different telemetry. Sub-technique detections typically depend on different artifacts, such as package manager activity on one hand and application or security product inventory on the other. Keeping them separate lets you tune thresholds and suppressions independently, and it makes coverage gaps visible in your ATT&CK mapping. Confirm the current sub-technique names and their scope in the ATT&CK 20.0 technique page before you build the mapping, because releases can rename or revise them. Document which data sources each sub-technique depends on, so a logging gap affects only the detections that need it.
How do I map T1518 detections to ATT&CK 20.0 detection strategies?
Map each detection to the detection strategy identifier and analytic on the ATT&CK 20.0 technique page, not to the older free-text detection fields. Since ATT&CK v18 replaced detections with detection strategies (DET IDs) and analytics, a mapping built on the older model will drift. For each analytic, record the data components it references, such as Process Creation or Command Execution, and the log source that supplies them. Store the ATT&CK version in the rule metadata so that a future release can be reviewed against it. Ask your team to recheck the mapping after each release, since v19 and later releases may change referenced identifiers.
Are Sigma rules for software discovery portable across SIEMs?
Sigma rules are portable in logic, but they still need field mapping and log source validation in each platform. A Sigma rule describes the process, command line and parent relationships in a vendor-neutral way, and converters translate it into the query language of your SIEM or search backend. The conversion depends on how your agents normalize process and command fields, so a rule that works in one stack can miss events in another. Test the converted rule against recorded telemetry in your range, confirm that the expected fields are populated, and review any filter that depends on platform-specific naming. Keep the Sigma source as the reference and treat converted queries as build artifacts.
When should I tune a T1518 alert and when should I suppress it?
Tune when the alert is correct but noisy, and suppress only when the activity is verified as approved and the suppression can be bounded. Tuning means narrowing the rule with specific hosts, service accounts, parent processes or time windows, so that a change in any of those attributes still produces an alert. Suppression removes the alert for a defined case and should carry an owner, a review date and a documented reason. Avoid broad suppressions such as all activity from a subnet, because they hide the lateral movement that discovery often precedes. Review suppressions after each ATT&CK release and after significant changes to your inventory tooling.
How DeployOpen builds software discovery detections and range exercises
DeployOpen works on T1518 Software discovery as a fixed-scope engagement inside your own environment, covering the platforms and telemetry your team actually runs. The work turns detection logic into tested, documented rules and rehearses them in a private cyber range before anything reaches production.
How we scope
- Confirm which platforms in your estate fall under T1518, such as ESXi, IaaS, Linux and macOS, and which are out of scope.
- Inventory the telemetry you already collect for Process Creation, Command Execution and Application Log Content, and note any gaps.
- Record the ATT&CK version the detection mapping will target, so later releases do not silently change the logic.
How we build
- Write detection logic in open formats such as Sigma rules, then translate it for your SIEM, for example Wazuh or Security Onion.
- Tune rules against your normal administrative tooling so that inventory scripts and monitoring agents do not generate noise.
- Document expected false positives, required log sources and the configuration steps each platform owner must complete.
How we hand over
- Deliver rules, configuration files and a validation runbook that your analysts can execute and repeat without us.
- Provide range exercise results showing which simulated software discovery activity was detected, missed or partially logged.
- Agree in writing what is handed over, in what format, and which open issues remain with your team.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, rule updates after ATT&CK releases and repeat range exercises are available as a retainer.
- Quotes follow from the written scope, so ask for the platforms, log sources and rehearsal count to be listed explicitly.
