The paradoxes of today’s digital world are well-known to anyone with a smartphone.
Over the last decade, connectivity has expanded, yet the world has become more fragmented. Our everyday lives are more digital, but we spend more time parsing text messages for scams or deliberating the authenticity of potential deepfakes. Technology is delivering great productivity gains to small businesses while making them a larger target for cybercriminals.
In this environment, exposure becomes the default: Access points are growing, control is hard and reacting to change stops working. AI intensifies these dynamics because it compresses time for everyone, including adversaries.
Today, trust has become the most critical tool to move all businesses forward. Without trust, even the best ideas stall. People hesitate, adoption slows and growth stagnates.
Trust used to be something businesses tried to repair after a breach. Now it must be the starting point, and something to nurture and continuously prove in a world that has fundamentally changed.
It would be impossible to eliminate the risk entirely. Some estimates project cybercrime could cost the world $15.6 trillion annually before 2030, surpassing all but two of the world’s largest economies. Instead, the goal must be to build the ability to see sooner, decide faster and limit impact when, not if, something breaks. Trust today is all about bringing together speed, intelligence and collaboration, and that’s exactly what we’re developing across our teams.
Getting this right isn’t just good business sense, but the only way to ensure new technologies are embraced and economies can keep growing.
The advantage is intelligence
Real advantage comes from understanding context and connecting signals across systems. That’s what turns data into better decisions. This kind of intelligence increases speed, reduces risk and enables proactive action. With the right intelligence, teams can hunt for threats continuously, test assumptions and act before harm occurs, not just triage alerts after the fact.
You can see this shift in how the payments industry is evolving, including the work we’re doing by bringing Recorded Future’s threat intelligence together with Mastercard’s security capabilities, payments infrastructure and partnership models. We’re helping organizations understand where risk concentrates, how it propagates, and how quick, collective action can reduce the cost of cybercrime.
Faster insights mean earlier action, which minimizes impact — and deepens trust.
Trust is built through collaboration
Security doesn’t scale through isolated heroics. It scales through ecosystems: shared signals, shared standards and partners who can move together as new threats arise, attack vectors shift and failures spread.
Resilience is strongest when public and private sectors plan, exercise and respond together, rather than in parallel. Different players have different sightlines in the digital ecosystem. Startups look at the edges of innovation. Enterprises understand the realities of operating in today’s environment. Governments see where systemic risk concentrates. When those visions combine, our shields strengthen and expand, pushing cybercriminals out of the frame.
During our time here in Miami for the eMerge Americas conference, we’ve had the opportunity to speak to enterprises, startups, investors and government leaders about the need to accelerate resilience in Latin America, where the digital economy is booming but security hasn’t always kept pace. The region has the world’s fastest-growing rate of disclosed cyber incidents — in 2025 alone, Recorded Future tracked 452 ransomware incidents — but only seven countries have developed cybersecurity plans protecting critical infrastructure, and only 20 have formal computer security incident response teams.
That gap is where trust breaks, and where more collaboration can become a growth necessity. We can’t build sustainable economic growth in Latin America without building digital trust and cyber resilience. That’s why we are deepening our footprint here, enhancing regional threat intelligence and resilience and paving the way for stronger public-private collaboration to address these complex risks.
Secure digital access unlocks economic opportunity — and insecurity shuts it down fast. For a first-time digital user, one fraud incident can be enough to opt out for good. For a small business, one account takeover can wipe out months of progress. That’s why trust is inextricably linked to financial health. People can’t build stability on top of systems they’re afraid to use. At Mastercard, we’ve committed to connecting and protecting 500 million people and small businesses by 2030, because secure participation is foundational, not optional.
The bar for digital innovation today is not what we can deliver, but what people will trust enough to use, depend upon and harness for their own financial health. Because in the end, trust is the superpower.
Building on our recent announcement of AWS Security Hub Extended —our full-stack enterprise security offering — we want to show you how we’re simplifying security procurement and operations for your multicloud environments. Whether you’re a security architect evaluating solutions or a CISO looking to streamline vendor management, this post walks through the streamlined experience that transforms how you acquire, deploy, and manage end-to-end enterprise security solutions across endpoint, identity, email, network, data, browser, cloud, AI, and security operations. Security Hub Extended brings together AWS security services with carefully curated security partners. Delivering better outcomes together through unified procurement, billing, and operations that significantly reduce vendor management overhead so you can focus on what matters most: protecting your organization.
The challenge we’re addressing
Security teams today spend too much time on vendor management, evaluating services, negotiating contracts, and managing multiple billing cycles instead of focusing on what matters most: managing risk. But the procurement challenge runs even deeper. Until now, customers really only had one option: sign multi-year agreements based solely on proof-of-concept testing and estimated annual usage. This forces organizations to commit budget before they can validate whether a solution will work for them at scale.
AWS Security Hub Extended transforms this procurement model. Security Hub Extended offers customers the option to get started with pay-as-you-go pricing and no commitments, so they can move fast and validate solutions in their actual environment. After they’ve confirmed a solution works at scale, they can then align their vendor strategy and sign longer-term commitments for even more favorable pricing.
Security Hub Extended provides a curated set of carefully chosen partner solutions with competitive pricing, unified billing through your AWS account, and seamless integration. Our initial launch partners, selected by customers for their proven value, include 7AI, Britive, CrowdStrike, Cyera, Island, Noma, Okta, Oligo, Opti, Proofpoint, SailPoint, Splunk, Upwind, and Zscaler.
Getting started with Security Hub Extended
AWS Security Hub consolidates threat analytics from Amazon GuardDuty, vulnerability management from Amazon Inspector, and sensitive data discovery from Amazon Macie, correlating these signals with Security Hub Exposure findings to determine overall risk, reachability, and assumability. Security Hub Extended builds on this foundation by adding curated partner solutions, extending these unified security operations across your entire organization including multicloud, on-premises, and endpoint environments. If you’re already using Security Hub, you can navigate directly to the Extended plan section.
Getting started with Security Hub is straightforward. From the AWS Management Console, search for Security Hub to start the onboarding walkthrough. If you’re not already a Security Hub customer, you can quickly complete onboarding by designating an AWS organization delegated administrator (DA) account. You can then centrally enable and manage Security Hub across your entire organization’s accounts and AWS Regions from a single location (see Introduction to AWS Security Hub). After you’ve onboarded, navigate to the Extended plan section to add curated partner solutions.
Figure 1: Security Hub centralized configuration
From this single interface, you can enable detection and response capabilities across your entire organization, provide granular configurations at the organizational unit or member account level, select specific Regions, and turn individual features on or off as needed.
Understanding risk through attack paths
The Security Hub risk correlation engine identifies potential exposures by correlating threats, vulnerabilities, and misconfigurations to reveal how they connect and could lead to compromise of critical resources.
The attack path visualization in the preceding figure reveals critical insights including upstream root causes and blast radius, showing the potential impact if a threat actor exploits a vulnerability. You can use this visualization to focus on fixing the root cause rather than addressing symptoms. For example, updating one security group configuration can eliminate the entire attack path, cutting off all downstream exposure.
Accessing Security Hub Extended
You can find Security Hub Extended, shown in the following figure, in the left navigation pane under Management in your Security Hub delegated administrator (DA) account; Security Hub Extended will only be visible from the delegated administrator account. The Extended plan brings curated third-party security solutions directly into the Security Hub experience. Because Extended is built into Security Hub, there’s no separate console to manage. You discover, subscribe to, and operate curated partner solutions from the same place you manage enterprise security, delivering unified operations across your entire security estate.
Transparent, competitive pricing consolidated with Security Hub
Unlike traditional third-party engagements that require lengthy negotiations, private pricing deals, and multi-year commitments, Security Hub Extended offers complete pricing transparency. Every partner solution displays clear, competitive monthly pay-as-you-go rates billed directly with Security Hub requiring no commitments. For example, Cloud Security from Upwind costs $3.75 per resource per month, and Identity Security from Okta costs $20 per user per month.
All Security Hub Extended offerings are also eligible for AWS Enterprise Discount Program (EDP) discounts that will be applied automatically. If you have an existing AWS enterprise discount agreement, those discounts automatically apply to Security Hub Extended offerings, further reducing your effective costs. All partner solutions you deploy through Security Hub Extended appear on your consolidated AWS bill, no separate invoices or payment processes.
Streamlined onboarding
Adopting curated partner solutions through Security Hub Extended is straightforward. Choose View Product to initiate an automated workflow. Depending on the solution, you’ll either be directed to the partner onboarding console or provide information for the partner to guide you through their onboarding process tailored to your environment.
Billing begins only after you’re fully activated on the partner solution and starts automatically, no additional action is required to benefit from the unified billing. If you’re already using one of the curated partner solutions, transitioning to Security Hub Extended for consolidated billing and flexible pricing won’t disrupt your current services. Now, instead of receiving separate invoices for each partner in addition to Amazon Inspector, GuardDuty, and Security Hub CSPM you get one unified bill through Security Hub. This consolidates visibility to support better understanding of spend and to manage cost.
Unified operations
Security Hub Extended unifies security operations by consolidating findings from AWS and curated partner solutions. All findings use the Open Cybersecurity Schema Framework (OCSF) for consistency, without the need for complex data normalization, transformation, and extract, transform, and load (ETL) processes.
When you deploy solutions such as CrowdStrike, Noma, and Upwind alongside Splunk and 7AI through Security Hub Extended, security findings automatically flow into Security Hub and then seamlessly route to Splunk and 7AI. All in OCSF format so your security team can focus on responding to threats, not managing pipelines, so you can quickly identify and respond to security risks that span boundaries—from endpoint compromises to cloud infrastructure—without spending valuable time on manual integration work.
The full-stack security vision
Security Hub Extended represents a shift in how you discover, procure, and build comprehensive security programs. Instead of managing dozens of vendor relationships, negotiating separate contracts, agreeing to multi-year annual commitments, and integrating disparate tools, you now have one procurement process through AWS, one bill with transparent competitive pay-as-you-go pricing, one console for unified security operations, one support channel for AWS Enterprise Support customers, and one schema (OCSF) for all security findings. The result: reduced security risk, improved team productivity, and a more unified approach to security operations across your enterprise.
Get started
Try Security Hub Extended today and experience how simplified procurement and unified operations can transform your security program. Security Hub Extended is generally available globally in all AWS commercial Regions where Security Hub is available. We’ve also published a walk through video to further explain how Security Hub Extended works.
It’s still Day 1, but we’re iterating fast, so share your feedback with us on AWS re:Post for Security Hub or through your AWS Support contacts and watch for future blog posts on our progress.
Amazon Web Services (AWS) is pleased to announce that the Winter 2025 System and Organization Controls (SOC) 1 report is now available. The report covers 184 services over the 12-month period from January 1, 2025 – December 31, 2025, giving customers a full year of assurance. This report demonstrates our continuous commitment to adhering to the heightened expectations of cloud service providers.
AWS strives to continuously bring services into the scope of its compliance programs to help customers meet their architectural and regulatory needs. You can view the current list of services in scope on our Services in Scope page. As an AWS customer, you can reach out to your AWS account team if you have any questions or feedback about SOC compliance.
To learn more about AWS compliance and security programs, see AWS Compliance Programs. As always, we value feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below.
AI vulnerability research and discovery capabilities are improving, but they have not changed the fundamentals of vulnerability management. Instead, they are scaling up problems familiar to vulnerability managers: patch prioritization and remediation backlogs.
For defenders, the timeline for determining which vulnerabilities matter most and remediating them before exploitation begins is narrowing, even as the overall volume of vulnerabilities rises. Organizations that rely on manual prioritization, slow patch cycles, or legacy software will face growing operational and security risks.
Figure 1: Reality versus hype of automated vulnerability research
The Vulnerability to Exploit Ratio
Vulnerabilities are software flaws attackers can use to gain access, run malicious code, escalate privileges, or disrupt operations. However, not every bug becomes a real-world threat: many are hard to reach, difficult to weaponize, or simply not worth an attacker’s time.
The total number of disclosed vulnerabilities has increased sharply in recent years, rising from roughly 21,000 in 2021 to nearly 50,000 in 2025. Part of that increase likely reflects stronger disclosure practices and bug bounty activity, though software growth, a broader attack surface, and more systematic reporting also play a role. Nonetheless, in 2025, Recorded Future only identified 446 vulnerabilities that were actively exploited in the wild, a reminder that confirmed exploitations remain a small fraction of total disclosures.
Figure 2:Yearly comparison of disclosed CVEs against CVEs with public exploits and vulnerabilities assessed as actively exploited by the Cybersecurity and Infrastructure Agency’s Known Exploited Vulnerabilities (KEV) Catalog and Recorded Future, 2021-2025
This is because attackers do not exploit every bug they find. Instead, they focus on developing exploits for the small subset of vulnerabilities that offer the best combination of reach, reliability, and return on investment, such as flaws that can be exploited remotely or affect widely used software. In other words, a vulnerability still has to be validated, turned into a reliable exploit, matched to a target, and integrated into an attack path worth the effort.
When a flaw matches the criteria, however, exploitation can move quickly. VulnCheck found that nearly 29% of KEVs in 2025 were exploited on or before CVE publication, a slight increase from the previous year, indicating the continued prevalence of zero-days and n-days. Much as their legitimate counterparts use AI in software development, adversaries are already using AI to accelerate parts of the attack workflow, including vulnerability research, exploit-path analysis, and malware development, even if its precise effect on exploitation timelines is hard to quantify. Some trackers estimate the median time-to-exploit may now be measured in hours rather than days, demonstrating the shortening window of time to act on a high-impact vulnerability.
How AI Changes the Equation
Anthropic and OpenAI recently drew significant attention through their limited release of what they claimed were uniquely powerful cyber defense models. An independent evaluation of Anthropic’s Mythos found significant improvements in multi-step cyberattack simulations. However, AI-assisted vulnerability discovery and penetration testing predate these models, and most frontier models have already demonstrated the ability to identify vulnerabilities and assist with exploit development. At present, these tools are still most effective in the hands of capable operators rather than enabling frictionless, low-skill exploitation at scale. This matters, too, as even if these capabilities are used primarily by security researchers in the near term, the resulting increase in disclosures, proofs of concept, and validated findings still adds to the defensive burden.
This impacts vulnerability management in three important ways:
More credible vulnerability reports to triage: New agentic systems can do more than flag suspicious code; they can reason through program behavior, validate findings, and help identify which weaknesses appear most exploitable.
Less time to mitigate exploitable vulnerabilities: Large-language models (LLMs) are accelerating the speed and scale of weaponization, meaning the path from disclosure to exploit could go from hours to minutes.
Reduced the cost of exploit development: Emerging models appear more capable of producing proof-of-concept exploit code, testing attack paths, and helping skilled operators iterate toward weaponizable exploits faster than before.
Figure 3: The vulnerability equation: How automated capabilities will likely impact reporting, exploit development, and impact
More Reports, More Noise
Using AI agents for software code will almost certainly increase the number of reported vulnerabilities and developed proofs-of-concept. Microsoft’s April 2026 Patch Tuesday, which followed Anthropic’s Project Glasswing announcement, was the company’s second-largest on record. However, according to Microsoft, it “does not reflect a significant increase in AI‑driven discoveries, though [they] did credit one vulnerability to an Anthropic researcher using Claude.” The more important question is not whether more flaws will be found — because they will be — but whether defenders can process, validate, and prioritize them fast enough to act.
Vulnerability submissions are already overwhelming researchers’ ability to assess their overall risk, creating a backlog of vulnerability enrichment and scoring. If AI sharply increases the volume of plausible findings, defenders will face even more uncertainty around which vulnerabilities represent the next high-impact systemic event and which are background noise.
Less Time to Act
For the vulnerabilities that are actually a problem, defenders have even less time to respond. Automated exploit development will likely shorten the path from discovery to proof of concept and, in some cases, to weaponization for the subset of vulnerabilities worth pursuing. Adding to the triage problem, some medium-severity or otherwise “non-critical” vulnerabilities will need to be re-evaluated as possible components of exploit chains, even if they would not normally rank as urgent on their own.
Drowning out the Alarms
Even as defenders deal with more noise, a larger volume of reported, plausible findings is likely to increase the absolute number of high-impact exploits they need to address quickly. As a result, defenders face an even greater challenge in identifying the small subset of issues that matter most before attackers do.
This does not mean every newly disclosed flaw will be weaponized, or that high-impact, “internet-breaking” events will become commonplace; however, even a modest increase in exploited vulnerabilities puts more pressure on prioritization, patching speed, and compensating controls, especially for organizations already struggling with manual triage, slow patch cycles, or legacy software.
How to Use Automation for Good
For most organizations, the immediate risk is not that every vulnerability will suddenly be exploited, but that defenders will have less time to determine which findings matter most. Vulnerability discovery and exposure management should therefore be treated as related but distinct problems: AI may increase the number of findings, but defenders still need context to determine which exposures are actually reachable, high-impact, and worth urgent remediation.
In this environment, using AI-enabled vulnerability discovery, prioritization, and defensive remediation will be essential to keeping pace with attackers. The five actions listed in the following section can help organizations stay ahead of the threat.
1. Automate Vulnerability Prioritization and Response
Shift from CVSS-only scoring to real-time exploitability and exposure-based risk scoring to handle the surge in AI-assisted vulnerability discovery. Deploy automated scanning, validation, and threat hunting to identify exploitation activity quickly, especially in widely used software and internet-facing systems. Recorded Future’s Insikt Group regularly reports on new vulnerabilities and exploit trends and develops Nuclei templates to detect actively exploited vulnerabilities.
2. Accelerate Patching and Upgrade Cycles
As the time to exploit shifts from days to hours, the time to mitigate vulnerabilities will similarly shorten. Patch management will need to move faster, particularly for internet-facing systems, widely used software components, and critical dependencies. Automated remediation and automated compensating controls will likely become necessary to keep pace with AI-accelerated discovery. The Vulnerability Intelligence module in the Recorded Future Intelligence Operations Platform can help with prioritization based on the likelihood of exploitation. Ensure all automated actions are logged and regularly audited by a human, and require a human-in-the-loop for any actions on high-impact systems.
3. Reduce Dependence on Legacy and Unsupported Software
AI may make it easier for threat actors to identify and validate exploitable weaknesses in older, under-maintained codebases. Unsupported systems and aging software are likely to become increasingly difficult to justify unless they are strongly isolated and tightly controlled.
4. Shift Vulnerability Detection Earlier in the Software Lifecycle
Organizations should integrate automated security testing and AI-assisted vulnerability discovery into development pipelines. Early detection can help defenders fix vulnerabilities before production, reducing remediation burden later.
5. Get Ready for the Next High-Impact Event
Develop emergency response and mitigation playbooks specifically for high-impact, broadly applicable flaws, including scenarios where a patch is not immediately available. Preparation should include not just patching, but also containment measures such as segmentation, access restrictions, traffic filtering, and other compensating controls.
Integrate, don't replace. Recorded Future enriches your existing security tools by automatically layering in contextual threat intelligence, reducing manual effort and enabling faster, better-informed decisions.
Know where you stand. Assessing your organization's maturity across four stages — reactive, proactive, predictive, and autonomous — helps you identify which workflows to prioritize and where automation can have the most impact.
Start simple, then scale. Four core workflows (i.e., IOC enrichment, vulnerability prioritization, Autonomous Threat Operations, and watch list automation) offer a practical on-ramp, and many integrations can be activated in just a few clicks through Recorded Future's Integration Center.
Threat intelligence can elevate cybersecurity programs from reactive to autonomous, transforming workflows and delivering measurable improvements. In a recent webinar, we shared practical steps for integrating threat intelligence into existing security stacks, optimizing workflows, and accelerating organizational maturity in cybersecurity practices.
Read on for actionable insights, frameworks, and tools shared during the session.
Bridging the gap: threat intelligence integration
The key to effective threat intelligence is making your tools work together seamlessly. Recorded Future doesn’t aim to replace your existing cybersecurity tools, but rather to enrich and connect them.
When Recorded Future connects to the tools already in your stack, it automatically adds contextually relevant threat intelligence to whatever you're working on. This can mean less manual effort and faster, better-informed decisions.
Understanding your organization’s cyber maturity
A useful starting point is assessing where your organization currently stands across four stages of cybersecurity maturity: reactive, proactive, predictive, and autonomous:
Reactive organizations focus on responding to incidents as they occur.
Proactive organizations hunt for threats before they lead to incidents and align detection systems to adapt toward emerging risks.
Predictive programs extend threat intelligence beyond the security operations center (SOC) to other organizational stakeholders.
Autonomous programs leverage automation to identify and respond to threats in real time at machine speed.
Maturity doesn't have to be assessed at the program level alone. Individual use cases may be at different stages. Alert management, for instance, may already be highly automated, while other workflows remain more reactive.
A helpful way to identify where to focus is to ask a series of questions, including:
What does my current alert workflow look like?
What's my most time-consuming process?
What's my top priority for the next 12 months?
Your answers will enable you to identify areas for improvement and then prioritize your workflows as needed.
Three key integration workflows—and one bonus workflow
Next, we suggest integration workflows that are designed to help you optimize your security operations with Recorded Future threat intelligence:
1. Indicator of compromise (IOC) enrichment
Detection tools often generate alerts with limited context, leaving you asking why something was flagged and how risky it actually is.By integrating Recorded Future, you’ll find that those alerts can be automatically enriched with information such as malware families, exploited vulnerabilities, and threat actor connections—enabling better, faster decisions without additional manual research.
2. Vulnerability prioritization
Most organizations depend on CVSS scores or vendor-provided data to assess vulnerabilities, but that approach doesn't always reflect real-world risk. A more effective strategy is asking: Is this vulnerability being actively exploited in targeted campaigns? Are threat actors targeting my industry with it?
Recorded Future enhances vulnerability management primarily through threat intelligence context, with risk scoring that tells you why something is risky—specifically whether a CVE is being actively exploited in the wild, and whether it's targeting organizations in your industry.
3. Autonomous Threat Operations
The most advanced workflow involves automating threat detection and prevention from end to end. Recorded Future can identify emerging threats, initiate retroactive threat hunts, and automatically update detection and blocking lists in tools like EDR platforms—all without manual intervention. This will enable your security team to shift from reactive firefighting to real-time, autonomous threat prevention. Learn more about Autonomous Threat Operations, available in Recorded Future’s Professional and Elite pricing packages.
4. Bonus workflow: Watch list automation
Your existing vulnerability scanners like Tenable, Qualys, Wiz, and Rapid7 are already identifying vulnerabilities in your environment. A Watch List automation connector can link those tools directly into Recorded Future's Watch Lists, so the Platform automatically reflects your real threat footprint at all times. Instead of tracking a static list of top vulnerabilities, you get contextual intelligence tied to what's actually in your environment, and you're automatically alerted when vulnerabilities change in risk status.This shifts vulnerability management from a reactive posture to a predictive one, and makes prioritization effectively autonomous.
The role of Recorded Future’s Integration Center
The Integration Center makes it straightforward to connect with popular security tools including Splunk, ServiceNow, CrowdStrike, and SentinelOne. Many of these integrations are pre-built and can be activated in just a few clicks, meaning there may already be value waiting to be unlocked within your existing SIEM, SOAR, EDR, TIP, vulnerability management tools, GRC platforms, and more.
Driving business value with integrated threat intelligence
Beyond operational efficiency, well-integrated threat intelligence workflows build organizational trust and give security leaders a stronger, data-backed narrative about how their teams are operating. Automating enrichment and response creates the space to focus on strategic priorities—and makes it easier to demonstrate the program's value to leadership.
The path toward autonomous threat operations requires sophisticated technology, seamless integrations, smart prioritization, and strategic planning. The best approach is simply to start: Activate a workflow, see the value it delivers, and build from there.
If you need help getting started or have questions about your organization’s specific needs, book a custom demo.
Business impersonation is the hidden thread connecting old and new fraud. Discover how the same core tactic is fueling both a surge in commercial check fraud and an explosion of AI-powered online shopping scams targeting younger consumers.
Tools like Positive Pay and 3D Secure authentication, while effective against the fraud they were built to stop, have pushed threat actors to evolve their schemes in ways that render those controls irrelevant.
Ecosystem gaps are often the real vulnerability. Fraudsters exploit the chain of assumed trust between social media platforms, card networks, merchant onboarders, banks, and local business registries — turning each party's reliance on the last into an open door.
If you’re a millennial or Gen Z-er, then you probably haven’t used a paper check in a while. According to the Federal Reserve Bank of Atlanta, just 1 out of 5 of your peers used a check in the last 30 days, versus 2 out of 5 Gen Xers and 3 out of 5 boomers. Yet despite year-on-year decreases in overall usage, Nasdaq Verafin saw check fraud instances rise another 11% in 2025.
Then again, if you are a millennial or Gen Z-er, you will have seen an advertisement for a cheap product on social media. For 40% of you, that has meant falling for an online shopping scam.
On the face of it, these look like two ends of the fraud spectrum:
On the one hand, we have what feels like the past: paper check usage rates even among those aged 65+ fell from 13% of transactions in 2013 to 6% in 2025 (Federal Reserve Bank of Atlanta).
On the other hand, we have the future: online shopping scams target a younger demographic through AI-enabled brand impersonation and sprawling social media ad ecosystems.
The payment instruments, demographics, and the teams working at financial institutions to address these problems differ. So what’s the thread linking them together? Business impersonation. It manifests itself differently across schemes, but for anti-fraud systems built to detect check washing and counterfeiting on the one hand, and unauthorized third-party card fraud on the other, business impersonation has emerged as the fraudster’s response to exploit both.
Commercial checks and copycat businesses across state lines
In the past, stolen checks were often whitewashed to change the recipient and amount, and then walked into banks for cashout. The Postal Inspection Service received over 299,000 mail theft complaints in a single 12-month period—a 161% increase from the prior year. Recorded Future’s Fraud Intelligence Team analyzed and mapped stolen checks to US geographies, illustrating hot spots of physical crime and observing that it remains a national issue that extends beyond heavily urbanized areas.
Mapping stolen checks by zip code; courtesy of Recorded Future
Yet even among declining consumer check usage rates, businesses’ use of commercial checks remains stubbornly high in the US: the Association for Financial Professionals (AFP) found that 91% of organizations are still using checks, and 63% experienced check fraud in 2024. When businesses send checks to suppliers, the amounts can rise quickly, leading fraudsters to expand beyond simple check-washing schemes.
In perhaps the most eye-catching example, fraudsters intercepted a commercial check destined for bubble-gum giant Bazooka in 2022. A $1.24 million check. Over the next two weeks, they transferred and withdrew over half a million dollars. How’d they do it? You can’t just wash out the payee name on a million-dollar check, replace it with John Smith, and expect it to clear after depositing it into a personal checking account.
Instead, the threat actors just created a fake Bazooka. The real Bazooka is registered in Delaware under the name “The Bazooka Companies, LLC”, so culprits registered a fictitious company in New York under the name “The Bazooka Companies 1 Inc”. They then used the official business license to open a corporate bank account for the new fictitious business. From there, they used cashier checks, withdrawals, and transfers to personal accounts to cash out the funds.
Fast forward to today, and the scheme is still happening. Recent research from Recorded Future Payment Fraud Intelligence(PFI) surveyed stolen checks for sale on Telegram in Q4 2025 and found over 30 checks with a business as the payee, along with suspicious new entities registered in other states a few days later. The total face value of the checks amounted to $2M.
As with most fraud, this scheme’s emergence is based on:
Exploiting ecosystem gaps between disparate parties: Businesses can have the same name as another when registered in different states. Pair that with most states’ limited mandate to investigate business registrations, and we’re left with the first gap:
“As long as the basic filing requirements are met, the office[s] may have little or no authority to question or reject a document submitted for filing or to verify information included in the filing” (National Association of Secretaries of State, September 2025)
When a fraudster approaches a bank to open a business bank account, the bank conducts its own due diligence. But the focus here is on money laundering threats and the legitimacy of documents and applicants. If the fraudsters are using a clean identity — synthetic or otherwise — then the bank won’t have a clear reason to reject the application just because a business called John’s Toilet Supply, LLC exists in another state.
Delivering a reactionary counterpunch to effective fraud processes: Think of this as the cat-and-mouse game. Fraud defenders figure out how to stop one scheme, forcing fraudsters to innovate. In this case, Positive Pay has proven remarkably effective at preventing check washing and counterfeit checks (when parties agree to use it). Payee Positive Pay, in particular, allows the payer to make sure that when their checks are deposited, the check number, date, payee name, and amount match their files. But what happens if everything is correct, but a copycat payee deposits the check? Cases like Bazooka.
80% discount on shoes? How can you say no?
If we detour into e-commerce, we see a very similar dynamic play out, but at a staggeringly larger scale. The premise is simple: use AI to launch a fake online shop impersonating company A, B, or C, buy ad space on social media to drive traffic, pocket the proceeds, and launder the funds while customers wait for goods that never arrive.
The scheme works because 53% of consumers, and 76% of Gen Zers, now begin shopping journeys on social media, according to Salesforce’s 2025 report. The problem is that the journey is littered with traps: in November 2025, leaked internal documents from Meta claimed the “company shows its platforms’ users an estimated 15 billion ‘higher risk’ scam advertisements — those that show clear signs of being fraudulent — every day”. Industry reporting paints the same picture, with the Better Business Bureau finding online shopping scams as the most reported scam type and social media advertisements as the most common originator.
Brand impersonation shopping scams impacting shoppers in January 2026; courtesy of Recorded Future
The basics of the scheme are nothing new. Capture payment card data by creating a fake online store and advertise too-good-to-be discounts. What’s changed is that these are no longer just phishing websites. They’re functional online shops that process payments via merchant accounts. Behind each of these merchant accounts is a registered business.
This is creating problems throughout the ecosystem:
Cardholders see websites that exactly mimic major (and increasingly niche) brands, letting discounts outweigh better judgment.
Financial institutions face the challenge of balancing their duty of care to process customer transactions with the risks of fraud and money laundering. But in these cases, the traditional indicators of cyber-enabled fraud aren’t present. The cardholder is authorizing the transaction, and there’s nothing suspicious within the behavioral or device indicators of the 3D Secure authentication stream. (Because, again, it’s the cardholder doing the transacting under manipulation.)
The fingers begin to point back at the acquirers and payment facilitators responsible for merchant onboarding, but, from their perspective, the entity holds a proper commercial license to engage in business issued by the local authorities. (Though, as a divergence from the check fraud scheme, the fraudsters in online shopping scams rarely impersonate a real big-name brand at the business creation and merchant onboarding stage. Instead, the fraudsters hide evidence of impersonation from the merchant onboarders and leave the impersonation for the ads and fake online shops visible to victims.)
But just like with the check fraud example, a big part of why online shopping scams have exploded — outside of generative AI making brand abuse content easier than ever to create at scale — is ecosystem gaps and fraudsters reacting to the defense:
Exploiting ecosystem gaps between disparate parties: By the time a victim is making a purchase on an online shopping scam website, each entity along the way has looked to the one before and trusted that due diligence had been performed. The cardholder wants to trust that the social media platform screened out malicious advertisers; the card issuer wants to trust the cardholder vetted the merchant; the card network wants to trust the merchant onboarder verified the business; and the merchant onboarder wants to trust local authorities properly licensed the business. A big, long line of incentivized trust.
Delivering a reactionary counterpunch to effective fraud processes: The industry has made huge strides in combating unauthorized, third-party card-not-present (CNP) fraud in the last decade. A major part of the success has been built on 3D Secure, introducing a layer of authentication on top of existing authorization controls. Online shopping scams completely sidestep the defensive layer by making the merchant the fraud surface and rendering cardholder authentication controls irrelevant.
Thinking towards the way out
On the check fraud side, the best solution may already be available, but, as with most solutions, it comes with trade-offs and adoption issues. The basic idea of Positive Pay and its derivative, Payee Positive Pay, is that a business informs its bank of the checks it is sending, and the bank only disburses funds if the check matches what the business provided. Positive Pay was designed to combat counterfeit and forged checks, and it does that very well.
Of course, in the Bazooka example of same-name business impersonation, this wouldn’t help. Nothing about the check was modified. So here, banks offer Reverse Positive Pay, which basically means the business personally signs off on each sent check. It can solve the problem but shifts more operational and investigatory expenses onto the business (which might explain why adoption rates are south of 20%, according to Datos Insights and Alkamai). In the end, though, it makes you wonder why not heed the advice and move to alternative electronic payment methods?
On the online shopping scam side, solutions are more complex and scattered across the ecosystem.
At the top of the funnel, there’s rising pressure on online advertising platforms to do a better job at limiting the presence of fraudulent advertisements. Based on more leaked internal Meta documents, regulatory pressure may not be producing the desired outcome.
At the merchant onboarding level, both the major card networks are forcing acquirers and payment facilitators to do more to defend the gates into payment processing, while also devoting more resources to identifying scam merchants that do make it in.
For card issuers on the frontline, it’s a more delicate dance. Card issuers aren’t on the hook for authorized card payments to fraudsters under the Fair Credit Billing Act (FCBA) or Electronic Funds Transfer Act (EFTA), but 67% of cardholders expect them to cover scam losses. Though when cards transacting on scam websites end up on the dark web for resale, and unauthorized charges start rolling in, it is the issuer’s problem.
The best solution aligns with the industry’s movement toward CTI-fusion models to address the cyber component of cyber-enabled fraud. The convergence of online shopping and purchase scams is precisely the type of problem the new organizational model was meant to combat.
In applying the CTI-fraud fusion model to purchase scams, traditional fraud assets start at the end of the fraud attack chain to correlate reported cardholder manipulation and non-delivery alerts against merchant account patterns. The CTI assets start at the beginning, sourcing online shopping scams at runtime and attributing the abused merchant accounts. The two teams then meet in the middle, using modeled transaction patterns and threat-hunted active scam websites, ultimately leading to the deployment of merchant-based fraud risk rules.
So, in the meantime, where does all this leave us? The same thing you’ve heard plenty of times: stop using checks if you can and don’t trust too-good-to-be-true offers from online ads.
How Recorded Future Helps
The research in this blog came directly from Recorded Future's Fraud Intelligence teams. Two capabilities speak to the threats described.
Payment Fraud Intelligence — tracks the complete fraud lifecycle: for check fraud, it uses OCR to extract payee, amount, and date from compromised checks being sold in forums, enabling deposit screening against known stolen checks; for card fraud, it monitors compromised merchants, stolen cards on criminal marketplaces, and the tester merchants fraudsters use to validate cards before striking.
Digital Risk Protection — provides continuous monitoring across millions of sources for malicious sites, brand and executive impersonation, data leakage, and dark web mentions — with risk-based alerting that surfaces only actionable threats and takedown workflows built directly into the Platform.
TeamPCP exploited a single stolen credential to gain write access to trusted software repositories, inject credential-harvesting malware, and cascade across five ecosystems in five days.
Stolen credentials can enable payroll redirection, freight rerouting, and extortion — active campaigns Insikt Group is tracking that show how a software supply chain breach can quickly become a business operations crisis.
Learn why an inventory of your software components isn't enough when malicious code is injected after the source commit, and what a truly effective defense — combining third-party due diligence. cryptographic signing, and AI-driven anomaly detection — actually requires.
In March 2026, a group calling itself TeamPCP compromised LiteLLM (a Python package with roughly 97 million monthly downloads used by thousands of organizations to connect to AI services) and Checkmarx (one of the most widely used application security testing platforms on the planet). How they got in isn’t publicly confirmed. But the result was write access to a trusted software repository.
From there, they injected a credential-harvesting payload into the software and poisoned two Checkmarx GitHub Actions workflows. The malware ran silently on installation, vacuuming up access keys, cloud credentials, secrets, and (the cruelest irony) every AI API key that LiteLLM was specifically designed to manage. The stolen data was encrypted, then pushed to a lookalike domain.
And here is the part that should keep you up at night: this was one campaign, by one group, in one week. The downstream consequences are still unfolding.
Identity Is the Perimeter (and the Attack Surface)
The throughline in the TeamPCP campaign is identity. Start to finish.
TeamPCP intelligence summary courtesy of Recorded Future.
No one has publicly confirmed exactly how TeamPCP gained access to the LiteLLM maintainer’s repository, but the most likely vector is stolen credentials. Recorded Future’s identity intelligence contains almost 1 million compromised GitHub developer credentials harvested by infostealers and sold across dark web marketplaces. A single publishing token or access key, lifted from a prior infection and left unrotated, would have been sufficient. TeamPCPs’ earlier compromise of Aqua Security’s Trivy infrastructure in late February (where incomplete credential rotation left residual access open for weeks) demonstrates exactly this pattern: one stolen token, one missed rotation, and the door stays open.
Whatever the precise mechanism, TeamPCP used valid credentials to push malicious code into trusted repositories. No firewall to bypass. No endpoint to exploit. Just a valid login and the implicit trust that comes with it.
Then the payload itself was designed to steal more identities. Each compromised environment yielded credentials that unlocked the next target. Trivy led to GitHub Actions. GitHub Actions led to four additional software distribution ecosystems. One incomplete incident response created a cascading chain of supply chain compromises across five ecosystems in five days.
This is the identity and access management problem stated as plainly as possible: if the perimeter is identity, then every stolen credential is a breach in the wall. And unlike a firewall rule, a stolen credential doesn’t trigger an alert. It just works.
We previously wrote about how deserialization vulnerabilities have plagued enterprise software for over a decade. The pattern is always the same: trusting input that should not be trusted. Supply chain attacks are the organizational equivalent. We trust the packages we install. We trust the pipelines we build. We trust the security tools we deploy. TeamPCP exploited every layer of that trust, starting with a single compromised identity.
The Impact Is Not Just Ransomware
TeamPCPs’ Telegram channel references a ransomware victim’s site. The group appears to operate as a ransomware affiliate and has publicly discussed extorting companies by threatening to release over 300 GB of stolen data. Reports indicate a possible collaboration with the Lapsus$ extortion group. Ransomware is the obvious play.
CipherForce intelligence summary courtesy of Recorded Future.
But ransomware is only the most visible impact. The more dangerous question is: what else can you do with over a million stolen cloud credentials, API keys, and service account tokens?
The answer, based on what Insikt Group is tracking across multiple unrelated campaigns, is far broader than encryption and extortion.
Redirect payroll. Late last year (2025) Insikt Group was monitoring activity around a campaign called “Swiper,” run by likely Russian-speaking actors who set up phishing infrastructure impersonating major financial institutions and payroll service providers. Stolen credentials were transmitted in real time, enabling the actors to alter direct deposit accounts and redirect payments before anyone noticed. The responsible actor was identified through a dispute on a criminal forum, and their cryptocurrency wallet has processed over 7,000 transactions. This was a credential theft operation that converted identity compromise directly into financial theft. Now imagine that same playbook amplified by a supply chain attack that harvests payroll platform credentials at scale.
Reroute shipments. Separately, Insikt Group has identified TAG-160, a threat group targeting the US logistics and transportation sector. TAG-160 impersonates logistics companies, sends fraudulent rate confirmations via phishing emails, and delivers remote access malware. But TAG-160 has also been caught running “double brokering scams,” where they pose as a legitimate carrier, obtain valid load details from a real broker, then re-advertise the load under the broker’s name to contract a different carrier. The legitimate carrier moves the freight. The threat actor collects the payment. The real carrier never gets paid. A second, unrelated threat cluster targets German logistics companies with a similar playbook.
These are not theoretical scenarios. They are active campaigns running in parallel with the TeamPCP supply chain compromises. And the common denominator across all of them is credential theft and identity abuse.
In the five risk impact categories we use as a framework for translating cyber threats into business risk, the TeamPCP compromise touches every single one: operational disruption (ransomware, system lockout), financial fraud (payroll redirection, double brokering fraud, extortion payments), competitive disadvantage (credentials, trade secrets, PII), brand impairment (customers learning their security tooling was the vector), and legal and compliance consequences (breach notification obligations, potential liability for downstream impacts).
The tendency is to categorize supply chain attacks as a “security tool problem” or a “developer problem.” It is neither. It is a business risk problem whose blast radius extends from IT operations to payroll to logistics to the boardroom.
Organizations should ask how they can use AI-driven analysis to continuously verify the integrity of every package and build artifact entering their production systems. This means comparing distributed packages against their source repositories to detect injected code. It means analyzing updates to flag anomalous changes in behavior. It means automated provenance verification that traces software from source to distribution, flagging breaks in the chain.
But the TeamPCP campaign exposed a truth the industry has been slow to internalize: the security tools themselves are targets. TeamPCP specifically chose a vulnerability scanner and an application security platform because those tools have the broadest access to credentials and infrastructure. Compromising the tool that checks your code is the ultimate fox-in-the-henhouse scenario.
The organizations that weather this era of supply chain risk will be those that treat code integrity verification as a continuous, automated, AI-augmented process rather than a periodic audit.
So What. Now What.
TeamPCP is not done. Their Telegram channel explicitly states the operation is still unfolding, and they claim to be working with new partners to monetize stolen data at scale.
For security leaders, the immediate actions are straightforward: if your organization uses LiteLLM, Trivy, or Checkmarx GitHub Actions, assume compromise and rotate every credential on affected systems. Audit your software pipelines for unauthorized changes. Pin software dependencies to verified, immutable versions.
But the longer-term lesson is more fundamental. Supply chain attacks convert the trust model of modern software development into an attack surface. The packages you install, the tools you run, the pipelines you build: these are not neutral infrastructure. They are vectors. And the credential stolen today from a compromised software package could show up tomorrow as a payroll redirect, a rerouted shipment, or a ransomware demand.
The keys to your kingdom are scattered across every package manager, every automation token, and every service account in your environment. Someone is collecting them. And your supply chain breach is already someone else’s payday.
How Recorded Future Helps
The TeamPCP campaign left signals at every stage. Three Recorded Future capabilities speak directly to this threat:
Identity Intelligence — monitors infostealer logs, dark web markets, and credential dumps in real time, automatically detecting compromised employee credentials and triggering immediate response — including the nearly one million compromised GitHub developer credentials already in Recorded Future's dataset.
Insikt Group — elite analysts with deep government, law enforcement, and intelligence agency experience who produced the TeamPCP, Swiper, TAG-160, and CipherForce research in this blog. Customers see threats as they develop, not after they've made headlines.
Third-Party Risk — continuously monitors vendors for ransomware extortion activity, breach indicators, and credential leaks, replacing point-in-time questionnaires with real-time visibility across your supply chain.
Recorded Future is now offering four solutions covering cyber operations, digital risk protection, third-party risk, and payment fraud.
Three tiered packages (Core, Professional, Elite) bundle these solutions to scale with an organization's security program.
Packages include unlimited users and integrations so intelligence reaches everyone who needs it.
The global threat landscape didn't simplify in 2025. It shattered. Recorded Future's Insikt Group® 2026 State of Security documented how geopolitical fragmentation, state-sponsored operations, and criminal ecosystem adaptation reshaped global risk. Threats that once stayed in distinct lanes converged, and they converged fast.
Consider what Insikt Group® tracked last year:
State-sponsored cyber actors shifted from intelligence collection to persistent access, pre-positioning inside target infrastructure so they can disrupt operations the moment geopolitical tensions escalate.
Weak governance and systemic corruption fueled industrialized cybercrime, enabling payment fraud and criminal operations to scale like legitimate businesses.
Influence operators and hacktivist groups multiplied alongside rising interstate conflict, amplifying fear, uncertainty, and doubt through exaggerated exploit claims.
Loosely organized criminal collectives used social engineering to compromise third-party SaaS platforms, rapidly adapting to law enforcement action and traditional defenses alike.
The risk surface has expanded well beyond networks and endpoints. Your brand, your third-party vendors, your payment networks: each has its own threat actors, its own attack methods, and its own intelligence requirements. Yet most intelligence programs only cover one of these domains. Or they monitor them in silos, with no shared context.
The right intelligence, from the right sources, at the right time, is a critical competitive advantage. But intelligence only matters if you can act on it across every critical risk domain before attackers reach their objective.
Re-Imagining How Intelligence Is Delivered And Operationalized
Historically, Recorded Future has been sold on a per-user and per-capability basis - a model that worked well in a simpler world where security teams were focused on solving the most urgent problem in front of them.
Today’s threat landscape is fast, more complex, and deeply interconnected. Customers are no longer looking for point solutions, they’re asking for a fundamentally different way to consume and operationalize intelligence.
Customers are asking us to provide:
Complete capabilities to support use cases aligned with core risk domains.
Democratized access to intelligence across teams, workflows and systems.
A simplified and predictable way to purchase for ease of budgeting and adoption.
In response, we’ve re-imagined Recorded Future is delivered:
“Four Solutions. Three Packages. One Intelligence Foundation.”
A unified approach designed to scale with your organization, accelerate time to value, and embed intelligence into every decision that matters.
Four Solutions for Four Critical Risk Domains
Your threats span your infrastructure, your brand, your vendors, and your payment networks. Your intelligence should too. We’ve re-organized our platform into four purpose-built solutions tied to distinct domains of enterprise risk.
Cyber Operations gives your security team the intelligence, workflows, and autonomous actions to detect, investigate, and respond to threats targeting your infrastructure. Alert triage, real-world vulnerability prioritization, malware analysis, proactive hunting: this is where reactive firefighting becomes predictive, intelligence-led defense.
Digital Risk Protection helps detect and disrupt threats that never touch your network but directly damage your business: brand impersonation, domain abuse, credential leaks, and phishing infrastructure across the open, deep, and dark web. With access to active infostealer logs and automated IAM remediation, your team can act on exposures within hours, not weeks.
Third-Party Risk delivers continuous, intelligence-driven monitoring of your vendor ecosystem. Security ratings combined with real-time threat intelligence surface breaches, ransomware activity, and dark web exposure days or weeks before formal vendor notification, giving your security and GRC teams evidence they can act on and defend to stakeholders.
Payment Fraud Intelligence identifies stolen payment cards, compromised checks, scam merchants, and web-skimming activity earlier in the fraud lifecycle, so financial institutions can stop losses before they materialize.
Each solution delivers complete, end-to-end capability for its risk domain. And because all four run on the same Intelligence Graph®, a signal detected in one domain immediately enriches context across the others.
Three Packages That Scale With Your Program
Modern organizations operate across multiple risk domains. We are introducing three packages that reflect that reality, meeting customers where they are and scale as their programs mature.
Core is the foundation for intelligence-led security. It enables organizations to tackle essential use cases on day one - threat detection and alert triage, vulnerability monitoring, credential exposure detection, domain abuse monitoring, and executive impersonation protection. The package combines capabilities across Cyber Operations and Digital Risk Protection solutions, providing immediate, high-impact coverage.
Professional is built for organizations ready to mature their program and operationalize intelligence at scale. Building on Core, it introduces deeper insights and automation to extend team capacity - enabling autonomous threat hunting, multi-source correlation, and external asset discovery. The result is broader coverage, faster response, and more leverage for security teams without adding headcount.
Elite delivers the most comprehensive intelligence coverage available. By unifying Cyber Operations, Digital Risk Protection, and Third-Party Risk, it provides a complete view of risk across infrastructure, brand, and supply chain. With a single pane of glass, Elite operationalizes intelligence across workflows and teams—from CTI to SOC to Risk—driving smarter and faster risk-enabled decision making and response.
Across all packages, customers get full access to the Intelligence Graph®, Recorded Future AI, all compatible integrations, APIs, and Collective Insights. No hidden costs or barriers to connect to your existing security stack.
Built for Everyone Who Needs Intelligence, Not Just Analysts
Intelligence only creates value when the right people can act on it. That's why our platform packages include unlimited users. Every analyst, every engineer, every stakeholder who needs intelligence gets it, with no seat limits and no trade-offs about who gets access.
For smaller teams building early-stage programs, we still offer flexible user-based licensing so you can start where it makes sense and expand as your program matures. Either way, pricing is predictable. You know what you're paying, and you can scale with confidence.
Every package also includes unlimited integrations from Recorded Future’s hundreds of supported applications at no additional cost. Your SIEMs, EDRs, SOAR platforms, and ticketing systems all get equipped with real-time intelligence, so every analyst and engineer working in those tools benefits from enriched context without switching screens. Add Autonomous Threat Operations, and those same integrations become the foundation for autonomous hunting, detection, and prevention across your entire stack. Connected tools become an intelligence-led defense system that acts continuously, with minimal human intervention.
One Intelligence Foundation Across Every Domain
What makes this approach powerful isn't just simpler packaging. All four solutions and all three packages run on the same intelligence foundation: the Intelligence Graph®, correlating over 1.2 million sources and 26 billion entities across cyber, digital, third-party, and fraud domains.
A credential leak detected in Digital Risk Protection immediately informs a Cyber Operations investigation. A vulnerability under active exploitation triggers prioritized patching in your workflow. A third-party vendor breach surfaces before the vendor discloses it. Intelligence flows across your entire risk surface, giving you the correlated, high-confidence context that point solutions can't deliver.
That's what it means to be intelligence-led. Not consuming more data. Connecting signals across domains so you can act earlier, with greater confidence, at machine speed.
The Path Forward
Adversaries in 2026 are faster, more coordinated, and more resourceful than they've ever been. They operate across every attack surface simultaneously, and they're accelerating.
Whether you're a team of three building your first intelligence program or a global enterprise running intelligence-led autonomous operations, there's a clear path. Start with the solution or package that matches your priorities today. Grow into deeper automation and broader coverage as your program matures. And at every step, you're backed by the most comprehensive and independent intelligence platform in the industry.
We built this for the threats you're facing right now, and the ones coming next.
In March 2026, Insikt Group® identified 31 high-impact vulnerabilities that should be prioritized for remediation, 29 of which had a Very Critical Recorded Future Risk Score.
These vulnerabilities affected products from the following vendors: Cisco, Microsoft, Google, ConnectWise, Langflow, Citrix, Aquasecurity, Nginx UI, Qualcomm, F5, Craft CMS, Laravel, Apple, Synacor, Wing FTP Server, n8n, Omnissa, SolarWinds, Ivanti, Hikvision, Rockwell, and Broadcom. This month’s most affected vendors were Microsoft and Apple, together accounting for approximately 32% of the 31 vulnerabilities.
One vulnerability (CVE-2017-7921 affecting Hikvision) is approximately nine years old, reinforcing how attackers continue to exploit long-known weaknesses in environments where patching has lagged. Legacy and unpatched systems remain attractive targets. Defenders should not discount older CVEs; instead, they should prioritize based on observed activity, maintain strong asset visibility, and apply compensating controls where remediation is not possible.
In March, Insikt Group® created Nuclei templates for a high-severity path traversal vulnerability in MindsDB (CVE-2026-27483) and a critical missing authentication vulnerability in Nginx UI (CVE-2026-27944). Additionally, Insikt Group® had already published a Nuclei template for CVE-2025-68613 (n8n) in December, prior to its exploitation this month. We also identified public proof-of-concept (PoC) exploits for 10 of the 31 vulnerabilities.
Quick Reference: March 2026 Vulnerability Table
All 31 vulnerabilities below were actively exploited in March 2026. The table below also provides examples of public PoCs identified by Insikt Group®. These PoCs were not tested for accuracy or efficacy. Vulnerability management teams should exercise caution and verify the validity of PoCs before testing.
Table 1:List of vulnerabilities that were actively exploited in March based on Recorded Future data.
Key Trends: March 2026
Most commonly observed weaknesses: CWE-502 (Deserialization of Untrusted Data) and CWE-94 (Code Injection).
Two vulnerabilities and one exploit kit (consisting of 23 exploits, 12 of which are currently associated with specific CVEs) were linked to malware campaigns.
Interlock Ransomware Group exploited a zero-day in Cisco Secure Firewall Management Center to compromise enterprise networks, deploy custom remote access trojans (RATs), and facilitate ransomware operations.
Separately, the DarkSword iOS full-chain exploit enabled Safari-based remote code execution (RCE), sandbox escape, and kernel-level access, leading to deployment of the GHOSTKNIFE, GHOSTSABER, and GHOSTBLADE payloads.
The Coruna exploit kit similarly compromised iOS devices to deliver the PlasmaLoader (PLASMAGRID) malware.
These 9 vulnerabilities affected Google, Langflow, Craft CMS, Laravel, Microsoft, n8n, SolarWinds, and Apple.
Exploitation Analysis
This section analyzes two of the highest-impact, actively exploited vulnerabilities this month. Where applicable, it also highlights the availability of Nuclei templates created by Insikt Group®. The full list of reports and detection rules from March is available to customers in the Recorded Future Intelligence Operations Platform.
Interlock Ransomware Group Exploits Cisco FMC Zero-Day (CVE-2026-20131)
On March 18, 2026, Amazon Threat Intelligence published an analysis detailing an ongoing Interlock ransomware campaign exploiting CVE-2026-20131. CVE-2026-20131 is a critical vulnerability affecting Cisco’s Secure Firewall Management Center (FMC) software that allows unauthenticated threat actors to execute arbitrary Java code as root on vulnerable devices. Cisco Secure FMC is a centralized management platform that allows administrators to configure, monitor, and control Cisco firewall devices and network security policies across an enterprise environment. According to Amazon Threat Intelligence, Interlock Ransomware Group exploited CVE-2026-20131 as a zero-day vulnerability beginning January 26, 2026, indicating active exploitation prior to its public disclosure and enabling early compromise of enterprise networks.
The Interlock Ransomware Group exploits vulnerable Cisco FMC instances via crafted HTTP requests exploiting CVE-2026-20131 to execute arbitrary Java code as root. After gaining access, the threat actors deploy a malicious ELF binary from a staging server at 37[.]27[.]244[.]222 (Intelligence Card) to support follow-on operations.
They then use custom Java- and JavaScript-based RATs, a memory-resident web shell, and proxy infrastructure to maintain access, enable lateral movement, and evade detection. Post-compromise activity includes reconnaissance, data collection and staging, and the use of legitimate tools such as ConnectWise ScreenConnect, Volatility, and Certify for remote access, credential theft, and privilege escalation.
Changes the machine’s desktop wallpaper that displays a pornographic image
Delays execution using the Sleep API function for evasion
Detects debuggers using the GetTickCount API function to compare timing
Figure 1:Risk Rules History from Hash Intelligence Card® for 6c8efbcef3af80a574cb2aa2224c145bb2e37c2f3d3f091571708288ceb22d5f in Recorded Future (Source: Recorded Future)
There's a category of employee credentials where standard monitoring often falls short: executives, finance leaders, IT administrators, and those with privileged access have a large target on their back.
VIP Credential Monitoring in Recorded Future is built to solve this problem. It continuously monitors for credential exposures tied to your most sensitive individuals across both work and personal accounts, and alerts your team fast enough to act before an account takeover occurs.
The Challenge with Protecting Your Most Targeted People
According to Verizon's 2025 Data Breach Investigations Report, credential abuse was the most prominent initial access vector observed across breaches. Attackers don't need to find a technical vulnerability to get inside your organization. Stolen credentials are widely available across criminal forums and dark web marketplaces, and buying access is often faster and cheaper than building an exploit.
What makes this particularly calculated is how threat actors decide which credentials to buy. Infostealer malware logs don't just capture usernames and passwords — they capture the authorization URLs where those credentials were entered. According to Recorded Future’s 2025 Identity Threat Landscape Report, 7 million credentials were indexed with identifiable authorization URLs, with 63.2% of those having been linked to authentication systems.
Figure 1: Top authorization URL categories, 2025 (Source: Recorded Future)
That means attackers can usually identify the access endpoints credentials unlock and they will prioritize accordingly. Executives and anyone with broad access to systems and data sit at the top of that list.
The 2025 cyber attack on University of Pennsylvania illustrates exactly how this plays out. A threat actor compromised a single employee's SSO credential and used it to move laterally across corporate systems, ultimately exposing data on approximately 1.2 million donors, alumni, and students. One credential, one login, and an organizational crisis.
The threat doesn't stop at corporate accounts. When attackers can't get hold of an executive's work credentials, they target personal accounts for these high-value targets. A personal email or social account can expose sensitive communications, private information, or material an attacker can use for extortion.
Corporate security controls don't extend to personal accounts. When those credentials are stolen, most security teams have no line of sight.
That gap between exposure and discovery is where the risk lives. Credentials stolen by infostealer malware are often purchased and weaponized within 48 hours of the compromise, potentially days or weeks before a security team has any indication something is wrong. For standard employee accounts, that window is serious. For your CEO or Head of Engineering, it's critical.
Monitoring Built for High-Value Targets
VIP Credential Monitoring provides continuous monitoring and alerting on compromised credentials for your high-value targets. Security teams can add personal or work email addresses for their executives and others with widespread access.
From that point forward, Recorded Future continuously monitors for those accounts across its full source coverage: infostealer malware logs from 30+ malware families, dark web forums, criminal marketplaces, paste sites, and breach dumps. When a VIP credential surfaces in that data, the team receives an alert with full contextual detail (malware family, authorization URL, compromised host information, etc.) so they can act with confidence.
Many executive monitoring solutions surface credential data that is days or weeks old by the time it reaches an analyst. By then, the window to get ahead of an attacker has often closed. For all stolen credentials indexed in 2025, Recorded future detected 36.4% within 24 hours of exfiltration, and 52.9% within one week.
The gap between when credentials are stolen and when a security team finds out is where breaches happen. Recorded Future closes that gap.
When a VIP credential appears in exposure data, teams can initiate a password reset, review active sessions, or reach out directly to the individual — all before the credential is exploited. For identities that carry this level of organizational risk, getting ahead of the exposure isn't just operationally valuable; it can be the difference between a resolved alert and a significant incident.
A Complete Picture of Identity Exposure
VIP Credential Monitoring is built on the same intelligence infrastructure that powers Recorded Future Identity Intelligence broadly: the same source coverage, the same detection engine, the same alert and triage workflow. It applies that capability to a category of identities that warrant closer attention, without requiring a separate tool, process, or integration. That's the logic behind Identity Intelligence as a whole: a unified view of credential exposure across every category of identity your organization needs to protect, covering employees, customers, and your highest-risk individuals.
For teams already using Identity Intelligence to monitor employee and customer credentials, VIP Monitoring is a targeted extension of coverage that fits into what they've already built. Any VIP credentials identified will benefit from the same core features of Identity Intelligence.
This includes Incident Reports, which surfaces any other credentials that may have been compromised from the same machine, and Customizable Alerting, which streamlines prioritization of these detections and can trigger response workflows through existing integrations with Okta, Microsoft Entra ID, XSOAR, Splunk, and others.
Attackers don't limit their targets to one type of account, and your monitoring shouldn't either. To see where you stand today, request a free Identity Exposure Assessment Report and get a concrete, evidence-based picture of your organization's credential exposure over the past year. Contact us to learn more about how Recorded Future can help your organization protect its identities and to see a demo of the platform in action.
For years, the cybersecurity industry has treated third-party risk management as a compliance exercise. Assess your vendors. Assign a score. File the report. Move on. That model was built for a different era. One where supply chains were smaller, threat actors were less sophisticated, and a quarterly questionnaire could reasonably approximate a vendor's security posture. That era is over.
Today, the average enterprise works with hundreds of third parties. Threat actors actively target the weakest links across those supply chains, not because the vendors themselves are the prize, but because they're the path of least resistance into larger, more valuable targets.
Ransomware groups list vendors on extortion sites before those vendors even know they've been compromised. Stolen employee credentials surface on dark web forums undetected. Critical vulnerabilities are weaponized in hours, not months. In this environment, a security rating is necessary. But it is nowhere near sufficient.
Recognized in the 2026 Forrester Wave™
Recorded Future was recently included in The Forrester Wave™: Cybersecurity Risk Ratings Platforms, Q2 2026. (The report is available online to Forrester customers or for purchasehere).
We see this recognition as a reflection of the market's evolution — and as an acknowledgement of the direction we've been building toward.
We believe the cybersecurity risk ratings market is at an inflection point. Analysts and practitioners alike recognize that the category is moving beyond standalone ratings toward integrated intelligence and actionable insights. We see our inclusion in this evaluation as confirmation that the convergence of hygiene data and threat intelligence isn't a niche play — it's where the market is heading. In light of where the ratings market is today, let’s dive into where Recorded Future is going and how Recorded Future envisions the future of securing the third-party ecosystem.
The Gap Between Hygiene and Intelligence
Cyber risk ratings have earned their place in the security stack. They provide a standardized, scalable way to evaluate a vendor's external security posture — patching cadence, encryption practices, DNS configuration, exposed services. That hygiene baseline matters. It's a correlative signal for breach potential, and it gives risk teams a common language for comparing vendors and benchmarking against industry peers.
But hygiene ratings only answer part of the problem: How well is this vendor maintaining their defenses?
They don't tell you whether anyone is actively trying to breach those defenses. They don't surface the dark web chatter on a specific vendor. They don't alert you when a vendor's credentials are leaked or has an active malware infection. This is the gap that has left third-party risk programs perpetually reactive. Teams learn about vendor compromises from news headlines or from the vendors themselves — often days or weeks after the initial breach. By then, the window for proactive response may have closed.
From our own customer conversations, we hear that security and risk teams have shifted from wanting ratings and accuracy alone to demanding intelligence that reveals real cybersecurity risk, with prioritized findings and actionable remediation guidance. Ratings are increasingly commoditized. The differentiation now lies in what you do with the data, and what additional signals you bring to the table.
Third-Party Risk Management Is an Intelligence Operation
If you accept that ratings alone aren't enough, the logical next step is clear: third-party risk management must be treated as an intelligence operation.
That means combining the hygiene baseline — the outside-in view of a vendor's security posture — with real-time threat intelligence that tells you who is being targeted, how, and what you should do about it. It means shifting from periodic assessments to continuous monitoring. It means equipping risk teams with the context to distinguish between a low-priority configuration issue and a vendor whose infrastructure is actively under attack. This is the problem Recorded Future Third-Party Risk was built to solve.
We've brought together two distinct capabilities that, until now, existed in separate worlds.
RiskRecon — built over a decade as one of the industry's leading cyber risk ratings platforms, trusted by 21,500+ users across 30+ industries, provides the hygiene foundation: transparent, evidence-backed security ratings evaluated across 40+ criteria in 9 security domains, with 99% audited data accuracy.
Recorded Future's threat intelligence capabilities, powered by collection and analysis across more than 1 million sources, adds the threat dimension: real-time alerting on ransomware extortion activity, dark web exposures, credential leaks, and active vulnerability exploitation — often before the affected vendor is even aware.
Together, these capabilities create something the market hasn't had before: a single solution that covers the full lifecycle of third-party risk, from initial assessment and onboarding through continuous monitoring and incident response.
What This Looks Like in Practice
The value of combining hygiene ratings with threat intelligence isn't theoretical. Our customers are already seeing it play out.
When a vendor appears on a ransomware extortion site, Third-Party Risk customers can receive alerts in hours — not the days or weeks it takes for vendor self-disclosure.
When credentials associated with a monitored vendor surface on dark web markets, risk teams can initiate outreach and remediation before those credentials are weaponized.
When a critical vulnerability is disclosed, intelligence context helps analysts determine which vendors are actually exposed and at risk of exploitation, rather than treating every vendor with the affected software as equally urgent.
Customers consistently report a roughly 33% increase in visibility into third-party risks after adopting the platform (UserEvidence). Teams save an average of 7 hours per week that was previously spent on manual research and monitoring (UserEvidence). And customers routinely detect vendor incidents before the vendor itself has disclosed — turning what used to be a reactive scramble into a controlled, proactive response.
These aren't incremental improvements. They represent a fundamental shift from reactive compliance to proactive risk management.
Where We're Going
We're not done. Bringing RiskRecon and Recorded Future together was the first step in a broader vision for what third-party risk management should become.
Our roadmap is focused on deepening the integration between these two platforms into a unified experience. One where hygiene ratings, threat intelligence, and risk workflows operate seamlessly together. We're investing in AI-driven capabilities that will help risk analysts cut through noise faster, automate routine assessment workflows, and surface the insights that matter most. And we're building toward predictive intelligence that doesn't just tell you what's happening now, but helps you anticipate where risk is headed.
The goal is straightforward: make third-party risk management as data-driven, automated, and intelligence-led as the best security operations programs already are.
Join the Shift to Intelligence-Driven Third-Party Risk
Third-party risk programs that rely exclusively on hygiene ratings will continue to be caught off guard. The vendors who score well on a Tuesday can be breached by Wednesday. The questionnaire response you received last quarter may not reflect today's reality.
The organizations that are getting ahead of this are the ones treating third-party risk as what it actually is: an intelligence operation that requires continuous monitoring, real-time alerting, and the context to act decisively when something changes.
That's the future we're building. And we believe we're the only ones building it with the depth of intelligence and the strength of ratings data required to get it right.
November 20, 2025: Original publication date of this post. This post has been updated to reference the most recent version of the LZA Compliance Workbook published to AWS Artifact in March 2026.
We’re pleased to announce the availability of the latest sample security baseline from Landing Zone Accelerator on AWS (LZA)—the Universal Configuration. Developed from years of field experience with highly regulated customers including governments across the world, and in consultation with AWS Partners and industry experts, the Universal Configuration was built to help you implement security and compliance at scale for on your regulated workloads. By setting a high bar with the latest AWS security best practices, the Universal Configuration can help address technical control requirements from compliance frameworks across different geographic regions and industry verticals. The Universal Configuration’s multi-account security architecture provides a foundation to host your diverse workload requirements today along with providing the ability to explore the generative AI and agentic AI solutions that will shape your organization in the future. It can also replace months of complex planning and design by deploying a comprehensive security and compliance-driven environment based on AWS Well-Architected principles in a matter of hours.
As organizations grow, they typically pursue or must adhere to new security compliance certifications. LZA and the Universal Configuration help organizations of all sizes and phases in their security and compliance journey. The speed of deployment, step-by-step documentation, and compliance resources can reduce traditional assessment and authorization timelines by months and result in more predictable and successful audit outcomes. This enables more freedom to invest resources to grow the business instead of choosing between security and compliance tradeoffs.
The Universal Configuration helps organizations:
Automate the deployment of a secure multi-account AWS environment
Foundational security controls based on AWS Well-Architected best practices
Apply consistent and predictable security controls post-deployment
Enable and integrate with native AWS security, identity, and compliance services
Implement controls across system layers
Organization-wide security architecture
Perimeter and resource-specific preventative, proactive, and detective controls
Support for multi-AWS Region resilience, disaster recovery, and active failover
Establish a foundation for security and compliance readiness
Built-in AWS security best practices and technical implementation statements
Map LZA capabilities across global and industry-specific compliance frameworks
Deploy hundreds of controls hours instead of months
The LZA Compliance Workbook
The LZA engine has been a trusted tool for quickly deploying secure multi-account AWS environments for over 4 years. It is also cost effective because you pay only for the AWS services used to operate your environment. The Universal Configuration is the first sample configuration accompanied by the LZA Compliance Workbook available on AWS Artifact. It is a first-of-its-kind resource with detailed control mappings showing how the Universal Configuration can support different industries and regions, helping you address requirements from frameworks listed below.
NIST 800-53 Rev5
C5: 2020 (Germany)
HIPAA
SOC 2
CMMC Level 2
ISO/IEC 27001 Annex A
US Dept of War CCI
NERC-CIP
NIST 800-171
NATO D-32 Appendix B
NIST CSF 2.0
CIS Critical Controls v8
The LZA Compliance Workbook is regularly maintained to reflect the latest Universal Configuration baseline and will include additional compliance mappings in future releases. The workbook contains detailed security configuration descriptions based on the Universal Configuration deployment files, along with control requirement mappings and implementation statements that translate its security capabilities into a compliance-friendly format. By combining AWS security best practices with global compliance expertise, the Universal Configuration delivers predicable security outcomes while also helping you meet regional and industry requirements.
Getting started
To get started with the Landing Zone Accelerator on AWS Universal Configuration, the LZA Implementation Guide walks you through the steps, use cases, and considerations when deploying with LZA. You can download the LZA Compliance Workbook from AWS Artifact today and configure notifications to receive emails when future versions are released. You can view the deployment files and additional technical implementation guidance on the GitHub Universal Configuration sample and documentation page. Additionally, visit the AWS Partner Network (APN) for help with audit and advisory initiatives, cloud migrations, deploying the LZA Universal Configuration, and other services. You can visit the AWS Partner Finder tool and search by solution for Landing Zone Accelerator for the latest LZA Partner offerings.
If you have feedback about this post, submit comments in the Comments section below.
Recorded Future is the World’s Largest Intelligence Company. Our team works to build products that customers love. In this video, Kyle Kohler interviewed with VentureFizz about his day-to-day as a Senior Product Manager for Integrations. He describes the job as truly multifaceted, encompassing starting new strategic initiatives, turning customers feedback into improvements, and enabling other team members to do the same. Full video and transcript available below.
I’m Kyle Kohler. I’m a product manager over the integration strategy at Recorded Future.
Recorded Future is the world’s largest threat intelligence provider. We are covering all sorts of domains of intelligence. It’s geopolitical intelligence, cyber intelligence, payment fraud intelligence. And essentially intelligence is this data that an organization uses to take action and make a better decision. So the more that you understand a subject or topic, a current event, the better that you can define what actions you take to either defend your organization or proactively increase your competitive edge.
As a product manager, it’s funny. I see it as this arson firefighter educator role. And I think that definitely needs to be unpacked a bit. As an arson, you’re starting fires. So, very strategically, which fire do I put under which team, under which initiative, which fire do I stoke and one do I burn hotter? And as a firefighter, you’ve got maybe fires coming in being reported to you from a customer, from an organization, from another product team who needs this other product team to make something happen. And so, you’re very strategically figuring out what to stamp out, what to stoke. And as an educator, you’re also teaching others how to start fires and put out fires. So, you’re constantly going from one thing to the next and keeping all of these moving pieces going. There’s no one project that you just shepherd along and that’s the only thing you work on. You’re constantly context switching and a good product manager has that multi-domain knowledge to think laterally, but also track how this thing affects that thing and how it might affect the other thing in the future.
At Recorded Future, we’re a global organization and I’m based on the west coast of California. So I wake up in the morning and the first thing I’ve got are 10 to 12 Slack messages from across the globe that come in from different geographies. Other people are ending their day and they’ve got some questions that maybe I can answer or they’re looking for how to direct on who might have the right answer. So the first thing generally starts with voraciously checking Slack and I’m answering notifications as I mentioned questions and the next thing is okay well from the answers to those questions are there new initiatives that need to get spun up or are there existing initiatives that need to get nudged along or are there certain fires that need to get stamped out and that’s the whole day is you’re really tracking where things are in their current state what needs to get responded to and what needs to get pushed along.
Recorded Future really was attractive to me because it was a pretty new field within cyber security and within technology but also as a company was not just related to IT and cyber had this geopolitical and payment fraud type of angle looking at the world. So it was really taking a big data problem how do you track everything that happens everywhere but then how do you break that down into these bite-sized pieces that ultimately help an organization’s current mission. So I really was attracted by the fact that we are helping organizations secure the world. We’re able to do that by securing the world with intelligence, but it’s so multi-domain that you’re just never going to get bored. There’s always something new. There’s always something to track. There’s always some new threat. There’s always some new initiative, some new innovation. And Recorded Future has really been at that cutting edge of innovation. Always coming up with what’s next in the market, what’s next in the threat landscape and how will we as a company address supercharging the existing missions of our organizations that we help today.
Agentic AI represents a qualitative shift in how software operates. Traditional software executes deterministic instructions. Generative AI responds to human prompts with output that humans review and use at their discretion. Agentic AI differs from both. Agents connect to software tools and APIs and uses large language models (LLMs) as reasoning engines to plan and execute sequences of actions autonomously—at machine speed—with real-world consequences. This shift raises new questions for information security. In January 2026, NIST’s Center for AI Standards and Innovation (CAISI) issued a Request for Information (RFI) seeking industry input on how to secure these systems. AWS submitted a response grounded in our experience building and operating agentic AI services. This post summarizes the four security principles at the heart of that response and the architectural building blocks that implement them.
The NIST agentic AI RFI
CAISI asked developers, deployers, and security researchers to weigh in on how the industry should secure AI systems that act autonomously. The RFI posed questions across five areas. What unique security considerations do agentic systems introduce, and how do those considerations change as systems gain more autonomy? What practices improve security during development and deployment? How do organizations assess the security of their agentic systems? How can deployment environments be constrained and monitored? And where should the industry focus future research?
Why this matters
Even a conservative risk/benefit analysis will conclude that the benefits of agentic AI clearly outweigh the risks in many domains. The rapid adoption of agentic technology across business and government confirms this. But agents are valuable precisely because of their autonomy and adaptability, and these same characteristics create the security challenge. An agentic system that carries out an unintended action can do so at machine speed, before a human can intervene. Unlike human actors who pause or escalate when something seems unusual, agents might not inherently recognize ambiguities that are evident to humans, nor intuitively grasp unstated policy boundaries.
The good news, however, is that the security response to agentic AI doesn’t need to start from scratch. Existing security frameworks, including the NIST Cybersecurity Framework, NIST AI Risk Management Framework, and the Secure Software Development Framework, remain relevant and should be extended for agent-specific considerations rather than replaced. The most important extension is architectural. Our response to NIST identified four foundational security principles that address how to make that extension.
Four security principles for agentic AI
These principles build on the premise that agentic AI doesn’t require a new security paradigm, but it does require existing practices to evolve. The first two principles address what carries forward; the second two address what is genuinely new.
Principle 1: Secure development lifecycle practices apply across system components. Agentic AI systems combine traditional software components (APIs, databases, orchestration logic) with AI elements such as foundation models, prompt templates, and retrieval pipelines. A secure development lifecycle must cover both sets of components. For traditional components, established practices such as code review, static analysis, dependency scanning, and threat modeling remain essential, keeping in mind that those practices are also in the process of being enhanced with AI-based tooling. For AI components, the challenge is different. Foundation models are probabilistic, which means traditional regression testing is necessary but not sufficient. Organizations must supplement it with behavioral testing, adversarial evaluation, and continuous monitoring to validate that AI components operate within expected parameters.
Regular re-evaluation is equally important for addressing behavioral drift. Models receive updates that can alter behavior. Prompt templates evolve as teams refine agent capabilities. New tools and data sources expand the agent’s operational surface. Each change can introduce new failure modes or potential security issues. Organizations must treat evaluation as an ongoing operational practice, not a one-time gate. This includes automated testing after model updates, red team exercises against deployed agents, and monitoring that detects behavioral drift over time.
Principle 2: Traditional security controls remain fully applicable. Agentic AI introduces new considerations, but it doesn’t render existing security risks obsolete. The full complement of traditional security controls still applies. An agentic AI system combines traditional software with the new LLM-plus-tools processing loop. Organizations must secure existing software, tools, and configurations against well-known risks to provide a sound foundation for the agentic elements.
Privilege escalation, confused deputy issues, session hijacking, code injection, and supply chain risks extend directly into agentic systems. Some of these risks increase in agentic contexts. Agents operate at greater scale and speed than human actors, which means excessive privileges carry more potential for unintended consequences. That means that applying principles of least privilege to access management in an agentic context is as important—if not more so—than in traditional systems. The supply chain surface is also broader. Agentic systems consume not only third-party code dependencies but also foundation models, plugins, tool servers, and data retrieval sources. Agents that invoke APIs, query databases, or generate code create new potential injection surfaces at tool boundaries. AI-specific controls must be additions to this foundational security, not replacements for it.
Principle 3: Deterministic external controls are the starting point for agentic security. This is the most important architectural principle for agentic AI security. Organizations should enforce security through deterministic, infrastructure-level controls external to the agent’s reasoning loop, not through the agent’s own reasoning, internal guardrails, or prompt-based instructions. The logic is straightforward. LLMs are probabilistic reasoning engines, not security enforcement mechanisms. Developers can instruct an LLM to refuse certain requests, but prompt injection techniques can override those instructions. An LLM can be told to respect access boundaries, but it has no reliable mechanism to enforce them. Attempting to constrain agent behavior only through prompting or alignment runs against the fundamental value proposition of agents, which is their ability to adapt dynamically to novel situations.
Effective security places fully specified, deterministic controls outside the agent that govern which tools it can access, what operations it can perform, and what data it can reach. Model manipulation cannot bypass these controls. We describe this as the security box. It’s external to the agent, deterministic in its enforcement, and comprehensive in its coverage. Every interaction between the agent and the outside world passes through it. The Agentic AI Security Scoping Matrix helps organizations calibrate the rigor of these controls based on their system’s autonomy level. Scopes range from systems that require explicit human approval before every action to fully autonomous systems that initiate their own activities based on external events.
The security box isn’t a limitation on the agent’s value. It’s the precondition for achieving that value responsibly. As agentic technology matures, the box itself will likely evolve to include agentic elements. Specialized AI agents designed to control the scope of other agents might replace some deterministic constraints over time, using new information and context to make more appropriate automated decisions than could be achieved by humans managing complex deterministic controls.
Principle 4: Greater autonomy should be earned through ongoing evaluation. Organizations should expand agent autonomy progressively based on demonstrated performance, not grant it by default. The starting point is human decision-making for high-consequence operations. When an agent encounters an action that could modify high-value production data, initiate financial transactions, or communicate sensitive information externally, a human makes the final decision. The agent recommends, and a human approves or rejects.
This approach carries a well-known risk. If every agent action requires human approval, the volume of decisions might overwhelm reviewers. Approval becomes reflexive rather than deliberate, shifting liability to humans who have been placed in a position to fail. Organizations must scope human oversight to genuinely high-consequence operations and resist the temptation to require human-in-the-loop designs for routine actions that carry low risk.
The path from human oversight to expanded autonomy runs through evaluation. As organizations systematically record what the agent recommended, what the human decided, and what actually happened, they build the evidence base for expanding autonomy. When data shows sustained alignment, organizations can shift from prior approval to after-the-fact review, and eventually to full autonomy for specific operation types. This progression should happen at the operation or workflow level, not across a broad range of unrelated tasks.
This progression isn’t one-way. Organizations should be prepared to reintroduce human oversight when evidence warrants it. Some deterministic boundaries likely remain permanent for the foreseeable future. These boundaries exist not because the agent hasn’t earned trust, but because the consequences of certain actions are unacceptable under a reasonable risk analysis. The overall model is one of earned autonomy through demonstrated competence, governed by evaluation, bounded by permanent constraints, and subject to continuous review. There might come a time with specialized boundary agents can provide better outcomes than purely deterministic controls, but that option can only emerge over time from experience and evaluation.
From principles to practice
The four principles define the goals. Achieving them requires specific architectural building blocks that compose the security box and the broader security architecture. Our response to NIST described these building blocks in greater detail. Here we provide a summary. AWS has implemented them in Amazon Bedrock AgentCore, a framework for building, deploying, and operating agentic AI systems with security built in from the ground up.
Compute isolation. Agent compute environments must isolate execution, prevent cross-agent data leakage, and contain agents within defined boundaries. Amazon Bedrock AgentCore runs agents on Firecracker, an open source virtual machine manager written in Rust. Firecracker provides lightweight micro-VMs backed by Linux KVM and hardware-based virtualization, delivering the speed of containers with the isolation properties of full virtual machines. Key security-critical elements of Firecracker have been formally verified by AWS teams, adding assurance beyond the memory safety that Rust provides.
Identity and access management. Agents require their own identities, secure credential storage, and least-privilege authorization enforced at the infrastructure level. AgentCore Identity provides machine identities for agents, manages OAuth and secure credential flows, and integrates with AWS Identity and Access Management (IAM) for fine-grained access control. It supports attribute-based access control and maintains traceable delegation chains so that the relationship between agent actions and the invoking user remains auditable.
Tool access and policy enforcement. Every tool an agent can access expands both its usefulness and its potential risk. Managing tool access individually across agents creates an unmanageable combinatorial explosion. AgentCore Gateway acts as a centralized intermediary between agents and tools, enforcing authentication and authorization at a single control point. It can inspect tool calls down to individual parameters, not just at the API level. AgentCore Policy, built on the open source Cedar authorization language, adds formally verified policy enforcement. Teams can author Cedar policies in natural language and then review them, combining the flexibility of LLMs with the rigor of formal methods.
Observability. Observability infrastructure must capture sufficient context for real-time monitoring and investigation, and it must be protected from the agents it monitors. Organizations wouldn’t allow employees to edit their own audit logs, and the same principle applies to agents. AgentCore provides observability through the AgentCore Gateway, session-level telemetry, and detailed traces that record internal state changes. These capabilities can extend to agents running outside of AgentCore as well.
Model execution environment. The security of the model execution environment matters as much as the security of the agent itself. Amazon Bedrock runs models in isolated network environments where neither AWS nor model providers access customer prompts and responses. When customers enable logging, those logs are encrypted at rest and protected by customer-managed encryption keys. This architectural isolation is a key reason government and enterprise customers have adopted Amazon Bedrock.
Deterministic external controls are complemented by controls within the AI processing loop. Amazon Bedrock Guardrails inspects prompts and responses using small AI models called classifiers that address challenges such as prompt injection. Automated Reasoning checks go further, so that developers can create a formal model of a knowledge domain and verify that LLM output conforms to it, producing results that are deterministic and provably correct.
Looking ahead
Agentic AI changes how software operates, but the security response builds on decades of established practice. Existing frameworks provide the right foundation. The task is to extend existing frameworks for agent-specific considerations. Organizations should apply secure development lifecycle practices to AI components and maintain traditional security controls. They should enforce security through deterministic controls external to the agent and earn greater autonomy through systematic evaluation.
These principles aren’t theoretical. They reflect the operational experience AWS has gained building and operating agentic AI services. They’re embedded in how we design our infrastructure. As NIST develops guidance based on industry input, we will continue to invest in helping customers build and operate agentic AI systems with confidence.
Payment fraud no longer operates as a collection of discrete schemes run by individual threat actors.
It is increasingly sustained by an industrial support ecosystem: purpose-built infrastructure, packaged toolkits, and professionalized services that allow threat actors to maximize fraud output while minimizing the skill and effort required to execute attacks.
According to Recorded Future's Annual Payment Fraud Intelligence Report: 2025, this industrialization was driven by technical advances and increasingly professionalized support services.
The Magecart e-skimmer supply chain is the clearest example. Full-stack e-skimmer kits and Malware-as-a-Service (MaaS) offerings have made large-scale compromise of ecommerce websites accessible to less technically capable threat actors.
The "Sniffer by Fleras" kit, responsible for 26% of all e-skimmer infections observed in 2025, includes a web-based portal for generating malicious scripts and a management server for stolen data. The result was more than 10,500 unique Magecart infections active at some point during the year, likely compromising more than 23 million transactions.
Additionally, the "AcceptCar" e-skimmer, discovered in H2 2025, illustrates how far the service model has matured. Operators handle installation and operation on compromised e-commerce sites; in return, threat actors pay 50% of proceeds from card data sales or 70% of raw data intake. Using services like AcceptCar, fraud threat actors can participate in large-scale compromise operations without owning or managing any underlying infrastructure.
Figure 1: Line graph showing Magecart e-skimmer infections in 2025, by different groups, kits, and techniques. (Source: Recorded Future)
Recurring patterns in merchant registration data indicate that scam operators have standardized their merchant acquisition workflows, standing up fraudulent payment infrastructure at scale through repeatable, low-friction processes.
Card testing operates on the same service-economy logic. Telegram-based card testing services validated at least 27 million card records in 2025 through public-facing card generation and testing channels that any threat actor can access.
Among dark web checker services, over 1,350 legitimate merchant accounts were abused for card testing, with 94% not observed prior to 2025, suggesting systematic rotation to stay ahead of detection.
Figure 2: Graphic illustrating the purchase scam attack chain. (Source: Recorded Future)
The Ecosystem Is Concentrated Upstream
Notably, each of these industrialized attack vectors sits upstream of the fraudulent transaction. E-skimmer infections and scam merchants compromise card data during online purchases. Card testing validates that stolen data before it’s monetized.
Fraud outcomes are visible, but the pathways that enable them are often not.
"Fraud outcomes are visible, but the pathways that enable them are often not."
This industrialized scale across these attack vectors requires standardization, and standardization produces detectable patterns.
When 26% of e-skimmer infections trace back to a single kit, when scam operators reuse merchant registration patterns across hundreds of acquirers, when card testers rotate through predictable BIN attack workflows, the convergence that makes fraud scalable also makes it mappable. As that standardization deepens, a single indicator of compromise reaches further across the threat landscape.
That standardization creates something concrete: a window.
Magecart infections are active and identifiable before stolen card data is harvested. Scam merchants often display detectable signals, including recent domain registration, merchant rotation, and merchant category code mismatches.
Card testing activity reveals when a monetization attempt is likely to occur.
Each stage represents an opportunity to act before fraud registers as a financial loss.
Transaction Monitoring Looks at the Wrong End of the Lifecycle
Transaction monitoring and behavioral fraud models are built to detect anomalies at the point of payment, like unusual spend patterns, velocity, and geographic inconsistencies. They do what they were designed to, but provide no visibility into the increasingly industrialized, pre-monetization stages that were built to avoid detection by these traditional processes.
Purchase scams are explicitly designed to circumvent transaction-based controls by manipulating cardholders into authorizing the fraudulent transaction themselves, making the payment appear legitimate by design.
Card testers cycle through new merchants specifically because historical tester merchants get flagged (94% of tester merchants identified in 2025 were not previously observed). A detection approach built around transaction signals will always be working with information that arrives after the upstream infrastructure has already done its job.
As the upstream ecosystem industrializes, the volume of activity that transaction monitoring cannot see has grown. With purchase scam detections more than quadrupling year-over-year and Magecart infections having likely compromised more than 23 million transactions in 2025 alone, the cost of that blind spot compounds.
Maintaining an effective fraud posture will increasingly require financial institutions to complement reactive account monitoring with proactive, intelligence-informed defenses.
How Recorded Future Payment Fraud Intelligence Addresses This
With daily monitoring of Magecart-infected sites and enriched merchant data that integrates with transaction monitoring, Payment Fraud Intelligence can enable detection of high-risk merchants months before stolen card data appears for sale.
Additionally, the Scam Merchants dataset can identify fraudulent merchant accounts and their associated domains before customers are defrauded and before downstream card data reaches criminal markets.
Tester merchant monitoring surfaces card testing activity as an early signal of which portfolios are being targeted ahead of any monetization attempt.
Because Payment Fraud Intelligence monitors the sources, kits, and infrastructure that threat actors have increasingly standardized around, a single identified indicator can surface exposure across a portfolio at scale.
According to Recorded Future data, 75% of compromised cards are identified before fraud occurs, and 90% of compromised card assets are identified within hours of a breach.
The pre-monetization window will not narrow as the fraud ecosystem matures — if anything, the report's data suggests it will widen as standardization deepens. Financial institutions with visibility into that window can act before losses occur. Those without it will continue to respond after the fact.
The expanding conflict around Iran signals a deeper shift. We have entered an era of quantum geopolitics, where the old rules of the international order no longer apply. What began as a regional confrontation is already reshaping global markets, supply chains, and corporate security planning. Leaders must adapt how they think, spend, and communicate in a system where uncertainty is not a risk to manage—it is the operating environment itself.
What is Quantum Geopolitics?
A useful analogy comes from physics.
Classical systems produce predictable outcomes. Quantum systems behave probabilistically, where interactions in one place can produce distant effects.
International politics increasingly resembles the latter.
The assumptions that shaped corporate strategy for decades—durable alliances, expanding globalization, and broadly coherent regulation—are weakening. Geopolitical shocks now move rapidly through tightly interconnected systems.
Four dynamics define how this system now behaves.
🌓 Superposition: Friends, Rivals, and Everything in Between
Countries can no longer be neatly categorised “ally” or “adversary.” They exist in overlapping states, with true alignment revealed only in moments of crisis.
States balance security partnerships with the West while maintaining economic ties with rivals. Turkey supports Ukraine diplomatically while sustaining trade flows that benefit Russia. India deepens defence ties with the United States even as it increases purchases of Russian oil.
Public statements offer limited guidance. Trade flows, enforcement patterns, and technology controls are more reliable indicators of intent.
For multinational firms, geopolitical positioning is no longer fixed. It is fluid.
🌀 The End of Guarantees: Promises Now Come with Caveats
Security commitments, trade access, and regulatory stability have shifted from certainties to probabilities.
Export controls can reroute supply chains within months. Sanctions regimes expand or unwind quickly. Even long-standing alliances depend on political will at the moment they are tested.
For businesses, this means long-term investments now carry elevated policy risk.
Leaders must plan for variance.
🧬 Quantum Entanglement: Local Conflicts Are Not Local
Global systems—financial, technological, logistical—are tightly coupled. Regional conflicts now generate immediate global effects.
Threats to Gulf commercial hubs disrupt international banking. Instability in the Strait of Hormuz drives energy price volatility and strains global shipping insurance. Cyber campaigns tied to the conflict target companies far beyond the region.
Disruption is rarely contained. Risk can no longer be managed by geography or function alone.
🔬 The Observer Effect: Whoever Sets the Rules First Wins
Influence increasingly derives from shaping rules rather than operating within them.
States that move early to establish standards in artificial intelligence, semiconductors, digital infrastructure, and financial regulation compel others to adapt.
Waiting for clarity can therefore be a strategic liability in itself. If you do not shape the agenda, you become subject to it.
Why This Moment Feels Different
These dynamics are most visible in cyberspace, where geopolitical competition unfolds continuously below the threshold of open conflict.
State-sponsored actors operate inside corporate networks without triggering overt confrontation. Criminal groups, proxies, and intelligence services overlap, complicating attribution and response.
The boundary between geopolitical conflict and corporate exposure is now thin. A single breach can trigger regulatory scrutiny, customer loss, market volatility, and diplomatic tension at once.
Cybersecurity is no longer a technical function. It is a core enterprise risk.
How Security Leaders Should Respond
In a system governed by probabilities rather than predictability, security leaders must adapt how they think, allocate resources, and position their organizations.
1. Mindset Shift: Scenarios, Not Forecasts
Replace long planning horizons and static risk assessments with continuous scenario planning. Tools such as the Cone of Plausibility can stress-test responses to sanctions escalation, maritime disruption, regulatory fragmentation, or supply chain shocks.
Evaluate decision speed, cross-functional coordination, and response thresholds under pressure. Adaptability matters more than accuracy.
2. Spending Shift: Invest in Resilience, Not Just Efficiency
Systems optimized solely for efficiency often lack resilience.
Diversifying suppliers, strengthening sanctions compliance, improving cybersecurity, and increasing visibility into third-party exposure can reduce vulnerability to geopolitical shocks.
Resilience is not a defensive expense; it is operational insurance.
3. Communication Shift: From Reporting to Action
Security leaders must translate geopolitical developments into clear decision frameworks before crises materialize.
This requires close coordination across legal, finance, and operations, as well as proactive engagement with regulators and industry partners.
Speed and clarity determine whether the organization shapes outcomes or reacts to them.
Final Thoughts
The Iran conflict offers a preview of what comes next. Alliances are conditional. Economic pressure, cyber activity, and regulatory responses unfold simultaneously.
Quantum geopolitics does not eliminate strategy. It demands a different kind—one built on scenario readiness, structural resilience, and faster decision cycles.
Leaders who wait for clarity will move too late.
Those who organize for uncertainty will operate ahead of it.
To access the latest InsiktGroup®researchclick here.
Insikt Group®helps Recorded Future secure our world with threat intelligence. With deep experience in government, law enforcement, military, and intelligence agencies, we power the Recorded Future Platform with analyst-validated data, analytics, along with cyber and geopolitical intelligence. This enables our customers to reduce risk and prevent disruption.
We’re excited to announce the release of our latest compliance guide, ISO/IEC 27001:2022 on AWS, which provides practical guidance for organizations designing and operating an Information Security Management System (ISMS) using AWS services.
As organizations migrate critical workloads to the cloud, aligning with globally recognized standards such as ISO/IEC 27001:2022 becomes an important step toward strengthening governance, risk management, and information security practices. This guide helps cloud architects, security teams, compliance leaders, and DevOps practitioners understand how to implement and operate ISO 27001-aligned controls using AWS services while applying the AWS Shared Responsibility Model.
The guide explains how organizations can integrate AWS services into their ISMS to support the requirements defined in ISO 27001:2022 clauses 4–10 and selected Annex A controls. It also highlights how AWS security, monitoring, and automation capabilities can help customers maintain visibility, improve operational consistency, and prepare audit-ready evidence.
While AWS provides a secure and compliant cloud infrastructure, customers remain responsible for defining their ISMS scope, implementing controls, and demonstrating conformity during certification audits.
Inside the guide:
Overview of the ISO/IEC 27001:2022 framework, including ISMS clauses 4–10 and the Annex A control
Mapping of selected ISO 27001:2022 Annex A controls to AWS services and architectural capabilities
Guidance for implementing complementary customer controls within AWS environments
Recommendations for evidence collection, documentation, and audit readiness using AWS native tooling
Governance and risk management considerations for organizations establishing an ISMS on AWS
Best practices for operationalizing compliance activities through automation and infrastructure-as-code.
By combining ISO 27001 best practices with AWS security services, organizations can build scalable environments that support continuous security improvement, operational visibility, and certification readiness.
June 3, 2022: Original publication date of this post. This post has been updated to add the additional IAM policy types: Resource control policies.
You manage access in AWS by creating policies and attaching them to AWS Identity and Access Management (IAM) principals (roles, users, or groups of users) or AWS resources. AWS evaluates these policies when an IAM principal makes a request, such as uploading an object to an Amazon Simple Storage Service (Amazon S3) bucket. Permissions in the policies determine whether the request is allowed or denied. While IAM operates primarily at the individual AWS account level, organizations with multiple AWS accounts can extend these access controls through AWS Organizations, which provides additional policy types that work alongside IAM to enforce governance and security standards across their entire organizational structure. By using AWS Organizations, you can group accounts in the multi-account environment into organizational units (OUs), apply policy-based controls across these groups.
In this blog post, you will learn how to select the appropriate policy types for your security requirements and determine which team should own and manage each policy. You will explore seven policy types—including identity-based policies, resource-based policies, permissions boundaries, service control policies (SCPs), and resource control policies (RCPs)—through a practical scenario involving multiple AWS accounts and teams.
Different policy types and when to use them
AWS has different policy types that provide you with powerful flexibility, and it’s important to know how and when to use each policy type. It’s also important for you to understand how to structure your IAM policy ownership to avoid a centralized team from becoming a bottleneck. Explicit policy ownership can allow your teams to move more quickly, while staying within the secure guardrails that are defined centrally.
Service control policies overview
Service control policies (SCPs) are a feature of AWS Organizations. AWS Organizations is a service for grouping and centrally managing the AWS accounts that your business owns. SCPs are policies that specify the maximum permissions for an organization, organizational unit (OU), or an individual account. An SCP can limit permissions for principals in member accounts, including the AWS account root user.
Resource control policies (RCPs) are an AWS Organizations feature to manage permissions centrally. RCPs set the maximum available permissions for resources across your organization. RCPs help ensure that resources in your accounts stay within your organization’s access control guidelines.
RCPs are typically used to enforce data perimeter controls to prevent accidental data sharing outside your organization and to control resource sharing and cross-account access patterns centrally. You can also use RCPs to implement security controls for sensitive resources across your organization’s accounts and to add an additional layer of protection for resources such as S3 buckets that store confidential data.
Note: SCPs are principal-centric controls that specify which services your IAM users and IAM roles can access, which resources they can access, or the conditions under which they can make requests (for example, from specific Regions or networks). On the other hand, RCPs are resource-centric controls that can restrict access to your resources so that they can be accessed only by identities that belong to your organization or specify the conditions under which identities external to your organization can access your resources. To understand SCPs and RCPs differences and use cases, see General use cases for SCPs and RCPs.
Permissions boundaries overview
Permissions boundaries are an advanced IAM feature in which you set the maximum permissions that an identity-based policy can grant to an IAM principal. When you set a permissions boundary for a principal, the principal can perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.
A permissions boundary is a type of identity-based policy that doesn’t directly grant access. Instead, like an SCP, a permissions boundary acts as a guardrail for your IAM principals that allows you to set coarse-grained access controls. A permissions boundary is typically used to delegate the creation of IAM principals. Delegation enables other individuals in your accounts to create new IAM principals, but limits the permissions that can be granted to the new IAM principals.
Identity-based policies overview
Identity-based policies are policy documents that you attach to a principal (roles, users, and groups of users) to control what actions a principal can perform, on which resources, and under what conditions. Identity-based policies can be further categorized into AWS managed policies, customer managed policies, and inline policies. AWS managed policies are reusable identity-based policies that are created and managed by AWS. You can use AWS managed policies as a starting point for building your own identity-based policies that are specific to your organization. Customer managed policies are reusable identity-based policies that can be attached to multiple identities. Customer managed policies are useful when you have multiple principals with identical access requirements. Inline policies are identity-based policies that are attached to a single principal. Use inline-policies when you want to create least-privilege permissions that are specific to a particular principal.
You will have many identity-based policies in your AWS account that are used to enable access in scenarios such as human access, application access, machine learning workloads, and deployment pipelines. These policies should be fine-grained. You use these policies to directly apply least privilege permissions to your IAM principals. You should write the policies with permissions for the specific task that the principal needs to accomplish.
Resource-based policies overview
Resource-based policies are policy documents that you attach to a resource such as an S3 bucket. These policies grant the specified principal permission to perform specific actions on that resource and define under what conditions this permission applies. Resource-based policies are inline policies. For a list of AWS services that support resource-based policies, see AWS services that work with IAM.
Resource-based policies are optional for many workloads that don’t span multiple AWS accounts. Fine-grained access within a single AWS account is typically granted with identity-based policies. AWS Key Management Service (AWS KMS)keys and IAM role trust policies are two exceptions, and both of these resources must have a resource-based policy even when the principal and the KMS key or IAM role are in the same account. IAM roles and KMS keys behave this way as an extra layer of protection that requires the owner of the resource (key or role) to explicitly allow or deny principals from using the resource. For other resources that support resource-based policies, here are some examples where they are most commonly used:
Applying an additional layer of protection for resources that store sensitive data, such as AWS Secrets Manager secrets or an S3 bucket with sensitive data. You can use a resource-based policy to deny access to IAM principals that shouldn’t have access to sensitive data, even if granted access by an identity-based policy. An explicit deny in an IAM policy always overrides an allow.
How to implement different policy types
In this section, we will walk you through an example of a design that includes all four of the policy types explained in this post.
The example that follows shows an application that runs on an Amazon Elastic Compute Cloud (Amazon EC2) instance and needs to read from and write files to an S3 bucket in the same account. The application also reads (but doesn’t write) files from an S3 bucket in a different account. The company in this example, Example Corp, uses a multi-account strategy, and each application has its own AWS account. The architecture of the application is shown in Figure 1.
Figure 1: Sample application architecture that needs to access S3 buckets in two different AWS accounts
There are three teams that participate in this example: the Central Cloud Team, the Application Team, and the Data Lake Team. The Central Cloud Team is responsible for the overall security and governance of the AWS environment across all AWS accounts at Example Corp. The Application Team is responsible for building, deploying, and running their application within the application account (111111111111) that they own and manage. Likewise, the Data Lake Team owns and manages the data lake account (222222222222) that hosts a data lake at Example Corp.
With that background in mind, we will walk you through an implementation for each of the four policy types and include an explanation of which team we recommend own each policy. The policy owner is the team that is responsible for creating and maintaining the policy.
Service control policies
The Central Cloud Team owns the implementation of the security controls that should apply broadly to all of Example Corp’s AWS accounts. At Example Corp, the Central Cloud Team has two security requirements that they want to apply to all accounts in their organization:
AWS API calls should be encrypted in transit to maintain security best practices
Accounts can’t leave the organization on their own.
The Central Cloud Team chooses to implement these security invariants using SCPs and applies the SCPs to the root of the organization. The first statement in Policy 1 denies all requests that are not sent using SSL (TLS). The second statement in Policy 1 prevents an account from leaving the organization.
This is only a subset of the SCP statements that Example Corp uses. Example Corp uses a deny list strategy, and there must also be an accompanying statement with an Effect of Allow at every level of the organization that isn’t shown in the SCP in Policy 1.
Policy 1: SCP attached to AWS Organizations organization root
Deny S3 access from AWS account outside the organization managed by AWS Organizations
The Central Cloud Team attaches the RCPs to the root of the organization, following the same approach used for SCPs, so that the policy applies across all accounts. Policy 2 enforces three controls across S3 buckets in the organization. The first statement requires TLS 1.2 for data-in-transit. The second statement requires AWS KMS encryption for data-at-rest. The third statement restricts S3 bucket access to principals from accounts within the organization (identified by example-corp-organization-id), blocking access from external accounts.
Policy 2: RCP attached to the organization root to enforce data perimeter
The Central Cloud Team wants to make sure that they don’t become a bottleneck for the Application Team. They want to allow the Application Team to deploy their own IAM principals and policies for their applications. The Central Cloud Team also wants to make sure that any principals created by the Application Team can only use AWS APIs that the Central Cloud Team has approved.
At Example Corp, the Application Team deploys to their production AWS environment through a continuous integration/continuous deployment (CI/CD) pipeline. The pipeline itself has broad access to create AWS resources needed to run applications, including permissions to create additional IAM roles. The Central Cloud Team implements a control that requires that all IAM roles created by the pipeline must have a permissions boundary attached. This allows the pipeline to create additional IAM roles, but limits the permissions that the newly created roles can have to what is allowed by the permissions boundary. This delegation strikes a balance for the Central Cloud Team. They can avoid becoming a bottleneck to the Application Team by allowing the Application Team to create their own IAM roles and policies, while ensuring that those IAM roles and policies are not overly privileged.
An example of the permissions boundary policy that the Central Cloud Team attaches to IAM roles created by the CI/CD pipeline is shown below. This same permissions boundary policy can be centrally managed and attached to IAM roles created by other pipelines at Example Corp. The policy describes the maximum possible permissions that additional roles created by the Application Team are allowed to have, and it limits those permissions to some Amazon S3 and Amazon Simple Queue Service (Amazon SQS) data access actions. It’s common for a permissions boundary policy to include data access actions when used to delegate role creation. This is because most applications only need permissions to read and write data (for example, writing an object to an S3 bucket or reading a message from an SQS queue) and only sometimes need permission to modify infrastructure (for example, creating an S3 bucket or deleting an SQS queue). As Example Corp adopts additional AWS services, the Central Cloud Team updates this permissions boundary with actions from those services.
Policy 3: Permissions boundary policy attached to IAM roles created by the CI/CD pipeline
In the next section, you will learn how to enforce that this permissions boundary is attached to IAM roles created by your CI/CD pipeline.
Identity-based policies
In this example, teams at Example Corp are only allowed to modify the production AWS environment through their CI/CD pipeline. Write access to the production environment is not allowed otherwise. To support the different personas that need to have access to an application account in Example Corp, three baseline IAM roles with identity-based policies are created in the application accounts:
A role for the CI/CD pipeline to use to deploy application resources.
A read-only role for the Central Cloud Team, with a process for temporary elevated access.
A read-only role for members of the Application Team.
All three of these baseline roles are owned, managed, and deployed by the Central Cloud Team.
The Central Cloud Team is given a default read-only role (CentralCloudTeamReadonlyRole) that allows read access to all resources within the account. This is accomplished by attaching the AWS managed ReadOnlyAccess policy to the Central Cloud Team role. You can use the IAM console to attach the ReadOnlyAccess policy, which grants read-only access to all services. When a member of the team needs to perform an action that is not covered by this policy, they follow a temporary elevated access process to make sure that this access is valid and recorded.
A read-only role is also given to developers in the Application Team (DeveloperReadOnlyRole) for analysis and troubleshooting. At Example Corp, developers are allowed to have read-only access to Amazon EC2, Amazon S3, Amazon SQS, AWS CloudFormation, and Amazon CloudWatch. Your requirements for read-only access might differ. Several AWS services offer their own read-only managed policies, and there is also the previously mentioned AWS managed ReadOnlyAccess policy that grants read only access to all services. To customize read-only access in an identity-based policy, you can use the AWS managed policies as a starting point and limit the actions to the services that your organization uses. The customized identity-based policy for Example Corp’s DeveloperReadOnlyRole role is shown below.
Policy 4: Identity-based policy attached to a developer read-only role to support human access and troubleshooting
The CI/CD pipeline role has broad access to the account to create resources. Access to deploy through the CI/CD pipeline should be tightly controlled and monitored. The CI/CD pipeline is allowed to create new IAM roles for use with the application, but those roles are limited to only the actions allowed by the previously discussed permissions boundary. The roles, policies, and EC2 instance profiles that the pipeline creates should also be restricted to specific role paths. This enables you to enforce that the pipeline can only modify roles and policies or pass roles that it has created. This helps prevent the pipeline, and roles created by the pipeline, from elevating privileges by modifying or passing a more privileged role. Pay careful attention to the role and policy paths in the Resource element of the following CI/CD pipeline role policy (Policy 5). The CI/CD pipeline role policy also provides some example statements that allow the passing and creation of a limited set of service-linked roles (which are created in the path /aws-service-role/). You can add other service-linked roles to these statements as your organization adopts additional AWS services.
Policy 5: Identity-based policy attached to CI/CD pipeline role
In addition to the three baseline roles with identity-based policies in place that you’ve seen so far, there’s one additional IAM role that the Application Team creates using the CI/CD pipeline. This is the role that the application running on the EC2 instance will use to get and put objects from the S3 buckets in Figure 1. Explicit ownership allows the Application Team to create this identity-based policy that fits their needs without having to wait and depend on the Central Cloud Team. Because the CI/CD pipeline can only create roles that have the permissions boundary policy attached, Policy 6 cannot grant more access than the permissions boundary policy allows (Policy 3).
If you compare the identity-based policy attached to the EC2 instance’s role (Policy 6 on left) with the permissions boundary policy described previously (Policy 3 on the right), you can see that the actions allowed by the EC2 instance’s role are also allowed by the permissions boundary policy. Actions must be allowed by both policies for the EC2 instance to perform the s3:GetObject and s3:PutObject actions. Access to create a bucket would be denied even if the role attached to the EC2 instance was given permission to perform the s3:CreateBucket action because the s3:CreateBucket action exceeds the permissions allowed by the permissions boundary.
Policy 6: Identity-based policy bound by permissions boundary and attached to the application’s EC2 instance
Resource-based policies The only resource-based policy needed in this example is attached to the bucket in the account external to the application account (DOC-EXAMPLE-BUCKET2 in the data lake account in Figure 1). Both the identity-based policy and resource-based policy must grant access to an action on the S3 bucket for access to be allowed in a cross-account scenario. The bucket policy below only allows the GetObject action to be performed on the bucket, regardless of what permissions the application’s role (ApplicationRole) is granted from its identity-based policy (Policy 6).
This resource-based policy is owned by the Data Lake Team that owns and manages the data lake account (222222222222) and the policy (Policy 7). This allows the Data Lake Team to have complete control over what teams external to their AWS account can access their S3 bucket.
Policy 7: Resource-based policy attached to S3 bucket in external data lake account (222222222222)
No resource-based policy is needed on the S3 bucket in the application account (DOC-EXAMPLE-BUCKET1 in Figure 1). Access for the application is granted to the S3 bucket in the application account by the identity-based policy. Access can be granted by either an identity-based policy or a resource-based policy when access is within the same AWS account.
Putting it all together
Figure 2 shows the architecture and includes the different policies and the resources they are attached to. The table that follows summarizes the various IAM policies that are deployed to the Example Corp AWS environment, and specifies what team is responsible for each of the policies.
Figure 2: Sample application architecture with CI/CD pipeline used to deploy infrastructure
The numbered policies in Figure 2 correspond to the policy numbers in the following table.
Policy number
Policy description
Policy type
Policy owner
Attached to
1
Enforce SSL and prevent member accounts from leaving the organization for all principals in the organization
Service control policy (SCP)
Central Cloud Team
Organization root
2
Enforce TLS 1.2 and KMS encryption for S3 buckets across the organization
Resource control policy (RCP)
Central Cloud Team
Organization root
3
Restrict maximum permissions for roles created by CI/CD pipeline
Permissions boundary
Central Cloud Team
All roles created by the pipeline (ApplicationRole)
4
Scoped read-only policy
Identity-based policy
Central Cloud Team
IAM role
5
CI/CD pipeline policy
Identity-based policy
Central Cloud Team
IAM role
6
Policy used by running application to read and write to S3 buckets
Identity-based policy
Application Team
on EC2 instance
7
Bucket policy in data lake account that grants access to a role in application account
Resource-based policy
Data Lake Team
S3 Bucket in data lake account
8
Broad read-only policy
Identity-based policy
Central Cloud Team
IAM role
Conclusion In this blog post, you learned about four different policy types: identity-based policies, resource-based policies, service control policies (SCPs), resource control polices (RCPs), permissions boundary policies, and resource control policies. You saw examples of situations where each policy type is commonly applied. Then, you walked through a real-life example that describes an implementation that uses these policy types.
By implementing multiple IAM policy types in a layered approach, you can achieve robust access control that follows the principle of least privilege while enabling team autonomy. This defense-in-depth strategy helps prevent unauthorized access through multiple policy evaluation checkpoints.
You can use this blog post as a starting point for developing your organization’s IAM strategy. You might decide that you don’t need all of the policy types explained in this post, and that’s OK. Not every organization needs to use every policy type. You might need to implement policies differently in a production environment than a sandbox environment. The important concepts to take away from this post are the situations where each policy type is applicable, and the importance of explicit policy ownership. We also recommend taking advantage of policy validation in AWS IAM Access Analyzer when writing IAM policies to validate your policies against IAM policy grammar and best practices.
Amazon threat intelligence has identified an active Interlock ransomware campaign exploiting CVE-2026-20131, a critical vulnerability in Cisco Secure Firewall Management Center (FMC) Software that could allow an unauthenticated, remote attacker to execute arbitrary Java code as root on an affected device, which was disclosed by Cisco on March 4, 2026.
After Cisco’s disclosure, Amazon threat intelligence began research into this vulnerability using Amazon MadPot’s global sensor network—a system of honeypot servers that attract and monitor cybercriminal activity. While looking for any current or past exploits of this vulnerability, our research found that Interlock was exploiting this vulnerability 36 days before its public disclosure, beginning January 26, 2026. This wasn’t just another vulnerability exploit, Interlock had a zero-day in their hands, giving them a week’s head start to compromise organizations before defenders even knew to look. Upon making this discovery, we shared our findings with Cisco to help support their investigation and protect customers.
A misconfigured infrastructure server—essentially, a poorly secured staging area used by the attackers—exposed Interlock’s complete operational toolkit. This rare mistake provided Amazon’s security teams with visibility into the ransomware group’s multi-stage attack chain, custom remote access trojans (backdoor programs that give attackers control of compromised systems), reconnaissance scripts (automated tools for mapping victim networks), and evasion techniques.
AWS infrastructure and customer workloads on AWS were not observed to be involved in this campaign. This advisory shares comprehensive technical analysis and indicators of compromise to help organizations identify potential compromise and defend against Interlock’s operations. Organizations running Cisco Secure Firewall Management Center should immediately apply Cisco’s security patches and review the indicators provided below.
Discovery and investigation timeline
Amazon threat intelligence identified threat activity potentially related to CVE-2026-20131 beginning January 26, 2026, predating the public disclosure. Observed activity involved HTTP requests to a specific path in the affected software. Request bodies contained Java code execution attempts and two embedded URLs: one used to deliver configuration data supporting the exploit, and another designed to confirm successful exploitation by causing a vulnerable target to perform an HTTP PUT request and upload a generated file. Multiple variations of these URLs were observed across different exploit attempts.
To advance the investigation and obtain additional threat intelligence, we performed the expected HTTP PUT request with the anticipated file content—essentially, we pretended to be a successfully compromised system. This successfully prompted Interlock to proceed to the next stage, issuing commands to fetch and execute a malicious ELF binary (a Linux executable file) from a remote server.
When analysts retrieved the binary, they discovered the same host (attacker-controlled server) is used for distributing Interlock’s entire operational toolkit. The exposed infrastructure organized artifacts into separate paths corresponding to individual targets, with the same paths used for both downloading tools to compromised hosts and uploading operational artifacts back to the staging server.
Attribution to Interlock ransomware
The ELF binary and associated artifacts are attributable to the Interlock ransomware family based on convergent technical and operational indicators. The embedded ransom note and TOR negotiation portal are consistent with Interlock’s established branding and infrastructure. The ransom note’s invocation of multiple data protection regulations reflects Interlock’s documented practice of citing regulatory exposure to pressure victims, essentially threatening organizations not just with data encryption, but with regulatory fines and compliance violations. The campaign-specific organization identifier embedded in the note aligns with Interlock’s per-victim tracking model.
Interlock has historically targeted specific sectors where operational disruption creates maximum pressure for payment. Education represents the largest share of their activity, followed by engineering, architecture, and construction firms, manufacturing and industrial organizations, healthcare providers, and government and public sector entities.
Temporal analysis performed on timestamps from observed threat activities, artifacts stored on the misconfigured infrastructure server, and metadata embedded within recovered threat artifacts indicates the actor most likely operates in UTC+3 with 75–80% confidence. Systematic analysis across all UTC offsets showed UTC+3 produced the best fit: first activity around 08:30, peak activity between 12:00 and 18:00, and a probable sleep window of 00:30–08:30.
Figure 1: Interlock ransomware negotiation portal where victims enter their organization ID and email address to receive an auth token to begin a negotiation chat session.
Once Interlock gains initial access, they use a variety of priority tools to complete their attack. Amazon threat intelligence teams recovered a PowerShell script designed for systematic Windows environment enumeration (automated information gathering about the victim’s network). The script collects operating system and hardware details, running services, installed software, storage configuration, Hyper-V virtual machine inventory, user file listings across Desktop, Documents, and Downloads directories, browser artifacts from Chrome, Edge, Firefox, Internet Explorer, and 360 browser (including history, bookmarks, stored credentials, and extensions), active network connections correlated with responsible processes, ARP tables, iSCSI session data, and RDP authentication events from Windows event logs.
The script stages results to a centralized network share (\JK-DC2\Temp) using each system’s fully qualified hostname to create dedicated directories—essentially creating a folder for each compromised computer. Following collection, it compresses data into ZIP archives named after each hostname and removes original raw data. This structured per-host output format indicates the script operates across multiple machines within a network—a hallmark of ransomware intrusion chains that prepare for organization-wide encryption.
Custom remote access trojans
Remote access trojans (RATs) are malicious programs that give attackers persistent control over compromised systems, functioning like unauthorized remote desktop software.
JavaScript implant: Amazon threat intelligence recovered an obfuscated JavaScript remote access trojan that suppresses debugging output by overriding browser console methods (hiding its activity from basic detection tools). On execution, it profiles the infected host using PowerShell and Windows Management Instrumentation (WMI), collecting system identity, domain membership, username, OS version, and privilege context before transmitting this data during an encrypted initialization handshake.
Command-and-control communication occurs over persistent WebSocket connections with RC4-encrypted messages using per-message 16-byte random keys embedded in packet headers—essentially, each message uses a different encryption key, making interception more difficult. The implant cycles through multiple operator-controlled hostnames and IP addresses in randomized order with exponential backoff between reconnection attempts.
The implant provides interactive shell access, arbitrary command execution, bidirectional file transfer, and SOCKS5 proxy capability for tunneling TCP traffic (routing malicious traffic through other systems to hide its origin). Self-update and self-delete capabilities allow operators to replace or remove the implant without reinfection, supporting operational cleanup to hinder forensic investigation.
Java implant: A functionally equivalent client implemented in Java provides identical command-and-control capabilities. Built on GlassFish ecosystem libraries, it uses Grizzly for non-blocking I/O transport and Tyrus for WebSocket protocol communication. In simpler terms, Interlock built the same backdoor in two different programming languages, ensuring they maintain access even if defenders detect one version.
Infrastructure laundering script
Sophisticated threat actors don’t attack from their own infrastructure, they build disposable relay networks to hide their tracks. Amazon threat intelligence teams identified a Bash script that configures Linux servers as HTTP reverse proxies (intermediary servers that forward traffic to hide the attacker’s true location). The script performs system updates, installs fail2ban with SSH brute-force protection, and compiles HAProxy 3.1.2 from source. The HAProxy instance listens on port 80 and forwards all inbound HTTP traffic to a hardcoded target IP, with systemd ensuring persistence across reboots.
A notable component is a log erasure routine running as a cron job every five minutes. The routine truncates all *.log files under /var/log and suppresses shell history by unsetting the HISTFILE variable. This aggressive evidence destruction, wiping logs every five minutes, combined with the purpose-built HTTP forwarding proxy, indicates the script establishes disposable traffic-laundering relay nodes. These nodes obscure exploit traffic origin, relay command-and-control communications, or proxy data exfiltration, making it nearly impossible to trace attacks back to their source.
Memory-resident webshell
Amazon threat intelligence teams observed a Java class file delivered as an alternative to the ELF binary drop. When loaded by the Java Virtual Machine (JVM), its static initializer registers a ServletRequestListener with the server’s StandardContext, essentially installing a persistent memory-resident backdoor that intercepts HTTP requests without writing files to disk. This “fileless” approach evades traditional antivirus scanning that looks for malicious files.
The listener inspects incoming requests for specially crafted parameters containing encrypted command payloads. Payloads are decrypted using AES-128 with a key derived from the MD5 hash of the hardcoded seed “geckoformboundary99fec155ea301140cbe26faf55ed2f40″ (using the first 16 characters: 09b1a8422e8faed0). Decrypted payloads are treated as compiled Java bytecode, dynamically loaded into the JVM, and executed—a technique designed to evade file-based detection by running malicious code entirely in memory.
Connectivity verification tool
Amazon threat intelligence teams recovered Java class files implementing a basic TCP server listening on port 45588 (encoded as Unicode character 넔 to obscure the port number from static analysis). The server accepts connections, logs connecting IP addresses, sends a greeting message, and immediately closes connections. This operational profile is consistent with a lightweight network beacon—essentially a “phone home” tool used to verify successful code execution or confirm network port reachability following initial exploitation.
Legitimate tool abuse
Interlock deployed ConnectWise ScreenConnect, a legitimate commercial remote desktop tool, alongside custom implants. When ransomware operators deploy legitimate remote access tools alongside their custom malware, they’re buying insurance—if defenders find and remove one backdoor, they still have another way in. This indicates multiple redundant remote access mechanisms—a pattern consistent with ransomware operators seeking to maintain access even if individual footholds are removed. The tool’s legitimate network footprint helps blend with authorized remote administration traffic, making detection more challenging.
Amazon threat intelligence teams also recovered Volatility, an open-source memory forensics framework typically used by incident responders (the same tool defenders use to investigate attacks). While no artifacts indicated automated use, its presence alongside custom implants and reconnaissance scripts is consistent with advanced threat operations. Both ransomware groups and nation-state actors have been observed deploying Volatility during intrusions. The tool’s focus on parsing memory dumps provides access to sensitive data such as credentials stored in RAM, which can enable lateral movement (spreading through the network) and deeper environment compromise in support of ransom operations or espionage objectives.
Interlock also used Certify, an open source offensive security tool designed to exploit misconfigurations in Active Directory Certificate Services (AD CS). For ransomware operators, Certify provides a pathway to identify vulnerable certificate templates and enrollment permissions that allow requesting authentication-capable certificates. These certificates can be used to impersonate users, escalate privileges, or maintain persistent access. These capabilities directly support both initial compromise and long-term persistence objectives in ransomware operations.
Indicators of compromise (IoCs)
The following indicators support defensive measures by organizations that may be affected. Due to Interlock’s use of content variation techniques, most file hashes are not included as reliable indicators. The threat actor modified most artifacts like scripts and binaries downloaded to different targets. This resulted in different file hashes for functionally identical tools. The customization allowed each attack to evade signature-based detection that looks for exact file matches.
206.251.239[.]164
Exploit source IP
Active Jan 2026
199.217.98[.]153
Exploit source IP
Active Mar 2026
89.46.237[.]33
Exploit source IP
Active Mar 2026
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0
Organizations should take the following actions to protect against Interlock ransomware operations.
Immediate actions:
Apply Cisco’s security patches for Cisco Secure Firewall Management Center
Review logs for the indicators of compromise listed above
Conduct security assessments to identify potential compromise
Review ScreenConnect deployments for unauthorized installations
Detection opportunities:
Monitor for PowerShell scripts staging data to network shares with hostname-based directory structures
Detect Java ServletRequestListener registrations in web application contexts (unusual modifications to Java web applications)
Identify HAProxy installations with aggressive log deletion cron jobs (proxy servers that erase their own logs every five minutes)
Watch for TCP connections to unusual high-numbered ports (e.g., 45588)
Long-term measures:
Implement defense-in-depth strategies with multiple layers of security controls
Maintain continuous threat monitoring and hunting capabilities
Ensure comprehensive logging with secure, centralized log storage (stored separately from systems that could be compromised)
Regularly test incident response procedures for ransomware scenarios
Educate security teams on Interlock’s tactics, techniques, and procedures
The real story here isn’t just about one vulnerability or one ransomware group—it’s about the fundamental challenge zero-day exploits pose to every security model. When attackers exploit vulnerabilities before patches exist, even the most diligent patching programs can’t protect you in that critical window. This is precisely why defense in depth is essential—layered security controls provide protection when any single control fails or hasn’t yet been deployed. Rapid patching remains foundational in vulnerability management, but defense in depth helps organizations not to be defenseless during the window between exploit and patch.
Amazon Threat Intelligence teams continue to monitor Interlock ransomware operations and will provide updates as additional information becomes available. The intelligence gathered from this campaign is being integrated into AWS security services to protect customers proactively.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Credential theft is the dominant initial access vector for enterprise breaches. In 2025, Recorded Future detected:
1.95 billion malware combo list credential exposures
36 million database combo list credential exposures
24 million database dump credential exposures
892 million malware log credential exposures
Five findings stand out from the data:
Credential theft accelerated as the year progressed. Recorded Future identified 50% more credentials in the second half of 2025 than in the first half of the year. 90% more credentials were identified in the last three months of the year than in the first three months
Stolen credentials are targeted, not random. Of the 7 million credentials indexed with identifiable authorization URLs, 63.2% were tied to authentication systems. VPNs, RMM tools, cloud platforms, and detection software also featured prominently — meaning attackers are often going directly for the systems that provide the broadest access and, in some cases, the ability to blind security teams entirely.
Infostealer malware is outpacing traditional breach detection. Each compromised device yielded an average of 87 stolen credentials. The scale and precision of modern infostealers means a single infected endpoint — including a personal device used to access corporate systems — can expose an entire organization.
MFA alone is no longer sufficient protection. 276 million of the credentials indexed in 2025 included active session cookies, meaning attackers can bypass multi-factor authentication entirely. This represents 31% of all malware-sourced credentials.
Detection speed is the decisive advantage. Over half of all credentials (53%) were indexed within one week of exfiltration, and 36.4% within 24 hours. Organizations that act on intelligence quickly can intervene before stolen credentials are exploited.
The Scale of the Problem: Compromised Credentials in 2025
Volume Grew Throughout the Year
Credential compromise from malware logs was not a static risk in 2025 — it compounded. Recorded Future observed a consistent upward trend throughout the year, with the second half producing 50% more indexed credentials than the first.
The final three months of the year were particularly active: They saw 90% more volume than the first three months, reflecting both the continued proliferation of infostealer malware-as-a-service (MaaS) and the disruption and reformation of major malware families mid-year (covered in detail in the malware section below).
CHART 1: Monthly credential volume from malware logs, full year 2025 (Source: Recorded Future)
What this means for security teams: Seasonal or quarterly threat reviews are insufficient. The volume and pace of credential exposure in 2025 demands continuous monitoring — not periodic audits.
What do Those Credentials Actually Unlock?
CHART 2: Top authorization URL categories, 2025 (Source: Recorded Future)
More credentials exposed means more doors open to attackers. The authorization URL data from 2025 reveals exactly which doors they're targeting — and the picture is stark.
Of the 7 million credentials with high-risk authorization URLs indexed in 2025, 63.2% were tied to authentication systems. The next largest categories were web content management (9.95%) and cloud computing (7.58%), followed by remote monitoring and management tools (6.19%) and email infrastructure (3.87%).
This is not a random distribution. Authentication systems, cloud platforms, and remote access tools — VPNs at 2.4% and RMM tools at 6.19% — are precisely the systems that give attackers the broadest foothold inside an organization. A single stolen credential for an authentication portal or VPN can serve as the entry point for lateral movement, privilege escalation, and ultimately a full breach.
The presence of detection and response software (1.17%) and SIEM platforms (0.06%) in this list is particularly notable. Credentials for the tools organizations rely on to detect attacks are themselves being stolen — giving attackers the ability to blind security teams before they strike.
What this means for security teams: The value of a stolen credential is determined by what it unlocks. Prioritize monitoring and rapid response for credentials tied to authentication systems, remote access tools, cloud infrastructure, and security platforms — these can represent the highest-leverage targets for attackers operating with stolen credentials.
A Global Problem With Regional Concentration
Compromised credentials were indexed from organizations across the globe. The ten countries with the highest credential volume in 2025 were:
Table 1: Credentials indexed by country (Source: Recorded Future)
MAP 1: Credentials indexed by country (Source: Recorded Future)
The breadth of this data underscores that credential theft is not concentrated in a single region or industry — it is a universal risk. Organizations with global workforces, multinational supply chains, or international customer bases face exposure across multiple geographies simultaneously.
The Anatomy of a Compromise: What Attackers Actually Steal
87 Credentials Per Device
When an employee's device is infected with infostealer malware, the damage rarely stops at one account. In 2025, the average compromised device yielded 87 stolen credentials — spanning corporate applications, personal accounts, and cloud services accessed from the same machine.
Recorded Future's Compromised Host Incident Reports surface the full scope of each device-level infection, including the malware family responsible, file paths, IP addresses, and infection timelines. This context is what separates actionable intelligence from a list of leaked passwords.
What this means for security teams: A single alert should trigger a device-level incident response, not just a password reset. Understanding what else was on that machine — and what else may have been exfiltrated — is essential to containing the full extent of the exposure.
The Cookie Problem: Why MFA Isn't Enough
One of the most significant findings from 2025 is the volume of credentials that included active session cookies alongside stolen passwords. Recorded Future indexed 276 million credentials with cookies — 31% of all malware-sourced credentials — a figure that grew 30% from the first half of the year to the second half.
Session cookies allow attackers to authenticate as a user without entering a password or completing an MFA challenge. They effectively render secondary authentication controls irrelevant for as long as the session remains active.
December was the single highest month for cookie-bearing credential exposure, indexing 18% more than the next highest month (November).
CHART 3: Monthly volume of credentials with cookies, 2025 (Source: Recorded Future)
What this means for security teams: MFA enrollment is necessary but not sufficient. Organizations should monitor for session cookie theft specifically, enforce shorter session token lifespans for high-risk applications, and treat any credential exposure from an infostealer log as a potential authentication bypass — not just a password reset trigger.
The Infostealer Ecosystem: How the Malware Landscape Shifted in 2025
LummaC2: The Year's Dominant Threat
LummaStealer emerged as the most widely deployed infostealer of 2025. Operating under a malware-as-a-service model since late 2022, it matured significantly over the past year, targeting Windows systems to harvest browser credentials, session cookies, cryptocurrency wallets, and two-factor authentication tokens.
Its distribution relied heavily on social engineering — fake software downloads and "ClickFix" techniques that trick users into executing malicious commands disguised as CAPTCHA challenges. Recent campaigns used CastleLoader for delivery, running obfuscated payloads in memory to evade detection.
In May 2025, a coordinated law enforcement action neutralized more than 2,300 LummaC2 command-and-control domains. The disruption was significant — but not fatal. LummaStealer operators migrated to bulletproof hosting services and employed sophisticated sandbox evasion techniques, including trigonometric analysis of mouse movements to avoid automated detection environments. Activity continued under private, select-affiliate operations through the remainder of the year.
How the Rest of the Ecosystem Responded
The 2025 infostealer landscape was shaped as much by law enforcement disruption as by attacker innovation. Each takedown created a vacuum that other malware families quickly filled.
Early 2025: The late-2024 law enforcement actions against RedLine and META pushed users toward emerging MaaS alternatives, consolidating volume around LummaC2 and accelerating its dominance through Q2.
Mid-2025: Following the LummaC2 disruption in May, established families — Rhadamanthys, Vidar, and StealC — absorbed the displaced activity. Rhadamanthys led through the summer until its own infrastructure was taken down by law enforcement in November 2025. Vidar stepped into the lead position thereafter.
Rebranding as a survival strategy: Disruption prompted reinvention. StealC relaunched as StealC v2. Vidar operators attempted a similar rebrand. These moves reflect a deliberate effort by malware developers to obscure continuity and frustrate attribution.
macOS: Atomic macOS Stealer (AMOS) dominated the macOS market through most of 2025, disappearing in October before returning in February 2026. MacSync (formerly Mac.C) emerged as the primary commodity macOS infostealer by year end.
Private operations grew: Increased law enforcement pressure on publicly accessible MaaS tools pushed sophisticated threat actors toward private infostealers with restricted affiliate access. Acreed (also known as ACR Stealer) and Odyssey Stealer represented the most significant private-operation families of 2025. Private Lumma operations also continued post-disruption.
What this means for security teams: Malware family names change. Takedowns create temporary disruption, not permanent resolution. Organizations that track exposure by malware family rather than only by leaked credential volume will be better positioned to understand the true source and scope of each incident.
Recommendations for Security Teams
The 2025 data points to four areas where security teams can meaningfully reduce their exposure to credential-based attacks.
1. Extend monitoring to personal devices. The majority of infostealer infections occur on personal devices used to access corporate systems — a risk that endpoint detection tools and traditional perimeter controls cannot address. Monitoring infostealer malware logs directly provides visibility into these exposures before they are weaponized.
One large automotive parts distributor found that Recorded Future surfaced stolen credentials tied to an employee's personal device — an exposure their existing tools had no visibility into and would likely never have caught.
2. Treat session cookie exposure as a critical-severity event. With 276 million credentials carrying active cookies in 2025, any infostealer-sourced credential exposure should trigger immediate session invalidation in addition to a password reset. MFA bypass via stolen cookies is not a theoretical threat — it is an observed, frequent attack pattern.
3. Automate response workflows to close the detection-to-remediation gap. The data shows that most credentials are indexed within days of theft. Organizations that have pre-built response playbooks — automatically checking Active Directory, clearing sessions, forcing resets, and notifying managers — respond in minutes rather than hours.
"We created a custom SOAR playbook using the Identity Intelligence module. This playbook takes the information of compromised corporate user accounts, runs an Active Directory check for the credentials, clears user sessions and resets the password if the account is found to be compromised. It also notifies the user's manager for email response. To date, we have processed over 330 different identity alerts. " — Bryan Cassidy, Lead Cyber Defense Engineer, 7-Eleven (UserEvidence)
4. Monitor your entire domain footprint — including subsidiaries and third parties. Some of the most consequential exposures in 2025 involved obscure subsidiaries and supply chain partners, not core corporate domains. Attackers do not limit themselves to obvious targets. Security teams shouldn't limit their monitoring to obvious domains either.
One large international financial services firm detected an infostealer on a third-party service provider's machine through Recorded Future — surfacing a supply chain exposure that would have been invisible through traditional monitoring alone.
The Recorded Future Advantage: Detection Speed – From Exfiltration to Alert in Hours
The gap between when credentials are stolen and when a security team finds out is where breaches happen. Most organizations discover compromised credentials days or weeks after the fact — through a public breach disclosure, a tip from law enforcement, or an incident that's already underway.
Recorded Future closes that gap. In 2025, 36.4% of all indexed credentials were detected within 24 hours of exfiltration, and 52.9% within one week. By the time stolen credentials are being traded or weaponized, Recorded Future customers have already been alerted.
Credential Exfiltration Breakdown
Within 24 hours
36%
Within 1 week
53%
Within 1 month
85%
Within 1 year
99%
Over 1 year
1%
Table 2: Exfiltration freshness breakdown (Source: Recorded Future)
Speed matters because attackers move fast. Infostealer logs are often listed for sale within hours of collection. Every day between exfiltration and detection is a day an attacker may already have access. The 15.3% of credentials not detected within a month illustrate what happens when that window stays open — extended attacker dwell time, lateral movement, and incidents that escalate into major breaches.
For Recorded Future customers, early detection is only half the equation. Pre-built integrations with Okta, Microsoft Entra ID, and SOAR platforms like XSOAR mean that when a credential alert fires, automated workflows can clear sessions, force password resets, and notify managers — without waiting for an analyst to pick up the ticket.
A large international financial services firm's Team Lead described a recent credential leak: identified and escalated in under 24 hours, triggering immediate automated remediation — exactly the outcome their team had built toward.
Appendix: Notable Passwords from 2025 Credential Exposures
The following passwords appeared most frequently across credentials indexed by Recorded Future in 2025. Their prevalence reflects the continued gap between password policies and actual user behavior — and the reason why credential monitoring cannot rely on password complexity alone as a proxy for risk.
About This Report
This report is based on data indexed by Recorded Future's Identity Intelligence Module across the full calendar year 2025. Recorded Future monitors credentials across open web, dark web, paste sites, Telegram channels, and infostealer malware logs sourced from 30+ malware families. All credential data can be processed and analyzed without storing plaintext passwords in customer-facing systems.
Find out What’s Already Exposed in Your Environment
The data in this report reflects the broader threat landscape. The question is how much of it applies to your organization specifically.
Recorded Future's complimentary Identity Exposure Assessment pulls directly from the Recorded Future Intelligence Graph to show you the volume, recency, and severity of your organization's credential exposure over the past year — including compromised employee credentials, infostealer-sourced data, and how your exposure has trended over time.
There's no commitment required. Just a clear picture of where your organization stands.