Unit 42 explores The Gentlemen ransomware operations, revealing the affiliate model driving its rapid growth. Learn more here.

The post No Manners Here: The Ruthless Rise of The Gentlemen Ransomware appeared first on Unit 42.

The conversation around AI-powered threats has focused heavily on the attacker side. What models can do, what vulnerabilities they can find, how fast they can chain exploits together. But the more important question for security practitioners is simpler and harder. Is your detection posture ready for what’s already happening?

AI has lowered the barrier to entry for sophisticated attacks. Threat actors don’t need to be experts to leverage LLMs for obfuscation, exploit development, or chaining attack steps that previously required deep manual skill. The speed and volume of attacks is increasing as a result. Detection engineering is part of how defenders respond. And most organizations are further behind than they realize, especially because many detection engineering programs live in their own siloed “ivory tower”, detached from the realities of what SOC analysts are handling. 

At Intezer, AI-powered detection engineering runs as part of a closed loop with automated, forensic triage and investigation. Every alert investigated across the environment feeds new signal back into detection logic, so coverage improves continuously instead of drifting between quarterly tuning cycles. Detection working in concert with triage and investigation is what a fully optimized security environment looks like against AI-powered attackers.

In this article, we’ll focus on how to improve detection engineering practices in general. 

Why your current detection posture isn’t keeping pace

The fundamental problem is that most detection programs were built for a world where attack volume was bounded by attacker expertise. That constraint is being removed. LLM-augmented attacks can move faster, produce more permutations, and adapt more readily to your environment than traditional campaigns. A detection posture built on static indicators and periodic tuning cycles can’t keep up.

There are three places this shows up in practice.

Covering one sub-technique doesn’t cover the technique

First, most organizations are only covering technique-level MITRE ATT&CK mappings, not sub-techniques. When you claim T1059 is covered because you have a rule for T1059.001, you’re exposing yourself to real risk hiding beneath that coverage number. Sub-techniques carry distinct behaviors that may exist in your environment and go completely undetected. High-level coverage scores look good in reports and obscure what’s actually happening. The risk lives at the sub-technique level.

IOCs are brittle indicators 

Second, IOC-based detections are becoming a liability at scale. IP addresses, file hashes, domains are valuable in incident response but brittle as primary detection logic. Their half-life is short, adversaries burn them readily, and maintaining a large list of active IOCs creates noise without proportionate signal. Organizations that lead with IOCs end up toggling rules on and off constantly, adding friction without improving coverage. The maintenance cost compounds without a meaningful security return.

Pulling logs is not the same as pulling useful logs

Third, telemetry that looks healthy often isn’t. A Windows Event ID 4688 without command-line logging enabled is an example. You’re paying to ingest it, it shows up in your coverage maps, but it provides no actionable data when something fires. Unmapped or broken telemetry creates the appearance of coverage where none actually exists. Before you write a new rule, validate that the data it depends on actually contains what you think it does.

What behavioral detection actually means in practice

Behavioral detections are built around what attackers do across a campaign, not what artifacts they happened to leave behind in a specific incident. Techniques, sequences, tool patterns, execution chains persist across campaigns, across threat actors, and even across malware families. A behavioral detection written well today has a much longer useful life than any IOC-based rule.

The shift to behavioral detection isn’t just a philosophy, it requires specific changes to how rules are built and maintained.

Score based detection

Score-based detection logic is one of the most underused approaches in enterprise SIEMs. If you’re running Splunk, Sumo Logic, or Cortex XDR, score-based rules let you assign weighted values to individual signals and alert when combinations cross a threshold. Individual signals that are weak in isolation, a process executing from an unusual path, a network connection to an uncommon destination, a scheduled task created outside business hours, become meaningful together. Noise goes down. True positive rate goes up. And the system stays tunable as your environment changes.

Permutation testing

Permutation testing is the other discipline most detection programs skip. LLMs make it straightforward to generate attack variants at volume. Defenders should be doing the same before releasing rules. If a detection rule only catches one specific implementation of a technique, an attacker using a slightly different toolchain or execution order will evade it. Testing rules against a range of permutations before production deployment closes gaps that post-deployment tuning will miss.

The detection engineering cycle has to get faster

The traditional cycle, write a rule, deploy it, wait for something to fire, tune reactively when it generates too many false positives, is too slow for the current threat environment. By the time you’ve finished tuning a rule for last quarter’s threat, new attack patterns are already in the wild.

The cycle needs to compress at every stage. Prototype rules should be tested in isolated environments before they reach production. Sandboxes and virtual machines can be spun up quickly in the same pipeline as rule development, giving you a controlled validation environment. Rules that are tuned before deployment don’t flood the SOC on their first day, and analysts who aren’t buried in false positives from new rules are analysts who can actually investigate real threats.

Continuous monitoring closes the loop. Every alert that fires, every verdict and every outcome feeds information back into the detection posture. Which rules are generating signal? Which ones are generating noise? Where are the coverage gaps that no existing rule addresses? Without this feedback loop, detection engineering becomes a periodic exercise rather than a continuously improving system.

A well integrated feedback loop investigates every single alert a detection creates, resolves false positives from critically important detections while continuously tuning the behavioral model to secure your organization and security detection pipeline.

Coverage benchmarks worth using

Coverage benchmarks help set realistic expectations and give teams a concrete target. Based on what we see across enterprise environments:

• Less than 30% MITRE ATT&CK coverage is immature. Organizations in this range typically have out-of-the-box rules, minimal customization, and significant gaps across Initial Access, Execution, and Lateral Movement.
• 30 to 45% represents a decent in-house SOC. Rules exist, there’s some customization, but detection engineering is not a dedicated discipline and tuning is reactive.
• 45 to 60% is strong. Dedicated attention to detection posture, some behavioral logic, and active management of the detection lifecycle.
• 60 to 70% is top-tier. Behavioral detection is primary, coverage is continuously maintained, and the feedback loop between investigation and detection is functioning.

Anything above 70% is usually inflated. Scores at this level typically reflect mapping sprawl across multiple MITRE versions, technique-level claims that obscure sub-technique gaps, or rules that are mapped but broken. Validate the underlying data before trusting the number.

The goal isn’t 100% coverage. That number isn’t achievable or meaningful. The goal is systematic, maintainable coverage of the techniques most relevant to your environment and your crown jewels, with the sub-technique depth to catch how those techniques are actually executed.

How AI changes things for attackers and defenders

Mythos focused attention on a specific capability and that is autonomous chaining of exploit steps that previously required human guidance at each stage. A skilled researcher can still walk an LLM through finding a vulnerability, reaching exploit code, and overtaking an instruction pointer, but that process requires human direction at each transition. What makes autonomous chaining meaningful is that it removes the human from the loop on the attacker side.

The detection engineering response isn’t a new category of rule. It’s the same disciplines applied with more rigor and at higher speed. Attackers using LLMs are still executing against endpoints, still writing to disk or running in memory, still making network connections, still creating processes. The behaviors are recognizable. What changes is the volume of variants and the speed at which new campaigns emerge.

Score-based logic handles volume well because it doesn’t require a rule per variant. Permutation testing handles new variants better than reactive tuning because gaps are found before deployment rather than after. Behavioral coverage handles campaign evolution better than IOC maintenance because the underlying techniques persist even as the tooling changes.

This is where an integrated model matters most. AI-powered detection engineering delivers the most value when it doesn’t operate in isolation, and at Intezer it runs on the same loop as automated triage and investigation. The platform investigates 100% of alerts across endpoint, identity, cloud, network, and SIEM, and every verdict feeds directly back into detection, surfacing noisy rules, broken telemetry, and coverage gaps as they happen rather than at the next review. Detection, triage, and investigation reinforcing one another is what produces a fully optimized security environment, one that keeps pace as attacker AI accelerates.

The organizations that fare best against AI-powered threats will be the ones that already had a functioning detection engineering program, one built on behavioral logic, continuous feedback, and validated telemetry, before the threat landscape changed. Catching up under pressure is possible, but it’s harder and slower than building the discipline now.

The attacker’s AI is getting faster. The detection engineering cycle should be too.

Learn more about Intezer’s AI-powered detection engineering.

The post Detection engineering in the AI era appeared first on Intezer.

A cybercrime campaign combined a loader-as-a-service framework and DLL sideloading via a Go-compiled fake MpClient.dll, a novel evasion layer combination.

The post Vidar Stealer Unmasked: Code Signing Abuse, Go Loaders and File Inflation appeared first on Unit 42.

Blogs

Blog

AI, Trust, and the Future of Threat Intelligence

In this post, we explore how AI is reshaping cyber threat intelligence and why governance, transparency, and trust are becoming increasingly important as organizations rely more heavily on AI-generated insights and autonomous capabilities.

SHARE THIS:

Flashpoint

July 7, 2026

Table Of Contents

Table of Contents

Trust Has Always Been the Foundation of Threat Intelligence

Governance Is Becoming a Core Requirement

AI Changes the Scale (and Reaps the Context) of Intelligence Operations

What Security Leaders Should Be Evaluating

Looking Ahead

Gartner Disclaimer

More

Flashpoint Named A Challenger in 2026 Gartner MQ

See Report

Artificial intelligence has quickly become embedded across cyber threat intelligence workflows.

Throughout research and analysis, enrichment, prioritization, and operational response, AI is helping organizations process large volumes of information and move more quickly from collection to action. As these capabilities mature, the conversation is moving beyond what AI can do, toward how organizations can trust, validate, and govern AI-generated intelligence.

Flashpoint has been recognized in the 2026 Gartner® Top 5 Vendors for AI Capabilities in Cyberthreat Intelligence Technologies: Governance & Trust research. Flashpoint was also named a Challenger in the 2026 inaugural Gartner Magic Quadrant for Cyberthreat Intelligence Technologies. The report recognizes five top vendors, including Flashpoint, across AI foundational elements within CTI and examines the governance, oversight, and trust mechanisms that help organizations use AI responsibly within intelligence operations.

Gartner notes in the report that “as organizations increasingly depend on autonomous agents from CTI vendors, the need for robust governance and trust frameworks has become critical.”

Trust Has Always Been the Foundation of Threat Intelligence

For intelligence teams, trust is not a new concept.

Analysts regularly evaluate the credibility of sources, validate claims, assess confidence levels, and determine whether reporting is relevant to their organization’s mission. The quality of intelligence has never been determined solely by how much information is available. It depends on whether that information is precise, timely, and accurate enough to move the needle and safely drive an operational decision.

AI, however, introduces a new layer to that process.

Organizations are increasingly leveraging AI to assist with enrichment, summarization, prioritization, and analysis. Those capabilities can accelerate workflows significantly, but they also introduce new questions. 

• How was a recommendation generated? 
• What evidence informed it? 
• How confident should an analyst be in the result? 
• What safeguards exist when the output is used to drive operational decisions?

Ultimately, these are questions of operational risk and data integrity, not just technology features. Analysts must be able to interrogate a system’s reasoning just as they would any other source.

Governance Is Becoming a Core Requirement

Establishing analytical trust is essential, but it requires strict operational guardrails to function safely at scale. This is where governance moves from an item on a checklist to a core requirement.

Many of the conversations around AI in cybersecurity focus on capability. 

• Can an AI system summarize faster? 
• Can it identify relationships that would otherwise be missed? 
• Can it reduce analyst workload?

While speed and scale are essential, they only tell half the story. As organizations move AI closer to daily operational workflows, a second, more critical set of questions is emerging centering around control.

As Gartner explains, “Agent governance and trust ensures that only authorized users and agents can access and manage sensitive threat data through role-based permissions and approval workflows.”

From our experience, by implementing these structural protections — alongside comprehensive audit logging — security leaders can ensure that AI-driven actions remain fully transparent, secure, and accountable. Governance isn’t about slowing down automation; it’s about establishing the administrative guardrails that dictate exactly who—and what—is allowed to execute a sensitive operation within the enterprise. 

This oversight is becoming a foundational necessity as threat intelligence breaks out of traditional security silos. Because CTI increasingly informs vulnerability management, fraud investigations, executive protection, security operations, and enterprise risk programs, the downstream impact of an inaccurate recommendation can disrupt an entire enterprise. This underscores the importance of understanding not only what an AI system recommends but also how it arrived at that recommendation in the first place.

AI Changes the Scale (and Reaps the Context) of Intelligence Operations

One area where AI has a massive, immediate impact is scale.

Threat intelligence teams today are completely inundated with data. Malicious activity spans encrypted messaging platforms, illicit criminal marketplaces, forums, social media, vulnerability disclosures, and vast streams of infrastructure telemetry. Even the most mature, well-resourced teams struggle to manually ingest and process this sheer volume of information.

When applied appropriately, AI elegantly solves this bottleneck. Automation acts as an incredible force multiplier — accelerating time-consuming foundational tasks like research, cross-language translation, data enrichment, summarization, clustering, and correlation. Large language models can process information at scale, reducing the manual effort required to move from collection to analysis.

The critical challenge, however, is ensuring that this massive injection of speed does not come at the expense of context.

Threat intelligence is fundamentally a contextual discipline. A standalone indicator, isolated vulnerability, or single threat actor reference rarely carries meaning on its own. To act safely, analysts must understand exactly where information originated, who is discussing it, how widely it is being shared, and how it relates to broader activity across the threat landscape.

What AI cannot do independently is establish that context. While machines are exceptionally effective at identifying patterns across vast datasets, they inherently lack source validation, analytical rigor, and nuanced judgment. If an AI accelerates the data pipeline but strips away the underlying context, assessing confidence becomes impossible, making informed decision-making even harder.

This is why Flashpoint champions a “human-led, AI-scaled” model. True scalability isn’t about replacing analysts with autonomous bots; it’s about using machines to conquer the overwhelming noise of the threat landscape while keeping the resulting intelligence heavily grounded in expert-reviewed sources. As AI capabilities continue to mature, context becomes more important, not less. The organizations that derive the most value from automation will be those that pair machine-scale processing with human-in-the-loop review to ensure every output can be validated, contextualized, and confidently acted upon.

What Security Leaders Should Be Evaluating

As AI becomes a larger component of cyber threat intelligence platforms, security leaders have an opportunity to evaluate these capabilities through a broader lens than automation alone.

The Gartner report provides a useful framework for thinking about these questions, particularly around governance and trust. Rather than focusing exclusively on what an AI system can do, Flashpoint recommends that organizations rigorously evaluate how those capabilities are managed, validated, and controlled. 

Some of the most important areas to evaluate include:

Explainability

Question to ask: Can analysts trace how an AI-generated recommendation or conclusion was produced?

The ability to review supporting evidence, understand contributing factors, and see outputs back to underlying intelligence sources is becoming increasingly important as AI is used to support operational decisions.

Confidence and Validation

Question to ask: How does the platform communicate confidence in AI-generated outputs?

Threat intelligence has always relied on confidence assessments. As AI-generated insights become more common, organizations should look for configurable confidence thresholds that allow them to tailor automated actions to their corporate risk tolerance.

Governance and Oversight

Question to ask: What controls exist around the use of AI?

Capabilities such as role-based permissions, approval workflows, and audit logging are critical governance mechanisms for organizations seeking to maintain accountability and trust in AI-driven processes.

Operational Impact

Question to ask: How does AI improve intelligence workflows in practice?

The most valuable AI capabilities are often those that help analysts spend less time on repetitive tasks and more time on investigation, analysis, and decision-making. Understanding where AI fits into the intelligence lifecycle can help organizations distinguish between meaningful operational improvements and isolated feature enhancements.

Looking Ahead

The conversation around AI in threat intelligence is still evolving, but the direction of travel is becoming increasingly clear. Organizations are looking beyond standalone AI features and placing greater emphasis on governance, transparency, and accountability.

Taken together with broader industry trends, this points to a threat intelligence market that is becoming increasingly sophisticated. Organizations are evaluating not only the quality and uniqueness of intelligence itself, but also how that intelligence is operationalized, how AI is applied, and how trust is maintained throughout the process.

We believe that shift reflects the realities of modern intelligence work. Speed and scale remain important, but neither replaces the need for context, validation, and informed decision-making.

For security leaders evaluating AI capabilities within cyber threat intelligence platforms, Gartner’s research offers valuable insight into how the market is evolving and what requirements are likely to become increasingly important in the years ahead.

Gartner subscribers can read the full report to explore the governance, trust, and AI capability trends shaping the future of cyber threat intelligence.

Gartner Disclaimer

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose. 

Gartner, Top 5 Vendors for AI Capabilities in Cyberthreat Intelligence Technologies: Governance & Trust, Jonathan Nunez, Jaime Anderson, June 15, 2026.

Gartner, Magic Quadrant for Cyber Threat Intelligence Technologies, Jonathan Nunez, Carlos De Sola Caraballo, Jaime Anderson, May 4, 2026.

Gartner and Magic Quadrant are trademarks of Gartner, Inc., and/or its affiliates.

The post AI, Trust, and the Future of Threat Intelligence appeared first on Flashpoint.

A look inside the reverse-engineering journey of building the first RDP client outside of Windows to support WebAuthn redirection.

The post How We Added WebAuthn to a Browser-Based RDP Client appeared first on Unit 42.

Blogs

Blog

Remus Stealer: A New, Not-So-New Infostealer

In this post, we explore the emergence of Remus Stealer, analyzing its structural and behavioral similarities to the infamous Lumma malware.

SHARE THIS:

Flashpoint Intel Team

July 2, 2026

Table Of Contents

Table of Contents

What We Know About Remus

Similarities to Lumma

Differentiators of Remus

Protect Against Infostealers Using Flashpoint

More

subscribe to our newsletter

The underground marketplace rarely stays quiet for long. A new information-stealing malware dubbed Remus Stealer has surfaced in the cybercrime underground, exhibiting significant similarities to the notorious Lumma malware family across its administration panel, stolen log files, and core code structure.

Despite parallels in its code and functionality, threat actors are eagerly buying into the platform. In addition to its familiar features, it provides attackers with a distinct, modern command and control (C2) and networking infrastructure designed to slip past current security perimeters.

What We Know About Remus

Flashpoint first observed Remus appearing for sale within illicit communities in March 2026. The malware listing offers similar functionality to other popular Malware-as-a-Service (MaaS) offerings, including Google OAuth cookie restoration and Telegram channel integration for logs.

Much like the Lumma malware family, the Remus subscription service operates on a three-tiered access model:

• Basic: US$250
• Pro: US$500
• Enterprise: US$1,000

At this time, Remus has no additional channels or automated bots associated with its sale or distribution. Despite undeniable similarities to Lumma, its developer claims to not be a rebrand of the Lumma project.

Since March 2026, Remus has continued its operations mostly unhindered by negative associations associated with Lumma—particularly the doxxing of its panel in August 2025.

Similarities to Lumma

Similarities can be observed in the Remus and Lumma panels in both aesthetics and functionality. Both panels use similar assets for tab icons and have embedded advertisements for other illicit services such as packers and log clouds. Harvested logs also share extremely similar directory structures in log files, including unique identifiers.

Code-Level Overlaps

Remus is a 64-bit compiled binary, and Lumma was a 32-bit binary. However, major similarities between the code bases of both malware can be observed.

Upon execution of an unpacked sample, both Remus and Lumma will send warning messages to the user that the build is unpacked. This was a unique phenomenon first established by Lumma several years ago. In both Remus and Lumma samples, the pack check and window message are performed before the main functionality of the malware.

In both Remus and Lumma, a function is used first to check if the sample is packed, and a second function is used to send the window error message.

Remus uses similar string obfuscation methods to Lumma, in which each string has been uniquely encoded and then decoded during runtime. Deobfuscation occurs by looping byte by byte through encoded blobs. Each encoded string is obfuscated by a unique pattern. This can be seen in the code samples below:

Of note, both samples have at least one NOP instruction between the encoded blob being moved onto the stack and the deobfuscation loop.

Another unique feature of Lumma is the presence of a plaintext identifier string used to link customers to specific build generations. In Lumma, this string was referred to as the LID (Lumma ID), and this ID method appears in Remus as well as a “tag.”

Like the Lumma LID string, the Remus tag could be leveraged to attribute variant builds and campaigns to single threat actors or groups.

Additionally, both Remus and Lumma exhibit similar control flow obfuscation by replacing direct jumps with indirect jumps read from offsets that have been moved onto the stack, jumps computed from a jump table, and jumps resolved by a pointer.

Differentiators of Remus

Although Remus bears remarkable similarities to Lumma, its main differences lie in its C2 beaconing.

Before performing main stealer functionality, Remus will beacon out to its C2 infrastructure. It will attempt to resolve several domain:port combinations via POST requests, and attempt a final connection to find the C2 server using EtherHiding. If it is unable to connect, the malware will terminate.

After a connection is established, the stealer sends a POST request to the C2 in order to receive an access token. Once received and decoded, this access token is used to receive encrypted config data used by Remus to target assets on the victim system. Data collected for logs is then exfiltrated as encrypted POST data.

Protect Against Infostealers Using Flashpoint

Remus stealer represents a sophisticated continuation of the MaaS infostealer model left behind by Lumma’s collapse. While the developer asserts independence, the overwhelming code overlaps, matching obfuscation techniques, and administrative panels indicate that Remus is either heavily inspired by, or derived from the Lumma codebase. These traits have allowed it to thrive, providing threat actors with a familiar, robust alternative that sidesteps the reputational baggage and law enforcement scrutiny of its predecessors.

Flashpoint continuously tracks the latest developments in illicit communities, hard-to-reach adversary spaces, and malware repositories to identify emerging threats. Request a demo to learn how Flashpoint’s primary source collections and analyst insights empowers your security teams.

The post Remus Stealer: A New, Not-So-New Infostealer appeared first on Flashpoint.

For 15 years (!), many of us who have touched cloud security have struggled with the shared responsibility model for cloud security. As with many “cyber things,” the theory is simple. Multiple vendors, consulting firms, and industry bodies have published deceptively clear matrices that depict exactly who is doing what for cloud security.

Everyone likes to present trivial cases: for example, the cloud provider is entirely responsible for the physical security of the data center, while the client is responsible for the application they just built and deployed within that cloud provider’s IaaS. In reality, many of the edge cases continue to cause pain to a lot of organizations.

Ok, so none of this is fundamentally new. However, in recent years, similar and more complex - dare I say sinister?- questions have emerged: What does shared responsibility look like for AI security?

Those who haven’t studied this topic in depth might assume there is no difference. Yet, there are fascinating, critical differences between shared responsibility for AI security and traditional cloud security, along with older related challenges like the shared security of outsourcing (that predate cloud).

Add AI with its probabilistic behaviors, untrusted user inputs, and nested vendor dependencies -and that finger-pointing cycle doesn’t just continue, it scales exponentially. When a customer-facing chatbot goes off the rails, the model provider blames your prompt engineering, the platform provider claims infrastructure isolation worked perfectly, and your internal application team swears it’s an upstream model limitation…

Put simply, what are the top 3 differences between shared responsibility for AI vs cloud? In my opinion:

1. A Broader Spectrum of Risk: The range of harms and risks we must consider is much wider. Shared responsibility for AI security frequently touches upon safety, privacy, ethical use, and the unique risk surfaces that emerge specifically in conversations about AI.
2. The Multi-Party Supply Chain: AI security is typically far more multi-party than traditional cloud security. For instance, one company builds the foundational model, another company fine-tunes it, a third party builds a Retrieval-Augmented Generation (RAG) architecture for you, and yet another party builds the consumer-facing application.
3. Non-deterministic Behavior: Unlike traditional cloud infrastructure where secure configurations yield predictable, deterministic outcomes, AI systems are non-deterministic. Because outputs can vary significantly based on user inputs, customers bear increased responsibility for implementing robust guardrails, continuous monitoring, and input/output filtering.

Early attempts to create a logical foundation for AI shared security responsibility produced some answers — and more questions.

In light of this being a tricky problem, here I really want to focus on one thing — a post-incident scenario. While shared responsibility covers numerous use cases (and numerous sources of confusion…), let’s examine a fairly straightforward situation: I am an enterprise end-user company that uses (maybe builds, maybe tunes, etc) AI in some form, then something blows up (digitally, as this is not IoT/ICS security blog). So:

• Who takes a loss vs who is to blame?
• Do I blame the model creator? The application developer? The model hosting platform? Or do I ultimately blame myself?

If you recall, many early challenges with the cloud shared responsibility model began with customers trying to blame the provider, only to discover they were actually at fault in the end. We tried to change this dynamic by introducing a “shared fate” model. While that specific terminology has seemingly fallen out of favor lately, the underlying philosophy remains: providers can probably do more to make AI usage inherently secure.

I was recently involved with a CoSAI (Coalition for Secure AI) working group to develop a paper covering the shared responsibility framework for AI security. As others on the team humorously pointed out, my voice was one of the loudest calling for the paper to be kept simple, crisp, and highly usable. You can judge based on the final result whether we succeeded.

We recently wrapped up and approved Version 1.0 of the CoSAI AI Shared Responsibility Framework (AI SRF) through the Coalition for Secure AI and OASIS Open. The core mission here wasn’t to build more abstract compliance theater, but to solve a practical, glaring operational pain point: Who actually owns what when an AI system fails?

Under the CoSAI framework, accountability traces down the stack with absolute clarity:

• The AI Model Provider (L5) is accountable for the base model’s inherent susceptibility to prompt injection and must document those boundaries explicitly within the model card.
• The Cloud/Platform Provider (L4) is accountable for the blast-radius containment, ensuring infrastructure-level tenant process isolation held firm during the exploitation.
• The Application Developer (L3) is accountable for failing to enforce application-level guardrails, input filtering, and localized data access controls that allowed the chatbot to hit the PII repository in the first place.
• The Deploying Organization (L1/L2) is accountable for the ultimate governance failure: they did not properly classify the data or restrict the chatbot’s system-level access boundaries before pushing it live.

Also, the paper included a phased Implementation Playbook in the document to give security teams a somewhat specific path forward:

1. Phase 1 (Days 1–30): Map your entire AI system inventory and cross-reference vendor contracts against these five layers to highlight immediate responsibility gaps.
2. Phase 2 (Days 31–90): Establish a cross-layer governance committee and formally update vendor procurement contracts with clean, explicit accountability matrices.
3. Phase 3 (12 Months): Run layer-specific tabletop simulations to stress-test your incident response playbooks before an actual threat actor tests them for you.

Fun quotes:

• “Ambiguous ownership is a growing liability for Al system deployments.” [A.C. — filed under ‘no shit, Sherlock’]
• “Without explicitly assigned owners for detection, containment, and remediation, teams default to the finger-pointing cycle” [A.C. — this will get worse, then MUCH worse, then eventually better…]
• “The framework turns ‘whose fault is this?’ into ‘which layer’s controls failed, and who owns remediation for each?’” [A.C. — this is beautifully, I probably wrote this :-)]
• “There should be exactly one accountable party per component to prevent overlaps.” [A.C. — ideal world called, it wants its problem back! Real world picked up and said ‘get lost’]
• “Clear accountability eliminates finger-pointing during incidents” [A.C. — clear evidence that Captain Obvious is alive!]

More seriously, read the paper!

In the end, I hope this work enlightens people on just how complex this problem truly is. This paper is definitely not a silver bullet that solves everything overnight; we have years of discussions and evolving challenges ahead of us down this path. However, I think this paper serves as an excellent first step. Please make sure to check out the resources listed at the end of the paper as well (a lot of gems there!)

Related blogs:

• Who’s Responsible When AI Goes Wrong? A New Framework Aims to Answer That Question
• Where Does Shared Responsibility Model for Security Breaks in the Real World?
• No Snow, No Flakes: Pondering Cloud Security Shared Responsibility, Again!
• EP203 Cloud Shared Responsibility: Beyond the Blame Game with Rich Mogull
• EP145 Cloud Security: Shared Responsibility, Shared Fate, Shared Faith?
• Who Does What In Cloud Threat Detection?
• The Cloud Shared Irresponsibilities Model

From Cloud to Chaos: Defining Shared Responsibility for AI Security was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Intezer already investigates 100% of your alerts and escalates fewer than 2% of them for human review. That part is handled.

The work does not stop there, though. Every SOC has its own routines wrapped around the investigation itself. The incident reports written in a particular format, the closure notes, the shift handoffs, the rules that decide who picks up which case. When we looked at how teams actually use AI Chat, our in-product investigation agent, more than a third of those conversations turned out to be the same repetitive tasks asked again and again. The same summaries. The same reports. The same closure notes.

Intezer’s AI SOC already runs agents around the clock to triage, investigate, and respond to your alerts on their own. Custom Agents is the next step. Now you can shape how that AI SOC works for your team. Add your own agents and automations on top of the ones Intezer runs out of the box, take more of the manual work off your analysts, and tailor the whole thing to the way your team actually operates.

Meet Custom Agents

Intezer ships with a set of agents and automations that handle triage, investigation, and response from day one. Custom Agents lets you build your own on top of them.

An agent is made up of three components:

1. Your instructions
2. A trigger
3. The tools it is allowed to use

You describe what you want done in plain language, choose when it should run, and pick what it can touch. It then runs on its own inside your Intezer environment, on the same engine that powers our investigation Agent (Chat).

Build an agent in minutes

1. Tell it what to do, in plain language. Write the instructions the way you would brief a new analyst. “Every morning, review the open case queue, close the clear false positives per our playbook, and leave a handoff note on the rest.” That is an agent.

2. Choose when it runs. Three trigger types cover most workflows:

• On a schedule: every day, week, or month. For example, a 9:00 report.
• On an event: the moment a case is closed, a verdict is set, or an alert meets your conditions.
• On demand: run it yourself, or call it from the API.

3. Give it the right tools. Agents work across your whole stack which includes Intezer’s built-in toolset plus the SIEM, EDR, and identity tools you have already connected, including CrowdStrike, SentinelOne, Splunk, Microsoft Sentinel, and Entra ID. They do more than summarize. They take action by updating, commenting on, closing cases, and emailing a finished report to your team.

See it in action

Take an Incident Report Writer agent illustrated above. We deliberately never shipped a single “Generate report” button, because no two teams want the same report. One team wants an executive summary up top, another wants the full timeline, another has a compliance format it has to match. So instead of a button, you put your format into the agent’s instructions, and it writes every report that way, every time.

The agent triggers on every escalated case an analyst has confirmed as a real threat. It reads the case, writes the report in your format, and emails it to your team’s inbox. The analyst makes the call. The paperwork writes itself.

That’s one agent. The point of Custom Agents is that you decide what they are.

Nothing runs blind

Security teams do not trust black boxes, and they are right not to. Custom Agents is built so you can see and control everything an agent does.

• Every run is visible. You see the agent’s reasoning, every tool call and its result, and the final output. Each run is logged, and you can export it.
• Test safely with Dry Run. Dry Run executes the agent for real but mocks every write action, so you can watch exactly what it would do before it does anything. Iterate on the instructions until it is right, then turn it on.
• Guardrails are built in. Action tools are limited by design. An agent can only email active members of your organization, for example. It cannot reach outside your walls.
• You stay in control. You choose which tools an agent gets, you review its output, and you can switch it off in one click.

This is how everything at Intezer works. AI executes, humans supervise. Custom Agents lets you decide what it executes.

What security teams are already building with it

We opened Custom Agents to a small group of alpha customers, and the best part has been watching what they build. Alongside the Incident Report Writer above, a few of the agents already running in production:

• SLA Monitor (daily): a morning email listing every escalated case that has been sitting too long, so nothing critical slips past its deadline.

• Tuning Advisor (weekly): takes the alerts your detection tools fired that Intezer judged to be false positives and turns them into suppression recommendations for the week ahead.

• Threat Hunter (weekly): proactively sweeps your environment for the latest threats instead of waiting for an alert to fire. It pulls the new malware families, campaigns, and indicators Intezer is tracking, queries your connected SIEM and EDR for matches across historical data, and opens a case for anything it surfaces.

• Smart Triage and Routing: for organizations with multiple entities, subsidiaries, and stakeholders, the agent reads each case and works out which team should own it, using your own escalation rules. It either leaves a comment with the routing, or assigns the case to the right analyst directly. Analysts stop digging through a separate list or knowledge base to figure out where a case goes.

• End of Shift Handoff: built to match what a real SOC handover looks like. At the end of a shift the agent compiles the open items, the escalations still waiting for attention, the shift’s statistics, and any open system events or configuration issues, then writes the handoff so the next shift starts with the full picture.

The AI SOC, built for your team

We are on a mission to build the AI SOC the industry has been promised but never delivered. One that does the work and earns the trust to do it. It runs autonomously, around the clock. It works alongside the people who supervise it, not over their heads. And it is never a black box. You can always open it up, question what it did, and change how it behaves.

Custom Agents is central to that vision. Triage, investigation, and response come built in. Everything particular to how your team operates, you build yourself. Because the strongest security teams have always run on their own playbooks, their own logic, and their own standards, and an AI SOC should be no different. It should not ship the same to everyone. No two SOCs are the same, and no two should be.

That is the point of Custom Agents. You decide what they are.

Available now

Custom Agents is available now in beta to Intezer customers, and it is free during the beta period. This is the moment to build, test, and tell us what you want it to do next.

See what your SOC could hand off. Book a demo.

If you are already an Intezer customer, you will find it under Custom Agents in the top menu.

The post Introducing Custom Agents: Automate your SOC, your way appeared first on Intezer.

Attackers can exploit LLM domain hallucinations through phantom squatting to target supply chains. Read the analysis to learn more.

The post Phantom Squatting: AI-Hallucinated Domains as a Software Supply Chain Vector appeared first on Unit 42.

My Anton’s Security Blog Quarterly covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our Cloud Security Podcast (subscribe on Spotify, now with VIDEO).

Top 10 posts with the most lifetime views (excluding paper announcement blogs):

1. Anton’s Alert Fatigue: The Study [A.C. — wow, this is still #1 now! Awesome! Perhaps I need more of such deep studies]
2. Security Correlation Then and Now: A Sad Truth About SIEM
3. Can We Have “Detection as Code”?
4. Detection Engineering is Painful — and It Shouldn’t Be (Part 1)
5. Revisiting the Visibility Triad for 2020 (update for 2025 is here!)
6. Beware: Clown-grade SOCs Still Abound
7. Why is Threat Detection Hard?
8. Top 10 SIEM Log Sources in Real Life?
9. A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next
10. Log Centralization: The End Is Nigh?

Top 5 posts with paper announcements:

1. New Paper: “Future of the SOC: SOC People — Skills, Not Tiers” (paper 2 of the series)
2. New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5) (one more paper coming later in 2026 … we are in reviews now!)
3. New Paper: “Future of the SOC: Forces shaping modern security operations”
4. New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)
5. New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center” (Our classic 2021 ASO paper! Still epic, still relevant)

3 random fun posts, must-read:

• Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1)
• Shadow Agents: A New Era of Shadow AI Risk in the Enterprise
• Anton’s Vibe Coding Experience: A Reflection on Risk Decisions

Top 7 Cloud Security Podcast by Google episodes (excluding the oldest 3!):

1. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with Gary McGraw
2. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil
3. EP47 “Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
4. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
5. EP109 How Google Does Vulnerability Management: The Not So Secret Secrets!
6. EP17 Modern Threat Detection at Google
7. EP156 Living Off the Land and Attacking Critical Infrastructure: Mandiant Incident Deep Dive

Now, fun posts by topic.

Security operations / detection & response:

• “Security Correlation Then and Now: A Sad Truth About SIEM”
• “Migrate Off That Old SIEM Already!” (VIDEO, a 2026 update is coming soon!)
• “Measuring the SOC: What Counts and What Doesn’t in 2025?” (Google Cloud Blog)
• “Can We Have “Detection as Code”?”
• “Revisiting the Visibility Triad for 2020” and “SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025”
• “Beware: Clown-grade SOCs Still Abound”
• “Why is Threat Detection Hard?”
• “A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next”
• “Stop Trying to Take Humans Out of SOC … Except … Wait… Wait… Wait…” and “A Brief Guide for Dealing with ‘Humanless SOC’ Idiots”
• “Top 10 SIEM Log Sources in Real Life?” (NEWER VERSION)
• “Debating SIEM in 2023, Part 1” and “Debating SIEM in 2023, Part 2”
• “Log Centralization: The End Is Nigh?”
• “Living with Multiple SIEMs”
• “Decoupled SIEM: Brilliant or Stupid?” and “Decoupled SIEM: Where I Think We Are Now?”
• “How to Make Threat Detection Better?”
• “SIEM Content, False Positives and Engineering (Or Not) Security”

Cloud security:

• “Secure cloud. Insecure use. (And what you can do about it)”
• “Using Cloud Securely — The Config Doom Question”
• “Who Does What In Cloud Threat Detection?”
• “How to Solve the Mystery of Cloud Defense in Depth?”
• “Does the World Need Cloud Detection and Response (CDR)?”
• “How to Think about Threat Detection in the Cloud”
• “Use Cloud Securely? What Does This Even Mean?!”
• “How CISOs need to adapt their mental models for cloud security” [GCP blog]
• “Who Does What In Cloud Threat Detection?”
• “AI Adoption: Learning from the Cloud’s Early Days”
• “Cloud Migration Security Woes”
• “Move to Cloud: A Chance to Finally Transform Security?”

How Google Does Security (HGD) — the new master site How Google Does It: An inside look at cybersecurity:

• “How Google Does It: Making threat detection high-quality, scalable, and modern” (Google Cloud blog)
• “How Google Does It: How we secure our own cloud” (Google Cloud blog)
• “How Google Does It: Securing production services, servers, and workloads”
• “How Google Does It: Finding, tracking, and fixing vulnerabilities” (Google Cloud blog)
• “How Google Does It: Collecting and analyzing cloud forensics”
• “How Google Does It: Red teaming at scale” (Google Cloud blog)
• “How Google Does It: Security programs at global scale” (Google Cloud blog)
• “How Google Does It: Securing production services, servers, and workloads”
• “How Google Does It: Collecting and analyzing cloud forensics”
• “How Google Does It: Applying SRE to cybersecurity”
• “How Google Does It: Building an effective AI red team”

(if you only read one, choose this one! BTW, we also have a lot of fun HGD podcasts)

AI security:

• “Implementing Secure AI Framework Controls in Google Cloud”
• “Office of the CISO 2025 Year in Review: 3 Key AI Security & Governance Themes”
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise”
• ““Risk Tiering AI Use Case — A Practical Guide” (Google Cloud Community blog)
• “Securing AI Supply Chain: Like Software, Only Not”
• “Spotlighting ‘shadow AI’: How to protect against risky AI practices” (Google Cloud blog)
• “Shadow AI Strikes Back: Enterprise AI Absent Oversight in the Age of Gen AI”
• “Cloud CISO Perspectives: How Google secures AI Agents”
• “New Paper: “Securing AI: Similar or Different?“
• “The Prompt: What to think about when you’re thinking about securing AI” (Google Cloud blog)
• “Gen AI governance: 10 tips to level up your AI program” (Google Cloud blog)
• “AI Adoption: Learning from the Cloud’s Early Days” (Google Community blog)
• “How Google secures AI Agents” (Google Cloud blog)
• “Demystifying AI Security: New Paper on Real-World SAIF Applications”
• “To securely build AI on Google Cloud, follow these best practices” (Google Cloud blog)
• “Oops! 5 serious gen AI security mistakes to avoid” (Google Cloud blog)
• “3 new ways to use AI as your security sidekick” (Google Cloud blog)
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise” (Google Cloud Community blog)

Fun presentations shared (nothing much new here):

• SecureWorld 2025 Keynote Déjà Vu All Over Again: Learning from Cloud’s Early Misadventures to Secure AI (2025)
• Detection Engineering Maturity — Helping SIEMs Find Their Adulting Skills (2024)
• Future of SOC: More Security, Less Operations (2024)
• SOC Meets Cloud: What Breaks, What Changes, What to Do? (2023)
• Meet the Ghost of SecOps Future (2023)
• The Future of Log Centralization for SIEMs and DFIR — Is the End Nigh? (2023)
• 20 Years of SIEM (2022) — should I do 25 years of SIEM in 2027?

Enjoy!

Previous posts in this series:

• Anton’s Security Blog Quarterly Q1 2026
• Anton’s Security Blog Quarterly Q4 2025
• Anton’s Security Blog Quarterly Q3 2025
• Anton’s Security Blog Quarterly Q2 2025
• Anton’s Security Blog Quarterly Q1 2025
• Anton’s Security Blog Quarterly Q4 2024
• Anton’s Security Blog Quarterly Q3 2024
• Anton’s Security Blog Quarterly Q2 2024
• Anton’s Security Blog Quarterly Q1 2024 Lite
• Anton’s Security Blog Quarterly Q3 2023
• Anton’s Security Blog Quarterly Q2 2023
• Anton’s Security Blog Quarterly Q1 2023
• Anton’s Security Blog Quarterly Q4 2022
• Anton’s Security Blog Quarterly Q3 2022
• Anton’s Security Blog Quarterly Q2 2022
• Anton’s Security Blog Quarterly Q1 2022
• Anton’s Security Blog Quarterly Q4 2021
• Anton’s Security Blog Quarterly Q3 2021
• Anton’s Security Blog Quarterly Q2 2021
• Anton’s Security Blog Quarterly Q1 2021
• Anton’s Security Blog Quarterly Q3.5 2020

Anton’s Security Blog Quarterly Q2 2026 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blogs

Blog

America250 Fourth of July Threat Assessment

In this post we break down the intersecting cyber risks, physical security strains, and operational challenges shaping the security landscape for the historic Semiquincentennial celebrations.

SHARE THIS:

Flashpoint Intel Team

June 30, 2026

Table Of Contents

Table of Contents

Key Takeaways

Physical Threat Vectors

Cyber Threat Vectors

Protect People Using Flashpoint

More

The Complete Guide to OSINT for Executive Protection

Download Now

As the United States prepares to mark its 250th anniversary this Fourth of July, the convergence of historic national celebrations, sprawling public events, and simultaneous high-profile sports tournaments is creating an exceptionally complex threat landscape. The multiyear national initiative “America250,” features over 1,200 synchronized grassroots gatherings under the “America’s Block Party” umbrella, with flagship events taking place in Washington DC, Philadelphia, Boston, New York, and Los Angeles.

Key Takeaways

While public sentiment surrounding America250 remains broadly positive, Flashpoint analysts have assessed the physical, cyber, and operational threat vectors that organizations, security teams, and municipalities must navigate during this high-visibility holiday weekend.

America250 Threats & Security Challenges:

1. Distributed Physical & Infrastructure Strain: Massive tourism influxes will collide with ongoing 2026 FIFA World Cup matches in Houston and Philadelphia on July 4, putting historic operational pressure on metropolitan transit grids and soft targets.
2. Elevated Iconicity and “City of Concern” Status: Although no specific, credible plots have been confirmed, the National Mall events in Washington, DC have received their first-ever National Special Security Event (NSSE) designation. Meanwhile, the National Counterterrorism Center (NCTC) has officially designated Philadelphia a “city of concern” due to the volume of synchronized events.
3. Ideological Protest Dynamics: Activist groups are organizing a significant anti-authoritarian march in Philadelphia. While expected to be peaceful, open-source chatter indicates a portion of attendees plan to exercise their license to carry firearms.
4. Disruption & Cyber Threat Vectors: Cyber threat groups, ransomware operators, and hacktivists are expected to attempt to exploit thin holiday IT staffing. Threat vectors range from mass public-transit ticketing fraud to high-consequence digital hoaxes involving rogue cellular infrastructure.

Physical Threat Vectors

Transportation and Infrastructure

Flashpoint assesses that “lone wolf” actors motivated by various ideological grievances, including those inspired by foreign terrorist organizations (FTOs), pose the most likely threat of disruptions to transportation infrastructure during America250 events. This threat is likely to apply to all major transport hubs during the event, including Washington DC, Philadelphia, New York City, and Boston. Attendees can expect to see an increased police and military presence near transit hubs at major events.

Event Threats

While no specific credible threats targeting America250 events have been identified, the July 4th events taking place on the National Mall in Washington DC, have been given a National Special Security Event designation, which is typically reserved for events deemed potential targets for terrorism or other criminal activity. This is the first time such a designation has been given to July 4th celebrations on the National Mall.

Memos released by the National Counterterrorism Center to security agencies also identified Philadelphia as a “city of concern” regarding potential targets for terror attacks due to the number and scale of events taking place on July 4th. Law enforcement officials have indicated that while no specific threats have been identified, increased security measures will be in place throughout the city.

Planned Protest

The Fayetteville Resistance Coalition, alongside Veterans Against Fascism, and the Women’s March is organizing an anti-authoritatian protest march in Philadelphia on July 4th—being the largest mobilization of military veterans in decades.

Flashpoint has identified chatter indicating that march attendees may be armed. However, Flashpoint has not identified any calls for violence at this protest and deem that actions will likely remain peaceful. Despite this, arrests may be possible if attendees gather in unauthorized areas or engage in civil disobedience.

Cyber Threat Vectors

Ransomware and Operational Technology (OT) Disruptions

Financially motivated threat actors frequently deploy ransomware during major US holiday weekends when corporate and municipal IT security staffing is historically thin.

Flashpoint analysts assess that attackers could target automated ticketing systems, regional rail signaling, and digital municipal transit grids. Disruption to public transit during the high-density travel window surrounding major events could induce logistical gridlock. Secondary targets include municipal water treatment facilities, local power grids, and emergency response (911) dispatch systems in primary host cities.

Hactivism

With hundreds of thousands of spectators gathering at prominent national landmarks, hacktivist groups seeking political leverage or global media visibility pose an elevated threat to public messaging infrastructure.

Compromising the digital billboards, stadium screens, or viewing decks used for America250 events presents an attractive vector for defacement. Adversaries may attempt to display political propaganda, anti-war messaging, or explicit content to captive, high-density crowds.

Event App Vulnerabilities and Data Harvesting

The decentralized nature of “America’s Block Party,” featuring over 1,200 grassroots events managed via localized apps, introduces software supply chain vulnerabilities.

Cybercriminals may target the ticketing infrastructure of high-profile, restricted-access events. Phishing campaigns, credential stuffing, or application programming interface (API) vulnerabilities within event-specific mobile applications could result in mass ticketing fraud, legitimate attendees being locked out, or crowd-control issues at venue gates.

Additionally, malicious actors frequently deploy spoofed public Wi-Fi networks around high-density tourist hubs to harvest sensitive personal data, financial credentials, and biometric profiles from unsuspecting attendees.

Protect People Using Flashpoint

To ensure attendee safety, safeguard operations, and protect public-facing brands, Flashpoint recommends implementing the following proactive measures:

1. Secure Public-Facing and Display Infrastructure: Implement strict access controls, multi-factor authentication (MFA), and offline fail-safes for all internet-connected digital signage, stadium screens, and public notification systems to prevent hacktivist defacements.
2. Audit Event Applications and Mobile Endpoints: Conduct rigorous vulnerability scans on event-specific APIs and ticket validation platforms. Advise personnel and contractors against posting photographs of official credentials, badges, or operational passes on public social media channels.
3. Establish Out-of-Band Incident Response Protocols: Prepare alternative communication channels and verified public-address messaging to immediately counter potential rogue emergency broadcasts, digital hoaxes, or localized telecom disruptions that could cause public panic.
4. Monitor High-Risk Overlap Zones: Cross-reference physical security deployment schedules in cities like Philadelphia where World Cup traffic, official America250 parades, and armed protest routes intersect near major transit networks.

Ensure your security team has full visibility into the cyber and physical threat vectors shaping this historic holiday weekend. Request a demo and see how Flashpoint equips organizations with the intelligence needed to detect, analyze, and mitigate emerging risks.

The post America250 Fourth of July Threat Assessment appeared first on Flashpoint.