Reading view

AI, Trust, and the Future of Threat Intelligence

Blogs

Blog


AI, Trust, and the Future of Threat Intelligence

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

SHARE THIS:
Default Author Image
July 7, 2026

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.

  •  

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

Blogs

Blog

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

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

SHARE THIS:

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

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

What We Know About Remus

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

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

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

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

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

Similarities to Lumma

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

Remus Stealer panel (Source: Flashpoint Collections)

Code-Level Overlaps

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

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

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

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

Remus inline string deobfuscation (Source: Flashpoint)
Lumma inline string deobfuscation. (Source: Flashpoint)

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

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

Lumma ID (Source: Flashpoint)
Remus tag (Source: Flashpoint)

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

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

Differentiators of Remus

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

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

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

Network traffic from Remus sample (Source: Flashpoint)

Protect Against Infostealers Using Flashpoint

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

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

See Flashpoint in Action

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

  •  

America250 Fourth of July Threat Assessment

Blogs

Blog

America250 Fourth of July Threat Assessment

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

SHARE THIS:
Default Author Image
June 30, 2026
Table Of Contents

The Complete Guide to OSINT for Executive Protection

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

Key Takeaways

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

America250 Threats & Security Challenges:

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

Physical Threat Vectors

Transportation and Infrastructure

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

Event Threats

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

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

Planned Protest

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

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

Cyber Threat Vectors

Ransomware and Operational Technology (OT) Disruptions

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

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

Hactivism

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

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

Event App Vulnerabilities and Data Harvesting

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

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

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

Protect People Using Flashpoint

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

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

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

See Flashpoint in Action

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

  •  

Unmasking the Digital Trail: Essential Techniques for Vetting AI-Generated Content

Blogs

Blog

Unmasking the Digital Trail: Essential Techniques for Vetting AI-Generated Content

In our latest on-demand webinar, we outline the practical, human-driven techniques threat intelligence teams must deploy to detect synthetic media, protect corporate RAG ecosystems, and filter through the noise of AI-polluted networks.

SHARE THIS:
Default Author Image
June 29, 2026

In the era of generative artificial intelligence (AI), threat intelligence is facing a profound signal-to-noise challenge. AI has introduced a massive paradigm shift to threat actor operations—making execution extremely easy while simultaneously dramatically complicating the task of verification for security teams.

In our latest on-demand webinar, Matt Edmonson, SANS Senior Instructor and founder of Argelius Labs, joined Flashpoint to discuss the intersection of Open Source Intelligence (OSINT) and AI. Drawing from his vast federal law enforcement experience, he shared actionable, human-driven techniques for detecting and vetting AI-generated online content.

Neutralizing the Automated RAG and Vector Database Trap

Before deploying any human-driven vetting techniques, an analyst must understand the specific structural trap threat actors are laying. Adversaries are no longer just using AI to spin up isolated phishing copy; they are using it to corrupt the automated defense pipelines that security teams rely on.

Modern threat intelligence workflows utilize automated ingestion to feed open-source data directly into local vector databases and Retrieval-Augmented Generation (RAG) models. Aware of this, sophisticated threat actors deploy a coordinated infrastructure strategy: they register multiple lookalike domains simultaneously to broadcast the exact same AI-generated disinformation narrative.

When automated security tools ingest this data, the system flags multiple distinct “sources” confirming the story as truth. This structural echo chamber completely bypasses automated verification safeguards, polluting corporate databases with validated lies. We have seen this play out via:

  • Long-Game Credibility Building: Edmonson highlighted an active Foreign Malicious Influence (FMI) campaign utilizing a French lookalike news site called Verite Cache (“The Hidden Truth”). The threat actors scrape legitimate Western news, use AI to rewrite it to build structural domain authority over time, and then manipulate narrative outcomes the moment a critical geopolitical event or election occurs.
  • Simultaneous Infrastructure Deployment: This pattern was mirrored in Southeast Asia, where Singapore recently banned six lookalike news sites targeting regional discourse. Upon technical inspection, five of those six distinct domains had been registered on the exact same day to broadcast a unified narrative.
  • Organic-Looking Algorithmic Surges: The scale of these operations can shift political landscapes in a matter of days. Romania recently took the extreme step of canceling and restarting its presidential election due to a covert, highly coordinated Russian-backed social media campaign. The operation used synthetic assets to trigger algorithmic recommendation engines, driving an intense, seemingly organic surge for an underdog candidate.

Triangulating AI Flaws and Anomalies Across Modalities

Vetting AI content relies on compiling a cluster of intersecting indicators across text, images, audio, and video until a definitive analytical confidence level is reached. While generative tools have grown highly sophisticated, they are still bound by mathematical constraints and architectural limitations. Catching these errors and inconsistencies requires analysts to identify a cluster of intersecting indicators across text, images, audio, and video:

  • Textual Analytics (Linguistic Quirks and Filler Text): Large Language Models (LLMs) leave distinct behavioral footprints. Analysts should look for commonly-used AI wordings and “portable sentences”, as well as automated translation leakage that reveals a threat actor’s native language mechanics.
  • Visual Logic Flaws (Physics and Seams): AI models frequently fail to grasp the fundamental physics of the real world. Analysts should closely inspect image logic for anatomical blunders (such as inverted hand structures), impossible geometry, or objects with extreme structural flaws. Additionally, AI struggles with “texture seams”—the exact boundaries where distinct textures meet.
  • Auditory and Video Glitches (Cadence and Duration): Human speech is inherently messy, characterized by breathing pauses, environmental background noise, and shifting cadences. Synthetic speech is often locked into a perfectly uniform, monotone rhythm. Furthermore, high-fidelity deepfakes are incredibly resource-intensive to sustain over long durations. While an actor can fake 10 to 15 seconds of synthetic video convincingly, a five-minute video will almost always display jarring cuts, visual artifacting, or avatars clipping out of frame.

Empowering the Human Layer | Watch the Full Webinar

Human analysts remain the most critical layer of defense against illicit uses of AI. Empowered by comprehensive threat intelligence, OSINT, and AI technologies, security teams can hunt for clusters of intersecting indicators across text, images, audio, and video to assess authenticity. To learn more and to gain more essential techniques, watch the full on-demand webinar. Using Flashpoint, organizations can filter through noise, execute critical data premortems, and neutralize sophisticated disinformation campaigns.

See Flashpoint in Action

The post Unmasking the Digital Trail: Essential Techniques for Vetting AI-Generated Content appeared first on Flashpoint.

  •  

Everyone’s Selling AI That Kills Pentesting. We Built One That Doesn’t.

What we built, Fusion AI, runs at about a third the cost of a traditional external pentest, a human tester still signs off on every finding, and it is not here to replace anybody.
We have been hearing that one a lot. So when Melisa from our Business Capture team sat down with Brian Fehrman and me for this episode of AI Security Ops, she started with, “What is this thing you built, and is it the same hype everyone else is selling?”

The post Everyone’s Selling AI That Kills Pentesting. We Built One That Doesn’t. appeared first on Black Hills Information Security, Inc..

  •  

AI Red Teaming Makes the Unknowns Known

AI Red Teaming Makes the Unknowns Known

AI security is getting attention because AI has stopped being a side experiment.  It is now part of how work gets done. Employees use copilots to write, research, code, and analyze. Product teams are adding AI into customer experiences. Developers are building applications on top of foundation models. Business teams are experimenting with agents that can read email, summarize documents, query data, and trigger workflows.  That is a very different world from the one many AI review processes were designed for.  An AI system can pass a benchmark and still fail in production. It can behave safely in a clean test environment and then encounter real […]

The post AI Red Teaming Makes the Unknowns Known appeared first on Check Point Blog.

  •  

The Shift to Threat-Informed Prioritization: Operationalizing CISA BOD 26-04

Blogs

Blog

The Shift to Threat-Informed Prioritization: Operationalizing CISA BOD 26-04

In this post, we examine how CISA BOD 26-04 shifts the industry away from flat CVSS scoring and details how Flashpoint bridges the critical data gaps left by public vulnerability repositories.

SHARE THIS:
Default Author Image
June 15, 2026

With the recent issuance of Binding Operational Directive (BOD) 26-04, CISA has officially shifted federal policy away from static severity scores and flat patching timelines  toward threat-informed prioritization. The move reflects a reality security teams have grappled with for years: not all critical vulnerabilities post the same risk, and not all active vulnerabilities receive the highest CVSS scores. 

Traditional vulnerability management programs have often relied on severity-based patching models that force resource-constrained teams to focus on large volumes of high-scoring vulnerabilities. Yet research consistently shows that threat actors routinely exploit a broader range of weaknesses, including lower-scoring vulnerabilities on internet-facing assets, to gain initial access and move laterally through victim environments. 

While BOD 24-04 represents a significant step forward, there are still hidden challenges organizations will face as they adopt a risk-based approach. The operational reality is that executing a truly risk-based matrix validates what Flashpoint has maintained for years: effective vulnerability prioritization requires deep, contextual threat data. Unfortunately, the needed real-world metadata for this kind of context are simply not supported by public sources of vulnerability intelligence.

Understanding BOD 26-04

BOD 26-04 evaluates the urgency of a vulnerability by cross-referencing a security flaw against four distinct operational variables:

  1. Asset Exposure: Is the asset publicly accessible via the internet?
  2. Known Exploited Status (KEV): Is there verifiable evidence of active exploitation in the wild?
  3. Exploit Automation: Can a threat actor completely automate the weaponization and delivery of the exploit?
  4. Technical Impact: Does a successful exploit result in partial disruption or total compromise of the target system?

By analyzing these variables in tandem, organizations can tier their response and execute clear, defensible SLA metrics.

Risk PriorityReal-World Matrix ConditionsRequired SLA & Operational Action
P1: Immediate RiskIn KEV + Publicly Exposed + Automatable + Total Impact3 Days (Includes Mandatory Forensic Triage)
P2: Urgent RiskIn KEV + Publicly Exposed + (Either Non-Automatable OR Partial Impact)7 Days
P3: Elevated RiskIn KEV + Internal / Non-Publicly Exposed Asset14 Days
P4: Standard RiskNot in KEV + Publicly Exposed + Automatable + Total Impact30 Days
Deferred RiskNot in KEV + Internal Asset OR Lower Technical ImpactNext Scheduled System Upgrade / Maintenance

According to CISA, the pilot testing of this model has shown that fewer than 1% of an organization’s typical vulnerability backlog requires urgent, immediate remediation, while over 60% can be safely deferred to standard system maintenance cycles. However, implementing this framework successfully requires access to granular, real-world data points that public sources of vulnerability intelligence simply do not support. 

“Speaking with security teams in the wake of this directive, it is clear that BOD 26-04 is a major paradigm shift. While the ability to safely defer more than half of your patch backlog is an invaluable efficiency gain for modern organizations, executing that strategy effectively requires ground-truth intelligence on exploit automation and adversary intent that public registries simply cannot deliver.

Josh Lefkowitz, CEO and Co-founder at Flashpoint

The Data Challenge

To operationalize this model successfully, organizations will require a high-fidelity intelligence pipeline that combines comprehensive threat and vulnerability intelligence into clear, context-rich insights that support prioritization and decision making. You cannot confidently defer remediation without verifiable intelligence that proves the vulnerability lacks active exploit history or automation maturity.

Unfortunately, relying on public data feeds like the CVE database or the National Vulnerability Database (NVD) to fuel this matrix creates an immediate operational bottleneck. Public repositories have historically struggled under severe analysis backlogs, leading to processing delays and missing Common Platform Enumeration (CPE) data. Furthermore, public feeds are inherently reactive; they do not monitor illicit communities where exploit code is developed, nor do they track the real-time weaponization metrics needed to meet BOD 26-04’s tight 3-day or 7-day compliance window.

How Flashpoint Solves the Prioritization Gap

Flashpoint Vulnerability Intelligence bridges the gap between public data limitations and the requirements of real-world exposure management. Independently researched and enriched, Flashpoint provides the precise contextual signals required by the CISA BOD 26-04 matrix:

  • Coverage across CVE and non-CVE vulnerabilities
  • Continuous tracking of exploitation activity and adversary usage
  • Context on exploit maturity and remediation
  • Consistent enrichment that can be integrated into operational workflows
  • Over 7,000 known exploited vulnerabilities (KEV)

By integrating Flashpoint’s continuous intelligence into operational workflows, security teams can automatically validate exposure, assess automation potential, and confidently claim the operational relief that risk-based prioritization promises.

“We are convinced by Flashpoint’s superior vulnerability coverage, timeliness in the updates, and long-term monitoring of exploits. We also really appreciate Flashpoint’s proprietary CVSS rating and classifications based on expert knowledge of the standard and practical use in the industry. Having all this curated information at your fingertips is a game changer.”

Vulnerability Manager, Telecommunications

Prioritize Vulnerability Risk Using Flashpoint

CISA’s BOD 26-04 represents a critical shift away from severity-based patching and toward defensive efficiency. However, the effectiveness of this model is entirely dependent on the fidelity of your threat data.

Without best-in-class comprehensive vulnerability intelligence, security teams will be forced back into reactive patching cycles. Request a demo to learn more how Flashpoint helps security teams move beyond the constraints of static scoring and align their vulnerability management workflows with actual risk.

See Flashpoint in Action

The post The Shift to Threat-Informed Prioritization: Operationalizing CISA BOD 26-04 appeared first on Flashpoint.

  •  

Inside a malicious infrastructure delivering EtherRAT, phishing pages, and malicious software 

During our recent threat hunting activities, we found EtherRAT malware being distributed by a website with a strange homepage. This homepage allowed us to discover a vast malicious infrastructure distributing malware, malicious documents, remote desktop software, and phishing pages. 

EtherRAT is a RAT developed in Node.js which allows an attacker to gain complete control over the machine and execute arbitrary code returned by the Command and Control (C2) server. The malware uses the Etherium blockchain to obtain the C2 server, hence the “Ether” part of the name. EtherRAT is typically distributed via MSI, PowerShell, or JavaScript scripts. 

An open directory that distributes EtherRAT: where it all began 

While threat hunting, we found an open directory that was distributing MSI installers and PowerShell scripts, which ultimately distributed EtherRAT. In the analyzed cases, the PowerShell scripts and MSI installers were distributed from a “/install” folder.  The versions have a progressive number, ranging from v1 to v10. 

Figure 1: Open Directory hosting EtherRAT MSI 
Open Directory hosting EtherRAT MSI 

The returned home page caught our attention and prompted us to further explore the campaign. 

The homepage returned by the EtherRAT distribution website 

Analyzing domains and associated IPs with the EtherRAT distribution, we detected other similar home pages with a hacking-style theme. They appeared to belong to a larger distribution chain, which also distributes phishing, remote control software, and other malware. These websites usually have several folders with malware and phishing related content, and what is displayed depends on the specific infection chain. 

Different websites that resolve to the same IP addresses have previously returned pages related to fake companies or default templates. The use of these new pages could therefore be a method to make detection more difficult for automated scanners or researchers.  Here are some of the home pages we found:

Some of the malicious websites indexed on Google 

EtherRAT is an interesting RAT, as it has few lines of code and allows the execution of arbitrary code returned by the C2 server. Furthermore, using the Ethereum blockchain to obtain the C2 server makes it more resilient to infrastructure takedowns. 

Technical analysis of EtherRAT 

The detected websites usually distribute an MSI or PowerShell script with the version name, such as v1.msi, v2.ps1, and so on. 

MSI Loader 

The MSI file “v9.msi” contains three components: 

MSI Filename Description 
KmPuGimn.cmd BAT launcher 
cDQMlQAru0.xml First Jscript loader 
MRaQCipBIZeiZNx.log Encrypted EtherRAT 

When the MSI is executed, the “KmPuGimn.cmd” file is started: 

conhost --headless cmd /c "KmPuGimn.cmd" 

This obfuscated BAT file performs different operations: 

  • Extracts the other files in a random folder in %LOCALAPPDATA%. 
  • Re-executes itself via: 
    • %SystemRoot%\System32\conhost.exe –headless %SystemRoot%\System32\cmd.exe /c call “C:\Users\{user}\AppData\Local\{random_path}\KmPuGimn.cmd” nKWa 
  • Runs the command “where node” to find an existing installation. 
  • Downloads Node.js if it’s not found 
    • Uses “curl -sLo” to download Node.js from the official website. 
    • Extracts to installation directory via “tar -xf”. 
    • Renames extracted directory to “28Q75h”.
  • Loops until both “MRaQCipBIZeiZNx.log” and “cDQMlQAru0.xml” exist, then executes: 
    • conhost.exe –headless C:\Users\{user}\AppData\Local\{random_path}\{random_path}\node.exe cDQMlQAru0.xml 

The executed “cDQMlQAru0.xml” is a loader that decrypts the embedded code with a XOR function and then executes it with “vm.compileFunction”. 

decrypted[i] = (encrypted[i] - key[i % key.length] - i) & 0xFF 
The embedded decrypted code 

The decrypted code: 

  • Copies node.exe in “C:\Users\{user}\AppData\Local\{random_path}\{random_path}\_MJlLlt5.exe”. 
  • Adds a registry key for persistence with “conhost.exe –headless”. 
  • Decrypts “MRaQCipBIZeiZNx.log” and executes it with “_MJlLlt5.exe” stdin. 

The decryption algorithm is a custom stream-like decoding routing based on XOR, byte rotations and an accumulator: 

for e in range(len(data)): 
    byte = data[e] 
    g = prev 
    prev = byte 
    byte = (byte - g) & 0xff 
    byte = byte ^ n[e % len(n)] ^ ((e >> 8) & 0xff) 
    byte = si[byte] 
    byte = (byte - k[e % len(k)]) & 0xff
    result[e] = byte 

The final stage is to deploy EtherRAT. EtherRAT allows the attacker to: 

  • Execute arbitrary JavaScript code received by the C2 server. This allows the attacker to execute new commands, perform operations on files and folders, modify the registry, and exfiltrate data. 
  • Get a new C2 server using the Ethereum blockchain. 
  • Reobfuscate itself. 
  • Save the logs to “svchost.log”. 
Part of decrypted EtherRAT code 

The EtherRAT uses Ethereum’s “eth_call” JSON-RPC method to retrieve the active C2 URL from a smart contract on the Ethereum mainnet.  

The blockchain parameters in this case are: 

  • Contract: 0x88ea8d0bc4146f0a018e989df3fd089ac48f9a58 
  • Function selector: 0x7d434425 
  • Argument: 0xf6a772e163e64b07f658946f863b5d457d88f9f0 
The decoded C2 from Ethereum blockchain 

The contacted URLs to obtain the C2 server endpoint are: 

  • mainnet[.]gateway[.]tenderly[.]co 
  • rpc[.]flashbots[.]net/fast 
  • rpc[.]mevblocker[.]io 
  • eth-mainnet[.]public[.]blastapi[.]io 
  • ethereum-rpc[.]publicnode[.]com 
  • eth[.]drpc[.]org 
  • eth[.]merkle[.]io 

Polling requests use randomized URL patterns based on some parameters defined in the code: 

GET /api/<4-byte-hex>/<victim-uuid>/<4-byte-hex>.<ext>?<param>=<build-id> 
X-Bot-Server: <c2_url> 

In the analyzed sample, the parameters are: 

  • Build ID: “6f816d80-0d6c-4384-9cd6-6b79965fc08f” 
  • ext: randomly selected from “png”, “jpg”, “gif”, “css”, “ico”, “webp”. 
  • param: randomly selected from “id”, “token”, “key”, “b”, “q”, “s”, “v”. 

After startup, the RAT sends its own source code to the C2 server. The C2 responds with a newly obfuscated version of the script, which is written back to disk, making each execution generate a new file hash. 

POST /api/[REOBF_PATH]/<victim-uuid> 
Body: { "code": "<current_script_contents>", "build": "<build_id>" } 

After the EtherRAT execution, we observed different post-compromised cmd.exe activities to check the environment. For example: 

  • powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command “(Get-WmiObject Win32_VideoController).Name”
  • reg query “HKLM\SOFTWARE\Microsoft\Cryptography” /v MachineGuid 
  • powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command “(Get-WmiObject Win32_ComputerSystem).Domain” 
  • powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command “(Get-WmiObject Win32_ComputerSystem).PartOfDomain” 
  • cmd.exe /d /s /c “net session” 
EtherRAT logs 

PowerShell Loader 

The activities performed by the PowerShell loaders are very similar to the last stage of the JS script of the MSI installer: 

  • Downloads Node.js if it’s not present. 
  • Create the necessary directories. 
  • Decode the EtherRAT with a custom decryption algorithm. 
  • Execute Node.js with conhost.exe and the decrypted EtherRAT payload. 

We detected some variants of the PowerShell loader hosted on these websites; namely that the functions’ names and the decryption functions change in the analyzed PowerShell scripts. 

The decryption of EtherRAT payload with the custom decryption algorithm 

Tracking the malicious infrastructure 

When we analyzed the different websites with the “hacking-theme” pages, we found that in the past many had hosted multiple phishing pages in some specific paths. For example: 

  • /zht/sharep-redirect.html 
  • /bl/me.php 
  • /t/teams 
  • /teams/Windows/invite.php 

It seems that these domains and IPs are actually part of a much larger infrastructure that distributes malware, phishing, malicious documents, and remote software. It is possible that these infrastructures are shared by multiple threat actors who activate different URL endpoints based on the specific campaign. 

Interestingly, the majority of the domains related to this malicious infrastructure in the past also returned an HTML page related to a “Bulletproof Infrastructure” service.  

We found that these phishing campaigns typically start via emails with documents attached, such as PDF or Excel files. These documents ask the user to click a link to view another document. Below are two examples of the phishing documents attached to the emails:

These phishing pages typically ask the user to enter their email address, then continue the infection chain and distribute phishing or malware pages.  Below are some of the phishing pages detected within the malicious infrastructure:

Misconfigurations exposed the phishing kits 

While tracking malicious websites, we found one with an open directory containing part of the phishing kit used in the campaigns. 

Open directory hosting part of phishing kits

 

The open directory contained several folders with code and pages related to the phishing campaigns. 

Phishing kit code 

Additionally, some domains were misconfigured and allowed the download of “cl.zip”, which contained the source code for the “URL Cloaker” pages. 

Part of “URL Cloaker” code 

Indicators of Compromise (IOCs)  

IPs 

82[.]165[.]65[.]244: malicious infrastructure  

185[.]221[.]216[.]121: malicious infrastructure  

43[.]163[.]233[.]166: malicious infrastructure  

40[.]160[.]238[.]30: malicious infrastructure  

159[.]89[.]227[.]204: malicious infrastructure  

57[.]128[.]31[.]168: malicious infrastructure  

Domains 

ivorilla[.]cloud: EtherRAT distribution  

mx[.]nrlwz[.]com: EtherRAT distribution  

dn[.]eyqwj[.]com: EtherRAT distribution  

bi[.]mkrjcsw[.]com: EtherRAT distribution  

dorqen[.]casa: EtherRAT distribution  

kelvra[.]club: EtherRAT distribution  

cambioefectivo[.]com: EtherRAT C2  

vabelles[.]com: EtherRAT C2  

tranzed[.]org: EtherRAT C2  

kibrisarazi[.]com: EtherRAT C2  

aravisblog[.]com: EtherRAT C2  

publicspeakingtip[.]org: EtherRAT C2  

Acknowledgements 


Stop threats before they can do any harm.

Malwarebytes Browser Guard blocks phishing pages and malicious sites automatically. Free, one click to install. Add it to your browser →

  •  

Deepfake porn sites are going offline (re-air) (Lock and Code S07E12)

This week on the Lock and Code podcast…

If you weren’t taking deepfakes seriously before, it’s too late now to ignore them.

According to new research from Malwarebytes, one in three people who use AI every day said it’s okay to generate pornography of people without their consent.

Nearly 10 years ago, “deepfake” technology provided hobbyists and film editors with artificial intelligence (AI) tools to swap the face of one person onto the body of another. In its infancy, this technology brought silly film experiments like swapping Tom Cruise in Mission Impossible with Keanu Reeves. Today, this same technology produces something far more harmful—fake nude images of teenagers.

On the Lock and Code podcast today with host David Ruiz, we are re-visiting an interview from 2024, in which we spoke with a lawyer named David Chiu about his lawsuit against 16 deepfake nude generation websites.

The websites named in that lawsuit often needed just one image of a person to generate fake pornography. And while nearly everyone has at least one image of themselves online, even if they had hundreds, the path towards deletion is somewhat understood—start by deactivating and deleting popular social media accounts. But for teenagers today, raised mostly online, and who share images directly with friends and boyfriends and girlfriends and exes, it’s likely impossible to remove every visual trace of themselves. Also, they shouldn’t have to face this problem alone.

The Lock and Code podcast frequently discusses structural problems that require individual management. You have to skirt corporate data collection. You have to find the automated license plate readers in your hometown. You have to review every single message you get with a certain antagonism, to guard yourself against scams.

So, it’s rare to encounter a solution that benefits more than one person.

Chiu serves as the City Attorney for San Francisco, which means his department can file a lawsuit on behalf of not just the people of San Francisco, but also California, and that’s what his team did in going after the deepfake websites.

Since then, Chiu’s department has shut down 10 deepfake nude websites, and it received a settlement agreement from a company called Briver LLC to no longer operate any website that creates nonconsensual deepfake pornography.

And, as California goes, so goes the nation.

In May of last year, the Take It Down Act became effective as law in the United States, which criminalizes “revenge porn” and AI-generated nonconsensual intimate imagery. The law is not perfect but so far it is being used as intended. Last month, two men in the US were among the first to be charged with violating the Take It Down act for allegedly creating deepfake nudes that, according to the AP, “included both celebrities as well as private women, including recent high school graduates.”

Today, we revisit our conversation with San Francisco City Attorney David Chiu about the important fight against deepfake porn and the clear threat that his department found against the public.

“At least one of these websites specifically promotes the non-consensual nature of this. So, and I’ll just quote, ‘Imagine wasting time taking her out on dates when you can just use website X to get her nudes.'”

Tune in today to listen to the full conversation.

Show notes and credits:

Intro Music: “Spellbound” by Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
http://creativecommons.org/licenses/by/4.0/
Outro Music: “Good God” by Wowa (unminus.com)


Listen up—Malwarebytes doesn’t just talk cybersecurity, we provide it.

Protect yourself from online attacks that threaten your identity, your files, your system, and your financial well-being with our exclusive offer for Malwarebytes Premium Security for Lock and Code listeners.

  •  

Check Point Joins OpenAI’s Trusted Access for Cyber Program and Daybreak Initiative

The model behind a security workflow shapes how fast a threat is caught, how accurately an incident is investigated, and how much a defender can trust the result. We treat that choice with care. Today we’re taking a clear step forward: Check Point has joined OpenAI’s Daybreak initiative through its Trusted Access for Cyber (TAC) program. These are real steps in how we bring AI into our defensive operations, and in the security we deliver to our customers. What Trusted Access for Cyber Gives Us Trusted Access for Cyber is OpenAI’s program for vetted security organizations that need its most […]

The post Check Point Joins OpenAI’s Trusted Access for Cyber Program and Daybreak Initiative appeared first on Check Point Blog.

  •  

From SQLi to RCE – Exploiting LangGraph’s Checkpointer

By Yarden Porat

AI agents need memory. Frameworks like LangGraph provide it through checkpointers – persistence layers that store execution state. But what happens when that persistence layer isn’t locked down?

Key Points

  • Check Point Research analyzed LangGraph, an open-source framework for stateful AI agents with over 50 million monthly downloads, and uncovered three vulnerabilities in its persistence layer.
  • Two of them chain into remote code execution: a SQL injection in the SQLite checkpointer (CVE-2025-67644) and an unsafe msgpack deserialization (CVE-2026-28277).
  • A third, parallel issue (CVE-2026-27022) introduces the same injection class into the Redis checkpointer.
  • Who’s at risk: teams self-hosting LangGraph with the SQLite or Redis checkpointer, where the application exposes get_state_history() with a user-controlled filter. LangChain’s managed cloud service, LangSmith Deployment (formerly LangGraph Platform), runs PostgreSQL and is not vulnerable.
  • LangChain patched all three issues. Users should update to langgraph-checkpoint-sqlite 3.0.1+, langgraph 1.0.10+, and langgraph-checkpoint-redis 1.0.2+.

Background

LangGraph is an open-source framework for building stateful, multi-agent AI systems with built-in persistence. It’s an extension of LangChain, with over 50 million monthly downloads according to PyPI stats.

Checkpointers are LangGraph’s persistence layer that stores execution state at each step. LangGraph supports two checkpointer implementations: SQLite and PostgreSQL.

Vulnerability #1: SQL Injection (CVE-2025-67644)

The SQLite Checkpointer Database Schema:
The SQLite checkpointer uses an internal table called checkpoints with the following structure:

CREATE TABLE checkpoints (
    thread_id TEXT NOT NULL,
    checkpoint_ns TEXT NOT NULL DEFAULT '',
    checkpoint_id TEXT NOT NULL,
    parent_checkpoint_id TEXT,
    type TEXT,
    checkpoint BLOB,
    metadata BLOB,
    PRIMARY KEY (thread_id, checkpoint_ns, checkpoint_id)
);

The metadata column stores additional contextual information about each checkpoint in JSON format. For example:

{
  "user_id": "alice",
  "step": 1,
  "source": "input"
}

The list() Function and Filtering:

When calling the list() function on sqliteSaver (the checkpointer), the filter parameter is used to query checkpoints based on their metadata:

def list(
    self,
    config: RunnableConfig | None,
    *,
    filter: dict[str, Any] | None = None,  # Used to filter by metadata
    before: RunnableConfig | None = None,
    limit: int | None = None,
) -> Iterator[CheckpointTuple]:

The filter parameter is passed to an internal function called _metadata_predicate, which constructs the SQL WHERE clause to query checkpoints by their metadata fields.

# process metadata query
    for query_key, query_value in filter.items():
        operator, param_value = _where_value(query_value)
        predicates.append(
            f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}"
        )
        param_values.append(param_value)

    return (predicates, param_values)

The Injection

The vulnerability exists in how _metadata_predicate handles the query_key from the filter dictionary.
Notice this critical line:

f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}"

An attacker-controlled filter could provide a query_key with a ' character that will escape the JSON path string and inject arbitrary SQL code.

Injection -> Arbitrary Deserialization

To understand how SQL injection leads to arbitrary deserialization, we need to see the complete picture.
Here’s the SQL query that gets executed in list():

query = f"""SELECT thread_id, checkpoint_ns, checkpoint_id, parent_checkpoint_id, type, checkpoint, metadata
FROM checkpoints
{where}
ORDER BY checkpoint_id DESC"""

This query retrieves checkpoint data from the database, including the checkpoint’s BLOB column.
The results are then processed:

async for (
    thread_id,
    checkpoint_ns,
    checkpoint_id,
    parent_checkpoint_id,
    type,
    checkpoint,  # ← This comes directly from the SQL query results
    metadata,
) in cur:  # ← cur contains the query results
    # ... 
    yield CheckpointTuple(
        # ...
        self.serde.loads_typed((type, checkpoint)),  # ← Deserialization
        # ...
    )

The checkpoint contains serialized data, and when fetched gets deserialized.

The Attack

Using SQL injection in the WHERE clause, an attacker can inject a UNION SELECT that adds their own row to the query results:

SELECT thread_id, checkpoint_ns, checkpoint_id, parent_checkpoint_id, type, checkpoint, metadata
FROM checkpoints
WHERE ... (injected: ') UNION SELECT 'thread1', 'ns', 'checkpoint1', NULL, 'msgpack', X'', '{}' -- )
ORDER BY checkpoint_id DESC

The injected UNION SELECT returns a fake checkpoint row where the checkpoint column contains attacker-controlled serialized data. When the code loops through the query results, it deserializes this malicious checkpoint’s BLOB, giving the attacker arbitrary deserialization

Vulnerability #2: MsgPack Unsafe Deserialization (CVE-2026-28277)

Now let’s examine what happens during deserialization. The self.serde.loads_typed() function that deserializes checkpoint data looks like this:

def loads_typed(self, data: tuple[str, bytes]) -> Any:
    type_, data_ = data
    if type_ == "null":
        return None
    elif type_ == "bytes":
        return data_
    elif type_ == "bytearray":
        return bytearray(data_)
    elif type_ == "json":
        return json.loads(data_, object_hook=self._reviver)
    elif type_ == "msgpack":
        return ormsgpack.unpackb(
            data_, ext_hook=self._unpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS
        )
    elif self.pickle_fallback and type_ == "pickle":
        return pickle.loads(data_)
    else:
        raise NotImplementedError(f"Unknown serialization type: {type_}")

Formats

  1. Pickle –  is disabled by default
  2. JSON –  The json.loads() with object_hook was discussed in our LangGrinch research, but does not lead to code execution
  3. Msgpack – This is the one we are interested in

What is msgpack?

MessagePack (msgpack) is a binary serialization format designed to be faster and more compact than JSON. LangGraph uses ormsgpack, a Rust-based implementation with Python bindings.

Msgpack Extensions

MessagePack allows developers to define custom extension types to handle additional data types beyond its built-in primitives. LangGraph implemented its own extension handler to support serialization of custom Python objects.

When the type_ is msgpack, the code calls:

ormsgpack.unpackb(data_, ext_hook=self._unpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS)
```
The `ext_hook` parameter points to LangGraph's custom implementation: `_msgpack_ext_hook`.

```python
def _msgpack_ext_hook(code: int, data: bytes) -> Any:
    if code == EXT_CONSTRUCTOR_SINGLE_ARG:
        try:
            tup = ormsgpack.unpackb(
                data, ext_hook=_msgpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS
            )
            # module, name, arg
            return getattr(importlib.import_module(tup[0]), tup[1])(tup[2])
        except Exception:
            return

When an attacker controls the serialized data, they control both the extension code and the data bytes.

The vulnerability

If we pass a msgpack with EXT_CONSTRUCTOR_SINGLE_ARG code, and the tuple:

  1. os
  2. system
  3. Command (“echo PWN > /tmp/pwned.txt” for example)

When this line executes:

return getattr(importlib.import_module(tup[0]), tup[1])(tup[2])

It will:

1. Import the os module

2. Get the system function from it

3. Call os.system("echo PWN > /tmp/pwned.txt")

This gives an attacker arbitrary code execution – by calling os.system() with attacker-controlled commands, they can execute any shell command on the server.

The Attack Chain: Combining Both Vulnerabilities

Now let’s walk through how an attacker chains these two vulnerabilities together to achieve remote code execution.

The Entry Point: When a developer exposes get_state_history(), it internally calls the checkpointer’s list() method to retrieve historical checkpoints:

def get_state_history(
    self,
    config: RunnableConfig,
    *,
    filter: Optional[Dict[str, Any]] = None,
    before: Optional[RunnableConfig] = None,
    limit: Optional[int] = None,
) -> Iterator[StateSnapshot]:
    # ...
    for checkpoint_tuple in self.checkpointer.list(config, filter=filter, before=before, limit=limit):
        # Process and return checkpoint data

If the filter parameter comes from user input without sanitization, an attacker controls the dictionary keys passed to the SQL injection vulnerability.

The Attack Flow

1. Craft Malicious Payload: The attacker prepares a msgpack payload containing instructions to execute arbitrary code (e.g., run a shell command).

2. Exploit SQL Injection: The attacker sends a malicious filter parameter that exploits the SQL injection vulnerability. This injection adds a fake checkpoint row to the database query results, where the checkpoint column contains their malicious msgpack payload.

3. Trigger Deserialization: When the application processes the query results, it encounters the injected fake checkpoint and deserializes the malicious msgpack data.

4. Code Execution: The unsafe deserialization executes the attacker’s payload, giving them remote code execution on the server.

Vulnerability #3: SQL Injection in the Redis Checkpointer (CVE-2026-27022)

The same injection class affects langgraph-checkpoint-redis: user-controlled keys in the filter dictionary are interpolated directly into the query instead of bound as parameters. Preconditions match CVE-2025-67644 (the application exposes get_state_history() with a user-controlled filter and uses the Redis checkpointer). Patched in langgraph-checkpoint-redis 1.0.2.

Additional SQL Injection Findings

Beyond the primary SQL injection in the filter parameter, we identified additional defense-in-depth SQL injection issues in both the SQLite and PostgreSQL checkpointers. These involved direct concatenation of integer values (such as LIMIT and ttl parameters) into SQL queries instead of using parameterized bindings.

Since Python doesn’t enforce type hints at runtime, these parameters could still accept malicious string input. We worked with the LangChain team during disclosure to remediate these issues using parameterized queries.

Disclosure Timeline

2025-11-19: CVE-2025-67644 (SQL injection), CVE-2026-28227 (msgpack deserialization) And CVE-2026-27022 (Redis injection) disclosed to LangChain team

2025-12-10: CVE-2025-67644 fixed and publicly released in langgraph-checkpoint-sqlite 3.0.1

2026-02-20: CVE-2026-27022  fixed and publicly released in langgraph-checkpoint-redis 1.0.2

2026-03-05: CVE-2026-28277  fixed and publicly released in langgraph-checkpoint 4.0.1

Note on Vendor Response

The LangChain team responded quickly to fix the critical SQL injection vulnerability, which effectively breaks the attack chain described in this research. They continue to work methodically on additional remediation efforts, including the msgpack deserialization issue.

Additional Research

There was significant community research into LangGraph security during November and December 2025. Other security researchers independently discovered CVE-2025-67644 and CVE-2026-28277. Full credits can be found in LangChain’s security advisories.

The post From SQLi to RCE – Exploiting LangGraph’s Checkpointer appeared first on Check Point Research.

  •  

Identity Is the New Attack Surface: How Infostealers Are Reshaping Enterprise Risk

Blogs

Blog

Identity Is the New Attack Surface: How Infostealers Are Reshaping Enterprise Risk

Our new guide explores how infostealers are fueling modern identity-based attacks and how organizations can build a proactive defense before stolen access is weaponized.

SHARE THIS:
Default Author Image
June 10, 2026

The New Reality of Identity-Based Threats

A publicly exposed database surfaced in early 2026 containing more than 149 million stolen login credentials. The records were not tied to a single breach or organization. Instead, they had been quietly collected over time from devices infected with information-stealing malware, with each record containing usernames, passwords, session data, and the context needed to use them.

Unlike traditional breach dumps, this data was structured, searchable, and immediately actionable. Credentials were mapped to specific services, session artifacts reflected active logins, and much of the information was recent enough to enable direct access without triggering traditional security controls.

This incident reflects a broader shift in the threat landscape.

More than 11.1 million devices were infected with infostealers last year, fueling a supply of over 3.3 billion stolen credentials, session cookies, cloud tokens, and other forms of identity data now circulating across illicit markets.

11.1 million infected hosts and devices
3.3 billion stolen credentials
Top 5 most prolific infostealers in 2025 (by infected hosts or devices):
Lumma
Acreed
Rhadamanthys
Vidar
StealC
Top 6 countries affected by information-stealing malware, 2025:
India
Brazil
Indonesia
Vietnam
Phillipines
United States

For security teams, the challenge is no longer simply detecting a breach after it occurs. It is understanding when access may already exist — where compromised credentials are circulating, how they are being used, and how quickly they can be weaponized.

That’s why Flashpoint created Identity Is the New Attack Surface: A Guide to Infostealers and Proactive Defense.

Drawing on Flashpoint’s Primary Source Collection (PSC) and analyst-driven intelligence, this guide helps IT, Threat Intelligence, Fraud, and HUNT teams understand how infostealers operate, how stolen identity data fuels real-world attacks, and how organizations can move from reactive response to proactive defense.

The guide explores:

  • How today’s most active infostealers power modern attack chains
  • How threat actors weaponize stolen credentials, cookies, and session data
  • How organizations can operationalize infostealer intelligence for proactive defense
  • How to evaluate infostealer intelligence providers and detection capabilities

Why Identity Has Become the Preferred Attack Surface

For years, security teams focused on vulnerabilities, malware delivery, and network intrusion as the primary paths to compromise. Increasingly, however, threat actors are taking a different

Modern infostealers such as Lumma, StealC, Vidar, Acreed, and Rhadamanthys provide attackers with something more valuable than initial access: usable identity. These malware families collect credentials, browser artifacts, session cookies, application data, and host metadata that help threat actors understand how a victim authenticates and what systems they can access.

A single infected device can expose credentials, browser artifacts, session cookies, application data, host metadata, and access to enterprise SaaS platforms. Together, these artifacts create a detailed profile of how a user authenticates, what systems they access, and how those systems trust that identity.

This is what makes infostealer data so valuable.

For years, organizations have invested heavily in detecting malware, blocking exploits, and hardening infrastructure. Meanwhile, attackers have increasingly shifted to a simpler strategy: logging in with valid identities.

Infostealers have fundamentally changed the economics of access. Threat actors no longer need to compromise a network directly when billions of credentials, session cookies, and authentication artifacts are already circulating in underground ecosystems. The challenge for defenders has risen from preventing compromise to identifying where access already exists and how quickly it can be weaponized.

Ian Gray, Vice President of Intelligence at Flashpoint

Identity data is inherently reusable. A stolen credential can be tested across multiple services. A session cookie can potentially allow attackers to hijack authenticated sessions. Browser and host metadata can help threat actors recreate a victim’s environment and bypass security controls designed to detect suspicious logins.

What begins as a single infection can quickly evolve into access across multiple systems, applications, and organizations.

What Is an Identity-Based Attack?

Identity-based attacks occur when threat actors use legitimate credentials, session cookies, authentication tokens, or other identity artifacts to gain access to systems and applications. Rather than exploiting a vulnerability or deploying malware inside a target environment, attackers authenticate as trusted users using stolen identity data.

This shift is one of the primary reasons infostealers have become so valuable. Modern infostealer logs often contain far more than usernames and passwords. They may also include browser cookies, session information, host metadata, application data, and other artifacts that help attackers understand how a user authenticates and what systems they can access. When combined, this information enables account takeover, fraud, lateral movement, and other forms of identity-based abuse.

From Credential Theft to Identity Exploitation

The way threat actors operationalize stolen data is evolving just as rapidly as the data itself.

Historically, attackers often had to manually review stolen credentials and determine which accounts were worth pursuing. Today, that process is increasingly automated.

Infostealer logs can be aggregated, tested, and prioritized at scale, allowing threat actors to rapidly identify valid access across enterprise systems, SaaS platforms, VPNs, and cloud environments.

Flashpoint identifies this as a hybrid threat: the convergence of large-scale identity compromise and automated exploitation.

Once valid access is identified, attackers can move quickly. Credentials may be reused across services. Session data can be leveraged for account takeover. Access can be sold to ransomware operators, fraud actors, or other criminal groups. In many cases, exposure itself becomes part of the attack lifecycle rather than merely a precursor to it.

The result is a threat landscape where stolen identity data is not simply stored and sold. It is continuously tested, validated, reused, and operationalized.

Turning Exposure Into Actionable Intelligence

For defenders, prevention remains important. But prevention alone is no longer enough.

Organizations must also be able to identify when credentials, session cookies, and other identity artifacts have already been exposed and are circulating within underground ecosystems.

The earliest opportunity to intervene is often after data has been exfiltrated but before attackers have successfully operationalized it.

Achieving that visibility requires more than traditional breach feeds or aggregated datasets.

Flashpoint’s Primary Source Collection approach provides direct visibility into the forums, marketplaces, Telegram channels, malware repositories, and illicit communities where infostealer activity originates. Rather than relying solely on recycled breach data, Flashpoint continuously collects from the environments where stolen identity data is first shared, sold, and operationalized.

However, collection alone is not enough.

Raw infostealer logs are noisy, fragmented, and difficult to operationalize at scale. Flashpoint transforms these logs into structured intelligence through a multi-stage workflow that includes:

  • Source ingestion from underground ecosystems
  • Normalization and de-duplication of collected data
  • Automated parsing and enrichment of credentials, cookies, host metadata, and malware attribution
  • Structured output that supports alerts, investigations, and integrations across existing security workflows

This process helps defenders understand not only what was exposed, but who may be affected, how exposure occurred, what systems may be at risk, and how quickly action is required.

Building a Proactive Defense Across the Identity Layer

The rise of infostealers has fundamentally changed how organizations should think about attack surface management.

The attack surface is no longer limited to infrastructure, endpoints, or internet-facing applications. It now includes the digital identities of employees, partners, vendors, and customers.

Security teams need visibility into the identity layer itself — understanding where exposure exists, how attackers are leveraging stolen data, and what actions should be taken before access is exploited.

By combining direct visibility into underground ecosystems with structured, actionable intelligence, organizations can identify compromised accounts earlier, uncover infection trends, prioritize response efforts, and reduce the likelihood of downstream compromise.

Download Identity Is the New Attack Surface: A Guide to Infostealers and Proactive Defense to learn how your organization can build a proactive defense program across the identity layer.

Key Infostealer Statistics

According to Flashpoint research:

  • More than 11.1 million devices were infected with infostealers in the last year.
  • Over 3.3 billion credentials, session cookies, cloud tokens, and identity artifacts are circulating across illicit markets.
  • Flashpoint analysts identified 30+ active infostealer strains being sold across underground ecosystems.
  • Flashpoint’s credential database contains 48+ billion credentials, including more than 1 billion tied to infostealer activity.
  • More than 4.2% of infostealer-exposed credentials include browser cookies that may support session hijacking.
  • Flashpoint can collect and parse some infostealer logs within one to two days of infection.

Frequently Asked Questions (FAQ)

FAQ: Infostealers and Identity-Based Threats

What is an infostealer?

An infostealer is a type of malware designed to collect sensitive information from an infected device. Depending on the strain, this can include usernames and passwords, browser cookies, session tokens, saved payment information, cryptocurrency wallets, system metadata, and other identity-related artifacts.

How do infostealers work?

Infostealers infect a victim’s device and collect information such as credentials, browser data, session cookies, autofill information, cryptocurrency wallet data, and system metadata. The stolen information is packaged into files known as infostealer logs, which can then be sold, shared, or operationalized by threat actors.

What information can infostealers steal?

Depending on the malware family, infostealers can collect usernames and passwords, session cookies, authentication tokens, browser history, saved payment information, cryptocurrency wallet data, system information, installed applications, and other identity-related artifacts. The goal is to provide attackers with enough information to access accounts and impersonate legitimate users.

What are the most common infostealers?

The infostealer ecosystem changes rapidly, but Flashpoint analysts currently track strains such as Lumma (also known as LummaC2/Remus), StealC, Vidar, Acreed, and Rhadamanthys among the most prominent malware families driving credential theft and identity-based attacks.

Why are infostealers so dangerous?

Infostealers provide attackers with more than credentials. Modern infostealer logs often contain the context needed to use stolen data, including session information, browser artifacts, and device metadata. This allows threat actors to perform account takeovers, move laterally within environments, and gain access to business-critical systems. According to Flashpoint’s 2026 Global Threat Intelligence Report, more than 11.1 million devices were infected with infostealers last year, contributing to a pool of over 3.3 billion stolen credentials, session cookies, cloud tokens, and other identity artifacts.

What is an infostealer log?

An infostealer log is a package of data collected from an infected device. Logs may contain credentials, cookies, browser data, application information, host metadata, and other artifacts that help attackers understand how a victim authenticates and what systems they can access.

Can infostealers bypass multi-factor authentication (MFA)?

In some cases, yes. While multifactor authentication remains a critical security control, stolen session cookies and authenticated session data can sometimes allow threat actors to hijack existing sessions without needing to complete the MFA process themselves. Flashpoint found that more than 4.2% of infostealer-exposed credentials in its dataset were associated with browser cookies, highlighting the growing importance of session-based risk.

How do threat actors obtain infostealer logs?

Infostealer logs are frequently bought and sold across illicit marketplaces, forums, Telegram channels, and other underground communities. Many are distributed through Malware-as-a-Service (MaaS) offerings that make infostealer capabilities accessible to a wide range of threat actors. Flashpoint analysts identified more than 30 unique infostealer strains actively offered for sale across underground ecosystems.

How can organizations detect credential exposure from infostealers?

Organizations can monitor underground sources where stolen data is shared and sold, identify exposed credentials associated with their domains, and investigate related artifacts such as cookies, host metadata, and malware attribution. The earlier exposure is identified, the greater the opportunity to remediate before attackers operationalize access. Flashpoint collects and parses some infostealer logs within one to two days of infection, helping organizations detect exposure closer to the point of compromise.

What should organizations do if employee credentials appear in an infostealer log?

Organizations should immediately assess the scope of exposure, reset affected credentials, invalidate active sessions, review authentication activity, investigate the infected device, and determine whether additional accounts or systems may have been impacted.

How is Flashpoint’s approach to infostealer intelligence different from traditional breach monitoring?

Many organizations rely on aggregated breach feeds or credential dumps that may be weeks or months old by the time they are discovered. Flashpoint’s Primary Source Collection (PSC) approach provides direct visibility into the forums, marketplaces, Telegram channels, and underground communities where stolen identity data is first shared, sold, and operationalized.

In addition to collecting raw infostealer logs, Flashpoint parses and enriches the data with context such as malware attribution, session cookies, host metadata, browser artifacts, and affected identities. Today, Flashpoint’s credential database contains more than 48 billion credentials, including over 1 billion tied to infostealer activity, providing organizations with actionable intelligence rather than raw exposure data.

Request a demo today.

The post Identity Is the New Attack Surface: How Infostealers Are Reshaping Enterprise Risk appeared first on Flashpoint.

  •  

Understanding Illicit Ecosystems: Weaponizing Mainstream Apps and Social Infrastructure

Blogs

Blog

Understanding Illicit Ecosystems: Weaponizing Mainstream Apps and Social Infrastructure

As part of our ongoing series, we focus on the shared infrastructure that fuels threat actors; the intersection of mainstream social media, open-source messaging platforms, and gaming communities.

SHARE THIS:

Threat actors and their illicit communities do not exist in a vacuum. To scale their operations, coordinate financial fraud, deploy malware, and recruit new talent, threat actors must interface with the broader digital world. This means leveraging everyday, public digital spaces to facilitate illicit activity, effectively hiding in plain sight.

The Clearnet Threat Landscape: Hiding in Plain Sight

When conceptualizing the cybercriminal underground, it is easy to focus exclusively on Tor-based onion sites or restricted-access dark web forums and marketplaces. However, a massive portion of modern illicit activity thrives on the clearnet. Threat actors heavily utilize commercial social media and public messaging networks to coordinate fraud, deploy malware, and run public relations campaigns for their operations.

At first glance, conducting illicit operations on highly monitored, mainstream platforms seems counterintuitive. However, the massive, continuous volume of legitimate traffic on the clearnet provides a form of operational security. By blending into the noise, threat actors can maintain a highly accessible digital presence. This visibility is crucial for their business models: it allows them to maintain a low barrier to entry for potential recruits and targets who know exactly what markers to look for, or who are systematically funneled into these spaces.

How Threat Actors Weaponize Consumer Platforms

The misuse of mainstream communication tools has changed how threat actors interact. Rather than waiting for users to seek out the dark web, cybercriminals are actively meeting their targets or co-conspirators on platforms designed for daily socialization.

Discord

Originally built to connect gaming communities, Discord’s rapid growth and robust infrastructure have inadvertently made it a target for malicious activity. Cybercriminals treat the platform as a multi-functional tool for both technical infrastructure, social engineering, and radicalization.

On a technical level, advanced persistent threats (APTs) and other threat actors exploit Discord’s content delivery network (CDN) to host and distribute malware. Because traffic to Discord domains is generally trusted by corporate networks, threat actors can potentially use it to deliver payloads—such as infostealers and remote access trojans (RATs)—bypassing standard security perimeters.

Beyond hosting malware, extremist groups across various ideological spectrums often target the platform’s demographic, which skews heavily towards younger tech-savvy users. This group provides an impressionable pool of adolescents who may be susceptible to grooming, indoctrination, and recruitment into illicit operations.

Case Study: The Targeting and Recruitment Mechanics of “The Com”

While monitoring The Com, Flashpoint analysts have observed the systematic use of platforms like Discord, Roblox, and Minecraft to run predatory extortion pipelines. The mechanics of this ecosystem takes place through a multi-phase methodology:

  1. Platform Scouting: Recruiters patrol servers on popular youth-centric gaming platforms, such as Discord, Roblox, and Minecraft. They look for minors showing signs of social isolation, depression, disordered eating, or a desire to belong.
  2. Building Trust and “Love Bombing”: Initial engagements are seemingly harmless. However, trust is built quickly to establish a sense of indebtedness. Recruiters offer gifts such as in-game perks/currency, premium subscriptions, or other digital items. In some cases, a romantic facade is used to establish a connection. In either scenario, “love bombing” creates an immediate feeling of psychological obligation in the target.
  3. Platform Migration: Once rapport is established, the recruiter moves the target away from the game and into an encrypted app or private Discord server, following a public-to-private strategy. By moving the interaction away from the original platform’s safety controls, the recruiter can isolate the target in a more controlled environment.

Once isolated, perpetrators coerce victims into sending sensitive imagery or CSAM. This material is immediately compiled and weaponized as leverage for blackmail via doxxing. This creates a severe psychological trap in which the victim feels compelled to partake in escalating illegal activity to keep their previous actions hidden. This drives the victim to transition from a victim into an aggressor to escape their own abuse.

Telegram

While many social media and messaging platforms can serve as an initial funnel for engagement, Telegram has been known to be used from time to time as an operational hub for the broader illicit ecosystem. Since the arrest of Pavel Durov, Telegram has begun working more closely with law enforcement, leading to several key arrests and major disruptions due to their cooperation. 

The platform occupies a unique space in threat intelligence and open source intelligence (OSINT). While the vast majority of its user base is entirely benign, its minimal moderation policy and robust channel architecture have made it vital to public and private intelligence gathering.

Telegram functions as an open marketplace and real-time coordination center for a vast spectrum of threat actors. Flashpoint has observed it being used by:

  1. State-sponsored APT groups and hacktivists
  2. Geopolitical actors and mercenary groups distributing battlefield intelligence and propaganda
  3. Cybercriminal syndicates coordinating financial fraud schemes, check fraud, and the sale of compromised data.

Furthermore, threat actors routinely use other public-facing platforms like X (formerly Twitter) alongside Telegram to amplify their impact. They leverage the broad reach of social media to broadcast proof of their compromises, hype up ransomware leaks, and exert public pressure on corporate victims during extortion cycles. Concurrently, Telegram often acts as the backend repository where the stolen data is hosted, discussed, and monetized.

Monitor the Clearnet Using Flashpoint

The evolution of illicit ecosystems demonstrates that the lines between the dark web and the clearnet have intersected. Whether analyzing the activities of extremist and threat actor groups or tracking the predatory pipelines of The Com, defenders must look beyond traditional intelligence sources.

Because malicious actors rely heavily on consumer messaging apps and social platforms to coordinate attacks, leak data, and target people, monitoring these public-to-private pipelines is an essential component of threat intelligence. Uncovering these physical and cyber threats requires best-in-class threat intelligence and OSINT investigations capable of parsing the massive noise of the clearnet to find the signals of illicit coordination.

Request a demo to see how Flashpoint empowers security teams to monitor these decentralized threat landscapes to proactively protect their critical assets.

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

See Flashpoint in Action

The post Understanding Illicit Ecosystems: Weaponizing Mainstream Apps and Social Infrastructure appeared first on Flashpoint.

  •  

Connecting Vulnerability Intelligence to Real-World Exposure With Flashpoint EASM

Blogs

Blog

Connecting Vulnerability Intelligence to Real-World Exposure With Flashpoint EASM

In this post, we explore how Flashpoint’s External Attack Surface Management (EASM) capability helps organizations continuously discover internet-facing assets, identify exposure to critical vulnerabilities, and prioritize remediation efforts based on real-world risk.

SHARE THIS:
Default Author Image
June 5, 2026

The volume of vulnerability disclosures is higher than ever, yet most security teams are still struggling to act.

From vulnerability scanners to public sources and AI-accelerated discovery, organizations are often drowning in findings, but lack the context to prioritize what affects their perimeter and is actively being exploited. 

Compounding this challenge is the growing issue of unknown and forgotten assets. Up to 95% of a company’s assets change each year, creating critical external blind spots and leaving them vulnerable to attacks on unmonitored infrastructure.

As attack surfaces expand due to cloud adoption, shadow IT, acquisitions, and distributed environments, many organizations struggle to maintain control over what assets they own, what software is running on those assets, and therefore, where exposures exist. You can’t patch what you don’t know is there.

These are the challenges Flashpoint External Attack Surface Management (EASM) is designed to address. With the introduction of EASM in Flashpoint Ignite, organizations can continuously discover internet-facing assets, map them to Flashpoint Vulnerability Intelligence, and prioritize remediation efforts based on actual risk rather than vulnerability volume and severity alone.

“The most effective vulnerability management programs are built on more than vulnerability awareness alone,” said Josh Lefkowitz, Co-Founder and CEO of Flashpoint. “Organizations need to understand where exposure exists within their environment and focus remediation efforts where they will have the greatest impact. Flashpoint EASM helps connect vulnerability intelligence directly to exposed assets, giving security teams a clear path from identification to remediation.”

Understanding the Exposure Gap

For many organizations, vulnerability intelligence is no longer the limiting factor.

Security teams have access to more vulnerability data than ever before. They can track newly disclosed vulnerabilities, monitor exploit activity, review KEV catalogs, and identify emerging threats often within hours of disclosure. And Flashpoint customers get the added advantage of learning about vulnerabilities up to 2 weeks faster than NVD, as well as the growing 105K+ vulnerabilities that never make it to public sources.

But understanding whether those vulnerabilities affect assets the organization actually owns remains a challenge. And that challenge exists because asset visibility and vulnerability intelligence often live in separate workflows.

  • Asset inventories become outdated. 
  • Cloud infrastructure changes constantly. 
  • New internet-facing services appear without centralized oversight. 
  • Acquisitions introduce unfamiliar infrastructure. 
  • Shadow IT creates blind spots that security teams may not discover until after exposure is identified.

As environments become more dynamic, validating exposure often requires analysts to pivot between scanners, spreadsheets, asset inventories, cloud consoles, and vulnerability intelligence sources.

As a result, organizations must face a growing disconnect between understanding which vulnerabilities are out there vs. whether the organization is actually at risk.

Connecting Asset Discovery to Vulnerability Intelligence

Flashpoint EASM begins by discovering internet-facing assets associated with an organization, giving security teams an attacker’s-eye view of their external perimeter. Using seed domains and IP addresses, it initiates ongoing discovery across the external environment, uncovering infrastructure that often evades internal tracking, including:

  • Shadow IT and untracked cloud resources
  • Forgotten infrastructure and legacy internet-facing assets
  • Newly exposed services and subdomains

Once assets are validated, they are surfaced within Ignite and automatically correlated with Flashpoint Vulnerability Intelligence, including pre-NVD findings, KEV intelligence, and proprietary vulnerability coverage beyond public sources. Teams receive alerts when new assets are discovered and when newly identified vulnerabilities affect monitored assets. For a full walkthrough of the workflow, see the Flashpoint EASM product update.

Prioritizing What Actually Requires Action

Not every vulnerability on your attack surface demands the same response. Flashpoint EASM helps teams cut through the noise by combining asset exposure with intelligence on what attackers are actively exploiting, so remediation efforts focus on the vulnerabilities that create meaningful risk.

Rather than focusing on vulnerability severity alone, security teams can now prioritize based on actual exploit activity targeting their attack surface. Flashpoint EASM provides the clarity needed to make that shift.

Building a Continuously Monitored, De-Risked Perimeter

As attack surfaces continue to evolve, organizations need full attack surface visibility, intelligence on what attackers are exploiting, and an efficient path to remediation.

By connecting Flashpoint Vulnerability Intelligence directly to their exposed assets, organizations can move from reactive investigation to having confidence that their external perimeter is continuously monitored and de-risked.

Learn more about Flashpoint External Attack Surface Management and request a demo.

Frequently Asked Questions (FAQ)

What is External Attack Surface Management (EASM)?

External Attack Surface Management (EASM) helps organizations discover, monitor, and assess internet-facing assets that could be exposed to attackers.

This includes domains, subdomains, IP addresses, cloud infrastructure, internet-accessible services, and other externally exposed assets that may introduce security risk.

By continuously monitoring these assets, organizations can better understand their external attack surface and identify exposures that require remediation.

How is Flashpoint EASM different from traditional asset inventories?

Traditional asset inventories, CMDBs, and internal scanners often depend on manual updates and may not reflect the full scope of an organization’s internet-facing environment.

Flashpoint EASM continuously discovers external assets and maps them to Flashpoint Vulnerability Intelligence, helping organizations identify exposures that may otherwise remain difficult to track through static inventories alone.

Why is attack surface visibility important?

As organizations adopt cloud services, acquire new businesses, deploy new applications, and support distributed environments, external attack surfaces change constantly.

Without continuous visibility, security teams may struggle to identify unknown assets, shadow IT, forgotten infrastructure, or newly exposed services that increase organizational risk.

How does Flashpoint EASM help prioritize remediation?

Knowing a vulnerability is severe is only half the picture. Flashpoint EASM correlates discovered assets with our proprietary vulnerability intelligence, including KEV data and pre-NVD findings, so teams can prioritize based on the severity of vulnerabilities present on their actual attack surface.

What vulnerability intelligence is included?

Flashpoint EASM integrates directly with Flashpoint Vulnerability Intelligence, including:

  • Proprietary vulnerability coverage beyond public sources
  • Pre-NVD vulnerability findings
  • Known Exploited Vulnerability (KEV) intelligence
  • Vulnerability enrichment and contextual risk information

This allows organizations to understand both exposure and vulnerability relevance within a single workflow.

Does Flashpoint EASM support continuous monitoring?

Yes. Once assets are discovered and validated, Flashpoint EASM continuously monitors the external attack surface for newly identified assets, vulnerable software, exposed services, and relevant vulnerability findings.

Teams can receive alerts when new exposure risks are identified.

How does Flashpoint EASM reduce alert fatigue?

Traditional vulnerability programs generate large volumes of findings without clarity on whether those assets are actually owned or exposed. Flashpoint EASM’s triage inbox lets teams accept true assets and reject noise, ensuring alerts are scoped only to infrastructure the organization actually owns.

Who should use Flashpoint EASM?

Flashpoint EASM is designed for security teams responsible for:

  • Vulnerability management
  • Attack surface management
  • Exposure management
  • Threat intelligence
  • Security operations
  • Risk management

It is particularly valuable for organizations seeking to connect vulnerability intelligence to real-world asset exposure and remediation priorities.

How does Flashpoint EASM work with Flashpoint Vulnerability Intelligence?

Flashpoint EASM extends the value of Flashpoint Vulnerability Intelligence by helping organizations understand where vulnerable assets exist within their external environment.

Rather than viewing vulnerability intelligence and attack surface visibility separately, organizations can use both capabilities together to identify exposure, prioritize remediation, and reduce risk more effectively.

Request a demo today.

The post Connecting Vulnerability Intelligence to Real-World Exposure With Flashpoint EASM appeared first on Flashpoint.

  •  

How AI and Evasion Demand a Radical Shift in Network Threat Prevention

The Future of Threat Defense Resides at the IP Layer

For years, network security operated on a relatively predictable premise: inspect traffic, identify malicious content, and block it. Because deep content inspection created a seemingly robust defense in depth, relatively static legacy approaches—like reliance on threat intelligence feeds—were allowed to simply persist in the background.

The weaponization of agentic AI and highly evasive techniques has fundamentally shattered that model. Attackers are no longer just iterating on old threats. They are launching attacks at staggering velocity, completely outpacing threat feeds, and employing evasion tactics that actively starve legacy prevention solutions of the content they rely on to inspect.

Our new research report from Unit 42, Attackers Are Evading Threat Prevention at the Internet Edge, reveals how adversaries are actively exploiting the contextual vacuum at the IP layer to bypass standard security controls. For security leaders, understanding this shift is no longer optional. As the nature of the threat fundamentally changes, our strategic approach to network security must definitively change with it.

The AI-Accelerated, Evasive Attack Lifecycle

To understand why legacy defenses are failing, we must look at how adversaries are accelerating and obfuscating every stage of the attack lifecycle. As these threats progress, the commonly used network indicators we have long relied upon are vanishing, collapsing traditional defenses and leaving defenders with little to act on.

Powered by frontier AI, adversaries now automate reconnaissance and exploitation at huge scale and speed, while using anonymizers to mask their intent. Once an intrusion is launched, orchestration shifts to highly evasive command and control (C2). Attackers hide communications using advanced encryption and AI-built malware-less techniques. They’re also bypassing traditional web and DNS inspection entirely by routing traffic directly to IP addresses—a tactic Unit 42 found in 23% of modern malware

Ultimately, the takeaway is clear: network threat prevention can no longer rely solely on detecting malicious payloads. As AI-driven attacks continue to minimize their footprint, security strategies must augment content inspection with real-time IP layer monitoring to left-shift threat detection and counter these rapid, machine-speed threats at the network foundation.

Existing Approaches Aren’t Working

Where content-based detection falls short, many security vendors and organizations still rely on IP threat intelligence feeds to pick up the slack in an attempt to filter out malicious connections on the network layer. However, after years of operating under this model, the results are in—the traditional feed is showing its age.

Attackers have long relied on proxies, anonymizers, residential routers and public cloud providers as a tactic to evade detection. However, agentic AI morphs this process, enabling rapid infrastructure rotation and stealth at an unprecedented scale. As this autonomous evasion accelerates, experienced network defenders continue to run into the well-known limitations of classic IP blocklists:

  • Too slow to keep pace: Unit 42 found an average 20-day lag time before new threats hit popular feeds. Because agentic AI enables adversaries to autonomously rotate proxy IPs in hours, these lists are obsolete at the moment of delivery.
  • Fundamentally incomplete: IP feeds are unable to see a massive portion of the modern attack surface. Unit 42 research indicates that 52% of malicious IPs used for direct-to-IP connections are completely absent from these lists.
  • Unactionable on shared infrastructure: Even known threats are often impossible to block. The Unit 42 team reports that 37% of direct-to-IP traffic uses reputable CDNs and cloud providers. IP feeds cannot distinguish malicious connections from legitimate ones, making blocking too risky for business continuity.
  • A management nightmare: Among the security teams that Unit 42 polled, 30% indicate resource-intensive vetting and false-positive triage as their top pain point. To avoid breaking legitimate traffic, feeds are frequently relegated to an alert-only mode, defeating the entire purpose of prevention.

If modern and agentic AI-enabled attacks can outrun traditional network payload-based detections, we need a new weapon in the network defender’s arsenal. We can no longer depend on yesterday’s IP feeds to secure such an extremely agile threat environment.

The Blueprint for Modernizing the Internet Edge

To outpace the impact of agentic AI and advanced evasion on network threat prevention, security leaders must redefine their defense strategy and shift-left to track the attacker infrastructure itself—monitoring the exact IP layer locations where adversaries build and control their campaigns. Deep content inspection remains essential, but securing the modern edge requires establishing the context and intent of a connection before a session is established.

To achieve this goal, organizations must move beyond the limitations of static defense and adopt a modern security blueprint:

  • Proactive protection against attacker infrastructure: While high-quality threat feeds remain essential for SOC investigations and incident response, relying on them for frontline, real-time prevention creates major blind spots. Instead, security teams must use real-world, global telemetry to proactively identify and block connections to attacker-controlled hosts before requesting a URL or file.
  • Zero trust principles applied to the network layer: An IP address without a negative reputation does not equal a safe connection. Continuous verification requires extending zero trust down to the network foundation. It validates the real-time behavior and intent of every single session to ensure attackers cannot hide in the contextual vacuum of the IP layer.  
  • Reducing the attack surface with rich contextual attributes: Traditional IP blocking is like a blunt instrument that creates unacceptable false positives and alert fatigue. To modernize the edge, security teams need deep, attribute-based visibility across the entire Internet address space to reduce noise and replace legacy IP feeds entirely.  

By moving away from point-in-time assumptions and embracing real-time, inline protection, security leaders can reclaim the advantage at the network foundation.

To see how these evasion tactics operate in the wild, read the latest Unit 42 report, Attackers Are Evading Threat Prevention at the Internet Edge. You’ll find this report valuable in understanding the systemic gaps in legacy risk models and learning why continuous verification must be our new mandate.

The post How AI and Evasion Demand a Radical Shift in Network Threat Prevention appeared first on Palo Alto Networks Blog.

  •  

Understanding Illicit Ecosystems: XSS and the Current State of the Russian-Speaking Underground

Blogs

Blog

Understanding Illicit Ecosystems: XSS and the Current State of the Russian-Speaking Underground

In this post, we explore XSS’ shift from a unified forum to a scattered community spread across several competing factions.

SHARE THIS:

What is XSS?

For more than two decades, XSS was the gathering ground for the Russian-speaking cybercriminal underground. Evolving from its former name, DaMaGeLaB, XSS evolved from a mid-tier message board into a top-tier hacking forum.

XSS is home to vendors of various crime types, including loaders, phishing, scamming, carding, malware development, distributed denial-of-service (DDoS) bots, and related services. It also facilitates the trade of illicit goods and services, while simultaneously serving as a networking and recruitment hub for threat actors.

XSS forum content falls within the following main sections:

  • “Underground”: Includes most noncommercial content, such as sharing information on malware, vulnerabilities, and exploits, phishing, fraud, open source intelligence, artificial intelligence, and machine learning.
  • “Programming, Development”: Includes posts and articles about programming languages and administration.
  • “Library”: Includes news articles, databases, and discussions around software and tools. Users also post about vulnerabilities and exploits.
  • “Business Decisions”: Users discuss different investments, the sale of digital goods, trading, start-ups of fraudulent businesses, and news about cryptocurrencies.
  • “Lounge Zone, Resting”: Content involves lifestyle discussions, hobbies, and cybercriminal community rumors and scandals.
  • “Trading Platform”: Users sell and look to buy network access, malware, counterfeit documents, and advertise their services. This is where users hire and look for work or partners.
  • “People’s Court”: Used for complaints and arbitration and contains lists of phishing forums and scammers.
  • “Ours”: Contains information about the XSS project, discussions on issues, suggestions, and initiatives for forum improvement.
  • “Private: Underground”: Closed section for only forum members.
XSS forum main sections (Source: XSS)

XSS Disruption: July 2025 Takedown

On July 23, 2025, law enforcement organizations reportedly seized XSS as part of a multinational operation with Ukrainian authorities, French police, and Europol. Alongside the domain seizure, French authorities reported the arrest of XSS’s longtime administrator in Ukraine.

This arrest triggered an immediate chain reaction that has had lasting effects on the Russian-speaking underground—with the XSS ecosystem splintering into several competing factions.

The Current State of the Russian-Speaking Underground

While the original XSS architecture was severely disrupted, the surrounding Russian-speaking cybercriminal ecosystem remains intensely active. However, instead of a centralized hub, the XSS ecosystem is spread out through competing environments that emerged directly from the fallout of the takedown.

DamageLib

Launched by the legacy moderators of XSS, DamageLib represents a structural pivot away from standard illicit forums. Concluding that the old XSS site was compromised by law enforcement, the moderators launched a new model that completely abandons commerce—shutting down all buying, selling, and auctions entirely—-to eliminate user tracking and surveillance. Instead, it focuses strictly on technical materials and tutorials.

Rehub

Recognizing that displaced cybercriminals still required a commercial venue to trade, a former XSS moderator launched Rehub quickly after the emergence of DamageLib. Rehub immediately integrated a commercial platform, successfully recruiting prominent threat actors into its moderation team to establish underground credibility.

The forum is still in its development stage, with its content being populated, and an active member base being built.

XSS[.pro]

In early August 2025, an unknown entity launched an alleged resurrection of the forum on a new domain [.pro], utilizing old backups that preserved legacy user data, threads, and forum deposits. However, this new version has been met with significant distrust from Exploit and DamageLib, believing the [.pro] domain to be a honeypot controlled by law enforcement.

XSSF Forum

Started by a pro-Russian Telegram hacking group, this community actively targets EU and Ukrainian digital infrastructure. According to user discussions on DamageLib, this forum is not related to XSS. In addition, Flashpoint analysts note that targeting Ukrainian infrastructure directly contradicts its original community rules. The authenticity of this forum and its ownership has not been verified.

Monitor a Fractured Underground Using Flashpoint

While law enforcement achieved a significant victory over XSS, they did not eliminate the Russian-speaking cybercriminal underground. Instead, they broke the foundational trust mechanics that had kept it centralized for twenty years.

This has left the Russian-speaking underground in a deeply fractured state that is still intensely active and highly adaptive. For defenders and analysts, this threat has not diminished—it has diversified. Tracking this ecosystem no longer means watching a single centralized community, but rather actively mapping out the live migrations, shifting rules, and behavioral patterns across these splintered groups.

Request a demo to learn how Flashpoint helps security teams aggregate intelligence from these scattered factions into a single source of truth, empowering your organization to proactively monitor and intercept emerging threats.

Request a demo today.

The post Understanding Illicit Ecosystems: XSS and the Current State of the Russian-Speaking Underground appeared first on Flashpoint.

  •  

The AI Defense Plane: Securing the New Enterprise Execution Layer

AI Defense Plane

Enterprise security has always had a comforting assumption baked into it: systems do what they were built to do. Sometimes badly. Sometimes insecurely. Sometimes in ways that make auditors develop a nervous twitch. But still, the basic shape was understandable. Applications processed requests. Databases stored data. APIs connected systems. Users clicked things they probably should not have clicked. Then AI arrived and made the whole thing a little weird. AI did not introduce one neat new risk category. Security teams are very good at turning new risk categories into taxonomies, dashboards, and meetings with names like “working group.” The real […]

The post The AI Defense Plane: Securing the New Enterprise Execution Layer appeared first on Check Point Blog.

  •  

What’s in the container? Analyzing vulnerabilities, risks and protection with Kaspersky Container Security and the KIRA AI assistant

Introduction

Containerization using Docker has become firmly established in modern development standards, significantly increasing the speed and convenience of deploying various services. Developers often use ready-made Docker images, making only minimal changes. The largest repository of container images is the Docker Hub service.

Container-hosted infrastructure is an attractive target for attackers. At a minimum, a compromised container can be used for DDoS attacks, cryptocurrency mining, or traffic proxying. The list of threats does not end there: once an attacker gains control of a container, they can steal or destroy data directly from it, access neighboring containers, or even attempt to escape the container, compromising the entire enterprise network.

At the same time, the infrastructure inside containers is typically updated less frequently and may contain outdated and vulnerable software versions. When deploying third-party images or modifying them for a specific environment, it is easy to make configuration errors that attackers can later exploit. And due to the architectural characteristics of containers, developers often face constraints when preparing images; to overcome these, they may resort to insecure solutions they find online.

In other words, containerized infrastructure can be both the simplest and the most lucrative target to exploit. Therefore, its security requires heightened attention. To minimize the risk of successful attacks on container infrastructure, it is essential to check the final Docker images, including all underlying layers, for vulnerabilities and misconfigurations. The easiest way to do this is by analyzing the Dockerfile; however, it is not always available for inspection. Moreover, it typically defines how to build layers on top of a base image from an external repository whose reliability cannot be guaranteed.

Image analysis results in Kaspersky Container Security

Image analysis results in Kaspersky Container Security

To help users identify insecure configurations and potential vulnerabilities within them, we have added our AI assistant to Kaspersky Container Security.KIRA (the assistant’s name) uses artificial intelligence to analyze the image and identify potential issues within, along with recommendations on how to fix them.

As part of this study, we asked KIRA to analyze a number of popular community images, and later in this article, we’ll show you the results.

Software vulnerabilities and compromise of update sources

One of the key security issues with using pre-built images is that developers do not update them in a timely manner. A Docker image is, by its very nature, a snapshot of a specific Linux distribution after packages have been installed on it. However, in most cases, it does not receive security updates on its own, unlike traditional Linux servers, where these updates are automatically installed by specialized services, such as unattended-upgrades in Debian-based distributions and dnf-automatic in RedHat-based distributions.

To apply updates to a Docker image, it must be rebuilt and redeployed. Often, this process is not automated, and some updates require additional effort to verify their correct operation, modify configurations when upgrading to new software versions, and so on. As a result, many popular images do not receive timely updates, which significantly increases the risks associated with their use.

An image that was secure at build time accumulates vulnerabilities as they are discovered in the packages installed within it, which over time significantly increases the opportunities for a successful attack on the container.

Vulnerable versions of web applications and network services accessible from the internet immediately become targets of various malicious campaigns. For example, just one day after the discovery of the CVE-2025-55182 vulnerability in React Server Components, our honeypots recorded numerous attack attempts related to this vulnerability. It was adopted by operators of many malicious campaigns, ranging from classic cryptocurrency miners to variants of Mirai and Gafgyt. Attackers are constantly adding new distribution methods and can use dozens of exploits targeting various vulnerabilities and configuration errors in popular services. Often, the same vulnerabilities are used in self-propagation mechanisms from already compromised hosts. For example, in a malicious campaign to spread the Dero miner, attackers use infected containers to automatically search for and infect new targets.

In addition to vulnerabilities that can be exploited remotely, attackers are rapidly adding local vulnerabilities to their arsenal, used to gain root privileges and escape the container: in the Kinsing malware campaign, attackers used CVE-2023-4911 (Looney Tunables) to elevate privileges, and in the perfctl campaign, the CVE-2021-4034 (PwnKit) vulnerability was used for the same purpose. The access gained was used to install a rootkit that hides the presence of perfctl on the system.

To assess the situation with unpatched vulnerabilities in containers, we took a random sample of 100 images, which included various popular solutions with 10,000 to 1 million downloads on DockerHub. In the 64 images we scanned, we found outdated software versions with critical vulnerabilities. For example, some images contained the CVE-2025-49844 vulnerability in the Redis server, leading to RCE by leveraging a vulnerability in the Lua parser; the current CVE-2026-24061 vulnerability in nginx, which in some configurations leads to a server process crash, and with ASLR disabled, again, to RCE; vulnerabilities CVE-2025-32463 in sudo and CVE-2023-4911 in glibc, allowing an attacker to gain root privileges with local access. At the same time, only one in ten Docker images from the analyzed sample is fully up to date.

TOP 10 Critical Vulnerabilities with PoC/Exploits available as shown in the Kaspersky Container Security Dashboard

TOP 10 Critical Vulnerabilities with PoC/Exploits available as shown in the Kaspersky Container Security Dashboard

It is worth noting that, of course, not every discovered vulnerability can be directly exploited by attackers. A practical risk arises when the vulnerable application or library is actually in use, and the conditions necessary for exploitation – which vary significantly from vulnerability to vulnerability – are met. Nevertheless, updates must not be ignored, as the risk of vulnerabilities being exploited – both individually and in various combinations – cannot be predicted in each specific case, and even vulnerabilities that seem harmless at first glance can ultimately pose a serious risk of compromise.

A record number of vulnerabilities in a single image

A record number of vulnerabilities in a single image

However, frequent updates have a downside. Every rebuild that downloads new packages from source repositories introduces an additional risk of a supply chain attack – a compromised dependency or a modified base image could silently inject malicious code into your environment precisely through an update. During our analysis of images from the sample, we did not find any signs of supply chain attacks. However, in March 2026, a supply chain incident occurred in the Trivy and LiteLLM projects. In the case of Trivy, the infected file was injected directly into the container image in the official repositories.

Detecting potentially malicious software using one of the images as an example

Detecting potentially malicious software using one of the images as an example

This leads to a difficult choice: infrequent updates leave known vulnerabilities unpatched within the image, while frequent updates increase the risk of supply chain compromise. Therefore, to protect your infrastructure, you need not only to regularly update base images but also to take a more comprehensive approach, specifically by pinning dependencies to known-good versions and scanning the resulting images for malware upon update.

Configuration vulnerabilities

Even a container with a fully updated image can be compromised if it is configured incorrectly. Embedding keys and secrets in the image, disabling authentication in network services, default passwords, and insecure file access permissions – all of these can be exploited by attackers in one way or another to achieve their goals.

Insecure image configurations detected by KCS based on rules

Insecure image configurations detected by KCS based on rules

The situation is exacerbated by the fact that errors may be introduced by the authors of the original image, which complicates their detection, as this requires analyzing every layer and the command that generated it. As with vulnerabilities, not every configuration error leads to compromise: it all depends on the container’s role, its network accessibility, and many other factors. But the very use of insecure settings will sooner or later lead to errors appearing in images where their consequences will be significantly more dangerous.

Standard rules are often insufficient for analyzing problematic configurations. To gain a deeper understanding of the context and assess potential risks, AI tools can be used. Later in this section, we will examine examples of typical insecure configurations we discovered while scanning public images from Docker Hub, along with the descriptions of issues and risk mitigation methods provided by the KIRA AI assistant.

Example of container analysis using KIRA

Example of container analysis using KIRA

Insecure handling of credentials

Use of default passwords

In some cases, containers may use default passwords set via environment variables or directly in Dockerfile. If these passwords are not overridden, attackers will be able to access the application by using the default password.

RUN |1 DEBIAN_FRONTEND=noninteractive /bin/sh -c echo [removed]:[removed] | chpasswd

According to KIRA’s analysis, the user’s password is stored in plain text in the image layer history. Anyone who gains access to the image – whether through a public registry, a compromised build environment, or other means – will be able to extract the password. If SSH or another form of interactive access is enabled in the container, this could lead to its complete compromise and allow attackers to move laterally within the infrastructure.

Passwords may be present in environment variables. Consider the following Dockerfile snippet:

ENV SERVERNAME=localhost WWW_PATH_CONF=/etc/apache2/apache2.conf WWW_PATH_ROOT=/var/www HTTPS=on PKP_CLI_INSTALL=0 PKP_DB_HOST=db PKP_DB_NAME=pkp PKP_DB_USER=pkp PKP_DB_PASSWORD=changeMePlease PKP_WEB_CONF=/etc/apache2/conf-enabled/pkp.conf PKP_CONF=config.inc.php PKP_CMD=/usr/local/bin/pkp-start

In this example, the environment variable PKP_DB_PASSWORD is set to changeMePlease. If the user forgets to override it, the application will use the password that can be obtained from Dockerfile.

Let’s look at another image:

/bin/sh -c #(nop)  ENV MOODLE_URL=<a href="http://0.0.0.0/">http://0.0.0.0</a> MOODLE_ADMIN admin       MOODLE_ADMIN_PASSWORD [removed]      MOODLE_ADMIN_EMAIL admin@example.com MOODLE_DB_HOST     MOODLE_DB_PASSWORD       MOODLE_DB_USER     MOODLE_DB_NAME    MOODLE_DB_PORT 3306

For this image, Dockerfile specifies that the administrator password is hardcoded in the ENV directive and remains in the image metadata (layer history, docker inspect). Anyone who gains access to the image (registry, build cache) will be able to extract this secret and compromise the account.

To eliminate these risks, ensure that no passwords are specified in Dockerfile. If authentication is required, you can use orchestrator mechanisms (secrets) or generate a temporary password when starting the container via the entrypoint script, without saving it in the layers. We also recommend using mechanisms for securely passing secrets at runtime (Docker secrets, Kubernetes Secrets) or, as a last resort, passing them via --secret during the build with BuildKit, but under no circumstances should they be left in the final image.

Passing passwords via command arguments

In some cases, passwords may be exposed when passed via command-line arguments, as these arguments are visible to all users on the system:

/bin/sh -c #(nop)  HEALTHCHECK &amp;{[""CMD-SHELL"" ""mysql --protocol TCP -u\""root\"" -p\""$MYSQL_ROOT_PASSWORD\"" -e \""SELECT 1;\""""] ""15s"" ""30s"" ""0s"" '\x05'}

In the example provided, the MySQL superuser password is passed into the healthcheck command in plaintext, making it visible when viewing the process list (ps aux), in audit logs, and in monitoring systems. If the attacker gains read access to the container’s processes or logs, they can extract the password and gain full control of the database.

To fix this issue, the healthcheck should use a local connection via a Unix socket with default authentication (if the auth_socket plugin is configured for root), or create a dedicated user with minimal privileges (e.g., only USAGE), without a password or with a password passed via a secure file (--defaults-file with restricted permissions). You can also use the MYSQL_PWD environment variable for healthcheck authentication, but it remains visible in /proc.

Privilege escalation in the container

One of the most common vectors for initial compromise of Linux systems is RCE in web applications and network services. Typically, these services have minimal privileges, which complicates attackers’ subsequent actions: dumping credentials, covering their tracks, attempting to escape the container, and much more.

The situation worsens significantly if the attacker gains root privileges, as this allows them to fully control all processes within the container, conceal their activity, and use methods to escape the container. For example, they can compromise the host if the container is privileged, a Docker socket is mounted inside it, or other insecure configurations and vulnerabilities exist that cannot be exploited with standard user privileges.

Similarly, this simplifies network attacks on neighboring containers, the orchestrator, and various internal services, making this configuration error a potential link in the chain for compromising the entire network.

Attacks on sudo

One of the simplest privilege escalation methods is executing arbitrary commands as root using sudo without entering a password. Consider the following example:

/bin/sh -c set -xe;     apt-get update &amp;&amp;       apt-get -y install sudo;       echo ""solr ALL=(ALL) NOPASSWD: ALL"" &gt;/etc/sudoers.d/solr;

Analyzing this configuration using KIRA immediately highlights the main issue: by installing the sudo package and setting NOPASSWD: ALL for the solr, the user severely violates the principle of least privilege. The Solr platform does not require such broad privileges to run within a container; instead, they create an easy path for escalating to root.

echo 'postgres ALL=(ALL:ALL) NOPASSWD:ALL' &gt;&gt; /etc/sudoers

In another example of an insecure configuration, NOPASSWD:ALL privileges are granted to a PostgreSQL database user, which is a direct and severe weakening of the access control policy. If an attacker gains the ability to execute code on behalf of the postgres user – through a vulnerability in a network service, an SQL injection, or by compromising of one of the processes – they will immediately and unconditionally be able to execute any commands on behalf of the root user. This is equivalent to the entire container running as root.

As a risk mitigation measure, we recommend completely removing this directive. The minimum necessary commands requiring privileges should be delegated on a case-by-case basis via sudoers with explicit specification of allowed executables and parameters, using NOPASSWD only as a last resort and for specific utilities.

Our AI assistant KIRA can identify even more complex insecure configurations, such as allowing passwordless sudo for the entire sudo group — by modifying existing rules.

perl -i -pe 's/\bALL$/NOPASSWD:ALL/g' /etc/sudoers

The risk in this example is that the command replaces standard declarations requiring authentication with passwordless execution of all commands for any user within the sudo group – potentially including postgres, should it be assigned to that group. This expands the attack surface to all group members, turning each of them into a potential point for instant privilege escalation.

To mitigate the risks, we recommend not modifying the global sudoers policy, keeping the standard password requirement, or using a more secure escalation mechanism – such as gosu to run a specific process on behalf of another user without permanent privileges.

Insecure file permissions

Another common vector for privilege escalation is insecurely configured file and directory permissions. Most often, for convenience, container image authors use 777 permissions, which allow anyone – including unprivileged users – to freely create and delete files, as well as modify their contents. This can lead to both privilege escalation and the ability for an unprivileged attacker to delete or modify logs, among other undesirable consequences.

Consider the following command:

chmod 0777 /usr/share/cargo /usr/share/cargo/bin

The risk is that directories containing binary files and scripts will become writable by any container user. This allows a low-privileged attacker to replace utilities included in cargo or add new malicious executables. When these tools are subsequently invoked, especially as the root user or via sudo, the attacker’s code will execute with the inherited privileges of the calling process, leading directly to a local privilege escalation.

To mitigate the risks, you can set the minimum necessary permissions: chmod 0755 for directories and chmod 0755/0644 for the corresponding files. The owner should be root, and only the owner should be allowed to write. Do not use chmod 777 on any system paths.

Lack of integrity checks

Downloading software without verifying its integrity can make the infrastructure vulnerable to software tampering.

For example, this risk may arise when downloading a distribution via HTTP:

RUN /bin/sh -c wget -qO- ""<a href="http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz">http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz</a>"" | tar --extract --gzip -C /opt/acestream

Using HTTP without verifying the archive’s integrity creates conditions for a man-in-the-middle attack during the image build phase. An attacker controlling the communication channel or DNS can replace the archive with malicious content, which will compromise the container and the entire environment in which it runs.

To mitigate the risks, you can configure connections to web resources to use HTTPS only — if the resource supports this protocol. You can also download the archive without extracting it, compare its checksum (SHA256) with the checksum from a trusted source, and only then extract it. It is advisable to store the verified archive in an internal artifact repository to avoid direct downloads from the network.

There will still be a MitM risk even if certificate verification is disabled:

wget --no-check-certificate<a href="https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip"> https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip</a> -O phpvirtualbox.zip

The absence of TLS certificate verification allows an attacker controlling the network segment to replace the downloaded ZIP archive with malicious content. Since the archive contains PHP code that will be executed by the web server, compromise during the build phase will result in the deployment of a backdoor or data leakage.

To mitigate the risks, remove the --no-check-certificate flag; after downloading, calculate the SHA256 hash of the archive and verify it against a known reference value (the release page or a local repository of trusted hashes). Additionally, consider using a fixed release (tag) rather than the floating 7.2-dev branch.

Conclusion

Docker containers have become a very popular means of deploying software, and attackers are by no means oblivious to this trend. They are rapidly adding software vulnerabilities and configuration errors to their arsenal and carrying out attacks on supply chains. They can compromise container infrastructure for a wide variety of purposes, from cryptocurrency mining to encrypting data for ransom or stealing information critical to the company.

Our research found that 64 out of 100 container images for popular applications contain critically vulnerable software, and only 10% are fully up to date. We also identified numerous insecure configurations, including passwords stored in plaintext in Dockerfiles and excessive privileges granted to users and processes.

To detect and prevent these threats, it is essential to strictly adhere to security measures: audit image configurations, securely manage secrets used in images, apply security updates in a timely manner, scan their contents for malware with every update, and follow industry-standard best practices for enhancing security.

This approach requires specialized solutions built to accommodate the unique characteristics of container environments. Kaspersky Container Security ensures the security of containerized applications at every stage of their lifecycle, from development to operation. The product protects an organization’s business processes, helps ensure compliance with industry standards and security regulations, and enables the implementation of secure software development practices.

  •  

The Mini Shai-Hulud Worm and the New Era of CI/CD Exploitation

Blogs

Blog

The Mini Shai-Hulud Worm and the New Era of CI/CD Exploitation

In this post we break down the technical mechanics of TeamPCP’s recent campaign, the impact on the developer ecosystem, and the urgent steps needed to secure software supply chains.

SHARE THIS:
Default Author Image
May 28, 2026

The developer ecosystem recently faced one of its most significant architectural threats to date, with the threat actor group TeamPCP unleashing Mini Shai-Hulud—a self propagating worm and multi-ecosystem threat. Potentially affecting millions of developers and thousands of companies, Mini Shai-Hulud has fundamentally compromised the trust layer of modern CI/CD pipelines.

The operational tempo of Mini Shai-Hulud has accelerated with every campaign. What began as opportunistic credential theft has now evolved into a high-speed, automated operation that can compromise hundreds of packages in under thirty minutes. From the exfiltration of approximately 3,800 internal GitHub repositories to the poisoning of critical libraries like TanStack and AntV, TeamPCP’s campaign has been incredibly effective in exploiting developer tooling and identity infrastructure.

What is Mini Shai-Hulud?

Mini Shai-Hulud is deployed as a 498 KB obfuscated script executed using the Bun JavaScript runtime. The deliberate choice of Bun, rather than Node.js, is a tactical evasion technique as most endpoint detection and response (EDR) platforms and security information and event management (SIEM) solutions have behavioral rules tuned to Node.js execution patterns.

How Mini Shai-Hulud Works

The worm propagates by stealing npm and GitHub authentication (OIDC) tokens from developer environments, then using those credentials to publish malicious versions of packages the compromised user maintains. To accomplish this, the worm scrapes runner process memory to extract short-lived identity tokens, which it then exchanges for per-package npm trusted-publisher tokens without requiring any long-lived npm secrets.

Credential Exfiltration and Command-and-Control

Mini Shai-Hulud targets credentials across 130 file paths, including npm tokens, GitHub personal access tokens, AWS, GCP, and Azure configuration files, Kubernetes kubeconfig files, Docker credentials, HashiCorp Vault tokens, 1Password and Bitwarden CLI vaults, SSH private keys, and Bitcoin wallet files. 

Exfiltration occurs across multiple channels: the Session Protocol network, the GitHub Git Data API using dynamically created Dune-themed repositories on victim accounts, HTTPS to the threat actor-controlled domain, and an api for GitHub Actions workflow exfiltration.

The worm uses a dead-drop command-and-control (C2) architecture via GitHub’s public commit search API. An installed daemon (kitty-monitor, deployed as a systemd service on Linux or a LaunchAgent on macOS) polls GitHub for commits containing the string “firedalazer,” parses RSA-PSS-signed command payloads from matching commits, and executes them. This technique leverages GitHub as a trusted relay, making C2 traffic difficult to block without disrupting legitimate GitHub usage.

The worm then uses a persistence mechanism as a dead-man’s switch: a GitHub personal access token named “IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner” is created on compromised developer machines. If an operator revokes this token without first disabling the persistence mechanism, the worm destroys all home directory data on the compromised device.

AI Agent Hijacking

Beyond standard persistence mechanisms, Mini Shai-Hulud targets AI coding agents. The SafeDep analysis documents that the worm modifies Claude Code’s settings .json to insert a SessionStart hook, enabling the worm to be reinstated with full LLM API privileges even if the infected npm packages are later removed, or the npm cache is cleared. A similar technique targets Visual Studio Code’s tasks.json file using the “runOn”: “folderOpen” trigger, and Codex configuration files are also targeted.

These AI agent hijacking techniques represent a novel attack surface: by persisting within trusted AI tool configurations, the malware can exfiltrate all code and secrets processed by those tools during future development sessions.

Four Waves of Supply Chain Attacks

Flashpoint has observed at least four documented waves of TeamPCP npm and PyPI supply chain attacks in 2026, leveraging Mini Shai-Hulud to compromise developer tooling ecosystems and steal credentials, cloud keys, and source code across tens of thousands of organizations. 

The following timeline tracks the escalation of TeamPCP and the Mini Shai-Hulud waves throughout 2026:

Wave 1: Initial SAP Packages (April 2026)

The first documented wave of Mini Shai-Hulud attacks targeted a small number of SAP-ecosystem npm packages in April 2026. While TeamPCP had already proven their CI/CD attack capabilities in March 2026 by compromising Aqua Security’s Trivy scanner and Checkmarx KICS via GitHub Actions, this initial wave served primarily as a proof-of-concept for the self-propagation mechanism and a reconnaissance phase for TeamPCP’s access broker network. Further, these attacks demonstrated the group’s ability to compromise widely used security tooling—a development that significantly undermines defenders’ ability to trust automated CI/CD pipeline scanning results.

Wave 2: TanStack, Mistral AI, and Guardrails AI (May 2026)

Leveraging a GitHub Actions cache-poisoning technique, TeamPCP published malicious versions of 42 TanStack packages across 84 releases, impacting a project with over 518 million cumulative downloads. 

The attack also compromised Mistral AI and Guardrails AI, extending the attack surface to the AI developer tools ecosystem. Forged commit authorship was used to blend the attacker’s commits into AI-assisted development environments where Claude Code is commonly deployed.

TeamPCP simultaneously listed Mistral AI source code for sale on BreachForums, claiming possession of approximately 5 GB of data across 450 internal Mistral repositories.

TeamPCP BreachForums posts advertising Mistral AI internal source code and repositories for sale, May 2026. (Source: Flashpoint)

Wave 3: AntV Ecosystem (May 2026)

Targeting AntV enterprise data visualization ecosystem, TeamPCP compromised the atool npm account, which held publishing rights across a broad catalog of AntV packages. In 22 minutes, 637 malicious versions were published across 323 packages—a scale and speed that overwhelmed standard security monitoring pipelines.

Each infected package contained the Mini Shai-Hulud worm, which, upon execution, created up to 2,500 compromised repositories on victim accounts within hours.

Wave 4: Co-Ownership of BreachForums and GitHub Breach

In the most recent wave, TeamPCP announced its assumption of co-ownership of BreachForums, the largest English-language cybercriminal forum currently active. This development significantly elevates TeamPCP’s standing and operational reach. As co-owners, the group stated it would manage platform operations, handle dispute resolution, staff and vet moderation personnel, and host monetary contests for the community. The announcement positions TeamPCP as both an active threat actor and a platform-level infrastructure operator, with the ability to shape forum policies, curate the availability of criminal tooling, and influence the broader access broker and ransomware ecosystem.

Additionally, by poisoning a GitHub employee’s development environment, TeamPCP exfiltrated approximately 3,800 internal GitHub repositories. Within the stolen data were highly sensitive codebases such as:

  • copilot-api and copilot-token-service
  • actions-runtime
  • billing-platform
  • enterprise-crypto
  • authentication
  • codeql-core
  • detection-engineering
  • csirt
  • azure-config
TeamPCP BreachForums posts advertising GitHub internal source code for sale. (Source: Flashpoint)

Recommended Immediate Actions

Critically, the theft of internal source code from one of the world’s most widely used code hosting platforms creates incredible downstream risk for organizations that depend on GitHub Copilot and GitHub Actions for their own software development pipelines. Organizations running AI coding agents such as Claude Code and VS Code with extensions in their CI/CD pipelines face heightened exposure. Security teams should treat AI agent configuration files as sensitive assets subject to integrity monitoring and change-control policies.

If your organization uses npm, PyPi, or AI-assisted development tools, Flashpoint recommends the following immediate steps:

  1. Audit and remove: Immediately audit CI/CD environments and remove all infected versions of AntV, TanStack, Mistral AI, and Bitwarden CLI packages.
  2. Rotate credentials: Rotate all cloud credentials (AWS, GCP, Azure) and npm tokens.
  3. Disable persistence first: Before revoking suspicious GitHub tokens, ensure the kitty-monitor daemon is disabled to avoid triggering the “dead-man’s switch” wiper.
  4. Lock down IDEs: Restrict the installation of VS Code extensions to an approved allow-list and monitor for unauthorized changes to settings.json or tasks.json.
  5. Block C2 infrastructure: Block all traffic to identified TeamPCP C2 domains.

Track TeamPCP and Defend against Mini Shai-Hulud Using Flashpoint

Flashpoint assesses with high confidence that TeamPCP will continue to scale its supply-chain attacks against npm, PyPI, and developer tooling ecosystems. The group’s shift from direct execution to orchestrating a broader ecosystem via BreachForums signals a maturation into a platform-layer criminal operation. While TeamPCP has hinted that the group may be approaching “retirement” due to law enforcement pressure, this should be treated with caution. Whether a misdirection or a genuine exit plan, the open-sourcing of Shai-Hulud means the tradecraft is available to the wider cybercriminal community.

Organizations should reference the OpenSSF npm Best Practices guidance for a practical baseline in hardening their package consumption posture. Flashpoint customers can gain access to known Indicators of Compromise (IOCs) and MITRE ATT&CK Mapping for Mini Shai-Hulud by logging into Flashpoint Ignite. To learn more about how Flashpoint tracks threat actor groups like TeamPCP and protects the software supply chain, request a demo.

Request a demo today.

The post The Mini Shai-Hulud Worm and the New Era of CI/CD Exploitation appeared first on Flashpoint.

  •  
❌