When your antivirus says it “found a threat,” the first instinct is “what did I just download?” But if you misread the date on that alert, you can panic over a perfectly fine situation.
Summary (TL;DR)
The detection date is not the day a file arrived or ran. It is the day the scanner found it.
Pull the file path from the detection log (Get-MpThreatDetection), then compare it against the file’s creation time. That tells “an old file the scanner caught late” from “something that just ran” in about five minutes. Usually it is the former.
Why did Defender flag it on a day I wasn’t even there?
One day Defender’s protection history showed a threat — classified HackTool, status “quarantined.” The catch: on that detection date I wasn’t at the PC. I was away on a night shift.
“I didn’t touch anything, so why did it trigger?” This is where a lot of people assume they have been hacked. The answer was far more boring. (I traced this together with my AI pair, command by command.)
The trap: detection date is not the day it arrived
Defender runs scheduled scans on its own, with nobody at the keyboard. So the “detection date” on screen is not when the file entered the system, and not when it ran. It is just the day the scanner found it.
Think of it this way. If a cleaner finds spoiled food at the back of a pantry on Tuesday, that does not mean the food arrived on Tuesday. When it actually arrived is a separate question.
Evidence 1 — pull the file path from the log
The on-screen alert only shows a summary. To see where the file actually was, dig with PowerShell.
Get-MpThreatDetection | ForEach-Object {
$name = (Get-MpThreat -ThreatID $_.ThreatID).ThreatName
"$($_.InitialDetectionTime) | $name | $($_.Resources)"
}
Resources holds the full path of the quarantined file. In my case it looked like this.
2026-06-19 10:43 | HackTool:... | file:D:\projects\_trash\downloads\...\setup.exe
Two things stand out. First, the file was inside a trash folder — already set aside for deletion. Second, the detection time was 10:43 AM, while I was away.
Evidence 2 — compare against the file’s creation time
Now the clincher. Check when the file actually appeared there.
Get-ChildItem 'D:\projects\_trash' -Recurse -Filter setup.exe |
Select-Object FullName, CreationTime, LastWriteTime
The creation time was a week earlier than the detection. So the file had been moved to trash a week ago, and the scheduled scan only swept that folder — and quarantined it — on that day.
Nothing ran that day. There is no contradiction with being away on a shift.
You can also confirm the scan runs on its own.
Get-MpComputerStatus | Select-Object QuickScanStartTime, QuickScanAge
A small QuickScanAge (say, 1 day) means Defender is scanning on a schedule without you.
Residue check — if it really ran, it leaves traces
“But what if it did run?” Test that hypothesis too. If malware actually executed and dug in, it leaves traces in startup items or services.
Get-CimInstance Win32_StartupCommand | Select-Object Name, Command, Location
Note: Win32_StartupCommand only covers Run keys and the Startup folder. It misses Scheduled Tasks (Get-ScheduledTask), Services (Get-CimInstance Win32_Service), WMI event subscriptions, and other autostart vectors. For a thorough sweep, Sysinternals Autoruns enumerates every autostart point (admin rights required).
If the startup list is all programs you recognize (cloud sync, messengers, antivirus) with nothing unfamiliar, there is no residue. If Defender quarantined the file and startup is clean, you are done.
How should you check when your AV flags something?
Here is the quick reference I use now. The left column usually means an old file; the right column means dig deeper.
| Signal | Safe side (usually an old file) | Suspicious side (dig deeper) |
|---|---|---|
| File location | Trash / Downloads folder | System folder / startup |
| Creation time | Days to weeks before detection | Right before detection |
| Status | Quarantined / removed | Active |
| Startup | Nothing unfamiliar | New unknown entry |
- Detection is not execution — being detected does not mean it ran. Quarantined means the AV already stopped it.
- Verify the date — the detection date is just the discovery day. Compare against the file’s creation time.
- Check the path — use
Get-MpThreatDetectionto find where the file actually was. Trash or Downloads changes the risk. - Check for residue — if startup and services have nothing unfamiliar, there is no sign it ran.
Five minutes on these four points usually settles whether it is a real breach or “the scanner cleaning up an old file late.” Most of the time it is the latter.
Bottom line
The date on an AV alert is the day it was found, not the day you were hit. Before you panic, check the path and the creation time first.
References
- Get-MpThreatDetection (Microsoft Learn)
- Get-MpThreat (Microsoft Learn)
- Get-MpComputerStatus (Microsoft Learn)
Note: I actually ran the PowerShell commands above and confirmed they work. Paths and timestamps are masked example values. Registry and startup paths may differ on your system, so confirm on your own machine.
Leave a Reply