Daily Digest

German authorities just pulled back the curtain on one of the most wanted hackers in ransomware history. The mysterious figure behind the notorious REvil and GandCrab gangs—known only as "UNKN"—now has a name and a face. Meet Daniil Maksimovich Shchukin, a 31-year-old Russian who allegedly masterminded over 130 cyberattacks against German targets. The damage? More than 35 million euros, with nearly 2 million euros in direct ransom payments. If you or your business have ever feared ransomware, this is the kind of bust that sends shockwaves through the underground.

**What exactly happened** German Federal Criminal Police (BKA) publicly identified Daniil Maksimovich Shchukin as the elusive leader behind two of the most damaging ransomware operations in history: GandCrab and REvil. For years, he operated under the handle "UNKN" or "UNKNOWN," hiding in plain sight while orchestrating global extortion campaigns. The BKA advisory linked Shchukin to at least 130 acts of computer sabotage and extortion against German victims between 2019 and 2021. He wasn't working alone—authorities also named 43-year-old Anatoly Sergeevitsch Kravchuk as a co-conspirator in the scheme. **Who is affected and how** The primary victims were German companies and organizations, but the ripple effects extend worldwide. GandCrab and REvil didn't discriminate—they hit hospitals, schools, government agencies, and private enterprises across multiple continents. Shchukin's groups pioneered the "double extortion" model that has since become industry standard among ransomware gangs. First, they'd encrypt your files and demand payment for the decryption key. Then, they'd steal your sensitive data and threaten to leak it publicly unless you paid a second ransom. **The real-world impact and consequences** The financial toll is staggering. The BKA estimates total economic damage exceeded 35 million euros from just the German attacks alone. Direct ransom payments reached nearly 2 million euros, but that's just the tip of the iceberg. Consider the hidden costs: business downtime, data recovery expenses, legal fees, reputational damage, and the psychological toll on victims. When REvil hit meat processor JBS in 2021, the company paid an $11 million ransom—and that was just one attack. **Technical breakdown** GandCrab launched in January 2018 as a ransomware-as-a-service (RaaS) operation. The model was simple but devastating: Shchukin and his core team developed the malware, then recruited "affiliates" who would distribute it in exchange for a cut of the ransom payments. REvil, which emerged in 2019, was essentially GandCrab 2.0. It refined the double extortion technique and added automated data exfiltration. The gang's custom-built portal allowed victims to negotiate ransoms and receive decryption tools—all while the stolen data sat ready for publication on a dark web leak site. **What should be done — mitigation and recommendations** For organizations still vulnerable to similar attacks, the playbook remains critical. First, implement robust offline backups that can't be encrypted by ransomware. Second, enforce multi-factor authentication everywhere—REvil often gained initial access through compromised credentials. Third, patch aggressively. Both GandCrab and REvil frequently exploited known vulnerabilities in unpatched systems. Fourth, invest in endpoint detection and response (EDR) tools that can spot ransomware behavior before encryption begins. Finally, have an incident response plan ready. Know who to call, how to isolate infected systems, and when to involve law enforcement. The BKA's success here shows that international cooperation can yield results—but only if victims report attacks promptly. **Why this matters in the bigger cybersecurity landscape** This takedown represents a major victory for law enforcement, but it's not a silver bullet. Ransomware remains a booming criminal enterprise, with new gangs emerging to fill any power vacuum. What's significant here is the shift toward attribution. For years, ransomware operators hid behind pseudonyms and jurisdictional boundaries. The BKA's work proves that anonymity is fragile—especially when investigators combine traditional detective work with modern tools like image comparison software. The unmasking of UNKN sends a clear message to the underground: no matter how careful you are, someone is watching. And eventually, they'll find you.

A cybercrime group just weaponized the Iran conflict into a digital battlefield. TeamPCP unleashed "CanisterWorm" — a self-spreading worm that hunts down poorly secured cloud servers and wipes everything if it detects Iran’s time zone or Farsi language settings. This isn't just another ransomware gang. They're using exposed Docker APIs and Kubernetes clusters like open doors, stealing credentials, and then destroying data instead of just locking it. If your organization runs cloud infrastructure in the Middle East or supports Farsi-speaking users, you need to pay attention right now.

**What exactly happened** Over the weekend, security researchers detected a new wiper campaign targeting Iran. The attacker, a relatively fresh cybercrime group called TeamPCP, deployed a worm they named "CanisterWorm" that spreads through exposed cloud services. The worm specifically targets systems configured with Iran's time zone or Farsi as the default language. When it finds a match, it wipes data instead of just encrypting it — making recovery nearly impossible without backups. **Who is affected and how** TeamPCP has been compromising corporate cloud environments since December 2025. Their primary targets are organizations using Azure (61% of compromised servers) and AWS (36%). They exploit exposed Docker APIs, Kubernetes clusters, Redis servers, and the React2Shell vulnerability. The group doesn't rely on sophisticated zero-days. Instead, they industrialize known vulnerabilities and misconfigurations at scale. As security firm Flare noted, their strength comes from "large-scale automation and integration of well-known attack techniques." **The real-world impact and consequences** This attack crosses a dangerous line. By targeting systems based on geographic and language settings, TeamPCP is injecting financial crime into geopolitical conflict. The wiper component means victims lose data permanently — no ransom, no negotiation. For organizations in or serving the Middle East, this creates an urgent operational risk. Even companies with no direct Iran connection could be affected if they host Farsi-language content or use Iran-adjacent time zones for their cloud infrastructure. **Technical breakdown — how CanisterWorm works** The worm spreads by scanning for exposed cloud control planes. Once inside, it moves laterally through victim networks, stealing authentication credentials. The wiper payload activates only when it confirms the target matches Iran-specific configurations. TeamPCP also compromised legitimate GitHub repositories to distribute malware. They injected malicious code into popular open-source projects, including the KICS vulnerability scanner from Checkmarx. This supply chain attack means even organizations with strong security could be compromised through trusted software updates. **What should be done — mitigation and recommendations** First, audit all cloud configurations immediately. Close any exposed Docker APIs, Kubernetes clusters, or Redis servers. Enable authentication for every cloud service and restrict access by IP range. Second, verify the integrity of your open-source dependencies. Check GitHub Actions and CI/CD pipelines for unauthorized modifications. Consider pinning versions of critical tools rather than automatically pulling the latest updates. Third, implement robust backup strategies with offline or immutable copies. Wipers destroy data — you can't pay to get it back. Test your recovery procedures now, not after an incident. **Why this matters in the bigger cybersecurity landscape** TeamPCP represents a worrying evolution in cybercrime. They combine the automation of nation-state actors with the ruthlessness of financially motivated gangs. Their willingness to destroy data rather than just encrypt it signals a shift toward more destructive attacks. The supply chain compromise of GitHub repositories is particularly alarming. If attackers can inject malware into widely used security tools, they gain access to thousands of organizations at once. This isn't just a problem for Iran — it's a blueprint for future attacks anywhere in the world.

Home security giant ADT just confirmed a data breach after the notorious ShinyHunters extortion group threatened to leak stolen customer records. The attackers claim to have swiped over 10 million records containing personal information — and they’re demanding a ransom by April 27. If you’re an ADT customer, your name, phone number, and address may be exposed. In some cases, partial Social Security numbers and tax IDs are also at risk. The good news? Your security system wasn’t compromised. The bad news? Your personal data is now a bargaining chip in a high-stakes extortion game.

**What exactly happened** ADT confirmed on April 20 that attackers gained unauthorized access to customer and prospective customer data. The company says it quickly terminated the intrusion and launched an investigation. But the damage was already done — personal information was stolen. The ShinyHunters extortion group then listed ADT on their data leak site, claiming to have stolen over 10 million records. They issued a final warning: pay up by April 27, or the data gets leaked along with “several annoying digital problems.” **Who is affected and how** The breach exposed names, phone numbers, and addresses for a broad set of customers and prospects. In a smaller subset of cases, dates of birth and the last four digits of Social Security numbers or Tax IDs were also taken. ADT was quick to clarify that no payment information — no bank accounts or credit cards — was accessed. And critically, customer security systems were not compromised. So your alarm still works, but your personal details are now in the hands of cybercriminals. **The real-world impact and consequences** For affected individuals, this means an elevated risk of phishing attacks, identity theft, and targeted scams. With names, addresses, and partial SSNs, attackers can craft convincing social engineering campaigns. For ADT, this is the third data breach disclosed since August 2024. That’s a troubling pattern for a company that sells security and trust. The reputational damage could be significant, especially if ShinyHunters follows through on their leak threat. **Technical breakdown — how the attackers got in** ShinyHunters told BleepingComputer they used a voice phishing (vishing) attack to compromise an ADT employee’s Okta single sign-on account. Think of it as a phone call designed to trick someone into handing over their login credentials. Once inside, the attackers used that SSO access to steal data from ADT’s Salesforce instance. This is a common playbook for ShinyHunters — they target corporate SSO accounts, then pillage connected SaaS apps like Salesforce, Microsoft 365, Google Workspace, and Slack. **What should be done — mitigation and recommendations** ADT says it has contacted all affected individuals. If you’re a customer, watch for official notifications and follow any guidance provided. For immediate protection: enable multi-factor authentication on all your accounts, especially email and financial services. Monitor your credit reports for suspicious activity. And be extra cautious of unsolicited calls or emails — attackers now have your address and phone number. For ADT and other enterprises: this breach underscores the need for stronger SSO security, vishing awareness training, and strict access controls on SaaS applications. **Why this matters in the bigger cybersecurity landscape** This breach is a textbook example of how modern cyber extortion works. Attackers don’t need to break through complex firewalls — they just need one employee to answer a convincing phone call. The rise of vishing campaigns targeting SSO accounts is a growing threat. ShinyHunters has been running this playbook since last year, hitting everything from Microsoft Entra to Okta to Google SSO. And once they’re in, they can access a treasure trove of connected apps. For security teams, the lesson is clear: your SaaS applications are only as secure as your SSO credentials. And your employees are the first — and often weakest — line of defense.

Imagine patching your firewall, rebooting, and still finding an intruder waiting inside. That’s the nightmare with Firestarter, a custom backdoor now lurking on Cisco Firepower and Secure Firewall devices. U.S. and U.K. cybersecurity agencies just sounded the alarm. This malware survives firmware updates, security patches, and even reboots. If you run Cisco ASA or FTD software, your network could be a silent battlefield—and you might not even know it yet.

**What exactly happened** Cybersecurity agencies in the U.S. (CISA) and U.K. (NCSC) are warning about a custom malware called Firestarter. It targets Cisco Firepower and Secure Firewall devices running ASA or FTD software. The backdoor is linked to a threat actor tracked as UAT-4356 by Cisco Talos. This group is known for cyberespionage, including the ArcaneDoor campaign. **Who is affected and how** Initial access came through two Cisco vulnerabilities: CVE-2025-20333 (missing authorization) and CVE-2025-20362 (buffer overflow). Attackers exploited these before patches were applied. In one incident at a federal civilian agency, CISA observed the attacker first deploying Line Viper malware. This user-mode shellcode loader established VPN sessions and stole admin credentials, certificates, and private keys. Then came Firestarter—the real persistence nightmare. **The real-world impact and consequences** Firestarter survives reboots, firmware updates, and security patches. Even if you terminate the process, it relaunches automatically. This means attackers can maintain access indefinitely. They can re-enter your network at will, steal data, or pivot to other systems. For organizations like government agencies or critical infrastructure, this is a worst-case scenario. **Technical breakdown (the "how" explained simply)** Firestarter achieves persistence through clever hooks into LINA, the core Cisco ASA process. It modifies the CSP_MOUNT_LIST boot file to ensure execution on startup. It stores a copy of itself in /opt/cisco/platform/logs/var/log/svc_samcore.log, then restores it to /usr/bin/lina_cs where it runs in the background. When a graceful reboot signal is received, the malware uses signal handlers to trigger reinstallation routines. It hooks into LINA by modifying an XML handler and injecting shellcode into memory. This shellcode is triggered by a specially crafted WebVPN request. After validating a hardcoded identifier, it loads and executes attacker-supplied payloads directly in memory. **What should be done — mitigation and recommendations** Cisco strongly recommends reimaging and upgrading devices using fixed releases. This covers both compromised and non-compromised cases. To check for compromise, run the command: `show kernel process | include lina_cs`. If any output appears, consider the device compromised. If reimaging isn't possible, a cold restart (disconnecting power) removes the malware. But Cisco warns this risks database or disk corruption, potentially causing boot problems. CISA has shared two YARA rules that can detect Firestarter when applied to a disk image or core dump. **Why this matters in the bigger cybersecurity landscape** Firestarter represents a new class of threat: malware that persists through the very updates meant to remove it. This challenges the fundamental assumption that patching equals security. For network defenders, it means traditional incident response playbooks need updating. You can't just patch and move on—you need to verify the device is clean before applying updates. This also highlights the growing sophistication of state-sponsored cyberespionage groups. They're not just breaking in anymore—they're building persistence mechanisms designed to survive our best defenses.

Microsoft is finally listening to the 7,621 complaints it read about Windows Update. The tech giant is rolling out a suite of changes that put you back in the driver's seat. The core promise? Fewer forced restarts and more control over when updates happen. If you've ever lost work to an untimely reboot or felt trapped by the update scheduler, these changes are designed for you. Everyone from home users to IT admins should pay attention.

**What exactly happened** Microsoft has announced a major overhaul of the Windows Update experience, currently rolling out to Windows Insiders. The changes directly address two pain points: disruption from untimely updates and a lack of user control. The company analyzed over 7,621 direct user feedback submissions. The result is a set of features aimed at reducing forced restarts and giving users clearer choices about when updates install. **Who is affected and how** All Windows users will eventually feel the impact, but the initial rollout targets Windows Insiders in the Dev and Experimental channels. Home users will benefit most from the new pause and power menu controls. Managed commercial devices are excluded from some features, like skipping updates during the out-of-box experience. For everyone else, the changes mean fewer unexpected interruptions and a more predictable update schedule. **The real-world impact and consequences** The biggest win is the reduction of forced restarts. Microsoft is consolidating different update types—driver, .NET, and firmware—into a single monthly restart. This means fewer reboots overall. The new Power menu is a game-changer. You can now choose "Restart" or "Shut down" without triggering updates. The "Update and restart" option only appears when you're ready. This simple change eliminates the anxiety of hitting shutdown and watching your PC decide to reboot instead. **Technical breakdown** Let's look under the hood. The update pause feature now uses a flyout calendar interface, letting you pause updates for up to 35 days. You can extend this pause repeatedly without a fixed limit. For driver updates, Microsoft is adding device type labels directly in the update title. Instead of seeing a generic "Intel Corporation" update, you'll now see "Display" or "Audio" next to it. This clarity helps you decide what's actually necessary. The consolidation trick is clever. Updates will download in the background and wait for a coordinated installation. They align with the next monthly quality update or any update you manually approve. You can still grab individual updates early if you want. **What should be done** For Windows Insiders, test these features immediately. Look for the new Power menu options and the calendar-based pause feature. Verify that driver updates now show device types. For everyone else, prepare for a smoother experience when these features reach the stable channel. IT admins should review the changes to understand how they affect managed devices, especially the OOBE skip option. **Why this matters in the bigger cybersecurity landscape** This update signals a shift in Microsoft's philosophy. The company is balancing security with user experience, acknowledging that forced updates can erode trust. By giving users more control, Microsoft reduces the incentive to disable updates entirely. This is a smarter approach to security—making the secure path the easy path. If users feel respected, they're more likely to keep their systems patched and protected.

**** A new hacking group called BlackFile is flooding the retail and hospitality sectors with a wave of vishing attacks that start with a simple phone call. Posing as your own IT helpdesk, these attackers trick employees into handing over credentials, then steal massive amounts of data from Salesforce and SharePoint servers. The stakes are sky-high: seven-figure ransom demands, swatting attempts on executives, and a direct link to a notorious cybercriminal network known as "The Com." If your company relies on helpdesk support or cloud platforms, this is a threat you need to understand today. **

** **What exactly happened** Since February 2026, a financially motivated group tracked as BlackFile has been orchestrating a surge of data theft and extortion attacks. Palo Alto Networks' Unit 42, working with the Retail & Hospitality ISAC, revealed that the group impersonates corporate IT helpdesk staff to steal employee credentials. The attacks are highly targeted, focusing on retail and hospitality organizations, and demand ransoms in the seven-figure range. **Who is affected and how** The primary victims are employees at retail and hospitality companies, but the real damage hits executives and the entire organization. Attackers start by calling employees from spoofed VoIP numbers, pretending to be IT support. They lure staff to fake corporate login pages where credentials and one-time passcodes are harvested. Once inside, they register their own devices to bypass multifactor authentication and escalate access to executive accounts by scraping internal employee directories. **The real-world impact and consequences** The consequences extend far beyond data theft. BlackFile exfiltrates sensitive documents—including files containing "confidential" and "SSN" terms—from Salesforce and SharePoint servers. They publish stolen data on a dark web leak site before even contacting victims with ransom demands. To add pressure, they have targeted employees and executives with swatting attempts, making false emergency calls to law enforcement. This combination of data exposure, financial extortion, and physical intimidation creates a nightmare scenario for any organization. **Technical breakdown** The attack chain is deceptively simple yet highly effective. It begins with vishing (voice phishing) from spoofed VoIP numbers or fraudulent Caller ID Names. Once credentials are stolen, attackers use standard Salesforce API functions and SharePoint download features to move large volumes of data—including CSV datasets of employee phone numbers and confidential business reports—to attacker-controlled servers. Crucially, this is done under the guise of legitimate SSO-authenticated sessions, making it hard to detect with simple user-agent alerts. Ransom demands are sent via compromised employee email accounts or randomly generated Gmail addresses. **What should be done — mitigation and recommendations** To defend against BlackFile, organizations must strengthen their call-handling policies. Enforce multifactor identity verification for any caller claiming to be IT support. Conduct simulation-based social engineering training for frontline staff so they recognize vishing tactics. Additionally, monitor for unusual API activity in Salesforce and SharePoint, especially bulk data downloads. RH-ISAC also recommends implementing strict access controls and auditing executive-level accounts for unauthorized device registrations. **Why this matters in the bigger cybersecurity landscape** BlackFile is not an isolated threat. It is linked with moderate confidence to "The Com," a network of English-speaking cybercriminals known for targeting and recruiting young people for extortion and violence. This connection highlights a disturbing trend: the convergence of financially motivated cybercrime with more sinister criminal activities. The group's tactics—vishing, API abuse, and swatting—are being copied by other groups like ShinyHunters and SLSH. As vishing attacks surge, every organization must rethink its trust in phone-based identity verification. The era of the "friendly IT helpdesk call" is officially over.

Microsoft just dropped a major security upgrade that could finally kill passwords for good. Come late April, Windows users will be able to unlock Microsoft Entra-protected resources using nothing more than their face, fingerprint, or PIN—no passwords required. This isn't just another feature drop. It's a direct shot at the phishing attacks that have been gutting corporate accounts lately. If you're using personal or shared Windows devices to access work resources, this update is built specifically for you—closing a gap that's left millions vulnerable to credential theft.

**What exactly happened** Microsoft announced that passkey support for Microsoft Entra ID will roll out to Windows devices starting late April, with full general availability expected by mid-June 2026. This means users can authenticate to corporate resources using device-bound FIDO2 passkeys stored securely in the Windows Hello container—no passwords required. The feature extends passwordless sign-in to unmanaged Windows devices that aren't Microsoft Entra-joined or registered. That's a big deal for organizations struggling with bring-your-own-device (BYOD) policies and shared workstations. **Who is affected and how** Any organization using Microsoft Entra ID for authentication will be impacted. The feature supports corporate-managed, personal, and shared devices—meaning everyone from full-time employees to contractors and temporary workers can benefit. Admins control access through Conditional Access and Authentication Methods policies. Users simply create a passkey on their device, then authenticate using Windows Hello methods: face recognition, fingerprint, or PIN. No passwords to remember, no tokens to carry. **The real-world impact and consequences** This closes a dangerous security gap. Personal and shared devices previously relied on password-based authentication to access Microsoft Entra ID—making them prime targets for phishing and credential theft. Recent months have seen threat actors aggressively targeting Microsoft Entra single sign-on accounts using stolen credentials in waves of SaaS data-theft attacks. By eliminating passwords from these devices, Microsoft removes the primary attack vector. **Technical breakdown** Passkeys are cryptographically bound to each device and stored locally in the Windows Hello container. They never traverse the network, making them immune to phishing attacks and malware-based credential theft. Unlike Windows Hello for Business, which enables device sign-ins and single sign-on, this new feature focuses purely on authentication to Microsoft Entra ID. Users can register multiple passkeys for different work or school accounts on the same device—a flexibility that shared device scenarios desperately need. **What should be done — mitigation and recommendations** Organizations should enable "Microsoft Entra ID with passkeys" in their Authentication Methods policy. Admins must also review Conditional Access policies to ensure they allow passkey authentication from unmanaged devices. For users, the process is simple: create a passkey on your Windows device, then authenticate with Windows Hello. IT teams should communicate this change clearly to avoid confusion during the transition. **Why this matters in the bigger cybersecurity landscape** This move aligns with Microsoft's broader Secure Future Initiative, launched in November 2023. The company has been steadily eliminating passwords: making MFA registration mandatory for Entra tenants, and announcing in May 2025 that all new Microsoft accounts will be "passwordless by default." The message is clear: passwords are dying. For organizations still relying on them for unmanaged devices, this update isn't just convenient—it's a critical security upgrade that closes a vulnerability attackers are actively exploiting.

Russia's military intelligence hackers just pulled off a cyber heist so quiet, it didn't even need malware. They weaponized old, forgotten routers to steal Microsoft Office authentication tokens from over 18,000 networks. This matters because those tokens are the digital keys to your email, files, and cloud accounts. If you're on a government network, a law enforcement agency, or even just using an outdated home router, you might be the next target. The attack is stealthy, simple, and already compromised over 200 organizations and 5,000 consumer devices.

**What exactly happened** Hackers from Russia's GRU unit—known as Forest Blizzard or APT28—exploited known flaws in aging Internet routers. They didn't break into systems with flashy exploits. Instead, they quietly intercepted authentication tokens from Microsoft Office users, allowing them to bypass passwords entirely. The campaign was remarkably low-tech. By compromising routers that were end-of-life or severely outdated, the hackers created a massive surveillance network. At its peak in December 2025, this network ensnared over 18,000 routers, turning them into silent token harvesters. **Who is affected and how** Microsoft identified more than 200 organizations caught in the net. The primary targets were government agencies, including ministries of foreign affairs and law enforcement. But the attack didn't stop there—5,000 consumer devices were also compromised. The real danger is the ripple effect. Once a token is stolen, hackers can access emails, documents, and cloud services without ever triggering an alert. They can impersonate legitimate users, escalate privileges, and move laterally across networks. **The real-world impact and consequences** This isn't just a data breach. It's a strategic espionage operation. The stolen tokens grant persistent, stealthy access to sensitive communications and intelligence. For government agencies, this means leaked diplomatic cables, compromised law enforcement operations, and potentially altered policy decisions. For consumers, it means identity theft, financial fraud, and loss of privacy. The hackers could use these tokens to access personal emails, cloud storage, and even banking accounts. The scale is staggering—over 18,000 networks affected, with no malware left behind to trace. **Technical breakdown** The attack exploited known vulnerabilities in older routers, many of which no longer receive security updates. These routers acted as man-in-the-middle devices, intercepting authentication traffic between users and Microsoft's servers. When a user logged into Microsoft Office, the router captured the authentication token. This token, once stolen, could be replayed to gain access without needing the user's password. The hackers didn't need to deploy any malicious code—just exploit existing flaws in outdated hardware. **What should be done — mitigation and recommendations** First, update your router firmware immediately. If your router is end-of-life, replace it with a supported model. Enable automatic updates and disable remote management if not needed. Organizations should implement multi-factor authentication (MFA) that uses hardware tokens or biometrics, not just SMS codes. Monitor for unusual token usage patterns, such as logins from unexpected locations or devices. Microsoft recommends enabling token binding and using conditional access policies to limit token reuse. **Why this matters in the bigger cybersecurity landscape** This attack highlights a critical blind spot: old hardware. While companies focus on patching servers and endpoints, routers often remain neglected. They're the perfect entry point for stealthy, long-term espionage. The FCC's recent policy banning new consumer-grade routers from foreign adversaries may help, but it won't fix the millions of already-deployed devices. The lesson is clear: your network's weakest link might be the router you forgot about. And in the hands of state-backed hackers, that forgotten router becomes a silent spy.

Think grammar fuzzing is a silver bullet for finding bugs? Think again. A veteran security researcher just exposed a critical blind spot in mutational grammar fuzzing—the very technique that’s uncovered everything from browser XSLT flaws to JIT engine crashes. The dirty secret? More code coverage doesn’t always mean smarter fuzzing. If you’re relying on this approach without tweaking it, you might be missing the juiciest vulnerabilities. And the fix is surprisingly simple—but you’ll need to rethink how you measure “progress.”

**What exactly happened** A cybersecurity researcher—who’s used grammar fuzzing to find real-world bugs in web browsers and JIT engines—decided to pull back the curtain on why this technique sometimes fails. In a detailed analysis, they dissect the hidden flaws of mutational coverage-guided grammar fuzzing, the method where a fuzzer mutates inputs while keeping them grammatically valid. The core problem? The fuzzer gets stuck in a rut. It prioritizes samples that trigger new code coverage, but that doesn’t always lead to deeper bugs. The researcher calls this “coverage tunnel vision”—and it’s more common than you’d think. **Who is affected and how** Anyone using grammar fuzzing tools—from open-source projects to enterprise security teams—is at risk of false confidence. If you’re running a fuzzer with default settings, you might be generating thousands of “valid” inputs that only scratch the surface. The researcher notes this isn’t just a grammar fuzzing issue. Other structure-aware fuzzing techniques suffer from the same blind spots. So if you’re fuzzing anything with complex input formats (think XML parsers, compilers, or protocol handlers), pay attention. **The real-world impact and consequences** The biggest consequence? Missed vulnerabilities. The researcher explains that coverage-guided fuzzing can create a “bubble” where the fuzzer keeps mutating the same successful samples, never exploring truly novel paths. This means bugs that require unusual input combinations—like edge cases in XSLT transformations—slip through. In one example, the researcher found that libxslt bugs were discovered faster using a custom setup that broke the “coverage-only” rule. The default approach would have taken much longer, if it found them at all. **Technical breakdown (the “how” explained simply)** Here’s the mechanics: In coverage-guided grammar fuzzing, when a mutated input triggers new code paths, it’s saved to the corpus. Future mutations build on that sample. Sounds smart, right? But the researcher shows this creates a feedback loop where the fuzzer over-optimizes for coverage, ignoring other valuable traits like input diversity or structural novelty. The fix? A simple technique: periodically replace old samples with newer ones, even if coverage stays the same. This breaks the loop and forces the fuzzer to explore fresh territory. The researcher calls it “novelty-driven replacement”—and it’s surprisingly effective. **What should be done — mitigation and recommendations** First, don’t trust default settings. The researcher advises experimenting with different fuzzing configurations based on your target’s specific quirks. For grammar fuzzing, consider adding a “novelty score” that rewards inputs with unusual structures, not just new coverage. Second, implement periodic corpus refreshing. Even if coverage metrics look stable, swap out older samples to prevent stagnation. The researcher’s Jackalope fuzzer showed that this simple tweak uncovered libxslt bugs faster than the standard approach. Finally, monitor for “coverage plateaus.” If your fuzzer’s coverage stops growing but you’re still generating valid inputs, it’s a red flag. Time to shake things up. **Why this matters in the bigger cybersecurity landscape** This isn’t just a niche fuzzing quirk—it’s a wake-up call for automated testing. As software grows more complex, we rely on fuzzers to find the bugs we can’t. But if those fuzzers are stuck in a coverage-obsessed rut, we’re building a false sense of security. The researcher’s insight echoes a broader truth: tools are only as good as their assumptions. By exposing this blind spot, they’ve given defenders a simple but powerful way to level up their fuzzing game. And in a world where zero-days can cost millions, that’s a fix worth implementing today.

Microsoft just quietly patched a dangerous API flaw that let attackers hijack any application's process handle—and it had been broken for years. The GetProcessHandleFromHwnd API, designed as a simple helper function, turned out to be a backdoor for privilege escalation when used with UI Access applications like Quick Assist. If you're running Windows 10 or 11 (pre-24H2), your system could have been exploited by malware that already has limited access. The fix only arrived in the latest Windows 11 update, leaving millions of devices exposed until they update.

**What exactly happened** Security researchers discovered that the GetProcessHandleFromHwnd API—a Windows function meant to retrieve a process handle from a window handle—had a fundamental security flaw. Microsoft's own documentation claimed it used Windows hooks to work, but the actual implementation in Windows 11 was far more dangerous. The API directly opened process handles in kernel mode, bypassing standard security checks. This meant any application with UI Access privilege could grab a handle to any other process running under the same user account, regardless of integrity level. **Who is affected and how** The primary targets are Windows users running versions before 24H2, especially those using applications that request UI Access—like Quick Assist, certain accessibility tools, or enterprise software. Attackers who already have low-level access to a system can exploit this to elevate privileges. The real danger? Malware that compromises a standard user account can use this API to hijack higher-integrity processes, potentially gaining admin-level control without triggering alarms. **The real-world impact and consequences** This isn't theoretical. A publicly disclosed UAC bypass using Quick Assist demonstrated the exploit in action. Attackers could silently steal process handles, inject code, or monitor sensitive operations in privileged applications. For enterprises, this means any compromised workstation becomes a launchpad for lateral movement. The flaw undermines Windows' User Interface Privilege Isolation (UIPI) protections, which are supposed to prevent lower-integrity processes from manipulating higher-integrity ones. **Technical breakdown** The API's implementation in Win32k.sys (the kernel-mode graphics driver) directly calls `ObOpenObjectByPointer` to open process handles. It completely ignores the integrity level checks that UIPI normally enforces. Microsoft's documentation claimed the API used Windows hooks—which would require matching integrity levels. But the actual code just opens the process handle directly, then returns it to the caller. The only check? That both processes run under the same user account. No integrity level comparison, no protected process verification. **What should be done — mitigation and recommendations** First, update to Windows 11 24H2 immediately. Microsoft finally fixed this in the latest release, adding proper UIPI checks and removing the dangerous kernel-mode behavior. For those stuck on older versions, disable or restrict UI Access applications where possible. Monitor for unusual process handle requests, especially from low-integrity processes targeting high-integrity ones. Security teams should treat any unexpected use of `GetProcessHandleFromHwnd` as suspicious. **Why this matters in the bigger cybersecurity landscape** This flaw exposes a recurring theme in Windows security: documentation and implementation often diverge. Microsoft's own remarks about the API were "not completely true," as the researcher noted, and the kernel-mode shortcut bypassed protections that user-mode code would have enforced. The fix in 24H2 also signals a broader shift in Windows security architecture. Microsoft is finally making UIPI permanent and hardening kernel-mode APIs against privilege escalation. But the lesson remains: trust the code, not the docs.