Normal view
-
Threat Intelligence Blog | Flashpoint

- Cybercrime at Machine Speed: Key Takeaways from Flashpoint’s 2026 Midyear Threat Intelligence Briefing
Cybercrime at Machine Speed: Key Takeaways from Flashpoint’s 2026 Midyear Threat Intelligence Briefing
Blog
Cybercrime at Machine Speed: Key Takeaways from Flashpoint’s 2026 Midyear Threat Intelligence Briefing
Threat actors are no longer just using automation to execute tasks, they are leveraging prepackaged, safeguard-free AI, weaponizing stolen session data, and directly targeting defenders’ security stacks.

In our latest webinar, Flashpoint Vice President of Intelligence, Ian Gray, briefed security leaders on the evolving threat environment, providing critical insights from the Flashpoint Global Threat Intelligence Report (GTIR): 2026 Midyear Edition.
The threat landscape has developed at a striking pace with Flashpoint tracking over 22 million illicit AI discussions, 7.4 million compromised hosts yielding 1.7 billion stolen credentials, and over 21,600 disclosed vulnerabilities in just six months. Beyond these staggering numbers, the on-demand session detailed something even more alarming: a fundamental shift in adversary operational tradecraft.
Here are the five critical shifts every cyber threat intelligence (CTI), Vulnerability Management, and SOC team needs to know.
The Death of Signal: Threat Actors are Shifting to “Private AI”
The public discussion surrounding criminal artificial intelligence (AI) has reached a critical inflection point. Early in the AI boom, Flashpoint observed threat actors collaboratively experiment across underground forums, jailbreaking commercial frontier models or advertising surface-level tools like WormGPT and DarkGPT.
Today, adversaries are shifting from public forums to running fine-tuned, open-source models locally on private servers, which greatly hampers traditional signature-based detection. Flashpoint analysts are now seeing attackers generate unique, highly tailored malware variants, flawless phishing lures, and custom exploit scripts at extremely low costs—completely offline and shielded from public monitoring.
“A few months ago, a lot of this was collaborative… public outsourcing. Now what we’re seeing is scarier: pre-packaged cybercrime models run locally on private infrastructure. Malicious code, exploit scripts, and targeted phishing are all being generated inside closed environments.”
Ian Gray, VP of Intelligence, Flashpoint
Weaponizing the Defender’s Own Tooling
Another eye-opening tactical insight shared during the session was how threat actors are repurposing defender infrastructure for automated initial access and extortion. In the webinar, we pointed to recent campaigns where adversaries specifically targeted misconfigurations and zero-day vulnerabilities inside open-source vulnerability scanners, secrets-detection tools, Kubernetes clusters, and Infrastructure-as-Code(IaC) environments.
What this means for defenders is that the attack surface is no longer bounded by traditional enterprise network boundaries: it extends directly into CI/CD pipelines, security orchestration tooling, and third-party SaaS integrations. Security teams are finding themselves in a race against attackers who use automated scanning scripts to weaponize vulnerabilities in the security tools themselves.
The Global Infostealer Threat and Identity-First Attacks
Flashpoint tracked 7.4 million hosts compromised by infostealers in H1 2026—a 27% increase period-over-period—harvesting 1.7 billion credentials and identity information.
While the top infostealer strains remain familiar, law enforcement operations have created vacuums that competitors rapidly fill.
Threat actors are leveraging drive-by downloads, watering holes, and pirated software packages to plant stealers. Once a machine is compromised, the logs capture corporate SSO credentials, active browser cookies, VPN keys, and SaaS session tokens. This enables adversaries to simply log in without having to leverage complex technical exploits.
The Structural Failure of CVE/NVD and the Importance of KEV
The Common Vulnerabilities and Exposures (CVE) and National Vulnerability Database (NVD) have failed to keep pace with the velocity of AI-assisted vulnerability discovery. As such, vulnerability management teams are facing significant operational delays.
| Metric | Flashpoint GTIR Midyear H1 2026 Data | Operational Impact |
| Total Disclosures | 21,667 | Remediation volume exceeds defender bandwidth. |
| Exploit Availability | 19% (4,015 CVEs) | Functional code is ready before patches are deployed. |
| Public Catalog Lag | Growing Backlog (NVD/KEV) | Delay in official scoring leaves teams blind to active risk. |
Therefore, waiting for NVD enrichment before prioritizing a patch is a dangerous strategy. To compensate, security teams require Vulnerability Intelligence (VI) that provides primary-source confirmation of weaponization, exploit availability, and actionable mitigation guidance long before public databases update.
Ransomware Evolution: From Encryption to Cloud Extortion
Ransomware-as-a-Service (RaaS) activity surged by 45% period-over-period, reaching 6,256 verified victim postings on data leak sites. However, total on-chain payout revenue dropped by 8% to $820 million, with victim pay-rates hitting a record low of 28%.
Faced with declining payouts and resilient enterprise backups, extortion syndicates are adapting. Rather than relying exclusively on technical file-encrypting malware, groups are executing pure data extortion campaigns—frequently targeting cloud platforms or extracting data through third-party vendor access.
Protect Your Organization Using Flashpoint
Defending against machine-speed attacks requires moving beyond reactive, post-incident telemetry. Flashpoint arms security, CTI, and vulnerability management teams with the primary-source intelligence required to preempt adversary operations:
- Unrivaled Deep & Dark Web Visibility: Flashpoint’s Primary Source Collection actively monitors closed criminal communities, illicit Telegram channels, and private forums, giving you early warning when threat actors build custom AI toolkits or trade credentials targeting your organization.
- Comprehensive Vulnerability Intelligence (VI): Flashpoint tracks zero-days and vulnerability disclosures independently, delivering immediate exploit availability data and threat-informed prioritization so you patch what actually matters.
- Continuous Compromised Credential Monitoring: Instantly surface exposed enterprise credentials, active session tokens, and stealer logs tied to your domain or third-party supply chain before they lead to an account takeover (ATO).
Request a demo, or watch the full on-demand webinar to explore the data shaping today’s risk landscape.
See Flashpoint in Action
The post Cybercrime at Machine Speed: Key Takeaways from Flashpoint’s 2026 Midyear Threat Intelligence Briefing appeared first on Flashpoint.
-
Threat Intelligence Blog | Flashpoint

- The Evolution of Hacktivism in Hybrid Warfare: Modern Tactics and Real-World Impact
The Evolution of Hacktivism in Hybrid Warfare: Modern Tactics and Real-World Impact
Blog
The Evolution of Hacktivism in Hybrid Warfare: Modern Tactics and Real-World Impact
In this post we examine how modern hacktivism has evolved into a tool of global hybrid warfare, analyzing crowdsourced attack tactics, media-driven propaganda, and real-world impacts across Ukraine, the Middle East, European Union, and NATO nations.

Hacktivism used to be perceived as digital graffiti, with lone-wolf threat actors defacing government websites or temporarily crashing banking portals to make a political point. However, Flashpoint is tracking a fundamental shift in how these groups operate.
Modern hacktivism is evolving into a disciplined component of global hybrid warfare, capable of bridging digital disruptions with tangible real-world impact. Today, these operations blur the line between volunteer activism and coordinated state interest, leveraging crowdsourced infrastructure to disrupt critical utilities, manipulate media narratives, and target public infrastructure on a global scale. Unpacking these modern hacktivist collectives reveals what their tactics look like in practice and their far-reaching consequences across dozens of nations.
What is Hacktivism?
Hacktivism is the use of cyberattacks to promote or advance a particular political or social cause, leveraging a wide range of tactics such as website defacement, distributed denial-of-service (DDoS) attacks, and data breaches. Modern hacktivist collectives serve as the loud, high-visibility arm of cyber conflict—frequently aligning with state geopolitical interests, as seen most prominently in recent pro-Russian operations and Iranian-aligned cyber campaigns.
These pro-Russian hacktivist groups, such as NoName057 and Killnet, alongside pro-Iranian collectives and proxy ecosystems like Handala Hack, often react to the news cycle and target countries designated by state media or ideological narratives as enemies. As such, modern hacktivist campaigns are opportunistic and tied to global events—from the escalation in the Middle East following military operations like Operation Epic Fury, to the Milan-Cortina Winter Olympics and new aid packages to Ukraine. These groups’ justification narratives typically mirror state messaging.
Modern Tactics: Gamifying Cyber Warfare
In tracking modern hacktivist groups, Flashpoint analysts identified a new method these groups are utilizing to convert ordinary devices into tools for hybrid warfare—the gamification of cyberattacks. Flashpoint has observed groups like NoName057 turning DDoS attacks into community-based “patriotic online games,” such as their “DDoSia Project,” with participants earning military-style ranks and cryptocurrency rewards for overloading the websites of government institutions, banks, and various infrastructure across various countries.
This model has enabled the scaling of operations by utilizing a large, low-skilled participant base rather than having to rely on sophisticated technical tradecraft. The model’s decentralized structure and ideological appeal continue to pose a significant challenge for international law enforcement.
The Propaganda Engine: Media Amplification and Validation
Beyond technical disruptions, publicity is the primary currency of modern hacktivism. Hacktivist groups demonstrate a consistent pattern of media-seeking behavior and self-promotion, likely intended to amplify their perceived impact and reinforce notoriety within the broader cyber threat landscape. Many of these groups repeatedly repost media coverage and news articles referencing themselves.
This serves as a curated self-promotion mechanism, allowing the group to selectively showcase external validation of its operations, including coverage from mainstream and security-focused outlets, to its followers. This behavior aligns with a broader trend observed with especially pro-Russian hacktivist collectives, in which media visibility is treated as a measure of operational success independent of verified technical impact. It also serves as a deliberate tactic for engagement and recruitment that reinforces “patriotic” branding and sustains participant morale and visibility.
Beyond Propaganda: Aligning Cyber Disruption with Military Objectives
In some cases, the digital targeting of hacktivist collectives is more aligned with kinetic objectives, rather than public perception or propaganda initiatives. This is especially true for Iranian-aligned hacktivists and proxy groups who are more deeply intertwined with military operations in the Middle East. These groups have expanded their operations from website disruptions into claims of large-scale data wipers, extortion, and cyberattacks targeting key infrastructure across the Gulf.
The Far Reach of Modern Hacktivism
Major geopolitical flashpoints in the Middle East have triggered waves of hacktivist activity that has spread across North America, with threat actors targeting supply chains, financial infrastructure, and operational technology and control systems.
Simultaneously, pro-Russian hacktivist groups, particularly NoName057, have been extremely prolific within the last year—carrying out two major illicit campaigns heavily targeting Ukraine, which then spilled over to more than 30 nations globally. The following breakdown contains statistics and targeting dynamics of pro-Russian hacktivist groups observed between July 2025 and 2026:

The Continuous Campaign Against Ukraine
Ukraine has been the primary target for pro-Russian hacktivist groups who seek to damage Ukrainian infrastructure and morale. Anti-Ukrainian content is constantly distributed through dedicated per-language channels, making it the most linguistically developed target spanning six languages. Involved channels each post near-identical translated content within minutes to hours of the Russian original, down to the same image file with identical SHA1 hashes, which suggests a sustained propaganda distribution operation.
This has resulted in alleged data breaches impacting Ukrainian General Staff, military enlistment offices, medical, and morgue databases to push a casualty-count narrative. It also has resulted in the defacement or disruption of websites of regional capitals and administrative centers, energy plants, water and power-adjacent infrastructure, and many more.
Spilling Over: Impact Across EU and NATO Allies
However, Ukraine is not the sole casualty of modern hacktivism. Recent pro-Russian hacktivist campaigns have spread to other EU nations and NATO members. Germany, the United Kingdom, and Spain have been observed to be priority targets, with threat actors targeting public transportation, federal and security agencies, municipal government and utilities, financial markets, and other infrastructure. In some cases, hacktivist campaigns manifest in the real-world, with physical sticker drives on municipal streets, alongside doxxing operations releasing alleged personal data and automated scans hijacking exposed CCTV camera systems across Europe.

Defend Against the New Wave of Hacktivism Using Flashpoint
As hacktivist operations continue to blur the boundary between digital disruption and real-world interference, organizations can no longer view DDoS attacks or low-level intrusions as simple background noise. Protecting critical assets requires proactive visibility into threat actor networks, early detection of targeting narratives, and primary source threat intelligence.
Request a demo today to see how Flashpoint provides actionable intelligence to help security teams, government agencies, and infrastructure providers identify, monitor, and mitigate emerging hacktivist campaigns before they impact operations.
See Flashpoint in Action
The post The Evolution of Hacktivism in Hybrid Warfare: Modern Tactics and Real-World Impact appeared first on Flashpoint.
Insider Threat Report: Dark Web Recruitment & Access Trends
Blog
Insider Threat Report: Dark Web Recruitment & Access Trends
Flashpoint’s monthly analysis of insider threat recruitment, illicit access advertising, and threat actor activity targeting enterprise environments.

Unknowingly, a member of key personnel is living two separate lives. On the clock, they are a highly-trusted systems administrator, but in their personal time, they moonlight on the deep and dark web, advertising their trust and access to the highest bidder. One day, they get a simple offer: $15,000 in the crypto of their choice to approve a single push notification at 2 AM. They accept. By morning, the attacker walks away with active domain admin credentials without the need for malware or cracking firewalls.
This is just one example of how insider threats lead to modern enterprise breaches. This year, Flashpoint uncovered 7,282 unique insider threat posts, with an average of 34 unique posts being posted daily. As perimeter security, EDR coverage, and other security tools mature, threat actors are finding it faster—and cheaper—to target the human element and simply buy an insider’s credentials or pay an employee to open the front door.
In a threat landscape where identity is becoming the primary attack surface, monitoring illicit marketplaces and recruitment efforts is critical. This new monthly report leverages Flashpoint’s Primary Source Collection (PSC) to analyze insider threat tactics, tracking active recruitment and advertising on dark web forums and encrypted networks.
The Insider Threat Landscape: July 2026
In July 2026, Flashpoint analysts identified a total of 12,653 insider posts. These communications include both threat actors attempting to recruit insiders in target organizations, as well as insiders advertising their services on illicit forums and marketplaces.
Of these total communications, Flashpoint observed 1,132 unique posts in July 2026.

Where Insider Threat Activity is Concentrated
Historically, the Telecommunications, Retail, and Financial industries are most adversely affected by insider threat activity. However, July 2026 findings noticeably deviate from this trend. Flashpoint found 58.6% of total insider threat posts affected “Other” industries—suggesting adversaries are diversifying their target base. Threat actors may be attempting to recruit within supply chain partners, logistic hubs, manufacturing platforms, and specialized service providers to find alternative entry points into target networks.

The following table shows a breakdown of unique insider posts by industry in July 2026:
| Industry | Posts |
| Other | 663 |
| Financial | 150 |
| Retail | 112 |
| Technology | 84 |
| Telecom | 74 |
| Public Sector | 43 |
| Healthcare | 3 |
| Media | 3 |
| Total | 1,132 |
Insider Threats: Recruiting vs. Advertising
Active insider threats work in two ways: an insider is “recruited” by a malicious outside party, or a malicious insider “advertises” their access and skills to an interested threat actor. Regardless, by leveraging this connection, insiders assist adversaries by exfiltrating valuable data, installing malware, sabotaging IT systems, or performing SIM swaps.
In July 2026, Flashpoint found that over 75% of unique threat actor posts came from insiders advertising their access to malicious third parties. This indicates a highly motivated internal threat landscape where disgruntled employees actively seek out buyers for corporate data and network entry points.

Protect Against Insider Threats Using Flashpoint
Insider threats are inherently difficult to detect using internal security controls alone because the malicious activity relies on valid credentials and legitimate access privileges. Relying solely on internal logs means security teams often only detect an insider threat after data exfiltration or system sabotage has already occurred.
Flashpoint protects organizations against insider threats through our Primary Source Collection (PSC) and specialized intelligence platforms:
- External Threat Intelligence & Early Warning: Flashpoint monitors deep and dark web forums, invite-only threat communities, and encrypted chat platforms to identify employee solicitations, stolen corporate domain mentions, and active recruitment attempts before an intrusion develops.
- Identity Protection & Infostealer Tracking: By tracking illicit marketplaces and infostealer activity, Flashpoint identifies compromised corporate credentials and active session tokens, preventing threat actors from utilizing purchased access.
- User & Entity Behavior Context: Flashpoint’s intelligence equips SOC, Security Operations, and Risk Management teams with adversary TTPs, enabling security operations to look for anomalous data downloads, off-hours access, or unauthorized software installation.
To learn more about how Flashpoint can help protect your enterprise from insider risk and monitor illicit underground communities, Request a Demo Today.
Frequently Asked Questions (FAQs)
What is the Flashpoint Insider Threat Report?
The Flashpoint Insider Threat Report is a monthly intelligence brief that analyzes trends, volume, targeted industries, and tactics surrounding insider threat recruitment and illicit access advertising on the deep web, dark web, and encrypted chat channels.
How does Flashpoint collect insider threat data?
Flashpoint collects data using its Primary Source Collection (PSC) engine, which actively monitors thousands of dark web forums, illicit marketplaces, and underground chat networks where threat actors and malicious insiders communicate.
What is the difference between insider recruitment and insider advertising?
Insider recruitment occurs when an external cybercriminal attempts to entice a corporate employee into assisting with a cyberattack. Insider advertising occurs when an employee or contractor proactively lists their legitimate access or services for sale on illicit marketplaces.
See Flashpoint in Action
The post Insider Threat Report: Dark Web Recruitment & Access Trends appeared first on Flashpoint.
-
Threat Intelligence Blog | Flashpoint

- Navigating AI-Driven Cyber Threats: Insights from Flashpoint’s 2026 GTIR Midyear Edition
Navigating AI-Driven Cyber Threats: Insights from Flashpoint’s 2026 GTIR Midyear Edition
Blog
Navigating AI-Driven Cyber Threats: Insights from Flashpoint’s 2026 GTIR Midyear Edition
In this post, we preview the critical findings of Flashpoint’s Global Threat Intelligence Report: 2026 Midyear Edition.

In the first half of 2026, the global threat landscape reached a clear operational inflection point: threat operations have fundamentally transitioned from human-led campaigns to machine-speed, AI-driven exploitation. As threat actors gain commoditized access to open-source AI technologies and actively deploy automated, safeguard-free tooling locally on private infrastructure, organizations face an accelerating hybrid risk environment.
Flashpoint’s Global Threat Intelligence Report: 2026 Midyear Edition
The Flashpoint Global Threat Intelligence Report: 2026 Midyear Edition anchors security leaders—from threat intelligence, vulnerability management, to executive leadership—in the data required to navigate this evolving threat landscape. Covering the period from January 1 to June 30, 2026, the report delivers timely insights backed by Flashpoint’s proprietary primary-source collection from over 3.9 petabytes of continuously monitored illicit sources.
Our midyear findings reveal several key metrics that highlight the speed and scale of the H1 2026 threat landscape:
- 22M+ threat actor posts discussed, shared, or advertised artificial intelligence toolkits for criminal deployment.
- 1.7B credentials and identity data points extracted across more than 7.4M unique compromised hosts globally.
- Nearly one-in-five (19%) of all vulnerability disclosures dropped with ready-made, functional exploit code.
- 45% period-over-period surge in Ransomware-as-a-Service (RaaS), with total victim volume reaching 6,256 even as victim payout rates dropped to a historic low of 28%.
Download the Flashpoint Global Threat Intelligence Report: 2026 Midyear Edition to gain:
- A Clear Understanding of the Convergence Between AI and Cyber Threats
From generating flawless phishing campaigns to automating vulnerability scanning and code obfuscation, discover how adversaries are optimizing for speed and cost-efficiency — utilizing AI as a force multiplier in their various illicit campaigns. - A Comprehensive Top-Down View of the Evolving Threat Landscape
Gain full visibility of the threat landscape with Flashpoint’s primary-source collections and real-time threat intelligence. - Strategies for Proactive Defense and Risk Mitigation
Move your organization beyond reactive incident response by leveraging Flashpoint’s comprehensive threat intelligence. Gain the foresight needed to strengthen defenses and optimize your security posture.
“AI is compressing the time between opportunity and exploitation. Capabilities that once took significant expertise, coordination, and time to develop are becoming faster to build, easier to scale, and harder to detect. Security teams are facing an adversary ecosystem that can use AI to iterate at unprecedented speed — the only way to keep pace is with primary-source intelligence that surfaces adversary behavior before attacks unfold.”
Josh Lefkowitz, Flashpoint Co-Founder & CEO
The Four Driving Themes Shaping the 2026 Threat Landscape
Artificial Intelligence (AI) Threats
During the first half of 2026, Flashpoint captured over 22M illicit posts discussing or advertising AI for criminal-related activities. By stripping ethical safeguards, custom malicious LLMs allow unsophisticated threat actors to automate complex phases of the attack lifecycle, including target profiling, malware evasion script creation, and zero-day exploit generation.
Information-Stealing Malware Threats
Infostealer malware harvested 1.7 billion credentials across 7.4 million compromised systems in H1 2026 alone, turning digital identity into the main entry point for enterprise intrusions.
Vulnerability Intelligence and Patching Management
19% (4,015) of all H1 2026 vulnerability disclosures arrived with ready-made exploit code. Adversaries deploy automated replication scripts almost immediately upon disclosure, eliminating manual remediation windows.
Ransomware Operations, Multi-Extortion Cartels, and Financial Risk
Despite a 45% surge in victim volume (6,256 overall), total on-chain revenue fell by 8% to $820M. Improved enterprise backups and incident response have driven payout rates down to 28%, prompting syndicates to demand larger sums from paying victims.
Proactive Security in 2026 and Beyond
The data shows that traditional enterprise security organizations are struggling to keep pace with modern threat cycles that are accelerated by illicit uses of AI. This continued convergence of AI engines and initial access vectors have further compressed attack timelines, making it nearly impossible for security teams to defend against them—especially if they are limited by traditional approaches to threat intelligence.
Equipping your team with primary-source threat intelligence is critical for protecting critical assets in 2026. Download the Flashpoint Global Threat Intelligence Report: 2026 Midyear Edition to gain the visibility and strategic clarity required to defend your organization.
See Flashpoint in Action
The post Navigating AI-Driven Cyber Threats: Insights from Flashpoint’s 2026 GTIR Midyear Edition appeared first on Flashpoint.
-
Threat Intelligence Blog | Flashpoint

- Beyond Cyber: How CTI Teams Are Solving Converged Threat Use Cases
Beyond Cyber: How CTI Teams Are Solving Converged Threat Use Cases
Blog
Beyond Cyber: How CTI Teams Are Solving Converged Threat Use Cases
In this post we explain how cyber threat intelligence teams are being expected to take on physical risk, how tradecraft overlaps, and how Flashpoint bridges the gap.

For years, the mandate of Cyber Threat Intelligence (CTI) teams has been narrow and well understood: track cyber threat actors, monitor for indicators of compromise, and defend the network. However, that mandate is widening. In today’s interconnected threat landscape, more CTI teams are being tasked with physical security, geopolitical and protective intelligence. Whether that is monitoring and securing executive travel, a facility, or an event, data shows that this new informal expansion is becoming an industry-wide shift.
What the Data Says About Cyber-Physical Security Convergence
The SANS 2026 CTI Survey affirms that CTI programs are being asked to cover more ground, including physical and geographical risk, without a proportional increase in headcount. Survey findings additionally emphasize that the risks CTI teams navigate increasingly span cyber, physical, and geopolitical domains simultaneously, rather than staying contained to the network.
Industry research confirms this shift from every angle:
- ASIS International: The security standards body developed formal Enterprise Security Risk Management (ESRM) guidance specifically to address how organizations struggle to unify physical and cyber risk into a single program with shared visibility.
- 2026 Physical Security Trends: Market analysis consistently identifies cyber-physical convergence and unified security operations as mainstream mandates rather than fringe concepts.
- International Security Journal: Analysis highlights a fundamental shift from reactive to proactive security, driven by the reality that digital and physical systems are now so closely linked that a compromise on one side rarely stays contained.
Taken together, the picture is consistent across independent sources: intelligence teams are being pulled toward physical and human risk, and most organizations are still early in closing the gap between that mission and the tooling built to support it.
Why Physical Security is a Natural Extension
It might seem like a jump from tracking ransomware to monitoring executive travel risk, but the underlying methodology is similar. Both rely on:
- Situational awareness: Understanding the context around an event, whether digital or physical.
- Data aggregation: Bringing together disparate sources into a coherent picture.
- Predictive analysis: Identifying indicators of risk before they become incidents.
CTI analysts are already well positioned to bridge this gap. When an executive’s safety or a physical location’s security is at risk, the earliest warning signs are frequently digital via social media sentiment, localized chatter, and open-source discussions. Treating physical security as an adjacent mission means pointing skills a team already has at a new question, rather than starting net-new.
The Strategic Advantage: Breaking Down Operational Silos
Bringing these missions together has a practical benefit beyond the workload—it prevents security silos where digital and physical intelligence teams operate in isolation. When the same team that monitors cyber threats also informs physical security decisions, the organization achieves a more complete view of risk, reducing the chance that threats fall between the gaps of two disconnected functions.
Extending CTI to Physical Security with Flashpoint
Facing this convergence head-on doesn’t require a new platform, a new vendor evaluation, or creating a new discipline. Organizations leveraging Flashpoint Ignite already have the foundation needed to seamlessly extend their visibility into physical and geopolitical threat landscapes.
Using both Flashpoint Cyber Threat Intelligence (CTI) and Flashpoint Physical Security Intelligence (PSI), security teams can answer two essential questions: “what is this threat actor doing” and “what is happening right now around this specific person or place.” Both draw on much of the same underlying data and OSINT tradecraft, so extending into physical security only requires a change in Intelligence Requirements, not mastery of new systems or tools.
With Flashpoint PSI, organizations gain real-time access to mainstream sources where conversations about fast-moving events tend to surface first, plus a geospatial layer that maps that activity to a specific place. Analysts can also draw boundaries around geographic locations to monitor mentions of an executive within that area, or observe a venue on event day, seeing relevant activity as it surfaces. All of this can be accomplished using plain language, removing the need to learn secondary query syntax or lengthy manual processes to get started.
Navigating the Future of Converged Intelligence
The distinction between cyber and physical intelligence will likely keep blurring and Flashpoint is helping security teams on the ground level integrate these two functions. CTI teams that take on physical security as part of their mission shouldn’t be expected to abandon their core discipline. Instead, they should be given the workflows to apply it to a wider set of questions, using tools built to extend rather than replace the way they already work.
See how Flashpoint supports converged cyber and physical missions from a single platform. Request a demo to see what this could look like for your team.
See Flashpoint in Action
The post Beyond Cyber: How CTI Teams Are Solving Converged Threat Use Cases appeared first on Flashpoint.
-
Threat Intelligence Blog | Flashpoint

- Flashpoint EASM: Industry-Leading Vulnerability Intelligence, Mapped to Your Internet-Facing Assets
Flashpoint EASM: Industry-Leading Vulnerability Intelligence, Mapped to Your Internet-Facing Assets
Blog
Flashpoint EASM: Industry-Leading Vulnerability Intelligence, Mapped to Your Internet-Facing Assets
Catch exposures before threat actors do. Here is how Flashpoint’s new module works and the top questions answered from our live demo.

Security teams don’t lose ground because they lack tools. They lose ground because they can’t see everything an attacker can.
This is the challenge we addressed in our latest Demo Day webinar introducing Flashpoint External Attack Surface Management (EASM), a new module inside our Ignite platform that gives security teams a continuous, attacker’s-eye view of their external attack surface, mapped directly to our proprietary vulnerability intelligence.
The Problem: Too Much Noise, Not Enough Context
Most security teams are dealing with three compounding problems:
- Disconnected Data: Vulnerability data lives isolated from actual infrastructure. Knowing a CVE exists doesn’t tell you whether it affects your active environment.
- Alert Fatigue: CVSS-only prioritization treats every “critical” score as an emergency, even when an asset isn’t internet-facing or exploitable.
- Accelerated Threat Cycles: AI is speeding up how quickly threat actors discover and exploit vulnerabilities, making manual tracking impossible.
Layer on top of that the reality that most teams still track their perimeter with spreadsheets or a static CMDB, and you get a widening gap between what security teams think they own and what is actually exposed. This gap has a name: shadow IT.
Shadow IT Is a Growing Blind Spot
Shadow IT covers the domains, subdomains, and cloud instances that get spun up to get work done, without IT’s knowledge or approval. It’s not a fringe issue. According to Gartner, by next year, 75% of employees will be acquiring, modifying, or creating technology outside their IT department’s visibility, up from 41% just a few years ago.
These unmanaged assets sit outside inventory and outside the reach of any scanner that only looks at what’s already known. That makes them exactly the kind of infrastructure an attacker finds first, and exactly the blind spot Flashpoint EASM is built to close.
What is Flashpoint EASM?
Flashpoint EASM gives security teams a continuous, attacker’s-eye view of their external attack surface and maps that view directly to Flashpoint’s vulnerability intelligence. Instead of your team asking “are we affected by this?”, every time a new vulnerability is disclosed, EASM answers that question continuously, often before the answer is obvious anywhere else.
Flashpoint EASM is built on three capabilities that work together:
Continuous Asset Discovery
Flashpoint EASM continuously discovers and monitors internet-facing assets: domains, subdomains, and IPs. New discoveries flow into a dedicated triage inbox, so security teams can quickly accept and focus on what’s actually relevant instead of drowning in noise.
Vulnerability Mapping
Every discovered exposure is mapped to Flashpoint’s proprietary vulnerability intelligence, including our pre-NVD findings, KEV (Known Exploited Vulnerabilities) status, ransomware likelihood, and exploit maturity. This provides organizations with immediate context into the vulnerabilities that pose the most risk.
Customizable Alerting
Using EASM, security teams get alerted to the exact moment a new asset or vulnerability is detected. This alert is fully customizable by severity and is available inside one unified workflow via Flashpoint Ignite.
Discover, map, and alert. This loop gives organizations an intelligence-led view of their perimeter, so they can proactively outpace threat actors instead of being forced to react.
How Flashpoint EASM Works
In our live demo, Flashpoint walked through the EASM workflow, which can be found under “Assets and Identifiers” in the Ignite Platform.
Here’s how it works:
Step 1: Submit Seed Keywords
Onboarding starts with keywords, meaning domain and IP address assets your organization actually owns. Any already set up asset is automatically surfaced in Flashpoint Ignite—such as through our compromised credential monitoring—ensuring no duplicated setup work.
Step 2: Triage Discovered Assets
Once keywords are approved, EASM iterates on them to surface additional related infrastructure, domains and IPs alike, along with a discovery graph showing exactly how each asset was found. That traceability makes it easy to judge relevance at a glance.
Every discovered asset lands in one of three statuses:
- Owned: Assets in your tech stack. EASM continues discovering related infrastructure from these and links vulnerabilities to them.
- External: Assets relevant to you, but where you don’t need further discovery, just vulnerability linkage.
- Discarded: Assets you don’t need, removed from the triage feed entirely.
Step 3: Review the Vulnerable Assets Overview
In the main dashboard, the Vulnerable Assets page, security professionals can view total asset count, number of exposures, unique vulnerabilities affecting them, and total potentially vulnerable assets—in addition to criticality breakdowns for both domains and IPs.
From there, security teams can drill into:
- Unique vulnerabilities, filterable by CVE or severity
- Domains with vulnerabilities, showing exposure counts by severity and the last exposure date
- Individual asset detail pages, showing products, versions, vendors, and ports, with vulnerabilities linked directly to the specific product version affected
Diving deeper into a surfaced vulnerability provides technical descriptions, solution information, and other affected products. Additionally, Flashpoint’s vulnerability database includes over 105,000 pre-NVD vulnerabilities, giving vulnerability management teams actionable indicators well before they show up in public sources.
Step 4: Set Up Alerting
Flashpoint EASM gives teams full control over signal versus noise. Whether that means getting notified the moment a critical vulnerability is disclosed, or reviewing a daily summary of your own schedule, EASM offers two alert types:
- Asset discovery alerts, either per-asset or as a daily rollup
- Vulnerability alerts, filterable by criticality (critical, high, medium, low), with the option for in-app only or in-app plus email, and available as a daily rollup
Why Flashpoint EASM Matters
- Flashpoint EASM isn’t just another scanning tool. The intelligence underneath it is the differentiator: discovery tells you what’s out there, Flashpoint provides the much-needed context to tell you what’s dangerous right now.
- The intelligence includes coverage that can’t readily be found elsewhere: Flashpoint’s independently researched data includes pre-NVD findings, improved KEV coverage, ransomware risk scoring, and exploit maturity.
- It closes a blind spot teams have quietly lived with: EASM closes shadow IT gaps and surfaces assets sitting outside inventory entirely.
Flashpoint External Attack Surface Management gives security teams a continuous, intelligence-led view of everything a threat actor sees, so organizations can find and fix exposures before they’re exploited. To see it in action in a personalized walkthrough of your own environment, reach out to schedule a demo.
EASM Frequently Asked Questions (FAQs): What Security Teams Want to Know
What makes Flashpoint EASM different from other EASM solutions?
Most EASM tools stop at raw discovery, telling you an asset exists without telling you whether it matters. Flashpoint EASM pairs continuous asset discovery with a triage inbox to cut noise, then maps every asset directly to Flashpoint’s proprietary vulnerability intelligence, all natively inside Ignite alongside CTI and Vulnerability Intelligence. That combination means prioritization is based on real attacker activity, not just an asset inventory, giving remediation teams the exact context they need to proactively address risk.
What makes Flashpoint’s vulnerability intelligence unique?
Flashpoint’s database covers 400,000+ vulnerabilities, including 105,000+ not found in NVD or CVE, often surfaced up to two weeks earlier than public sources. Every entry is enriched with threat-informed context like EPSS scores, ransomware likelihood, exploit maturity, and MITRE ATT&CK mapping, then reviewed by human analysts, not just automated feeds. The result is prioritization based on real-world exploitation risk rather than CVSS alone.
Can existing monitored assets be imported into Flashpoint EASM?
Yes. EASM integrates closely with Flashpoint’s existing assets module, so assets already set up (for example, for compromised credential monitoring) surface automatically during onboarding.
Is there a limit on discovered assets, beyond the 30-keyword cap?
No. The 30-keyword limit only applies to initial seed keywords, to keep that starting set relevant. Once assets are marked owned or external, there’s no cap on ongoing discovery.
How does continuous polling compare to traditional scanning?
Traditional scanners give you a point-in-time snapshot. EASM continuously discovers assets and vulnerabilities, giving you a moving view of your exposure, essentially the same view an attacker would have in real time.
Does EASM identify compound risk, where multiple weaknesses increase exploitability together?
The Vulnerable Assets view surfaces how many vulnerabilities are tied to a given asset, so teams can quickly spot assets carrying disproportionate risk and prioritize accordingly.
Does EASM overlap with SBOM alerting?
Not exactly. SBOM alerting monitors vulnerabilities in assets you already know about. EASM is focused on discovering the assets you don’t know about yet. Most mature security programs benefit from running both in tandem.
See Flashpoint in Action
The post Flashpoint EASM: Industry-Leading Vulnerability Intelligence, Mapped to Your Internet-Facing Assets appeared first on Flashpoint.
Enriched URL Reports: VirusTotal URL Scanning 2.0
Introduction
In today's fast-moving cybersecurity landscape, threat analysts must move beyond basic, binary reputation scores to successfully defend against modern, highly adaptive web threats. Traditional URL analysis has been redefined by the launch of URL Scanning 2.0, an update that significantly expands VirusTotal's URL analysis capabilities by introducing automated visits with a full browser instance and deeper historical visibility.
Instead of relying on static reputation scores alone, URL Scanning 2.0 enriches reports with "under-the-hood" headless browser telemetry, including the DOM, full-page screenshots, web technologies, and network request logs. Crucially, it introduces historical analysis pivoting, giving analysts the ability to track how a page has changed over time.
URL Scanning 2.0
To successfully defend against modern, highly adaptive web threats, threat analysts must move beyond basic, binary reputation scores. With the debut of URL Scanning 2.0, VirusTotal introduces robust headless browser integration that captures how a page behaves dynamically in a clean sandbox environment.
Every scan now generates rich, granular telemetry that provides a blueprint of the target page's execution:
- Headless Browser Data: Full-page visual screenshots, full DOM (Document Object Model) trees, and web technologies (e.g., Cloudflare, PHP, HTTP/3).
- Page and Network Statistics: Highly detailed counters of individual network requests, encrypted HTTPS transactions, unique contacted domains/subdomains, and serving IP address mappings with geographic tracking.
- Anti-Phishing Fingerprints: Automatic identification of brands, cloned-website tags, password input fields, tracker IDs, and favicon dhashes.
- Historical Pivoting: A timeline containing historical analyses of a URL with its corresponding risk score, allowing analysts to track exactly how its metadata and content have shifted over time.
Access Levels in VirusTotal
Public Access (Free for VirusTotal Users)
The core enhancements of the URL Scanning 2.0 engine are available to everyone. For the latest scan, analysts can access rich telemetry generated by headless browser execution, including visual screenshots, extracted JavaScript globals, console messages, and a list of all loaded network resources.
VirusTotal Premium Customers
For paid VirusTotal customers, the platform unlocks deeper retrospective capabilities and exclusive data fields. Analysts have the ability to pivot to and review the full historical analyses of a URL as it was observed at specific points in time, and access advanced telemetry like the full DOM captures of the execution. Furthermore, premium access unlocks advanced infrastructure relationships, allowing users to pivot on contacted domains, IPs, and downloaded files.
Note: The aforementioned Google Threat Intelligence and Automatic Brand Identification features are exclusively available to Google Threat Intelligence customers.
Investigating a Phishing Case
Initially, when an analyst navigates to the mentioned URL to view the report generated by VirusTotal, they would see something similar to the following with the new URL Scanning features:
At the top of the interface, we can see that the URL has been scanned three times. This means there are three distinct reports for the same URL, each potentially containing different information that could be highly useful for an analyst. In the top right corner, we can view these past analyses by clicking on "History".
This is where the new historical analysis pivoting comes into play: it allows analysts to travel back through a URL's timeline with point-in-time snapshots.
By clicking on "History", we can view all the historical analyses for that URL, including response codes, detections, screenshots, and other metadata. You can also apply filters to narrow down the timeline and view only the historical records you are interested in, based on specific response codes, URL actions, and other criteria.
In this case, if we click on the initial historical analysis performed on July 6, 2026 (as shown in the screenshot above), we can examine its specific information across the "Summary", "Details", and "Detection" tabs. A key feature of URL Scanning 2.0 is that the information within these report tabs will dynamically re-render to match the exact historical state of the snapshot you select.
As observed in the history timeline, after clicking on this specific analysis included a live screenshot and other relevant metadata, indicating the scan occurred while the website was fully operational and actively distributed. The previous screenshot gives us a clear view of how the phishing page was visually structured.
Furthermore, diving into the "Details" tab reveals other interesting technical artifacts from the campaign. These details are incredibly useful for pivoting and identifying new malicious URLs that share similar characteristics.
Among the wealth of information generated by URL Scanning 2.0, analysts will find HTTP transactions, detected JavaScript variables, console messages, external outbound links, and other critical metadata. These key technical markers serve as pivotable and searchable attributes, allowing teams to conduct advanced footprint hunting and instantly find other malicious URLs exhibiting the exact same technical fingerprint.
Furthermore, every snapshot taken during each analysis provides the complete Document Object Model (DOM) tree captured by the full browser instances. It allows you to inspect the exact structure of the page as it was dynamically rendered to the victim, exposing elements that static scans might miss. As can be seen in the following image, having direct access to this point-in-time DOM data empowers analysts to dig deep into the page's architecture.
Advanced Threat Hunting: Scaling the Investigation
Let's scale our investigation using VirusTotal Intelligence queries based on the artifacts discovered via URL Scanning 2.0.
During the analysis of the financial phishing site, we discovered that the page relied on static assets hosted on a third-party domain: jiaoyisuo.thai2570[.]com. We can pivot on this finding using an advanced query:
|
VT Query
|
The results demonstrate a multi-brand operation, including fake cryptocurrency exchange portals and typosquatting domains for other financial services. By further pivoting on the hosting domain with entity:domain "thai2570.com", analysts can map out a highly segmented subdomain tree used for hosting assets, capturing payments, and backend control panels.
Conclusion
URL Scanning 2.0 represents a paradigm shift in how security analysts investigate web-based threats. Investigations are no longer limited to static verdicts. By surfacing powerful metadata directly inside the workflow—such as historical DOM captures, live screenshots, and pivotable technical identifiers—analysts can now turn a single indicator into a comprehensive infrastructure map.
Log in to VirusTotal to explore the new URL Scanning 2.0 features today, and consider upgrading to VirusTotal Premium to unlock the full power of historical pivoting and advanced threat hunting.
Batten Down Your Packages: Mitigation Guidance for Supply Chain Compromise
Written by: Kelli Vanderlee, Stuart Carrera
For years, the cybersecurity industry's understanding of software supply chain compromise has been anchored by a few watershed events, including Russian cyber espionage actor ICE RELIC’s (formerly known as APT29) 2020 compromise of SolarWinds and North Korean cyber espionage actor UNC4736's 2023 compromise of 3CX. However, Google Threat Intelligence Group (GTIG) has been tracking growth in threat activity targeting open source software repositories to conduct supply chain compromises over the past several years. A series of large scale open source software supply chain compromise campaigns in 2025 and the first half of 2026 underscore how important it is that organizations implement defensive strategies that directly address this threat vector.
In this blog post, GTIG and Mandiant discuss trends we have observed in threat actor use of software supply chain compromise, and provide mitigation and hardening recommendations that incorporate insights we have developed as a result of supporting customers through recent campaigns in which threat actors manipulated open source packages.
Open Source Supply Chain Compromise Grows in Volume and Impact in 2025 and Early 2026
The majority of the most impactful and far-reaching supply chain compromise incidents that GTIG tracked in 2025 and early 2026 involved the compromise of code repositories, software dependencies and developer tools (T1195.001). Open source supply chain compromises offer attackers the same efficiency, scale, and initial stealth as traditional supply chain compromises, but typically require significantly less planning and resources to execute. However, open source supply chain compromises are also noisy once enabled; malicious open source packages are often discovered and publicized much more quickly than traditional supply chain compromises.
GTIG assesses with high confidence that the growth in very large-scale, open-source supply chain compromise campaigns, including use of worms and iterative compromises in 2025 and early 2026, represent a significant expansion in use of this tactic compared to prior years. We anticipate that threat actors will emulate the tactics of these campaigns and contribute to growth in open-source supply chain compromise through the rest of 2026 and years to come. GTIG identified several notable supply chain compromises in 2025 and early 2026 that we believe exemplify this trend of exceptionally large campaigns, as measured by size and/or impact (Figure 1).
Figure 1: Notable open source supply chain compromises, 2025 - early 2026
For example from February to May 2026, UNC6780 (aka "TeamPCP") conducted extensive open source supply chain compromises targeting ecosystems like PyPI, npm, and Docker Hub. Initial infection vectors varied across incidents, and included abuse of the pull_request_target GitHub Actions trigger to obtain base repository secrets and write permissions. The threat actor typically used compromised packages to deploy credential stealers, including SANDCLOCK, to obtain high value secrets. In incident response engagements, we observed UNC6780 attempting to pivot from compromised artificial intelligence (AI) software to broader network environments. UNC6780 has monetized stolen credentials through either direct sale of the stolen data, or through partnerships with ransomware and data theft extortion groups.
In March 2026, GTIG observed the introduction of a malicious dependency in the legitimate axios package. GTIG analysis and the maintainer's post mortem indicate that the maintainer account was compromised via social engineering and used to publish the updated versions. We identified the malicious dependency as a dropper that deploys the WAVESHAPER.V2 backdoor, and attributes the activity to North Korean actor MIDNIGHT NEPTUNE (formerly known as UNC1069). While the malicious versions of axios were removed from the npm registry within three hours of their release, the scope of the compromise is estimated to be broad, as the package has over 100 million weekly downloads. GTIG supported customers in at least 15 industry verticals and 13 different countries affected by this incident. Further, axios is also a dependency for tens of thousands of other packages, and open sources reported that the malicious axios update had spread to several of these.
AI Likely to Accelerate Open Source Supply Chain Compromises
GTIG anticipates AI will accelerate the growth of open source software supply chain compromise. Integration of AI into open source software development practices, including "vibe coding," increases attacker opportunities both to manipulate AI functionalities and to take advantage of AI to speed and scale their own operational planning. Open sources have documented multiple instances of threat actors planting malicious resources on open source AI communities and inserting malicious code into open source Model Context Protocol (MCP) packages. MCP is a standardized protocol for AI to interact with tools and data. Malicious packages have also tricked AI coding agents, which have unwittingly incorporated them into projects. North Korean threat actors reportedly uploaded malicious cryptocurrency-themed packages, and subsequently an AI coding agent co-authored a commit integrating one of the malicious packages as a dependency to a legitimate cryptocurrency trading project.
Thousands of Malicious Open Source Packages Detected
Corroborating GTIG's findings, statistics compiled by the Open Source Security Foundation (OpenSSF), a cross-industry, non-profit collaboration under the Linux Foundation, indicate that the number of malicious open source software packages identified increased exponentially, or 1,444% from 2024 to 2025 (Figure 2).
Figure 2: Count of malicious open source packages reported 2022–2025 (source: OpenSSF)
Traditional Supply Chain Compromise Remains Rare
In contrast to what we observed in the open source ecosystem, GTIG assesses with high confidence that traditional software supply chain compromise, the manipulation of source code or update/distribution mechanisms (T1195.002), remains rare. The handful of identified cases in 2025 and early 2026 were predominantly cyber espionage incidents with intentionally limited targeting scopes.
In the most significant case, North Korean threat actor UNC4899 reportedly used social engineering to compromise a developer's machine at a web3 organization. The threat actor used this access to inject malicious code into the frontend systems, specifically impacting smart contract functionality to alter transactions initiated by a third party organization that utilized the multi-signature wallet with the targeted organization. This compromise was tailored to a single victim, but did not directly touch the targeted organization's infrastructure. The compromise ultimately led to a cryptocurrency theft of assets with an estimated value of $1.4B USD.
Other examples include the compromise of hosting infrastructure serving updates of Notepad++ from June to December 2025, activity GTIG attributes to UNC6688. GTIG observed organizations in South Korea and France affected by this activity. GTIG also tracked the early 2026 compromise of DAEMON Tools installers. During this campaign, UNC6863 deployed SLICKDEMON to perform broad-spectrum reconnaissance and filter for targets of strategic interest. Following this profiling stage, the group selectively delivered the shellcoded loader BADFALL to facilitate hands-on-keyboard activity and bridge the deployment of the advanced QUIC RAT. The campaign targeted Russia, Brazil, and Turkey, with follow-on exploitation of government and scientific entities in Belarus and Thailand.
In addition to likely cyber espionage incidents, we observed suspected financially motivated compromises with broader distribution. In two separate incidents threat actors compromised underlying software used in consumer-facing websites: in one case, automotive dealership websites served ClickFix lures leading to the installation of SHADOWLADDER (aka SectopRAT), and in another, eCommerce websites were infected with web skimmers.
Mitigation Recommendations
To effectively mitigate and harden against software supply chain compromises, organizations should adopt a multi-tiered defensive strategy designed to minimize exposure and strengthen resilience against potential compromises.
Administrative Oversight and Risk Governance
-
Cataloging Assets and Dependencies: Maintain a tiered, continuous inventory of all applications, third-party vendors, and services based on operational importance to detect single points of failure and security risks.
-
Software Bill of Materials (SBOM): Implement an automated SBOM for all internal and third-party software packages, allowing security teams to continuously monitor and cross-reference active code inventories against newly disclosed vulnerabilities.
-
Action Bill of Materials (ABOM): Maintain a dedicated ABOM to inventory every third-party pipeline vendor and development utility in use, linking it to your container image inventory to track exactly which external actions are building your production images.
-
Software Development Lifecycle (SDLC) Threat Modeling and Attack Chain Mapping (Wiz SITF): Align your software supply chain risk management with capabilities such as the Wiz SDLC Infrastructure Threat Framework (SITF) to transition from treating security as a checklist of isolated controls to a holistic threat model. With this freely available framework, organizations can map recent incidents, threat actor campaigns, and red team exercises directly to Wiz SITF Reference IDs indexing each risk to its specific lifecycle stage: Version Control Systems (VCS), continuous integration and continuous delivery (CI/CD) pipelines, package registries, or production infrastructure. This methodology allows security teams to model complex "attack chains" where minor, isolated weaknesses (e.g., a lockfile bypass combined with an overprivileged pipeline token) are chained together by sophisticated threat actors to execute critical, high-impact breaches
-
Active Risk Monitoring: Maintain a dedicated supply chain risk register and a centralized remediation tracker to systematically group development lifecycle (SDLC) threats into clear operational domains: Governance, Identity, Pipeline Logic, and Supply Chain Hygiene. If using Wiz SITF, each vulnerability must be mapped to its exact pipeline stage with a unique Wiz SITF Reference ID. Instead of treating vulnerabilities as isolated bugs, prioritize the blocking of complex "attack chains" (such as a leaked token combined with missing branch protections and overprivileged OIDC trust) that pose the highest breach risk. Ensure each logged item has a designated owner, a targeted completion date, and clear tracking of technical dependencies.
-
Standardized Configuration & Change Control: Form a Change Advisory Board (CAB) to manage the rollout of all enterprise software and hardware. Ensure every modification includes a pre-deployment risk review, post-deployment monitoring, and a verified plan for recovery or backout.
-
Staff Security Education: Deploy ongoing training initiatives centered on supply chain hazards, social engineering techniques, and internal procedures for reporting incidents.
-
Node.js (npm/pnpm): Enforce cooldown controls by using the
minimumReleaseAgeconfiguration. Setting this value to at least 24 hours (1440 minutes) ensures that freshly published, potentially poisoned packages are quarantined until the broader security community has had time to identify and remove them. Ensure that older, unsupported package manager versions (such as legacy Yarn or pnpm versions) are modernized, as they will silently ignore these cooldown boundaries. -
Python (pip): Ensure that Python project environments do not pull dependencies directly from the public PyPI registry, which bypasses internal release-age policies and gating controls. All configurations must specify a secure, vetted private
--index-urlin their configuration files to ensure consistent quarantine and vetting of upstream packages.
Vendor Lifecycle Management
-
Vendor Security Vetting: Conduct rigorous due diligence prior to procurement by assessing third-party security frameworks against industry standards such as ISO 27001 or SOC 2.
-
Cybersecurity Provisions in Contracts: Integrate specific security mandates into vendor agreements, including strict timelines for incident notification, persistent audit rights, and clear liability terms.
-
Hardware Provenance and Verification: Use supply chain tracing to confirm the integrity of components, establish methods for detecting counterfeit items, and secure the logistics of repairs and replacements.
Security Architecture and Engineering Controls
Identity and Access Management
-
Automated System and Workload Identities: Transition third-party integrations and build-system processes away from static, long-lived administrative Personal Access Tokens (PATs). Instead, mandate the use of dedicated GitHub Apps or short-lived system tokens via federated OpenID Connect (OIDC) for automated machine integrations. This ensures that credentials used by system-to-system workflows expire in a matter of minutes, neutralizing the risk of a persistent compromise if an automation pipeline is breached.
-
Developer and User Identity Controls (command-line interface (CLI) and Repository Access): Enforce strict access control boundaries for programmatic developer sessions. Because Okta-linked SAML SSO is only capable of verifying identity during the initial creation or authorization of personal tokens and keys, continuous session state cannot be challenged over programmatic CLI connections. Therefore, session security must be enforced through credential expiration and hardware-backed controls.
-
Enforce Strict Token Expiration: Strictly limit the allowable lifespan of all personal access tokens (PATs) and programmatic application programming interface (API) keys to a minimum threshold (e.g.a maximum 7-day limit). This guarantees that credentials expire regularly, forcing developers to re-authenticate through the primary SSO gateway.
-
Consider Restricting Personal Access Tokens to Neutralize Git-over-HTTPS & Mandate FIDO2 Secure Shell (SSH): To protect developer environments against credential theft, organizations should consider restricting Personal Access Tokens (PATs) globally across GitHub Enterprise Cloud. Because GHEC has no direct protocol-disable switch, administrators should consider disabling classic PATs and enforcing short token lifespans to effectively block unauthorized programmatic HTTPS connections. This protocol containment helps encourage developers to shift entirely to SSH authentication. To secure this transport layer, consider mandating the use of hardware-backed FIDO2 security keys to cryptographically verify physical token possession for all command-line repository actions.
-
Isolated CI/CD Execution: Utilize ephemeral runners for build pipelines that are purged immediately after completing a single task. This prevents malicious actors from maintaining a persistent presence between different build phases.
-
Workflow Trigger Governance (pull_request_target): Strictly limit and secure the use of highly privileged triggers such as pull_request_target in automated environments. Multiple prominent supply chain campaigns have actively exploited vulnerable workflows using this trigger as their initial entry vector.
Infrastructure Protection
-
Zero Trust and Least Privilege: Maintain rigorous control over managed service providers (MSPs) and third-party vendors by enforcing role-based access control (RBAC), multifactor authentication (MFA), and frequent audits of access rights.
-
Network Micro-Segmentation: Segregate vital hardware and software from the rest of the enterprise network. Use allow-list-only firewall rules to block unauthorized outbound traffic and disrupt command-and-control (C2) activities.
Secure Development Ecosystems
-
Pipeline and Sandbox Isolation: Ensure that testing environments, CI/CD pipelines, and informal scripting sandboxes are physically or logically isolated from production assets.
-
Artifact Management: To secure the supply chain, organizations can integrate Google's Assured Open Source Software into their internal workflows to defend against dependency confusion and malicious hijacking. This process provides "provenance" cryptographically signed evidence that the code has not been tampered with and originates from a verified source thereby establishing a higher level of trust for third-party dependencies.
-
Quarantine Gates: Require all binaries, packages, and container images to be hosted in monitored internal repositories. To defend against zero-day dependency hijackings, implement localized "quarantine gates" by enforcing cooling windows on newly published third-party assets.
-
Lifecycle Script Sandboxing (ignore-scripts): Mitigate the critical threat of arbitrary code execution by disabling the automatic running of package install scripts. Attackers commonly hijack dependencies and add malicious post-installation execution scripts to steal credentials from developer environments and runners during routine installs. Organizations should mandate
ignore-scripts=truein their repository-level .npmrc files and configure native allowlists, such as pnpm'sonlyBuiltDependencies, to restrict execution exclusively to verified, essential tools. -
Software Composition Analysis (SCA) with Google OSV-Scanner: Integrate Google's open source OSV-Scanner tool into CI/CD build pipelines to continuously scan project dependencies for known security flaws. This tool provides an officially supported frontend to the OSV.dev database that maps a project's list of dependencies with the specific vulnerabilities affecting them.
-
High-Fidelity Vulnerability Detection: Unlike traditional scanners that rely on imprecise name matching, the OSV schema stores vulnerability data in a machine-readable format that maps unambiguously onto version ranges and commit hashes. This results in fewer false positives and produces highly actionable remediation notifications, significantly reducing development team triage overhead.
-
Authoritative & Collaborative Threat Intel: The underlying OSV.dev database aggregates high-quality threat intelligence from authoritative open sources, allowing the broader developer community to suggest continuous improvements. Utilizing OSV-Scanner helps developers identify impactful third-party open source vulnerabilities in their applications and focus remediation on genuine risks.
-
Hardware-Backed Key Protection: Secure code-signing certificates using Hardware Security Modules (HSMs) or vaulting solutions. Monitor public transparency ledgers and logs to detect any unauthorized certificate activity.
-
Hardened Distribution Points: Audit and lock down software delivery channels, such as Content Delivery Network (CDN) endpoints and FTP servers, to ensure legitimate binaries cannot be replaced by compromised payloads.
-
Audit NPM Package Maintainer Accounts for Stale or Expired Recovery Email Domains: Expired maintainer email domains are a critical risk because attackers can purchase them to intercept password reset emails, take over the package registry account, and publish malicious code to downstream users. To identify vulnerable packages, organizations can perform the following:
-
Deploy automated scanning tools to audit the entire dependency tree and verify the domain name system (DNS) resolution and registration status of all maintainer email domains.
-
For defense-in-depth, pipelines must disable package execution scripts and employ cold periods.
-
Use by default ephemeral, single-use runners to prevent compromised packages from accessing persistent build environments.
-
Isolate runners in a restricted network segment with strict egress filtering blocks any unauthorized connection to external domains even if an active exploit is triggered.
Integration with Native Ecosystem Guardrails
-
These organization-controlled quarantine policies must operate in conjunction with native platform-level security updates to achieve a Defense-in-Depth posture. Relying solely on client-side configurations or automated update tools in isolation creates single points of failure. The following native platform controls must be orchestrated alongside standard controls:
-
Dependabot Native Cooldowns (July 2026): Dependabot now enforces a default three-day cooldown on version updates to allow for the public discovery of upstream compromises (such as the historical chalk and debug hijackings) before automated Pull Requests are generated].
-
PyPI Server-Side Immutability (July 2026)]: PyPI now natively rejects new file uploads to any release older than 14 days. This prevents adversaries possessing compromised tokens from retroactively poisoning legacy, pinned dependencies (as observed in the LiteLLM and Telnyx compromises) .
-
npm v12 Install-Time Defaults (July 2026): npm v12 disables all lifecycle scripts by default (
allowScripts: off), replacing manual, workflow-level ignore flags with explicit, commit-verified package allow-lists
By explicitly aligning baseline configurations including .npmrc and pip.conf registry pinning, immutable installation protocols via npm ci, and runner isolation with these native platform-level guardrails, while committing to the continuous evaluation and adoption of new upstream security features as they are released, the organization establishes a resilient, multi-layered security boundary across the entire software supply chain
Continuous Verification, Monitoring, and Response
Automated Ingestion and Validation
-
Automate SBOM Management: Implement a Software Bill of Materials (SBOM) for all third-party and internal software. This enables continuous monitoring for emerging vulnerabilities like Log4j through automated cross-referencing. Automate and scale this process by feeding SBOMs into central vulnerability management platforms that continuously cross-reference deployed inventory against newly disclosed exploits.
-
Security Analysis Integration: Incorporate automated dynamic application security testing (DAST) and static application security testing (SAST) tools within development pipelines to identify and block compromised third-party code before it is compiled.
-
Verification of Cryptographic Integrity: Prior to installing updates, use automated systems to validate digital signatures and hashes against vendor-provided specifications.
-
Implement autonomous security verification: Organizations should look to integrate advanced security workflows directly into their CI/CD pipelines. These systems can behaviorally evaluate threats by executing simulations in isolated sandboxes, cross-reference those flags with cloud context to determine a flaw's actual reach, and automatically generate tested code patches to rapidly remediate verified risks at scale.
Proactive Threat Hunting and Monitoring
-
Egress and Proxy Analysis: Establish network traffic baselines to identify suspicious egress flows to external repositories or unrecognized Internet Protocol (IP) addresses.
-
Comprehensive Endpoint Security: Utilize endpoint detection and response (EDR) tools across infrastructure and developer workstations to detect post-execution malicious activities from supply chain compromises.
-
Log Aggregation and Alerting: Unified log management should alert on the following anomalies:
-
Development Systems: Watch for unauthorized code changes, build parameter adjustments, or irregular user activity.
-
CI/CD Integrity: Alert on unauthorized workflow modifications or anomalous triggers (e.g., repository_dispatch) that bypass standard code-review gates.
-
Injection Detection: Monitor logs for shell-escape characters or command-substitution patterns within untrusted input variables.
-
Credential Misuse: Track authentication hits on long-lived static keys from unrecognized IP addresses or regions.
-
Physical Assets: Record all firmware modifications, including installation status and source information.
Incident Response Strategies
-
Specific Supply Chain Playbooks: Perform tabletop exercises and document response plans for:
-
Upstream Package Takeover: Maintainer account takeover (ATO) on public registries leading to direct runtime application code manipulation
-
Dependency Confusion Exploits: Malicious registration of lapsed administrative recovery domains or unscoped internal namespaces on public registries to hijack local developer and build runner installations.
-
Automated Pipeline Harvesting: Pipeline poisoning of CI/CD environments via runner exploitation to harvest credentials and perform unauthorized package publication.
- Developer Workstation & IDE Compromise: Targeted social engineering, malicious IDE extensions, or typosquatted local dependencies designed to exfiltrate private cryptographic keys, API tokens, and local session credentials.
-
-
Operational Re-evaluation: Create processes for immediate vendor re-mapping and security re-assessment during industry-wide security events.
Recommendations for mitigation strategies are also available publicly via:
-
Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (NIST SP 800-161 Rev. 1) from the US National Institute of Standards and Technology (NIST)
-
Securing the Software Supply Chain: Recommended Practices Guide for Developers from the US National Security Agency (NSA)
-
WIZ SDLC Infrastructure Threat Framework (SITF) SDLC Infrastructure Threat Framework
Acknowledgements
This analysis would not have been possible without the assistance of Matthew McWhirt and Michael Veal.
-
Threat Intelligence Blog | Flashpoint

- Demystifying The Com and Nihilistic Violent Extremism: What You Need To Know
Demystifying The Com and Nihilistic Violent Extremism: What You Need To Know
Blog
Demystifying The Com and Nihilistic Violent Extremism: What You Need To Know
In our latest webinar, we explore the rise of Nihilistic Violent Extremism and unpack the digital-to-physical threat landscape of The Com.

Most threat intelligence frameworks were built around clear, recognizable motives—advanced persistent threats seeking intelligence, financially motivated ransomware syndicates, or ideological extremists pursuing political or religious goals. However, security practitioners and physical security teams are facing a vastly different and highly volatile new vector on the threat landscape: Nihilistic Violent Extremism (NVE).
Operating across surface web platforms, niche gaming servers, and encrypted messaging channels, NVE actors seamlessly blend traditional cybercrime, physical violence, real-world property destruction, and severe digital extortion.
In a recent Flashpoint webinar, our analysts took a deep dive into this complex digital threat, fully breaking down the inner mechanics of NVE, its warning indicators, and how cross-functional security teams can proactively monitor and mitigate these dangerous digital-to-physical threats.
Here are the core takeaways from our on-demand webinar that organizations need to understand.
What is Nihilistic Violent Extremism (NVE)?
Nihilistic Violent Extremism (NVE) defines criminal conduct driven by a deep misanthropy and a desire to trigger societal collapse through random acts of chaos, psychological cruelty, and violence. While casual observers might dismiss these activities as extreme “internet trolling” or adolescent angst, Flashpoint recognizes NVE as a digitized, accelerated evolution of long-standing extremist and occult philosophies.
NVE draws heavily from the Order of Nine Angles (O9A), a paramilitary philosophy originally established in the United Kingdom. Unlike traditional movements seeking political control, O9A advocates for the total destruction of modern civilization to force a return to social darwinism.
How NVE Transitioned from Ideological Literature to Gamified Online Terror
The transition of reclusive occult literature into digital networks followed a deliberate path of gamification. Threat actors stripped away the theological texts, replacing them with fast-paced, highly visual media designed to engage younger audiences on gaming platforms and encrypted messaging apps.
These repackaged materials were then adopted by the various groups within The Com, such as 764 and other scavenger cults. By wrapping graphic violence and extremist symbology in internet humor, these groups lower a recruit’s psychological defenses, accelerating their desensitization and drawing them rapidly into higher-harm activities.
Key Tactics, Techniques, and Procedures (TTPs) of NVE
NVE networks represent a primary example of digital-to-physical convergence, where virtual harassment directly manifests as physical security risks. For NVE actors, violence that remains private is considered wasted effort—because their focus is on generating public fear, breaking taboos, and winning peer status polls, publicity is an operational requirement.
Recorded acts of violence serve as the primary currency across all three pillars of “The Com”. To build status, gain access to private channels, or enforce extortion, threat actors rely on a distinct set of operational tactics to create a societal environment of fear and discord, elaborated on in our expert webinar.
The Demographic Realities and Accessibility of NVE Groups
A critical takeaway from the webinar was the demographic profile and accessibility of NVE networks, with participants—both perpetrators and victims—being overwhelmingly young, typically ranging from ages 11 to 22, with a high concentration of juveniles. Additionally, because extreme coercion and abuse are normalized in these spaces, victims are frequently pressured into becoming enforcers against others as a condition to cease their own victimization.
Because of this young demographic, most NVE actors do not rely solely on Tor hidden services. Instead, they recruit, coordinate, and broadcast activities across mainstream social media, open messaging apps, and popular online gaming platforms.
Protect Against NVE Risk Using Flashpoint
Tracking a highly decentralized threat ecosystem where groups form, rename, and dissolve within hours requires specialized, multi-disciplinary intelligence capabilities. Flashpoint provides enterprise security teams, physical safety leads, and CTI analysts with the visibility required to identify and mitigate NVE activity.
To explore the complete webinar discussion, which includes deeper analyst breakdowns of threat actor activity, behavioral indicators, and enterprise mitigation strategies, watch the on-demand recording today.
See Flashpoint in Action
The post Demystifying The Com and Nihilistic Violent Extremism: What You Need To Know appeared first on Flashpoint.
Updated Cyber Threat Actor Naming System
Update (July 30): A table listing the new names of select prominent threat actors was appended to this post.
Introduction
Today, Google Threat Intelligence Group (GTIG) will begin rolling out a unified naming schema for tracking threat actors. This new naming taxonomy represents an effort to standardize tracking across platforms and public reporting.
Why are we Adopting a Different Naming System?
Historically, Mandiant and Google’s Threat Analysis Group (TAG) maintained distinct tracking systems, relying on parallel naming schemas that grew independently over time. The creation of GTIG has necessitated a new, fused tracking system, and a new naming system. Thinking to the future, GTIG’s new system will rely on cryptonyms. Relying on sequential numbers or disparate identifiers (e.g. APT1) fails to provide defenders the critical context needed to operate quickly. Threat tracking shouldn’t be an exercise in memorization, but rather one of intuition. The new naming convention aligns with industry standard threat actor naming systems.
Our New Schema
Our new schema utilizes a cryptonym-based approach, employing memorable two-word combinations for each distinct threat actor:
-
The first word is a unique and memorable term chosen to represent the specific actor, particularly names that may have been used in prior public reporting. If no previously used term exists, this word is randomly generated to remove bias, then vetted by our analysts.
-
The second word categorizes threat clusters by motivation, attribution, or activity type based on which category we consider to be most important for defense and response strategies.
The table below provides a sample of how threat actor categories will map to the second word in each cryptonym:
|
Origin or Type |
Group Name |
|
People’s Republic of China |
CASTLE |
|
Iran |
ION |
|
North Korea |
NEPTUNE |
|
Russia |
RELIC |
|
Cybercriminal |
COMET |
Table 1: Examples of Google’s new threat actor naming system categories
We know there are many threat actor tracking schemas in the industry, so we are intentionally seeking to keep this system as simple as possible to streamline operations and facilitate mapping to other naming taxonomies. However, a significant caveat remains: because no two organizations have the exact same visibility into the threat landscape, direct, apples-to-apples comparisons between threat actors are rarely possible. Transitioning to a convention that is simpler to follow and remember is a practical step toward managing a highly intricate tracking problem.
A Work in Progress
We have initially prioritized renaming several dozen of the most active groups, and will continue this process on a rolling basis. Previous names will remain indexed and searchable in the Google Threat Intelligence (GTI) platform, with MITRE ATT&CK mappings and other vendor aliases preserved, see Figure 1.
Figure 1: Threat actor name appearance in GTI platform on initial rollout
We will continue to use UNC, or “uncategorized” designations for threat clusters that are still in the early stages of investigation, as described here.
Selection of Re-Named Threat Actors
|
Origin or Type |
Previously Used Names |
New Names |
|
Cybercriminal |
FIN11 |
RAZOR COMET |
|
Cybercriminal |
FIN6 |
SQUID COMET |
|
Cybercriminal |
FIN7 |
WILD COMET |
|
Cybercriminal |
FIN8 |
PUNCH COMET |
|
Iran |
APT33 |
BLEAK ION |
|
Iran |
APT34 |
SOLAR ION |
|
Iran |
APT35 |
RICH ION |
|
Iran |
APT39 |
CINDER ION |
|
Iran |
APT42, CALANQUE |
CALANQUE ION |
|
Iran |
TEMP.Zagros, MUDDYCOAST |
MUDDY ION |
|
North Korea |
APT37 |
PLAIN NEPTUNE |
|
North Korea |
APT45 |
GRASS NEPTUNE |
|
North Korea |
UNC1069, MASAN |
MIDNIGHT NEPTUNE |
|
North Korea |
Temp.Hermit |
HERMIT NEPTUNE |
|
People’s Republic of China (PRC) |
APT15 |
RIVER CASTLE |
|
PRC |
APT20 |
RIDGE CASTLE |
|
PRC |
UNC1088 |
RAVINE CASTLE |
|
PRC |
APT27 |
SHORE CASTLE |
|
PRC |
APT30 |
ISTHMUS CASTLE |
|
PRC |
APT31 |
TIDE CASTLE |
|
PRC |
APT40 |
ISLAND CASTLE |
|
PRC |
APT41 |
SPIRE CASTLE |
|
PRC |
APT5 |
BASALT CASTLE |
|
PRC |
Tonto Team |
LONE CASTLE |
|
PRC |
TEMP.Tick |
TICK CASTLE |
|
PRC |
UNC2814 |
DARK CASTLE |
|
PRC |
Naikon Team |
NAIKON CASTLE |
|
PRC |
Conference Crew |
CONFERENCE CASTLE |
|
PRC |
TEMP.Hex |
BASIN CASTLE |
|
PRC |
TEMP.Overboard |
CAVERN CASTLE |
|
Russia |
APT28, FROZENLAKE |
LAKE RELIC |
|
Russia |
APT29, ICECAP |
ICE RELIC |
|
Russia |
APT44, FROZENBARENTS |
SANDWORM RELIC |
|
Russia |
UNC4057, COLDRIVER |
COLD RELIC |
|
Russia |
TEMP.Vermin |
VERMIN RELIC |
|
Russia |
Turla Team |
TURLA RELIC |
Table 2: Selection of Re-named Threat Actors
Intelligence Insights: July 2026
-
Threat Intelligence Blog | Flashpoint

- The Flashpoint Method: Prioritizing Vulnerabilities in an Era of AI-Accelerated Discovery
The Flashpoint Method: Prioritizing Vulnerabilities in an Era of AI-Accelerated Discovery
Blog
The Flashpoint Method: Prioritizing Vulnerabilities in an Era of AI-Accelerated Discovery
We outline Flashpoint’s practical, repeatable framework for prioritizing vulnerabilities based on real-world risk, exploitability, and business impact.

Organizations are gaining new ways to identify vulnerabilities at scale, thanks to new generations of powerful AI models. However, security teams still face the same fundamental question: which vulnerabilities actually matter?
Vulnerability management teams have increasingly struggled to keep pace with growing disclosure volumes. From January 1, 2026 to June 30, 2026, Flashpoint tracked 21,667 vulnerabilities, an 8% period-over-period increase, with one-in-five containing publicly available exploit code at time of disclosure. At the same time, the gap between disclosure and exploitation continues to shrink, with some vulnerabilities weaponized in as little as 24 hours.
Flashpoint’s Method for Threat-Informed Vulnerability Prioritization
Recent developments such as Anthropic’s Mythos model have highlighted the growing potential for AI-assisted vulnerability discovery. As advances in code analysis enable researchers and organizations to identify software flaws at unprecedented speed and scale, the volume of discovered vulnerabilities is set to potentially increase significantly across software ecosystems.
That’s why we created this guide, The Flashpoint Method for Threat-Informed Vulnerability Prioritization, a practical, intelligence-driven framework designed to help vulnerability and exposure management teams cut through the AI-driven noise and focus on the vulnerabilities that matter most. By incorporating real-world exploitation activity, threat actor behavior, asset exposure, business context, and remediation considerations, organizations can make faster, more informed decisions and reduce risk more effectively.
Download to gain:
- A clear, threat-informed prioritization framework: How to assess which vulnerabilities demand immediate attention, and why — moving beyond static severity scores alone.
- Core and expanded prioritization checklists: Criteria spanning asset criticality, active exploitation, CVSS severity and ransomware risk, social risk and community chatter, business context, compensating controls, zero-day status, KEV inclusion, EPSS scoring, ease of remediation, and vulnerability age.
- How to operationalize prioritization at AI scale: Insight into how Flashpoint’s vulnerability intelligence platform and analyst expertise help teams keep pace as AI-assisted discovery accelerates disclosure volume.
Prioritize Vulnerabilities More Effectively and Faster Using Flashpoint
While increased visibility into vulnerabilities is ultimately a positive for defenders, it amplifies a challenge security teams already face—separating which vulnerabilities represent meaningful risk to your environment and require immediate action.
Download The Flashpoint Method for Threat-Informed Vulnerability Prioritization to learn how Flashpoint’s vulnerability intelligence helps organizations triage, prioritize, and remediate risk more effectively.
Frequently Asked Questions (FAQ)
What is threat-informed vulnerability prioritization?
Threat-informed vulnerability prioritization is the process of evaluating vulnerabilities based on real-world risk rather than severity scores alone. It incorporates factors such as active exploitation, exploit availability, threat actor activity, asset exposure, business context, and remediation considerations to determine which vulnerabilities require immediate attention.
Why is vulnerability prioritization important?
Organizations face thousands of newly disclosed vulnerabilities each year, while security teams have limited time and resources to remediate them. Effective vulnerability prioritization helps organizations focus on the vulnerabilities most likely to be exploited and most likely to impact their environment.
How is AI changing vulnerability management?
AI-assisted code analysis is enabling researchers and organizations to identify software flaws faster and at greater scale. While increased visibility into vulnerabilities benefits defenders, it also increases the volume of vulnerabilities that security teams must evaluate, making effective prioritization even more important.
Why isn’t CVSS enough for vulnerability prioritization?
CVSS provides a standardized measure of technical severity, but it does not account for whether a vulnerability is actively being exploited, relevant to your environment, or likely to impact your business. Effective prioritization combines severity with threat intelligence and organizational context to assess real-world risk.
How does Flashpoint help organizations prioritize vulnerabilities?
Flashpoint combines analyst-driven vulnerability intelligence with real-world exploitation data, threat actor insights, asset exposure, and business context to help organizations identify the vulnerabilities that pose the greatest operational risk. This intelligence supports faster, more informed remediation decisions and operationalizes threat-informed vulnerability management at AI scale.
See Flashpoint in Action
The post The Flashpoint Method: Prioritizing Vulnerabilities in an Era of AI-Accelerated Discovery appeared first on Flashpoint.
-
Threat Intelligence Blog | Flashpoint

- Understanding Illicit Ecosystems: Inside Rehub’s Rise as a Primary Ransomware Marketplace
Understanding Illicit Ecosystems: Inside Rehub’s Rise as a Primary Ransomware Marketplace
Blog
Understanding Illicit Ecosystems: Inside Rehub’s Rise as a Primary Ransomware Marketplace
As part of our ongoing series, Flashpoint intelligence tracks Rehub, breaking down its migration, infrastructure, and the various RaaS groups sponsoring and partnering with it.

What is Rehub?
Rehub, also known as ReHub or RehubCom, is a Russian-language cybercrime forum founded in August 2025 by a former XSS moderator following its shutdown in the summer of 2025. Rehub dedicates itself to the commercial and marketplace use of ransomware, while its counterpart, DamageLib, serves as a knowledge base archive and exchange.
Operating both on Clear Web domains and an onion domain, the forum positions itself as free from state and law enforcement interference, framing existing XSS iterations as compromised. After law enforcement seized the RAMP (RAMP4U) forum in January 2026, Rehub absorbed a significant portion of the displaced cybercriminal community and became one of the primary destinations for ransomware operators.

Who Are Known Members of Rehub?
There are many notable threat actors among Rehub moderators and users, including ransomware operators, vendors, and other prominent threat actors active across several illicit communities. Several current or ex-Rehub moderators were also maintainers of other illicit forums such as XSS, DamageLib, and RAMP.
Notably, Ransomware-as-a-Service (RaaS) groups such as DragonForce have maintained an active presence on the platform to market their affiliate programs. Flashpoint assesses that DragonForce is likely the forum’s primary sponsor or partner, as their banner is permanently displayed on the forum’s home page, with both logos merged—similar to its previous placement on RAMP.

Other active RaaS include:
- The Gentlemen
- CHAOS ransomware
- Anubis
- LockBit
- DevMan
What Does Rehub Infrastructure Look Like?
As of July 2026, Flashpoint intelligence observes over 8,300 active users, 15,000 posts, and nearly 3,000 threads. Despite being free to join, Rehub practices a zero trust policy, which was established in mid-April 2026. Under this system, the forum restricts newly registered users from accessing any section other than its Sandbox. Users can also purchase paid upgrades:
- Premium status (gold rank): Costing US $100 per year, this rank grants distinctive color, custom title, nickname changes, unlimited post editing/deletion, extended signature, unlocks all hidden text regardless of post count, likes, join date, ability to bump commercial threads, and inherits all lower-tier perks.
- Patron status (pink/magenta rank): Costing US $5,000 per year, this rank grants custom title editing, a personal profile link, custom styling for posts, profile, and postbit, and inherits all “Premium” perks.

What are the Various Rehub Forum Sections?
Rehub sections, similar to other forums, are grouped by major activities, separating the knowledge base from commerce and from general discussions.

Sandbox
Serves as an entry-level general discussion area and a place for community questions. Main activity consists of queries about operational security, introductory networking, and entry-level fraud or malware logistics.
Technical
Covers threads ranging from traditional network infrastructure vulnerabilities to emerging technologies such as AI jailbreaking and deepfake social engineering. Highly active, most communications focus on network vulnerabilities and carding.
Programming (Development)
This is a dedicated space for discussions on software engineering, system administration, and web optimization within the forum. Primary activities include sharing programming language tutorials, comparing backend technologies, and developing specialized automation tools.
Library
Serves as a repository of resources for the forum, hosting the most threads and community engagement. Users share operational materials, leaked databases, and utility software. Additionally, this section aggregates cybersecurity and tech industry news and articles.
Supermarket
This is a commercial section featuring ransomware affiliate programs, compromised network access, malware tools, stolen financial data, bulk spam infrastructure, forged documents, anonymous hosting, and crypto laundering services.
Arbitration
Serves as the forum’s internal justice system, where members resolve financial disputes and flag scammers. The “Black List” subsection functions as a public record of bad actors and scam sites.
Administration
This is where forum staff post announcements, policy updates, and operational notices, including rules, official domains, forum news, moderator applications, and 2FA requirements. Members use it to ask questions, request escrow services, propose features, and raise concerns about the forum’s public image.
Monitor Illicit Marketplaces Using Flashpoint
Flashpoint will continue to monitor Rehub’s marketplace activity and infrastructure updates. Rehub’s rapid evolution from a post-XSS refuge to a heavily sponsored ransomware marketplaces demonstrates the resilience of the cybercrime ecosystem.
Positioning itself as the primary ransomware marketplace, Rehub has built a high-barrier, high-reward environment for sophisticated threat actors. Request a demo to learn how Flashpoint delivers visibility into illicit communities—empowering security teams to track threat actors, identify exposed assets, and mitigate ransomware risks.
See Flashpoint in Action
The post Understanding Illicit Ecosystems: Inside Rehub’s Rise as a Primary Ransomware Marketplace appeared first on Flashpoint.
-
Threat Intelligence Blog | Flashpoint

- Inside Qilin Ransomware: Custom Rust Loader and Kernel-Level EDR Killer
Inside Qilin Ransomware: Custom Rust Loader and Kernel-Level EDR Killer
Blog
Inside Qilin Ransomware: Custom Rust Loader and Kernel-Level EDR Killer
In this post we analyze Qilin ransomware’s new custom Rust loader, break down the inner workings of its sophisticated kernel-level EDR killer, and explore how organizations can defend against these aggressive defense evasion tactics. Flashpoint customers can access the full intelligence report—complete with deeper technical analysis and all associated IOCs—directly within Flashpoint Ignite.

Qilin ransomware is a highly active and sophisticated ransomware operation that has rapidly modernized its evasion techniques. Historically focused on file encryption, the ransomware-as-a-service (RaaS) group has expanded its operations to include aggressive, kernel-level defense evasion. By deploying a specialized toolkit, Qilin now focuses heavily on blinding and permanently disabling endpoint security products before its main ransomware payload is executed on a victim’s network.
Flashpoint has observed Qilin quietly deploying a previously unreported custom packer, which has been actively observed in wild samples since May 2024, with continuous use detected as recently as last month.
Here’s how Qilin works:
How Qilin Ransomware Uses a Custom Rust Loader for Reflective PE Loading
Flashpoint analysts observed a custom Rust-written loader that performs reflective Portable Executable (PE) loading of the ransomware payload. After deobfuscation, the code execution jumps to the newly unpacked executable within the same process, avoiding noisier process injection techniques. The following is an overview of the decompiled unpacking routine:

The unpacking routine then reads each DWORD from the embedded bytes, allocates it on the heap, and performs multiple mathematical operations to deobfuscate. Flashpoint notes that the calculations and values used were unique to each sample, but the underlying methodology remained the same.
Manually performing the calculations in the sample confirms the presence of the embedded binary, with the first deobfuscated DWORD yielding an ‘MZ’ header in little-endian format.
To better understand Qilin, Flashpoint analysts created an automated unpacker and configuration extraction script that uses CPU emulation to address the issue of unique calculations per sample. This script uses pattern matching to locate the unpacking routine within the binary. It then reads the disassembly, identifying specific points in the code at which emulation should start and stop.

Reading the disassembly directly avoids issues arising from hardcoded offsets, such as when threat actors add or remove code, or when the compiler introduces changes. Additionally, it provides a smaller set of instructions for emulation, avoiding WinAPI calls and other invalid memory errors that often occur when emulating a full binary.
After additional setup, including mapping the sample into the emulator’s memory and creating a fake heap, the unpacking routine runs successfully.

The script then performs configuration extraction from the deobfuscated bytes produced by the CPU emulation, achieving a 100% success rate.

How Qilin’s New EDR Killer Blinds Security Products
An additional update with Qilin is its new endpoint detection and response (EDR) killer, which Flashpoint found to be sold on illicit marketplaces for US $2,000. This is packed via the Shanya packer—which was sold on XSS for US $100 to US $150 back in 2024. The packer is highly sophisticated, and uses several techniques that make it difficult to analyze, such as junk code, application programming interface (API) hashing, IAT hooking, pattern scanning, and VEH code execution flow.
Once unpacked, the EDR killer starts by using dynamic API hashing and PE walking to resolve a number of useful NTAPI functions it will use throughout the process, and stores them in a structure located within the GdiHandleBuffer within the Process Environment Block (PEB).
The structure stored in the PEB itself looks as follows:

The API hashing algorithm is simple: it performs a bitwise OR of each character of the API name with hexadecimal value 0x20 to convert any and all uppercase characters to lowercase, then performing additional simple calculations.
The EDR killer compares the returned locale to a known locale blacklist to avoid attacking any Commonwealth of Independent States (CIS) countries such as Russia and Belarus.
The malware then attempts to give itself the following privileges by dynamically resolving and calling RtlAdjustPrivilege():
- SE_PROF_SINGLE_PROCESS_PRIVILEGE
- Required to gather profile information for a single process.
- Used later to create a map of the victim machine’s physical memory space.
- SE_DEBUG_PRIVILEGE
- Required to debug and adjust the memory of a process owned by another account.
- SE_LOAD_DRIVER_PRIVILEGE
- Required to load or unload a device driver.
Abusing Vulnerabilities to Map Physical Memory
The EDR killer then writes a vulnerable driver to disk and loads this driver via Service Manager. This driver is the ThrottleStop driver from TechPowerUp LLC’s free and legitimate application of the same name, used to bypass CPU throttling. However, the driver suffers from a vulnerability, allowing the malware to map physical memory to kernel-mode virtual memory to perform direct kernel read and write operations.
Qilin weaponizes this vulnerability by feeding its EDR killer physical memory addresses, as the driver relies on the API to map physical memory to a kernel-mode virtual address. To achieve this, the EDR killer builds a physical memory map using a Windows memory management service that preloads frequently used applications into RAM.
- First it gathers baseline information about all physical memory blocks. Because memory pages (typically 4KB) are allocated to physical blocks, hundreds of virtual pages can point to a single physical range.
- It then calls the service to obtain detailed Page Frame Number (PFN) details. The malware stores this complete mapping in a global variable, giving it a reliable, built-in translation table between virtual and physical memory spaces.
Bypassing Driver Signing Checks
To run its own malicious tools, the EDR killer must first bypass Windows’ driver signing enforcement. Normally, Windows uses a built-in verification check to block unsigned or blacklisted drivers from loading. The malware tricks Windows into disabling this gatekeeper using a simple swap:
- The malware finds a specific kernel function and uses its physical memory map to pinpoint its location.
- It commands the vulnerable driver to scan this memory area for a specific byte signature. This leads directly to the Code Integrity callback table.
- Within this table, the malware locates the built-in verification check and “patches” it with a harmless, dummy function.
Blinding Security Products
With driver signing checks completely bypassed, the malware uses its read/write primitives to dismantle system callbacks, it identifies and targets:
- Process notify callbacks
- Thread notify callbacks
- Image load notify callbacks
- Registry callbacks and minifilters
Rather than conducting a blanket unlinking of all system callbacks, the EDR killer checks the address of each callback. If the address falls within a memory range owned by a security product on its hardcoded blacklist, Qilin surgically unlinks it by zeroing out the pointer with null bytes.

Next, the EDR killer drops and loads its own custom driver, which appears to Windows as purpose-built. Once loaded, the Qilin EDR killer gets all relevant running processes. For any processes running that match a hardcoded list, it stores the Process ID in a vector.
For every PID found, the malware sends a message to a driver. At a high level, the driver finds the full path of the target executable, makes it unreadable, unwriteable, and undeletable to any and all users, and then terminates the process.
Interestingly, the Qilin EDR killer performs a Discretionary Access Control List (DACL) modification on the target security product executable. The driver creates a new empty ACL header and sets the flag SE_DACL_PRESENT to TRUE. This is significant because a null DACL and empty DACL are not the same. A null DACL grants everyone access, whereas an empty DACL grants no access. This process makes it so that the security product’s executable can no longer be executed without needing to delete the file like other EDR Killers. Once the driver then terminates the executable, it can’t be restarted.

Once everything is completed, the EDR killer unpatches the Code Integrity Check to avoid triggering PatchGuard and then exits.
Defend Against Qilin Using Flashpoint
The sophisticated kernel-level manipulation highlights a rapidly expanding trend in the broader threat landscape: the proliferation of highly effective malware designed purely to disable enterprise-level security products. Qilin’s integration of these techniques demonstrates how the EDR killer market is maturing in the cybercrime underground, transitioning from a niche capability into a standard prerequisite for high-impact ransomware operations.
As security platforms continuously improve their detection mechanisms, Flashpoint believes the threat landscape surrounding anti-EDR tools will only grow larger and more aggressive, forcing organizations to focus on protecting the kernel and detecting rogue driver deployments. To learn more about Qilin and the latest advancements in ransomware, request a demo.
See Flashpoint in Action
The post Inside Qilin Ransomware: Custom Rust Loader and Kernel-Level EDR Killer appeared first on Flashpoint.
Demystifying AI Exploits: A Blueprint for AI-Assisted Vulnerability Management
Written by: Jules Czarniak
Introduction
As highlighted in the Mandiant M-Trends 2026 report, the mean time-to-exploit (TTE) has dropped to -7 days, meaning vulnerabilities are often exploited a week before a patch even exists.
To keep pace, many security teams are exploring how to integrate large language model (LLM) agents into their codebases, development environments and continuous integration and continuous delivery (CI/CD) pipelines for automated vulnerability discovery and remediation. However, deploying privileged artificial intelligence (AI) agents without mature integration processes introduces new architectural risks.
In response to customer inquiries about how to safely integrate AI capabilities into vulnerability management workflows, this blog provides actionable guidance from Mandiant Consulting about how to establish operational guardrails for AI assisted vulnerability management, including several detailed scenarios. What each of these examples show is that security teams can accelerate workflows with AI while also upholding the structural integrity of their environments. We suggest that combining AI capabilities with deterministic controls and human intelligence in strategic ways maximizes benefits and reduces risk.
Establish Operational Guardrails to Safely Deploy AI Agents
To safely adopt advanced AI capabilities without introducing unpredictable failures into deployment pipelines, organizations should ground their approach in established industry standards. While guidelines like the NIST AI Risk Management Framework (RMF) and the OWASP Top 10 for LLMs provide comprehensive baselines for identifying risks, operationalizing these controls requires a structural blueprint.
Frameworks like Google’s Secure AI Framework (SAIF) and Google’s approach to secure AI Agents provide a practical path forward, demanding that organizations extend existing deterministic controls directly into the AI execution environment. When deploying AI agents, security teams should navigate specific operational and structural risks:
-
Pre-agent data security and Defense-in-Depth: Agents should not be able to access personally identifiable information (PII), protected health information (PHI), or other sensitive data. Organizations should enforce data security before the prompt reaches the model. This includes strictly using non-production environments populated with synthetic data for testing. For production, security teams should deploy a hybrid defense-in-depth model. This includes Layer 1 deterministic policy engines acting as chokepoints, alongside Layer 2 reasoning-based defenses like specialized guard models (such as Model Armor or similar provider-agnostic guardrails) to filter out sensitive data and block malicious prompt injections before they reach the agent layer. Crucially for vulnerability discovery, security teams should treat the codebase itself as an untrusted input. Threat actors can embed indirect prompt injections within source code comments or third-party dependencies (e.g., hidden instructions telling the agent to ignore vulnerabilities or exfiltrate environment variables), making input sanitation a requirement even for internal scanning.
-
Cloud provider limitations and zero data retention (ZDR): Many cloud and LLM providers block or throttle automated offensive security probing by default to prevent abuse. Organizations should establish clear rules of engagement and authorized testing agreements to navigate acceptable use policies. Furthermore, organizations should enforce strict zero data retention (ZDR) agreements with their LLM providers to guarantee that proprietary code and discovered vulnerabilities are never used to train external models.
-
Workload isolation: Agent workloads should execute in strictly isolated, unprivileged containers with dynamically limited privileges. By relying on robust sandboxing to prevent privilege escalation, if an agent hallucinates a destructive command or is hijacked via prompt injection, the blast radius remains contained.
-
Red Teaming: Before deploying autonomous vulnerability scanners that can dynamically spin up sandboxes and execute code, organizations should subject the AI agents themselves to human-led red teaming as part of comprehensive assurance efforts. This validates the agent's resilience against jailbreaks, recursive logic loops, and complex prompt injections, ensuring the security tooling does not become the attack vector.
-
Least-Privileged Machine Identities and Human Controllers: While workloads should be isolated, agents inherently require privileges to generate pull requests and commit code. Security teams should ensure these agents operate under distinct, strictly scoped machine identities that tie back to human controllers to ensure accountability and user consent. Organizations should use short-lived, just-in-time (JIT) tokens bound exclusively to the specific repository and branch under review. This enforces the principle of limited agent powers and ensures that even if an agent’s container is compromised via prompt injection, the threat actor cannot pivot to modify adjacent enterprise codebases.
-
Supply chain resilience for skills: As developers augment AI with third-party skills and model context protocol (MCP) servers, security teams should treat these integrations as untrusted supply chain components. MCP plugins introduce the risk of supply chain poisoning, where a previously benign integration is silently updated with malicious dependencies. Additionally, security teams should evaluate the underlying agent orchestration frameworks themselves (e.g., LangChain, AutoGen) for inherent vulnerabilities, such as session memory poisoning or recursive loop hijacking.
-
Toxic flow analysis (TFA) and Observable Actions: The objective of TFA is to monitor data paths at runtime, ensuring agents do not exfiltrate sensitive internal context to unvetted external endpoints. Agent actions, inputs, reasoning, and outputs must be fully observable and transparently logged. While implementing dynamic taint tracking for LLMs remains a complex architectural challenge, organizations should clearly separate this runtime observability from static supply chain controls. Integrating threat intelligence to hash and vet incoming agent tools provides a necessary baseline for verifying integrity before deployment. However, because static controls cannot address behavior post-deployment, mitigating data exfiltration ultimately requires active runtime monitoring and secure, centralized logging to trace and restrict the actual flow of data.
Figure 1: Visual representation of an isolated AI agent environment using SAIF mechanisms
By operationalizing these tools within frameworks that demand verifiable integrity and structural resilience, organizations can safely bridge the gap between AI velocity and enterprise defense.
The need for human-led threat modeling
While LLMs excel at identifying syntax patterns, source code itself rarely contains the full picture of unwritten business intent. Some organizations attempt to solve this by connecting LLM agents to internal wikis, design documents, and issue trackers using retrieval-augmented generation (RAG).
While RAG gives the model access to external business context, it is not a perfect fix. Corporate documentation is frequently stale, contradictory, or incomplete. An AI agent might retrieve an outdated architecture diagram and confidently hallucinate a secure path that no longer exists in production. Because LLM agents struggle to resolve conflicting, undocumented human assumptions, human-led threat modeling remains a critical security control across both legacy applications and modern agent workflows.
Security teams should apply threat modeling during both the pre-build system design phase to establish a secure foundation, and during post-build architecture reviews. While an AI agent might successfully identify a poorly configured internal endpoint locally, a human threat modeler asks the structural question: why does that microservice possess broad database read permissions in the first place?
Identifying architectural vulnerabilities requires reasoning about business risk, data sensitivity, and operational constraints. To structure this process, organizations can use industry frameworks like PASTA (Process for Attack Simulation and Threat Analysis) or service offerings like the Mandiant Threat Modeling Security Service to map trust boundaries, uncover structural design flaws, and prioritize compensating controls. Securing fundamental architecture through human oversight is a necessary component when relying on automated agents to find bugs in a poorly designed system.
Once these AI agents are safely sandboxed, as guided by SAIF, and the architecture is verified through threat modeling, organizations can typically apply them to two different problem spaces: Enterprise Vulnerability Management (to assist in managing the volume of known CVEs in commercial off-the-shelf (COTS) software and infrastructure) and Product Security (to identify vulnerabilities in 1st-party (1P) code).
Track 1: Enterprise Vulnerability Management
Foundational security and discovery
While the second track of this post explores how AI agents can uncover complex zero-days in custom code, organizations should manage the scale of enterprise infrastructure in tandem with these AI deployments. Even as new AI capabilities dominate headlines, organizations should still address foundational security challenges, such as secrets sprawl, unmanaged service accounts, missing FIDO2 MFA, and legacy VPN concentrators. Although vulnerability exploitation was the primary initial infection vector in intrusions Mandiant investigated last year, threat actors consistently rely on missing foundational controls and unpatched edge devices to secure and escalate their foothold after exploiting a vulnerability.
Furthermore, AI cannot replace foundational visibility. As security teams deploy AI agents, they should simultaneously close these tactical entry points by maximizing dynamic discovery capabilities like External Attack Surface Management (EASM), Cloud Security Posture Management (CSPM), and Continuous Threat Exposure Management (CTEM). In hybrid and cloud environments, tools like Wiz can be used to map this initial footprint.
Risk-based vulnerability management
Vulnerability management teams are already overwhelmed by the current volume of findings generated by traditional scanners. As organizations scale dynamic discovery tools, such as EASM, CSPM and CTEM, alongside automated AI agents, this influx of findings will compound the problem. To manage this influx, telemetry from these diverse discovery methods must first be normalized and deduplicated. This normalized data serves two purposes: it feeds directly into the risk engine, and it acts as a live overlay to correct stale records in the configuration management database (CMDB). By evaluating the deduplicated vulnerabilities alongside this newly updated asset context and frontline threat intelligence, the RBVM engine calculates a custom risk score that allows security teams to dynamically prioritize remediation.
A mature RBVM methodology calculates a customized risk score on a 0 to 100 scale using a weighted average. A sample formula for calculating this risk-based score is:
Final Score = (W_1 * S_vuln) + (W_2 * S_asset) + (W_3 * S_threat)
The variables and weights (W) are customized to the organization's risk appetite (for example, 0.20 for vulnerability, 0.40 for asset, and 0.40 for threat, summing to 1.0), while the underlying variables (S) are scored on a 0 to 100 scale and defined as follows:
-
Vulnerability severity (S_vuln): The inherent technical severity of the flaw. This is calculated by taking the CVSS Base Score (which natively accounts for confidentiality, integrity, and availability impact) and multiplying it by 10.
-
Asset context (S_asset): A combined metric of exposure and data sensitivity. Scores range from 100 for internet-facing assets holding customer data, down to 25 for internal-only assets with no sensitive data. To translate this impact into monetary terms for non-technical stakeholders, organizations can incorporate Factor Analysis of Information Risk (FAIR) principles into this metric. However, this approach requires highly accurate, continuously updated financial data that many enterprises struggle to maintain at scale.
-
Threat context (S_threat): The real-world urgency of the vulnerability. Scores range from 100 if actively exploited by threat actors relevant to the organization's profile, 75 if a proof-of-concept exists or if it is a vulnerability class easily exploited by autonomous AI agents, down to 25 if the exploit is theoretical and highly complex. Organizations should also map the Exploit Prediction Scoring System (EPSS) probability percentage directly into this variable. This allows the threat score to automatically scale up or down as real-world exploitation telemetry shifts, aligning static vulnerability data with active threat intelligence.
An asset's customized risk score should directly influence internal remediation service-level agreements (SLAs), unless external compliance-driven mandates, such as CISA Binding Operational Directives (BODs), or relevant equivalents, override internal prioritization. A risk-driven and threat-intelligence-driven vulnerability prioritization methodology will help organizations focus resources on managing and mitigating the most critical security vulnerabilities first. This is an area where LLMs can support the vulnerability management process, particularly by helping teams synthesize unstructured threat intelligence to surface relevant risk contexts more efficiently. Enforcing strict SLOs for patching, while requiring formal risk acceptance documentation for any patching exceptions, will help reduce the number of vulnerabilities available to threat actors and increase the visibility of outstanding risks across the organization. Furthermore, organizations should integrate RBVM data directly into their security orchestration, automation, and response (SOAR) platforms for automated alert enrichment.
Figure 2: Integration points of a risk-based vulnerability management (RBVM) program.
Containment and Observability
Modern architecture blueprints must prioritize attack surface reduction under the assumption that vulnerabilities will inevitably be exploited. Moving away from traditional perimeter defenses, organizations should align with zero trust principles, ensuring that security boundaries are established around every asset, workload, and identity.
A component of this alignment is the implementation of strong authentication principles. Organizations should eliminate implicit trust by enforcing continuous, context-aware authentication and authorization. Utilizing Zero Trust Network Access (ZTNA) solutions, such as Identity-Aware Proxies (IAP), shields critical management interfaces (e.g., SSH, RDP) and internal systems from direct internet exposure, granting access only to verified identities and compliant devices.
For public-facing applications and APIs, attack surface reduction involves deploying Layer 7 inspection at the load balancer or API gateway level. This hardening layer enforces strict schema validation, intercepting and neutralizing malformed inbound traffic and potential exploits before they can interact with internal application logic.
Securing the software supply chain is equally vital in modern blueprints, and organizations should align with frameworks like Supply-chain Levels for Software Artifacts (SLSA) across both dependency and build tracks. Security policies should mandate that third-party dependencies are routed through a centralized artifact repository equipped with automated curation services, such as Google Assured Open Source Software (OSS) or an equivalent solution, preventing untrusted code from entering the development lifecycle. Furthermore, maturing toward advanced SLSA build levels (e.g., SLSA level 3) through the implementation of isolation, ephemerality and reproducibility requirements via ephemeral compute infrastructure for CI/CD runners reduces the likelihood of attacker persistence by ensuring environments are short-lived and automatically cycled.
To complement these pre-build controls, runtime observability should be established across all production workloads. This requires monitoring both infrastructure-level behavior and the specific runtime libraries actively executing in production, which surfaces true exploitable risk far beyond a static Software Bill of Materials. In tandem with monitoring workloads, organizations should secure how they authenticate by implementing workload identity federation. By removing static credentials and instead using short-lived tokens backed by strong cryptographic identity verification, organizations can reduce the risk of credential theft and unauthorized lateral movement.
Within the internal environment, microsegmentation should be enforced to break down flat networks into granular security zones. Routing application traffic through a Secure Access Service Edge (SASE) architecture integrates network routing directly with robust identity controls, rendering internal services completely invisible to unauthenticated users and containing threats to their initial point of entry.
Finally, automated containment and incident response within a zero trust framework must rely on deterministic, auditable tooling. Endpoint detection and response (EDR) platforms and SOAR playbooks should handle high-fidelity containment tasks through hardcoded execution logic. While AI tools accelerate triage and policy recommendation, actual execution capabilities must remain restricted to well-defined, pre-tested workflows to maintain total architectural predictability.
Figure 3: Structural containment and observability architecture
Track 2: Product Security & Development (1P Code)
Deterministic and probabilistic tooling
Integrating LLM agents into vulnerability management and security workflows requires recognizing the differences between deterministic and probabilistic tooling. Traditional SAST and DAST tools utilize fixed methodologies to evaluate vulnerabilities through structural code parsing or definitive runtime observations. LLMs, however, evaluate source code by processing tokens simultaneously to calculate statistical and semantic relationships, rather than tracing deterministic execution tracks.
While techniques like Chain of Thought (CoT) prompting allow models to bridge this gap by decomposing complex code paths into intermediate reasoning steps, this process remains bounded by architectural limitations. Even when a model possesses a context window large enough to ingest entire repositories, it may experience attention degradation across long inputs, often failing to correctly weight intervening validation or sanitization logic within the prompt. For example, if a variable is tainted on line 10 but sanitized on line 500, attention degradation can cause the model to lose track of the sanitization logic. Furthermore, when enterprise codebases require chunking to fit within context limits, the resulting fragmentation may cause the model to lose track of end-to-end data flows.
Consequently, probabilistic engines are effective at uncovering localized, static anomalies, such as hardcoded credentials or outdated dependencies, but frequently misjudge complex vulnerabilities split across fragmented chunks or extended context windows. Notable exceptions occur when these probabilistic models are coupled with deterministic feedback loops. For instance, when analyzing C++ memory corruption, an LLM can be equipped with a test harness to iteratively execute code and definitively prove a crash. While these dynamic validation applications are detailed in subsequent sections, the baseline limitation for static analysis across standard enterprise codebases remains: models struggle to consistently evaluate dispersed logic.
Figure 4: Deterministic SAST scanners vs. probabilistic LLMs
Binary and architectural oracles
Many security programs are moving toward agent workflows where an agent autonomously spins up a test environment and uses tools to execute payloads and verify its findings. This is a promising approach, but it is important to understand where it is most effective.
Agent workflows perform well against bug classes with binary and observable oracles, meaning the system provides an objective, 'crash or no crash' feedback loop. For example, if a model is hunting for memory corruption in a C++ kernel, a successful exploit is undeniable: the payload executes, and a resulting crash definitively proves the vulnerability. This explains why the industry is currently seeing a surge in AI-discovered vulnerabilities across memory-unsafe targets like web browsers and operating systems.
However, enterprise software is heavily dominated by vulnerabilities that require architectural oracles for validation. Vulnerabilities like authorization bypasses, complex business logic flaws, and indirect server-side request forgeries require an understanding of business context and cross-service trust boundaries. If an agent's payload fails to produce a clear outcome, it can't reliably distinguish whether the vulnerability is a hallucination or if it simply constructed the payload incorrectly. An agent's malformed payload might even crash an unrelated background process and cause the model to hallucinate a success and report a false confirmation. Complex enterprise architecture contains unwritten business intent that a probabilistic engine can't inherently know.
Figure 5: Evaluating vulnerabilities against binary vs. architectural oracles
Targeted deployment and human impact
Organizations adopting LLMs for vulnerability discovery face a massive staffing challenge. LLMs can generate findings significantly faster than human engineers can triage them. If every LLM-generated alert requires manual review, security teams will quickly face burnout and/or suffer alarm fatigue.
Rather than indiscriminately pointing agents at all available codebases and risking an influx of unverified output, security teams need a selective deployment strategy. Mature programs should maintain SAST and DAST for baseline hygiene and deterministic rule enforcement, and reserve intensive agent audits for high-impact components with clear binary oracles.
Organizations can prioritize agent audits on systems where the technology's strengths align with the broader risk profile:
-
Memory-unsafe codebases: Legacy or high-performance components written in memory-unsafe languages such as C, C++, or Assembly are strong candidates for LLM audits. These languages are susceptible to memory corruption flaws, such as buffer overflows and use-after-free conditions. Because these vulnerabilities trigger definitive failure states like segmentation faults, they work well with automated sandboxes where agents can compile the code with memory sanitizers and write proof-of-concept inputs. This approach is also effective for auditing the native extensions where safe languages call unsafe internal libraries, such as Python C extensions or the Java Native Interface (JNI).
-
Systems highly exposed to outside content: First-party data ingestion pipelines, custom API gateways, or proprietary edge proxies. A prerequisite here is direct access to the source code, this strategy is strictly for internally developed or fully open-source codebases where the organization can inspect the logic. Because these systems directly parse untrusted internet traffic, targeting their source code for LLM-driven audits yields the highest risk-reduction ROI.
-
Shared internal libraries and utilities: Core serialization/deserialization packages, common utility functions, and custom middleware wrappers (such as internal message-queue parsers) maintained in-house. Because the enterprise owns the source code for these shared building blocks, agent tools can easily hook into them within automated test harnesses to fuzz inputs and catch low-level logic or parsing bugs with high fidelity.
-
Foundational security boundaries: Internally developed centralized authentication services, custom OAuth providers, and internal credential brokers. While testing complex identity boundaries generates higher logic-based noise, having full access to the source code allows teams to pair agents with deterministic checks to safely triage findings, given that the blast radius of an authentication failure justifies the human effort.
To filter the noise generated by LLMs, organizations should establish routing rules. Require the agent to generate a fully reproducible, deterministic test harness (such as a compiled binary or a Python test script) that attempts to prove the exploit. This harness must execute automatically in an isolated, monitored sandbox. If the sandbox execution fails (due to a syntax error or a failed exploit), the ticket is discarded, sparing human resources. However, organizations should enforce execution timeouts and iteration limits on these test harnesses. Without hard limits, an autonomous agent attempting to prove a vulnerability can fall into an infinite loop: writing a script, failing, rewriting, and failing again, exhausting API token budgets and compute resources against a single dead-end vulnerability, creating significant cost overruns without advancing the security review. To manage these expenses, organizations should incorporate FinOps principles to balance the compute and API costs of LLM audits against the traditional expenses of manual triage.
However, a successful execution in the sandbox does not guarantee an actionable, high-priority risk. In practice, autonomous agents frequently produce working PoCs for genuine technical flaws that are ultimately irrelevant; or warrant a lower remediation priority within the context of the system's threat model. For example, the agent might successfully exploit an unreachable dead-code path, or trigger a bug that requires administrative access to execute and yields no further escalation of privilege. Therefore, a human engineer should be assigned to review and prioritize the ticket only if the sandbox registers a successful execution, validating environmental context, reachability, and true business impact as part of the review.
This workflow reduces the volume of alerts, but it is important to understand that the security team's workload does not disappear. The engineer's primary job shifts from manually hunting for the initial vulnerability to auditing the LLM-generated proof to ensure it represents a meaningful risk rather than an unexploitable or contextually irrelevant finding. Leadership should properly staff and train teams for this new reality. Deploying LLM agents does not remove the need for skilled practitioners; it redirects their workload toward complex validation. Equally important is training teams to recognize the risk of false negatives. A hyper-focus on filtering AI-generated noise can create a false sense of security. If an exploit relies on a novel technique or a zero-day vulnerability that was not heavily weighted in the model's training data, the agent will likely scan right past it in silence. LLMs augment discovery, but they do not guarantee exhaustive coverage.
When integrating LLMs into SAST triage pipelines, human engineers should also verify the broader architectural integrity. Prompting an LLM with specific SAST warnings can induce contextual narrowing, where the agent becomes hyper-fixated on resolving a localized syntax error and misses broader architectural flaws existing in the same file. Furthermore, if the agent's mandate extends beyond discovery to automated remediation (such as writing and proposing code fixes), this human-in-the-loop validation becomes critical to ensure the LLM does not inadvertently introduce new regressions or bypass intended business logic.
Figure 6: Flowchart outlining the targeted LLM deployment and triage workflow.
Remediation and hardening
LLM-assisted code remediation
A primary goal of integrating large language models (LLMs) into the software development lifecycle is automated remediation. To achieve this, organizations are deploying these capabilities through two primary execution methods: directly within the integrated development environment (IDE) or as a centralized pipeline runner. Examples include CodeMender, although as of time of writing, it is not publicly available.
IDE-integrated method
This method shifts remediation as far left as possible by operating as an active pair-programmer. Tools running continuous static analysis in the background of the IDE surface vulnerabilities directly to the developer via editor diagnostics like inline indicators or hover tooltips.
-
Localized scope: The developer can trigger the LLM agent to analyze the localized data flow and generate a targeted patch (such as implementing parameterized SQL queries). By constraining the LLM to localized, syntax-level fixes, the scope of the change remains contained. This prevents the agent from attempting sprawling, multi-file refactors that frequently break complex architectural logic.
-
Human-in-the-loop: The developer reviews the AI-generated patch before the code is committed.
-
Managing false positives: Local IDE agents allow developers to manage false positives dynamically. Suppressing alerts anchored to specific line text reduces alert fatigue and preserves developer trust.
CI/CD runner method
The runner method executes asynchronously within the CI/CD pipeline to use an LLM to review committed code and automatically propose remediation.
-
Restricted execution and deterministic validation: Asking a centralized runner to automatically rewrite a complex, multi-file authorization flaw directly in the main branch introduces a high risk of breaking logic errors. To mitigate this, agents must be restricted to generating pull requests (PRs). Once a PR is generated, it must automatically execute standard regression suites alongside the deterministic test harness. By rerunning the initial PoC against the patched code, the workflow repurposes the exploit script as a validation oracle to prove the vulnerability has been remediated. A human engineer then reviews the PR to validate the architectural logic before merging.
In all cases security teams should define a clear boundary between the two methods rather than rely on a single approach. IDE agents provide immediate, syntax-level support. They catch and resolve low-complexity errors locally before developers commit code. Centralized CI/CD runners handle broader organizational baselines. They propose complex, repository-wide fixes for vulnerabilities that bypass local environments.
Post-deployment controls
Even with human review and deterministic test harnesses, AI-generated patches can still introduce logic regressions in production. Organizations should implement strict post-deployment controls:
-
Automated rollbacks: Treating LLM-generated code with the same post-deployment scrutiny as any major architectural change ensures that if an unforeseen regression traverses the CI/CD pipeline, the environment can revert to a known good state.
-
Mitigating model drift: Relying on managed AI services introduces the ongoing risk of model drift. To prevent silent weight updates from breaking test harnesses, organizations need to pin specific model API versions to frozen releases. When a pinned version reaches its end-of-life, organizations will face a forced migration. Mitigating this pipeline fragility requires combining model pinning with deterministic regression suites.
-
Compliance and auditability: If an AI agent automatically closes a security ticket or generates a patch in the CI/CD pipeline, organizations should maintain immutable audit logs to satisfy frameworks like SOC 2 ,PCI-DSS, FedRAMP, and CMMC. National security deployments must also account for data sovereignty requirements. This logging should record the specific model version that proposed the fix, the deterministic test results that validated it, and the human engineer who approved the merge. Furthermore, because emerging legislation like the EU AI Act emphasizes human oversight for high-risk applications, security teams should carefully evaluate how autonomous remediation workflows align with these evolving global regulatory standards.
Figure 7: Flowchart demonstrating the difference between local IDE AI remediation and centralized CI/CD pipeline remediation.
Conclusion
Leveraging LLMs in vulnerability management is a multi-layer solution: Integrating it requires separating workflows by layer. At the enterprise infrastructure level, Risk-Based Vulnerability Management (RBVM) and exposure management are necessary to process the volume of findings and configuration drift. At the product and code security level, LLM-enabled vulnerability assessment and remediation must operate alongside foundational deterministic controls, such as SAST and DAST, to audit custom, open-source, or third-party code.
Although LLMs can help manage technical debt and accelerate vulnerability discovery, they do not replace secure-by-design principles. The fact that LLM agents are proving exceptionally capable at identifying and exploiting localized memory corruption in memory-unsafe codebases, alongside other primary vectors, should serve as a wake-up call.
As a long-term strategy aligned with NSA guidance on Software Memory Safety, organizations need to phase memory-safe languages into new internal development. LLMs are beginning to expand what is possible here by reducing the manual labor required for code migration. Converting existing C or C++ codebases to Rust has historically been unrealistic due to the large volume of engineering hours needed. While fully automated translation is not a turn-key solution, using LLMs to assist engineers with the bulk of the conversion can make these long-term migrations operationally viable. Beyond internal efforts, organizations should use procurement requirements to incentivize vendors to reduce their reliance on memory-unsafe languages and establish secure configuration defaults over time. Bridging the gap between AI velocity and enterprise defense means building an automated pipeline to manage the current backlog, while architecting systems where entire classes of vulnerabilities and misconfigurations are eliminated by design.
Acknowledgements
This analysis would not have been possible without the assistance of Google Threat Intelligence Group (GTIG) and other broader Google teams.
The Risk of Exposed Cloud Functions and How to Harden
Written by: Corné de Jong
Introduction
Mandiant security assessments frequently identify publicly exposed serverless applications that lack authentication, often as a result of specific business requirements. Serverless deployments typically run custom-developed code that incorporates third-party packages, making them targets for a wide range of application-level attacks, including:
-
Local and Remote File Inclusion (LFI/RFI)
-
Command Injection
Successful exploitation of these vulnerabilities can grant an attacker full control over the underlying container instance. Such access can serve as a foothold that may ultimately lead to a full compromise of the victim’s cloud environment.
Based on lessons learned in customer engagements, in this blog post we describe attack scenarios and provide actionable guidance on how to secure serverless environments. While this analysis focuses on hardening strategies for Google Cloud Run services and functions that must remain publicly accessible, these principles apply universally to any public serverless deployment.
What are Serverless Applications?
Serverless applications, also described as Function-as-a-Service (FaaS), allow the deployment of individual blocks of code as microservices within a flexible, decoupled, and event-driven cloud architecture without the need to manage underlying infrastructure. These services enable applications and automations to scale automatically and deploy instantly, removing operational overhead. Serverless services underpin major e-commerce, media, payment processing applications, and AI usage.
The rapid expansion of generative AI adoption is a significant driver of increased serverless architecture use. AI workflows, including chatbot interactions, image generation, “vibe-coding”, and multi-step AI agents rely on serverless functions to complete tasks for users. This growth has made securing serverless environments a more pressing challenge for enterprise security teams.
Risks of Serverless Application Attacks
Publicly exposed serverless workloads can serve as an initial access point for threat actors. As noted, these services may contain vulnerabilities within the code, imported packages, or the underlying runtime environment.
Once an entry point is exploited, attackers typically attempt to escalate privileges or move laterally. Common techniques observed include:
-
Extracting secrets stored directly within the application code.
-
Reviewing application logic and sensitive data to identify further attack vectors within the environment.
-
Exfiltrating service account bearer tokens from the metadata server following successful Remote Code Execution (RCE).
Leveraging these compromised secrets or service accounts allows threat actors to pivot to adjacent systems and workloads, potentially resulting in a total environment takeover if proper hardening strategies are not in place.
Example Attack Scenarios
The following simplified scenarios illustrate how serverless functions can be compromised and how attackers pivot after achieving initial code execution.
Local File Inclusion (LFI)
In the following Cloud Run example, a Python/Flask function accepts user-controlled input to open a file without performing proper validation. This pattern is an example of a Local File Inclusion (LFI) vulnerability.
import functions_framework
@functions_framework.http
def hello_http(request):
request_json = request.get_json(silent=True)
request_args = request.args
if request_json and 'file' in request_json:
file = request_json['file']
elif request_args and 'file' in request_args:
file = request_args['file']
# VULNERABILITY: The 'file' parameter is used directly in open()
# without validation, allowing arbitrary file access
with open(file, 'r') as resp:
filedata = resp.read()
return 'local file data {}!'.format(filedata)
Figure 1: Vulnerable Python/Flask function accepting unvalidated user input to open files
This vulnerability allows an attacker to request sensitive files from the Cloud Run instance by using curl to send a POST request via the file parameter:
curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "main.py"}'
Figure 2: curl POST request targeting the file parameter
The response provides the complete main.py source code. An attacker can analyze the code for:
-
Hardcoded secrets such as API keys, database credentials, or authentication tokens
-
Business logic flaws and additional injection points
-
Internal service endpoints and architecture details
-
Import statements revealing the technology stack and potential CVE exposure
Additionally, attackers can leverage standard ../ directory traversal sequences to retrieve sensitive system files:
curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "../../../etc/passwd"}'
Figure 3: curl POST request leveraging directory traversal sequences
An LFI vulnerability allows an attacker to retrieve and fuzz various files directly from the container. Key examples include:
-
requirements.txt, package.json, go.mod: Used to identify installed packages and versions with known vulnerabilities. -
.
envfiles: Frequently contain sensitive environment variables or hard coded secrets. -
Application configuration files: May contain database credentials, API keys, or service endpoints if not securely managed.
-
/etc/passwd, /proc/self/environ: Contains user information, environment variables. -
Application logs: may contain auth tokens or PII data.
Best Practice: Never store secrets or credentials within the source code or local container files. Utilize a dedicated secrets management solution, such as Secret Manager.
Code Execution/Command Injection
In the following scenario, a Python function uses shell execution methods with unsanitized user input, allowing an attacker to execute arbitrary commands.
import functions_framework
import subprocess
@functions_framework.http
def hello_http(request):
request_json = request.get_json(silent=True)
request_args = request.args
if request_json and 'input' in request_json:
input = request_json['input']
elif request_args and 'input' in request_args:
input = request_args['input']
result = subprocess.run(input, shell=True,capture_output=True, text=True)
return format(result)
Figure 4: Python function utilizing shell execution with unsanitized user input
This allows an attacker to execute a subsequent curl request targeting the GCP metadata service to retrieve the service account’s bearer token.
The following request extracts the service account's OAuth 2.0 bearer token, which remains valid for 1 hour:
curl -X POST https://cloudrun02-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d "{\"input\": \"curl 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' -H 'Metadata-Flavor: Google'\"}"
Figure 5: Extraction of a GCP service account bearer token via a curl request
Once obtained, an attacker can use it on an attacker-controlled system to execute Google Cloud CLI commands. For example the CLOUDSDK_AUTH_ACCESS_TOKEN environment variable can be set using the stolen bearer token.
export CLOUDSDK_AUTH_ACCESS_TOKEN=”obtain bearer token”
Figure 6: Defining CLOUDSDK_AUTH_ACCESS_TOKEN environment variable
Attackers can then leverage Google Cloud Cloud CLI within the security context of the Cloud Run Compute service account. If deployed without best practices and thoughtful configuration controls, for example, if the Cloud Run service runs as the default compute service account with Editor permissions, this would be equivalent to a full GCP project takeover, and allow the attacker to:
-
Read/write/delete most GCP resources
-
Deploy new services and modify existing configurations
-
Access secrets and encryption keys
-
Exfiltrate data across all accessible storage systems
-
Establish persistent backdoors through new service accounts or SSH keys.
Hardening Recommendations
Mandiant recommends that organizations implement parallel approaches for effective serverless security:
-
Secure Software Development Lifecycle (S-SDLC): integrate security scanning, code review, least-privilege IAM into CI/CD pipelines before deployment and integrate continuous security testing;
-
Vibe Coding: Mandiant recommends multi-layered security enforcement for AI-generated code or "vibe coding." Organizations should isolate AI experimentation within dedicated sandbox environments and enforce strict data egress controls to protect production systems and internal data. Furthermore, development environments should be restricted to approved IDEs with human-in-the-loop capabilities, utilizing only verified plugins operating under least privilege to mitigate supply chain vulnerabilities. Finally, organizations must ensure this AI-generated software follows Secure Software Development Lifecycle (S-SDLC) controls while establishing clear internal guidelines regarding permitted use cases. Comprehensive security fundamentals for vibe coding are documented in detail within the Wiz Vibe Coding Security Fundamentals blog.
-
Compensating Runtime Controls: Implement the following defense-in-depth measures to limit and contain compromise even when application vulnerabilities exist;
Segregate Public Services
Host public-facing Cloud Run services consumed by untrusted external entities in a dedicated, isolated Google Cloud project. This ensures a compromise does not provide an immediate path to critical internal resources. The implementation of this 'Service Project' model is beyond the scope of this post; however, it is documented in detail within the secured serverless architecture blueprint.
Identity and Access Management (IAM)
Mandiant recommends using a custom service account for service authentication rather than the default Compute Engine service account, following the principle of least privilege. Grant only the specific permissions necessary for the Cloud Run function to operate, for example:
-
Cloud Storage Bucket Access: If the service only requires read access to objects from a Cloud Storage bucket, grant the
Storage Object Viewer(roles/storage.objectViewer) role restricted to that specific bucket. -
Secret Manager Access: If the service requires access to secrets, grant the
Secret Manager Secret Accessor(roles/secretmanager.secretAccessor) role only to the individual secrets required. For further details on secret access from Cloud Run, refer to the GCP documentation on configuring secrets.
Layer 7 Application Load Balancer (ALB) Architecture
Restrict ingress traffic for serverless functions to internal only and use an external Layer 7 ALB to manage internet exposure. This provides:
-
Centralized Traffic Management: Granular control over headers and SSL policies.
-
Cloud Armor Integration: Web Application Firewall (WAF) support to harden applications against vulnerabilities such as Local/Remote File Inclusion (LFI/RFI) and Server-Side Request Forgery (SSRF).
-
Traffic Shaping: Implementation of rate limits and request limitations to prevent abuse.
-
Enhanced Visibility: Robust logging and log-forwarding capabilities for security monitoring.
-
Identity-Aware Proxy (IAP): integration support for scenarios requiring specific identity-based authentication for internal users.
Web Application Firewall (WAF) — Cloud Armor
Cloud Armor provides WAF protections that can be integrated with the Load Balancer to filter malicious traffic. The following examples demonstrate how to configure Cloud Armor security policies to block the specific local file inclusions, remote code execution and traversal attacks previously outlined.
Local File Inclusion
The lfi-v33-stable preconfigured WAF rules can block common local file inclusion attacks (local file inclusion reference).
evaluatePreconfiguredWaf('lfi-v33-stable', {'sensitivity': 3})
Figure 7: Cloud Armor lfi-v33-stable WAF rule configuration
Blocking a path traversal request ../../../etc/passwd resulting in a 403 forbidden:
curl -X POST https://exampleabc01.com -H "Content-Type: application/json" -d '{"file": "../../../etc/passwd}'
<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden
Figure 8: Verification of Cloud Armor blocking path traversal request, resulting in a 403 forbidden
Remote Code Execution
The rce-v33-stable preconfigured WAF rules can block remote code execution attempts (remote code execution reference).
evaluatePreconfiguredWaf('rce-v33-stable', {'sensitivity': 3})
Figure 9: Cloud Armor rce-v33-stable WAF rule configuration
Blocking the remote code execution request from the previous example results in a 403 forbidden:
curl -X POST https://exampleabc01.com -H "Contencurl -X POST https://exampleabc01.com -H "Content-Type: application/json" -d "{\"input\": \"curl 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' -H 'Metadata-Flavor: Google'\"}"
<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden
Figure 10: Verification of Cloud Armor blocking Remote Code execution, resulting in a 403 forbidden
Serverless Architecture Controls
Hardening Cloud Run services is only one part of a secure architecture. Because these services often connect to other Google Cloud resources, a single compromise can expose additional services. Implementing defense-in-depth is critical. Specifically, when using direct VPC egress or VPC Access connectors, use VPC Service Controls to restrict lateral movement and exfiltration through granular access policies.
Secure Software Development Lifecycle (S-SDLC)
While the previously outlined hardening strategies are critical, the ideal standard remains the proactive identification of vulnerabilities during the initial development stages. A deep dive into "Shift-Left" security is beyond the scope of this analysis, which focuses on mitigating risks within existing code. However, a Secure Software Development Lifecycle (S-SDLC) remains a fundamental principle. Robust code validation and continuous security testing are essential to neutralize threats before serverless functions are published externally.
Cloud Run Threat Detection
Beyond the hardening recommendations outlined in this post, Google Cloud Security Command Center (SCC) provides built-in services to detect control plane attacks against Cloud Run resources. These include detectors for credential access, reconnaissance, and the execution of scripts or reverse shells. The Cloud Run Threat Detection service is available for Premium and Enterprise tiers.
Conclusion
Serverless applications drive agility and rapid business value. While "vibe-coding" has made it easier than ever to deploy code, this breakneck speed demands that teams integrate security early in the development lifecycle, move beyond default configurations, and prioritize a defense-in-depth strategy centered on identity and architecture.
Acknowledgements
This analysis would not have been possible without the assistance of Ischa Rijff, Phil Pearce, and Juraj Sucik.
-
Threat Intelligence Blog | Flashpoint

- Understanding Illicit Ecosystems: How Dark Web Forums Structure Cybercrime
Understanding Illicit Ecosystems: How Dark Web Forums Structure Cybercrime
Blog
Understanding Illicit Ecosystems: How Dark Web Forums Structure Cybercrime
As part of our ongoing series, we analyze how dark web forums operate, breaking down Flashpoint’s tiered classification system and examining how specialized, hybrid platforms function together as an interconnected cybercrime supply chain.

When a high-profile data breach hits headlines, the default assumption is often to view the dark web as a single, centralized marketplace where any illicit service or tool can be bought. While many illicit forums aspire to be seen as a “one-stop shop,” the reality is that the underground economy relies on an interconnected network of specialized hubs that each align with distinct phases of the cybercrime lifecycle.
To understand how cybercrime thrives, it is vital to learn how these online spaces survive and how they play their parts in graduating threat actors from entry-level novices to sophisticated adversaries.
Navigating the Cybercrime Ecosystem: Entry Barriers and Forum Tiering
An illicit community’s survival hinges on its operational value and culture, which is ultimately created by its supporters. In a low-trust environment filled with cybercriminals, hidden law enforcement, and security researchers, these digital spaces are inherently defensive. To protect their communities from competitors’ attacks, surveillance, and eventual takedowns, forums implement rigorous gatekeeping mechanisms.
As such, Flashpoint organizes the cybercrime ecosystem into a tiered structure, separating them into low, mid, or top-tier forums, defined by several key factors such as:
- Entry Barriers: The financial or reputational requirements for a user to join the community, indicating the forum’s exclusivity.
- Technical Expertise: The collective technical skills and proficiency of the forum’s members.
- Trade Quality: The quality and value of illicit goods and services exchanged, such as advanced hacking tools or high-value data leaks.
- Operational Security (OP SEC): The extent to which the community upholds strict security protocols and practices.
By analyzing these vectors, the ecosystem naturally separates into three distinct operational tiers.

Low-Tier Forums
These communities are easily accessible, often requiring a small fee or completely free registration with little to no vetting. They host less sophisticated users, beginner hackers, and minor data brokers seeking free material. Because the technical barrier is low, these spaces primarily share low-cost, high-volume data, including large data leaks, generic phishing guides, unchecked stolen accounts, and cracked software.
Consequently, these environments face a persistently high risk of scams and poor quality data. Within low-tier forums, reputation is often built by sharing free data or purchasing a rank or upgrade which is viewable by other users.
Mid-Tier Forums
Moderately accessible via both Tor and the clearnet, entry into these spaces typically require a vouch from an existing member, a minimal registration fee, or an initial deposit. These platforms concentrate on large-scale fraudulent activity and the exchange of various datasets—including bulk carding data, stolen credentials, stealer logs, phishing kits, botnets, and various malware.
The user base includes a mix of vendors, experienced threat actors, affiliates of larger groups, and aspiring cybercriminals looking for training. To protect users from internal fraud, these forums heavily prioritize integrated escrow services and reputation systems, which can be improved by purchasing an internal high-tier status.
Top-Tier Forums
These are highly exclusive platforms dedicated to high-value, highly technical, and targeted criminal operations. New applicants face a stringent vetting process, typically demanding either a formal invitation or a substantial registration payment. This exclusive layer hosts highly skilled, professional threat actors, malware developers, and key decision-makers within major illicit groups.
This is the ecosystem where adversaries build trust through valuable technical contributions or community reputation points and execute complex money laundering schemes, trade zero-day exploits, facilitate ransomware-as-a-service (RaaS) partnerships, and conduct large-scale initial access broker sales.
What Are the Different Types of Dark Web Forums?
Once a community establishes its tier, it usually functions as a specialized hub linked to a specific stage in the overall cybercrime lifecycle. They do this to cultivate talent and expertise, which naturally bridges communities together, creating a supply chain where different forums handle distinct operational and structural needs.
General Information and Community Boards
Modeled after surface-web sites like Reddit, these platforms serve as social and informational hubs. Discussions prioritize coordination, reputation management, and the propagation of best practices regarding OPSEC. Users share news about cybercriminal arrests, look for advice on how to remain anonymous, report potential exit-scams, and provide detailed reviews of specific vendors, particularly those selling illicit drugs.
Financial Theft and Carding Forums
These semi-structured environments blend marketplaces with social networks, utilizing a professionalized supply chain for selling stolen cards, dumps, and fullz. To reduce internal fraud, they rely heavily on reputation-building tools like verified seller statuses and integrated refund systems for invalid data. To ensure operational longevity, they are typically hosted on bulletproof infrastructure located in states that do not comply with international takedown requests, such as the Russian Federation.
Data Leak Forums
Depositories for stolen databases where raw breach information is structured into a tradeable commodity. Leaks are listed by victim name and sector, allowing actors to quickly find credentials or corporate records to repurpose for credential stuffing, extortion, or identity fraud.
Cracking and Hacking Tutorials (Knowledge Bases)
Existing entirely for knowledge exchange and offensive techniques, threat actors share methods, tutorials, fraudulent schemes, and bypass techniques, often encouraging educational sharing through competitions.
High-Skill Exploit and Access Forums
Top-tier platforms hosting the “upper echelons” of the community, such as initial access brokers, exploit developers, and malware creators. They rely heavily on strict arbitration systems, mandatory vendor deposits, and escrow mechanisms to safely conduct high-impact transactions and corporate intrusions.
Low-Barrier Retail Forum
High-traffic segments trading mass-market digital goods like cracked subscription accounts, premium software, and online gaming assets. Characterized by an exceedingly low barrier to entry and a relatively young user base seeking quick profit without the capability for advanced, complex operations.
Map the Illicit Pipeline Using Flashpoint
What makes the cybercriminal ecosystem truly cohesive is that the lines between these various types of forums and communities constantly blur. Most illicit communities are hybrid and transitional, intentionally or naturally blending categories to cater to each other’s needs and boost monetization.
Hybrid forums frequently connect the how-to tutorials with actual stolen data and network access, effectively creating a structural pipeline for threat actor progression. Platforms like BreachForums combine the attention-grabbing aspect of a data leak site with a structured marketplace for selling logs and other sensitive data. This type of hybridization allows a threat actor to progress from a beginner reading tutorials to an active criminal deploying stolen data.
Monitoring these fluid structures and transitions is the only way to understand how threat actors develop, and how the interconnected cybercrime landscape shifts over time. Therefore, it is essential for security teams to look beyond cyber threats as isolated, and recognize the multi-platform strategies these actors employ. Request a demo to gain visibility into these threat actor communities and proactively defend your organization from across the entire cybercrime supply chain.
| Check out the rest of our “Understanding Illicit Ecosystems” series: |
| Understanding Illicit Ecosystems: The Hybrid Threat of “The Com” |
| Understanding Illicit Ecosystems: XSS and the Current State of the Russian-Speaking Underground |
| Understanding Illicit Ecosystems: Weaponizing Mainstream Apps and Social Infrastructure |
See Flashpoint in Action
The post Understanding Illicit Ecosystems: How Dark Web Forums Structure Cybercrime appeared first on Flashpoint.
What the June 2026 Threat Technique Catalog update means for your AWS environment
The AWS Customer Incident Response Team (AWS CIRT) encounters patterns that repeat across engagements when helping customers respond to security incidents. We’re passionate about making sure that information is accessible so that everyone can improve their security posture and their organization’s resilience to disruption. The primary method we use to share this information is the Threat Technique Catalog for AWS (TTC). The latest update to the catalog for June 2026 focuses on container security, organization-level trust, and compute hijacking. Each new entry reflects something we’ve encountered in practice, and each provides straightforward mitigation. This post breaks down what changed, why it matters, and what you can do about it today.
What we’re seeing
We’ve added five new entries to the TTC.
EKS workload modification
Amazon Elastic Kubernetes Service (Amazon EKS) gives teams powerful orchestration capabilities. We’re seeing threat actors who have obtained Kubernetes credentials or an AWS Identity and Access Management (IAM) role with EKS permissions modify running workloads—altering container images, injecting sidecar containers, or changing pod specifications to introduce malicious code into a deployment.
Nothing new is created. The workload already exists, it might be running in production, and by modifying it in place the threat actor inherits the network access, service account permissions, and data access the legitimate workload already had. Without admission controllers or image verification, these changes can go unnoticed until the impact shows up downstream. Enforcing image signing through admission controllers, restricting workload changes with Kubernetes role-based access control (RBAC), and enabling Amazon GuardDuty EKS Protection to surface anomalous cluster activity all reduce this risk. For more information, see EKS Modification – Workload Integrity Degradation.
Exploit public-facing application – EKS
Publicly exposed Kubernetes API servers and misconfigured ingress controllers continue to be an entry point we see exploited. This technique captures threat actors targeting the customer-deployed workloads running on Amazon EKS—not EKS itself—and their exposure to the internet.
The pattern starts with an exposed service and an application-level weakness, then pivots from the compromised pod toward broader cluster access. When inside a pod, a threat actor can query the instance metadata service, read mounted service account tokens, or move laterally across the cluster network. Limiting public exposure of the Kubernetes API server, applying network policies to restrict pod-to-pod communication, and running workloads with least-privilege service accounts reduce the risk of this technique succeeding. For more information about this technique, see Exploit Public-Facing Application.
Assume root into organization member account
AWS Organizations centralizes trust across member accounts, and that trust runs in one direction—from the management account downward. We’ve observed threat actors who compromise a management account—or gain sufficient privilege within one—use that position to assume root access into member accounts using sts:AssumeRoot. Because the trust is inherent to the organization structure, this can avoid the access controls a member account administrator has configured.
With root access to a member account, a threat actor can disable security controls, delete resources, change billing configurations, and establish persistence that survives remediation focused on IAM principals. We strongly encourage implementing service control policies (SCPs) that restrict which principals can call sts:AssumeRoot and under what conditions, and monitoring for sts:AssumeRoot calls in AWS CloudTrail. For more information, see Assume Root into Organization Member Account.
Compute hijacking – EKS
Compute hijacking remains one of the most common motivations we see behind unauthorized access, and Amazon EKS clusters are increasingly the target. Threat actors deploy cryptocurrency mining or other compute-intensive workloads inside compromised clusters, consuming customer resources and generating unexpected cost.
What sets EKS-based hijacking apart is scale. In clusters without resource quotas, a single compromised service account can consume all available capacity across nodes. The workloads use legitimate-looking images pulled from public registries, which makes image scanning alone insufficient. Setting resource quotas and limit ranges, restricting which registries workloads can pull from, and enabling Amazon GuardDuty EKS Protection to flag mining behavior provides effective detection. For more information, see Resource Hijacking: Compute Hijacking – EKS.
Invite accounts to unknown organization
A threat actor with access to a standalone account—or one they’ve removed from its legitimate organization—invites it into an organization they control. After the account joins, it falls under the threat actor’s governance. The threat actor’s organization can apply SCPs that restrict the legitimate owner’s actions, gain visibility into the account’s resources through organizational services, and access consolidated billing information. The legitimate owner finds themselves locked out of their own governance controls. Monitoring organizations:InviteAccountToOrganization and organizations:AcceptHandshake, and implementing SCPs that prevent accounts from leaving their legitimate organization are important preventive measures. For more information, see Modify Cloud Resource Hierarchy: Invite Accounts to Unknown Organization.
What’s updated
We’ve refreshed three existing entries. S3 Object Collection now captures additional API calls used for bulk data staging from Amazon Simple Storage Service (Amazon S3), with refined detection guidance and mitigations that use recent Amazon S3 security features. Compute Hijacking – ECS adds methods threat actors use to deploy unauthorized tasks in Amazon Elastic Container Service (Amazon ECS), including abuse of overly permissive task execution roles. Role Assumption and Federated Access has been expanded to cover new cross-account role assumption variations and identity provider manipulation, with sharper guidance for distinguishing legitimate federated access from unauthorized use.
The current trend
This June update reflects a clear trend: threat actors are increasingly targeting container orchestration platforms and using organizational trust relationships to their advantage. The container techniques show that as organizations adopt Kubernetes at scale, the attack surface grows with it. The organization-level techniques show that threat actors understand organizational trust relationships.
The common thread is that every one of these techniques operates within the boundaries of legitimate functionality. Modifying a workload, assuming cross-account trust, and joining an organization are all expected actions in healthy environments.. Detection, then, depends entirely on context: the principal, the timing, and the sequence of events that follows.
The Threat Technique Catalog for AWS is designed to help with this. We encourage teams to review the relevant entries and assess whether their current monitoring would catch these patterns:
- Unexpected modifications to EKS workload specifications
- Pod deployments that use unsigned container images
sts:AssumeRootcalls into member accounts- Unbounded compute consumption in your EKS clusters that could be prevented by resource quotas
- Unexpected organization invitations to your accounts
Each of the threats leaves traces in AWS CloudTrail and Kubernetes audit logs, and the TTC provides specific guidance on what to watch for and how to respond.
Looking ahead
The Threat Technique Catalog for AWS exists because we believe the patterns we observe during security engagements shouldn’t stay behind closed doors. When we see techniques repeating across customers, the most effective thing we can do is document them and make that knowledge available so you can act on it before you’re in the middle of an incident.
This June update adds five new entries and updates three existing ones, and the catalog will continue to evolve. Our team updates it based on what we’re seeing in the real world when helping customers respond to security events. We encourage security teams to review the catalog, incorporate its techniques into threat modeling exercises, and use it as a shared vocabulary for discussing cloud-specific threats.
Explore the full catalog: Threat Technique Catalog for AWS – Full Matrix
Additional resources
- Threat Technique Catalog for AWS – Full Matrix
- What the March 2026 Threat Technique Catalog update means for your AWS environment
- Amazon EKS Best Practices Guide for Security
- Amazon GuardDuty EKS Protection
- AWS Organizations – Centralized root access management
- Service control policies (SCPs)
- AWS CIRT announces the launch of the Threat Technique Catalog for AWS
If you have feedback about this post, submit comments in the Comments section below.
AI, Trust, and the Future of Threat Intelligence
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.

Flashpoint Named A Challenger in 2026 Gartner MQ
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.



