Get-MpThreatDetection reads active and past malware threats detected by Microsoft Defender on the computer. It is useful when a support ticket asks what Defender recorded, but its output is not a certificate that the endpoint is clean. A past detection, a repeated detection and an empty successful result each need different interpretation.
This workflow is for authorised defensive inspection on Windows. It reads detection records without removing threats, restoring files, adding exclusions or switching protection off. If an incident is already suspected, follow your organisation’s response process rather than delaying escalation while trying to produce a perfect report.
Establish the endpoint and the question
Before opening PowerShell, confirm the device and ticket you are investigating. Record the observation time and the user’s reported event: for example, an alert after opening an attachment. Do not describe that report as a confirmed infection or invent an explanation for it. Keep observed behaviour separate from your interpretation.
Use a Windows session with the Defender module available and an account authorised for the inspection. These cmdlets are not general Linux PowerShell commands. If the command is unavailable, or the endpoint is managed with a different security product, that is a tooling or environment limitation, not proof of absent threats.
Do not change antivirus modes, permissions or organisational policy merely to obtain output. A managed device’s security administrator can determine the appropriate collection route when the local query is unavailable.
Capture a fresh successful query before counting
Run this block in Windows PowerShell on the intended endpoint. It resets the variable first, captures output as an array, and prevents a failed query from being reported as a successful empty inventory:
$detections = $null
try {
$detections = @(Get-MpThreatDetection -ErrorAction Stop)
Write-Output ("Returned detection records: {0}" -f $detections.Count)
$detections | Format-List *
}
catch {
$detections = $null
Write-Error ("Detection query failed; no clean-state conclusion: {0}" -f $_.Exception.Message)
}The count describes returned records, not necessarily distinct malware families, affected files or incidents. Microsoft’s documentation says that a specified threat can return each time Defender detected it. Repeated entries therefore need investigation rather than automatic deduplication into a single harmless event.
Format-List * is used here for interactive inspection of the properties actually returned by your system. It is not a promise of identical fields on every Windows build. If you later automate collection, retain the original objects before formatting, document the schema you use, and distinguish unavailable properties from negative answers.
Read the evidence without overstating it
A successful query with records establishes that Defender has recorded detections available to this query. It does not, by itself, tell you that every detection is still active or that every required remediation step has completed. Review the returned details alongside Windows Security and the organisation’s management console or incident records.
A successful query with zero records means this command returned none in this context. It does not establish that the computer has never been compromised, that another security product has no alerts, or that an unobserved threat cannot exist. A failed query is weaker still: it establishes that collection failed, and should not be relabelled as zero detections.
For example, if a user reports an alert but your query succeeds with no records, preserve both facts. Ask the security team to reconcile the alert’s device, time and originating product. Do not close the case merely because one local query did not reproduce the report.
Preserve a useful, restrained handover
Document the endpoint identifier, collection time, exact command, whether it succeeded, and relevant returned details or error text. Separate the user’s account, the recorded evidence and the next requested action. File paths and usernames can contain sensitive information: share them only through the approved incident channel, not a public forum or unrestricted chat.
Do not open a suspicious file to confirm the result, restore quarantined material for a screenshot, or add an exclusion to silence an alert. Those are changes with different risks and authorisation requirements. The read-only command does not need a rollback; any later remediation should have its own approved procedure.
Detection history also answers a different question from protection readiness. For that separate check, see checking Defender signature freshness. A current signature timestamp is not evidence that a specific incident has been resolved either.
Quick questions before closing the ticket
Does an old record mean an active infection? Not automatically. The command covers active and past detections; reconcile the actual record and incident status before labelling it.
Does this command start a scan or remove malware? No. This article uses the retrieval cmdlet, not a scan, removal or configuration command.
Was this tested on my endpoint? No. The example follows the documented command interface; your Windows environment, permissions and returned records must be checked locally.
Source: Microsoft’s Get-MpThreatDetection reference, including its description of active and past threats and repeat detections.
This tutorial is for educational, defensive use. Test carefully before production use and work only on authorised systems. The site owner is not responsible for misuse, damage, data loss or production issues.
