Analysis Threats

This content announces the launch of the new Project Zero blog, highlighting past research posts on Windows exploitation techniques and zero-day vulnerabilities. It does not describe a specific vulnerability or active threat but rather serves as an informational update about ongoing research efforts.

This analysis examines the GetProcessHandleFromHwnd API in Windows, focusing on its implementation changes and security implications. Originally introduced in Windows Vista, the API attempts to obtain a handle to a process owning a specified window handle (HWND). Early versions used a windows hook technique to duplicate process handles, but modern Windows 11 implementations use a kernel-mode function to open process handles directly. The API's documented security properties contain inaccuracies, particularly regarding UIAccess requirements and user integrity levels. The analysis highlights that the API can be used in certain UAC bypass scenarios, such as with Quick Assist, even when processes run under different user contexts.

This analysis discusses the limitations of mutational grammar fuzzing, a technique that uses predefined grammars to mutate inputs while maintaining structural validity. The author highlights that increased code coverage does not necessarily correlate with finding more bugs, especially in complex language fuzzing scenarios where triggering bugs requires specific sequences of function calls. The analysis points out that coverage-guided fuzzers may struggle to combine multiple samples effectively to trigger such bugs, and that generative fuzzers might sometimes be more effective. The discussion is based on practical experience and examples from fuzzing XSLT implementations and JIT engines.

A significant portion of malware samples use direct IP communication to bypass DNS-based detection and controls. This technique allows command-and-control (C2) malware to evade traditional DNS monitoring defenses. The threat highlights the importance of enforcing zero trust policies at the IP level to secure networks against such evasive malware communications.

This report analyzes how threat actors are leveraging cloud-based AI applications such as Claude Code, CodeX, Cursor, and Gemini by collecting prompt logs from compromised endpoints. It provides a data-driven overview of adversaries weaponizing AI capabilities to aid their malicious activities. No specific software vulnerability or exploit details are provided. The threat is categorized as medium severity based on the observed adversary behavior.

For the latest discoveries in cyber research for the week of 27th July, please download our Threat Intelligence Bulletin. TOP ATTACKS AND BREACHES Minnesota IT Services has confirmed coordinated cyberattacks affecting more than 30 community water utilities across the state. The incidents briefly disrupted a treatment plant in Braham and affected industrial control systems. Officials reported […] The post 3rd August – Threat Intelligence Report appeared first on Check Point Research .

Tenable spent 30 days running frontier AI models against our own code. It didn’t just find bugs — it proved they’re real, with reproducible exploits. That fundamentally changes code security from ranking potential code defects to a much higher signal focused on the findings that matter. Read on to learn how it reshaped our security team's work, what it cost, and why your program is next. Key takeaways: Now code security starts with proof, not suspicions. Frontier AI instantly builds working exploits and proves which flaws are genuinely dangerous in your source code. Now remediations are confirmed issues, not just ranked lists of maybes. The durable asset is the harness, not the model. Frontier AI models get the attention, but the durable asset for security teams is the harness: the orchestration and systems around the model that turn suspected flaws into proven, reproducible exploits engineers can act on. Frontier AI doesn’t replace senior researchers; it makes one as productive as five. The scarce resource is still the expert who writes the threat model and judges what’s real. Buy the compute without funding that person, and you get a very fast way to generate findings no one can use. We’ve been running Claude Mythos Preview against our own code now for over 30 days, and one thing is crystal clear: Code security is fundamentally changing, and we believe there’s no turning back. At Tenable, our security team already had security testing agents that drove our applications, exercised API endpoints, and ran our predefined checks. But until recently, the agents couldn’t handle the harder part of code testing: finding previously unidentified flaws and proving their exploitability. As part of our work testing Anthropic’s Claude Mythos Preview for Project Glasswing , we built an agentic code security harness and powered it with this Anthropic frontier LLM, running it against our code and service repositories with pinned commits to ensure reproducible results. The work of code security is changing, but not in the way hype-driven blogs suggest. And certainly not for free. We’ve found the costs are measured in two currencies: dollars and senior-engineer hours. What follows is an account from the security practitioner’s perspective of Tenable’s internal security team and how we leveraged frontier AI: where the model proved its value, where it fell short, and what you should consider before investing further. From ranking guesses to ranking proof with frontier AI For well over a decade, the scarce resource for security teams was analyst attention. We built a whole discipline around it — reachability heuristics, exploitability guesswork, etc. — all to decide what a human security analyst should look at first in your own code. Now a frontier AI model in a harness collapses that. The ranking doesn’t go away, it gets a proof instead of a guess. When a finding arrives with a working exploit, you’re no longer ranking by how likely it is to matter; you’re ranking by what you’ve already proven does. When an LLM can surface a suspected flaw and drive a working exploit against a running build, the difficult question is no longer “which among the thousands of static findings deserves a human first?” It becomes “which of the code defects are real, and can we prove it?” A bug that shows up with a reproducible proof-of-concept sorts itself. One that can’t be reproduced goes to a validation queue. This does not mean fewer bugs. In fact, it means many more findings, especially early on, because the model surfaces threats and exposures in your source code that traditional tooling never would. Instead, what changes with frontier AI is that practically all of the bugs that reach a human analyst arrive pre-sorted by proof instead of by score. It becomes a short list of things you can already reproduce, plus a holding pen of candidates the harness is still chewing on. The model gets the headlines; the harness does the work This is not to say that the model doesn’t matter. It does, very much so. Claude Mythos Preview reads unfamiliar code and reasons about code abuse better than anything we’ve seen before. The harness acts as its orchestrator, guiding the model from finding to proving. We designed our harness to operate in a loop. The threat model feeds the harness context. It scopes a static pass to specific abuse cases in specific code paths. It drives targeted exploitation against a running build. It feeds the result back to confirm exploitability or kill a false positive. That live exploitation step is the furthest “shift left” we’ve dragged dynamic testing to date. This means the model doesn’t guess whether an injection fires; it fires at real targets and actively reads what comes back. Here’s the part that should decide where you spend your engineering time. The model underneath will change: a better one ships, pricing changes, a provider sunsets the endpoint you built against. If your program is a pile of clever prompts wired to one model, then every single one will require its own migration. But if your program is a harness that treats the model as an interchangeable component, then replacing it with any new or updated version of the model amounts to a simple config change and an afternoon of re-benchmarking. Now the harness is the asset for security teams. The model is a consumable. Blindly pointing coding agents at repos doesn’t work Every team starting out asks the same thing: “We already have a coding agent. Can’t we just tell it to scan our code and find bugs?” We tried exactly that before building anything. It’s the cheapest experiment and it would have been embarrassing to skip. It doesn’t hold up, and the reasons are structural. Prompting harder won’t help. Standard coding agents are engineered for linear pursuit, following a single hypothesis through to the end. Effective code security requires the inverse. It’s a broad, horizontal exercise that involves managing numerous concurrent theories, most of which will inevitably collapse. Direct an agent toward a complex service and it exhausts its context window mapping the architecture, leaving minimal capacity for the actual hunt. The harness earns its keep on three problems the model can’t solve alone: State: so a run that dies at hour six resumes instead of restarting, with the system remembering which paths it already cleared Parallelism with focus: so fifty narrow hunters each chew one attack class against one component and nobody drowns in context. Cross-repo reasoning: the vulnerable code and the entry point that reaches it each typically live in different services. The flaw sits in service A, while the reachable, attacker-controlled entry point can only be found three services upstream. No single repo session sees both — but it’s that very link that often separates a finding from a real, exploitable flaw. These are orchestration problems, and a prompt, however good, is not an orchestrator. Where frontier AI excels: low-severity noise, chained into real attacks The model takes primitives that read as low-severity noise on their own and stitches them into one exploit that matters. This is the work that used to separate a senior researcher from a code security tool, and it’s exactly the work that rots in a backlog when each piece gets triaged alone as “low.” Watching the frontier model chain those issues into a proven write primitive was the moment the frontier model stopped feeling like a better SAST tool and started feeling like a security researcher who never gets tired and never gets bored. The frontier model also prefers to run code over theorizing about it. Hand it a suspected flaw and it writes the triggering input, compiles in a scratch environment, runs it, reads the crash, and goes again. That loop closes the gap between “this looks exploitable” and “here is the input that exploits it.” Where the human is non-negotiable Everything downstream is driven by the threat model. The threat model must come from someone who understands the system from top to bottom. If you hand the frontier model a blank threat model, it produces confident, plausible, wrong output at machine speed. Hand it a sharp threat model and it comes back with findings your team can act on the same day. Garbage in, expensive noise out, and the noise is expensive precisely because it reads so well. The same researcher reads what the model surfaces, deciding what’s worth driving to a working exploit, triaging what comes back, and folding the lessons into the threat model so the next pass is more effective. The threat model isn’t a document you write once. It’s the living state where the entire agentic SDLC loop turns around. This researcher has to be the most senior person, not the most available one. The skill that used to go into manual testing now goes into threat modeling and reviewing. You’re changing what experts do all day and handing them a very fast, very literal apprentice to point at the work they’ve scoped. From proof to action: the gates before a human analyst Every candidate finding must clear the same gate before it reaches a human: Is there a reproducible proof-of-concept? Without one, it goes to the validation queue. With one, we walk it down a short list of questions that map to what the business actually cares about it: Reachable: If it can’t be hit from an untrusted, exposed entry point, it’s a backlog item, not live risk. Automatable: A reliable, low-skill, repeatable exploit jumps the queue; one that needs bespoke tailoring waits for the next planned release. Impact: Partial impact or a denial-of-service (DoS) attack sits in one tier; total control, arbitrary write, or remote-code execution (RCE) sits in another. Crown jewels: If it touches a critical asset or crosses a trust boundary, a major ticket becomes an emergency out-of-band patch. Figure 1: Agentic finding triage Budget for two things: compute and senior expertise The work is changing, but not for free, and the expense is m

Explore how passkey implementation gaps undermine security when relying parties fail to validate the User Verified flag, reducing MFA to a single factor. The post Pass the Passkey: A Novel Attack Surface in Passwordless Authentication appeared first on Unit 42 .

This detailed 2026 investigative briefing analyzes the surge in manufacturing cyber security breaches, highlighting real-world incidents at Mercedes-Benz and Coca-Cola Fairlife. It provides a technical breakdown of SCADA supply chain attack methods and prescribes a Zero-Trust defense architecture tailored for industrial environments, offering actionable mitigation strategies for defenders.

The article details a significant data breach at SplitVPN exposing 865,336 user emails, hashed passwords, and nearly 58 million connection logs, contradicting the provider's no-logs claim. It provides a verified scope of the leaked data, analyzes the privacy implications, and offers actionable mitigation steps for affected users and organizations.