Unit 42 explores The Gentlemen ransomware operations, revealing the affiliate model driving its rapid growth. Learn more here.
The post No Manners Here: The Ruthless Rise of The Gentlemen Ransomware appeared first on Unit 42.
The conversation around AI-powered threats has focused heavily on the attacker side. What models can do, what vulnerabilities they can find, how fast they can chain exploits together. But the more important question for security practitioners is simpler and harder. Is your detection posture ready for what’s already happening?
AI has lowered the barrier to entry for sophisticated attacks. Threat actors don’t need to be experts to leverage LLMs for obfuscation, exploit development, or chaining attack steps that previously required deep manual skill. The speed and volume of attacks is increasing as a result. Detection engineering is part of how defenders respond. And most organizations are further behind than they realize, especially because many detection engineering programs live in their own siloed “ivory tower”, detached from the realities of what SOC analysts are handling.
At Intezer, AI-powered detection engineering runs as part of a closed loop with automated, forensic triage and investigation. Every alert investigated across the environment feeds new signal back into detection logic, so coverage improves continuously instead of drifting between quarterly tuning cycles. Detection working in concert with triage and investigation is what a fully optimized security environment looks like against AI-powered attackers.
In this article, we’ll focus on how to improve detection engineering practices in general.
The fundamental problem is that most detection programs were built for a world where attack volume was bounded by attacker expertise. That constraint is being removed. LLM-augmented attacks can move faster, produce more permutations, and adapt more readily to your environment than traditional campaigns. A detection posture built on static indicators and periodic tuning cycles can’t keep up.
There are three places this shows up in practice.
First, most organizations are only covering technique-level MITRE ATT&CK mappings, not sub-techniques. When you claim T1059 is covered because you have a rule for T1059.001, you’re exposing yourself to real risk hiding beneath that coverage number. Sub-techniques carry distinct behaviors that may exist in your environment and go completely undetected. High-level coverage scores look good in reports and obscure what’s actually happening. The risk lives at the sub-technique level.
Second, IOC-based detections are becoming a liability at scale. IP addresses, file hashes, domains are valuable in incident response but brittle as primary detection logic. Their half-life is short, adversaries burn them readily, and maintaining a large list of active IOCs creates noise without proportionate signal. Organizations that lead with IOCs end up toggling rules on and off constantly, adding friction without improving coverage. The maintenance cost compounds without a meaningful security return.
Third, telemetry that looks healthy often isn’t. A Windows Event ID 4688 without command-line logging enabled is an example. You’re paying to ingest it, it shows up in your coverage maps, but it provides no actionable data when something fires. Unmapped or broken telemetry creates the appearance of coverage where none actually exists. Before you write a new rule, validate that the data it depends on actually contains what you think it does.
Behavioral detections are built around what attackers do across a campaign, not what artifacts they happened to leave behind in a specific incident. Techniques, sequences, tool patterns, execution chains persist across campaigns, across threat actors, and even across malware families. A behavioral detection written well today has a much longer useful life than any IOC-based rule.
The shift to behavioral detection isn’t just a philosophy, it requires specific changes to how rules are built and maintained.
Score-based detection logic is one of the most underused approaches in enterprise SIEMs. If you’re running Splunk, Sumo Logic, or Cortex XDR, score-based rules let you assign weighted values to individual signals and alert when combinations cross a threshold. Individual signals that are weak in isolation, a process executing from an unusual path, a network connection to an uncommon destination, a scheduled task created outside business hours, become meaningful together. Noise goes down. True positive rate goes up. And the system stays tunable as your environment changes.
Permutation testing is the other discipline most detection programs skip. LLMs make it straightforward to generate attack variants at volume. Defenders should be doing the same before releasing rules. If a detection rule only catches one specific implementation of a technique, an attacker using a slightly different toolchain or execution order will evade it. Testing rules against a range of permutations before production deployment closes gaps that post-deployment tuning will miss.
The traditional cycle, write a rule, deploy it, wait for something to fire, tune reactively when it generates too many false positives, is too slow for the current threat environment. By the time you’ve finished tuning a rule for last quarter’s threat, new attack patterns are already in the wild.
The cycle needs to compress at every stage. Prototype rules should be tested in isolated environments before they reach production. Sandboxes and virtual machines can be spun up quickly in the same pipeline as rule development, giving you a controlled validation environment. Rules that are tuned before deployment don’t flood the SOC on their first day, and analysts who aren’t buried in false positives from new rules are analysts who can actually investigate real threats.
Continuous monitoring closes the loop. Every alert that fires, every verdict and every outcome feeds information back into the detection posture. Which rules are generating signal? Which ones are generating noise? Where are the coverage gaps that no existing rule addresses? Without this feedback loop, detection engineering becomes a periodic exercise rather than a continuously improving system.
A well integrated feedback loop investigates every single alert a detection creates, resolves false positives from critically important detections while continuously tuning the behavioral model to secure your organization and security detection pipeline.
Coverage benchmarks help set realistic expectations and give teams a concrete target. Based on what we see across enterprise environments:
Anything above 70% is usually inflated. Scores at this level typically reflect mapping sprawl across multiple MITRE versions, technique-level claims that obscure sub-technique gaps, or rules that are mapped but broken. Validate the underlying data before trusting the number.
The goal isn’t 100% coverage. That number isn’t achievable or meaningful. The goal is systematic, maintainable coverage of the techniques most relevant to your environment and your crown jewels, with the sub-technique depth to catch how those techniques are actually executed.
Mythos focused attention on a specific capability and that is autonomous chaining of exploit steps that previously required human guidance at each stage. A skilled researcher can still walk an LLM through finding a vulnerability, reaching exploit code, and overtaking an instruction pointer, but that process requires human direction at each transition. What makes autonomous chaining meaningful is that it removes the human from the loop on the attacker side.
The detection engineering response isn’t a new category of rule. It’s the same disciplines applied with more rigor and at higher speed. Attackers using LLMs are still executing against endpoints, still writing to disk or running in memory, still making network connections, still creating processes. The behaviors are recognizable. What changes is the volume of variants and the speed at which new campaigns emerge.
Score-based logic handles volume well because it doesn’t require a rule per variant. Permutation testing handles new variants better than reactive tuning because gaps are found before deployment rather than after. Behavioral coverage handles campaign evolution better than IOC maintenance because the underlying techniques persist even as the tooling changes.
This is where an integrated model matters most. AI-powered detection engineering delivers the most value when it doesn’t operate in isolation, and at Intezer it runs on the same loop as automated triage and investigation. The platform investigates 100% of alerts across endpoint, identity, cloud, network, and SIEM, and every verdict feeds directly back into detection, surfacing noisy rules, broken telemetry, and coverage gaps as they happen rather than at the next review. Detection, triage, and investigation reinforcing one another is what produces a fully optimized security environment, one that keeps pace as attacker AI accelerates.
The organizations that fare best against AI-powered threats will be the ones that already had a functioning detection engineering program, one built on behavioral logic, continuous feedback, and validated telemetry, before the threat landscape changed. Catching up under pressure is possible, but it’s harder and slower than building the discipline now.
The attacker’s AI is getting faster. The detection engineering cycle should be too.
Learn more about Intezer’s AI-powered detection engineering.
The post Detection engineering in the AI era appeared first on Intezer.
A cybercrime campaign combined a loader-as-a-service framework and DLL sideloading via a Go-compiled fake MpClient.dll, a novel evasion layer combination.
The post Vidar Stealer Unmasked: Code Signing Abuse, Go Loaders and File Inflation appeared first on Unit 42.
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.
Table Of Contents
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.”
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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 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.
Email remains the primary entry point for phishing, fraud, malware, and Business Email Compromise (BEC) attacks. While Microsoft 365 provides a strong foundation, organizations need additional layers of protection to defend against increasingly sophisticated threats
A look inside the reverse-engineering journey of building the first RDP client outside of Windows to support WebAuthn redirection.
The post How We Added WebAuthn to a Browser-Based RDP Client appeared first on Unit 42.
In this post, we explore the emergence of Remus Stealer, analyzing its structural and behavioral similarities to the infamous Lumma malware.
Table Of ContentsThe 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.
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:
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 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 is a 64-bit compiled binary, and Lumma was a 32-bit binary. However, major similarities between the code bases of both malware can be observed.
Upon execution of an unpacked sample, both Remus and Lumma will send warning messages to the user that the build is unpacked. This was a unique phenomenon first established by Lumma several years ago. In both Remus and Lumma samples, the pack check and window message are performed before the main functionality of the malware.
In both Remus and Lumma, a function is used first to check if the sample is packed, and a second function is used to send the window error message.
Remus uses similar string obfuscation methods to Lumma, in which each string has been uniquely encoded and then decoded during runtime. Deobfuscation occurs by looping byte by byte through encoded blobs. Each encoded string is obfuscated by a unique pattern. This can be seen in the code samples below:
Of note, both samples have at least one NOP instruction between the encoded blob being moved onto the stack and the deobfuscation loop.
Another unique feature of Lumma is the presence of a plaintext identifier string used to link customers to specific build generations. In Lumma, this string was referred to as the LID (Lumma ID), and this ID method appears in Remus as well as a “tag.”
Like the Lumma LID string, the Remus tag could be leveraged to attribute variant builds and campaigns to single threat actors or groups.
Additionally, both Remus and Lumma exhibit similar control flow obfuscation by replacing direct jumps with indirect jumps read from offsets that have been moved onto the stack, jumps computed from a jump table, and jumps resolved by a pointer.
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.
Remus stealer represents a sophisticated continuation of the MaaS infostealer model left behind by Lumma’s collapse. While the developer asserts independence, the overwhelming code overlaps, matching obfuscation techniques, and administrative panels indicate that Remus is either heavily inspired by, or derived from the Lumma codebase. These traits have allowed it to thrive, providing threat actors with a familiar, robust alternative that sidesteps the reputational baggage and law enforcement scrutiny of its predecessors.
Flashpoint continuously tracks the latest developments in illicit communities, hard-to-reach adversary spaces, and malware repositories to identify emerging threats. Request a demo to learn how Flashpoint’s primary source collections and analyst insights empowers your security teams.
The post Remus Stealer: A New, Not-So-New Infostealer appeared first on Flashpoint.
Intezer already investigates 100% of your alerts and escalates fewer than 2% of them for human review. That part is handled.
The work does not stop there, though. Every SOC has its own routines wrapped around the investigation itself. The incident reports written in a particular format, the closure notes, the shift handoffs, the rules that decide who picks up which case. When we looked at how teams actually use AI Chat, our in-product investigation agent, more than a third of those conversations turned out to be the same repetitive tasks asked again and again. The same summaries. The same reports. The same closure notes.
Intezer’s AI SOC already runs agents around the clock to triage, investigate, and respond to your alerts on their own. Custom Agents is the next step. Now you can shape how that AI SOC works for your team. Add your own agents and automations on top of the ones Intezer runs out of the box, take more of the manual work off your analysts, and tailor the whole thing to the way your team actually operates.
Intezer ships with a set of agents and automations that handle triage, investigation, and response from day one. Custom Agents lets you build your own on top of them.
An agent is made up of three components:
You describe what you want done in plain language, choose when it should run, and pick what it can touch. It then runs on its own inside your Intezer environment, on the same engine that powers our investigation Agent (Chat).
1. Tell it what to do, in plain language. Write the instructions the way you would brief a new analyst. “Every morning, review the open case queue, close the clear false positives per our playbook, and leave a handoff note on the rest.” That is an agent.
2. Choose when it runs. Three trigger types cover most workflows:
3. Give it the right tools. Agents work across your whole stack which includes Intezer’s built-in toolset plus the SIEM, EDR, and identity tools you have already connected, including CrowdStrike, SentinelOne, Splunk, Microsoft Sentinel, and Entra ID. They do more than summarize. They take action by updating, commenting on, closing cases, and emailing a finished report to your team.
Take an Incident Report Writer agent illustrated above. We deliberately never shipped a single “Generate report” button, because no two teams want the same report. One team wants an executive summary up top, another wants the full timeline, another has a compliance format it has to match. So instead of a button, you put your format into the agent’s instructions, and it writes every report that way, every time.
The agent triggers on every escalated case an analyst has confirmed as a real threat. It reads the case, writes the report in your format, and emails it to your team’s inbox. The analyst makes the call. The paperwork writes itself.
That’s one agent. The point of Custom Agents is that you decide what they are.
Security teams do not trust black boxes, and they are right not to. Custom Agents is built so you can see and control everything an agent does.
This is how everything at Intezer works. AI executes, humans supervise. Custom Agents lets you decide what it executes.
We opened Custom Agents to a small group of alpha customers, and the best part has been watching what they build. Alongside the Incident Report Writer above, a few of the agents already running in production:
We are on a mission to build the AI SOC the industry has been promised but never delivered. One that does the work and earns the trust to do it. It runs autonomously, around the clock. It works alongside the people who supervise it, not over their heads. And it is never a black box. You can always open it up, question what it did, and change how it behaves.
Custom Agents is central to that vision. Triage, investigation, and response come built in. Everything particular to how your team operates, you build yourself. Because the strongest security teams have always run on their own playbooks, their own logic, and their own standards, and an AI SOC should be no different. It should not ship the same to everyone. No two SOCs are the same, and no two should be.
That is the point of Custom Agents. You decide what they are.
Custom Agents is available now in beta to Intezer customers, and it is free during the beta period. This is the moment to build, test, and tell us what you want it to do next.
See what your SOC could hand off. Book a demo.
If you are already an Intezer customer, you will find it under Custom Agents in the top menu.
The post Introducing Custom Agents: Automate your SOC, your way appeared first on Intezer.
Attackers can exploit LLM domain hallucinations through phantom squatting to target supply chains. Read the analysis to learn more.
The post Phantom Squatting: AI-Hallucinated Domains as a Software Supply Chain Vector appeared first on Unit 42.
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.
Table Of Contents
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.
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.
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.
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.
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.
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.
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.
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.
To ensure attendee safety, safeguard operations, and protect public-facing brands, Flashpoint recommends implementing the following proactive measures:
Ensure your security team has full visibility into the cyber and physical threat vectors shaping this historic holiday weekend. Request a demo and see how Flashpoint equips organizations with the intelligence needed to detect, analyze, and mitigate emerging risks.
The post America250 Fourth of July Threat Assessment appeared first on Flashpoint.
The email landscape has fundamentally changed — and in 2026, there is no ambiguity left:
DMARC is no longer optional. It is enforced.
Over the past two years, the world’s largest mailbox providers — Google, Yahoo, and Microsoft — have implemented strict authentication requirements. Today, any domain sending bulk email must have properly configured SPF, DKIM, and DMARC, or risk outright rejection. [mailcop.net], [redsift.com]
This shift marks the end of the “open email era” and the beginning of a trust-based ecosystem where authentication is mandatory.
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.
Table Of ContentsIn 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.
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:
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:
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.
The post Unmasking the Digital Trail: Essential Techniques for Vetting AI-Generated Content appeared first on Flashpoint.
We provide guidance for preparing for and mitigating large-scale credential attacks, focusing on recent campaigns targeting security vendors' devices.
The post Threat Brief: Mitigating Large-Scale Credential Attacks appeared first on Unit 42.
Government entities and critical infrastructure were targeted for espionage in SE Asia by attackers using a hybrid toolkit, including custom TinyRCT backdoor.
The post CL-STA-1062 Targets Southeast Asian Governments and Critical Infrastructure appeared first on Unit 42.
Unit 42's analysis of ClawHub revealed evasive malicious skills bypassing automated scanners to deploy infostealers and execute agentic financial fraud.
The post OpenClaw’s Skill Marketplace and the Emerging AI Supply Chain Threat appeared first on Unit 42.
Cold email are unsolicited outreach sent to people who have no prior relationship or consent—usually to pitch a product, partnership, or opportunity. Well, the key message is simple: most cold email, especially at scale, behaves like spam—even if it looks personalized or “legit.” Don't let it pass more than once or twice!
Unit 42 research details how attackers could exploit global name uniqueness in bucket hijacking to redirect cloud data streams across major CSPs.
The post The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration appeared first on Unit 42.
Login