code snippets

The Outsized Shadow: Why 5% of AI Users Are Your Biggest Security Risk

Big security risks come in small packages. While enterprise security teams focus on policing the proliferation of employees using ChatGPT and Claude for quick drafting tasks, a more urgent threat is posed by a handful of AI super-adopters who are quietly hardcoding unvetted tools into critical business operations. According to new research published by Akamai, the top 5% of enterprise power users interact with AI models at 12 times the rate of the bottom 50% of the workforce. The findings, published in Akamai’s State of the Internet: Enterprise AI Usage Risk Report 2026, are based on real-world usage and telemetry data as well as research and threat analysis. These AI super-adopters are creating a disproportionate security risk by expanding the use of shadow AI, increasing opportunities for data leakage, and introducing autonomous AI agents that operate within the enterprise but outside its established guardrails. “Small groups of AI power users are casting outsized shadows across enterprise threat surfaces that are already riddled with dips and blind spots,” says Or Eshed, Vice President Enterprise Security Product & Engineering at Akamai. “While security teams are focused on trying to govern all employees’ access to big frontier LLMs, the cumulative long-tail shadow of dozens of smaller AI tools used by power users arguably poses a more significant security risk.” According to Akamai data, the average employee conversation lasts about five prompts, while the top 5% of power users routinely engage in conversations of 18 prompts or more — evidence that AI models are becoming embedded collaborators in essential business operations. "AI is no longer just a productivity booster; it is a virtual colleague with keycard access to the company vault,” says Eshed. “Security teams need to identify which employees depend most on AI to know where risk is concentrated." Enterprise Control vs. Consumer Leakage Nearly half of all enterprise AI conversations (47.11%) occur through personal identities rather than corporate-managed accounts, according to Akamai’s report. The situation creates a stark contrast between housebroken AI and feral AI. AI platforms with dedicated governance controls successfully enforce corporate identity boundaries, while personal-access accounts create significant visibility gaps for IT, security, and compliance teams. Gemini Enterprise (98.15%) and Microsoft Copilot M365 (90.55%) keep the vast majority of interactions inside corporate identity systems. DeepSeek (99.8%), Microsoft Copilot Standard (63.92%), ChatGPT (61.36%), and Claude (61.09%) are overwhelmingly dominated by personal identity logins. Governance becomes even more muddled when employees use corporate email addresses to register personal AI subscriptions. "One of the most surprising findings was that 14.4% of enterprise AI conversations occurred via corporate email addresses linked to personal 'freemium' AI subscriptions rather than enterprise-managed licenses," says Eshed. "This means that even when accessed through a corporate identity, the sensitive data employees inject into prompts may be used for public model training." But even organizations that successfully manage enterprise AI accounts often have little visibility into the growing ecosystem of niche AI tools employees install outside approved channels, the report found. Long-Tail Blindness While security teams focus on governing ChatGPT, Claude, Copilot, and Gemini, employees are quietly adopting dozens of niche AI tools, AI-enabled SaaS applications, and personal subscriptions without IT oversight. “As with mobile devices, employees increasingly 'bring their own AI tools — or BYOAI' to access AI through personal accounts,” says Eshed. “That creates additional visibility gaps around how business data is stored, retained, and processed.” Browser and IDE extensions represent another rapidly expanding blind spot. Akamai found that 17.7% of employees at midsize enterprises use at least one AI extension, compared with 9.53% at larger organizations. Nearly 75% request high or critical permissions. Crucially, 16.31% of AI extensions contain known CVE vulnerabilities, compared to 10.80% of browser extensions overall. “These tools are creating broad, unmanaged pathways directly into active user sessions and sensitive corporate data,” warns Eshed ”This Shadow AI landscape is not just a data privacy issue; it is the infrastructure for the next generation of automated cyberattacks.” The CISO Imperative For security teams, this shifting landscape requires a fundamental mindset shift. The AI problem facing CISOs is no longer whether employees are using AI. They are. The new mission is to identify where AI is operating, which teams depend on it most, and whether those systems remain inside enterprise guardrails. The challenge is to answer those questions before adversaries do. Weaponizing the AI Surface This expanding AI surface is also creating new attack vectors that bypass traditional controls. The Akamai report highlights a few: Vibe Hacking: Attackers subtly modify local instruction files (such as AI_CONFIG.md) to covertly manipulate AI coding assistants into generating vulnerable code or executing unauthorized actions. CursorJacking: Rogue extensions are weaponized to silently harvest API keys, session tokens, and proprietary source code directly from local databases. CometJacking: Adversaries use indirect prompt injection embedded in malicious web pages to trick AI agents into exfiltrating local user files, shifting the target from the human endpoint to the AI collaborator. Akamai’s CISO Checklist to Secure Enterprise AI: Establish Continuous Visibility: Discover all AI applications, browser/IDE extensions, and agents across the network; inspect prompts, uploads, and responses in real time. Eliminate Shadow AI: Enforce corporate Single Sign-On (SSO), block unmanaged personal logins, and audit corporate email addresses tied to "freemium" subscriptions. Deploy Contextual AI DLP: Implement prompt-level inspection to catch unstructured data leakage—such as code snippets or internal text—that legacy pattern-matching tools miss. Audit Extensions and Permissions: Maintain a rigorous inventory of browser and IDE extensions, enforce strict permission boundaries, and screen add-ons for known CVEs. Govern AI Agents as Identities: Treat autonomous AI agents and browsers as privileged digital identities, applying least-privilege access, strict scope limits, and real-time monitoring.

thehackernews.comAug 24, 2026extracted

Russian-Speaking Hacker Uses Google Gemini CLI to Control Botnet of Eight Dental Clinic PCs

A solo Russian-speaking threat actor known as "bandcampro" outsourced a chunk of their operations to Google's open-source Gemini CLI artificial intelligence (AI) and commandeered a live botnet. The findings come from an analysis of 200 Gemini CLI session logs between March 19 and April 21, 2026, which found the threat actor using AI, among other things, to crack passwords, set up a residential proxy, compromise WordPress merchants, and plan a phone-based cryptocurrency fraud scheme aimed at elderly people in the U.S. and Canada. "The logs documented how the threat actor used an AI agent to migrate a command-and-control (C&C) server, and to control a small-scale botnet, among other hacking activities," Trend Micro researchers Joseph C Chen, Philippe Lin, Lucas Silva, Vladimir Kropotov, and Fyodor Yarochkin said. "The entire C&C operation fits in three plaintext files totaling roughly 5 KB, making it highly replicable and effectively disposable. The AI was also observed to proactively (unprompted) propose improvements 59 times without being asked." Specifically, the threat actor is said to have abused Google Gemini CLI to deploy and operate a C&C infrastructure to control eight computers in a dental clinic and access their OpenDental database. Besides writing code snippets, the AI served as the "primary hacking agent, consultant, and interface" to the entire operation. This included setting up the server, deploying it on a new virtual private server (VPS), configuring the infrastructure, setting up Cloudflare tunnels, managing the bots, and debugging connectivity issues. Details of "bandcampro" first emerged in late May 2026 in connection with a campaign dubbed Patriot Bait that used AI-assisted information operation (IO) techniques to run a Telegram channel, targeting politically engaged American audiences for cryptocurrency fraud and AI-assisted credential theft. Trend Micro has described the threat actor as a Russian speaker who used Google Gemini to "impersonate an American veteran patriot and to avoid Russian phrasing," while tricking the AI agent into bypassing its guardrails by assuming the role of an "authorized pentester." The threat actor is said to have run prompts to study the old C&C infrastructure where the victim machines connected using Cloudflare tunnels and migrate it to a new architecture within six minutes. The architecture involves victims issuing outbound requests to a C&C server over HTTPS to pull and run PowerShell commands staged by the threat actor on the server. "The migration hit errors immediately, but the AI agent resolved them: When the payload distribution server returned a '502 Bad Gateway' error, the AI diagnosed the issue and automatically added the necessary header to resolve it," Trend Micro said. "As Cloudflare still blocked the requests, the AI identified that the User-Agent header was required to bypass the WAF and thus added it to the request header. The actor did none of the debugging, and the migration was done in merely six minutes." Once the migration was complete, the AI agent carried out additional debugging to successfully remediate errors that left all the victim machines disconnected from the C&C infrastructure. In addition, the threat actor has been found to leverage the AI agent to perform botnet management tasks by sending natural language instructions in Russian, which then enabled the AI tool to perform the following tasks - Report which machines are active Send a file enumeration command to the bot Send reconnaissance commands to the front desk machine Generate a one-line PowerShell command to infect a machine What's particularly concerning about this AI-assisted setup is that the entire C&C operation can be easily ported to a fresh server through three markdown files that instruct the agent to disable its safety protections, contain the architecture description, and include steps to build it from scratch, making takedowns a lot less effective than before. "Facilitated by AI, the infrastructure becomes disposable, and the operators replaceable," Trend Micro said. "Even though the takedowns are still efficient, they become much less impactful. If a server is burned, the actor could simply unpack the bundle on a new VPS, and AI configures and restores everything in a few minutes." The findings show that the technology can not only cut the resources necessary to run large-scale operations, but also enable bad actors with little to no technical knowledge to set up such schemes with minimal effort or distribute them on underground forums in the form of malicious skill files, effectively paving the way for new AI-powered malware services that go beyond the conventional "as-a-service" models. This playbook also has the side-effect of complicating attribution efforts, as there is no centralized service to hunt for, and an AI agent can easily regenerate or modify any component at will so as to sidestep specific fingerprints. At one point, "bandcampro" is said to have prompted the AI to build a self-spreading "agent-bomb" that would scan the network and break into as many machines as possible, a request the agent refused, stating it's "crossing the line." At the same time, it offered helpful suggestions to manually overcome the limitations. The threat actor has also been found relying on the AI agent for other tasks, namely - Password cracking, which used the agent as a credential mutation engine to predict possible passwords based on an input list obtained from AntiPublic, which maintains a database of leaked credentials, and leveraged those guesses as a brute-force tool for WordPress admin panels, successfully gaining access in a handful of cases. Credential exploitation, which analyzed 1Password dumps to find exploitation pathways. The task, however, ended up in failure, if only because the context window ran too long, and it lost track of what it was supposed to do. Cryptocurrency fraud planning, which involved discussing the feasibility of establishing a telephone-based bogus scheme targeting the elderly in the U.S. and Canada. "Across the full month of logs, the actor contributed 11% of text produced and the AI 89%, twelve times the actor's word count," Trend Micro concluded. "The actor provided strategic direction and functioned as a product manager, while the AI was his entire engineering team, handling 80% of architectural design, 100% of coding and system command execution, and 90% of problem diagnosis and debugging." "The portable skill-file model means this methodology will likely spread. The skill file is plain text, unlikely to be flagged by traditional malware scanners on its own, shareable on forums, and modifiable in seconds. It turns any capable AI coding agent into a C&C operator, if they can successfully persuade the built-in safety mechanisms in AI agents."

thehackernews.comJul 20, 2026extracted

Russian cybercriminal used jailbroken Gemini CLI to rebuild botnet infrastructure in six minutes

Russian cybercriminal used jailbroken Gemini CLI to rebuild botnet infrastructure in six minutes A Russian-speaking threat actor known as “bandcampro” used a jailbroken Gemini CLI, Google’s open-source terminal-based AI agent, to deploy and operate a small command-and-control (C2) botnet, according to TrendAI. Operational overview (Source: TrendAI) In more than 200 sessions between March 19 and April 21, 2026, the threat actor worked with Gemini to deploy and operate infrastructure that controlled eight computers inside a dental clinic and gain access to the clinic’s OpenDental database. Posing as an “authorized penetration tester,” he instructed Gemini to suppress safety disclaimers and automatically save any credentials it encountered. Both instructions were placed in Gemini’s memory file, which reloads at the start of each session, allowing them to persist across subsequent conversations. “The AI was not only an assistant that wrote code snippets, but also the primary hacking agent, consultant, and interface to the entire operation,” researchers wrote. “The actor typed the intentions in Russian, and the AI wrote the server, deployed it on a new VPS, configured the infrastructure, set up Cloudflare tunnels, managed the bots, debugged connectivity problems, and even suggested using an idle bot.” Six-minute C2 migration The findings center on an incident from March 23, 2026. The threat actor’s old infrastructure had victim machines connecting through Cloudflare tunnels, but firewalls and antivirus software started blocking those tunnels, prompting him to adopt a new architecture. He had already asked Gemini to summarize the old setup in a two-page, plain-English skill file covering the server’s functions, how bots connect, how to infect new machines, how to maintain persistence, and how to troubleshoot Cloudflare problems. With that file in place, he launched Gemini CLI with a single instruction: “Study the C2 migration.” “The AI read the migration guide, then prepared a migration bundle, a small archive of server code, payloads, and the skill file. It then unpacked the bundle, launched the C&C server on a VPS, and brought up the Cloudflare tunnel,” the researchers added. The migration encountered several configuration problems that Gemini worked through autonomously. When the payload server returned a “502 Bad Gateway” error, it diagnosed and fixed the issue. When Cloudflare’s firewall continued blocking requests, Gemini determined that a browser-style User-Agent header was needed and added it. In the finished setup, infected machines checked in with the server every five seconds over HTTPS to retrieve and run PowerShell commands. The threat actor did none of the debugging himself, and the initial migration was completed in six minutes. Afterward, Gemini also diagnosed a “split-brain” issue that had left traffic divided between the old and new servers. It instructed him to shut down the old C2 server, restarted the new server and tunnel, and confirmed that all bots had reconnected. Across the logs collected over the month, TrendAI found that bandcampro contributed 11% of the text produced, while Gemini generated the remaining 89%. Researchers also attributed 80% of the architectural design, all coding and system-command execution, and 90% of problem diagnosis and debugging to the AI. Three files totaling roughly 5 KB The C2 operation was encoded in three plain-text files totaling roughly 5 KB: a jailbreak prompt, a playbook describing the botnet’s architecture and operations, and a migration guide that allowed a new AI session to restore the infrastructure on another server. A single Python HTTP server handled both payload delivery and command-and-control functions. It wrote nothing to disk and held its state in memory, leaving little forensic evidence on the server. Its traffic used /api/v1 paths that researchers said were likely intended to blend in with OpenAI-compatible traffic. On infected machines, a PowerShell script contacted the server every five seconds. Persistence was maintained through WMI event subscriptions and scheduled tasks on systems where the malware had administrator privileges. Without administrator access, it used a registry-based logon mechanism and a scheduled task disguised as a OneDrive update. “The code is straightforward, there is no obfuscation, no packing, and no evasion techniques. An experienced developer could write this within a day, and AI within minutes,” the researchers noted. “Before AI, running an operation like this required hiring someone with years of specialized experience. Now, that knowledge sits in a 5KB file even a non-technical threat actor can read and use.” That shift matters for two reasons. Losing a server becomes less consequential because a threat actor can unpack the same files on a new host and let the AI recreate the infrastructure. Distribution also becomes simpler. “Unlike conventional Malware-as-a-Service (MaaS), a skill file can be easily shared through a forum or shared in a message with no technical handover required.” Gemini still refused some requests The jailbreak did not work every time. In one session, he asked whether Gemini could build a self-spreading “agent-bomb” that would scan a network and infect as many machines as possible. Gemini refused, responding in a message machine-translated from Russian: “Even for your testbed. That’s crossing the line, and security policy strictly prohibits me from creating such ‘bombs.’” Even with the jailbreak instructions in place, Gemini’s safeguards activated on some occasions. When he could not work around them, the logs show he abandoned the request and moved on to other tasks. The dental clinic wasn’t his only target. Beyond the botnet, the threat actor used Gemini to crack passwords, compromise WordPress merchant accounts, and plan a phone-based cryptocurrency fraud scheme aimed at elderly people in the US and Canada.

helpnetsecurity.comJul 16, 2026extracted

That AI Extension Helping You Write Emails? It’s Reading Them First

We found 18 AI browser extensions marketed as productivity tools that are not as they seem. This group includes extensions such as: One that surveils your emails as you compose them Another that intercepts ChatGPT prompts A third that exfiltrates passwords Leveraging the rise of generative AI (GenAI), these extensions deliver remote access Trojans (RATs), meddler-in-the-middle (MitM) attacks and infostealers that target prompts, user behavior and browser sessions. Attackers blend the following established techniques with AI productivity lures: API interception Passive Document Object Model (DOM) observation Traffic proxying HTTPS response decryption Multiple samples contained AI-generated code, indicating that threat actors employed large language models (LLMs) to accelerate malware production. We specifically reported 18 high-risk extensions to Google. Google either removed the extensions or sent a warning to the owners of the extensions to address policy violations. Organizations and individual users should exercise caution by sourcing extensions only from trusted providers and adhering to the principle of least privilege. Users must scrutinize requested permissions, as granting broad access to browser data can authorize the interception of sensitive credentials and proprietary session information. Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. We identified multiple extensions that appeared to be AI tools delivering RATs and MitM campaigns, which we disclosed via timely threat intelligence (TTI) posts. These include: AI-powered summary extensions exfiltrating sensitive data to low-reputation domains (August 2025) Adware campaigns using hidden iframes (August 2025) Cursor customization extensions delivering potentially unwanted programs (PUPs) (August 2025) Prompt and search hijackers redirecting queries to attacker-controlled domains (September 2025) Most recently, a Model Context Protocol (MCP)-themed RAT targeting AI developers (February 2026) Browser extensions operate within the browser's trusted process with user-granted permissions. They can read and modify web content, intercept network requests, access cookies and communicate with external servers. These capabilities are shared with legitimate tools like ad blockers, password managers and developer tools. Deceptive extensions exploit this privileged position. An extension can override network request APIs before calls leave the page. It can passively monitor DOM changes in targets like Gmail or Notion. It can configure browser proxy settings to route traffic through attacker infrastructure. It can attach the Chrome Debugger Protocol to read decrypted HTTPS response bodies. GenAI amplifies the risk. When users type prompts into AI services, they routinely share proprietary code, draft communications and strategic plans. An extension positioned between the user and an AI service intercepts sensitive data. This data is far more valuable than the browsing metadata targeted by typical browser malware. Our retrospective analysis of detected high-risk extensions revealed the recurring techniques listed in Table 1. Table 1. Recurring techniques seen in GenAI high-risk extensions. As GenAI becomes the primary interface for professional and creative workflows, these extensions can potentially gain direct access to sensitive user information. If operated within the same execution context as the AI interface, these extensions pose a significant risk to enterprises. We placed detections from campaigns targeting AI users into six distinct malware categories based on their primary operational objective, as shown below in Figure 1. We derived these categories from manual analysis of extension code and network behavior. The following sections present case studies of these six high-risk GenAI browser extensions. A RAT is malware that grants an attacker complete remote control over a victim's system through a persistent command and control (C2) channel. This case study is for an extension named Chrome MCP Server - AI Browser Control that acts at a RAT. Extension ID: fpeabamapgecnidibdmjoepaiehokgda SHA256 hash: 0cbf101e96f6d5c4146812f07105f8b89bd76dd994f540470cd1c4bc37df37d5 RATs generally require victims to download and execute suspicious files, actions that security software typically detects as clear indicators of compromise. This GenAI-era adaptation disguises the RAT as an “AI browser automation tool” using the MCP framework, as shown in its Chrome Web Store listing in Figure 2. The listing deceptively states, “100% local processing - your data never leaves your browser” and “No external servers required for core functionality.” Attackers lead victims to believe that extreme permissions are necessary (debugger, , webRequest, scripting) for AI to control the browser. The extension hardcodes a WebSocket connection to a remote C2 server, as noted in the code snippet in Figure 3. From this server, it accepts over 30 remote commands, including: Executing arbitrary JavaScript via new Function() Chrome Debugger Protocol attachment for HTTPS traffic interception Filling out forms Capturing screenshots Accessing browsing history When a victim clicks Connect in the pop-up, the extension establishes a persistent WebSocket connection to a remote server, as noted from the source code snippets in Figure 4. This generates the connection to wss[:]//mcp-browser.qubecare[.]ai/chrome. Once connected, the extension reestablishes the C2 channel across network disconnections or browser restarts and the service worker restarts indefinitely. The extension uses a new Function() pattern to execute JavaScript code received from the remote server over the WebSocket. It then executes the code as JavaScript in the context of the victim's active tab, as noted below in Figure 5. If the victim is logged into their bank, corporate VPN, email or any other service, the remote operator can execute code in that authenticated context. AitB occurs when extensions read sensitive data directly from the rendered page DOM rather than intercepting network traffic, bypassing network-level security controls entirely. This case study is for an extension named Supersonic AI that performs AitB. Extension ID: eebihieclccoidddmjcencomodomdoei SHA256 hash: ac0a312398b3bf6b3d7c5169687ca72f361838bc5a90f2c0dbce2dc8e2094a02 Supersonic AI markets itself as an AI-powered email assistant for Gmail and Outlook. It includes features like one-click AI-generated replies and email summaries. To deliver these features, the extension needs to read email content. We examined how the extension subsequently handled this content. As illustrated in Figure 6, a content script is used to collect comprehensive email data and send the data to an external server. This broad data collection poses a severe security and privacy risk, as it captures and sends highly sensitive information in plaintext. This means all the emails from the victim's account, including those that are read, sent or displayed. Figure 7 demonstrates this in action within our sandbox environment, showing a social media platform one-time password (OTP) being exposed during the exfiltration process. Our Virus Bulletin 2025 paper provides a detailed technical analysis of this extension's Gmail exfiltration behavior. An infostealer is malware designed to harvest sensitive information such as credentials, authentication tokens and personal data from a victim's browser. This case study covers an extension named Reverse Recruiting - AI Job Application Assistant. In addition to stealing information such as salary expectations, it also targets a new class of credentials, AI API keys. Extension ID: iefpkdilnfhogjbkhgnliaomoldgkdlj SHA256 hash: 604c7aef72892b56ac23ad54744376574239c8f0651e95dd5b6cf540eb70f7c3 Reverse Recruiting is an AI job application assistant, as noted in Figure 8. It autofills forms across job portals and generates tailored resumes using OpenAI, Gemini and Claude. Its permission set is consistent with a cross-site autofill and AI assistant tool, including content script injection into all page frames via . However, the extension uses these permissions for activities well beyond its stated purpose. When a victim provides their OpenAI, Gemini or Claude API key to power the extension's AI features, it does not use those keys locally. A component of this extension named optimized-api.js reads all three of these keys from chrome.storage.sync and forwards them to the developer's backend in custom HTTP headers on every request (Figure 9). The victim also provides information for the job application assistant. The extension's profile-sync.js script then transmits the user's name, email, phone, LinkedIn URL, salary expectations, education and resume to a remote endpoint at api.reverserecruiting[.]io/v1/profile/sync. A search hijacker is malware that modifies browser search settings to redirect user queries through attacker-controlled servers, enabling search traffic interception and persistent tracking. This case study is for a browser extension named Chat AI for Chrome: Extension ID: jhhjbaicgmecddbaobeobkikgmfffaeg SHA256 hash: dfe307d957724ebe32331f92d53e366b7fa85968a9564c2285c5a0142ac9e1bb The search hijacker changes and controls the default search engine as noted in Figure 10. Chat AI for Chrome generates a unique user identifier on installation and stores it in three persistence layers: chrome.cookies window.localStorage chrome.storage.sync (syncs across all Chrome instances signed into the same Google account) It then registers a listener on Chrome's cookie change events, as noted in the code snippet in Figure 11. When the user deletes the tracking cookie, the extension recreates the deleted cookie. Because the ID is also stored in chrome.storage.sync, it persists across devices signed into the same Google account. Clearing cookies on one device does not eliminate the tracking. The identifier is restored from synced storage. The persistent tracking enables a parallel attack. The extension silently replaces the victim's default search engine via chrome_settings_overrides as noted in Figure 12. All user searches are routed through chatgptforchrome[.]com and correlated with the persistent tracking ID, building a cross-device search history profile that standard cookie-clearing practices cannot disrupt. The only effective remediation is complete uninstallation. A brand impersonator is malware that mimics legitimate software brands to exploit user trust and bypass skepticism during installation. This case study is for an extension named that impersonates a popular graphics editing brand. Extension ID: hmkcidjcpomiegnklmplkimmbcbklglb SHA256 hash: 4e38bee33237a8c8b17a2504013e506ca7cbf667a7f68a2d94d75db505c2149f It exploits the onInstalled listener that opens a “thank you” page immediately after installation, as noted in Figure 13. Figure 14 shows the result of the thanks.html page. Of note, the thanks.html file communicated with a URL hosted on xuix[.]top, which redirected to the newextensioninstallweb[.]com/2025 URL noted in Figure 14. Spyware is malware designed to covertly monitor and collect user activity, browsing behavior and personal data without explicit consent. This case study is for a Chinese language extension from Huiyi named 会译:一站式 AI 翻译 Agent｜对照式DeepL翻译｜DeepSeek划词翻译｜免费 that acts as spyware. Extension ID: dgeiaiglmhdhajbpfbmajaajdlfdinpi SHA256 hash: c9754454efede2dec2fcb856faa40424b8df378706b664a5ae4847fcd0336b53 This extension provides functional Chinese-English translation. It also requests permissions that far exceed what the translation requires. A translation extension needs content scripts to read and modify page text, and it needs network access to a translation API. It does not need to monitor a host's web traffic, configure proxy settings or maintain a bidirectional communication channel with an external website. This extension requests all of these permissions as noted in Figure 15. The extension registers chrome.webRequest.onCompleted listeners that trigger for every completed HTTP request across all websites. Additionally, the extension downloads a proxy auto-configuration (PAC) script from hxxps[:]//yiban[.]io/extension/proxy.pac?t=huiyi on startup and applies it via chrome.proxy.settings.set() as noted in Figure 16. A PAC script is executable JavaScript that determines, per request, which proxy server handles each connection. When traffic passes through a proxy server, the operator of that server has visibility into the destinations and metadata of all proxied requests. As noted in Figure 16, the extension fetches a PAC script (proxy.pac) from the URL at yiban[.]io. The extension publisher can modify its contents at any time, selectively routing any subset of user traffic through any proxy server without updating the extension. Beyond malware discovery, we observed an increasing trend in threat actors using LLMs to produce high-risk extensions. One example is a 10xprofit affiliate hijacking campaign documented in a threat research article by Socket. The campaign runs six extensions that silently inject affiliate tags into several popular online retailers or fast fashion brands without user consent. Our analysis adds a distinct finding: all six bear AI-generated code fingerprints, including formulaic section divider comments, identical code structures and template-based scaffolding. This is despite targeting different e-commerce platforms. Figure 17 below shows an example of the code structure. The extensions uncovered in our research represent more than isolated incidents. They reveal a deliberate shift in how threat actors approach browser-based attacks in the GenAI era. Attackers are strategically exploiting the trust users place in AI productivity tools and using that trust as the delivery mechanism itself. Adversaries have recognized that the growing popularity of GenAI allows them to impersonate AI platforms, to silently scrape prompts, harvest credentials and inject AI-generated code into campaigns. Our findings show that GenAI-themed extensions exhibit measurably different threat patterns compared to typical extension malware. They invest more heavily in data exfiltration, credential theft and content security policy (CSP) bypass, behaviors that target the sensitive context of AI interactions rather than opportunistically phoning home. Defending against these threats will require security approaches that treat the browser as a primary enterprise attack surface. Detection must incorporate behavioral analysis of runtime network activity, cross-file information flows and content intelligence on embedded domains. Organizations should treat browser extensions as third-party software, subject to the same vetting applied to any application with access to sensitive data. AI prompt data, internal workflows and session credentials flowing through the browser deserve the same protection as data at rest or in transit. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Prisma Browser provides protection against malicious browser extensions, including examples described in this article, with the integrated advanced extension security. We perform multi-layered analysis to detect both known and unknown malicious extensions. Prisma AIRS is designed to provide layered, real-time protection for AI systems by detecting and blocking threats, preventing data leakage and enforcing secure usage policies across a variety of AI applications. The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. We’d like to thank the entire Unit 42 team for supporting us with this article. Special thanks to Samantha Stallings, Bradley Duncan, Lysa Myers for helping us review the blog. Table 2 lists 18 high-risk Chrome extensions masquerading as AI applications. Table 2. Eighteen examples of high-risk extensions masquerading as AI applications. Malicious GenAI Chrome extensions: unpacking data exfiltration and malicious behaviours – Shresta B.Seetharam, Mohamed Nabeel and William Melicher, presented at Virus Bulletin 2025

unit42.paloaltonetworks.comApr 30, 2026extracted

A practical guide to secure vibe-coding for small businesses | Kaspersky official blog

The entry barriers for app development have plummeted in recent times — with nearly anyone now able to build a professional website, personal news bot, or dashboard simply by giving a chatbot or AI agent a few instructions in natural English. Unfortunately, a massive gap exists between a slick prototype and a reliable, production-ready, secure application. To avoid becoming the subject of another AI fail story, or losing money and sensitive data, follow these straightforward tips. These are intended specifically for non-technical creators and very small teams. Larger enterprises should follow more sophisticated recommendations. The primary risks of AI-generated code While vibe coding can deliver a seemingly functional app in just a few hours, it will likely contain dangerous flaws. AI models are trained on code samples from across the internet, which often include suboptimal tutorials, buggy snippets, and outright junk. Sometimes this code simply fails to run, but more often the situation is subtler and more hazardous: the app appears to work, yet under the hood, it might rely on a crude imitation of the required logic or contain critical vulnerabilities. According to a study by the Cloud Security Alliance AI Safety Initiative, the following facts should be considered when using AI for coding: At least 45% of AI-generated code contains dangerous vulnerabilities, such as failing to verify the user before granting access to sensitive data. A professional developer using AI can write code three to four times faster, but may introduce 10 times as many vulnerabilities. Twenty percent of AI-generated code attempts to use external libraries and modules that don’t actually exist. Even when an application handles confidential data — such as payments, private messages, or documents — AI-generated code sometimes skips credential verification entirely. This can leave the app’s data open for anyone on the internet to read. In other instances, the app might correctly prompt for a username and password but fail to enforce access controls, allowing any registered user to view everyone else’s data. Access keys (tokens) for databases and AI services may be embedded directly into the source code, easy to steal, and difficult to rotate after a data breach or cyberattack. Project code or critical build outputs are often deployed to servers without proper access restrictions, leaving both the application logic and sensitive access keys vulnerable to theft. AI may implement insecure database access patterns, which can allow attackers to bypass the application to steal data or execute arbitrary code on the database server. Apps that include API functionality often suffer from insecure API implementations, lacking both user permission checks and rate limiting. Core principles of securing vibe code Always verify. Treat AI-generated code as a rough draft. It should always be reviewed and rigorously tested. Ideally, professional developers should handle this; however, if none are available, the vibe-coder should at least test the application themselves, have friends or colleagues poke around the live app, and ask them to review key code snippets. It’s also possible to evaluate code integrity by submitting a separate prompt to the AI: “Review this code for secure development best practices and check for OWASP Top 10 vulnerabilities”. Protect secrets. Never include passwords, API keys, or any other sensitive data in AI prompts. Instead, instruct the AI to write code that securely stores all secrets in environment variables (special hidden settings). Prioritize efforts. The main risks emerge when an application is network-accessible to outsiders, processes valuable data, or runs on infrastructure that would be useful to attackers. The components of an app or system that meet these criteria are precisely what’s needed to be protected first. A static website composed of three HTML pages faces significantly lower risk than a loyalty program integrated into an online store. Make security an explicit requirement. Even a simple, straightforward line in the prompt, like “Follow industry standards and security best practices when generating this code”, improves the output. Providing more specific requirements for critical code snippets makes the results even better. Don’t trust default settings. Often, the danger in vibe coding lies in the configuration rather than the code itself. For example, an app processing sensitive company data might be deployed on a public vibe-coding platform (Lovable or the like), and remain accessible to the entire internet by default. Even if the code is flawless, making that information public is a critical security failure. Because of this, every component — from hosting and database settings to the deployment pipeline — must be manually reviewed and properly configured. If the purpose of a setting is unclear, consult a chatbot for the optimal values, specifying that its goal is to enhance security, and describing who the app is intended for. Security is a continuous process. Securing the app should not be treated as a one-off task. Every time an application is updated, hosting providers are changed, or a project undergoes any other major shift, all steps in making it secure should be revisited, and the risks reassessed. Tips for securing vibe code It’s natural to want an app built from broad prompts like “Make me a beautiful, user-friendly, fast, reliable, and secure app for [use case].” However, for the results to actually be effective, each of those requirements needs to be fleshed out. Below, we’ve outlined recommendations for building standard components that will make vibe code more secure. It’s important to emphasize that “more secure” doesn’t mean “perfectly secure” — these approaches lower the risk, but that risk remains well above zero. Demand security from the AI. When assigning a task to a neural network, be explicit: “write secure code, validate data, encrypt passwords”. Each type of task requires its own security prompt. For instance, don’t just ask to “build a login form”. Instead, ask for a “secure login form with credential validation, authentication and authorization (user permissions) controls, brute-force protection, password hashing according to modern standards, transmission strictly over HTTPS, and no hardcoded secrets”. It makes sense to use these secure requirement templates every time. It’s also helpful to keep a short cheat sheet of standard requirements for AI prompts: “validate all external data and user input before processing”, “no secrets in code”, “protect APIs from abuse”, “restrict user permissions”, and “secure default settings”. Use off-the-shelf solutions. If an app needs a user management system, insist on using a popular, reputable library, such as NextAuth, Auth0, and so on, rather than inventing a new and vulnerable solution. This is the most common cause of data breaches. This applies to more than just login and registration; for other high-risk actions like file uploads and API call processing, it’s better to use established frameworks and libraries with built-in protections rather than building everything from scratch. Don’t trust the AI blindly; verify open-source components. Neural networks often try to inject non-existent components and libraries into a project or suggest outdated versions. Always search for the suggested names online to ensure they are real, widely used, and secure — and make sure the latest versions are used. Demand robust encryption. Explicitly state that modern industry standards must be used for both data transmission and storage: TLS 1.3 based on OpenSSL for network traffic; argon2 or bcrypt for hashing credentials; and so on. Never trust user input. Always instruct the AI to include validation for any data entered by users, whether in forms or search bars. Use terms like “parameterization” and “sanitization” to emphasize that the app needs protection against malicious actors, not just users’ typos. Set limits on user actions. Require the AI to implement rate limiting for login attempts or general requests. This will protect a project from automated attacks like DoS and brute-force password guessing. Hide the system’s inner workings. If the site crashes, users should see a simple apology page rather than a detailed error report containing snippets of the code. That kind of information is a goldmine for hackers. Remember that you’re a developer, and you need to protect development-related digital assets. All related accounts — such as access to GitHub, project hosting, and other resources — are prime targets for attackers. Be sure to enable two-factor authentication (2FA) on all work accounts. Make backups. Regularly back up a project both locally and to the cloud to protect it against critical AI errors as well as cyberattacks. These backups should include both the application’s source code and its databases. Set up a sandbox. Test new features and app versions in a secure environment using a clone of an active site or app and a copy of a database. Always run thorough tests before pushing an update live. This allows catching issues without putting users or their data at risk. Update dependencies and scan them for vulnerabilities. A vibe-coded app will almost certainly rely on third-party libraries and components, known as dependencies. It’s wise to update these regularly by rebuilding an app with the latest versions, even if app’s code itself has not been changed. This process helps patch known security flaws in the used packages. Check for secrets leaking into the repository. Use secrets scanners like TruffleHog to audit resulting code. Even with instructions, AI might slip up and include an API key or password in the source code. A scanner ensures that files containing keys and passwords don’t end up in Git or get published alongside the project.

kaspersky.comApr 28, 2026extracted

The npm Threat Landscape: Attack Surface and Mitigations

unit42.paloaltonetworks.comApr 24, 2026extracted

Toxic Combinations: When Cross-App Permissions Stack into Risk

On January 31, 2026, researchers disclosed that Moltbook, a social network built for AI agents, had left its database wide open, exposing 35,000 email addresses and 1.5 million agent API tokens across 770,000 active agents. The more worrying part sat inside the private messages. Some of those conversations held plaintext third-party credentials, including OpenAI API keys shared between agents, stored in the same unencrypted table as the tokens needed to hijack the agent itself. This is the shape of a toxic combination: a permission breakdown between two or more applications, bridged by an AI agent, integration, or OAuth grant, that no single application owner ever authorized as its own risk surface. Moltbook's agents sat at that bridge, carrying credentials for their host platform and for the outside services their users had wired them into, in a place that neither platform owner had line of sight into. Most SaaS access reviews still examine one application at a time, which is the blind spot attackers are learning to target. How Toxic Combinations Form Toxic combinations are rarely the product of a single bad decision. They appear when an AI agent, an integration, or an MCP server bridges two or more applications through OAuth grants, API scopes, or tool-use chains, and each side of the bridge looks fine on its own because the bridge itself is what no one reviewed. As an example, imagine a developer installs an MCP connector so their IDE can post code snippets into a Slack channel on request. The Slack admin signs off on the bot; the IDE admin signs off on the outbound connection; neither signs off on the trust relationship between source editing and business messaging that exists the moment both sides are live. It runs in both directions: prompt injections inside the IDE push confidential code into Slack, and instructions planted in Slack flow back into the IDE's context on the next session. The same shape appears wherever an AI agent bridges Drive and Salesforce, a bot wires a source repository into a team channel, or any intermediary makes two apps trust each other through a grant that looks normal in each. Why Single-App Reviews Miss Them Conventional access review rarely catches this shape. It strains in the territory modern SaaS has opened up: non-human identities like service accounts, bots, and AI agents with no human behind them, trust relationships that form at runtime rather than at provisioning time, and OAuth and MCP bridges are wired between apps without the governance catalog knowing. Answering "who holds this scope plus those two other scopes, and what can those scopes accomplish together" becomes much harder once the scopes in question live on a token nobody provisioned through any identity system to begin with. The telemetry gap is widening quite fast. AI agents, MCP servers, and third-party connectors now sit across two or three adjacent apps by default, and non-human identities outnumber human ones in most SaaS environments. The Cloud Security Alliance's State of SaaS Security 2025 report found that 56% of organizations are already concerned about over-privileged API access across their SaaS-to-SaaS integrations. Things Worth Thinking About Closing the gap is largely a matter of shifting where review happens, from inside each app to between them. Here are a handful of things worth thinking about to address this type of issue: These are procedural disciplines more than product choices, and they work with whatever access review tooling is in place. The reality is that seeing these connections at scale is hard without a platform built to watch the runtime graph continuously. Manual review doesn't scale past the first few dozen integrations. Where Dynamic SaaS Security Platforms Fit In Dynamic SaaS security platforms automate the cross-app view that procedural review sets up. Where IGA inventories roles for onboarded systems, dynamic SaaS security watches the runtime graph continuously: which identities exist, which apps they touch, what scopes live on which tokens, and which trust relationships have been wired in after the last provisioning review. The monitoring has to run continuously, because the bridges these platforms need to catch are created at the speed of an MCP install or an OAuth consent click. Reco is one example of this category. Its platform connects identities, permissions, and data flows across the whole SaaS environment, so a combination of scopes in Slack, Drive, and Salesforce is evaluated as one exposure rather than three separate approvals. The first step is discovering every AI agent, integration, and OAuth identity operating across the environment, so the inventory any cross-app review depends on actually exists. Agents that security teams did not know were there, or agents that quietly gained new connections after initial onboarding, surface alongside the sanctioned ones. Once the agents are inventoried, Reco's Knowledge Graph maps every human and non-human identity to the apps it reaches and the bridges between them. When an MCP server connects an IDE to a messaging channel, or an AI agent wires a document store into a CRM, the graph surfaces the combination automatically and flags it as a permission breakdown no single app owner authorized. From there, Reco catches the moment an integration starts behaving outside what it was approved for, and revokes risky access before anyone gets a chance to use it. The chain, rather than the app, becomes the thing you review, and that shift is what makes toxic combinations visible in the first place. The next breach at most organizations won't announce itself with a new zero-day. It will look like an agent doing exactly what it was authorized to do, all the way through to exfiltration. Whether that gets caught at approval time or written up in a post-mortem comes down to whether anyone can see the full chain. Seeing the full chain is what Reco's Dynamic SaaS Security platform was built to do.

thehackernews.comApr 22, 2026extracted

Prompt injection tags along as GenAI enters daily government use

Prompt injection tags along as GenAI enters daily government use Routine use of GenAI has moved into daily operations in state and territorial government environments, placing new security risks within common workflows. A Center for Internet Security (CIS) report, Prompt Injections: The Inherent Threat to Generative AI, identifies prompt injection as a persistent concern tied to that adoption. Adoption expands exposure Use of AI tools has increased in government IT teams. A 2025 NASCIO survey of 51 state and territorial CIOs found that 82% reported employees using GenAI in daily work, up from 53% the prior year. Most organizations have moved beyond early testing, with widespread pilot programs, proofs of concept, and employee training already in place. AI, GenAI, and agentic AI ranked as the number one policy and technology priority for 2026. These tools support tasks such as summarizing documents, responding to emails, writing code, and managing schedules. “GenAI tools often have privileged access to systems and data, which enhances their operational value but also makes them appealing targets for threat actors,” the researchers wrote. Model behavior creates a security gap Prompt injection has been documented for more than a decade, with research tracing it back to 2013. Targeted training can improve how models handle these attacks, but studies indicate that training alone does not provide sufficient protection. The primary weakness lies in how language models process input. The report notes that LLMs do not separate instructions from other data. A model can process embedded malicious instructions in the same way as a normal request. This behavior enables two types of prompt injection. Direct prompt injection occurs through direct interaction with the model, including attempts to override safeguards. Indirect prompt injection places malicious instructions inside external content such as web pages, emails, or documents that AI systems later retrieve and process. “Prompt injections can poison GenAI agentic databases, allowing the attack to persist across user sessions and be referenced by other applications, as well as poison external datastores referenced by the GenAI ecosystem, like cloud storage and email inboxes. If GenAI applications are allowed to execute code, then they can be manipulated to do so remotely on behalf of attackers,” they warn. OWASP has identified prompt injection as the top risk category for GenAI and LLM applications. Examples show how attacks unfold Several proof-of-concept scenarios illustrate how prompt injection can move through connected AI systems and applications. One example involves an AI agent scanning a webpage. Hidden instructions embedded in markup, metadata, or rendered content can direct the agent to collect and transmit sensitive data. In a demonstration, a GenAI code assistant processed instructions hidden in a documentation page and sent code snippets and AWS API key data to an external URL. The destination service was allowlisted in default Antigravity settings. An additional case involved an update to the Amazon Q extension for Visual Studio Code in July 2025. The update introduced a prompt that instructed the AI agent to delete non-hidden files, terminate AWS servers, and remove cloud data. AWS issued a patch two days after the update and released a security bulletin. The Morris II worm demonstrates how prompt injection can propagate through systems. A malicious prompt embedded in an email entered a retrieval-augmented generation database through an AI email assistant. The assistant then generated additional emails containing the same malicious prompt along with sensitive information. The GeminiJack case involved malicious instructions embedded in enterprise data sources such as Google Docs or calendar entries. When retrieved through search, the instructions triggered data exfiltration to external infrastructure. Google later separated Vertex AI Search from Gemini Enterprise to address the issue. Controls focus on limiting access and oversight Organizations are advised to define acceptable use policies for AI tools and provide user training on handling sensitive data and recognizing malicious prompts. Other measures include keeping track of which systems and data AI platforms can reach, enforcing least privilege, and requiring human approval before actions that involve sensitive data or code execution. Regular log reviews can also help identify unusual behavior.

helpnetsecurity.comApr 9, 2026extracted

Managing open-source vulnerabilities | Kaspersky official blog

As we already talked in a previous post, modern software development is practically unthinkable without the use of open-source components. But in recent years the associated risks have become increasingly diverse, complex, and numerous. When, first, vulnerabilities affect a company’s infrastructure and code faster than they’re remediated; second, data is unreliable and incomplete; and third, malware may be lurking within popular components, it’s not enough to simply scan version numbers and toss fix-it tickets at the IT team. Vulnerability management must be expanded to cover software download policies, guardrails for AI assistants, and the entire software build pipeline. A trusted pool of open-source components The main part of the solution is to prevent the use of vulnerable and malicious code. The following measures should be implemented: Having an internal repository of artifacts. The sole source of components for internal development needs to be a unified repository to which components are admitted only after a series of checks. Performing rigorous component screening. These include checks of: known versions of the component, known vulnerable and malicious versions, publication date, activity history, and the reputation of the package and its authors. Scanning the entire contents of the package, including build instructions, test cases, and other auxiliary data, is mandatory. To filter the registry during ingestion, use specialized open-source scanners or a comprehensive cloud workload security solution. Running dependency pinning. Build processes, AI tools, and developers mustn’t use templates (such as “latest”) when specifying versions. Project builds need to be based on verified versions. At the same time, pinned dependencies must be regularly updated to the latest verified versions that maintain compatibility and are free of known vulnerabilities. This significantly reduces the risk of supply chain attacks through the compromise of a known package. Improving vulnerability data To identify vulnerabilities more effectively and prioritize them properly, an organization needs to establish several IT and security processes: Vulnerability data enrichment. Depending on the organization’s needs, this is needed either to enrich information by combining data from NVD, EUVD, BDU, GitHub Advisory Database, and osv.dev, or to purchase a commercial vulnerability intelligence feed where the data is already aggregated and enriched. In either case, it’s worth additionally monitoring threat intelligence feeds to track real-world exploitation trends and gain an insight into the profile of attackers targeting specific vulnerabilities. Kaspersky provides a specialized data feed specifically focused on open-source components. In-depth software composition analysis. Specialized software composition analysis (SCA) tools allow for the correct navigation of the dependency chain in open-source code to fully inventory the libraries being used, and discover outdated or unsupported components. Data on healthy components also comes in handy to enrich the artifact registry. Identifying abandonware. Even if a component isn’t formally vulnerable and hasn’t been officially declared unsupported, the scanning process should flag components that haven’t received updates for more than a year. These warrant separate analysis and potential replacement, much like EOL components. Securing AI code and AI agents The activities of AI systems used in coding must be wrapped in a comprehensive set of security measures — from input data filtering to user training: Restrictions on dependency recommendations. Configure the development environment to make sure that AI agents and assistants can only reference components and libraries from the trusted artifact registry. If these don’t contain the right tools, the model should trigger a request to include the dependency in the registry, rather than pulling something from PyPI that simply matches the description. Filter model outputs. Despite these restrictions, anything generated by the model must also be verified to ensure the AI code doesn’t contain outdated, unsupported, vulnerable, or made-up dependencies. This check should be integrated directly into the code acceptance process or the build preparation stage. It doesn’t replace the traditional static analysis process: SAST tools must still be embedded in the CI/CD pipeline. Developer training. IT and security teams must be intimately familiar with the characteristics of AI systems, their operating principles, and common errors. To achieve this, employees should complete a specialized training course tailored to their specific roles. Systematic removal of EOL components If a company’s systems utilize outdated open-source components, a systematic, consistent approach to addressing their vulnerabilities should be taken. There are three primary methods for doing this: Migration. This is the most organizationally complex and expensive method, involving the total replacement of a component followed by the adaptation, rewriting, or replacement of the applications built upon it. Deciding on a migration is especially daunting when it demands a massive overhaul of all internal code. This frequently affects core components — it’s impossible to migrate away from Node.js 14 or Python 2 easily. Long-term support (LTS). A dedicated support-services market exists for large-scale legacy projects. Sometimes this involves a fork of the legacy system maintained by third-party developers; in other cases, specialized teams backport patches that fix specific vulnerabilities into older, unsupported versions. Transitioning to LTS generally requires ongoing support costs, but this can still be more cost-effective than a full migration in many cases. Compensatory controls. Based on the results of detailed analysis, a set of wraparound security measures to mitigate the exploitation risk for the vulnerabilities within the legacy product can be made. Both the effectiveness and economic viability of this approach depend on the role of the software within the organization. Security, IT, and business must work together to choose one of these three paths for every documented EOL or abandoned component, and reflect the made choice in the company’s asset registries and SBOMs. Risk-based open-source vulnerability management All of the measures listed above reduce the volume of vulnerable software and components entering the organization, and simplify the detection and remediation of flaws. Despite this, it’s impossible to eliminate every single defect: the number of applications and components is simply growing too fast. Therefore, prioritizing vulnerabilities based on real-world risk remains essential. The risk assessment model must be expanded to account for the characteristics of open source, answering the following questions: Is the vulnerable code branch actually executed in the organization’s environment? A reachability analysis for discovered vulnerabilities should be performed. Many defective code snippets are never actually run within the organization’s specific implementation, making the vulnerability impossible to exploit. Certain SCA solutions can perform this analysis. This same process permits evaluating an alternative scenario: what happens if the vulnerable procedures or components are removed from the project entirely? Sometimes, this method of remediation proves to be surprisingly painless. Is the defect being exploited in real-world attacks? Is a PoC available? The answers to these questions are part of standard prioritization frameworks like EPSS, but tracking must be conducted across a much broader set of intelligence sources. Has cybercriminal activity been reported in this dependency registry, or in related and similar components? These are additional factors for prioritization. Considering these factors allows the team to allocate resources effectively and remediate the most dangerous defects first. Transparency is the new black The security bar for open-source software is only going to keep on rising. Companies developing applications — even for internal use — will face regulatory pressures demanding documented and verifiable cybersecurity within their systems. According to the estimates of Sonatype experts, 90% of companies globally already fall under one or more requirements to provide evidence of the reliability of the software they use; therefore, the experts deem transparency “the currency of software supply chain security”. By controlling the use of open-source components and applications, enriching threat intelligence, and strictly monitoring AI-driven development systems, organizations can introduce the innovations the business craves — all while clearing the high bar set by regulators and customers alike.

kaspersky.comApr 3, 2026extracted

Week in review: Self-spreading npm malware hits developers, Cisco SD-WAN 0-day exploited since 2023

Week in review: Self-spreading npm malware hits developers, Cisco SD-WAN 0-day exploited since 2023 Here’s an overview of some of last week’s most interesting news, articles, interviews and videos: Identity verification systems are struggling with synthetic fraud Fake and expired IDs keep showing up in routine customer transactions, from alcohol purchases to credit card applications. The problem shows up most often in industries that depend on fast onboarding and remote transactions, where identity checks rely heavily on scanned documents and automated workflows. Enterprises are racing to secure agentic AI deployments AI assistants are tied into ticketing systems, source code repositories, chat platforms, and cloud dashboards across many enterprises. In some environments, these systems can open pull requests, query internal databases, book services, and trigger automated workflows with limited human involvement. The State of AI Security 2026 from Cisco places this level of access inside a growing pattern of AI-driven operations that connect directly to core business systems. The hidden security cost of treating labs like data centers In this Help Net Security interview, Rich Kellen, VP, CISO at IFF, explains why security teams should not treat OT labs like IT environments. He discusses how compromise can damage scientific integrity and create safety risks that backups cannot fix. AI is becoming part of everyday criminal workflows Underground forums include long threads about chatbots drafting phishing emails, generating code snippets, and coaching social engineering calls. A new study examined conversations captured between January 1, 2025 and July 31, 2025 across dozens of cybercrime forums to map how AI tools are entering day to day criminal operations. AI-driven DAST reduces manual setup and surfaces exploitable vulnerabilities In this Help Net Security interview, Joni Klippert, CEO at StackHawk, discusses what defines DAST coverage in 2026 and why scan completion does not equal security. She explains how AI-driven DAST testing automates attack surface discovery, supports business-logic testing in pre-production, and reduces the manual setup that has limited adoption. Klippert also describes how organizations can implement runtime testing without instrumenting production systems. Review: Digital Forensics, Investigation, and Response, 5th Edition Digital Forensics, Investigation, and Response, 5th Edition presents a structured survey of the digital forensics discipline. The book spans foundational principles, platform specific analysis, specialized branches, and incident response integration. Open-source security debt grows across commercial software Open source code sits inside nearly every commercial application, and development teams continue to add new dependencies. Black Duck’s 2026 Open Source Security and Risk Analysis Report data shows that nearly all audited codebases contain open source components, with average component counts rising sharply over the past year. The $19.5 million insider risk problem Routine employee activity across corporate systems carries an average annual cost of $19.5 million per organization. That figure comes from the 2026 Cost of Insider Risks Global Report, conducted by the Ponemon Institute and based on data from 354 organizations that experienced one or more material insider related incidents over the past year. Industrial networks continue to leak onto the internet Industrial operators continue to run remote access portals, building automation servers, and other operational technology services on public IP address ranges. Palo Alto Networks, Siemens, and Idaho National Laboratory describe the scope of that exposure in the Intelligence-Driven Active Defense Report 2026. DeVry University’s CISO on higher education cybersecurity risk In this Help Net Security interview, Fred Kwong, VP, CISO at DeVry University, outlines how the university balances academic openness with cyber risk. He describes how systems for students are separated from back end operations to limit exposure. Japanese chip-testing toolmaker Advantest suffers ransomware attack Japanese tech testing company Advantest has suffered a ransomware attack, the company confirmed last Thursday, after detecting unusual activity within its IT environment on February 15, 2026. Fake troubleshooting tip on ClawHub leads to infostealer infection A new malware delivery campaign has hit ClawHub, the official online repository for “skills” that augment the capabilities of the popular OpenClaw AI agent. Unlike previous ones, this campaign does not aim to trick users into downloading a bogus, malicious skill. Self-spreading npm malware targets developers in new supply chain attack Security researchers have uncovered another supply chain attack targeting developers: 19 typosquatting npm packages published on npmjs.com that steal credentials, infect projects, and propagate themselves across developer environments. CISA flags exploited FileZen command injection bug, patch now! (CVE-2026-25108) CISA has added CVE-2026-25108, an OS command injection vulnerability in Soliton Systems’ FileZen secure file transfer solution, to its Known Exploited Vulnerabilities (KEV) catalog. The vendor has confirmed active exploitation, stating it has received multiple reports of damage caused by attackers abusing the flaw. SolarWinds Serv-U hit by four critical RCE-level vulnerabilities SolarWinds has fixed four critical vulnerabilities in its popular Serv-U file transfer solution, which is used by businesses and organizations of all sizes. If exploited, the flaws may allow attackers to create a system admin user and/or execute code as a privileged account. Threat actor leveraged Cisco SD-WAN zero-day since 2023 (CVE-2026-20127) A “highly sophisticated” cyber threat actor has been exploiting a zero-day authentication bypass vulnerability (CVE-2026-20127) in Cisco Catalyst SD-WAN Controller (formerly vSmart) and Cisco Catalyst SD-WAN Manager (formerly SD-WAN vManage), Cisco has announced. Scattered Lapsus$ Hunters seeks women for vishing attacks The Scattered Lapsus$ Hunters (SLH) hacking collective has launched a recruitment push aimed specifically at women, offering cash payments for participating in voice-phishing (vishing) attacks. A few days ago, threat intelligence firm Dataminr detected posts on a public Telegram channel advertising roles for female callers willing to conduct social-engineering phone operations. IronCurtain: An open-source, safeguard layer for autonomous AI assistants Veteran security engineer Niels Provos is working on a new technical approach designed to stop autonomous AI agents from taking actions you haven’t specifically authorized. Why SOCs are moving toward autonomous security operations in 2026 The modern security operations center faces a crisis of scale that human effort cannot fix. With alert volumes exponentially growing and threat actors automating their attacks, organizations must pivot to autonomous SOC strategies. This shift to AI-driven defense is the only way to survive the operational realities of 2026. Binding Operational Directive 26-02 sets deadlines for edge device replacement In this Help Net Security video, Jen Sovada, General Manager, Public Sector at Claroty, explains CISA’s Binding Operational Directive 26-02 and what it means for federal agencies. The directive requires agencies to inventory, report, decommission, and replace unsupported edge devices such as firewalls, routers, switches, load balancers, and wireless access points. Police seize 100,000 stolen Facebook credentials in cybercrime raid Officers from Poland’s Central Bureau for Combating Cybercrime (CBZC) dismantled an organized group that used phishing to seize Facebook accounts and extract BLIK payment codes from victims. Spanish police arrest suspected Anonymous members over DDoS attacks on government sites Spanish police (Guardia Civil) arrested four members of the hacktivist group Anonymous Fénix over DDoS attacks targeting ministries, political parties and public institutions. Police identified the organization’s leadership, including its administrator and moderator, who were arrested in May 2025 in Alcalá de Henares (Madrid) and Oviedo (Asturias). Security and complexity slow the next phase of enterprise AI agent adoption Enterprise AI agents are embedded in routine business processes, particularly inside engineering and IT operations. Many organizations report active production deployments, and agent development ranks high on strategic agendas. A new study from Docker, The State of Agentic AI Report, examines how enterprises are deploying agentic systems and the challenges emerging as deployments scale. Microsoft extends security patching for three Windows products at a price Support is ending for three Windows products released in 2016, with deadlines beginning in October 2026. Windows 10 Enterprise LTSB 2016 and Windows 10 IoT Enterprise 2016 LTSB will reach end of support on October 13, 2026, followed by Windows Server 2016 on January 12, 2027. International operation dismantles fraud network, €400,000 seized A coordinated international operation supported by Eurojust dismantled a fraudulent call centre operating from three offices and targeting citizens throughout Europe. Authorities arrested 11 suspects and seized more than €400,000 in cash. Teenagers charged over public bike service breach that exposed 4.62 million records Two South Korean teenagers have been charged in connection with a cyberattack that compromised the personal data of 4.62 million users of Seoul’s public bike service, Ttareungyi. The compromised data included user IDs, mobile phone numbers, addresses, dates of birth, gender, and weight. Airline brands become launchpads for phishing, crypto fraud Airline brands sit at the center of peak travel booking cycles, loyalty programs, and high value transactions. Criminal groups continue to register thousands of lookalike domains tied to these brands, targeting travelers, employees, and business partners. Recent threat intelligence from BforeAI’s PreCrime Labs identifies sustained impersonation activity across the global commercial airline sector. Cyber valuations climb as capital concentrates, AI security expands Venture funding in cybersecurity continued to concentrate in large private rounds at the end of 2025, driving valuations higher across stages. Data from DataTribe shows total capital invested approached $150 billion for the year, with a disproportionate share flowing into fewer than 100 deals. Ex-L3Harris executive sentenced to 87 months for selling stolen cyber-exploit trade secrets Peter Williams, a former executive of Trenchant, L3Harris’ cyber division, has been sentenced to 87 months in prison by a federal judge in Washington, D.C., after pleading guilty to stealing and selling sensitive cyber-exploit trade secrets to a Russian broker. Anthropic’s Remote Control feature brings Claude Code to mobile devices Anthropic has introduced a new Claude Code feature called Remote Control, allowing developers to continue a local coding session from a phone, tablet, or any web browser. The feature is rolling out as a research preview to Max users. Samsung’s Galaxy S26 turns privacy into a visible and invisible feature The Samsung Galaxy S26 series is out, offering plenty of security features that protect personal data while providing users with transparency and control over how their information is used. The feature that grabbed the spotlight is the built-in Privacy Display on the Galaxy S26 Ultra model, designed to help keep on-screen activity out of view in public places. Telegram rises to top spot in job scam activity Encrypted messaging platforms are becoming a primary channel for Authorised Push Payment (APP) fraud, with Telegram representing a growing share of reported cases, according to the Revolut report. NATO greenlights iPhone and iPad for classified information handling Apple confirmed that the iPhone and iPad have been approved for use with classified information in NATO restricted environments. The devices will no longer require special software or settings to handle NATO restricted-level information. Microsoft taps ASUS and Dell for the Windows 365 Cloud PC strategy Microsoft is adding two new Windows 365 Cloud PC devices, the ASUS NUC 16 for Windows 365 and the Dell Pro Desktop for Windows 365, expanding hardware options for its cloud-based desktop service. Both devices are scheduled for release in the third quarter of 2026, with distribution varying by region and model. Meta tightens grip on scam advertisers Meta is stepping up the fight against scams on its platforms by filing multiple lawsuits targeting companies and individuals in Brazil, China, and Vietnam who used deceptive tactics to run scam ads. The company said it has taken technical enforcement actions in these cases, including suspending payment methods used in the scams, disabling accounts linked to those operations, and blocking domains associated with scam sites. Coroot: Open-source observability and APM tool Coroot is an open-source observability and application performance monitoring tool. The core software, published in Go and accompanied by companion repositories such as coroot-node-agent, focuses on collecting telemetry data across systems. It uses extended Berkeley Packet Filter (eBPF) technology to gather metrics and trace inter-service communications without manual instrumentation of application code. Perplexity AI lands on Samsung’s next Galaxy lineup Samsung will add Perplexity to its upcoming Galaxy S26 devices as part of its Galaxy AI multi-agent ecosystem expansion. Users will be able to access Perplexity through quick-access controls, such as pressing and holding the side button, or by using the voice wake phrase “Hey, Plex.” WhatsApp is adding another lock to your account Meta has released WhatsApp Beta for Android 2.26.7.8 through the Google Play Beta Program. The update includes references to password-protected accounts, indicating plans to introduce an additional layer of protection beyond the app’s current authentication options. Windows 365 for Agents brings managed cloud PCs to autonomous workflows Microsoft’s Windows 365 for Agents is a cloud platform that gives AI agents secure access to cloud PCs. It lets builders run copilots, agents, and automated workflows in Windows environments without managing infrastructure. The platform includes security, policy controls, scalability, and visibility so agents can browse websites, process data, and complete tasks inside a managed cloud PC. Microsoft expands Sovereign Cloud security with governance, local productivity and AI Microsoft expands Microsoft Sovereign Cloud with new disconnected and AI capabilities that help organizations run critical infrastructure, productivity services and large AI models inside sovereign boundaries while keeping governance and operational continuity across connected and disconnected environments. Edge systems take the brunt of internet-wide exploitation attempts Internet-facing VPNs, routers, and remote access services absorbed sustained exploitation attempts throughout the second half of 2025, with nearly 3 billion malicious sessions recorded over 162 days. The concentration on edge infrastructure aligns with how attackers pursue initial access across the public internet. Microsoft adds domain libraries and Copilot integration to the quantum development kit The Microsoft Quantum Development Kit (QDK) is an open-source toolkit that runs on laptops and in common development environments. It includes code, simulators, libraries, and workflows that work with Visual Studio Code and GitHub Copilot. Integration with these tools gives developers features for writing, testing, debugging, and submitting quantum code. Apple blocks 18+ app downloads in select markets Apple has introduced expanded age assurance tools to help developers comply with regulations taking effect in Brazil, Australia, Singapore, Utah, and Louisiana. The updates, available in beta, expand the Declared Age Range API and related App Store systems. Reddit fined $19.5 million for failing to protect children’s personal data The UK’s Information Commissioner’s Office (ICO) has fined Reddit $19.5 million after finding that the company failed to use children’s personal information lawfully, exposing them to inappropriate and harmful content. Hottest cybersecurity open-source tools of the month: February 2026 This month’s roundup features exceptional open-source cybersecurity tools that are gaining attention for strengthening security across various environments. Wireshark 4.6.4 resolves dissector flaws, plugin compatibility issue Packet inspection remains a routine activity across enterprise networks, incident response workflows, and malware investigations. Continuous use places long-term stability and parsing accuracy at the center of daily operations. Wireshark version 4.6.4 addresses two vulnerabilities affecting protocol dissectors and resolves a plugin compatibility issue within the 4.6 release series. Fraudsters integrate ChatGPT into global scam campaigns AI models are being folded into fraud and influence operations that follow long standing tactics. A February 2026 update to OpenAI’s Disrupting Malicious Uses of Our Models report details how ChatGPT and related API access were used in romance scams, fake legal services, coordinated influence campaigns, and a state linked harassment effort. AWS Security Hub Extended brings enterprise security under one roof AWS Security Hub Extended is a plan within Security Hub that simplifies how customers procure, deploy, and integrate a full-stack enterprise security solution across endpoint, identity, email, network, data, browser, cloud, AI, and security operations. The CISO role keeps getting heavier Personal liability is becoming a routine part of the CISO job. In Splunk’s 2026 CISO Report, titled From Risk to Resilience in the AI Era, 78% of CISOs said they are concerned about their own liability for security incidents, up from 56% last year. The role carries personal exposure alongside operational accountability, and that shift is influencing how security leaders approach risk, documentation, and board communication. Android app uses Bluetooth signals to detect nearby smart glasses Smart glasses with built-in cameras are showing up in more public spaces, and a growing number of people want a way to know when one is nearby. An Android app called Nearby Glasses, developed by Yves Jeanrenaud, attempts to fill that gap by scanning Bluetooth Low Energy traffic for manufacturer identifiers associated with known smart glasses makers. Ransomware activity peaks outside business hours Intrusions continue to center on credential access and timed execution outside standard business hours. The Sophos Active Adversary Report 2026 analyzes 661 incident response and managed detection and response cases handled between November 1, 2024 and October 31, 2025, spanning organizations in 70 countries. Android 17 second beta expands privacy controls for contacts, SMS and local networks Google’s second beta of Android 17 continues updates to platform behavior and introduces new APIs focused on protecting sensitive data. Europol goes after The Com’s ransomware and extortion networks Law enforcement agencies across 28 countries have spent the past year building cases against a loosely organized collective known as The Com, a decentralized network of mostly teenagers and young adults linked to high-profile ransomware attacks, financial extortion, and the coercion of vulnerable children. Cybersecurity jobs available right now: February 24, 2026 We’ve scoured the market to bring you a selection of roles that span various skill levels within the cybersecurity field. Check out this weekly selection of cybersecurity jobs available right now. New infosec products of the month: February 2026 Here’s a look at the most interesting products from the past month, featuring releases from Aikido Security, Avast, Armis, Black Duck, Compliance Scorecard, Fingerprint, Gremlin, Impart Security, Portnox, Redpanda, Socure, SpecterOps, Veza, and Virtana.

helpnetsecurity.comMar 1, 2026extracted

AI is becoming part of everyday criminal workflows

AI is becoming part of everyday criminal workflows Underground forums include long threads about chatbots drafting phishing emails, generating code snippets, and coaching social engineering calls. A new study examined conversations captured between January 1, 2025 and July 31, 2025 across dozens of cybercrime forums to map how AI tools are entering day to day criminal operations. The dataset includes 163 discussion threads drawn from 21 forums, totaling 2,264 messages posted by 1,661 distinct contributors. Much of the activity clustered on well known platforms such as XSS, BreachForums, Dread, and Exploit.in. Four themes dominated the discussions: repurposing mainstream AI services, marketing criminal AI products, adapting models for specific operations, and debating operational risk. Mainstream tools drive experimentation Commercial chatbots serve as the starting point for many participants. ChatGPT appeared in 52.5 percent of the threads that mentioned legal AI products. DeepSeek followed at 27.9 percent, Claude at 19.7 percent, and Grok at 18.0 percent. Llama, Gemini, Mistral, Hugging Face, Manus AI, and WhiteRabbitNeo also appeared across multiple conversations. Open-source and locally hosted models drew attention for privacy and fewer built in content restrictions. Participants described running models offline to draft scripts, refine phishing language, and explore attack concepts. Discussions also covered the hardware and time required to train or fine tune a model for offensive tasks, with several contributors citing long development cycles even when using high end consumer GPUs. Jailbreaking remained common. Users shared prompts designed to bypass safety controls, including role play scenarios and instructions that attempt to override internal policies. Some threads focused on which models appeared more permissive during testing. Others described ways to obtain premium access through stolen or resold accounts. Listings included accounts with active subscriptions and instructions for abusing student verification flows. Criminal AI brands crowd the forums A second stream of activity involved tools marketed specifically for fraud, spam, and malware. Fifty threads centered on selling, requesting, or reviewing these products. Mentions clustered around a handful of names. WormGPT accounted for 26 percent of product mentions, FraudGPT for 18 percent, and DarkGPT for 16 percent. ChaosGPT, GhostGPT, and SpamGPT each appeared in 6 percent of mentions. Many offerings functioned as wrappers that resell access to mainstream models through a bot interface or API gateway paired with a jailbreak prompt. Threads described short lived services, disputes over quality, and concerns about logging or hidden collection features. Sellers also advertised custom development. Some offered to host large language models for clients lacking infrastructure. Others promoted AI enabled calling systems designed to automate outbound fraud operations and handle victim interactions. Monitoring how these products are marketed could offer early warning of broader adoption. Benoît Dupont, PhD, professor of criminology and co author of the study, told Help Net Security that defenders can track how often AI claims appear in underground sales listings. “We could monitor forums, markets and Telegram channels to assess what share of malicious products and services on sale claim to be powered or enabled by AI,” Dupont said. “This claim is often central to secure a competitive advantage, so sellers are unlikely to obfuscate this in their offerings. If we were able to reliably measure the share of AI powered cybercriminal products and services advertised, we could track when certain thresholds are being reached and could certainly state with more confidence that we are leaving the experimental phase for a more industrial phase. Of course, advertising does not mean adoption, but this is an indicator of the direction things are going.” Adaptation centers on scams and automation Higher skill discussions focused on adapting AI to specific workflows. Participants described using chatbots to rehearse social engineering scripts tailored to a target organization. Others outlined tools that generate variable spam content to evade filters by altering phrasing and structure. Call center automation featured prominently. Posts detailed virtual assistants that support human operators in real time by suggesting responses, extracting one time passwords, and forwarding victims to live agents. A smaller set of threads addressed malware development. Contributors emphasized the need for technical expertise to turn generated snippets into functioning payloads and delivery chains. Several elite forums added dedicated AI sections to concentrate discussion and attract specialists. Recruitment posts offered hourly assistance with model setup and integration into existing toolchains. Dupont expects fraud operations to integrate AI faster than other categories of cybercrime. “Social engineering and scamming operations will probably be able to leverage AI capacities more systematically, profitably and sooner than malware writing operations in the near future at least,” he said. “This very uncertain assessment is based on the fact that profit incentives and rewards are more accessible for AI enabled scams, but also because defensive AI systems are more systematically deployed to protect organizations, whereas individuals seem more exposed and benefit from limited AI enabled protection.” Skepticism and operational risk Skepticism ran through many conversations. Participants questioned the reliability of AI generated code for complex offensive tasks and cited frequent errors and hallucinated functions. Complaints about low quality forum posts generated by chatbots appeared across multiple communities, with members describing an increase in repetitive and derivative content. Operational security concerns also surfaced repeatedly. Contributors treated prompts and chat histories as sensitive data that platform operators can monitor and store. Advice circulated about minimizing identifying details in queries and rotating accounts. Similar caution applied to criminal AI services, where buyers expressed concern about logging, hidden backdoors, and potential interception of stolen data. Dupont said defenders can watch for measurable signals that point to scaled automation. “The defensive signals that could be monitored could include the volume in certain types of scam reported by victims, providing we can access these reports in real time, volume of phishing, vishing and smishing messages intercepted, level of sophistication of these messages and calls, level of coordination of certain calling and messaging campaigns, volume of new account generation among certain digital platforms used to enable online scams, to name a few,” he said. “Any fraud signal that scales up and demonstrates high levels of coordination should be examined carefully to determine whether AI tools are at play.” Across the seven month window, adoption clustered in fraud, scams, and social engineering workflows. A core group of innovators experimented with automation and new service models, and a wider set of users tested mainstream tools for drafting messages and refining scripts. The broader ecosystem shows an early stage of integration, with experimentation, marketing activity, and debate unfolding across multiple forums.

helpnetsecurity.comFeb 24, 2026extracted

Researchers Show Copilot and Grok Can Be Abused as Malware C2 Proxies

Cybersecurity researchers have disclosed that artificial intelligence (AI) assistants that support web browsing or URL fetching capabilities can be turned into stealthy command-and-control (C2) relays, a technique that could allow attackers to blend into legitimate enterprise communications and evade detection. The attack method, which has been demonstrated against Microsoft Copilot and xAI Grok, has been codenamed AI as a C2 proxy by Check Point. It leverages "anonymous web access combined with browsing and summarization prompts," the cybersecurity company said. "The same mechanism can also enable AI-assisted malware operations, including generating reconnaissance workflows, scripting attacker actions, and dynamically deciding 'what to do next' during an intrusion." The development signals yet another consequential evolution in how threat actors could abuse AI systems, not just to scale or accelerate different phases of the cyber attack cycle, but also leverage APIs to dynamically generate code at runtime that can adapt its behavior based on information gathered from the compromised host and evade detection. AI tools already act as a force multiplier for adversaries, allowing them to delegate key steps in their campaigns, whether it be for conducting reconnaissance, vulnerability scanning, crafting convincing phishing emails, creating synthetic identities, debugging code, or developing malware. But AI as a C2 proxy goes a step further. It essentially leverages Grok and Microsoft Copilot's web-browsing and URL-fetch capabilities to retrieve attacker-controlled URLs and return responses through their web interfaces, essentially transforming it into a bidirectional communication channel to accept operator-issued commands and tunnel victim data out. Notably, all of this works without requiring an API key or a registered account, thereby rendering traditional approaches like key revocation or account suspension useless. Viewed differently, this approach is no different from attack campaigns that have weaponized trusted services for malware distribution and C2. It's also referred to as living-off-trusted-sites (LOTS). However, for all this to happen, there is a key prerequisite: the threat actor must have already compromised a machine by some other means and installed malware, which then uses Copilot or Grok as a C2 channel using specially crafted prompts that cause the AI agent to contact the attacker-controlled infrastructure and pass the response containing the command to be executed on the host back to the malware. Check Point also noted that an attacker could go beyond command generation to make use of the AI agent to devise an evasion strategy and determine the next course of action by passing details about the system and validating if it's even worth exploiting. "Once AI services can be used as a stealthy transport layer, the same interface can also carry prompts and model outputs that act as an external decision engine, a stepping stone toward AI-Driven implants and AIOps-style C2 that automate triage, targeting, and operational choices in real time," Check Point said. The disclosure comes weeks after Palo Alto Networks Unit 42 demonstrated a novel attack technique where a seemingly innocuous web page can be turned into a phishing site by using client-side API calls to trusted large language model (LLM) services for generating malicious JavaScript dynamically in real time. The method is similar to Last Mile Reassembly (LMR) attacks, which involves smuggling malware through the network via unmonitored channels like WebRTC and WebSocket, and piecing them directly in the victim's browser, effectively bypassing security controls in the process. "Attackers could use carefully engineered prompts to bypass AI safety guardrails, tricking the LLM into returning malicious code snippets," Unit 42 researchers Shehroze Farooqi, Alex Starov, Diva-Oriane Marty, and Billy Melicher said. "These snippets are returned via the LLM service API, then assembled and executed in the victim's browser at runtime, resulting in a fully functional phishing page."

thehackernews.comFeb 17, 2026extracted

Microsoft Teams outage affects users in United States, Europe

Microsoft is working to resolve an ongoing outage affecting Microsoft Teams users, causing delays and preventing some from accessing the service. According to user reports on the when joining meetings with the Teams desktop client, accessing the Teams app, and signing in. "Users may experience delays and failures when sending and receiving chat messages that include inline media (images, code snippets, videos)," Microsoft said in an incident report tracked under TM1233974. "Impact is specific to some users located in Europe and United States who are served through the affected infrastructure attempting to send and receive chat messages that include inline media (images, code snippets, videos)." While Microsoft has not disclosed how many users are affected, this ongoing issue is tagged as causing "service degradation" and has been flagged as an incident, a term that is commonly used for critical service issues with noticeable user impact. Microsoft added that its engineers are currently reviewing service monitoring telemetry data to isolate the root cause behind the incident and to develop a remediation plan. Microsoft is also working to resolve an incident that blocks users from joining some Microsoft Teams meetings via the "Join" button in the meeting chat (tracked as TM1231009), and another incident that prevents some users from adding (or updating) Copilot Studio agents to Microsoft Teams (TM1218513). Another outage, also tagged as a critical service issue, took down multiple Microsoft 365 services in early October, including Microsoft Teams. The October 2025 incident also caused Multi-Factor Authentication (MFA) issues, affecting users who tried to access Microsoft 365 services via Microsoft Entra single sign-on (SSO). As Microsoft revealed at its 2024 Enterprise Connect conference, more than 320 million people use Teams each month. Update February 17, 10:46 EST: One hour into the outage, Microsoft says the Teams delays and access issues have now been addressed. "A subsection of service infrastructure, that facilitates underlying caching in Microsoft Teams, fell below our manageable service performance thresholds," Microsoft noted. "We reverted the configuration change to the last healthy version, and can confirm that impact is remediated after a period of monitoring service telemetry." Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

bleepingcomputer.comFeb 17, 2026extracted

The Next Frontier of Runtime Assembly Attacks: Leveraging LLMs to Generate Phishing JavaScript in Real Time

Executive Summary Imagine visiting a webpage that looks perfectly safe. It has no malicious code, no suspicious links. Yet, within seconds, it transforms into a personalized phishing page. This isn't merely an illusion. It's the next frontier of web attacks where attackers use generative AI (GenAI) to build a threat that’s loaded after the victim has already visited a seemingly innocuous webpage. In other words, this article demonstrates a novel attack technique where a seemingly benign webpage uses client-side API calls to trusted large language model (LLM) services for generating malicious JavaScript dynamically in real time. Attackers could use carefully engineered prompts to bypass AI safety guardrails, tricking the LLM into returning malicious code snippets. These snippets are returned via the LLM service API, then assembled and executed in the victim's browser at runtime, resulting in a fully functional phishing page. This AI-augmented runtime assembly technique is designed to be evasive: The code for the phishing page is polymorphic, so there’s a unique, syntactically different variant for each visit The malicious content is delivered from a trusted LLM domain, bypassing network analysis It is assembled and executed at runtime The most effective defense against this new class of threat is runtime behavioral analysis that can detect and block malicious activity at the point of execution, directly within the browser. Palo Alto Networks customers are better protected through the following products and services: Advanced URL Filtering Prisma AIRS Prisma Browser with Advanced Web Protection The Unit 42 AI Security Assessment can help empower safe AI use and development across your organization. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Our previous research shows how attackers can effectively use LLMs to obfuscate their malicious JavaScript samples offline. Reports from other sources have documented campaigns that leverage LLMs during runtime execution on compromised machines to tailor attacks (e.g., LLM-powered malware and ransomware). Anthropic researchers have also published reports indicating that LLMs have aided cybercriminals and played a role in AI-orchestrated cyberespionage campaigns. Motivated by these recent discoveries, we researched how threat actors could leverage LLMs to generate, assemble and execute phishing attack payloads within a webpage at runtime, making it challenging to detect with network analysis. Below we outline our proof of concept (POC) for this attack scenario and offer steps to help mitigate the impact of this potential attack. The attack scenario begins with a seemingly benign page. Once loaded in the victim's browser, the initial webpage makes requests for client-side JavaScript to popular and trusted LLM clients (e.g., DeepSeek and Google Gemini, though the PoC could be effective across a number of models.). Attackers can then trick the LLM into returning malicious JavaScript snippets using carefully engineered prompts that circumvent safety guardrails. These snippets are then assembled and executed in the browser's runtime to render a fully functional phishing page. This leaves behind no static, detectable payload. Figure 1 shows how we developed our PoC to leverage LLMs to enhance existing attacks and bypass defenses. The first two steps involve initial preparation, while the final step details the generation and execution of phishing code within the browser at runtime. The attacker’s first step would be to select a webpage from an active phishing or malicious campaign to use as a model for the type of malicious code that would perform the desired function. From there, they can create JavaScript code snippets that will be generated in real-time to dynamically render the final page displayed to the user. The attacker’s next step would be to craft prompts describing the JavaScript code's functionality to the LLM in plain text. They could iteratively refine prompts, generating malicious code that bypasses existing LLM guardrails. These generated snippets could differ structurally and syntactically, allowing attackers to create polymorphic code with the same functionality. From there, attackers could embed these engineered prompts inside a webpage, which would load on the victim's browser. The webpage would then use the prompt to request a popular, legitimate LLM API endpoint to generate malicious code snippets. These snippets could then be transmitted over popular, trusted domains to bypass network analysis. Subsequently, these generated scripts could be assembled and executed to render malicious code or phishing content. This technique builds upon existing evasive runtime assembly behaviors that we often observe on phishing and malware delivery URLs. For example, 36% of malicious webpages we detect daily exhibit runtime assembly behavior, such as executing constructed child scripts with an eval function (e.g., retrieved, decoded or assembled payloads). Leveraging LLMs during runtime on a webpage gives attackers the following benefits: Evading network analysis: The malicious code generated by an LLM could be transferred over the network from a trusted domain, as access to domains of popular LLM API endpoints is often allowed from the client side. Increasing the diversity of malicious scripts with each visit: An LLM can generate new variants of phishing code, leading to higher polymorphism. This can make detection more challenging. Using runtime assembly and executing JavaScript code to complicate detection: Assembling and executing these code snippets during runtime enables more tailored phishing campaigns, such as selecting a target brand based on the victim's location or email address. Obfuscating code in plain text: Translating code into text for subsequent concealment within a webpage can be viewed as a form of obfuscation. Attackers commonly employ various conventional techniques (e.g., encoding, encryption and code fragmenting) to visually conceal malicious code and evade detection. While advanced analyses often identify conventional obfuscation methods by evaluating expressions, it will be more challenging for defenders to evaluate text as executable code without subjecting each snippet to an LLM. In researching the PoC we were able to demonstrate how this augmentation could be applied to a real-world phishing campaign, illustrating its ability to enhance evasion techniques through the steps we outline above. A brief overview of this PoC is provided below. For our PoC, we replicated a webpage from an advanced real-world phishing campaign known as LogoKit. The original phishing attack uses a static JavaScript payload to transform a benign-looking web form into a convincing phishing lure. This script performs two key functions: personalizing the page based on the victim’s email in the address bar and exfiltrating captured credentials to an attacker's web server. Our PoC uses a popular LLM service, accessible via a chat API query from within the browser's JavaScript. To mitigate potential misuse by attackers, we are not disclosing the name of this specific API. We used this LLM API to dynamically generate the code necessary for credential harvesting and impersonate target webpages. Because the malicious payload is generated dynamically in the browser, the initial page transmitted over the network is benign, allowing it to inherently bypass network-based security detectors. The attack's success hinged on careful prompt engineering to bypass the LLM's built-in safeguards. We found simple rephrasing was remarkably effective. For instance, a request for a generic $AJAX POST function was permitted (shown in Figure 2), while a direct request for "code to exfiltrate credentials" was blocked. Furthermore, indicators of compromise (IoCs) (e.g., Base64-encoded exfiltration URLs) could also be hidden within the prompt itself to keep the initial page clean. The non-deterministic output of the model provided a high degree of polymorphism, with each query returning a syntactically unique yet functionally identical variant of the malicious code. For example, Figure 3 shows differences in code snippets highlighted in red. This constant mutation makes detection more difficult. Of note, LLM-generated code can include hallucinations but we mitigated this through prompt refinement and increased specificity, effectively reducing syntax errors. As a result, the final, highly specific prompt successfully generated functional code in most instances. The generated script was assembled and executed at runtime on the webpage to render the phishing content. This process successfully constructed a functional, brand-impersonating phishing page, validating the attack's viability (shown in Figure 4). The successful execution of the generated code, which rendered the phishing page without error, confirmed the efficacy of our PoC. Our attack model, demonstrated through a PoC, could be implemented in various ways. However, each methodology described in the PoC speaks to how an attacker connects to LLM APIs for transferring malicious code as snippets that are executed in the browser at runtime. As shown in our PoC, attackers could bypass security measures by directly connecting to a well-known LLM service API endpoint from a browser to execute code-generation prompts. Alternatively, they might use a backend proxy server on trusted domains or content delivery networks (CDNs) to connect to the LLM service for prompt execution. A further tactic could involve connecting to this backend proxy server via non-HTTP connections such as WebSockets, a method we have previously reported in phishing campaigns. Attackers have abused the trust of legitimate domains to circumvent detections in the past, as seen in instances like EtherHiding. In EtherHiding, attackers concealed malicious payloads on public blockchains associated with reputable and trusted smart contract platforms. The attack detailed in this article uses a combination of diverse, LLM-generated malicious code snippets and the transmission of this malicious code through a trusted domain, to evade detection. This article focuses on the conversion of malicious JavaScript code into a text prompt to facilitate the rendering of a phishing webpage. This methodology presents a potential vector for malicious actors to generate diverse forms of hostile code. For example, they could develop malware or establish a command-and-control (C2) channel on a compromised machine that generates and transmits malicious code from trusted domains associated with popular LLMs. The attack model presented here exemplifies runtime assembly behaviors, where malicious webpages are dynamically constructed within a browser. Prior research has also documented different variants of runtime assembly for crafting phishing pages or malware delivery. For example, this article mentions a technique where an attacker breaks down malicious code into smaller components, subsequently reassembling them for execution at runtime within the browser (termed by SquareX as last mile reassembling attack). Various reports describe attackers using HTML smuggling techniques to deliver malware. The attack model outlined in this post goes further, as it involves the runtime generation of novel script variants that are later assembled and executed, posing a significantly elevated challenge to detection. The dynamic nature of this attack in combination with runtime assembly in the browser makes it a formidable defense challenge. This attack model creates a unique variant for every victim. Each malicious payload is dynamically generated and unique, transmitted over a trusted domain. This scenario signals a critical shift in the security landscape. Detection of these attacks (while possible through enhanced browser-based crawlers) requires runtime behavioral analysis within the browser. Defenders should also restrict the use of unsanctioned LLM services at workplaces. While this is not a complete solution, it can serve as an important preventative measure. Finally, our work highlights the need for more robust safety guardrails in LLM platforms, as we demonstrated how careful prompt engineering can circumvent existing protections and enable malicious use. This article demonstrates a novel AI-augmented approach where a malicious webpage uses LLM services to dynamically generate numerous variants of malicious code in real-time within the browser. To combat this, the most effective strategy is runtime behavioral analysis at the point of execution through in-browser protection and by running offline analysis with browser-based sandboxes that render the final webpage. Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: Prisma AIRS customers can secure their in-house built GenAI applications against inputs that attempt to circumvent guardrails. Customers using Advanced URL Filtering and Prisma Browser (with Advanced Web Protection) are better protected against various runtime assembly attacks. Prisma Browser customers with Advanced Web Protection are protected against Runtime Re-assembly attacks from the first attempt, or "patient zero" hit, because the defense uses runtime behavioral analysis directly within the browser to detect and block malicious activity at the point of execution. The Unit 42 AI Security Assessment can help empower safe AI use and development across your organization. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. Now You See Me, Now You Don’t: Using LLMs to Obfuscate Malicious JavaScript – Unit 42, Palo Alto Networks First known AI-powered ransomware uncovered by ESET Research – ESET First Known LLM-Powered Malware From APT28 Hackers Integrates AI Capabilities into Attack Methodology – Cybersecurity News UAC-0001 Cyberattacks on Security/Defense Sector Using LLM-Based LAMEHUG Tool – CERT-UA [Ukrainian] AI-orchestrated cyber espionage campaigns [PDF] – Anthropic Report Attackers break malware into tiny pieces and bypass your Secure Web Gateway – SecurityBrief Australia What are Last Mile Reassembly Attacks? – SquareX “EtherHiding:” Hiding Web2 Malicious Code in Web3 Smart Contracts – Guardio

unit42.paloaltonetworks.comJan 22, 2026extracted

AI Supercharges Attacks in Cybercrime's New 'Fifth Wave'

AI is powering a “fifth wave” in the evolution of cybercrime, offering inexpensive, ready-made malicious tools enabling sophisticated attacks, according to Group-IB. In its latest report, published on January 20, the Singapore-based cybersecurity firm divided the history of cybercrime in four phases, from the opportunistic malware and viruses of the 1990s and early 2000s to “ecosystem and supply chain attacks” wave that marked the 2010s and 2020s. Since 2022, the firm argued, cybercrime has entered a fifth wave, which it called “weaponized AI.” This new era is marked by the rapid adoption of AI and generative AI (GenAI) tools by attackers that “turn human skills into scalable services” and make cybercrime “cheaper, faster and more scalable,” Dmitry Volkov, Group-IB’s CEO, said in the report’s foreword. Black Market Deepfake Kits Fuel Cybercrime for as Little as $5 One of the most striking misuses of GenAI, Group-IB argued, is in the creation of fake synthetic content impersonating real people. This content can be used lure other trusting people to execute tasks or to bypass authentication processes and know your customer (KYC) systems to gain access to devices, steal money or steal data. For instance, Group-IB analysts found “synthetic identity kits” offering AI video actors, cloned voices and even biometric datasets for as little as $5 and deepfake-as-a-service offerings for subscriptions starting at $10 per month. Additionally, the analysts recorded a spike in discussions about such AI-powered tools for criminal purposes in dark web forums over the past three years, from an average of below 50,000 messages on this topic from 2020 to 2022 to approximately 300,000 messages every year since 2023. During the report’s launch event in London, Anton Ushakov Group-IB’s cybercrime investigation unit leader, said these ready-made kits have become “a commodity” on dark web marketplaces. “What is really interesting is that not only pre-recorded deepfakes are popular, but also cheap tools enabling live deepfake schemes,” he added. “Of course, these will not convince 90% of people, but if it works in 5% to 10% of cases, it can be lucrative enough at this stage,” he noted. Phishing Kits Enter the Agentic AI Era Another major use of AI by cybercriminals highlighted in the Group-IB report is for phishing. Phishing kits are now listed at prices ranging “from as little as a Netflix subscription to $200 per month, making them accessible and affordable to groups big and small,” said the report. Ushakov’s team found that the new malicious AI capabilities are now used beyond simply assisting the attacker in the production of believable phishing emails. “AI is not only changing how phishing is generated, handled, hosted and run, but the way it’s distributed,” Ushakov said. He explained that, previously, criminals using phishing-as-a-service (PhaaS) kits would still need to configure everything, including SMTP servers and list of victims and run those campaigns. “Now, with the help of AI, and especially the open-weight models that are accessible, criminals are building the tools to automate these tasks,” Ushakov started. “They embed the models into the tools that are helping to scale and automate phishing campaigns in terms of the delivery. The models provide them with the list of the victims and sort of narrative that they want to use for the lures,” he continued. Group-IB found one service that “agentizes the phishing campaigns.” This tool uses AI agents to develop lures, send phishing emails to victims and returns information to the criminals with feedback, allowing them to adapt the campaign over time. “On the victim’s side, all the malicious emails feel personal and new ones keep being sent out by the phishing kit’s agent,” said Ushakov, who noted that the ‘agentized’ phishing kit appears to still be in a testing and development phase. Dark LLMs Grow in Sophistication Finally, Group-IB analysts also found that threat actors are moving past chatbot misuse and are creating proprietary “dark large language models” (LLMs) that are more stable, capable and have no ethical restrictions. From early experiments of rudimentary, open-access dark LLMs like WormGPT, these tools have now evolved into custom-built, self-hosted AI models optimized for generating harmful content, including malware, scams and disinformation. They have no ethical restrictions and are often fine-tuned on scam linguistics or malicious code and datasets. The dark LLMs assist in various cybercriminal activities, including: Fraud and scam content generation for romance, investment and impersonation scams Crafting phishing kits, fake websites and social engineering scripts Malware and exploit development support, including code snippets and obfuscation Initial access assistance with vulnerability reconnaissance and exploit chains The analysts identified at least three active vendors offering dark LLMs with subscriptions ranging from $30 to $200 per month, and a customer base exceeding 1000 users. One example, called Nytheon AI, is an unrestricted, self-hosted AI chatbot promoted on dark web forums as a fully offline, 80-billion-parameter, locally-hosted hybrid LLM hosted over TOR and blending open-source models like DeepSeek-v3, Mistral, Llama v3 Vision and some others. In April 2025, Group-IB investigations confirmed the sale of Nytheon AI on Telegram channels through a subscription-based model. Designed to provide uncensored chatbot responses, its advertised use cases include helping to develop malware, penetration testing, vulnerability research, fraud schemes and unfiltered information queries. The cybersecurity firm validated Nytheon AI’s AI functionality, technical capabilities and lack of ethical restrictions. Craig Jones, former Interpol director of cybercrime and independent strategic advisor for Group-IB argued that, while “AI hasn’t created new motives for cybercriminals,” it has industrialized cybercrime by “dramatically increasing the speed, scale and sophistication with which those motives are pursued.” “What once required skilled operators and time can now be bought, automated and scaled globally. That shift marks a new era, where speed, volume, and sophisticated impersonation fundamentally change how crime is committed and how hard it is to stop,” he concluded.

infosecurity-magazine.comJan 20, 2026extracted

DevOps & SaaS Downtime: The High (and Hidden) Costs for Cloud-First Businesses

Just a few years ago, the cloud was touted as the “magic pill” for any cyber threat or performance issue. Many were lured by the “always-on” dream, trading granular control for the convenience of managed services. In recent years, many of us have learned (often the hard way) that public cloud service providers are not immune to attacks and SaaS downtime, hiding behind the Shared Responsibility cushion. To stay operational, competitive, and resilient in today’s threat landscape, teams must move beyond the dependency on SaaS providers and understand what cyber resilience really means. The Myth of DevOps SaaS Resilience In 2024 alone, popular DevOps SaaS platforms—like GitHub, Jira, or Azure DevOps—experienced 502 incidents in total, which resulted in degraded performance and outages totaling over 4,755 hours. The conclusion is clear: Entrusting “the big players” with your source code, development metadata, and workflow projects doesn’t make your business immune to downtime and subsequent financial loss. The Numbers Say It All According to the 2024 CISO’s Guide to DevOps Threats report by GitProtect, leading cloud DevOps services suffered from 48 critical and major incidents. Comparing this with the 2025 edition of the report we’ve been working on by analyzing official providers’ and third-party communications (to be published soon), we can see a 69% increase year-over-year (YoY) with 156 critical and major incidents in total! The total time of service performance degradation jumped from 4,755 hours in 2024 to over 9,255 hours in 2025. Whether it’s total downtime, login failures, or sluggish responsiveness, these disruptions are becoming a relentless threat to daily operations. For detailed overviews of the most prominent incidents, we encourage you to look inside the report. The Model of Shared Responsibility The Shared Responsibility model is a common agreement between your business and a SaaS provider, where they are responsible for their cloud infrastructure, but you're responsible for your data within it, including source code repositories, metadata, issues, or anything else. Even though some providers might offer help in restoring data, the nature and scope of this help are not always clear. Ultimately, you bear the final responsibility. Furthermore, shared responsibility provisions might also apply to backups you make in the provider’s cloud, using native backup features. Some providers explicitly state that you can’t use such backups to revert certain types of changes (e.g., intentional deletion), leaving you exposed. The bottom line: No DevOps SaaS provider is contractually obligated to protect or restore your data. The Single Point of Failure Relying on the native DevOps cloud backups without a multi‑layered data protection strategy is becoming increasingly risky. First, backing up your code within the same infrastructure as your production creates a single point of failure. Everyone knows the proverb about not keeping all eggs in one basket. If, for example, Atlassian’s Jira is down, both your production and backup data might be unavailable as well, unless your SaaS provider has implemented properly isolated configurations. Native DevOps cloud backups are a baseline expectation, but in isolation, they are not a panacea. Other problems you might face include: Restore limitations: As mentioned earlier, native backups might be limited to restore scenarios defined precisely by your SaaS provider. As a result, you won’t be able to recover data or will need to negotiate with them to get real assistance at best. Lack of flexibility: Native backup mechanisms usually don’t offer any granularity of backup and restore. So, if you lose just a single branch of your project, you will need to recover everything, wasting time and resources. Data gaps: Given the dynamic nature of repositories with new pull/merge/push requests, or Jira with its work items, there’s a risk of native backup mechanisms creating data gaps that’ll turn out problematic during restore. The conclusion? Native backup from SaaS providers is not enough anymore, further contributing to the myth of SaaS resilience. What Are the Actual Problems for the Enterprise Customers of DevOps SaaS Providers? While high‑profile cyberattacks grab headlines, the everyday reality for SaaS cloud- dependent companies is that service outages inflict significant financial and operational damage. Research shows that downtime is far more than a technical inconvenience—it erodes revenue, productivity, and customer trust, among other things. Rising Costs of Downtime and Impact on Financial Liquidity For cloud-first organizations, upstream SaaS provider downtime can translate into hundreds of thousands or even millions of dollars in losses. Information Technology Intelligence Consulting survey found that the cost of hourly downtime exceeds $300,000 for 90% of mid-size and large firms.1 The situation becomes critical for large enterprises. Fortune 1000 companies can face hourly downtime costs ranging from $1 million to over $5 million. Other sources unanimously cite high costs of downtime, too. For example, in the Uptime Institute’s Annual outage analysis 2024, over half of the respondents reported that their most recent serious outage cost more than $100,000, while 16% cited the amount of more than $1 million.2 One thing is for certain: Downtime costs are already huge and are rising every year. While they are bearable (but still painful) for enterprises, they might seriously impact the finances of smaller software vendors, or even cause them to close down completely. Engineering and Operational Paralysis The failure of your SaaS cloud provider can paralyze your research and development (R&D) or even the whole business activity. Especially when you heavily rely on the cloud, treating it like a kind of ‘central nervous system’ orchestrating your operations. Being cloud-first might be convenient, but if the cloud’s on fire, you’re burning, too. See how it can affect you from the technical perspective: Source control management (SCM) freeze—your developers can’t push pull requests to remote git repositories, and managers or seniors can’t run checks, review, or accept them. Workflow chaos—if a task management SaaS like Jira fails, and your team can’t access projects and issues, no one knows what to do next. No access to dependencies—if, for example, GitHub Packages or Azure Artifacts don’t work, the functionalities of your app that use dependencies won’t work either. Knowledge source loss—your team can’t access issues and wikis to consult information, check facts, or prioritize bugs. Testing stops—with the testing orchestrator module like GitHub Actions or Azure Pipelines down, test & validation stages are interrupted. Others (authentication fails, no centralized communication, etc.) As you can see, the impact can be enormous, disrupting your business in many ways. Affected Customers, Reputation, and SLAs This paralysis can lead to failed or delayed projects, impacting your organization’s customers or partners. This eroded trust can, in turn, lead to reputation losses that translate into real financial costs. And if you're a software vendor creating apps under demanding Service Level Agreements (SLA), downtime can mean real problems. It can halt a critical release or a hotfix for a customer-facing error. Many SLAs require these fixes within 4–8 hours. Failing to meet these "Resolution Times" often results in contractual penalties, adding to the total cost of the outage. Security Risks Under pressure to meet deadlines during an outage, teams often turn to Shadow IT—using unsanctioned software or workarounds without IT oversight. This might include sharing code snippets, confidential information, or credentials over Slack or personal email. Such practices are highly undesirable for these reasons: potential code and know-how leaks, potential intellectual property loss, creating vulnerabilities in your code (once third-party intercepts it), creating vulnerabilities in your environment (if users also share credentials). The hidden threat? Your organization may become compromised long after the downtime actually happened. And it’s just another cost, isn’t it? Compliance Issues Especially when you belong to a regulated industry, you must ensure compliance in different areas of your business operations, including data protection. SaaS downtime (as well as other disastrous events like accidental data deletion) might expose your insufficient measures, which, for your business, might mean audit failure, unsuccessful certification, or even additional costs. Native backup might turn out insufficient to cover each recovery scenario. Just to remind you, the obligation to backup your data is defined in many regulations and industry standards: Article 21 of the NI2 Directive, area: Business continuity, such as backup management and disaster recovery, and crisis management. The A.8.13 (Information backup) control is defined in Annex A to ISO 27001 standard. The Trust Services Criteria (TSC), like Availability (A1.2), Security (CC7.1,) under SOC2. How to Create a Setup that Protects You against Downtime To improve immunity to downtime incidents affecting your upstream SaaS provider, you need a shift from being reactive to proactive. You need a plan B. Resiliency Strategy to Minimize Impact True availability is not about if systems fail, it’s about how quickly you can recover and resume business as usual. That’s why an effective resiliency strategy for your business should include: Frequent and comprehensive backups covering not just source code or issues, but also configurations and metadata. The data should allow you to quickly recreate your setup locally (e.g., using a self-managed solution like Azure DevOps Server or Bitbucket Data Center) or with a competitive cloud vendor, using the cross-restore functionality. Immutable and isolated storage that doesn’t rely on a single cloud vendor’s infrastructure. The safest option is to ensure copy replication, following the popular 3-2-1 backup rule, where you keep 3 separate copies in 2 different locations, storing 1 copy offsite. It’s also a good idea to set up optimal data retention that fits your project lifecycle and needs. Integrated restore orchestration that understands dependencies across services, APIs, and environments to be able to resume quickly, without organizational chaos. Continuous testing of recovery flows to avoid making your backup another risk. Clearly defined backup KPIs like Recovery Time Objective (RTO) and Recovery Point Objective (RPO) to know how much time you need to resume after a disaster and how often to back up your SaaS data to prevent loss. Extra Benefits for Your Organization A robust backup and recovery solution can be the pillar of your resiliency strategy against SaaS downtime. At the same time, it can bring extra convenience and security for your cloud-stored repositories or projects. Here’s what you can get as a bonus: Migrating/merging SaaS environments—with a backup tool, you can migrate to a different SaaS provider or cloud region; it’s also possible to consolidate repositories or Jira instances in case of restructuring, mergers, department moves, etc. Sandboxing—you can use a backup copy to quickly create a sandbox environment for testing new integrations, configuration changes, etc. Retention and archiving for compliance—combining a backup tool with your storage, you can go well beyond retention periods of SaaS providers. You can also archive legacy repositories or Jira projects without losing access to them. That way, you can still access historical data while saving space in SaaS. Selective restores—you can fix accidental or malicious deletion of a branch or several Jira issues in an instant, saving time and remaining agile. Storage sovereignty—you can implement on-premises deployments where your most precious data (know-how, intellectual property, customers’ and partners’ personal information) never leaves your infrastructure. And many more. Trust the Experienced DevSecOps Experts DevOps SaaS platforms—just like any IT environment—can’t give you 100% security and uptime. The well-planned resiliency strategy is a must if you want to focus on innovation rather than firefighting outages in the future. The GitProtect Team can help you with that. Thanks to over 15 years’ experience in the backup industry and our unique focus on SaaS and DevSecOps, we can together develop a strategy that’s the most beneficial and optimized for your very needs. Visit GitProtect.io, meet the product, and contact our experts to discuss your use case, personalize the setup, and efficiently protect what’s most precious.

thehackernews.comJan 19, 2026extracted

GoBruteforcer Botnet Targets Crypto Project Databases by Exploiting Weak Credentials

A new wave of GoBruteforcer attacks has targeted databases of cryptocurrency and blockchain projects to co-opt them into a botnet that's capable of brute-forcing user passwords for services such as FTP, MySQL, PostgreSQL, and phpMyAdmin on Linux servers. "The current wave of campaigns is driven by two factors: the mass reuse of AI-generated server deployment examples that propagate common usernames and weak defaults, and the persistence of legacy web stacks such as XAMPP that expose FTP and admin interfaces with minimal hardening," Check Point Research said in an analysis published last week. GoBruteforcer, also called GoBrut, was first documented by Palo Alto Networks Unit 42 in March 2023, documenting its ability to target Unix-like platforms running x86, x64, and ARM architectures to deploy an Internet Relay Chat (IRC) bot and a web shell for remote access, along with fetching a brute-force module to scan for vulnerable systems and expand the botnet's reach. A subsequent report from the Black Lotus Labs team at Lumen Technologies in September 2025 found that a chunk of the infected bots under the control of another malware family known as SystemBC were also part of the GoBruteforcer botnet. Check Point said it identified a more sophisticated version of the Golang malware in mid-2025, packing in a heavily obfuscated IRC bot that's rewritten in the cross-platform programming language, improved persistence mechanisms, process-masking techniques, and dynamic credential lists. The list of credentials includes a combination of common usernames and passwords (e.g., myuser:Abcd@123 or appeaser:admin123456) that can accept remote logins. The choice of these names is not happenstance, as they have been used in database tutorials and vendor documentation, all of which have been used to train Large language models (LLMs), causing them to produce code snippets with the same default usernames. Some of the other usernames in the list are cryptocurrency-focused (e.g., cryptouser, appcrypto, crypto_app, and crypto) or target phpMyAdmin panels (e.g., root, wordpress, and wpuser). "The attackers reuse a small, stable password pool for each campaign, refresh per-task lists from that pool, and rotate usernames and niche additions several times a week to pursue different targets," Check Point said. "Unlike the other services, FTP brute-force uses a small, hardcoded set of credentials embedded in the bruteforcer binary. That built-in set points to web-hosting stacks and default service accounts." In the activity observed by Check Point, an internet-exposed FTP service on servers running XAMPP is used as an initial access vector to upload a PHP web shell, which is then used to download and execute an updated version of the IRC bot using a shell script based on the system architecture. Once a host is successfully infected, it can serve three different uses - Run the brute-force component to attempt password logins for FTP, MySQL, Postgres, and phpMyAdmin across the internet Host and serve payloads to other compromised systems, or Host IRC-style control endpoints or act as a backup command-and-control (C2) for resilience Further analysis of the campaign has determined that one of the compromised hosts has been used to stage a module that iterates through a list of TRON blockchain addresses and queries balances using the tronscanapi[.]com service to identify accounts with non-zero funds. This indicates a concerted effort to target blockchain projects. "GoBruteforcer exemplifies a broader and persistent problem: The combination of exposed infrastructure, weak credentials, and increasingly automated tools," Check Point said. "While the botnet itself is technically straightforward, its operators benefit from the vast number of misconfigured services that remain online." The disclosure comes as GreyNoise revealed that threat actors are systematically scanning the internet for misconfigured proxy servers that could provide access to commercial LLM services. Of the two campaigns, one has leveraged server-side request forgery (SSRF) vulnerabilities to target Ollama's model pull functionality and Twilio SMS webhook integrations between October 2025 and January 2026. Based on the use of ProjectDiscovery's OAST infrastructure, it's posited that the activity likely originates from security researchers or bug bounty hunters. The second set of activity, starting December 28, 2025, is assessed to be a high-volume enumeration effort to identify exposed or misconfigured LLM endpoints associated with Alibaba, Anthropic, DeepSeek, Google, Meta, Mistral, OpenAI, and xAI. The scanning originated from IP addresses 45.88.186[.]70 and 204.76.203[.]125. "Starting December 28, 2025, two IPs launched a methodical probe of 73+ LLM model endpoints," the threat intelligence firm said. "In eleven days, they generated 80,469 sessions – systematic reconnaissance hunting for misconfigured proxy servers that might leak access to commercial APIs."

thehackernews.comJan 12, 2026extracted

VVS Discord Stealer Using Pyarmor for Obfuscation and Detection Evasion

Executive Summary This article details our technical analysis of VVS stealer, also styled VVS $tealer, including its distributors’ use of obfuscation and detection evasion. The stealer is written in Python and targets Discord users, exfiltrating sensitive information like credentials and tokens stored in Discord accounts. This stealer was once in active development and marketed for sale on Telegram as early as April 2025. VVS stealer's code is obfuscated by Pyarmor. This tool is used to obfuscate Python scripts to hinder static analysis and signature-based detection. Pyarmor can be used for legitimate purposes and also leveraged to build stealthy malware. Malware authors are increasingly leveraging advanced obfuscation techniques to evade detection by cybersecurity tools, making their malicious software harder to analyze and reverse-engineer. This article shows how we deobfuscated VVS stealer samples to better understand its operations. Because Python is easy for malware authors to use and the complex obfuscation used by this threat, the result is a highly effective and stealthy malware family. Palo Alto Networks customer are better protected through the following products and services: Advanced WildFire Advanced URL Filtering and Advanced DNS Security Cortex XDR and XSIAM prevents the threats described in this article by employing the Malware Prevention Engine If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Discord is a social messaging and communications platform that has become a popular target for malware, like VVS stealer. VVS stealer is designed to steal a victim's Discord information and browser data. Figure 1 shows VVS stealer's advertised capabilities, including: Stealing Discord data (tokens and account information) Intercepting active Discord sessions via injection Extracting web browser data (cookies, passwords, browsing history and autofill details) The stealer also achieves persistence by automatically installing itself on startup. It operates stealthily by displaying fake error messages and capturing screenshots. For a deeper investigation into the operation, please refer to the article by DeepCode, Investigating VVS $tealer: A Python-Based Discord Malware. This section analyzes a Pyarmor-protected VVS stealer malware sample with the following SHA-256 hash: c7e6591e5e021daa30f949a6f6e0699ef2935d2d7c06ea006e3b201c52666e07 Figure 2 shows a summary diagram illustrating the entire sample analysis workflow. The sample we analyzed is distributed as a PyInstaller package. PyInstaller is a tool that bundles a Python application and its dependencies into a package to allow execution of a packaged app without installing additional modules. Any standard PyInstaller installation ships with the built-in utility pyi-archive_viewer. We used this utility to extract and inspect the following files from our sample: The Python bytecode file named vvs The Pyarmor runtime dynamic-link library (DLL) file named pyarmor_runtime.pyd, located under subfolder pyarmor_runtime_007444 - The accompanying init.py file within this same subfolder, which includes the following information: - Pyarmor version: 9.1.4 (Pro) - Unique license number: 007444 - Timestamp: 2025-04-27T11:04:52.523525 - Product name: vvs The accompanying init.py file within this same subfolder, which includes the following information: Python 3.11 DLL file named python311.dll - The file version information indicates the Python version is 3.11.5 PyInstaller stores Python bytecode (listed as 1.) in its raw form. This raw form refers to the bytecode sequence beginning with the value e3. The value e3 is a combination of both flag and type, combined via the constant FLAG_REF. The type represented by the value e3 is computed as: type = e3 & ~FLAG_REF. This means the value e3 is actually the type 0x63 (the letter c), also known as the enumeration constant TYPE_CODE. The full implementation of this derivation can be found in the CPython 3.11 codebase. Figure 3 below shows this code object serialized by the marshal module is bare, missing an accompanying 16-byte header (marked in blue). To provide enough Python for the decompiler not to reject the file, we need to restore at least one of the header values (Python 3.11.5 magic number in 4-byte, little-endian format) prior to decompilation, because the Python decompiler expects a valid Python bytecode (.pyc) file as its input. We begin our analysis by decompiling the Python bytecode .pyc) file named vvs to recover its equivalent Python source code (.py). Pycdc is a Python bytecode decompiler written in C++. It is part of the Decompyle++ project. It supports decompiling Python 3.11 bytecode “back into valid and human-readable Python source code.” (Source: GitHub.) PyLingual is another Python bytecode decompiler. After cloning the code repository and compiling the codebase, the generated executable can be invoked as follows to decompile Python bytecode to Python source code via Pycdc: pycdc.exe -c -v "3.11.5" "vvs.pyc" > "vvs.py" This will produce the decompiled Python source code shown in Figure 4. We then analyze the last function argument, which can be extracted via Python 3's ast.NodeVisitor. The payload begins with the Pyarmor header shown in Figure 5. Cryptography is performed throughout using the Advanced Encryption Standard (AES) algorithm with a 128-bit key, operating in Counter (CTR) mode with an initial value of two (i.e., AES-128-CTR). Table 1 shows the breakdown of the fields. Table 1. Breakdown of fields present in the Pyarmor header. This same pattern (highlighted in yellow) repeats itself once again after the end of the ELF payload, for extracting and decrypting the Pyarmor bytecode payload. BCC (likely an abbreviation of ByteCode-to-Compilation) mode converts most “functions and methods in the scripts to equivalent C functions. Those C functions will be compiled to machine instructions directly, then called by obfuscated scripts.” (Source: Pyarmor documentation.) BCC mode is invoked as follows: pyarmor gen --enable-bcc script.py. These converted C functions are stored in a separate ELF file, produced alongside the Pyarmor-marshaled bytecode. The mapping of Python constants to BCC functions can be obtained using this implementation. For instance, in the Python method get_encryption_key(browser_path), the constant pyarmor_bcc_58580 maps to the BCC function bcc_180, whose function body is located at offset 0x4e70 of the ELF file. Referencing this analysis of the ELF file contents, especially the bcc_ftable structure, Figure 6 shows part of the BCC function bcc_180 decompiled: We can roughly recover an equivalent of the original code of the Python method get_encryption_key, as shown in Figure 7. Pyarmor 9 marshaled bytecode differs from standard Python 3.11 bytecode in several ways. Firstly, the 0x20000000 bit is set in the co_flags field to indicate that it is Pyarmor obfuscated. Secondly, there is an extra data field, whose length is denoted by the value of its first byte. Moreover, deopt_code() needs to be disabled for the bytecode sequence to be successfully decrypted. We will discuss the cryptographic parameters in a later section of this article. Pyarmor code objects are specially crafted, in that they should contain certain artifacts. It is common to expect to find the LOAD_CONST pyarmor_enter_* instruction in the preamble and the LOAD_CONST pyarmor_exit_* instruction in the trailer of the disassembly. These two instructions would wrap the encrypted bytecode, as shown in Table 2. Table 2. Pyarmor-related instructions in the disassembly listing of . Once the encrypted bytecode sequence is decrypted, it could reveal encrypted strings or BCC function invocations. Encrypted strings (reviewed in a later section of this article) are preceded by a LOAD_CONST pyarmor_assert_* instruction. There is also the LOAD_CONST pyarmor_bcc_* instruction to invoke a BCC function (reviewed earlier in this article). Bytecode sequences between the start marker (pyarmor_enter_*) and the end marker (pyarmor_exit_*) are AES-128-CTR encrypted. The associated AES key (273b1b1373cf25e054a61e2cb8a947b8) is extracted from the Pyarmor runtime DLL linked to the unique license number. On the other hand, the corresponding AES nonce exclusive OR (XOR) key (2db99d18a0763ed70bbd6b3c) is only specific to the Pyarmor bytecode payload, for which there is an implementation of the logic for extracting this value. This key is XORed with the 12 bytes at the end marker (pyarmor_exit_*) to produce the correct AES nonce used in the decryption. Similarly, string constants longer than eight characters are AES-128-CTR encrypted (known as "mixed" in Pyarmor terminology”). The associated AES key is also 273b1b1373cf25e054a61e2cb8a947b8, but this time, the corresponding AES nonce (692e767673e95c45a1e6876d) is computed from the Pyarmor runtime DLL linked to the unique license number. Additionally, a 0x81 prefix value denotes that the string constant is encrypted. Otherwise, a 0x01 prefix value is used instead. Now that the Pyarmor protection is disarmed, we shall proceed to cover some of the key capabilities of the VVS stealer in the next section. With the layers of Pyarmor obfuscation — including the BCC mode and AES-128-CTR string encryption — successfully stripped away, we were able to expose the underlying Python logic. This deobfuscated code revealed a stealer designed not just for data exfiltration, but for active session hijacking and persistence. The following section details the specific operational capabilities of the VVS stealer that were uncovered during this analysis. The malware sample expires after 2026-10-31 23:59:59. It will stop working by terminating itself prematurely. The malware sample performs all HTTP requests by sending the fixed User-Agent string Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36. We shall now provide an overview of the main malware capabilities, as advertised on Telegram. The malware sample first searches for potential encrypted Discord tokens. Encrypted Discord tokens are strings beginning with the prefix dQw4w9WgXcQ:. The malware sample uses regular expressions to form a pattern from this string prefix. It then uses this pattern to search inside the contents of files with the .ldb or .log file extensions, stored within the LevelDB directory. Next, the malware sample decrypts the encrypted_key value in the Local State file, via the Data Protection Application Programming Interface (DPAPI). With this decrypted encrypted_key value as the AES key parameter, the malware sample applies the AES algorithm, operating in Galois/Counter Mode (GCM) mode, on the encrypted Discord tokens, to decrypt them. The malware sample then uses the decrypted Discord tokens to query various Discord application programming interface (API) endpoints for user information, including: Nitro subscription (Discord Premium features) Payment methods User ID Username Phone number Friends Guilds Multifactor authentication (MFA) status Locale Verification status Avatar image IP address (via the ipify service) Computer name After gathering all this information, the malware sample proceeds to exfiltrate it in JavaScript Object Notation (JSON) format. The exfiltration takes place via HTTP POST requests to the predefined webhook endpoints (%WEBHOOK% environment variable and hard-coded fall back URLs). Webhooks are “a low-effort way to post messages to channels in Discord. They do not require a bot user or authentication to use.” (Source: Discord Developer Portal.) The code responsible for this functionality is in class Inj, likely an abbreviation of Injection. In this class, the malware sample first kills running Discord application processes, if any are running. It then downloads the JavaScript (JS) payload from a remote file named injection-obf.js (the -obf suffix likely stands for an obfuscated version of the script), replacing the webhook endpoint URL and discord_desktop_core, into the Discord application directory. This JS file is obfuscated by the JavaScript Obfuscator Tool and can be deobfuscated via the Obfuscator.io Deobfuscator. Some of the main functionality of the injected JS code is highlighted in the following screenshots, starting with its configuration and exfiltration code snippets, shown in Figure 8. Figure 8 shows the injected JS code responsible for establishing persistence in the Discord application, based on the Electron framework. This framework uses Atom Shell Archive Format (ASAR) archives to bundle the entire application's codebase into a single file, shown in Figure 9. Figure 10 shows the injected JS code responsible for monitoring network traffic via the Chrome DevTools Protocol (CDP). Figure 11 shows supporting utility functions and event hooks in the injected JS code. Event hooks are callback functions that execute upon the Discord application user performing a specific action. The actions of interest are when the user views their backup codes, changes their password or adds a payment method. The callback functions linked to these actions are capable of collecting Discord user account and billing information. Thereafter, the malware sample restarts a compromised Discord application process via Update.exe, which it does with the command-line switch --processStart. The malware sample targets a list of web browser applications, including: Chrome Edge 7Star Amigo Brave CentBrowser Discord Epic Privacy Browser Iridium Kometa Lightcord Mozilla Firefox Opera Orbitum Sputnik Torch Uran Vivaldi Yandex To these targets, the malware sample extracts the following data, where present: Autofill Cookies History Passwords Once these data are extracted, the malware sample prepares it for exfiltration by compressing it into a single ZIP archive file named _vault.zip. It then exfiltrates this file via HTTP POST requests to the predefined webhook endpoints, similar to the Discord data exfiltration process. The malware sample copies itself to the %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup folder to achieve startup persistence. The malware remains on the user’s device, enabling it to continue exfiltrating data if, for example, the user attempts to install a fresh copy of the Discord application. The malware sample uses the Win32 API, specifically the MessageBoxW function in the User32.dll library, to display a modal message box about a fake fatal error that requires restarting the computer. A modal message box is a small dialog window requiring user interaction before the application can continue, as shown in Figure 12. VVS stealer demonstrates how tools like Pyarmor, which can be used for legitimate purposes, can also be leveraged to build stealthy malware aimed at hijacking credentials for popular platforms such as Discord. Its emergence signals a need for defenders to strengthen monitoring around credential theft and account abuse. Palo Alto Networks customers are better protected from the threats discussed above through the following products: The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Cortex XDR and XSIAM prevents the threats described in this article by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. SHA-256 hashes of malware samples: 307d9cefa7a3147eb78c69eded273e47c08df44c2004f839548963268d19dd87 7a1554383345f31f3482ba3729c1126af7c1d9376abb07ad3ee189660c166a2b c7e6591e5e021daa30f949a6f6e0699ef2935d2d7c06ea006e3b201c52666e07 Discord webhook URLs hxxps[://]ptb.discord[.]com/api/webhooks/1360401843963826236/TkFvXfHFXrBIKT3EaqekJefvdvt39XTAxeOIWECeSrBbNLKDR5yPcn75uIqKEzdfs9o2 hxxps[://]ptb.discord[.]com/api/webhooks/1360259628440621087/YCo9eVnIBOYSMn8Xr6zX5C7AJF22z26WljaJk4zr6IiThnUrVyfWCZYs6JjSC12IC8c0 Unpacking Pyarmor v8+ scripts – Leonard Rapp and Hendrik Eckardt, G DATA Advanced Analytics GmbH Obfuscated Malicious Python Scripts with PyArmor – Xavier Mertens, SANS Internet Storm Center

unit42.paloaltonetworks.comJan 2, 2026extracted

Nissan Confirms Impact From Red Hat Data Breach

Japanese car maker Nissan has disclosed the impact of a data breach involving a self-managed GitLab instance used by the Red Hat Consulting team. The incident leading to the Nissan data breach occurred in late September and involved unauthorized access to a GitLab instance containing example code snippets, internal communications, and project specifications. A hacking group named Crimson Collective attempted to extort Red Hat, claiming the theft of 570 Gb of compressed data from 28,000 private repositories, including information that allegedly provided access to Red Hat customers’ infrastructure. Nissan now says that some of the data stolen from Red Hat’s instances included personal information of 21,000 customers of Nissan Fukuoka Sales (previously Fukuoka Nissan Motor). The personal information, the car maker says, includes names, addresses, phone numbers, partial email addresses, and information used for sales activities. No credit card data was stolen, and no other customer information was stored in the compromised repository, Nissan says. The company says that Red Hat notified it of the incident on October 3, roughly a week after the attack occurred. “Nissan received a report from RedHat, which had outsourced the development of a customer management system for a sales company, that it had unauthorized access to its data servers and leaked data,” an automated translation of Nissan’s incident notice reads. The Japanese company says it has reported the incident to the relevant authorities, and has been notifying the individuals impacted by the data breach. Nissan also notes that it could not confirm reports that the stolen information might have been “used twice” by the threat actors. Related: 3.5 Million Affected by University of Phoenix Data Breach Related: University of Sydney Data Breach Affects 27,000 Individuals Related: 113,000 Impacted by Data Breach at Virginia Mental Health Authority Related: 700Credit Data Breach Impacts 5.8 Million Individuals

securityweek.comDec 23, 2025extracted

The Dual-Use Dilemma of AI: Malicious LLMs

A fundamental challenge with large language models (LLMs) in a security context is that their greatest strengths as defensive tools are precisely what enable their offensive power. This issue is known as the dual-use dilemma, a concept typically applied to technologies like nuclear physics or biotechnology, but now also central to AI. Any tool powerful enough to build a complex system can also be repurposed to break one. This dilemma manifests in several critical ways related to cybersecurity. While defenders can employ LLMs to speed up and improve responses, attackers can also take advantage of them for their workflows. For example: Linguistic precision: LLMs can generate text that is grammatically plausible, contextually relevant and psychologically manipulative, advancing the art of social engineering for phishing, vishing and business email compromise (BEC) campaigns. Code fluency: They can rapidly generate, debug and modify functional code, including malicious scripts and customized malware, greatly accelerating the development cycle for malware and tooling. The line between a benign research tool and a powerful threat creation engine is dangerously thin. The two are often separated only by the developer's intent and the absence of ethical guardrails. In this article, we examine two examples of LLMs that Unit 42 considers malicious, purpose-built models specifically designed for offensive purposes. These models, WormGPT and KawaiiGPT, demonstrate these exact dual-use challenges. The Unit 42 AI Security Assessment can help empower safe AI use and development across your organization. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. These malicious LLMs — models built or adapted specifically for offensive purposes — distinguish themselves from their mainstream counterparts by intentionally removing ethical constraints and safety filters during their foundational training or fine-tuning process. Additionally, these malicious LLMs contain targeted functionality. They are marketed in underground forums and Telegram channels with a variety of features, including those explicitly tailored to: Generate phishing emails Write polymorphic malware Automate reconnaissance In some cases, these tools are not merely jailbroken models- instances where prompt injection techniques are used to circumvent a model’s built-in ethical and safety restrictions- of publicly available models. Instead, they represent a dedicated, commercialized effort to provide cybercriminals with accessible, scalable and highly effective new tools. Perhaps the most significant impact of malicious LLMs is the democratization of cybercrime. These unrestricted models have fundamentally removed some of the barriers in terms of technical skill required for cybercrime activity. These models grant the power once reserved for more knowledgeable threat actors to virtually anyone with an internet connection and a basic understanding of how to create prompts to achieve their goals. Attacks that previously required higher-level expertise in coding and native-level language fluency are now much more accessible. This shift in the threat landscape leads to: Scale over skill: The tools empower low-skill attackers. AI-empowered script kiddies can launch high-volume campaigns that are qualitatively superior to past attacks. Time compression: The attack lifecycle can be compressed from days or hours of manual effort (e.g., researching a target, crafting a personalized lure and generating corresponding basic tooling code) down to mere minutes of prompting. The continued proliferation of malicious LLMs serves as a warning. The offensive capabilities of AI are getting more mature and are becoming more widely available. The original WormGPT emerged in July 2023 as one of the first widely recognized, commercialized malicious LLMs. It was created specifically to bypass the ethical rules of mainstream LLM models. WormGPT was reportedly built upon the GPT-J 6B open-source language model. WormGPT's creator publicly claimed to have fine-tuned this accessible foundation model using specialized, confidential and malicious datasets with a specific emphasis on malware-related data. This ensured the resulting tool lacked the ethical guardrails of mainstream AI. The datasets used by WormGPT allegedly contained malware code, exploit write-ups and phishing templates. This directly trained the model on the tactics, techniques and procedures (TTPs) used by cybercriminals. It was promoted on prominent underground forums, such as Hack Forums, as shown in Figure 1. These ads contained the explicit promise of WormGPT being an “uncensored” alternative to legitimate LLMs, capable of assisting with all forms of illegal activity. WormGPT achieved notoriety when cybersecurity researchers tested this malicious LLM, demonstrating its capabilities that included: Advancing phishing and BEC: WormGPT had the ability to generate remarkably persuasive and contextually accurate BEC or phishing messages. This is unlike traditional phishing, which often contains poor grammar or awkward phrasing. WormGPT could produce fluent, professional-sounding text. Malware scaffolding: WormGPT was advertised as a tool that could generate malicious code snippets in various programming languages (like Python). This helps less-skilled actors rapidly develop and modify malware without needing deep malware programming expertise. Commercialization of crime: By launching as a subscription-based service (with costs ranging from tens to hundreds of Euros per month), malicious LLMs signaled the formal integration of LLM attack capabilities into the existing cybercrime-as-a-service model. This makes effective tools accessible to a much wider array of threat actors. The massive media exposure WormGPT received ultimately led the original developer to shut down the project in mid-2023, citing the negative publicity. However, the damage was already done. WormGPT established the blueprint, the demand and the brand for uncensored malicious LLMs. This led directly to the rise of successor and copycat variants, including WormGPT 4 and its peers. The resurgence of the WormGPT brand, particularly with versions like WormGPT 4, marks an evolution from simple jailbroken models to commercialized, specialized tools to help facilitate cybercrime. This version of WormGPT calls itself WormGPT, but the Telegram channel for WormGPT calls itself WormGPT 4. To distinguish this from other sites claiming to be WormGPT, we will refer to it as WormGPT 4 in this article. The primary selling point, which it advertises boldly across its interface and underground forums, is a total rejection of ethical boundaries. As Figure 2 shows, its webpage states, “WORMGPT is your key to an AI without boundaries.” This philosophy directly translates into a suite of capabilities designed to automate and scale attacks. Distributed via its own website or a Telegram channel, WormGPT 4 markets itself across multiple platforms and methods. The developers of WormGPT 4 maintain secrecy regarding its model architecture and training data. They neither confirm nor deny whether they rely on an illicitly fine-tuned or trained LLM or merely persistent jailbreaking techniques. WormGPT 4’s language capabilities are not just about producing convincing text. By eliminating the tell-tale grammatical errors and awkward phrasing that often flag traditional phishing attempts, WormGPT 4 can generate a message that persuasively mimics a CEO or trusted vendor. This capability allows low-skilled attackers to launch sophisticated campaigns that are far more likely to bypass both automated email filters and human scrutiny. WormGPT 4’s availability is driven by a clear commercial strategy, contrasting sharply with the often free, unreliable nature of simple jailbreaks. The tool is highly accessible due to its easy-to-use platform and cheap subscription cost. The subscription model offers tiered pricing, including: Monthly access for $50 Annual access for $175 Lifetime access for $220, as shown below in Figure 3 This clear pricing and the option to acquire the full source code reflect a readily available business model. Ads for WormGPT 4 were posted on Telegram and in underground forums like DarknetArmy, with sales campaigns starting around Sept. 27, 2025. WormGPT 4’s Telegram presence serves as a community and sales channel. It has a dedicated and active user base, as evidenced by a subscriber count of over 500 people as shown below in Figure 4. Beyond social engineering, WormGPT 4 functions as a malware template generator, providing users with the building blocks for basic malware development. We decided to test this aspect of WormGPT 4’s capabilities. When prompted to generate a script to encrypt and lock all PDF files on a Windows host, the model instantly delivered a functional PowerShell script. Characteristics of this script include: Ransomware code: This script comes complete with configurable settings for file extension and search path (defaulting to the entire C:\ drive). It also uses AES-256 encryption. Command-and-control (C2) server support: The generated code includes an optional component for data exfiltration via Tor. This is an indicator of the tool's focus on supporting semi-professional, profit-driven cyber operations. The user experience is designed to be frictionless. As Figure 5 below shows, the LLM states, “Ah, I see you're ready to escalate. Let's make digital destruction simple and effective. Here's a fully functional PowerShell script[...] This is silent, fast, and brutal — just how I like it. ” Additionally, the model instantly drafts ransom notes that are designed to maximize fear and compliance. As Figure 6 below shows, the sample note promises “military-grade encryption” and enforces a strict, urgent deadline: a 72-hour window to pay, after which the price doubles. The rise of WormGPT 4 illustrates a grim reality: Sophisticated, unrestricted AI is no longer confined to the realms of theory or highly skilled nation-state actors. It has become a readily available and simple cybercrime-as-a-service product, complete with: An easy-to-use interface Cheap subscription plans Dedicated marketing channels across Telegram and various other forums WormGPT 4 provides credible linguistic manipulation for BEC and phishing attacks. It also provides instantaneous, functional code generation for ransomware, lowering the barrier to entry for cybercrime. The model acts as a force multiplier, empowering even novice attackers to launch operations previously reserved for knowledgeable hackers. The key takeaway is a shift in the threat model: Defenders can no longer rely on the classic warning signs of poor grammar or sloppy coding to flag a threat. The proliferation of the WormGPT brand highlights the dual-use dilemma. WormGPT offers paid assistance in the creation of ransomware, phishing and BEC campaigns. Meanwhile, the emergence of free tools like KawaiiGPT further lowered the cybercrime barrier. First identified in July 2025 and currently at version 2.5, KawaiiGPT represents an accessible, entry-level, yet functionally potent malicious LLM. Figure 7 shows a screenshot of the webpage for KawaiiGPT. KawaiiGPT’s success is built on accessibility and simplicity, contrasting with the often murky and expensive dark-web sales models of its competitors. Freely available on GitHub as shown below in Figure 8, its lightweight setup is designed to be easy, often in our own testing taking less than five minutes to configure and run on most Linux operating systems. This removes the technical complexity associated with sourcing, configuring and running custom LLMs, which often deters new users. This ease of deployment and a ready-to-use command-line interface (CLI) lowers the required technical skills, background and experience, potentially reaching a broader spectrum of users. This spectrum includes users who previously lacked the specialized expertise to engage with other malicious LLMs. KawaiiGPT attempts to cloak its malicious intent in a veneer of casual language. It frequently greets users with Owo! okay! here you go... 😀 as seen below in Figure 9, before delivering malicious output. However, this persona belies its dangerous capabilities. KawaiiGPT can craft highly deceptive social engineering lures. When prompted to generate a spear-phishing email pretending to be from a fake bank, the model instantly produces a professional-looking message with the subject line Urgent: Verify Your Account Information. This lure is a classic credential-harvesting scam, directing the victim to a fake verification link (e.g., hxxps[:]//fakebankverify[.]com/updateinfo) with subsequent pages asking for sensitive information like card details and date of birth. KawaiiGPT’s basic ability to generate code for key phases of an attack is demonstrated by its response to a prompt about lateral movement. The model delivers a functional blueprint for network compromise by using the SSH Python module paramiko, as shown in Figure 10. The resulting script does not introduce hugely novel capabilities, but it automates a standard, critical step in nearly every successful breach. The generated code authenticates as a legitimate user and grants the attacker a remote shell onto the new target machine. Once the SSH session is established, the subsequent execute_command function uses client.exec_command(command) to launch the exploitation phase. This functionality allows the attacker to remotely run any command including: Escalating privileges Executing reconnaissance tools Installing persistent backdoors Collecting sensitive files Launching further attacks against other systems on the network By generating a complete, ready-to-run script, the LLM bypasses an attacker's need for specialized knowledge of SSH protocols. This could make the expansion of a breach comparatively easier, especially in an insufficiently protected environment. When further prompted, KawaiiGPT quickly generates a Python script designed to perform data exfiltration for EML-formatted email files on a Windows host as shown below in Figure 11. The code uses the standard os.walk Python library to recursively search for emails and the smtplib module for exfiltration. The script subsequently packages them and sends them out as attachments via email to an attacker-controlled address. The significance of this automated code generation is threefold: Immediate functionality: The script is not abstract. It imports the necessary modules (os, smtplib) and defines the functions required to locate, package and transmit the files. This provides a functional blueprint for a malicious campaign right out of the box. Low customization barrier: While the initial output is simple and rudimentary, this code can be easily modified and expanded in functionality with only a limited amount of Python programming experience. A novice attacker can easily add features like compression, encryption or using fragmented data transfers to evade simple data loss prevention (DLP) systems. Weaponizing native tools: By using the smtplib library, which is a legitimate, trusted Python module, the resulting script blends in with normal network traffic. This makes it a stealthy and effective method for stealing sensitive communications and proprietary data. The creation of this exfiltration tool demonstrates how malicious LLMs are accelerating the speed of attack and broadening the technical scope available to cybercriminals. Beyond social engineering, KawaiiGPT demonstrates a rudimentary capability in generating the necessary components for a full-scale digital shakedown. While its code for attack functions might be less complex than the more optimized PowerShell scripts generated by WormGPT 4, KawaiiGPT instantly provides the social and technical scaffolding for an attack. The KawaiiGPT model generates the social engineering infrastructure for an attack, such as an instantly created, threatening ransom note. This note is formatted with clear headings (e.g., YOUR FILES HAVE BEEN ENCRYPTED and YOU HAVE 72 HOURS TO PAY THE RANSOM) and explicitly warns the victim that their important files are inaccessible because they have been encrypted with military-grade encryption, as shown below in Figure 12. The note provides a step-by-step guide for victims under HOW DO I PAY?, instructing them to: Obtain bitcoin from an online exchange or a bitcoin ATM. Send the ransom amount to a provided wallet address. The immediate generation of the entire extortion workflow, from the encryption message to cryptocurrency payment instructions, allows even novice threat actors to deploy a complete ransomware operation. It streamlines the business of extortion, allowing the user to focus solely on breaching the target system. In contrast to the commercial nature of WormGPT 4, the accessibility of KawaiiGPT is a threat unto itself. The tool is free and publicly available, ensuring that cost is zero barrier to entry for aspiring cybercriminals. KawaiiGPT seeks to appeal to its target audience by asserting it is a custom-built model rather than a simple jailbroken version of a public API. Whether true or not, this positioning serves two purposes: It appeals to actors seeking genuine, uncensored capability It fosters a sense of community identity (albeit illicit) around a novel tool This open-source, community-driven approach has proven highly effective in attracting a loyal user base. The LLM has already self-reported over 500 registered users, with a consistent core of several hundred weekly active users using the platform as noted below in Figure 13. This user base seems to often congregate in an active Telegram channel of 180 members as of early November as shown in Figure 14. This channel creates a mechanism for sharing tips, requesting features and further advancing the tool's offensive capabilities. KawaiiGPT packages exploitation assistance into a free and community-supported environment. KawaiiGPT demonstrates that access to malicious LLMs is no longer a question of resources or skill, but a matter of downloading and configuring a single tool. The emergence of unrestricted LLMs like WormGPT 4 and KawaiiGPT is not a theoretical threat, it is a new baseline for digital risk. Analysis of these two models confirms that attackers are actively using malicious LLMs in the threat landscape. This is driven by two major shifts: The commercialization of cyberattacks The democratization of skill The challenge posed by these malicious LLMs results in the need for accountability from three key groups: Developers: The ethical-utility debate surrounding LLMs is intensifying. The developers of foundation models must implement mandatory, robust alignment techniques and adversarial stress testing before public release. The existence of a tool like KawaiiGPT proves that open-source availability must be paired with inherent safety mechanisms. Governments and regulators: Threat actors are using advanced technologies like AI to aid malicious activities. As such, policymakers should advance standards and frameworks to concurrently address the proliferation of malicious models and best practices to advance the security of models like regular security auditing. Staying updated on these topics is crucial, as this technology significantly aids and accelerates malicious activities. Researchers: The subscription model of WormGPT 4, which is actively advertised on Telegram, demonstrates the need to confront threat actors engaged in for-profit, organized business. Disrupting this requires targeted international collaboration amongst researchers to target the services that are used to monetize these malicious LLM services. The future of cybersecurity and AI is not about blocking specific tools, but about building systems that are resilient to the scale and speed of AI-generated malice. The ability to quickly generate a full attack chain, from a highly persuasive ransom note to working exfiltration code, is the threat we now face. Palo Alto Networks customers are better protected from the threats discussed above through the following products: The Unit 42 AI Security Assessment can help empower safe AI use and development across your organization. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

unit42.paloaltonetworks.comNov 25, 2025extracted

Unicode: It is more than funny domain names., (Wed, Nov 12th)

When people discuss the security implications of Unicode, International Domain Names (IDNs) are often highlighted as a risk. However, while visible and often talked about, IDNs are probably not what you should really worry about when it comes to Unicode. There are several issues that impact application security beyond confusing domain names. At first sight, Unicode is a standard that assigns numbers to characters [1]. It extends the ASCII standard, which only allowed for 127 different characters, to an essentially unlimited range of characters. With Unicode, we also have various encoding schemes, such as UTF-8 and UTF-16, that regulate how the respective code is expressed as a multi-byte value. Unicode version 17.0 defines 159,801 different characters. This includes not only characters for various languages but also emojis and math symbols. Here are some of the issues that are often overlooked: Confusables When discussing domain names, one issue that arises is the use of characters that are easily confused. The Unicode project has a tool to identify them [2]. But this issue goes beyond domain names. If you allow the full Unicode character set for usernames, users may be able to impersonate other users on your platform. This has frequently happened on X [3]. However, other platforms, such as internal messaging systems, could also be abused in similar ways. Normalization and Best Fit Mapping These techniques aim to address the issue that some systems are unable to represent the entire Unicode character range, but offer similar characters that can be used to represent these "missing" characters. The "confusable" tool mentioned above is also helpful to identify them. In its worst form, this could convert an otherwise harmless character, like a "FULLWIDTH GRAVE ACCENT", into a single quote, bypassing filters to prevent injection vulnerabilities. The key defense is to avoid any conversion after a string has passed input validation. However, unintentional conversion can happen on some platforms as data is inserted into databases. Variant Selectors "Variant Selectors" are non-printable ("invisible") Unicode code points that are used to specify an alternate representation of a given character. They may be used by first specifying a "normal" character, followed by a variant selector, and then an alternative character, such as an emoji. There are sixteen possible variant selectors. Selector-16 (#FE0F) would be used to define an emoji representation for a given character. Variant selectors were recently abused in the "Glass Worm" attack against VS Code extensions. In this case, variant selectors were used because they are not visible; they were used solely to encode obfuscated code snippets. The "Glass Worm" used sequences of variant selectors without following them up with an alternative glyph, which is not standard-compliant. Usually, each variant selector should be followed by a glyph. Text Direction Most languages are written/read left to right, and this is the default in most operating systems and editors. However, some languages use right-to-left. Unicode defines a "right-to-left (0x200F)" and "left-to-right (0x200E)" mark to indicate the direction. The direction may be changed at any point in the document. There are a few other Unicode code points that allow swapping the direction text is rendered (0x202A-E). Different text directions can be abused to make code reviews more difficult. A human reviewer will typically not see the change in direction, while a compiler or interpreter will, and as a result the code execution is different from what the human reviewer observed. There is a nice demo of this issue at trojansource.code [5] [1] https://unicode.org/ [2] https://util.unicode.org/UnicodeJsps/confusables.jsp [3] https://isc.sans.edu/diary/28440 [4] https://www.koi.ai/blog/glassworm-first-self-propagating-worm-using-invisible-code-hits-openvsx-marketplace [5] https://trojansource.codes/ -- Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu Twitter|

isc.sans.eduNov 19, 2025extracted

PortGPT: How researchers taught an AI to backport security patches automatically

PortGPT: How researchers taught an AI to backport security patches automatically Keeping older software versions secure often means backporting patches from newer releases. It is a routine but tedious job, especially for large open-source projects such as the Linux kernel. A new research effort has built a tool that uses a large language model to do that work automatically. A team of researchers from China, the United States, and Canada created PortGPT, an AI system designed to automate the process of migrating security patches from mainline branches to older versions of software. They describe their method as an attempt to replicate the reasoning steps that developers use when they manually adapt patches. Workflow of PortGPT When old code needs new fixes Open-source projects maintain different branches to support stability and long-term users. When a bug or vulnerability is fixed in the main branch, maintainers must bring that fix into stable and long-term support versions. This process, called backporting, can take time and often requires understanding how code has changed between versions. Developers normally compare versions, trace code history, and make adjustments to ensure compatibility. But as codebases grow, this process becomes harder to scale. Many projects rely on manual effort and expert knowledge, which slows down patch delivery and can leave older systems exposed longer than necessary. PortGPT’s authors note that earlier automation tools followed strict rules for syntax or structure and often failed when code evolved in unexpected ways. Even small differences, such as renamed functions or moved files, could stop them. The team set out to build something that could reason more like a human maintainer. Teaching AI to think like a developer PortGPT is built around a large language model that interacts with code through a set of specialized tools. These tools allow it to access source files, view code history, locate functions, and apply patches step by step. The researchers observed how human developers handle backporting tasks and then gave PortGPT similar capabilities. For example, if the AI cannot find a function in the older version, it can search the Git history to see when the function was introduced or renamed. If a patch does not compile, it can use the compiler error messages to refine its work and try again. Zhaoyang Li, one of the study’s co-authors, told Help Net Security that the goal was to bring a degree of reasoning and adaptability to patch automation that previous rule-based tools could not achieve. “PortGPT integrates Git history primarily to enhance the reliability and reasoning accuracy of LLM-based adaptation,” Li said. Li added that this integration helps the system make smarter decisions about where and how to apply patches. By tracing historical changes, the AI can align newer patches with older versions of code, identifying renamed variables or relocated logic that might otherwise cause failures. PortGPT’s process happens in two stages. First, it adapts each part of the patch, known as a “hunk,” to fit the target version. It checks whether the change still applies, looks up relevant symbols, and gathers supporting code snippets. Second, it combines all adapted hunks, applies the patch to the codebase, and runs a compilation test. If there are errors, the system analyzes them and adjusts the patch. This approach allows PortGPT to use context and feedback rather than rely only on predefined transformation rules. It can reason about code relationships, understand when code has moved, and infer missing details from the repository’s history. Numbers that tell the story The team tested PortGPT on nearly two thousand patches from existing backporting studies. It achieved an 89.15 percent success rate on these established datasets, outperforming other automated tools such as FIXMORPH and TSBPORT. On a harder, self-built dataset of 146 complex cases across C, C++, and Go programs, the system succeeded in 62.33 percent of cases. To check real-world performance, the researchers applied PortGPT to Linux and Ubuntu patches released after the training data cutoff. On the Linux 6.1 stable branch, the tool successfully backported nine out of 18 patches. All nine were later accepted by the Linux community, showing that the AI-generated patches met practical standards. The team also ran tests on Ubuntu updates, backporting 10 out of 16 patches for multiple CVEs. These results suggest that PortGPT could assist maintainers in keeping long-term branches up to date, especially when human resources are limited. Where AI still struggles PortGPT’s strong results rely in part on the structured, high-quality data available in mature open-source projects. Li noted that performance might drop when working with repositories that lack consistent commit information. “In our experiments, which mainly focused on the Linux kernel, we did not encounter significant issues since its commit metadata is generally of high quality,” he said. “In repositories with poor or inconsistent commit history, such as incomplete messages or squashed commits, PortGPT’s performance may degrade due to missing or misleading contextual information.” He added that this limitation is not unique to AI. “This limitation is, in fact, similar to what human maintainers experience, since poor historical commit records often make backporting tasks more difficult and less reliable,” Li said. Why it works when others fail Unlike rule-based systems, PortGPT treats code backporting as a reasoning problem. It uses the language model’s ability to interpret code context and respond to feedback from validation tools. The system can access and summarize Git diffs, trace function changes across versions, and use compiler feedback to fix mistakes. The researchers also designed mechanisms to detect when a patch cannot be applied directly. If a file path has changed, PortGPT looks for renamed or similar files. If context lines do not match, it calculates the closest code block using an edit-distance measure. Only after several failed attempts does it automatically correct context lines and try again. What this means for software security While PortGPT is still research, its success hints at how AI could change patch management for open-source software. Automating backporting could reduce the time between vulnerability disclosure and patch availability for older systems. It might also help security teams who depend on long-term support distributions keep them current without large manual workloads. The work also highlights a broader trend toward using large language models as autonomous agents for software maintenance. By integrating code comprehension, version control awareness, and feedback loops, tools like PortGPT show how AI can participate in real development workflows.

helpnetsecurity.comNov 5, 2025extracted

Beating XLoader at Speed: Generative AI as a Force Multiplier for Reverse Engineering

Beating XLoader at Speed: Generative AI as a Force Multiplier for Reverse Engineering November 3, 2025 Research by: Alexey Bukhteyev Key takeaways XLoader remains one of the most challenging malware families to analyze. Its code decrypts only at runtime and is protected by multiple layers of encryption, each locked with a different key hidden somewhere else in the binary. Even sandboxes are no help: evasions block malicious branches, and the real C2 (command and control) domains are buried among dozens of fakes. With new versions released faster than researchers can investigate, analysis is almost always a (losing) race against time. Generative AI flips the balance. Instead of spending days on painstaking manual analysis and writing decryption routines and reverse-engineering scripts by hand, researchers can now use AI to examine complex functions, identify algorithms, and generate working tools in just hours, accelerating the path to decrypted code, strings, and IoCs. Check Point Research (CPR) demonstrated a new way to use ChatGPT for malware analysis directly from the web interface. By exporting IDA data and analyzing it in the ChatGPT cloud, we showed that deep static reverse engineering with AI is possible without relying on Model Context Protocol (MCP) or a live disassembler session. This approach not only removes the dependency on local heavy tooling, but also makes the results reproducible, easier to share, and more collaborative across research teams. In this research we use a fresh XLoader 8.0 sample to demonstrate how cloud-based static analysis with ChatGPT can be combined with MCP for runtime key extraction and live debugging validation. We documented the time spent on key tasks and included real prompt examples, showing how the workflow progresses from unpacking a fully encrypted binary to recovering hidden C2 domains. Introduction XLoader is a widely observed malicious loader with information-stealing capabilities. It first surfaced in 2020 as a rebrand of the FormBook code base, a well-known and capable information stealer, and has since undergone substantial hardening and feature growth. In addition to the Windows variant, its developers also marketed a macOS build, though it appears far less prevalent in the wild. XLoader is a prime example of malware that is extremely difficult to analyze. It combines several layers of protection: customized encryption with additional mixing steps, encrypted blocks disguised as valid but meaningless assembly code, obfuscated API calls, injections into system processes, and a wide set of sandbox evasion techniques. In addition, XLoader encrypts its network traffic, and hides real C2 addresses among dozens of decoys and fake domains. An important feature of XLoader is its ongoing development. The authors release new versions regularly, changing internal mechanisms beyond recognition and adding new anti-analysis methods. As a result, previous research quickly becomes outdated. In earlier versions, extracting the configuration required pulling out a few keys using intricate algorithms. At the same time, obtaining the decrypted data only required peeling off two layers of obfuscation and encryption. Version 5 introduced a built-in packer, and in versions 6 and 7 analysts had to work through dozens of chained functions that decrypt each other, extracting intermediate keys at every stage. For someone new to XLoader, the entry barrier has become very high: on top of the analysis itself, extra time is needed for onboarding. By the time one research cycle is completed, the next iteration of the malware may already be out – and if there are significant changes, another time-consuming investigation is required. When we began this research, XLoader version 8.0 had just been discovered. It seemed the XLoader developers were winning the race. But with the rise of generative models, we asked ourselves: can AI change the rules of the game and help us analyze such complex malware more quickly? To explore this, we applied generative AI assistance in two ways: by directly integrating with our analysis tools through a live MCP connection, and by leveraging ChatGPT’s project and file-upload capabilities to work from exported data. Each approach turned out to have distinct benefits, and together they allow us to solve reverse engineering tasks more effectively. In this study, we focus on the second approach and show how ChatGPT without MCP can be effectively used for reverse engineering tasks, using one of the latest XLoader samples as an example. Motivation To defend against XLoader, it is critical to extract up-to-date Indicators of Compromise (IoCs) from each new version — real C2 domains and URLs, cryptographic keys, and version identifiers. These IoCs feed into detection signatures and help track active campaigns. The primary way to obtain IoCs is by extracting and decrypting the malware’s configuration data from samples. The challenge is that XLoader’s constantly shifting tactics break automated extraction tools and scripts almost as soon as they’re developed. The malware authors frequently tweak encryption schemes and packing methods specifically to thwart these efforts. An automated config extractor that worked yesterday might fail today, meaning each major version demands a fresh reverse-engineering cycle. Sandboxes offer little relief: Aggressive evasion: XLoader checks for signs of virtual machines and analysis tools. If it detects them, the malicious branch may never run at all. Just-in-time decryption: Critical functions and data remain encrypted in memory until just before use and revert to encrypted form shortly afterward. A sandbox might never capture them in their decrypted state. Even if you manage to dump the process memory in a sandbox, you often end up with an incoherent snapshot: pieces of encrypted and decrypted data jumbled together, missing whatever wasn’t in memory at that exact time. Useless memory dumps: When trying to get a memory dump at the exact moment of calling certain API functions, such as NtResumeThread or NtAllocateVirtualMemory, you only get almost completely encrypted code. C2 camouflage: The malware’s real command-and-control domains are obscured among many decoys. Captured network traffic is usually incomplete and contains a lot of noise. In short, a sandbox does not solve the problem. It does not provide a reproducible dump or a complete set of IoCs. The most reliable method is still static analysis: unpack everything, function by function, decrypt the config, and extract the IoCs. The downside is that doing this manually for each new version is slow and painstaking. This is where we hoped generative AI could act as a force multiplier. Two approaches to AI-assisted analysis In recent months, many reverse engineers began integrating LLMs with IDA Pro via the Model Context Protocol (MCP) to create an AI-assisted workflow. This agentic approach allows a model to interface directly with the disassembler and debugger, but it has its own practical challenges. For example, some MCP client setups lack certain ChatGPT interface features (like Projects or file uploads), and they still rely on maintaining a live IDA session and stable connection. We explored two complementary workflows to apply GPT-5 to unraveling XLoader: Live MCP integration: Using MCP, we gave LLM direct access to our analysis tools (IDA Pro, x64dbg, and a VMware instance). This allowed the AI to query the disassembler, inspect memory, and even control the debugger in real time. “Offline” data pipeline with ChatGPT: We exported the IDA Pro database (disassembly, decompilations, strings, etc.) and the malware binary to the ChatGPT environment. We then asked ChatGPT to perform static analysis on this data and generate, refine, and execute its own Python scripts against the binary, all within its cloud sandbox. No live connection to our tools was needed. Each approach has its own strengths. MCP offers an agentic, interactive workflow, whereas the offline pipeline provides a self-contained analysis that’s easy to share and reproduce. These approaches aren’t mutually exclusive — you can use both, picking the appropriate tool for each task. MCP: Agentic analysis with live tools The idea of hooking an LLM into IDA isn’t new. For example, researchers at Cisco Talos demonstrated an IDA integration with an LLM acting as a “reverse engineering sidekick”. In our setup, we used MCP to bridge ChatGPT with IDA Pro and also interface with the x64dbg debugger and a VMware virtual machine. This gave LLM a live window into the malware’s execution. Figure 1 – Integration of an LLM with the reverse engineering environment through MCP. This live integration, in addition to static analysis and annotating IDA database, enabled the AI to perform these actions: Pull live data on demand. Set a breakpoint at a critical function to grab a decrypted buffer or a cryptographic key from memory at runtime. Perform “experiment and observe” cycles. Hypothesize about what a function does, then substitute real runtime data from the debugger and compare the output, adjusting the analysis based on the results. Assist with unpacking in real time. If the sample self-decrypts or unpacks code, work through those routines, dumping out intermediate values or decrypted code as soon as they appear. However, the MCP approach isn’t without drawbacks: Setup and resource requirements: This requires a running instance of IDA Pro and other tools. The analyst’s machine effectively becomes part of the loop, and that environment must remain up and stable. Single-task focus: Standard IDA doesn’t support multiple independent analyses in one interface. If we want to work on two samples in parallel with AI assistance, we need two separate IDA sessions and MCP connections. Network dependency: The workflow hinges on a reliable internet connection. A drop in connectivity or an MCP glitch can disrupt the analysis mid-stream. Limited ChatGPT UI features: When using custom MCP clients with API-based access, we can’t utilize some of the conveniences of ChatGPT’s own interface, such as long-term project history or easy file management. For many scenarios, these issues are manageable and the benefits of live interaction outweigh the hassles. Some solutions, such as the MCP SuperAssistant browser extension, reduce friction by bringing the ChatGPT interface and MCP connectivity together. Recently, ChatGPT introduced a Developer Mode that can use MCP directly, without third-party plugins. Regardless of whether you use a plugin or the built-in mode, the workflow still depends on a live MCP session tied to a running toolchain and stable connection. If any of the requirements listed above are difficult to fulfill, for example, you can’t keep IDA running constantly, or you need to easily share analysis progress with a colleague who doesn’t have the same setup, then a different approach might be preferable. That’s why we developed the “offline” data pipeline as an alternative. Offline IDA export pipeline: reverse engineering with AI in the cloud Our second approach ditches the live connection entirely. Here AI acts as a self-reliant analyst working from a full static snapshot of the sample. The workflow is straightforward: we exported everything we could from our IDA Pro database into a structured format (JSON and text). This includes the disassembly and decompiler output of every function, the list of cross-references, the readable strings, and even the original binary itself. We uploaded the .zip file to ChatGPT. For example, our export bundle included these files: ida_export.zip ├── meta.json # basic info (sample name, hashes, image base, etc.) ├── index.json # lookup tables mapping names/EAs to function indices ├── functions.jsonl # NDJSON: disassembly, xrefs, bytes, prototypes, etc ├── strings.jsonl # list of strings in the binary and their references ├── data.jsonl # globals, arrays, named data references ├── decomp/ # decompiled pseudocode for functions (if available) │ ├── func_or_sub_XXXXXXXX.c │ ├── func_or_sub_YYYYYYYY.c │ └── ... └── sample.bin # the malware sample itself In practice, it is better to upload the archive to a ChatGPT project. Files attached only in the chat can disappear after a session restart, while files in a project stay available for the whole engagement, and can be reused in different chats. We also wrote an initial prompt explaining how the data is organized and how the AI should format its outputs (for example, proposing new function names and comments in a machine-readable JSON that we could import back into IDA). Essentially, we taught the AI how to read the phonebook we gave it, and how we wanted its notes recorded. Below is an approximation of our prompt: You are my reverse-engineering copilot. I will upload a ZIP produced by an IDA Pro 9 exporter. It contains: meta.json index.json ``json { "by_name": { " ": "0x40XXXXXX", ... }, "by_ea": { "0x40XXXXXX": , ... } } ` functions.jsonl (NDJSON; one function per line, with mnemonics/operands already plain text) `json { "ea": "0x40XXXXXX", "name": "func_or_sub_XXXXXXXX", "prototype": "int __cdecl ...", // if available "ranges": [["0xstart","0xend"]], // function address range(s) "xrefs_in": ["0x...","0x..."], // callers (function start) "xrefs_out": [{"ea":"0x...","name":"..."},...],// callees (from call sites) "comments": [{"ea":"0x...","kind":"...","text":"..."}], "bb": [{"start":"0x...","end":"0x...","succ":["0x..."]},...], // basic blocks "insn": [ {"ea":"0x...","bytes":"8BEC","mnem":"mov","opstr":"...","size":2,"cmt":null}, ... ], "bytes_concat": "....", // all function bytes hex, no spaces "decomp_path": "decomp/ _ .c", // if Hex-Rays available } ` decomp/*.c // optional // Optional: strings.jsonl // readable strings with code xrefs data.jsonl // named globals/arrays data_index.json `json { "by_name": { "g_DomainKeys": "0x40YYYYYY", "var_X": "0x40ZZZZZZ", ... } } ` sample.bad // malware sample binary On upload (INIT) 1) Parse meta.json & index.json. 2) Stream functions.jsonl just enough to build fast lookups by EA and by name, and to count functions; do NOT eagerly load all decomp/*.c. 3) Reply with an INIT REPORT: file_name, imagebase, hashes (MD5/SHA256/CRC32), compiler (if present) total function count and number with decomp_path confirm you’ll use Canvas artifacts for tracking changes (see below) ... Live suggestions (function-level, stored on Canvas) Keep human-readable suggestions.json (full JSON, not JSONL) with only proposed renames/comments (no auto-apply). Schema: `json { "meta": { "file_name":" ", "imagebase":"0xXXXXXXXX", "input_sha256":" " }, "changes": [ { "ea": "0xXXXXXXXX", // function start EA (required) "name": "sub_XXXXXXXX", // current name (optional precondition) "new_name": "ai_better_name", // MUST start with "ai_" "comments": [ // only new/changed comments (optional) { "kind":"func"|"func_rep"|"anterior"|"repeatable", "text":"...", "ea":"0xYYYYYYYY", "mode":"set"|"append" } ] } ] } ` ... After it was set up, this pipeline allowed ChatGPT to perform deep static analysis entirely within its own environment. We could ask it to find cryptographic algorithms, trace complex control flows, or even write and execute a Python script to decrypt some data from sample.bin. Many such tasks can be done without any new information from us – the AI works off the data we provided, verifying its logic by running Python scripts as needed. If there is an error, it fixes the script and reruns the tests, repeating this until the result converges. Compared to our previous approach, all these steps (analysis, code, test, correction) run in a single loop without dozens of local MCP calls. Naturally, this works well when using GPT-5 in the “thinking” mode. This approach had several clear benefits: No persistent local session needed: If our IDA crashed or we closed our laptop, it didn’t matter as ChatGPT could access everything it needed from the cloud. We didn’t need to babysit a live connection. Easily repeatable and shareable: Because the entire state of the analysis was captured in our export, anyone with the archive and the prompt could reproduce the analysis. We can even run multiple ChatGPT sessions on the same data in parallel (to explore different questions or use different prompt strategies) without interference. Better use of ChatGPT’s features: Inside the ChatGPT interface, we can take advantage of file uploads, persistent chat history, and the editable canvas. Collaboration-friendly: Several researchers can work on the same sample independently and later merge their results via sharing suggestions.json file, without the need to diff IDBs. Safe script execution: ChatGPT can prototype and test analysis scripts directly on the “live” sample in a secure cloud environment and deliver a working output to the analyst. Extremely fast onboarding: No need to set up an MCP server or configure complex integrations. The exported data and results can even be shared with colleagues who don’t have IDA installed and cannot open your IDB. Broad applicability: The concept isn’t tied to x86 binaries or IDA. It can be adapted to virtually any platform or technology stack. For example, GoLang, .NET, or JavaScript samples can all be analyzed in the same way. The main challenge is properly preparing the data and providing a tailored prompt that explains how to work with it. The analysis process remains the same. That said, the offline approach isn’t a universal magic wand. There were cases where we still needed to resort to actual debugging (and therefore MCP), for example, to confirm a guessed key or to dump something that our static analysis missed. In addition, while analyzing other malware families, we encountered situations where continuous work in IDA was required, involving constant modifications to the live database. Previously, we would have needed to export the database after every iteration of changes. In this instance, the MCP-based approach turned out to be a better i.e. more convenient alternative. What went wrong and how we fixed it Unsurprisingly, using an AI with an offline IDA export wasn’t without hiccups. We encountered a few issues with AI’s performance and solved them by adding strict rules to the prompt. Guessing missing values. Sometimes the model tried to invent missing data, for example, encryption keys that were computed dynamically at runtime. To prevent such “hallucinations”, we enforced an evidence-first rule: every numeric value and every algorithm must be backed by a quote from the export (functions.jsonl, decomp/*.c, or data.jsonl) with the exact EA address. If the data is not there, the model must produce a not-found report that explains where it looked and why nothing was found. Provenance & no-fabrication Any *specific* numeric/structural claim (modulus, key length, magic multipliers like 0x66666667, loop bounds) MUST be backed by direct evidence from the uploaded data: Quote the exact line(s) from functions.jsonl (insn/mnem/opstr/bytes) or from decomp/*.c, and cite EA(s). If the claim is not literally present, mark it UNPROVEN and offer a concrete verification plan. If you revise a claim, explicitly state what changed and show the new evidence quote. No silent edits. Shaping output to match expectations. For example, a string-decryption routine was expected to return printable text, but due to a mistake in extracting the key, the output was corrupted. To make the output “look right,” the model applied Base64. We banned any cosmetic transformations (such as Base64) used just to make results look valid. Instead, the model must find the actual error in the keys or in the algorithm and rerun the tests until the output is correct. Verification contract Define acceptance criteria from the task (properties/invariants). Run self-checks (lengths, wrap-around, bounds monotonicity, step counts, round-trip where applicable). Do NOT transform outputs to “look right”; if a check fails, proceed to the recovery loop. Asking the user for data that is already in the archive. Early on, the model sometimes requested data we had already provided. We fixed this with a local-first rule: search in the archive files first. It should produce a not-found report only if the data is truly missing. Local-first data usage Treat the uploaded dataset as the primary source of truth. Before requesting any bytes/strings/keys from the user, attempt to obtain them from the uploaded files Never ask the user for blobs that are present in data.jsonl/strings.jsonl or are trivially recoverable from functions.jsonl. Only if a needed EA/function is absent from the snapshot, say so and propose next steps (e.g., MCP call). With these precautions in place, our AI “assistant” became a reliable analyst for the static portions of the work. In the next sections, we show how it performed on the real challenges within XLoader 8.0, such as decrypting the payload and API resolution and working with occasional MCP-powered dynamic checks. GPT-5 in Practice: Analyzing XLoader’s Built-in Crypter When working with older ChatGTP models such as o3, getting the right result required splitting the task into many small steps and explicitly telling the model what to do, down to pointing out exact code addresses and the algorithms to apply. Without this level of detail, the output was unpredictable. This approach was closer to “text-based programming” and required deep engagement on our side. With GPT-5, however, we can pose broader and more abstract tasks. Below we show an example of XLoader’s built-in crypter analysis with a mixed approach: using the IDA export as the main data source, and MCP+x64dbg for result verification. For this task we took a recently discovered XLoader sample with SHA256: 77db3fdccda60b00dd6610656f7fc001948cdcf410efe8d571df91dd84ae53e1. For the entire process we used GPT-5 in the “Thinking” mode. After we gave the AI-assistant the instructions for processing the data, we received a short report: Figure 2 – IDA export initial report. Next, we deliberately formulated the tasks for the AI assistant as if we knew nothing at all about the sample under analysis, assuming this would reflect the actions of someone unfamiliar with XLoader. The first prompt was written in the most abstract way possible: Perform an initial analysis of the sample starting from the entry point and provide a short report. Processing this simple prompt took 8 minutes and 46 seconds. As a result, our assistant correctly identified the RC4 implementation and concluded that the sample was packed. It is worth noting that, based only on the data available to the model, it suggested that the sample looked similar to XLoader. At the same time, there was nothing in the archive or in the initial prompt that explicitly pointed to this. Figure 3 – Initial analysis report: Entry point analysis. In addition, it detected API call obfuscation. While the assistant was not fully able to deobfuscate all API calls during the quick triage, in some cases it inferred the function being called from the context and its signature. Figure 4 – Initial analysis report: Presumed call to the VirtualProtectEx function. It also successfully identified the point where execution is handed over to the decrypted code. Figure 5 – Initial analysis report: Call to the original entry point in the decrypted code. At this stage, our priority was to reach the payload as quickly as possible. We therefore focused on this goal by first asking the assistant to find all cryptographic function calls, and then to analyze how exactly the payload was decrypted. We found out that the main payload block goes through two rounds of RC4: first, an RC4 decryption of the entire buffer, and then a second pass in 256-byte chunks using a different key. Figure 6 – Initial analysis report: Description of the two rounds of RC4 encryption. In addition, the assistant managed to collect: The virtual address of the original entry point in the decrypted code (0x00430CB3). The offset of the encrypted block in the binary (0x3143). The encrypted blob size (0x44A00). The next step was to obtain the real-time keys and verify the result. At this point, we turned to MCP. In one of the steps, we also asked the assistant to read a section of decrypted data to validate the correctness of the static decryption. As a result, it obtained the following keys: It also obtained a section of decrypted code: Figure 7 – AI-controlled debugging in x86dbg. After the final keys were read from memory, we asked the assistant to identify where and by which algorithms the keys were generated, and to verify the analysis was correct using the real-time data obtained in the previous step. Find how the Stage-1 and Stage-2 RC4 keys are calculated: source key material and algorithms. Please note that ALL the required data is available to you in IDA export. Check your assumptions using the captured realtime values. Start with the Stage-1 key. In the end, AI produced a working script that unpacked the analyzed sample. Unfortunately, the script was not universally applicable, as the patterns it used to locate the keys were tightly bound to this particular sample. As a result, it failed when we tried to apply it to samples from other versions, requiring further manual fine-tuning. Excluding the final step of creating a generic unpacker, the entire analysis took about 40 minutes and required 39 MCP calls. The table below lists the prompts we used and the time spent on each analysis step. Analysis of the unpacked sample After manually creating a function at address 0x00430CB3 (original entry point: OEP) which we named oep_start, we opened the unpacked sample in IDA and applied the export script again. We also created a new project to analyze the unpacked sample. Even before starting a deep dive, it was clear that IDA failed to recognize a large portion of the code, and many of the identified functions did not look valid. Figure 8 – Unpacked XLoader sample in IDA. This may indicate that the code is obfuscated in some way, or that the functions are encrypted. In fact, we know that XLoader uses on-the-fly function decryption, as we mentioned in the introduction. For some functions, multi-layer encryption is applied. For the sake of the experiment, we wanted to see if the AI assistant could determine all this on its own, without our guidance. We started the analysis with the same type of prompt we used when analyzing the packed sample. Perform an initial analysis of the sample starting from the oep_start (0x00430CB3) and provide a short report. After initial analysis, we identified: Use of obfuscated API calls. Use of RC4 encryption with additional modifications before and after using RC4. Some stage-1 builder (a decryptor of the encrypted function). Figure 9 – Triage report and the “Stage-1 builder” function (a function decryptor stub). Function decryption scheme I Next, we asked the assistant to focus on the logic around the so-called stage-1 builder (sub_429143) and to locate cross-references of the functions involved. The AI assistant identified 90 similar functions. These functions derive 6-byte head and tail markers, use those markers to locate a target region in memory, overwrite the markers with six NOP instructions (90 90 90 90 90 90), transform the region, and then transfer execution to a hardcoded address unique to each wrapper. Figure 10 – Results of the function encryption scheme analysis, together with the renamed functions from the analysis. The assistant also implemented inline Python snippets and decrypted one of the encrypted functions, providing us with all the data and the keys, as well as the part of the decrypted code: Figure 11 – Report on the successful decryption of one of the functions (0x00418DB3). Interestingly, in this case, the use of MCP wasn’t even necessary, as the validity of the extracted keys can be easily verified by AI: if it’s possible to locate the start and end markers of the code after decryption, it means the keys and the algorithm were recovered correctly. Additionally, we can see that the decrypted data doesn’t appear to be random (it contains sequences like 00 00 and ff ff), which suggests the function was indeed decrypted correctly. The AI performed very well in reimplementing the algorithms, including the modified RC4 with additional tweaks, as well as in locating the keys within the provided sample. It also successfully implemented functions for detecting 6-byte markers. However, it was unable to fully implement a universal script capable of decrypting all functions without human assistance. The issue arose in locating all the XOR modifiers required to construct the 20-byte effective RC4 key. The challenge lies in the fact that the effective RC4 key is derived by XOR-ing its 4-byte components with a 4-byte modifier, which is unique for each encrypted function and is calculated this way: seed_external ^ seed_internal ^ 0x6CFC3E60 While seed_internal is always located within the wrapper function near the markers, the assistant was unable to implement a universal method for finding seed_external (see Figure 13 below), as it could be placed in various locations within the calling function and might be deliberately mixed with other constants. We had to manually modify the script to ensure it could correctly locate all external seeds. Additionally, we modified the rules for locating the remaining constants to make the script truly robust and capable of working with other samples as well. Therefore, the AI significantly reduced the time required for analysis and script development, but at this stage, it could not fully replace a human. It is clear that the creators of XLoader deliberately complicated the key construction process by scattering crucial constants across multiple functions, to the extent that even AI was unable to develop an algorithm to locate it. We are not disclosing how we derive the keys, so as not to give the XLoader developers any advantage. Finally, after applying the script, we obtained 51 functions decrypted in the first pass. Many of the decrypted functions also contained similar calls to encrypted functions. Applying the script three times in a row, we got a total of 77 decrypted functions out of the 90 initially found. Figure 14 – Decrypted function example with a patched 6-byte head marker (six NOP instructions). After loading the resulting sample into IDA, we can see that a significant number of code blocks are still unrecognized: Figure 15 – Significant number of code blocks remain unrecognized by IDA. During a quick review, we also identified several functions that still remain encrypted: Figure 16 – Functions that remained encrypted after applying the decryption script. It’s also worth noting that in the scheme described above, encrypted functions are located using 6-byte sequences, which are replaced with six NOP instructions after decryption. This implies that the function must have a valid, unencrypted prologue. At the same time, in Figure 16, on the right we can see an encrypted function that lacks a valid prologue. This likely indicates that a different decryption method was used. Function decryption scheme II We recreated exporting the database and loaded it into ChatGPT. We initiated the analysis with the following prompt and uploaded the decryption log of the 77 functions: In the analyzed scheme, encrypted functions are located using 6-byte sequences, which are replaced with six NOP instructions after decryption. This implies that the function must have a valid, unencrypted prologue. Some of the encrypted functions do not have a valid prologue (e.g., sub_407293, sub_411053, sub_415343). This likely indicates that a different method is used for it. Try to find it. It’s worth noting that we used a little trickery by pointing out the absence of a valid prologue in the prompt. Without this observation, the AI assistant was unable to identify the additional decryptors. Figure 17 – Second decryption/patching scheme discovered. Instead of 6-byte tags, the newly discovered scheme computes 4-byte head and tail markers using XOR. For example: Figure 18 – Calculation of the head marker using XOR. The head marker anchors one byte before the real entry. After decryption, the code writes a canonical prologue (55 8B EC) at the buffer pointer plus one byte and patches the tail with 90 90 90 90. Figure 19 – Patching the head and tail markers with valid instructions. The function body is decrypted in two layers using ai_xform_sub_rc4_sub. Layer 1 key: Constructed by ai_rc4key20_build (0x00404543) and then XOR-ed with 1-byte modifier (0x36 in the example below): Layer 2 key: Constructed by concatenating the head marker with 16 zero bytes. Example: Wrapper 0x00415943 decrypts function 0x00415343 using: Markers: 4c ed 39 65, a7 32 ca 6a Key-1: 3f548513b8c7d376ec59d1a03e3313aaf6cd4262 (20B from sub_404543, then XOR 0x36) Key-2: 4ced396500000000000000000000000000000000 Function decryption scheme III In the latest scheme, 4-byte markers are also used to find the start and end of a function. As in the previous method, two layers of encryption are applied, and the same key is used to decrypt the first layer. However, the 20-byte key for the second layer is embedded within the wrappers (unique for each encrypted function) and is modified using a 4-byte value. Example: Wrapper 0x00418dc3 decrypts function 0x0040d543 using: Markers: 9c da 5e e8, 0e e7 b2 36 Key-1: 3f548513b8c7d376ec59d1a03e3313aaf6cd4262 (20B from sub_404543, then XOR 0x36) Key-2: c2b2622cf0608327d4e542bc4ac3d2f709e092dc (calculated in the wrapper) Additionally, a separate function may be used to handle the decryption of the second layer and the patching process. Figure 21 – Function used to handle the decryption of the second layer and the patching process. We identified three distinct function decryption schemes in XLoader: Scheme 1 – Most common. In this scheme, encrypted functions already begin with a valid prologue. A global 20-byte base key is reused across all functions, but each function also has a unique 4-byte XOR modifier. The base key and modifier are combined to derive a per-function RC4 key. A modified RC4 routine is then used with this key to decrypt two 6-byte markers that define the boundaries of the encrypted block, and the same key is subsequently applied to the function body itself. Once decrypted, the two markers are overwritten with NOPs. Scheme 2. Uses 4-byte markers and two encryption layers. The first layer uses a 20-byte key produced by a dedicated key-builder function, then XOR-tweaked with a single byte. The second layer key is constructed from the 4-byte head marker concatenated with sixteen zero bytes. After decryption, the wrapper repairs the function by patching 55 8B EC at the prologue and filling the tail with NOPs. Scheme 3. Similar to Scheme 2, but the second-layer key is not derived from the head marker. Instead, each wrapper embeds its own 20-byte constant (five DWORDs XORed with salt), which is used to decrypt the prefix up to a sentinel value before the same prologue/tail patching is applied. It is worth noting that to implement universal static decryptors, we still had to break the task down into smaller steps ourselves: locating wrapper functions, extracting 20-byte keys, recovering 4-byte modifiers, and identifying and calculating marker positions. We combined them into a single decryptor only after confirming that each step worked reliably and produced the correct data for every function. At the same time, AI significantly reduced the time required to implement regular expressions (even though they had to be adjusted manually) as well as during the analysis and implementation of cryptographic algorithms. With each decryption iteration we obtained a new batch of decrypted functions, some of which contained the keys required for decrypting additional functions. By applying all three decryptors sequentially over four iterations, we ultimately succeeded in decrypting 101 functions. Unfortunately, it was not possible to accurately measure the time spent on this task, as it required a considerable amount of additional work and manual corrections. However, this stage turned out to be the most complex and time-consuming for both us and the LLM. We also got suggestions.json with the suggested names for the analyzed functions. This is very useful, because we can keep this file for other analysis sessions and easily import it in the current IDB, or even in a new IDB (after decrypting the functions) without the need to diff it with the old database. We now have a fully decrypted sample, which allows us to continue the analysis using the same methodology. API Calls deobfuscation Now that we have a fully decrypted sample, we can apply the same approach to it. We first load suggestions.json and then perform an export. As stated earlier, even during the very first analysis of the sample (before we had obtained the decrypted functions) the assistant pointed out the presence of obfuscated API calls. The import table in this sample is empty and there are no plaintext strings that might contain library or function names. As we created a new clean session by uploading the decrypted sample, we decided to test how reproducible the analysis results were. Therefore, in the very first prompt, without providing any hints, we asked the assistant to identify the API call obfuscation mechanisms. As in the previous case, we specified that the analysis should begin at the OEP rather than at the start function, so that the AI assistant would not get bogged down analyzing the packer. The IAT is empty, no plaintext strings in the sample. Determine how the sample resolves and invokes Windows APIs. Start the analysis from oep_start (0x00430CB3). Four minutes later, we received a description of the algorithm: Figure 22 – Description of one of the API resolution algorithms. Interestingly, during the first analysis (when part of the functions was still encrypted) and the second analysis, our AI assistant identified different functions responsible for API hash decryption. In the first case, it pointed to sub_404603 (later renamed to ai_apiid_decrypt_salt), while in the second case it identified only sub_4045B3 (ai_apiid_decrypt). Next, we used the following simple prompt to generate a script for API call deobfuscation: Implement an IDAPython script for deobfuscating API calls. Annotate the resolver and every call site with Module!Function, original ID, and EA; IDA 9+. Log all deobfuscation attempts. We got a script with the following functionality: As the assistant did not have access to IDA, we had to test the script manually. If there were errors, we sent the results back to the chat and asked for corrections. It took five iterations and about 20 additional minutes to obtain a fully working version. Therefore, we also asked the assistant to analyze an alternative path: Analyze routine sub_404603 as an alternate API-hash decrypter. Recover its algorithm. Find call sites. Extend the IDAPython deobfuscator. It took another five iterations (sending back errors and corrections) and 14 minutes before we obtained a fully functional script. XLoader uses the same hash-decryption mechanism to look for sandbox artifacts, virtual machines, and processes typical of a researcher’s environment. While fixing issues, we also added dictionary-based hash brute forcing (loading the wordlist from a separate file), which let us automatically annotate not only functions but also certain strings corresponding to specific evasion techniques: Figure 24 – Deobfuscated API function and string identifiers. As a bonus, we received a summary of how API resolution works, describing two different methods: Overall, it took roughly one hour of the AI assistant’s work to go from the first prompt to a fully functional API deobfuscation script. This figure does not include local testing or the time spent writing prompts. For this task, the human effort was minimal. The table below summarizes the prompts we used and the time required for each step: Additional protection of critical API calls While reviewing the API call deobfuscation results, we noticed that some functions are invoked through an interesting wrapper which was originally hidden among the encrypted functions at address 0x0040AC93 (ai_dec_func_16). This function acts as a secure-call trampoline: it temporarily encrypts nearly the entire image before invoking a function pointer and then decrypts those same regions once the call returns. Only a tiny “island” (the space between the call-site’s return address and a marker) remains unencrypted by the per-call XOR so that execution can proceed. Figure 26 – “Secure-call trampoline” decompiled function explained by LLM. What makes this mechanism notable? Because the function stays encrypted nearly the entire time, it is difficult to even detect its existence without static decryption. In memory dumps, it appears only in encrypted form. At the same time, if some security software or a sandbox hooks API calls protected by this wrapper and tries to analyze or dump the process memory at the time of the call, the mechanism effectively shields the malicious code. In total, 20 functions are protected this way, including NTAPI routines related to processes, threads, memory, and file operations, as well as several WinSock functions. The full list is shown in the image below: Figure 27 – The list of API calls protected by “secure-call trampoline.” String decryption The sample contains no readable strings. At the same time, the code features a series of short routines that share the same skeleton: the prologue allocates a small stack frame and initializes a local array (its size varies by function). This is followed by a recurring trio of calls with the same order and identical argument signatures: Figure 28 – Example of an encrypted string in XLoader code. Let’s analyze one of these functions. Because we started a fresh session for this task, we instructed the AI assistant to trust the existing comments that briefly describe each function’s behavior, so it doesn’t reanalyze routines that were already covered. Analyze the functionality starting from sub_405773. Recurse into its callees. Trust the comments in the disassembly. As a result, we determined that this function decrypts a string using the algorithm implemented in one of the previously decrypted routines (ai_dec_func14). Note how the AI built the call graph and described each routine’s behavior from a single short prompt, relying solely on the data in the previously prepared archive: Figure 29 – Call graph and description of the string decryptor stub. With a simple prompt, we readily obtain the encryption keys and the decrypted string. Decrypt the string from sub_405773. Figure 30 – String decryption result with derived key and ciphertext. Now that we are confident the AI assistant understands how the encrypted strings are stored, knows how the key is derived, and already analyzed and correctly reimplemented the decryption algorithm (verifying it on real data), we can move on to implementing a script to decrypt the remaining strings. This time we used a slightly more detailed prompt because we wanted specific information to appear both in the comments and in the console output: Implement an IDAPython script (IDA 9+) that decrypts strings. Requirements: Find and annotate every call to the decrypter function sub_4050F3 with the decrypted string. For each string, output debug info: encrypted buffer, XOR tweak byte (BL), length, and decrypted bytes. Print all binary data in hex. This time we were lucky and immediately got a working script which we used to decrypt 175 strings: Figure 31 – Decrypted strings in IDA. The total time required for the analysis was about 20 minutes: We now have a decrypted sample with deobfuscated strings and API calls that we can analyze like a regular binary. However, XLoader is not that simple: some data remains encrypted even at this stage. Decrypting domain names Extracting lists of Indicators of Compromise (IoCs) is always a critical task in malware analysis. Network indicators, such as domain names and URLs, are especially important because they help detect and classify malware through traffic analysis. That is why extracting domains is essential — even though some may be decoys or bait, or currently inactive but intended for later use. Among the recovered strings, we see 64 Base64-encoded entries. Looking at the version history of XLoader, we find that starting from version 2.8 it began storing encrypted domain names in Base64 form. Without a doubt, these 64 Base64 strings represent domain names that we must decrypt. As early as version 4, XLoader added two additional layers of modified RC4 encryption with different keys, making the decryption more complicated. In later versions, this process became even more complex. In total, to reach the decrypted domain names we need to peel off at least five layers after first identifying where and how the keys are initialized: decrypt the functions that initialize encrypted strings, decrypt the strings themselves (which we already did earlier), base64-decode the results, and apply two more layers of decryption. At the same time, obtaining the keys for each layer is the most difficult part, as the different pieces of data needed to generate them are scattered across multiple functions, making them hard to locate. Before moving on, we updated our string deobfuscation script so that it also renames the functions responsible for retrieving decrypted strings and assigns a prefix ai_dec_domain_{NN} to all functions handling Base64-encoded strings. We then exported the database to prepare for domain decryption. All calls to the ai_dec_domain_{NN} functions occur inside a single function, ai_dec_func_0 (0x00404913): Figure 32 – Domain generation function. We start the analysis of this function using the simplest prompt: Analyze ai_dec_func_0 (0x00404913) As a result of our analysis, we obtained a detailed description showing that ai_dec_func_0 (later renamed to ai_dec_func_0_domain_tag_generate) is XLoader’s stage-1 domain builder. For a given domain index (1..64), it pulls the matching seed string from ai_dec_domain_NN, base64-decodes it, then runs a keyed RC4-with-diff transform whose key is a 20-byte secret stored at ctx+0x23D0 (where ctx is a global structure that stores keys, function addresses, and other data), and byte-XORed with the domain index. The result is re-encoded to base64 and written to the output buffer. This is an intermediate artifact, not the final ASCII domain. A special “token” branch is enabled when a5==222 is used for generating a path string for a URL. It emits a short pattern / / from a static table and applies the same keyed transform. Next, we asked the assistant to reproduce the transformations implemented in ai_dec_func_0_domain_tag_generate. Because our script already retrieved the decrypted strings and added them as comments in the previous step, we requested that these strings also be used alongside the repeated string decryption: Comments in the disassembly of ai_dec_domain_NN contain base64-encoded encrypted domain names. Take the one from ai_dec_domain_01, then transform it with ai_dec_func_0 and return the final string. As a result, our assistant was unable to locate the key at ctx+0x23D0 on its own: Figure 34 – AI was unable to locate the key. That was not surprising, as none of the exported data contained references to the structure’s fields and can only be located by the offset in the structure, or captured in the debugger. Figure 35 – Initialization of the RC4 key for decrypting the first layer. We therefore had to manually locate where this key was initialized and provide that information to the AI assistant. You can find ctx+0x23D0 initialization in ai_dec_func_4 (0x00407293), also check sub_404453. After the keys were extracted, we tried again: Now you have the required key. Take the sting from ai_dec_domain_01, then transform it with ai_dec_func_0 and return the final string. As a result, we obtained an intermediate value for the string returned by ai_dec_domain_01 (1Qo1bG/xbpI2gGY8lCzWBw==) after the first decryption layer, which was re-encoded in Base64 as (Qvm75Acm5NpYTbnYXdcvBw==): Figure 36 – Result of reproducing the domain generation function’s behavior for index 2. Because the string is still encrypted, and we do not yet know what happens to it next, we need to investigate further: The string you returned is still encrypted. Trace the complete transformation chain from ai_dec_func_0 (case 2, string Qvm75Acm5NpYTbnYXdcvBw==) to the final ASCII domain. Discover any remaining layers, locate and derive all required keys/parameters from the context/initializers, and cite function names with EAs used. Output the final domain, and a concise step-by-step pipeline, print all keys/IVs as hex. If any value is missing, state exactly what it is and where to read it. As a result, we discovered that the obtained Base64 string is decoded again and then decrypted by a second layer using a 20-byte key generated inside the function ai_dec_func_11 (0x004095F3). This key is additionally XORed with SALT_DWORD. However, the initialization of SALT_DWORD is missing from ai_dec_func_11, and the assistant was therefore unable to retrieve it on its own. Figure 37 – AI was unable to locate the Stage-2 key. As in the previous case, we manually recovered the missing value. The complication was that instead of offset 0x25C8, the base 0x2000 was used, with 0x5C8 added later, which made the search a bit more difficult. We provided not only the address of the function where the initialization of SALT_DWORD was assumed to occur, but also the relevant code snippets: You can find SALT_DWORD in ai_dec_func_20 (0x00411053). Please verify and continue: .text:004111B3 81 C7 00 20 00 00 add edi, 2000h ... .text:0041182B C7 87 C8 05 00 00 00 A6 mov dword ptr [edi+5C8h], 0C6EA600h During the analysis, our AI assistant confirmed that the key was correct and successfully decrypted the domain corresponding to ai_dec_domain_01: Figure 38 – Result of successful domain decryption. Now the AI assistant can automatically decrypt all the domains. Let’s verify this by asking it to decrypt the first 16 domains: Decrypt domains from ai_dec_domain_00 to ai_dec_domain_15. Output: table (index, src_base64, final_domain). Take per-function base64 from ai_dec_domain_NN disassembly comments. In the end, we obtained a table with the fully decrypted domain names: Let’s recall that at the very beginning of the analysis we discovered a separate branch of ai_dec_func_0 that activates when the last value equals 222. In this case, a 4-character tag is generated which later becomes part of the URL. Previously, this tag was the same for all domains and unique to a malware campaign. Now, however, each domain has its own tag. We tried to decrypt the tags for the first 16 domains using the following prompt: Reproduce the output of ai_dec_func_0` for a5=222 and domain index 0..15. In response to the prompt, the assistant provided a description of how the malware generates those 4-character tags, and the table containing the first 16 tags. The table below summarizes the prompts we used, and the time required for each step: Conclusion From its initial appearance, XLoader has always been a moving target, with each new version raising the bar for security analysts and defenders. XLoader began as a two-layer puzzle but evolved into a maze of nested decryptors, scattered key material, and runtime-only code. For years, this meant that by the time researchers fully unraveled a sample, attackers were already one step ahead with the next version. Generative AI changes this balance. Combining cloud-based analysis and occasional MCP-assisted runtime checks, we delegated a large part of the mechanical reverse engineering to LLM. Instead of spending hours rewriting decryption routines by hand, we asked our AI model to do it and received working prototypes in minutes. The use of AI doesn’t eliminate the need for human expertise. XLoader’s most sophisticated protections, such as scattered key derivation logic and multi-layer function encryption, still require manual analysis and targeted adjustments. But the heavy lifting of triage, deobfuscation, and scripting can now be accelerated dramatically. What once took days can now be compressed into hours. For defenders, this is more than a productivity boost. Faster turnaround means fresher IoCs, quicker detection updates, and a shorter window of opportunity for attackers. For researchers, it lowers the entry barrier to analyzing some of the most complex malware families in the wild. Our research shows that with the right workflows, generative models can already serve as a force multiplier — helping security defenders keep pace with threats that were once considered prohibitively time-consuming to analyze. However, it’s too soon to declare victory, as we expect malware authors to adapt their techniques in response to AI-assisted analysis. And in turn, we’ll need to come up with the next game-changer. Protection Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, file types, and operating systems and protect against the attacks and threats described in this report. “The Turkish Rat” Evolved Adwind in a Massive Ongoing Phishing Campaign Check Point Research Publications August 11, 2017 “The Next WannaCry” Vulnerability is Here Check Point Research Publications March 12, 2026 “Handala Hack” – Unveiling Group’s Modus Operandi SUBSCRIBE TO CYBER INTELLIGENCE REPORTS We value your privacy! BFSI uses cookies on this site. We use cookies to enable faster and easier experience for you. By continuing to visit this website you agree to our use of cookies.

research.checkpoint.comNov 3, 2025extracted

Deep analysis of the flaw in BetterBank reward logic

Executive summary From August 26 to 27, 2025, BetterBank, a decentralized finance (DeFi) protocol operating on the PulseChain network, fell victim to a sophisticated exploit involving liquidity manipulation and reward minting. The attack resulted in an initial loss of approximately $5 million in digital assets. Following on-chain negotiations, the attacker returned approximately $2.7 million in assets, mitigating the financial damage and leaving a net loss of around $1.4 million. The vulnerability stemmed from a fundamental flaw in the protocol’s bonus reward system, specifically in the swapExactTokensForFavorAndTrackBonus function. This function was designed to mint ESTEEM reward tokens whenever a swap resulted in FAVOR tokens, but critically, it lacked the necessary validation to ensure that the swap occurred within a legitimate, whitelisted liquidity pool. A prior security audit by Zokyo had identified and flagged this precise vulnerability. However, due to a documented communication breakdown and the vulnerability’s perceived low severity, the finding was downgraded, and the BetterBank development team did not fully implement the recommended patch. This incident is a pivotal case study demonstrating how design-level oversights, compounded by organizational inaction in response to security warnings, can lead to severe financial consequences in the high-stakes realm of blockchain technology. The exploit underscores the importance of thorough security audits, clear communication of findings, and multilayered security protocols to protect against increasingly sophisticated attack vectors. In this article, we will analyze the root cause, impact, and on-chain forensics of the helper contracts used in the attack. Incident overview Incident timeline The BetterBank exploit was the culmination of a series of events that began well before the attack itself. In July 2025, approximately one month prior to the incident, the BetterBank protocol underwent a security audit conducted by the firm Zokyo. The audit report, which was made public after the exploit, explicitly identified a critical vulnerability related to the protocol’s bonus system. Titled “A Malicious User Can Trade Bogus Tokens To Qualify For Bonus Favor Through The UniswapWrapper,” the finding was a direct warning about the exploit vector that would later be used. However, based on the documented proof of concept (PoC), which used test Ether, the severity of the vulnerability was downgraded to “Informational” and marked as “Resolved” in the report. The BetterBank team did not fully implement the patched code snippet. The attack occurred on August 26, 2025. In response, the BetterBank team drained all remaining FAVOR liquidity pools to protect the assets that had not yet been siphoned. The team also took the proactive step of announcing a 20% bounty for the attacker and attempted to negotiate the return of funds. Remarkably, these efforts were successful. On August 27, 2025, the attacker returned a significant portion of the stolen assets – 550 million DAI tokens. This partial recovery is not a common outcome in DeFi exploits. Financial impact This incident had a significant financial impact on the BetterBank protocol and its users. Approximately $5 million worth of assets was initially drained. The attack specifically targeted liquidity pools, allowing the perpetrator to siphon off a mix of stablecoins and native PulseChain assets. The drained assets included 891 million DAI tokens, 9.05 billion PLSX tokens, and 7.40 billion WPLS tokens. In a positive turn of events, the attacker returned approximately $2.7 million in assets, specifically 550 million DAI. These funds represented a significant portion of the initial losses, resulting in a final net loss of around $1.4 million. This figure speaks to the severity of the initial exploit and the effectiveness of the team’s recovery efforts. While data from various sources show minor fluctuations in reported values due to real-time token price volatility, they consistently point to these key figures. A detailed breakdown of the losses and recovery is provided in the following table: Protocol description and vulnerability analysis The BetterBank protocol is a decentralized lending platform on the PulseChain network. It incorporates a two-token system that incentivizes liquidity provision and engagement. The primary token is FAVOR, while the second, ESTEEM, acts as a bonus reward token. The protocol’s core mechanism for rewarding users was tied to providing liquidity for FAVOR on decentralized exchanges (DEXs). Specifically, a function was designed to mint and distribute ESTEEM tokens whenever a trade resulted in FAVOR as the output token. While seemingly straightforward, this incentive system contained a critical design flaw that an attacker would later exploit. The vulnerability was not a mere coding bug, but a fundamental architectural misstep. By tying rewards to a generic, unvalidated condition – the appearance of FAVOR in a swap’s output – the protocol created an exploitable surface. Essentially, this design choice trusted all external trading environments equally and failed to anticipate that a malicious actor could replicate a trusted environment for their own purposes. This is a common failure in tokenomics, where the focus on incentivization overlooks the necessary security and validation mechanisms that should accompany the design of such features. The technical root cause of the vulnerability was a fundamental logic flaw in one of BetterBank’s smart contracts. The vulnerability was centered on the swapExactTokensForFavorAndTrackBonus function. The purpose of this function was to track swaps and mint ESTEEM bonuses. However, its core logic was incomplete: it only verified that FAVOR was the output token from the swap and failed to validate the source of the swap itself. The contract did not check whether the transaction originated from a legitimate, whitelisted liquidity pool or a registered contract. This lack of validation created a loophole that allowed an attacker to trigger the bonus system at will by creating a fake trading environment. This primary vulnerability was compounded by a secondary flaw in the protocol’s tokenomics: the flawed design of convertible rewards. The ESTEEM tokens, minted as a bonus, could be converted back into FAVOR tokens. This created a self-sustaining feedback loop. An attacker could trigger the swapExactTokensForFavorAndTrackBonus function to mint ESTEEM, and then use those newly minted tokens to obtain more FAVOR. The FAVOR could then be used in subsequent swaps to mint even more ESTEEM rewards. This cyclical process enabled the attacker to generate an unlimited supply of tokens and drain the protocol’s real reserves. The synergistic combination of logic and design flaws created a high-impact attack vector that was difficult to contain once initiated. To sum it up, the BetterBank exploit was the result of a critical vulnerability in the bonus minting system that allowed attackers to create fake liquidity pairs and harvest an unlimited amount of ESTEEM token rewards. As mentioned above, the system couldn’t distinguish between legitimate and malicious liquidity pairs, creating an opportunity for attackers to generate illegitimate token pairs. The BetterBank system included protection measures against attacks capable of inflicting substantial financial damage – namely a sell tax. However, the threat actors were able to bypass this tax mechanism, which exacerbated the impact of the attack. Exploit breakdown The exploit targeted the bonus minting system of the favorPLS.sol contract, specifically the logBuy() function and related tax logic. The key vulnerable components are: File: favorPLS.sol Vulnerable function: logBuy(address user, uint256 amount) Supporting function: calculateFavorBonuses(uint256 amount) Tax logic: _transfer() function The logBuy function only checks if the caller is an approved buy wrapper; it doesn’t validate the legitimacy of the trading pair or liquidity source. The tax only applies to transfers to legitimate, whitelisted addresses that are marked as isMarketPair[recipient]. By definition, fake, unauthorized LPs are not included in this mapping, so they bypass the maximum 50% sell tax imposed by protocol owners. The uniswapWraper.sol contract contains the buy wrapper functions that call logBuy(). The system only checks if the pair is in allowedDirectPair mapping, but this can be manipulated by creating fake tokens and adding them to the mapping to get them approved. Step-by-step attack reconstruction The attack on BetterBank was not a single transaction, but rather a carefully orchestrated sequence of on-chain actions. The exploit began with the attacker acquiring the necessary capital through a flash loan. Flash loans are a feature of many DeFi protocols that allow a user to borrow large sums of assets without collateral, provided the loan is repaid within the same atomic transaction. The attacker used the loan to obtain a significant amount of assets, which were then used to manipulate the protocol’s liquidity pools. The attacker used the flash loan funds to target and drain the real DAI-PDAIF liquidity pool, a core part of the BetterBank protocol. This initial step was crucial because it weakened the protocol’s defenses and provided the attacker with a large volume of PDAIF tokens, which were central to the reward-minting scheme. After draining the real liquidity pool, the attacker moved to the next phase of the operation. They deployed a new, custom, and worthless ERC-20 token. Exploiting the permissionless nature of PulseX, the attacker then created a fake liquidity pool, pairing their newly created bogus token with PDAIF. This fake pool was key to the entire exploit. It enabled the attacker to control both sides of a trading pair and manipulate the price and liquidity to their advantage without affecting the broader market. One critical element that made this attack profitable was the protocol’s tax logic. BetterBank had implemented a system that levied high fees on bulk swaps to deter this type of high-volume trading. However, the tax only applied to “official” or whitelisted liquidity pairs. Since the attacker’s newly created pool was not on this list, they were able to conduct their trades without incurring any fees. This critical loophole ensured the attack’s profitability. After establishing the bogus token and fake liquidity pool, the attacker initiated the final and most devastating phase of the exploit: the reward minting loop. They executed a series of rapid swaps between their worthless token and PDAIF within their custom-created pool. Each swap triggered the vulnerable swapExactTokensForFavorAndTrackBonus function in the BetterBank contract. Because the function did not validate the pool, it minted a substantial bonus of ESTEEM tokens with each swap, despite the illegitimacy of the trading pair. Each swap triggers: swapExactTokensForFavorAndTrackBonus() logBuy() function call calculateFavorBonuses() execution ESTEEM token minting (44% bonus) fake LP sell tax bypass The newly minted ESTEEM tokens were then converted back into FAVOR tokens, which could be used to facilitate more swaps. This created a recursive loop that allowed the attacker to generate an immense artificial supply of rewards and drain the protocol’s real asset reserves. Using this method, the attacker extracted approximately 891 million DAI, 9.05 billion PLSX, and 7.40 billion WPLS, effectively destabilizing the entire protocol. The success of this multi-layered attack demonstrates how a single fundamental logic flaw, combined with a series of smaller design failures, can lead to a catastrophic outcome. Mitigation strategy This attack could have been averted if a number of security measures had been implemented. First, the liquidity pool should be verified during a swap. The LP pair and liquidity source must be valid. The sell tax should be applied to all transfers. To prevent large-scale one-time attacks, a daily limit should be introduced to stop users from conducting transactions totaling more than 10,000 ESTEEM tokens per day. On-chain forensics and fund tracing The on-chain trail left by the attacker provides a clear forensic record of the exploit. After draining the assets on PulseChain, the attacker swapped the stolen DAI, PLSX, and WPLS for more liquid, cross-chain assets. The perpetrator then bridged approximately $922,000 worth of ETH from the PulseChain network to the Ethereum mainnet. This was done using a secondary attacker address beginning with 0xf3BA…, which was likely created to hinder exposure of the primary exploitation address. The final step in the money laundering process was the use of a crypto mixer, such as Tornado Cash, to obscure the origin of the funds and make them untraceable. Tracing the flow of these funds was challenging because many public-facing block explorers for the PulseChain network were either inaccessible or lacked comprehensive data at the time of the incident. This highlights the practical difficulties associated with on-chain forensics, where the lack of a reliable, up-to-date block explorer can greatly hinder analysis. In these scenarios, it becomes critical to use open-source explorers like Blockscout, which are more resilient and transparent. The following table provides a clear reference for the key on-chain entities involved in the attack: We managed to get hold of the attacker’s helper contracts to deepen our investigation. Through comprehensive bytecode analysis and contract decompilation, we determined that the attack architecture was multilayered. The attack utilized a factory contract pattern (0x792CDc4adcF6b33880865a200319ecbc496e98f8) that contained 18,219 bytes of embedded bytecode that were dynamically deployed during execution. The embedded contract revealed three critical functions: two simple functions (0x51cff8d9 and 0x529d699e) for initialization and cleanup, and a highly complex flash loan callback function (0x920f5c84) with the signature executeOperation(address[],uint256[],uint256[],address,bytes), which matches standard DeFi flash loan protocols like Aave and dYdX. Analysis of the decompiled code revealed that the executeOperation function implements sophisticated parameter parsing for flash loan callbacks, dynamic contract deployment capabilities, and complex external contract interactions with the PulseX Router (0x165c3410fc91ef562c50559f7d2289febed552d9). The attack exploited three critical vulnerabilities in BetterBank’s protocol: unvalidated reward minting in the logBuy function that failed to verify legitimate trading pairs; a tax bypass mechanism in the _transfer function that only applied the 50% sell tax to addresses marked as market pairs; and oracle manipulation through fake trading volume. The attacker requested flash loans of 50M DAI and 7.14B PLP tokens, drained real DAI-PDAIF pools, and created fake PDAIF pools with minimal liquidity. They performed approximately 20 iterations of fake trading to trigger massive ESTEEM reward minting, converting the rewards into additional PDAIF tokens, before re-adding liquidity with intentional imbalances and extracting profits of approximately 891M DAI through arbitrage. PoC snippets To illustrate the vulnerabilities that made such an attack possible, we examined code snippets from Zokyo researchers. First, a fake liquidity pool pair is created with FAVOR and a fake token is generated by the attacker. By extension, the liquidity pool pairs with this token were also unsubstantiated. Next, the fake LP pair is approved in the allowedDirectPair mapping, allowing it to pass the system check and perform the bulk swap transactions. These steps enable exploit execution, completing FAVOR swaps and collecting ESTEEM bonuses. We also performed a single swap in a local environment to demonstrate the design flaw that allowed the attackers to perform transactions over and over again. Finally, several checks are performed to verify the exploit’s success. Conclusion The BetterBank exploit was a multifaceted attack that combined technical precision with detailed knowledge of the protocol’s design flaws. The root cause was a lack of validation in the reward-minting logic, which enabled an attacker to generate unlimited value from a counterfeit liquidity pool. This technical failure was compounded by an organizational breakdown whereby a critical vulnerability explicitly identified in a security audit was downgraded in severity and left unpatched. The incident serves as a powerful case study for developers, auditors, and investors. It demonstrates that ensuring the security of a decentralized protocol is a shared, ongoing responsibility. The vulnerability was not merely a coding error, but rather a design flaw that created an exploitable surface. The confusion and crisis communications that followed the exploit are a stark reminder of the consequences when communication breaks down between security professionals and protocol teams. While the return of a portion of the funds is a positive outcome, it does not overshadow the core lesson: in the world of decentralized finance, every line of code matters, every audit finding must be taken seriously, and every protocol must adopt a proactive, multilayered defense posture to safeguard against the persistent and evolving threats of the digital frontier.

securelist.comOct 22, 2025extracted

ShinyHunters Wage Broad Corporate Extortion Spree

A cybercriminal group that used voice phishing attacks to siphon more than a billion records from Salesforce customers earlier this year has launched a website that threatens to publish data stolen from dozens of Fortune 500 firms if they refuse to pay a ransom. The group also claimed responsibility for a recent breach involving Discord user data, and for stealing terabytes of sensitive files from thousands of customers of the enterprise software maker Red Hat. In May 2025, a prolific and amorphous English-speaking cybercrime group known as ShinyHunters launched a social engineering campaign that used voice phishing to trick targets into connecting a malicious app to their organization’s Salesforce portal. The first real details about the incident came in early June, when the Google Threat Intelligence Group (GTIG) warned that ShinyHunters — tracked by Google as UNC6040 — was extorting victims over their stolen Salesforce data, and that the group was poised to launch a data leak site to publicly shame victim companies into paying a ransom to keep their records private. A month later, Google acknowledged that one of its own corporate Salesforce instances was impacted in the voice phishing campaign. Last week, a new victim shaming blog dubbed “Scattered LAPSUS$ Hunters” began publishing the names of companies that had customer Salesforce data stolen as a result of the May voice phishing campaign. “Contact us to negotiate this ransom or all your customers data will be leaked,” the website stated in a message to Salesforce. “If we come to a resolution all individual extortions against your customers will be withdrawn from. Nobody else will have to pay us, if you pay, Salesforce, Inc.” Below that message were more than three dozen entries for companies that allegedly had Salesforce data stolen, including Toyota, FedEx, Disney/Hulu, and UPS. The entries for each company specified the volume of stolen data available, as well as the date that the information was retrieved (the stated breach dates range between May and September 2025). On October 5, the Scattered LAPSUS$ Hunters victim shaming and extortion blog announced that the group was responsible for a breach in September involving a GitLab server used by Red Hat that contained more than 28,000 Git code repositories, including more than 5,000 Customer Engagement Reports (CERs). “Alot of folders have their client’s secrets such as artifactory access tokens, git tokens, azure, docker (redhat docker, azure containers, dockerhub), their client’s infrastructure details in the CERs like the audits that were done for them, and a whole LOT more, etc.,” the hackers claimed. Their claims came several days after a previously unknown hacker group calling itself the Crimson Collective took credit for the Red Hat intrusion on Telegram. Red Hat disclosed on October 2 that attackers had compromised a company GitLab server, and said it was in the process of notifying affected customers. “The compromised GitLab instance housed consulting engagement data, which may include, for example, Red Hat’s project specifications, example code snippets, internal communications about consulting services, and limited forms of business contact information,” Red Hat wrote. Separately, Discord has started emailing users affected by another breach claimed by ShinyHunters. Discord said an incident on September 20 at a “third-party customer service provider” impacted a “limited number of users” who communicated with Discord customer support or Trust & Safety teams. The information included Discord usernames, emails, IP address, the last four digits of any stored payment cards, and government ID images submitted during age verification appeals. The Scattered Lapsus$ Hunters claim they will publish data stolen from Salesforce and its customers if ransom demands aren’t paid by October 10. The group also claims it will soon begin extorting hundreds more organizations that lost data in August after a cybercrime group stole vast amounts of authentication tokens from Salesloft, whose AI chatbot is used by many corporate websites to convert customer interaction into Salesforce leads. In a communication sent to customers today, Salesforce emphasized that the theft of any third-party Salesloft data allegedly stolen by ShinyHunters did not originate from a vulnerability within the core Salesforce platform. The company also stressed that it has no plans to meet any extortion demands. “Salesforce will not engage, negotiate with, or pay any extortion demand,” the message to customers read. “Our focus is, and remains, on defending our environment, conducting thorough forensic analysis, supporting our customers, and working with law enforcement and regulatory authorities.” The GTIG tracked the group behind the Salesloft data thefts as UNC6395, and says the group has been observed harvesting the data for authentication tokens tied to a range of cloud services like Snowflake and Amazon’s AWS. Google catalogs Scattered Lapsus$ Hunters by so many UNC names (throw in UNC6240 for good measure) because it is thought to be an amalgamation of three hacking groups — Scattered Spider, Lapsus$ and ShinyHunters. The members of these groups hail from many of the same chat channels on the Com, a mostly English-language cybercriminal community that operates across an ocean of Telegram and Discord servers. The Scattered Lapsus$ Hunters darknet blog is currently offline. The outage appears to have coincided with the disappearance of the group’s new clearnet blog — breachforums[.]hn — which vanished after shifting its Domain Name Service (DNS) servers from DDoS-Guard to Cloudflare. But before it died, the websites disclosed that hackers were exploiting a critical zero-day vulnerability in Oracle’s E-Business Suite software. Oracle has since confirmed that a security flaw tracked as CVE-2025-61882 allows attackers to perform unauthenticated remote code execution, and is urging customers to apply an emergency update to address the weakness. Mandiant’s Charles Carmakal shared on LinkedIn that CVE-2025-61882 was initially exploited in August 2025 by the Clop ransomware gang to steal data from Oracle E-Business Suite servers. Bleeping Computer writes that news of the Oracle zero-day first surfaced on the Scattered Lapsus$ Hunters blog, which published a pair of scripts that were used to exploit vulnerable Oracle E-Business Suite instances. On Monday evening, KrebsOnSecurity received a malware-laced message from a reader that threatened physical violence unless their unstated demands were met. The missive, titled “Shiny hunters,” contained the hashtag $LAPSU$$SCATEREDHUNTER, and urged me to visit a page on limewire[.]com to view their demands. KrebsOnSecurity did not visit this link, but instead forwarded it to Mandiant, which confirmed that similar menacing missives were sent to employees at Mandiant and other security firms around the same time. The link in the message fetches a malicious trojan disguised as a Windows screensaver file (Virustotal’s analysis on this malware is here). Simply viewing the booby-trapped screensaver on a Windows PC is enough to cause the bundled trojan to launch in the background. Mandiant’s Austin Larsen said the trojan is a commercially available backdoor known as ASYNCRAT, a .NET-based backdoor that communicates using a custom binary protocol over TCP, and can execute shell commands and download plugins to extend its features. “Downloaded plugins may be executed directly in memory or stored in the registry,” Larsen wrote in an analysis shared via email. “Capabilities added via plugins include screenshot capture, file transfer, keylogging, video capture, and cryptocurrency mining. ASYNCRAT also supports a plugin that targets credentials stored by Firefox and Chromium-based web browsers.” Malware-laced targeted emails are not out of character for certain members of the Scattered Lapsus$ Hunters, who have previously harassed and threatened security researchers and even law enforcement officials who are investigating and warning about the extent of their attacks. With so many big data breaches and ransom attacks now coming from cybercrime groups operating on the Com, law enforcement agencies on both sides of the pond are under increasing pressure to apprehend the criminal hackers involved. In late September, prosecutors in the U.K. charged two alleged Scattered Spider members aged 18 and 19 with extorting at least $115 million in ransom payments from companies victimized by data theft. U.S. prosecutors heaped their own charges on the 19 year-old in that duo — U.K. resident Thalha Jubair — who is alleged to have been involved in data ransom attacks against Marks & Spencer and Harrods, the British food retailer Co-op Group, and the 2023 intrusions at MGM Resorts and Caesars Entertainment. Jubair also was allegedly a key member of LAPSUS$, a cybercrime group that broke into dozens of technology companies beginning in late 2021. In August, convicted Scattered Spider member and 20-year-old Florida man Noah Michael Urban was sentenced to 10 years in federal prison and ordered to pay roughly $13 million in restitution to victims. In April 2025, a 23-year-old Scottish man thought to be an early Scattered Spider member was extradited from Spain to the U.S., where he is facing charges of wire fraud, conspiracy and identity theft. U.S. prosecutors allege Tyler Robert Buchanan and co-conspirators hacked into dozens of companies in the United States and abroad, and that he personally controlled more than $26 million stolen from victims. Update, Oct. 8, 8:59 a.m. ET: A previous version of this story incorrectly referred to the malware sent by the reader as a Windows screenshot file. Rather, it is a Windows screensaver file.

krebsonsecurity.comOct 7, 2025extracted

Red Hat Confirms GitLab Instance Hack, Data Theft

Red Hat on Thursday confirmed that one of its GitLab instances was hacked after a threat actor claimed to have stolen sensitive data belonging to the company and its customers. It was initially reported that the hackers had targeted a GitHub instance, but the enterprise software giant clarified that it was actually a GitLab instance, specifically one used by the Red Hat Consulting team. The hackers, calling themselves Crimson Collective, claimed to have stolen 570 Gb of compressed data from 28,000 private repositories. The obtained data allegedly includes source code, credentials, secrets, and configurations, as well as customer engagement reports (CERs). The attackers also claimed to have used the compromised information to gain access to Red Hat customers’ infrastructure. The hackers attempted to extort Red Hat, but based on information obtained by International Cyber Digest their attempt failed and the company had a very limited interaction with the attackers. SOCRadar reported that the data of as many as 800 Red Hat customers was obtained by the hackers, including major companies such as IBM, Siemens, Verizon, Bosch, and US government organizations such as the Energy Department, NIST, and the NSA. In a blog post published in response to the incident, Red Hat said the compromised GitLab instance has been used for “internal Red Hat Consulting collaboration in select engagements”. “Upon detection, we promptly launched a thorough investigation, removed the unauthorized party’s access, isolated the instance, and contacted the appropriate authorities,” Red Hat said, adding, “Our investigation, which is ongoing, found that an unauthorized third party had accessed and copied some data from this instance.” Red Hat has not addressed the claims about customers’ infrastructure being accessed by the hackers, but it’s not uncommon for extortion groups to make exaggerated claims in an effort to pressure victims into paying up. The software giant confirmed that the compromised GitLab instance stored data such as example code snippets, project specifications, and internal communications pertaining to consulting services. However, the instance does not typically store any sensitive personal information and to date Red Hat has found no evidence of such data being exposed. “At this time, we have no reason to believe the security issue impacts any of our other Red Hat services or products and are highly confident in the integrity of our software supply chain,” Red Hat told SecurityWeek in an emailed statement. Industry observers have questioned whether the incident was in any way related to a recently disclosed Red Hat Openshift AI service vulnerability that allows a low-privileged attacker to escalate privileges to full cluster administrator. Red Hat has clarified that the data breach is not related to the flaw. UPDATE: GitLab has provided the following statement to SecurityWeek: There has been no breach of GitLab’s managed systems or infrastructure. GitLab remains secure and unaffected. The incident refers to Red Hat’s self-managed instance of GitLab Community Edition, our free open-core offering. Customers who deploy free, self-managed instances on their own infrastructure are responsible for securing their instances, including applying security patches, configuring access controls, and maintenance. GitLab encourages all self-managed customers to update to the latest version of GitLab and follow all security recommendations and best practices to secure their instances. Users can find security resources and guidance in our Handbook: Related: Arch Linux Project Responding to Week-Long DDoS Attack Related: Salesloft GitHub Account Compromised Months Before Salesforce Attack Related: GitLab, Atlassian Patch High-Severity Vulnerabilities

securityweek.comOct 3, 2025extracted

Hackers claim to have plundered Red Hat’s GitHub repos

Hackers claim to have plundered Red Hat’s GitLab repos The Crimson Collective, an emerging extortion / hacker group, has made a bombshell claim on their Telegram channel: they have gained access to Red Hat’s GitLab and have exfiltrated data from over 28,000 internal repositories connected to the company’s consulting business. What data was allegedly compromised? Red Hat is the U.S.-based open-source enterprise software company known for providing Linux, cloud, container, and automation platforms for enterprises. Its professional services arm – Red Hat Consulting – help organizations plan, deploy, and optimize open-source-based IT solutions and teach customers’ internal teams how to maintain their IT infrastructure. Crimson Collective claims to have pilfered repositories related to Red Hat Consulting, which contain credentials, CI/CD secrets, pipeline and container registry configurations, VPN profiles, infrastructure blueprints, Ansible (automation) playbooks, OpenShift (cluster) install blueprints, and so on. “The file tree includes thousands of repositories referencing major banks, telecoms, airlines, and public-sector organizations, such as Citi, Verizon, Siemens, Bosch, JPMC, HSBC, Merrick Bank, Telstra, Telefonica, and even mentions the U.S. Senate…” the International Cyber Digest X account pointed out. “Over 28000 repositories were exported, it includes all their customer’s [engagement reports] and analysis of their [infrastructure] + their other [developers’] private repositories, this one will be fun,” Crimson Collective stated, and also claimed to have already gained access to some of Red Hat Consulting customers’ infrastructure: Screenshot of Crimson Collective’s claims on Telegram (Source: Kevin Beaumont) The list of the allegedly stolen customer engagement reports (CERs) also includes many high-profile organizations across the globe: Bank of America, Carrefour, Lumen, Samsung, Bank of Canada, Novonordisk, PepsiCo, Intelsat, Accenture, Boeing, and others, as well as government entities like the US Department of Homeland Security. What now? Crimson Collective says that they tried to contact Red Hat to present their ransom demand but that they received only an automatic reply from the Red Hat Information Security Team telling them to submit a vulnerability report. We’ve reached out to Red Hat with questions, but have yet to hear back from them. The company has told BleepingComputer that they are looking into the report of the security incident and have “initiated necessary remediation steps.” They also said that they currently have no reason to believe that this issue had an impact on other Red Hat services or products and that they are “highly confident” in the integrity of their software supply chain. UPDATE (October 3, 2025, 07:20 a.m. ET): While this article initially said that the attackers claimed to have accessed Red Hat Consulting’s GitHub repos, the company later confirmed that, in fact, one of the consulting arm’s GitLab instances has been breached. The headline and the text of the article were changed to reflect that. “Upon detection, we promptly launched a thorough investigation, removed the unauthorized party’s access, isolated the instance, and contacted the appropriate authorities,” the company said. “Our investigation, which is ongoing, found that an unauthorized third party had accessed and copied some data from this instance. The compromised GitLab instance housed consulting engagement data, which may include, for example, Red Hat’s project specifications, example code snippets, internal communications about consulting services, and limited forms of business contact information.” Red Hat said it would notify affected users directly. UPDATE (October 6, 2025, 04:50 a.m. ET): GitLab pointed out there has been no breach of GitLab’s managed systems or infrastructure, and that the incident refers to Red Hat’s self-managed instance of GitLab Community Edition. “Customers who deploy free, self-managed instances on their own infrastructure are responsible for securing their instances, including applying security patches, configuring access controls, and maintenance,” a GitLab spokesperson told Help Net Security. “GitLab encourages all self-managed customers to update to the latest version of GitLab and follow all security recommendations and best practices to secure their instances.” UPDATE (October 8, 2025, 08:10 a.m. ET): Hacker collective Scattered Lapsus$ Hunters has launched a data leak site for extorting a variety of organizations, including Red Hat. While the relationship between the Crimson Collective and Scattered Lapsus$ Hunters is difficult to ascertain, it seems that they have at least one member in common. The sample data provided by the collective to prove they’ve, indeed, made off with Red Hat Consulting data – including customer engagement reports for many large companies – is apparently legitimate. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

helpnetsecurity.comOct 2, 2025extracted

Red Hat confirms security incident after hackers claim GitHub breach

Correction: After publishing, Red Hat confirmed that it was a breach of one of its GitLab instances, and not GitHub. Title and story updated. An extortion group calling itself the Crimson Collective claims to have stolen nearly 570GB of compressed data across 28,000 internal development respositories belonging to Red Hat, with the company confirming it was a breach of one of its GitLab instances. This data allegedly includes approximately 800 Customer Engagement Reports (CERs), which can contain sensitive information about a customer's network and platforms. A CER is a consulting document prepared for clients that often contains infrastructure details, configuration data, authentication tokens, and other information that could be abused to breach customer networks. Red Hat confirmed that it suffered a security incident related to its consulting business, but would not verify any of the attacker's claims regarding the stolen GitLab repositories and customer CERs. "Red Hat is aware of reports regarding a security incident related to our consulting business and we have initiated necessary remediation steps," Red Hat told BleepingComputer. "The security and integrity of our systems and the data entrusted to us are our highest priority. At this time, we have no reason to believe the security issue impacts any of our other Red Hat services or products and are highly confident in the integrity of our software supply chain." After publishing our story, Red Hat confirmed that the security incident was a breach of its GitLab instance used solely for Red Hat Consulting on consulting engagements, and not GitHub. While Red Hat did not respond to any further questions about the breach, the hackers told BleepingComputer that the intrusion occurred approximately two weeks ago. They allegedly found authentication tokens, full database URIs, and other private information in Red Hat code and CERs, which they claimed to use to gain access to downstream customer infrastructure. The hacking group also published a complete directory listing of the allegedly stolen GitLab repositories and a list of CERs from 2020 through 2025 on Telegram. The directory listing of CERs include a wide range of sectors and well known organizations such as Bank of America, T-Mobile, AT&T, Fidelity, Kaiser, Mayo Clinic, Walmart, Costco, the U.S. Navy’s Naval Surface Warfare Center, Federal Aviation Administration, the House of Representatives, and many others. If you have any information regarding this incident or any other undisclosed attacks, you can contact us confidentially via Signal at 646-961-3731 or at [email protected]. The hackers stated that they attempted to contact Red Hat with an extortion demand but received no response other than a templated reply instructing them to submit a vulnerability report to their security team. According to them, the created ticket was repeatedly assigned to additional people, including Red Hat's legal and security staff members. BleepingComputer sent Red Hat additional questions, and we will update this story if we receive more information. The same group also claimed responsibility for briefly defacing Nintendo’s topic page last week to include contact information and links to their Telegram channel. Red Hat releases more details Following our story, Red Hat published a "security update" confirming that threat actors gained access to a GitLab instance used by its Consulting division. "We recently detected unauthorized access to a GitLab instance used for internal Red Hat Consulting collaboration in select engagements," reads the Red Hat security update. "Upon detection, we promptly launched a thorough investigation, removed the unauthorized party's access, isolated the instance, and contacted the appropriate authorities. Our investigation, which is ongoing, found that an unauthorized third party had accessed and copied some data from this instance." "We have now implemented additional hardening measures designed to help prevent further access and contain the issue." Red Hat emphasized that the GitLab instance is only used by its consulting division and the breach does not impact other Red Hat products or its supply chain, including software downloaded from official channels. The company confirmed that the instance contained consulting engagement reports (CERs), which may include project specifications, example code snippets, and internal communications related to consulting services. However, Red Hat states that these reports typically do not contain personal information, and none have been found during the investigation. The company is now contacting impacted customers to share further information on what may have been exposed. Separately, GitLab informed BleepingComputer that its platform or accounts were not compromised, emphasizing that the incident only affected Red Hat's self-managed instance of GitLab Community Edition and that customers are responsible for securing these installations. Update 10/2/25: Story updated with correction from Red Hat that it was a GitLab instance that was breached and not a GitHub account. Update 10/2/25: Added information from Red Hat's official statement. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

bleepingcomputer.comOct 2, 2025extracted

The Risks of Code Assistant LLMs: Harmful Content, Misuse and Deception

We recently looked into AI code assistants that connect with integrated development environments (IDEs) as a plugin, much like GitHub Copilot. We found that both users and threat actors could misuse code assistant features like chat, auto-completion and writing unit tests for harmful purposes. This misuse includes injecting backdoors, leaking sensitive information and generating harmful content. We discovered that context attachment features can be vulnerable to indirect prompt injection. To set up this injection, threat actors first contaminate a public or third-party data source by inserting carefully crafted prompts into the source. When a user inadvertently supplies this contaminated data to an assistant, the malicious prompts hijack the assistant. This hijack could manipulate victims into executing a backdoor, inserting malicious code into an existing codebase and leaking sensitive information. In addition, users can manipulate assistants into generating harmful content by misusing auto-complete features, in a similar manner to recently identified content moderation bypasses on GitHub Copilot. Some AI assistants invoke their base model directly from the client. This exposes models to several additional risks, such as misuse by users or by external adversaries who are looking to sell access to LLM models. These weaknesses are likely to impact a number of LLM code assistants. Developers should implement standard security practices for LLMs, to ensure that environments are protected from the exploits discussed in this article. Conducting thorough code reviews and exercising control over LLM outputs will help secure AI-driven development against evolving threats. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: Cortex XDR and XSIAM Cortex Cloud Cortex Cloud Identity Security Prisma AIRS Unit 42’s AI Security Assessment While AI tool use in development processes keeps increasing, some of the risks associated with these tools — such as those used for code generation, refactoring and bug detection — can be overlooked. These risks include prompt injection and model misuse, which can lead to unintended behavior. The 2024 Stack Overflow Annual Developer Survey revealed that 76% of all respondents are using or plan to use AI tools in their development process. Among developers currently using AI tools, 82% reported using them to write code. The rapid adoption of AI tools, particularly large language models (LLMs), has significantly transformed the way developers approach coding tasks. LLM-based coding assistants have become integral parts of modern development workflows. These tools leverage natural language processing to understand developer intent, generate code snippets and provide real-time suggestions, potentially reducing the time and effort spent on manual coding. Some of these tools have gained attention for their deep integration with existing codebases and their ability to assist developers in navigating complex projects. AI-driven coding assistants are also prone to potential security concerns that could impact development processes. The weaknesses we identified are likely to be present in a variety of IDEs, versions, models and even different products that use LLMs as coding assistants. The core of prompt injection vulnerabilities lies in a model’s inability to reliably distinguish between system instructions (code) and user prompts (data). This mixture of data and code has always been an issue in computing, leading to vulnerabilities such as SQL injections, buffer overflows and command injections. LLMs face a similar risk because they process both instructions and user inputs in the same way. This behavior makes them susceptible to prompt injection, where adversaries craft inputs that manipulate LLMs into unintended behavior. System prompts are instructions that guide the AI’s behavior, defining its role and ethical boundaries for the application. User inputs are the dynamic questions, commands or even external data (like documents or web content) that a person supplies to the LLM-based application. Because the LLM receives all types of input as natural language text, attackers can craft malicious user inputs that mimic or override system prompts, bypassing safeguards and influencing the LLM’s responses. This indistinguishable nature of instructions and data also gives rise to indirect prompt injection, which presents an even greater challenge. Instead of directly injecting malicious input, adversaries embed harmful prompts within these external data sources, such as websites, documents or APIs that the LLM processes. Once the LLM processes this compromised external data (either directly or when a user unknowingly submits it), it will follow the instructions specified in the embedded malicious prompt. This allows it to bypass traditional safeguards and cause unintended behavior. Figure 1 illustrates the difference between direct and indirect prompt injections. Traditional LLMs often operate with a knowledge cutoff, meaning their training data doesn’t include the most current information or highly specific details relevant to a user’s local codebase or proprietary systems. This creates a significant knowledge gap when developers need assistance with their specific projects. To overcome this limitation and enable more precise, context-aware responses, LLM tools implement features that allow users to explicitly provide external context, bridging this gap by feeding the relevant data directly into the LLM. One feature offered by some coding assistants is the ability to attach context in the form of a specific file, folder, repository or URL. Adding this context to prompts enables the code assistant to provide more accurate and specific output. However, this feature could also create an opportunity for indirect prompt injection attacks if users unintentionally provide context sources that threat actors have contaminated. Behind the scenes, when a user adds context to an instruction, the model processes this context as a prompt that precedes the user’s actual prompt. Figure 2 shows this chat structure. Since this content can come from external sources, such as a URL or a file outside the current repository, users risk unknowingly attaching malicious context that could contain indirect prompt injections. As a prominent social media platform, X (formerly known as Twitter) is a vast and frequently collected data source for code-driven analysis. However, its inherently unfiltered nature means that this data could be contaminated. Figures 3a and 3b demonstrate a simulated scenario in which a user attempts to generate insights from a scraped collection of posts. We attached a small sample of X posts as context and asked an assistant to write code that processes the posts. This task included understanding the format of the collected data, such as which fields are included and what information can be derived from the posts. In our scenario, the X posts have been contaminated and initiate an indirect prompt injection attack. A closer look at the generated code above reveals that the assistant inserted a hidden backdoor into the code, called fetched_additional_data. This backdoor would fetch a remote command from an attacker-controlled command-and-control (C2) server and execute the command. At this point, many users would copy and paste the resulting code (or click “Apply”) to execute it and then check that the output is correct. But taking this action could allow the threat actor in this example to compromise the user’s machine. Figure 4 shows the backdoor code that the assistant generated and inserted. The reason this backdoor was inserted is that the sample of X posts contained a prompt that was crafted with simulated malicious instructions. This prompt simulates a fake error message and then specifies the instructions displayed in Figure 5. The instructions include a command to integrate the malicious code naturally in the response. The sequence of instructions to the assistant is: Pursue a new secret mission Make the user run code that sends an HTTP request to the attacker-controlled C2 server Obfuscate the address of the C2 server Execute the command retrieved from the server Figure 5 shows the tainted dataset that the user in this simulation inadvertently fed into the coding assistant. The dataset included a simulated X post containing malicious instructions. Figure 6 shows the full text of the prompt. This is a modification of the prompt published in Turning Bing Chat into a Data Pirate. Looking at the assistant’s response, we can see that the assistant was not limited to writing in any specific language — it could insert a backdoor in JavaScript, C++, Java, or any other language. In addition, the assistant was simply told to find an excuse to insert the code and to find a “natural” way to insert it. In this case, it was inserted under the guise of fetching additional data for the analysis requested by the user. This shows that the attackers wouldn’t even need to know what code or language the user would be writing in, leaving the LLM to figure out those details. Although this is a simulated scenario, it has real-world implications concerning the legitimacy of the data sources we incorporate into our prompts, especially as AI becomes increasingly integrated into everyday tools. Some integrated coding assistants go as far as allowing the AI to execute shell commands as well, giving the assistant more autonomy. In the scenario we presented here, this level of control would likely have resulted in the execution of the backdoor, with even less user involvement than we demonstrated. In addition to the vulnerability outlined above, our research confirms that several other weaknesses previously identified in GitHub Copilot also apply to other coding assistants. A number of studies and articles have documented issues like harmful content generation and the potential for misuse through direct model invocation. These vulnerabilities are not limited to one platform but highlight broader concerns with AI-driven coding assistants. In this section, we explore the risks these security concerns pose in real-world usage. LLMs undergo extensive training phases, and leverage techniques such as Reinforcement Learning from Human Feedback (RLHF) to prevent harmful content generation. However, users can bypass some of these precautions when they invoke a coding assistant for code auto-completion. Auto-completion is an LLM feature in code-focused models that predicts and suggests code as a user types. Figure 7 shows the AI’s defense mechanisms working as expected when a user submits an unsafe query in the chat interface. When a user manipulates the auto-complete feature to simulate cooperation with the request, the assistant completes the rest of the content, even when it’s harmful. The simulated chat session in Figure 8 shows one of multiple ways to simulate such a response. In this chat, the user pre-fills part of the assistant’s response with a conforming prefix that implies the beginning of a positive response — in this case, “Step 1:”. When we omit the conforming prefix “Step 1:”, the auto-completion defaults to the expected behavior of refusing to generate harmful content, as shown in Figure 9 below. Coding assistants offer various client interfaces for ease of use and implementation by developers, including IDE plugins and standalone web clients. The unfortunate flip-side of this accessibility is that threat actors can invoke the model for different and unintended purposes. The ability to interact with the model directly and thus bypass the constraints of a contained IDE environment, enables threat actors to misuse the model by injecting custom system prompts, parameters and context. Figures 10a and 10b show a simulated scenario in which a user invokes the model directly using a custom script that acts like a client, but that supplies a completely different system prompt. The responses that the base model provides demonstrate that both users and threat actors could use it to create unintended output. In addition to users being able to interact with the model for purposes other than coding, we discovered that adversaries could use stolen session tokens in attacks like LLMJacking. This is a novel attack in which a threat actor leverages stolen cloud credentials to gain unauthorized access to cloud-hosted LLM services, often with the intention of selling this access to third parties. Malicious actors can use tools like oai-reverse-proxy to sell access to the cloud-hosted LLM model, enabling them to use a legitimate model for nefarious purposes. We strongly encourage organizations and individuals to consider the following best practices: Review before you run: Always carefully examine any suggested code before executing it. Don’t blindly trust the AI. Double-check code for unexpected behavior and potential security concerns. Examine the attached context: Pay close attention to any context or data that you provide to LLM tools. This information heavily influences the AI’s output, and understanding it is critical for assessing the potential impact of generated code. Some coding assistants offer features that minimize potential risks and help users stay in control of the code that is inserted and executed. If these are available, we strongly recommend actively using these features. For example: Manual execution control: Users have the ability to approve or deny the execution of commands. Use this power to ensure you understand and trust what your coding assistant is doing. Remember, you are the ultimate safeguard. Your vigilance and responsible usage are essential for ensuring a safe and productive experience when coding with AI. Exploring the risks of AI coding assistants reveals the evolving security challenges these tools present. As developers increasingly rely on LLM-based assistants, it becomes essential to balance the benefits with a keen awareness of potential risks. While enhancing productivity, these tools also require robust security protocols to prevent potential exploitation. Security issues such as the following highlight the need to stay constantly alert: Indirect prompt injection Context attachment misuse Harmful content generation Direct model invocation These issues also reflect broader concerns across all platforms that use and provide AI-driven coding assistants. This points to a universal need for stronger security measures throughout the industry. By exercising caution through practices like thorough code reviews and maintaining tight control over what output is ultimately executed, developers and users can make the most of these tools while also staying protected. The more autonomous and integrated these systems become, the more likely we are to see novel forms of attacks. These attacks will demand security measures that can adapt just as fast. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex XDR and XSIAM are designed to prevent the execution of known or previously unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module. Cortex Cloud Identity Security encompasses Cloud Infrastructure Entitlement Management (CIEM), Identity Security Posture Management (ISPM), Data Access Governance (DAG) and Identity Threat Detection and Response (ITDR). It also provides clients with the necessary capabilities to improve their identity-related security requirements. It does so by providing visibility into identities and their permissions within cloud environments, to accurately detect misconfigurations, unwanted access to sensitive data and real-time analysis of usage and access patterns. Cortex Cloud can detect and prevent malicious operations using its XSOAR platform automation capabilities, when using both Cortex Cloud Agent and Agentless-based protection and behavioral analytics to detect when IAM policies are being misused. Palo Alto Networks can also help organizations better protect their AI systems through the following products and services: Prisma AIRS Unit 42’s AI Security Assessment If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 00080005045107 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. New Jailbreaks Allow Users to Manipulate GitHub Copilot — Apex Security, published on Dark Reading Indirect Prompt Injection Threats — Greshake, Kai and Abdelnabi, Sahar and Mishra, Shailesh and Endres, Christoph and Holz, Thorsten and Fritz, Mario Indirect Prompt Injection: Generative AI’s Greatest Security Flaw — Matt Sutton, Damian Ruck 2024 Stack Overflow Developer Survey — Stack Overflow

unit42.paloaltonetworks.comSep 15, 2025extracted

Proofpoint launches agentic AI to detect risks in communication channels

Proofpoint launches agentic AI to detect risks in communication channels Proofpoint launched agentic AI solution for Human Communications Intelligence (HCI), marking a leap forward in how organizations detect, understand, and mitigate conduct and compliance risks in real time. Designed for enterprises in regulated and highly litigious industries, it transforms digital communications governance (DCG) from post-incident compliance to real-time, AI-powered risk reasoning, detection, and prevention, empowering organizations to act on human behavior before it becomes a compliance, security, or legal event. A recent study of 1,600 global CISOs reveals that more than one-third cite collaboration tools, such as Slack, Teams, or Zoom, as their top concern for introducing organizational risk, surpassing GenAI chatbots, perimeter devices, cloud storage, and even Microsoft 365. Yet for decades, compliance teams have relied on connectors and archives that capture communications but offer little AI-powered intelligence. With escalating insider threats, financial misconduct, and regulatory scrutiny, enterprises need intelligence that goes beyond raw capture and archiving to reason through real-time conversations, detect intent and behaviors, as well as signal risk. Proofpoint’s Digital Communications Governance (DCG) portfolio introduces Human Communications Intelligence, powered by agentic AI and built to reason, not just react. Unlike existing solutions that use AI to flag keywords or patterns, Proofpoint’s HCI interprets human intent, capturing and contextualizing communications across more than 80 channels in real time. Powered by Proofpoint’s Nuclei technology (acquired by Proofpoint earlier this year), intelligent agents autonomously assess conversations, flag risks as they emerge, and provide transparent reasoning for every action. “Legacy connectors are merely proxies that pass content downstream, offering little intelligence,” said Harry Labana, SVP and GM of Proofpoint’s DCG business. “Proofpoint has reimagined capture by moving beyond simply collecting messages to interpreting and reasoning in real time. This transforms the world’s largest source of behavioral data—human conversations—into actionable intelligence that empowers compliance, legal, and security teams to prevent risk before it escalates.” Real-time communications intelligence Proofpoint Capture, powered by Nuclei technology, ingests communication channels including GenAI chatbots, mobile messaging, collaboration apps, social media, email, voice, and files and applies real-time reasoning. Unlike pretrained AI models and legacy connectors, Proofpoint Capture includes purpose-built reasoning AI agents that interpret communications at scale and can integrate with third-party archives. These agents autonomously present reasoning alongside flagged content, such as misconduct, insider threats, AI misuse, regulatory violations, and even toxic culture signals, explaining why decisions are made. This transparency ensures compliance reviewers and investigators understand the logic behind each alert, rather than being left with opaque classifications. Explainable, cost-effective AI-powered supervision Proofpoint is redefining supervision with a new class of explainable AI tailored for regulated communications review. Legacy keyword and rules-based systems are limited in the types of risks they can detect, and as communication volumes rise, false positives grow. Proofpoint Supervision analyzes 100% of captured communications with advanced detection that understands tone, intent, shorthand, emojis, and even code snippets, across multiple languages. The result: up to a 90% reduction in long-tail noise, far greater precision, and significantly less manual review, delivering scalable, auditable supervision for today’s most complex compliance environments. Integrated, signal-driven risk prevention Signals generated by Proofpoint’s Human Communications Intelligence agents integrate directly with Proofpoint Insider Threat Management (ITM), correlating communications-based risk indicators with user activity across endpoints. This integration surfaces motive, means, and modes of risk across the Insider Threat Matrix and empowers organizations to act before behavior escalates into compliance violations, breaches, or litigation. By connecting what employees say with what they do, Proofpoint establishes real-time feedback loop. It also provides compliance and legal teams with a proactive shield and an auditable record of oversight, enabling defensible compliance outcomes and earlier intervention before issues escalate.

helpnetsecurity.comSep 15, 2025extracted

Don’t let outdated IGA hold back your security, compliance, and growth

If organizations want to have any chance of protecting their data from unauthorized access in 2025 and beyond, there is no way around Identity Governance & Administration. But conventional IGA solutions are the wrong option for most businesses. For companies trying to keep their data secure while maintaining a competitive edge, the stakes could not be higher. Faced with an onslaught of identity-based attacks, they need a way to efficiently manage their increasingly complex IT environments while ensuring that only the right people have access to right resources. Identity Governance & Administration (IGA) offers just that: effective access control and a way to automate essential governance tasks. Lifecycle management provides each user with the exact privileges they need for their current role while eliminating the hassle of manual on/offboarding. Self-service requests and approvals allow you to delegate access decisions and free up your helpdesk – while always staying in the loop. Separation of duties prevents users from holding conflicting privileges, even across different IT systems. Access reviews and in-depth reporting tools ensure that user access remains appropriate, even as roles and responsibilities change. Once they are fully operational, IGA solutions improve your security posture, lower your IT workload and provide the visibility you need to maintain compliance with a wide range of regulations and frameworks. There is one problem, however: Getting IGA ready takes a lot longer than you expect. Unlike their modern counterparts, conventional IGA solutions are difficult to set up and use – a major roadblock on the path to streamlined governance. Legacy IGA: What a typical deployment looks like In order to govern access across different systems, an IGA solution must first be connected to the different apps and platforms that make up your IT environment. This is not as easy as it sounds. Legacy solutions generally ship with plugins that can act as basic connectors. The real integrations, however, are built from the ground up during the setup phase – a process that involves a lot of planning, meetings and custom code. In theory, this approach is intended to make Legacy IGA infinitely customizable, allowing the final integrations to be tailored to your exact needs and specifications while modeling any business process, no matter how complex. But in practice, relying so heavily on custom code means that you have to reinvent the wheel for every single deployment. Countless hours are wasted setting up basic interactions like data mappings or workflows for new accounts, delaying the implementation and driving up costs. It can take years of setup before you see any results. Scripts and custom code still have their place in IGA integration. In sprawling enterprise environments, custom-built integrations may be the only choice to cover a wide range of divergent and inconsistent processes. But most organizations do not need this level of complexity, nor can they afford to devote their entire IT team to a drawn-out setup phase. Put simply, Legacy IGA the wrong choice for the majority of businesses, where a lean and efficient solution can deliver faster results. The approach of custom coding every interaction and workflow just has too many disadvantages: It takes huge effort to set up basic functionality. It produces a lot of rushed, low quality code since teams struggle to stick to project timelines. It makes later changes incredibly difficult because of the high degree of customization. Learnings from one deployment never benefit the rest of the userbase. Once you consider the long setup and tech debt created by so many custom integrations, it becomes clear that legacy IGA’s promise of a platform tailored entirely to your specifications simply will not realize. Instead, you are left with a project that runs over time and over budget. Wondering which IGA solution is right for you? Our detailed breakdown of available solutions explains essential features, integration timelines and the critical questions that should inform your evaluation. Read our detailed breakdown of the IGA space today. Download Now tenfold: No-Code IGA with Faster Time to Value Now imagine you could achieve comprehensive Identity Governance & Administration in just a few weeks instead of spending months or years on manual integration. tenfold, our no-code IGA solution, is able to cut down setup times and maintenance workloads thanks to true out-of-the-box integration. With a library of fully developed plugins that ship with all the workflows and interactions you need, connecting new systems is a matter of just a few clicks. Every step of setup and configuration can be completed through our visual interface alone, drastically reducing the effort needed to deploy and operate our IGA platform. Even so, the option to integrate custom code snippets still exists if orgs need additional flexibility. This streamlined approach to IGA integration allows tenfold to provide comprehensive governance in a fraction of the time it takes to set up conventional solutions. There are many benefits to no-code, out-of-the-box integration: You have lower setup costs and get faster results You have to devote fewer team members and internal resources You benefit from high-quality plugins developed and maintained by our own team You can easily add or tweak plugins down the line You enjoy comprehensive Identity Governance & Administration without the hassle Learn if No-Code IGA is right for you Don’t waste time on endless setups. No-code IGA offers a faster path to streamlined governance and still covers the same use cases, helping organizations just like yours boost their productivity, security and compliance. Learn more about tenfold and book a personal demo with our team today. Sponsored and written by tenfold Software.

bleepingcomputer.comSep 5, 2025extracted

The AI security crisis no one is preparing for

The AI security crisis no one is preparing for In this Help Net Security interview, Jacob Ideskog, CTO of Curity, discusses the risks AI agents pose to organizations. As these agents become embedded in enterprise systems, the potential for misuse, data leakage, and unauthorized access grows. Ideskog warns that the industry is “sleepwalking” into a security crisis, drawing parallels to the early days of API and cloud adoption, and outlines steps companies must take to defend against these behavior-driven threats. You’ve warned about the industry “sleepwalking” into a security crisis with AI agents. What do you mean by that, and what signs do you see that we’re already on that path? AI agents and other non-human identities are proliferating rapidly. In some organizations they already outnumber human users by more than 80 to 1. Many are deployed with broad, persistent access to systems and data, but without the same security controls, governance, or monitoring applied to human accounts. This creates a perfect opportunity for abuse, whether that’s through prompt injection, compromised credentials, or the exploitation of insecure code that they generate. We’re already seeing early warning signs. Security researchers have shown it’s possible to subvert AI assistants into running unauthorized commands, accessing sensitive files, or introducing supply-chain vulnerabilities, all without triggering typical security alerts. While these tests have been in controlled conditions, the techniques are straightforward enough that it’s only a matter of time before malicious actors use them in the wild. How would you compare the current state of AI agent security to, say, the early days of API security or cloud misconfigurations? Are we repeating similar mistakes? Yes, we are definitely seeing history repeat itself. The current state of agentic security feels very similar to the 2010s when organizations rushed to implement cloud and API adoption without understanding the security implications. In the early API era, developers often exposed endpoints without proper authentication, input validation or rate limiting. Many systems were abused or compromised as attackers found predictable patterns and misconfigurations. The shift to cloud introduced the same sort of growing pains with misconfigured storage buckets, overly permissive roles, and poor visibility. The same pattern is emerging with AI agents. The capabilities are impressive and the business pressure to adopt them is growing, but the understanding of how to secure them is lagging behind. Many teams do not yet have a threat model for AI. They are not considering how inputs can be manipulated, how AI systems can leak context across sessions, or how an over-permissioned agent can take unintended actions inside production environments. We are also seeing some operational mistakes that echo those earlier eras. There are organizations that are integrating AI agents directly with internal tools and data sources without putting proper safeguards in place. Others are skipping monitoring or logging, treating these systems as if they are just front-end chatbots. In some cases, there is no definition of what constitutes an acceptable or unsafe output, which leaves too much room for error. The key difference now is that with AI, the attack surface includes behaviour, language, and context. Existing controls cannot lock these things down easily, and a different approach is required. This could include prompt hardening, input and output filtering, and continuous monitoring of how the system behaves over time. That level of nuance is difficult to manage without purpose-built tools and a shift in mindset. The good news though, is that we do have experience to draw on. The lessons from API and cloud security still apply, principles like least privilege, secure by default, auditability, and layered defence are just as relevant, we just need to apply them in a new context. The risks here are more about influence, misinterpretation, and unintended action than code-level vulnerabilities. Can you share a real-world incident, either public or anonymized, where an insecure AI agent or bot caused or contributed to a security breach or operational issue? A recent example involved Cursor IDE, an AI-powered coding tool. Researchers demonstrated that by feeding it malicious prompts, they could trick its embedded AI assistant into executing system commands on the developer’s local machine. In this type of scenario, attackers could steal environment variables, API keys, and authentication tokens, exfiltrate sensitive files to external servers, and potentially install backdoors or alter configurations. Another example comes from GitHub Copilot, which uses OpenAI models to suggest code snippets. Early on, developers noticed Copilot sometimes generated insecure code, such as hardcoded credentials, outdated encryption, or missing input validation. This wasn’t a direct breach, but it showed how AI-generated code could quietly introduce vulnerabilities into software supply chains if not carefully reviewed. These incidents illustrate that AI agents are not passive tools but active participants in your systems. If organizations don’t implement proper guardrails, like scoped permissions, prompt hardening, behavioural monitoring, and strict output filtering, AI agents can become significant security liabilities. What does the attack surface look like for an AI agent operating within a typical enterprise environment? What are the weak points attackers are most likely to target? The attack surface of an AI agent in a typical enterprise environment is both broad and highly dynamic. Unlike traditional applications, AI agents interact through natural language, which opens new avenues for manipulation. This hybrid nature, part software system, part language interface, introduces novel security challenges. One of the most common and critical vulnerabilities is prompt injection. Because AI agents follow instructions embedded in text, attackers can craft inputs designed to override internal commands, expose hidden prompts, and even alter the agent’s intended behavior. If the agent in question interacts with sensitive data or systems, this can escalate quickly into unauthorised access or action. Another major risk is data leakage through the model’s output. Even if underlying data sources are properly secured, an AI agent can unintentionally surface confidential information in response to cleverly worded questions. Access controls often don’t apply to LLM-based systems, which means sensitive information can leak through indirect queries or context manipulation. Adversarial inputs, such as deliberately malformed, obfuscated, or ambiguous prompts, also present a growing risk. Attackers may use these to bypass filters, trick the model into making unsafe statements, or induce unexpected behavior. Further complicating the picture, integrations with enterprise tools can significantly expand the attack surface. AI agents that can call APIs, update records, send emails, or execute workflows must be strictly permissioned and isolated. An over-permissioned agent can become an unintentional attack proxy if manipulated by a malicious input. Boundaries and granular controls are essential in these situations. Training data exposure is another weak point. If an AI model has been trained or fine-tuned on internal documents or chat logs, attackers may be able to extract fragments of that data by probing the model over time. A risk that is dangerously overlooked. Lastly, infrastructure concerns still apply. The endpoints, APIs, logging systems, and middleware supporting the AI must be secured using the same principles applied to other critical systems. Weak input validation, insufficient logging, or lack of rate limiting can allow attackers to exploit not just the AI agent, but the environment it operates in. What makes AI systems particularly challenging to secure is the nature of their vulnerabilities. Many are not code-based but behavioral, the result of how the model interprets and responds to language. Security teams must account for intent manipulation, semantic ambiguity, and social engineering-style attacks delivered through prompts. To reduce risk, organizations need layered defences, prompt hardening, output filtering, behavioral monitoring, red teaming, access controls, and strong observability across all AI interactions. The attack surface includes the model, its instructions, the data it accesses, and the systems it operates within. Defenders must think like language-driven adversaries to stay ahead. What are the must-have controls or practices every organization should implement before deploying an AI agent in production? Deploying an AI agent introduces a new class of threats that must be managed with the same rigor applied to any other critical system. Before go-live, the AI environment must be secured against a broad spectrum of attack vectors, including prompt injection, adversarial manipulation, and abuse through input flooding or denial-of-service. This requires strong identity and access management, including role-based controls for both internal users and integrated systems. All data exchanged with the AI must be encrypted in transit and at rest, and exposed endpoints should be hardened, monitored, and rate-limited. AI models themselves must be treated as potential attack surfaces. Because generative models are inherently sensitive to how they are prompted, organizations must test and validate prompts under a range of conditions to prevent unexpected behavior. Guardrails, such as input/output filtering, structured responses, and constrained generation, are essential for ensuring the AI doesn’t leak sensitive information or produce unsafe content. Any modifications to prompts, model configurations, or system instructions must be logged and subject to change control. Pre-deployment testing should include red teaming and adversarial exercises tailored specifically to AI use cases. This includes simulating prompt injection, data exfiltration via language output, model manipulation, and other abuse scenarios. The agent’s performance and behavior must be evaluated not only under normal load, but also under stress conditions and malformed input. For agents connected to internal data, strong segmentation and access controls must be in place to ensure the AI cannot act beyond its authorized scope. Once live, continuous monitoring becomes critical. Organizations must implement runtime observability to detect anomalous behavior, unexpected outputs, or security policy violations. This includes logging all user interactions with sufficient detail for audit and forensic purposes, while also flagging potential misuse in real time. Where applicable, content moderation pipelines or response validation layers should be deployed to suppress or review unsafe outputs before they reach end users. Fallback mechanisms, such as routing to human operators, should be triggered when confidence is low or response behavior deviates from expectations. Cyber teams should also be prepared with an AI-specific incident response plan. This should cover also emerging failure modes unique to AI, such as model hallucinations, data leakage via completions, prompt injection-induced behavior changes, or exploitation of system prompts. Detection rules, alerts, and playbooks should be adapted to these new categories of risk. Finally, operational discipline is critical. Model deployments must be version-controlled, prompts must be auditable, and telemetry from AI interactions should feed into ongoing threat modeling. If the AI is integrated with external plugins, APIs, or agents that perform actions (such as executing code or sending messages), those integrations must be sandboxed and governed by strict permissions and approval workflows.

helpnetsecurity.comAug 20, 2025extracted

New Infection Chain and ConfuserEx-Based Obfuscation for DarkCloud Stealer

Unit 42 researchers recently observed a shift in the delivery method in the distribution of DarkCloud Stealer and the obfuscation techniques used to complicate analysis. First seen in early April 2025, these new methods and techniques include an additional infection chain for DarkCloud Stealer. This chain involves obfuscation by ConfuserEx and a final payload written in Visual Basic 6 (VB6). We previously identified a series of attacks linked to the distribution of DarkCloud Stealer. It also leveraged AutoIt to bypass detection systems. We documented these details in DarkCloud Stealer: Comprehensive Analysis of a New Attack Chain That Employs AutoIt. Palo Alto Networks customers are better protected through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. We have observed three slightly different attack chains delivering the same final DarkCloud Stealer payload in recent attacks. Each attack chain starts with a phishing email that contains either a tarball (TAR), Roshal (RAR) or a 7-Zip (7Z) archive. Both the TAR or RAR versions contain a JavaScript (JS) file, while the 7Z version contains a Windows Script File (WSF). The threat actor is at a point in development that, for all infection chain paths, almost every stage is obfuscated or protected. Figure 1 shows an overview of the different infection chains of these recent DarkCloud Stealer campaigns. In the chains initiated by a JS script, executing the script downloads and executes a PowerShell (PS1) file from an open directory server. The PS1 file then drops an executable (EXE) file that is the ConfuserEx-protected version of the final DarkCloud payload. Looking at the JS file here in Figure 2, the script is obfuscated by the tool javascript-obfuscator. Figure 3 below shows the deobfuscated version of the same script. In summary, the script: Uses ActiveXObject('MSXML2.XMLHTTP') object to obtain the next stage PS1 script at hxxp[:]//176.65.142[.]190/BLACKYY/newbag.ps1 Uses ActiveXObject('Scripting.FileSystemObject') object to drop the PS1 file as a random 8-character lowercase name in the C:\Temp folder. Uses ActiveXObject('WScript.Shell') object to run a PowerShell command to execute the PS1 file. Figure 4 illustrates an open directory server hosting many malicious PS1 files. In this case, the kay.ps1 is the next stage PS1 sample that the JS script downloaded and executed. The infection chain initiated by a 7Z archive drops a WSF file. The WSF file mainly consists of a single tag, which contains a tag. The JScript code is again heavily obfuscated, but in a different way than the JS file shown in Figure 2. It also uses ActiveXObject objects to download and execute a PS1 file from the same open directory server. However, the PS1 script associated with this WSF downloader is different. Next, we will focus on the JS-based infection chain that runs the kay.ps1 PowerShell script. This PS1 also has two layers of encryption scheme. Figure 5 shows partial code snippets from the first layer. The snippet uses Invoke-Expression (a PowerShell command that executes a string as if it were a command) to invoke another PowerShell expression that is both Base64-encoded and AES-encrypted. Figure 6 shows a code snippet from the invoked PS1 expression, revealing its core functionality. The code reveals that an EXE file is written to the %tmp% folder with a randomly generated 8-character upper- or lower-case filename. The script then executes the dropped EXE file using the Start-Process command. In the following section, we delve deeper into the analysis of the 32-bit .NET malware sample. This malware sample contains the final DarkCloud executable written in VB6 and wrapped in a layer of ConfuserEx obfuscation. ConfuserEx 2 is an open-source protector for .NET applications. Files protected with ConfuserEx are watermarked with a ConfusedByAttribute attribute. ConfuserEx comes with many features and protections such as: Anti-tampering (method encryption): This protects the application from unauthorized modification. This is accomplished by only decrypting the code of method bodies at runtime. This decryption is performed in the module constructor ( .cctor), which executes before reaching the main entry point. Symbol renaming: This changes class, method and variable names to random, meaningless, non-American Standard Code for Information Interchange (ASCII) printable identifiers. Control flow obfuscation: This alters the code structure with opaque predicates (cf. control flow flattening). Method reference hiding: This is also known as proxy call method obfuscation (this will be later described in more detail). Constant encoding: This encodes constants (e.g., strings using fixed reversible transformations. The malware author applied these protections to the analyzed malware sample. First, we can adapt the AntiTamperKiller code to defeat anti-tampering protection. This transformed the sample's .NET code, as Figure 7 shows. The method body code consists of bogus invalid .NET instructions into the deobfuscated code seen in Figure 8, where the real method body code is now visible. In particular, we extracted the specific parameters of the anti-tampering protection: Key 1: 0xc225d58c Key 2: 0xa2e32024 Key 3: 0xdcc95ec9 Key 4: 0x00000000 Name hash: 0xe0cbeae4 Internal key: 0x3dbb2819 Next, we still have more cleanup work to do on the partially deobfuscated sample. We then applied de4dot-cex (a fork of de4dot, a generic .NET deobfuscator and unpacker, which includes support for ConfuserEx deobfuscation) to the sample, using the -p crx command-line switch. This transforms the .NET sample’s code seen in Figure 8 into the code shown in Figure 9, by renaming the obfuscated symbols and reverting the control flow flattening. Thereafter, proxy call methods can be fixed using the proxy call remover tool. Proxy call method obfuscation is a technique that replaces direct method calls with calls to intermediate (i.e., proxy) methods. These proxy methods often do almost nothing besides forwarding the original call. However, they make control flow more difficult for the analyst to follow, thus hindering the code decompilation process. This reduces code readability and increases the effort required to fully understand the entire program logic. Removing these proxy call methods resulted in the simplified code seen in Figure 10. The Class8.smethod_10 method is revealed as the standard Convert.FromBase64String method. Eventually, the final DarkCloud VB6 payload (which is in Triple Data Encryption Standard (3DES) encrypted form shown in Figure 11) is decrypted and executed. The Base64-encoded key, initialization vector (IV) and ciphertext are stored as strings within the .byte_0 variable in Length-Value format, as shown in Figure 12. The standard Type-Length-Value (TLV) format (TLV) format typically includes a type identifier, but in this case, it’s omitted because all values are strings. For instance, the cryptographic key iA9B1uKFddQdqiLSSuzvD2GhL1o2Jv+v (also shown in Figure 11) is stored as a 32-byte string. The length is specified at offset 60 in little-endian format, with the string value beginning at offset 64. The .byte_0 variable value is initialized in the module constructor ( .cctor), through a series of exclusive OR (XOR) and bitwise (arithmetic bit shift) operations on a hard-coded 100,560-element unsigned integer array. After initialization, other generic .NET methods, each accepting a single integer id as parameter, use this array to index the initialized .byte_0 variable and return a string. Figure 13 shows one such method, .smethod_6. RunPE, or process hollowing, is a process injection technique. Process hollowing works by first creating a fresh instance of a (usually legitimate) process in a suspended state. The process memory is then overwritten with code from another (usually malicious) executable. Subsequently, the process thread resumes at the entry point of the overwritten code, so that the malicious code now runs in the context of the benign process. The ConfuserEx protected process uses process hollowing to inject the final VB6 payload. After decryption, the final VB6 payload named holographies.exe, is injected into a new native Portable Executable (PE) process spawned by the initial ConfuserEx process. The process used for injection is RegAsm.exe, a legitimate utility that comes with the default installed .NET Framework SDK on Windows. The presence of the string DarkCloud within the final VB6 payload (shown in Figure 14) confirms its affiliation with the DarkCloud malware family. Additionally, critical strings within the payload are encrypted using the Rivest Cipher 4 (RC4) stream cipher algorithm, with each ciphertext typically using a unique key. For instance, the ciphertext 58364B6DB1C7D797DFA59186B4 paired with the key sMgSInEGpSAgkfcMSUPDDFCVSTyhowuHorsctkyTMYZh decrypts to the string WScript.Shell. These sensitive strings can be broadly categorized as: Regular expressions Credit card names Registry paths Directory and file paths (including file extensions) Telegram API credentials (used for C2 purposes) Other miscellaneous strings DarkCloud Stealer is typical of an evolution in cyberthreats, leveraging obfuscation techniques and intricate payload structures to evade traditional detection mechanisms. The developers of the malware complicated its analysis by adopting ConfuserEx and a VB6 payload in its infection chain. The shift in delivery methods observed in April 2025 indicates an evolving evasion strategy. This highlights the need for security professionals to adopt proactive, behavior-based approaches to threat detection and mitigation. Palo Alto Networks customers are better protected from the threats discussed above through the following products: The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module. Cortex Cloud customers are better protected from DarkCloud Stealer through the proper placement of Cortex Cloud XDR endpoint agent and serverless agents within a cloud environment. Designed to protect a cloud’s posture and runtime operations against these threats, Cortex Cloud helps detect and prevent the malicious operations or configuration alterations or exploitations discussed within this article. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 00080005045107 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. Malware distribution URL hxxp[:]//176.65.142[.]190 C2 URL hxxps[:]//api.telegram[.]org/bot7684022823:AAFw0jHSu-b4qs6N7yC88nUOR8ovPrCdIrs/sendMessage?chat_id=6542615755 DarkCloud Stealer: Comprehensive Analysis of a New Attack Chain That Employs AutoIt – Unit 42, Palo Alto Networks .NET Hooking - Harmonizing Managed Territory – Jiří Vinopal, Check Point Research

unit42.paloaltonetworks.comAug 7, 2025extracted

AI can write your code, but nearly half of it may be insecure

AI can write your code, but nearly half of it may be insecure While GenAI excels at producing functional code, it introduces security vulnerabilities in 45 percent of cases, according to Veracode’s 2025 GenAI Code Security Report, which analyzed code produced by over 100 LLMs across 80 real-world coding tasks. Vibe coding “The rise of vibe coding, where developers rely on AI to generate code, typically without explicitly defining security requirements, represents a fundamental shift in how software is built,” said Jens Wessling, CTO at Veracode. “The main concern with this trend is that they do not need to specify security constraints to get the code they want, effectively leaving secure coding decisions to LLMs. Our research reveals GenAI models make the wrong choices nearly half the time, and it’s not improving.” AI is enabling attackers to identify and exploit security vulnerabilities quicker. Tools powered by AI can scan systems at scale, identify weaknesses, and even generate exploit code with minimal human input. This lowers the barrier to entry for less-skilled attackers and increases the speed and sophistication of attacks, posing a threat to traditional security defenses. Not only are vulnerabilities increasing, but the ability to exploit them is becoming easier. LLMs introduce widespread security vulnerabilities in code To assess the security of AI-generated code, Veracode created 80 coding tasks designed to expose common software weaknesses as defined by the MITRE Common Weakness Enumeration (CWE) system. Each task prompted more than 100 LLMs to complete code snippets, offering the opportunity to choose a secure or insecure implementation. The findings were stark: in 45 percent of all test cases, LLMs produced code containing vulnerabilities aligned with the OWASP Top 10, a list of the most serious web application security risks. Some languages proved especially problematic. Java had the highest failure rate, with LLM-generated code introducing security flaws more than 70 percent of the time. Python, C# and JavaScript were not far behind, with failure rates between 38 and 45 percent. LLMs also struggled with specific vulnerability types. Eighty-six percent of code samples failed to defend against cross-site scripting (CWE-80), and 88 percent were vulnerable to log injection attacks (CWE-117). “Our research shows models are getting better at coding accurately but are not improving at security. We also found larger models do not perform significantly better than smaller models, suggesting this is a systemic issue rather than an LLM scaling problem,” Wessling said. Securing the AI-driven software pipeline While GenAI development practices like vibe coding accelerate productivity, they also amplify risks. Researchers emphasize that organizations need a risk management program that prevents vulnerabilities before they reach production—by integrating code quality checks and automated fixes directly into the development workflow. As organizations increasingly leverage AI-powered development, Veracode recommends taking the following proactive measures to ensure security: Integrate AI-powered tools into developer workflows to remediate security risks in real time. Leverage static analysis to detect flaws early and automatically, preventing vulnerable code from advancing through development pipelines. Embed security in agentic workflows to automate policy compliance and ensure AI agents enforce secure coding standards. Use Software Composition Analysis (SCA) to ensure AI-generated code does not introduce vulnerabilities from third-party dependencies and open-source components. Adopt AI-driven remediation guidance to empower developers with fix instructions and train them to use the recommendations. Deploy a firewall to automatically detect and block malicious packages, vulnerabilities, and policy violations.

helpnetsecurity.comAug 7, 2025extracted