Security Software False Positives

Software developers and end-users are often interested in understanding how to resolve incorrect detections from their antivirus/security software, including Microsoft Defender.

Such False Positives (FPs) can disrupt your use of your device by incorrectly blocking innocuous files or processes. However, you should take extreme care before concluding that a given detection is a false positive — attackers work hard to make their malicious files seem legitimate, and your security software is built by experts who work hard to flag only malicious files.

How Do False Positives Occur?

Every security product must perform the difficult task of maximizing true positives (protecting the user/device) while minimizing false negatives (protecting productivity/data). The resulting ratio is called security efficacy.

False-positives can occur for numerous reasons, but most are a result of security software observing what it deems to be suspicious content or behavior on the part of a file or process. Virtually all modern security software consists of a set of signatures and heuristics that attempt to detect indications of malice based on threat intelligence data collected and refined by threat researchers (both humans and automated agents). In some cases, the threat intelligence is scoped too broadly and incorrectly implicates harmless files along with harmful ones.

To correct this, the threat intelligence from your security vendor must be adjusted to narrow the detection so that it applies only to truly malicious files.

Sidenote: Is it really a block?

In some cases a security feature might block a file not as malicious but merely as uncommon; for example, SmartScreen Application Reputation can interrupt download or starting of an app if the app isn’t recognized:

In such cases, users may choose to ignore the risk and continue if they have good reason to believe that the file is safe. Over time, files should build reputation (especially when signed, see below) and these warnings should subside for legitimate files.

False Positives for End-Users

Before submitting feedback, it’s probably worthwhile to first confirm what security product is triggering a block. In some cases, blocks that look like they may be coming from your security software might actually reflect intentional blocks from your network security administrator. For example, users of Microsoft Defender for Endpoint should review this handy step-by-step guide.

To get a broader security ecosystem view of whether a given file is malicious, you can check it at VirusTotal, a free service which will scan files against most of the world’s antivirus engines and which allows end-users to vote on the safety of a given file.

When a security vendor realizes a false positive has occurred, they will typically issue a signature update; while this typically happens entirely automatically, you might want to try updating your signatures just to ensure they’re current.

False positives (and false negatives) for Microsoft Defender Antivirus can be submitted to the Defender Security Intelligence Portal; these submissions will be evaluated by Microsoft Threat researchers and detections will be created or removed as appropriate. Other vendors typically offer similar feedback websites.

In most cases, users may override incorrect detections (if they are very sure they are false positives) using the Windows Security App to “Allow” the file or create an exclusion for its location.

Avoiding False Positives for Software Vendors

If you build software, your best bet for avoiding incorrect detections is to ensure that your code’s good reputation is readily identifiable for each of your products’ files.

To that end, make sure that you follow Best Practices for code-signing, ensuring that every signable file has a valid signature from a certificate trusted by the Microsoft Trusted Root Program (e.g. Digicert, Azure Trusted Signing).

If your files are incorrectly blocked by Microsoft Defender, you can submit a report to the Defender Security Intelligence Portal.

-Eric

Security Surfaces

An important concept in Usable Security is whether a given UI represents a “security surface.” Formally, a security surface is a User Interface component in which the user is presented with information they rely upon to make a security decision. For example, in the browser, the URL in the address bar is a security surface. Importantly, a spoofing issue in a security surface usually represents a security vulnerability.

Just as importantly, not all UI surfaces are security surfaces. There are always many other UI surfaces in which similar information may be presented that are not (and cannot be) security surfaces.

Unfortunately, knowing which surfaces are security surfaces and which are not is simultaneously

  1. Critically important If you think an untrustworthy surface is trustworthy, you might get burned.
  2. Unintuitive There’s usually no indication that a surface is untrustworthy.

Eight years ago, Chromium wrote a document listing the Chrome browser’s security surfaces. Approximately no one has ever seen it.

Non-Security Surfaces

Perhaps the most famous non-security surface is the “status bubble” shown at the bottom left of the browser window that’s designed to show the user where a given link will go:

The Chromium “Status Bubble”

There are many reasons why this UI cannot be a security surface.

The primary issue is that it’s below the line-of-death, in a visual area of the page that an attacker can control to paint anything they like. The line-of-death is a major reason why many UIs cannot be considered security surfaces — if an attacker has control over what the user sees, a UI cannot be “secure.”

But even without that line-of-death problem, there are other vulnerabilities: most obviously, JavaScript can cancel a navigation when it begins, or it can rewrite the target of a link as the user clicks on it. Or the link could point to a redirector site (e.g. bit.ly) rather than the ultimate destination. etc.

Low-Priority Security Surfaces

An example of a low-priority security surface is the edge://downloads page. This page shows a list of downloads and allows the user to open them. In some versions of Edge, this page will show the URL from which the download originated.

A user might look at that URL to decide whether the download originated from a trustworthy place before running it. This means that any issue where the URL shown is incorrect or misleading is arguably a security issue because the user could make a security decision incorrectly based on the “spoofed” URL. URL spoofing might include triggering a download from an open-redirect on a trustworthy domain, or using a URL protocol like data: that allows the attacker to control the contents of the subsequent string (e.g. data:spoofed.com/mime,base64...).

A mitigating factor here is that the edge://downloads page is relatively obscure. Almost all user interaction with downloads occurs using the Downloads bubble that opens from the icon in the browser toolbar. Even if the user does end up making a security decision from the Downloads page, other features like SmartScreen AppRep still provide protection from files not known to be safe.

Challenging Security Surfaces: The “URL Bar”

Perhaps the most complicated security surface in existence is the browser’s address bar, known in Chromium-based browsers as the “Omnibox”.

The “omnibox” in modern Edge

That omnibox naming reflects why this is such a tricky security surface: Because it tries to do multiple things: It tries to be a security surface which shows the current security context of the currently-loaded page (e.g. https://example.com), but it also tries to be a information surface which shows the full URL of the page (e.g. https://example.com/folder/page.html?query=a#fragment), and it tries to be an input surface that allows the user to input a new URL or search query. Only certain portions of the URL information are security-relevant, and the remainder of the URL could be used to confuse the user about the security-relevant parts.

Making matters even more complicated, the omnibox also has to deal with asynchronicity — what should be shown in the box when the user is in the middle of a navigation, where the user’s entered URL isn’t yet loaded and the current URL isn’t yet unloaded?

Windows LNK Inspection

Earlier this year, a security vulnerability report was filed complaining that Windows File Explorer would not show the full target of a .lnk file if the target was longer than 260 characters.

Windows File Explorer’s .lnk Properties Dialog

The reporter complained that without accurate information in the UI, a user couldn’t know whether a LNK file was safe.

This is true, but it’s also the case that the user isn’t being asked to make a security decision in this dialog; the UI where the user is asked to make a security decision doesn’t even show the target at all:

Windows Security Warning prompt when opening a LNK file from the Internet Zone

Even in the exceptionally unlikely event that a user uses Explorer’s LNK inspection UI, very few users could actually make a safe determination based on the information within. Ultimately the guidance in the Security Warning prompt is the right advice: “If you do not trust the source, do not open.”

The Windows team ended up fixing the display truncation earlier this year, but not as a security fix, just a general quality-improvement for Windows 11 24H2+.

Update: Adam complains that the Security Warning prompt doesn’t really provide the user with the information needed to decide whether the link’s source is trustworthy. He’s not wrong.

Defensive Technology: Ransomware Data Recovery

In a prior installment we looked at Controlled Folder Access, a Windows feature designed to hamper ransomware attacks by preventing untrusted processes from modifying files in certain user folders. In today’s post, we look at the other feature on the Ransomware protection page of the Windows Security Center AppRansomware data recovery.

User-Interface

The UI of the feature is simple and reflects the state of your cloud file provider (if any) which for most folks will be OneDrive. Depending on whether OneDrive is enabled, and what kind of account you have, you’ll see one of the following four sets of details:

Windows 11 Ransomware data recovery feature status

What’s it do?

Conceptually, this whole feature is super-simple.

Ransomware works by encrypting your files with a secret key and holding that key for ransom. If you have a backup of your files, you can simply restore the files without paying the bad guys.

However, for backup to work well as a ransomware recovery method, you need

  1. to ensure that your backup processes don’t overwrite the legitimate files with the encrypted versions, and
  2. to easily recognize which files were modified by ransomware to replace them with their latest uncorrupted version.

The mechanism of this feature is quite simple: If Defender recognizes a ransomware attack is underway, it battles the ransomware (killing its processes, etc) and also notifies your cloud file provider of the timestamp of the detected infection. Internally, we’ve called this a shoulder tap, as if we tapped the backup software on the shoulder and said “Uh, hang on, this device is infected right now.

This notice serves two purposes:

  1. To allow the file backup provider to pause backups until given an “all clear” (remediation complete) notification, and
  2. To allow the file backup provider to determine which files may have been corrupted from the start of the infection so that it can restore their backups.

Simple, right?

-Eric

Appendix: Extensibility

This feature is Defender’s implementation of a semi-public interface (IWscDataProtection) that allows third-party security software and cloud backup software to integrate with the Windows Security Center. OnDataCorruptionMalwareFoundNotification and OnRemediationNotification. Unfortunately, the documentation isn’t public — it’s only available to members of the Microsoft Virus Initiative program for AV partners.


When a 3rd party antivirus application is installed and Microsoft Defender is disabled, attempting to open “Ransomware data recovery” from the Windows Start menu shows the following end message:

Windows Shell Previews – Restricted

Windows users who installed the October 2025 Security Updates may have noticed an unexpected change if they use the Windows Explorer preview pane. When previewing many downloaded files, the preview is now replaced with the following text:

Explorer PDF Preview: “The file you are attempting to preview could harm your computer.”

While it also occurs when viewing files on remote Internet Zone file shares, the problem doesn’t occur for other files on your local disk, for remote shares in your Trusted or Intranet zone, or if you manually remove the Mark-of-the-Web from the file.

😬 BUG: Notably, Explorer caches a previously-observed Mark-of-the-Web, and due to a bug (discovered in October 2025) deleting the MotW stream by clicking the Unblock Button doesn’t clear the cached Zone, so users must restart Explorer to actually preview a file.

What happened?

The change in Windows was a trivial one: the value for URLACTION_SHELL_PREVIEW (0x180f) in the Internet Zone (3) was changed from Enable (0) to Disable (3):

Before Windows Explorer asks the registered previewer to show the preview for a file, it consults the SHELL_PREVIEW URLAction to see whether the file’s location allows previews. With this settings change, the permission to show previews is now denied for files that originate from the Internet Zone.

Why?

The reason is a simple one that we’ve covered before: the risk of leaking NTLM credential hashes to the Internet when retrieving resources via SMB via the file: protocol. Leaked hashes could allow an attacker to breach your account.

As we discussed in the post on File Restrictions, browsers restrict use of the file protocol to files that are opened by the file protocol. When you preview a downloaded file in Explorer, the URL to that download uses file: and thus the previewer is allowed to request file: URLs, potentially leaking hashes when the file is previewed. With this change, the threat is blunted because with the previews disabled, you’d have to actually open the downloaded file to leak a hash.

Unfortunately, this fix is a blunt instrument: while HTML files can trivially reference remote subresources, other file types like PDF files typically cannot (we disable PDF scripting in Explorer previews) but are blocked anyway.

If you like, you can revert this change on your own PC by resetting the registry key (or by adding download shares you trust to your Trusted Sites Zone). However, keep in mind that doing so reenables the threat vector, so you’ll want to make sure you have another compensating control in place: for example, disabling NTLM over SMB (more info), and/or configuring your gateway/firewall to block SMB traffic.

For Developers

By default, Shell previewers run at Low Integrity, but an opt-out flag DisableLowILProcessIsolation permits an individual previewer to opt-out of that protection. Unfortunately for this scenario, LowIL processes are not immune to the SMB leak.

Other trivia:

I do not think the active previewer is tied to the Windows File Associations settings in any way.

When I change my PDF viewer from Edge to Chrome, there’s no change in the registry key that defines the Previewer. (And I don’t see the Previewer registry key 8895b1c6-b41f-4c1c-a562-0d564250836f in the Chromium Source).

It looks like it’s always just looking directly at `\ShellEx\{88….09e}`. So when I install Acrobat Reader, it immediately takes over the `\ShellEx\{88….09e}` key (before prompting to become the default PDF handler). Even if I set my default PDF viewer back to Edge, that `\ShellEx\{88….09e}` still points at Acrobat. After I uninstall Acrobat Reader, it blows away the shellex registry key entirely, leaving no previewer for PDF files. Even choosing Edge as the default PDF handler again doesn’t fix it.

-Eric

An Improbable Recovery

Way back on May 11th of 2022, I was visiting my team (Edge browser) for the week in Redmond, Washington. On Wednesday night, I left my ThinkPad X1 Extreme laptop in a work area on the 4th floor of the office when I went out for drinks with friends.

After dinner, I decided not to head back to the office to grab my laptop and bag to bring them back to the hotel. When I arrived at the office the next morning, my backpack (containing $80 in cash) and charger were still there, but my laptop was nowhere to be found. An exterior door in a nearby stairwell had been failing to latch but hadn’t been reported to the maintenance team.

I muddled through the rest of the week before heading home to Austin. Losing my X1 was a huge loss for me, because a bunch of irreplaceable files on it were not backed up to the cloud, including tax return data files and a birthday video some friends had arranged from Cameo. Some code updates to my tools hadn’t yet been uploaded to GitHub, and I lost access to a variety of notes and other information that wasn’t copied elsewhere. One consolation was that I knew that I’d enabled BitLocker Drive Encryption on the main disk, so the company’s data was safe.

For decades I’ve been worried about losing files through human error. Unfortunately, I only backed up to external drives every month or two, instead relying on more frequent backups by copying to dated folders to a second SSD on the same machine. Because COVID WFH meant that my laptop rarely left my home office, my entire machine getting stolen just wasn’t a significant part of my threat model. Oops.

I held out some hope that Microsoft Campus Security had video of the thief, and indeed they did. They supplied it to the Redmond Police department. Apparently, the thief was a “known transient in the area” and for a few weeks I held out hope that might mean I would see my laptop again. As the months went by, I lost hope. Because the laptop was my personal machine in BYOD mode (I’ve long used exclusively my own hardware for work) Microsoft wasn’t going to buy me a new one. Depression and frustration about the situation doubtless contributed in part to my leaving the Edge team later that summer.

The next time I gave my missing ThinkPad any real thought was the following April, when I was doing my taxes and had to painstakingly reenter data and make my best guesses based on my recollections of the past year’s now-missing data. It was very frustrating, and I’m sure I paid a few hundred dollars more than I needed to, having lost carryover deductions.

The last time I really thought about my lost ThinkPad was two years ago, when someone stole my son’s iPad out of my car parked in front of my house. I immediately assumed it was gone forever, and rolled my eyes that Apple’s “Find My” was so dumb that it still showed the tablet outside my house. And not even directly in the driveway of my house, but like 300 feet away. And that location never updated in the following days. Annoyed, I finally grudgingly decided to meander down the block to the tiny grove of trees marked by the blue dot and … sure enough, the iPad was sitting there in the grass under a tree. The thieves were smart enough to realize that they weren’t going to be able to use or sell the iPad without its passcode. Amazing.

Years passed.

And then…

Improbably, two weeks ago I received the following email:

I clicked the link, and sure enough, there it was, my laptop with my name still on the screen:

The listing was posted 60 miles away from Redmond. I contacted the seller and in chats over the following week, more of the story came out. Alexandra bids on abandoned storage units, and a recent acquisition had a pile of laptops in it, including mine. She mentioned that the container also had another ThinkPad, which unlike mine, bore a “Microsoft Asset” sticker on it. (I grabbed that Asset number and told her that our Corporate Security team would be in touch.)

She shipped my laptop back to me (somewhat tenuously packed in just an envelope full of bubble-wrap) and it arrived this afternoon. The fun stickers that once adorned the face are gone without a trace, but it’s unquestionably my device.

I’m a little afraid to turn it on — I’m pretty sure when I do, it’s going to auto-connect to my WiFi, realize that it’s been marked stolen, and get automatically wiped. Still, even in the unfortunate event that such a wipe happens, I might still end up formatting and reinstalling Windows 11 on it — the X1 Extreme Gen1 was the last ThinkPad that I really liked (my more recent buys have been “meh“), and it probably has at least a bit of useful life left in it.

And there’s something kinda magical in having my long wandering machine finally, improbably, find its way home, one thousand two hundred sixteen days later….

Lessons

  1. If you see something, say something. I never would’ve gotten this laptop back if Howard didn’t reach out. It never would’ve been stolen to start with had the defective door been reported. (This advice goes for software bugs too!)
  2. Encrypt your disk. I would’ve been very very uncomfortable with my tax returns and other personal data floating around in the wide world.
  3. Regularly back up your data. Cloud backups are convenient, local offline backups provide additional assurance. Don’t forget your BitLocker keys!

-Eric

PostScript

Postscript: It looks like Microsoft Corp got rid of my device’s BitLocker disk encryption recovery key years ago, and I couldn’t find a copy of the recovery key file anywhere on my many external devices. (Consider backing yours up right now!)

But I randomly searched my other machines for text files containing the word “BitLocker” and found the X1’s key in an old SlickRun Jot file backed up from another laptop in 2022. I turned off WIFI in the X1 BIOS and successfully booted to my Windows desktop. It was a bit disorienting at first because the colors were all nuts — apparently, the last thing I was working on that fateful night in 2022 was a high-contrast bug. :)

omg omg omg I’m in!

Unfortunately, it looks like one component didn’t survive over the years — my beloved TrackPoint (the little red eraser-looking input device) only moves the cursor side-to-side, so I have to rely on the touch pad. But still, not bad at all.