Bug Bounty

Microsoft probes SignDrop zero-day dropped amid bounty feud

Microsoft is investigating SignDrop, a public Windows SYSTEM exploit from a researcher who says the firm withheld bounties. What UK teams should do.

Illustration of a bug symbol over a Windows-style grid with the words Windows zero-day dropped amid bounty feud

Microsoft is investigating SignDrop, a public Windows privilege escalation exploit released with no CVE or patch by a researcher who accuses the company of withholding bounty payments. Independent testers say it works on some systems, which puts the long-running feud over coordinated disclosure back on defenders’ desks.

What happened

On 13 November Microsoft confirmed it is looking into SignDrop, a proof of concept published on GitHub earlier in the week by the researcher known as Nightmare Eclipse. In a statement to SecurityWeek the company said it had not seen the technique used in attacks and that “Microsoft Defender detects and blocks exploitation of this vulnerability”. It has not assigned a CVE, issued an advisory or shipped a fix.

The code went public on 10 November, the same day as November’s Patch Tuesday, so it missed that month’s update cycle entirely. Over the following three days several parties tried it out. Cyderes compiled and ran the code and found no sign of exploitation in the wild. Heewon Song of 78researchlab’s PurpleHound team confirmed that it works but judged it too unreliable for operational use, according to the firm’s head of research, Sungyup Nam. Will Dormann, a veteran vulnerability analyst, reproduced it as well, though only on some Windows 11 machines, Ars Technica reported.

SecurityWeek names the researcher as Abdelhamid Naceri. SignDrop is the latest in a run of Windows and Defender exploits he has released since April. Three are now on CISA’s Known Exploited Vulnerabilities catalogue, and Microsoft has since assigned CVEs to others, including RoguePlanet (CVE-2026-50656) and ShieldBreak (CVE-2026-69414).

The technical picture

SignDrop does not abuse a memory corruption bug in the Common Log File System driver, the usual CLFS problem. It turns the mitigation against itself. In October 2025 Microsoft began requiring CLFS log files to pass an authentication check so that the kernel driver would refuse to parse tampered logs. To support that check, the driver writes a companion authentication file next to each log.

According to the researcher’s write-up, a standard user can prepare a log that a more privileged process is later induced to open. In the published chain that process is the Defender antimalware service. The companion file is then created with that process’s authority but keeps permissions the user can modify, and that can be chained into full SYSTEM rights. The researcher’s own verdict was that Microsoft implemented everything correctly but “the logic allows abuse”.

The scope is narrower than the researcher’s headline claim that about 80 per cent of Windows installations are exposed. Testing so far points to Windows 11 26H2 and Server 2025 preview builds with the CLFS authentication mode set to enforced or learning. Machines older than about 90 days move to enforcement automatically. Defender has to be running. The exploit also changes how UAC prompts behave, so anyone sitting at the machine would probably notice. A broader claim that the same trick could disable other vendors’ anti-tamper protections has not been independently tested. No safe workaround exists: switching the mitigation off removes this path but reopens the memory corruption risks it was built to close.

Timeline of the SignDrop disclosure from the researcher's first releases in April to Microsoft's statement on 13 November 2026

Why it matters for UK organisations

Local privilege escalation bugs rarely start an intrusion, but they often decide how bad one gets. A phishing payload or a stolen low-privilege account becomes far more dangerous once the attacker can reach SYSTEM, disable security tooling and harvest credentials. CLFS flaws have a track record here: ten are already listed as exploited by CISA, one of them used in ransomware campaigns in 2025. Three of this researcher’s earlier releases were exploited after publication, so the risk that criminals adopt public code is real.

The bounty and disclosure angle matters too. The UK government has said it will give “accredited” researchers a defence under section 1 of the Computer Misuse Act, but the scheme does not yet exist. Meanwhile the NCSC continues to push organisations to publish vulnerability disclosure policies. Cases like this show what happens when the relationship between a researcher and a vendor breaks down entirely. According to Naceri’s own account, as reported by Security Affairs, he previously worked for Microsoft in the UK and Germany and lost a German labour court challenge over his dismissal. Earlier this year he alleged that Microsoft deleted his MSRC account, held back bounty payments and removed his credit from an advisory. None of those claims has been independently verified. Microsoft, for its part, has said uncoordinated releases of exploit code are “never justifiable”.

Expert view

I have no sympathy for dropping working exploit code for unpatched flaws. Defenders end up taking the punishment meant for a vendor. Still, this saga is a warning about how fragile coordinated disclosure is. Bug bounty programmes run on trust. A researcher hands over valuable work on the understanding that it will be triaged fairly, credited properly and paid as promised. When a researcher believes that bargain has been broken, private reporting stops being attractive. A talented, aggrieved person can then do a great deal of damage without selling anything.

Katie Moussouris, who designed Microsoft’s original bounty programme, made a related point on Bluesky earlier this year, as reported by The Record: non-disclosure, often driven by vendor threats, is worse than an awkward public drop. I agree. Organisations that run their own VDPs or bounties should treat researcher relations as a security control, not a public relations exercise. Clear timelines, honest communication when a report is rejected, and a route to escalate disputes cost far less than an exploit published on Patch Tuesday.

In my experience, privilege escalation is where internal testing most often turns a minor foothold into domain-wide compromise. Treat SignDrop as a reason to test whether your environment would notice a standard user suddenly running as SYSTEM, not as a reason to panic.

What to do now

  1. Find exposed builds. Inventory Windows 11 26H2 and Server 2025 systems, including preview builds, and check the CLFS authentication mode in the registry. Do not disable the mitigation to avoid SignDrop.
  2. Keep Defender current and its protections switched on. Microsoft says Defender blocks this exploit, so confirm signatures are updating and tamper protection is enabled across the estate (Cyber Essentials: malware protection).
  3. Tighten local privilege. Remove standing local admin rights, use LAPS or equivalent, and restrict who can log on interactively to servers (Cyber Essentials: user access control).
  4. Hunt for unusual SYSTEM activity. Alert on unexpected SYSTEM shells spawned from user sessions, odd UAC behaviour and anomalous Defender update activity, and make sure your EDR has coverage.
  5. Watch the MSRC update guide. Plan to deploy any out-of-band fix inside the 14-day window Cyber Essentials expects for critical updates (Cyber Essentials: security update management).
  6. Review your own disclosure process. If you run a VDP or bounty, check response times, rejection communications and escalation routes so that a dispute never ends in a public drop.

Bottom line

SignDrop is a real but narrow privilege escalation risk. Defender reportedly blocks it and there is no evidence of attacks yet. The bigger lesson is about disclosure: when trust between researchers and vendors collapses, customers pay the price. Patch quickly when Microsoft responds, limit local privilege now, and make sure your own researcher relationships never reach this point.

Sources