Daily Digest

Germany just pulled back the curtain on one of the most wanted hackers in ransomware history. The BKA has officially named and shamed Daniil Maksimovich Shchukin, a 31-year-old Russian, as the mastermind behind the notorious ransomware gangs GandCrab and REvil. For years, he hid behind the handle "UNKN" while orchestrating attacks that paralyzed businesses and extracted millions. Now, his face is public, and the implications are massive for anyone who tracks cybercrime—or worries about being the next victim.

**What exactly happened** Germany’s Federal Criminal Police (BKA) dropped a bombshell advisory that finally unmasked the elusive hacker known as "UNKN." They identified him as Daniil Maksimovich Shchukin, a Russian national who ran both the GandCrab and REvil ransomware operations. The BKA linked Shchukin to at least 130 acts of computer sabotage and extortion across Germany between 2019 and 2021. He wasn’t alone—his accomplice, Anatoly Sergeevitsch Kravchuk, was also named in the same advisory. **Who is affected and how** The victims were primarily German businesses and organizations that got hit with double extortion tactics. Shchukin’s gangs demanded payment for decryption keys, then threatened to leak stolen data if victims didn’t pay up. The BKA says these attacks caused over 35 million euros in total economic damage. Shchukin and Kravchuk allegedly extorted nearly 2 million euros across two dozen separate cyberattacks. **The real-world impact and consequences** This isn’t just about Germany. REvil and GandCrab were global threats that pioneered the ransomware-as-a-service model. They made it easy for wannabe criminals to launch devastating attacks. Shchukin’s unmasking sends a clear signal: law enforcement is getting better at connecting digital handles to real people. A U.S. Justice Department filing from February 2023 even tied a crypto wallet containing over $317,000 to Shchukin’s activities. **Technical breakdown (explain the "how" simply)** GandCrab launched in January 2018 as an affiliate program. It paid hackers a cut of each ransom they collected, creating a massive incentive for cybercriminals to join. REvil evolved from GandCrab and introduced double extortion. Attackers would encrypt files, demand a ransom for the decryption key, then threaten to publish stolen data if the victim refused to pay. This made it much harder for companies to ignore the demands. **What should be done — mitigation and recommendations** For organizations, the playbook remains the same but more urgent. Back up critical data offline, patch systems religiously, and train employees to spot phishing attempts—the primary entry point for ransomware. Law enforcement agencies worldwide are now sharing intelligence faster. If you’re hit, report it immediately. The BKA’s success shows that collaboration between countries can crack even the most secretive cybercrime rings. **Why this matters in the bigger cybersecurity landscape** Unmasking UNKN is a huge win for transparency. It proves that no matter how clever the alias, digital footprints eventually lead back to real people. This also highlights the evolving nature of ransomware. GandCrab and REvil set the template for modern extortion, and their takedown doesn’t mean the threat is gone—it means the next generation of gangs is watching and adapting. The cat-and-mouse game continues, but for now, the good guys have scored a major point.

A ransomware strain just shot itself in the foot—and it's taking victims' data down with it. Researchers discovered that VECT 2.0 has a critical flaw in how it handles encryption keys for large files. Instead of locking your data for ransom, it's permanently destroying it. If you're hit by this buggy ransomware, paying the attackers won't help. Even they can't recover what's been wiped. The real victims? Any organization with files larger than 128KB—which is basically everyone.

**What exactly happened** Security researchers at Check Point uncovered a devastating flaw in VECT 2.0 ransomware. The malware's encryption mechanism contains a bug that turns it into a data wiper for any file larger than 128KB. Instead of encrypting files in a recoverable way, VECT 2.0 permanently destroys three-quarters of each large file. The last 25% remains technically recoverable, but that's useless without the rest. **Who is affected and how** VECT has been actively marketed on BreachForums, recruiting affiliates to deploy it. The operators even partnered with TeamPCP—the group behind supply-chain attacks on Trivy, LiteLLM, Telnyx, and the European Commission. Any organization that falls victim to these affiliates is at risk. But here's the kicker: the flaw affects Windows, Linux, and ESXi versions equally. No platform is safe from this self-sabotaging ransomware. **The real-world impact and consequences** Most valuable enterprise data lives in files larger than 128KB. We're talking VM disks, databases, backups, email mailboxes, spreadsheets, and routine documents. Check Point notes that "almost nothing a victim would care to recover" falls below that threshold. So when VECT 2.0 strikes, it's not holding your data hostage—it's destroying it. The worst part? Even if victims pay the ransom, the attackers can't decrypt the files. The nonces needed for recovery are gone forever, lost in the malware's own flawed logic. **Technical breakdown** VECT 2.0 splits large files into four chunks for faster encryption. Each chunk gets its own encryption nonce—a unique number required for decryption. But here's where it breaks: the malware uses a single memory buffer for all four nonces. Each new nonce overwrites the previous one. By the time encryption finishes, only the last nonce remains in memory. Only that final nonce gets written to disk. The other three are gone. Permanently. Even the attackers never received them. **What should be done** Organizations should immediately review their defenses against ransomware affiliates. VECT's distribution model means it could arrive via compromised supply chains or direct affiliate attacks. Maintain offline backups that can't be encrypted or wiped by ransomware. Test your recovery procedures regularly—because with VECT, there's no paying your way out. Monitor for indicators of VECT 2.0 activity, especially if you've been affected by recent TeamPCP supply-chain attacks. **Why this matters** This flaw exposes a fundamental truth about ransomware: it's software written by criminals, not engineers. Bugs happen, and when they do, victims pay the price—not just in ransom, but in permanently lost data. VECT 2.0 is a cautionary tale for the ransomware ecosystem. As attackers rush to deploy new variants, quality control is nonexistent. The result? A weapon that hurts its wielder as much as its target. For defenders, this is a rare bright spot. One less functional ransomware strain in the wild. But the lesson remains: never assume your data can be bought back.

A cybercrime group just weaponized a self-spreading worm to launch a wiper attack specifically targeting Iran. The malware doesn't just steal data—it actively destroys files on any system set to Iran's time zone or Farsi language. This isn't state-sponsored chaos. It's a financially motivated crew called TeamPCP trying to inject themselves into geopolitical tensions for profit. If your organization uses cloud services like Docker, Kubernetes, or Redis, you're in their crosshairs.

**What exactly happened** Over the weekend, security researchers detected a wiper campaign from TeamPCP—a relatively new cybercrime group that emerged in December 2025. Their worm, dubbed CanisterWorm, spreads through poorly secured cloud environments and wipes data on infected systems. The wiper activates only when it detects Iran's time zone or Farsi as the default language. This targeting suggests the group is deliberately inserting itself into the ongoing conflict between Iran and other nations. **Who is affected and how** TeamPCP initially compromised corporate cloud environments by targeting exposed Docker APIs, Kubernetes clusters, Redis servers, and the React2Shell vulnerability. Once inside, they move laterally through networks, stealing authentication credentials. According to security firm Flare, Azure accounts for 61% of their compromised servers, while AWS makes up 36%. That's 97% of their targets sitting on just two cloud platforms. **The real-world impact and consequences** This isn't just data theft. The wiper component destroys files, making recovery impossible without backups. For Iranian organizations—or any company with employees in Iran's time zone—this means potential operational paralysis. The extortion component adds another layer. Victims receive demands over Telegram, creating a double threat: pay up or lose your data permanently. **Technical breakdown** TeamPCP doesn't invent new exploits. They industrialize existing vulnerabilities into a self-propagating ecosystem. The worm spreads by scanning for exposed cloud control planes, then uses stolen credentials to jump between services. Flare's Assaf Morag described it perfectly: "The group industrializes existing vulnerabilities, misconfigurations, and recycled tooling into a cloud-native exploitation platform." **What should be done** Immediately audit your cloud configurations. Ensure Docker APIs, Kubernetes clusters, and Redis servers are not exposed to the internet without authentication. Apply patches for React2Shell and similar vulnerabilities. Monitor for unusual lateral movement in your cloud environments. TeamPCP relies on stolen credentials, so enforce multi-factor authentication everywhere possible. **Why this matters** This attack blurs the line between cybercrime and geopolitics. A financially motivated group is now willing to cause destructive damage for leverage. It signals a dangerous evolution in ransomware-style operations. If TeamPCP succeeds here, expect copycats. The playbook is simple: target cloud misconfigurations, add a wiper, and pick a geopolitical side to maximize pressure. Every organization using cloud infrastructure should take notice.

Three weeks ago, Microsoft quietly broke a core feature of Teams Free—and they’re only now telling us why. A backend change is skipping critical onboarding steps, leaving new users invisible to everyone else. If you’ve tried to chat or call someone on Teams Free lately and got silence, this is why. The bug affects individuals, families, and small groups relying on the free version for daily communication. Microsoft admits the fix is still in progress.

**What exactly happened** On April 8, Microsoft rolled out a backend change to Teams Free—the no-cost version for personal use, families, and community groups. But something went wrong. Instead of streamlining the experience, the update started skipping onboarding and privacy consent screens for new users. The result? Their profiles became incomplete, appearing as “Unknown users” to others. Microsoft flagged this as a “service degradation”—a label for issues that don’t take the service offline but still cause noticeable disruption. The company confirmed the problem in a service health update today, three weeks after the first reports surfaced. **Who is affected and how** Teams Free users who signed up during the impact window are the ones hit hardest. Their profiles are stuck in a ghost state—not searchable, not reachable, and unable to complete chat requests. This means they can’t be found by friends, family, or group members. They can’t initiate calls or receive them. For a communication tool, that’s a fundamental failure. Microsoft hasn’t yet disclosed which regions or how many users are impacted. But given Teams Free’s broad user base of individuals and small groups, the ripple effects could be significant. **The real-world impact and consequences** For personal users, this isn’t just an inconvenience—it’s a breakdown of trust. Imagine signing up for a free tool to stay connected with loved ones, only to become invisible. Small community groups relying on Teams Free for coordination are especially vulnerable. Missed calls, lost messages, and broken workflows can derail plans and erode confidence in the platform. Microsoft’s slow acknowledgment—three weeks after the first reports—adds to the frustration. Users were left wondering why their chats went dark, with no explanation until now. **Technical breakdown** The root cause is a “recently deployed backend change” that incorrectly treats new users as already onboarded. This skips the privacy consent screens and leaves profiles in an incomplete state. In technical terms, the user profile fails to register properly in the directory. That’s why affected users appear as “Unknown” and can’t be searched or reached. Microsoft’s engineering team is still working on a fix. They’ve scheduled another update later today, but no timeline for resolution has been given. **What should be done — mitigation and recommendations** For now, there’s no workaround for affected users. Microsoft recommends waiting for the backend fix to roll out. If you’re a Teams Free user and suspect you’re impacted, check your profile visibility. If others can’t find you, you’re likely in the bug’s crosshairs. For administrators or group leaders, consider alternative communication channels until the issue is resolved. This isn’t a security breach, but it’s a reliability failure. **Why this matters in the bigger cybersecurity landscape** This incident highlights a growing risk in modern software: backend changes can break core features without warning. For free services, users often have little recourse or visibility into fixes. It also underscores the importance of testing updates before deployment. A skipped consent screen might seem minor, but it can render a communication tool useless. As more people rely on free, cloud-based tools for personal and community use, providers must prioritize reliability. Trust is hard to earn and easy to lose—especially when a simple backend change goes wrong.

Russian military hackers just pulled off a 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 worldwide. This isn't just another data breach. It's a supply chain attack on trust itself—bypassing passwords and multifactor authentication entirely. If you're using an outdated router or work for a government agency, law firm, or email provider, your digital credentials could already be in enemy hands.

**What exactly happened** A Russian state-backed group known as Forest Blizzard—also called APT28 or Fancy Bear—exploited known vulnerabilities in aging Internet routers to silently harvest Microsoft Office authentication tokens. These tokens act like digital keys, allowing access to email, documents, and cloud services without needing a password. Microsoft confirmed over 200 organizations and 5,000 consumer devices were compromised. The hackers didn't break in—they simply waited for the doors to be left unlocked. **Who is affected and how** The primary targets were government agencies, including ministries of foreign affairs and law enforcement, plus third-party email providers. But the ripple effect is wider: any organization using unsupported or unpatched routers connected to Microsoft Office services was at risk. At the campaign's peak in December 2025, more than 18,000 routers were ensnared in the surveillance dragnet. Most were end-of-life devices or routers far behind on security updates—digital ghosts still running critical infrastructure. **The real-world impact and consequences** This isn't about stealing passwords. It's about stealing access. Once the hackers had authentication tokens, they could read emails, download attachments, and pivot to other systems without ever triggering an alarm. For the compromised organizations, this means sensitive diplomatic communications, law enforcement operations, and private legal strategies may have been exposed. The attack also demonstrates how state actors can weaponize neglected hardware to bypass even the strongest authentication protocols. **Technical breakdown (explain the "how" simply)** Forest Blizzard targeted routers with known, unpatched vulnerabilities—think old Cisco, D-Link, or TP-Link models no longer receiving security updates. By exploiting these flaws, they gained control of the routers themselves. Once inside, they didn't deploy malware. Instead, they intercepted network traffic flowing through the router, capturing authentication tokens sent between users and Microsoft's servers. These tokens, meant to prove identity without constant password entry, were then forwarded to Russian-controlled servers. The beauty—and danger—of this method is its simplicity. No malicious code on the victim's device. No suspicious files. Just a compromised router silently copying data as it passed through. **What should be done — mitigation and recommendations** First, inventory your network. Identify every router, especially older models, and check their support status. If a device is end-of-life, replace it immediately—no exceptions. Second, enforce strict firmware update policies. Many routers in this attack were years behind on patches. Automate updates where possible, and disable remote management features if not absolutely necessary. Third, implement token expiration and rotation policies. Microsoft recommends shortening token lifetimes and using conditional access policies to limit where tokens can be used. If a token is stolen, it should expire before it can be exploited. Finally, monitor for unusual authentication patterns. Sudden logins from unexpected IP addresses or devices should trigger immediate investigation. **Why this matters in the bigger cybersecurity landscape** This attack reveals a fundamental shift in how state-sponsored hackers operate. They're moving away from flashy exploits and toward invisible, infrastructure-level attacks that leave no trace on the endpoint. The reliance on outdated routers is particularly alarming. These devices are everywhere—in homes, small businesses, government offices—and often forgotten once installed. They represent a massive, unpatched attack surface that adversaries are increasingly eager to exploit. The FCC's recent policy requiring new consumer routers to be manufactured in the U.S. may help in the long term, but it won't protect the millions of vulnerable devices already in use. The lesson is clear: your network is only as secure as its oldest, most neglected component.

Fuzzing is a powerful tool for finding bugs, but even the smartest fuzzing techniques have hidden blind spots that can leave critical vulnerabilities undiscovered. A veteran security researcher has exposed a major flaw in mutational grammar fuzzing—a technique used to hunt bugs in everything from web browsers to JIT engines. The issue? More code coverage doesn't always mean you're finding more bugs. If you're running fuzzers without understanding these limitations, you might be wasting compute cycles and missing real threats. Here's what you need to know.

**What Exactly Happened** A cybersecurity researcher who has successfully used mutational grammar fuzzing to find bugs in XSLT implementations and JIT engines has publicly dissected the technique's hidden weaknesses. The core issue is counterintuitive: coverage-guided grammar fuzzing can actually become *less effective* over time, even as it appears to be working perfectly. The researcher explains that the very mechanism designed to find new bugs—saving samples that trigger new code coverage—can create a trap that limits discovery. **Who Is Affected and How** This affects anyone using grammar fuzzing tools like Jackalope, or any structure-aware fuzzer that relies on predefined grammars and coverage feedback. Security teams running fuzzing campaigns on parsers, compilers, interpreters, or any software that processes structured input should pay close attention. The flaws are not implementation-specific, meaning they apply across different fuzzing frameworks and tools. **The Real-World Impact and Consequences** The most dangerous consequence is a false sense of security. A fuzzer might show impressive coverage numbers while missing entire classes of bugs. The researcher notes that this technique has found complex issues in the past, but the flaws mean it could miss equally critical vulnerabilities that require different mutation strategies. For organizations relying on fuzzing as part of their security testing, this could mean deploying software with undiscovered vulnerabilities. **Technical Breakdown: The "How" Explained Simply** Mutational grammar fuzzing works by taking valid samples and mutating them while keeping them grammatically correct. Coverage-guided versions save samples that trigger new code paths. Issue #1: More coverage doesn't mean more bugs. The fuzzer can get stuck exploring deep but narrow code paths while ignoring shallow but buggy ones. Issue #2: The sample corpus becomes stale. Old samples get reused repeatedly, and the fuzzer stops exploring new regions of the input space. Issue #3: Grammar constraints can be too restrictive. By always maintaining valid structure, the fuzzer misses malformed inputs that could trigger edge-case bugs. The researcher's counter-technique is elegantly simple: periodically inject completely random mutations that break grammar rules, then let the coverage guide decide if they're worth keeping. **What Should Be Done: Mitigation and Recommendations** First, don't trust coverage numbers alone. High coverage doesn't guarantee thorough bug discovery. Second, experiment with different fuzzing setups. The researcher found that mixing grammar-aware mutations with random ones discovered bugs in libxslt faster than default settings. Third, consider adding novelty-seeking strategies. Replace old samples with newer ones even when coverage doesn't change. Fourth, use multiple fuzzing approaches in parallel. Don't rely on a single technique or tool. **Why This Matters in the Bigger Cybersecurity Landscape** This research highlights a fundamental truth in security testing: no single technique is a silver bullet. As fuzzing becomes more automated and integrated into CI/CD pipelines, understanding these limitations becomes critical for security teams. The researcher's work also shows that sometimes the most effective solutions are simple and counterintuitive—breaking the rules can find bugs that following them never will. For defenders, this is a reminder to question assumptions, experiment with configurations, and never let impressive metrics create false confidence.

Microsoft’s GetProcessHandleFromHwnd API has been hiding a dangerous secret for years. This little-known function, designed to help UI automation tools grab process handles, was actually handing attackers a golden ticket to bypass security controls. The flaw lets any process with UI Access—even low-integrity ones—steal a full-access handle to any same-user process. That means malware can hijack privileged apps, inject code, or steal data without triggering alarms. If you’re running Windows 11 before 24H2, your system is wide open.

**What exactly happened** Security researchers uncovered a critical flaw in the GetProcessHandleFromHwnd API, a Windows function that lets apps grab a process handle from a window handle (HWND). The API was supposed to be restricted to UI Access (UIAccess) applications, but the implementation was broken from the start. The documentation claimed the API used Windows hooks to inject code and retrieve handles. In reality, Windows 11’s kernel-mode implementation simply opened the target process directly—no hooks, no injection. And crucially, it forgot to check for protected processes or enforce proper integrity levels. **Who is affected and how** Every Windows 11 user before the 24H2 update is at risk. The flaw specifically impacts systems where any process runs with UIAccess privileges—common in accessibility tools, remote assistance apps like Quick Assist, and enterprise software. Attackers can exploit this by first gaining low-level access (e.g., through a phishing link or malicious download). Once inside, they use the API to steal a handle to a higher-privileged process running as the same user. That handle grants full access: read memory, inject code, or even spawn new processes with elevated rights. **The real-world impact and consequences** This isn’t just a theoretical bug. Researchers demonstrated a working UAC bypass using Quick Assist’s UIAccess process. The attack chain is simple: a standard user process calls GetProcessHandleFromHwnd, gets a handle to the UIAccess process, then uses that handle to launch a command prompt with admin privileges—no UAC prompt, no user consent. The consequences are severe. Malware can silently escalate privileges, steal credentials from browser processes, or modify system settings. Since the API works across all same-user processes, even antivirus tools and security software are vulnerable if they run under the same user account. **Technical breakdown (explain the "how" simply)** The API’s implementation in Windows 11 (before 24H2) is a kernel-mode function that directly opens the target process. It checks two things: that the caller has UIAccess, and that both processes run as the same user. But it never verifies the caller’s integrity level. UIAccess processes typically run at high integrity, but any process with UIAccess—even medium integrity—can call the API. The function then returns a handle with PROCESS_ALL_ACCESS rights, bypassing User Interface Privilege Isolation (UIPI) that normally blocks lower-integrity processes from accessing higher-integrity ones. The fix in Windows 11 24H2 adds proper integrity level checks and blocks access to protected processes (like antivirus or Windows Defender). The API now only works when the caller has equal or higher integrity than the target. **What should be done — mitigation and recommendations** For most users, the only fix is to update to Windows 11 24H2 or later. Microsoft has patched the vulnerability in this version, making the API safe again. If you can’t update immediately, consider these workarounds: - Disable UIAccess for non-essential applications (check app manifests) - Use AppLocker or WDAC to restrict which processes can have UIAccess - Monitor for unusual calls to GetProcessHandleFromHwnd using Sysmon or EDR tools Enterprise admins should audit all UIAccess-enabled applications and review their security posture. Quick Assist and similar tools should be restricted to authorized users only. **Why this matters in the bigger cybersecurity landscape** This flaw highlights a recurring problem in Windows security: APIs designed for convenience often bypass security boundaries. The GetProcessHandleFromHwnd API was meant to simplify UI automation, but its broken implementation created a backdoor for privilege escalation. The fact that it went unnoticed for years—and that the documentation was misleading—shows how even well-known APIs can hide dangerous assumptions. As Windows continues to evolve, security researchers and Microsoft must work together to audit every “convenience” feature for hidden risks. The lesson is clear: trust no API, verify every boundary, and always question the documentation. In cybersecurity, the smallest oversight can become the biggest vulnerability.