T1518 Software Discovery: Catching Security Tool Checks Before Defence Tampering

Before an intruder disables your EDR or deletes your backups, it usually checks which EDR and which backup product you run, and that check is one of the most reliable early warnings a SOC can get. MITRE ATT&CK tracks this as T1518 Software Discovery, a Discovery (TA0007) technique on ESXi, IaaS, Linux, macOS and Windows, with two sub-techniques: T1518.001 Security Software Discovery and T1518.002 Backup Software Discovery. This guide is for detection engineers, SOC analysts and endpoint and cloud teams. It explains how adversaries use software inventory to decide what to do next, which ATT&CK v20 analytics and telemetry catch it, how to separate it from the large volume of legitimate inventory activity, and which controls make the answer less useful to an attacker. For the tampering that typically follows, see the EDR Evasion and Defence Guide and T1685 Disable or Modify Tools Defensive Guide.

Key takeaways

• Security software discovery is a predictor, not an end. ATT&CK states the results shape follow-on behaviour, including whether the adversary fully infects the target; in ransomware cases the next step is often tool tampering or backup destruction.
• Single queries are noise, sequences are signal. Inventory tools, installers and admin scripts query installed software constantly; alert on a security product query followed within minutes by service stops, exclusions or shadow copy deletion.
• Cloud has its own version. T1518.001 covers cloud monitoring agents such as the AWS CloudWatch agent, Azure VM Agent and Google Cloud monitoring agent, discovered through cloud APIs, so control plane logs matter as much as EDR.
• The answer matters more than the question. Storm-0501 checked for Defender for Endpoint services on the few devices that had it and chose systems that were not onboarded, so coverage gaps are themselves the finding.
• Tamper protection removes the payoff. If discovery cannot be followed by a successful stop, uninstall or exclusion change, the adversary learns little that helps them.

What T1518 covers in ATT&CK v20

ATT&CK v20 (technique version 1.5) describes adversaries listing installed software and versions on a system or in a cloud environment, and using the result during automated discovery to shape what they do next. The parent technique names three reasons: finding security measures, finding a vulnerable version for T1068 Exploitation for Privilege Escalation, and finding widely deployed management software such as MITRE ATT&CK T1072 Software Deployment Tools that could give broad access across the estate.

The ATT&CK description for T1518.001 lists the methods defenders will see: netsh, reg query, dir and tasklist on Windows, checks for tools such as LittleSnitch and KnockKnock on macOS, and calls through T1059.009 Cloud API to find cloud-native agents. In procedure examples the most common Windows method is a WMI query against the root\SecurityCenter2 namespace (Sidewinder, Kimsuky) or a service query for specific products (Storm-0501).

How adversaries use it: real cases

All cases below come from ATT&CK v20 procedure examples and the sources they cite, plus the Microsoft and CISA reports linked.

• Storm-0501 (G1053): Microsoft reported in August 2025 that the group ran sc query sense and sc query windefend on a few onboarded devices before acting, checking for Defender for Endpoint services. Microsoft read this as a deliberate attempt to work from systems that were not onboarded; only one of the compromised domains had significant Defender for Endpoint deployment, and an Entra Connect Sync server that was not onboarded became a pivot point. The earlier phase of the same group is analysed in the Storm-0501 Hybrid Cloud Attacks 2024 breach page, where stolen sync account credentials carried the intrusion into Entra ID. See also the Storm-0501 Threat Actor Profile Guide.
• Play (G1040): CISA advisory AA23-352A states that Play actors scan for anti-virus software and maps this to T1518.001; ATT&CK records the use of the Grixba information-stealing tool for this. The same advisory reports tools such as GMER, IOBit and PowerTool used to disable security tools, and PowerShell scripts aimed at Microsoft Defender. See the Play Ransomware Profile.
• Wizard Spider (G0102): ATT&CK records WMI queries for installed anti-virus products and a PowerShell script, Get-DataInfo.ps1, collecting installed backup software information, which is the T1518.002 pattern that precedes recovery inhibition.
• Medusa Group (G1051) and BlackByte (G1043): ATT&CK records hard-coded lists of security product executables used to find tools for termination, and enumeration of installed security products during operations. See the Medusa Ransomware Threat Actor Profile and BlackByte Ransomware Profile Guide.
• Volt Typhoon (G1017): ATT&CK cites the 2023 joint advisory and CISA AA24-038A for registry queries for installed software on compromised systems, part of a living-off-the-land approach where built-in tools replace malware. See the Living off the Land Guide.

The pattern across ransomware cases is consistent: discover security and backup products, then remove or bypass them, then encrypt. The discovery step is the cheapest point at which to intervene.

What to detect and where

ATT&CK v20 attaches three detection strategies to this technique. The table summarises the analytics and the log sources they name.

Turning analytics into alerts that survive tuning

The following approach is an NHI Mgmt Group recommendation built on the v20 analytics above.

1. Build a watchlist of your own product names. List the service names, process names, driver names and install paths of the EDR, antivirus, firewall, logging agents and backup products you actually run. A query that names your EDR service is far more specific than a generic software listing.
2. Score the parent and the account. A SecurityCenter2 WMI query from your software inventory agent running as SYSTEM on a schedule is expected. The same query from cmd.exe under a remote management tool, an Office process or a newly created account is not.
3. Correlate within a short window. Raise severity when a watchlist query is followed on the same host, within about 30 minutes, by a stop or delete of a security service, a Defender exclusion change, a tamper protection block (Microsoft notes Defender event 5013 can indicate that tamper protection blocked a change), shadow copy deletion or backup job changes. The ATT&CK v20 Defense Impairment tactic (TA0112) covers that second stage.
4. Look across hosts. The same product check on many hosts in quick succession from one account suggests scripted reconnaissance across the estate, which ransomware affiliates run before mass deployment.
5. Treat backup discovery separately. Queries for backup services, backup consoles or backup configuration files from non-backup accounts are rare enough to alert on alone, and the cost of missing them is the loss of recovery.

Cloud agent and extension inventory

In cloud environments, attackers holding a stolen access key or a compromised workload role can read the software inventory you built for operations. AWS Systems Manager Inventory, for example, collects applications, AWS components such as agents and drivers, services and Windows registry values from managed nodes, which is exactly the list an attacker wants. ATT&CK v20 names ssm:ListInventoryEntries and ssm:GetCommandInvocation in CloudTrail as the IaaS signals. Alert when these calls come from identities that never use them, from new source networks, or shortly after a new access key appears. The same principle applies to reading VM extension or agent state through Azure and Google Cloud management APIs: baseline which automation identities do this, and flag the rest. See the MITRE ATT&CK T1580 Cloud Infrastructure Discovery guide for the wider cloud discovery picture.

Where non-human identities fit

Most software discovery in a healthy estate is done by non-human identities: inventory agents, configuration management service accounts, vulnerability scanners and cloud automation roles. That is why baselining by identity works. Record which service accounts and workload roles are expected to run software inventory, from which hosts and on what schedule, and alert on human accounts or unexpected machine identities performing the same queries. The flip side is that a stolen inventory or scanner credential gives an attacker a ready-made, low-noise view of your security tooling; scope those credentials to read only what they need and monitor their use like any other privileged NHI. See the How to find Windows services running as domain accounts guide for one place to start.

Mitigations and controls

ATT&CK v20 lists no mitigations for T1518 or its sub-techniques, because the commands involved are normal administrative functions. The useful controls are the ones that make the follow-on step fail, plus coverage that leaves no host unmonitored. These are NHI Mgmt Group recommendations.

How to test your detections

1. Agree scope and a test host set. Use a pilot group with full EDR and logging, and tell the SOC in advance or run as a purple team exercise.
2. Emulate the discovery step only. Use an authorised adversary emulation framework's T1518 and T1518.001 tests, which query installed software and security products without changing anything. Do not run tampering tests on production endpoints.
3. Check each analytic fires with the right context. Confirm the alert names the parent process, account and queried product, and that the inventory agent's routine queries do not fire.
4. Test the sequence rule. On a lab host, follow the discovery with a benign change that tamper protection should block, and confirm the correlated alert and Defender event 5013 appear.
5. Test cloud signals. From a test role, call the inventory APIs and confirm CloudTrail delivery and the identity baseline alert.
6. Roll back. Remove test accounts and keys, and document suppressions added during tuning with an owner and expiry date.

Measuring it

• EDR coverage: percentage of servers and endpoints onboarded and reporting in the last 24 hours, with identity infrastructure tracked separately (target 100%).
• Tamper protection coverage: percentage of onboarded devices with tamper protection enabled.
• Analytic precision: share of T1518.001 and T1518.002 alerts that were true positives or authorised tests after tuning.
• Sequence latency: time from a watchlist query to analyst triage when it is followed by a tampering event.
• Unexpected inventory callers: count of identities calling cloud inventory APIs outside the approved list each month (target zero).

Common failure patterns

• Alerting on every software query. The SOC drowns in inventory agent noise, then disables the rule. Use product watchlists, parent and account context and sequences.
• Coverage gaps on the systems that matter. As in the Storm-0501 case, identity sync servers and secondary domains without EDR give attackers somewhere to work. Count coverage per domain and per tenant, not overall.
• Ignoring backup discovery. Teams tune security product checks but have no rule for backup product checks, so the first sign is failed restores.
• Tamper protection turned off for convenience. Exclusions and policy changes are easier without it, and so is the attacker's next step. Use troubleshooting mode for temporary changes instead.
• No cloud control plane view. Endpoint rules miss an attacker reading agent and software inventory through cloud APIs with a stolen key.

Framework mapping

Practitioner checklist

• Build a watchlist of service, process, driver and path names for every security and backup product you run.
• Deploy the ATT&CK v20 DET0016, DET0088 and DET0392 analytics, scored by parent process and account.
• Add a correlation rule: watchlist query followed by tampering, exclusion change or backup change on the same host.
• Baseline which service accounts and cloud roles legitimately run software and agent inventory, and alert on others.
• Enable tamper protection on all supported endpoints and track coverage.
• Reconcile EDR onboarding against asset inventory weekly, starting with identity and backup servers.
• Collect command line, PowerShell, auditd and macOS unified log telemetry needed by the analytics.
• Run a discovery-only emulation test each quarter and after major EDR changes.

Standards and references

• MITRE ATT&CK: T1518 Software Discovery
• MITRE ATT&CK: T1518.001 Security Software Discovery
• MITRE ATT&CK: T1518.002 Backup Software Discovery
• CISA: #StopRansomware: Play Ransomware (AA23-352A)
• Microsoft Threat Intelligence: Storm-0501's evolving techniques lead to cloud-based ransomware
• Microsoft Learn: Protect security settings with tamper protection
• AWS: AWS Systems Manager Inventory
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: EDR Evasion and Defence Guide · T1685 Disable or Modify Tools Defensive Guide · EDR Tampering and BYOVD Response Playbook · T1490 Inhibit System Recovery Defensive Guide · Discovery and Reconnaissance Techniques Guide